Port checker

Check whether a TCP port is open and reachable on a host.

Have feedback or an idea for this tool?

What is a port check?

A port check tests whether a specific TCP port on a host is open and accepting connections from the public internet. Every networked service listens on a port, such as 443 for HTTPS, 22 for SSH or 3306 for MySQL, and a port is reachable only if the service is running and no firewall blocks the path. This tool opens a connection from a ServerCake server to the host and port you enter and reports whether it succeeded, along with how long the handshake took. Enter a hostname or IP and a port number to test it. Use it to confirm a newly opened firewall rule works, to check that a service you just started is reachable from outside, or to diagnose why a client cannot connect to a database or an application.

Key facts

A TCP port check attempts a connection from an external host to a target host and port and reports whether the port is open, closed or filtered.
An open port means the TCP three-way handshake (SYN, SYN-ACK, ACK) completed and a service is listening, while a closed port means the host replied with a reset and nothing is bound there.
A filtered port means no reply came back before the timeout, indicating a firewall or security group is silently dropping the packet.
Common TCP ports include 22 for SSH, 80 for HTTP, 443 for HTTPS, 25 and 587 for mail, 3306 for MySQL and 5432 for PostgreSQL.
A TCP port check cannot probe UDP services such as DNS on port 53, because UDP is connectionless and has no handshake to observe.

What this port checker actually tests

This tool attempts a TCP connection from our servers on the public internet to the host and port you enter, then reports the result. It answers one precise question: can a machine on the open internet reach this port on this host right now?

Because the probe originates from our network and not from your laptop, it tests true external reachability. That is different from running a check on the server itself. A service can be running perfectly and still fail here if it only binds to 127.0.0.1, if a host firewall drops the packet, or if a cloud security group or NAT rule never forwards the port. Testing from outside is the only way to separate 'my service is down' from 'my service is unreachable from the internet'.

The result falls into one of three states. Open: the TCP handshake completed and something is listening. Closed: the host answered but rejected the connection (RST), so it is reachable but nothing is listening on that port. Filtered: no answer at all, meaning a firewall or security group is silently dropping the packet, so you cannot even tell if a service is behind it.

DNS lookup · Website speed test from India

Open vs closed vs filtered, and the TCP handshake

TCP opens a connection with a three-way handshake: your side sends SYN, the server replies SYN-ACK, and you finish with ACK. This checker performs exactly that handshake. If SYN-ACK comes back, the port is open. If the server replies with a RST (reset) packet, the port is closed - the host is up and reachable but no process is bound to that port.

Filtered is the case that trips people up. If nothing comes back before the timeout, a firewall, security group or ACL is dropping the SYN silently. From outside you cannot distinguish 'no service' from 'service hidden behind a deny rule' - both simply time out. When a port you expect to be open shows filtered, the fix is almost always a firewall or security-group rule, not the application.

Note that this tool checks TCP reachability. UDP services (for example DNS on 53 or many game servers) are connectionless and cannot be probed with a handshake, so a lack of TCP response there is expected.

Subnet / CIDR calculator

Common ports and the services behind them

Knowing which port maps to which service speeds up debugging. The usual suspects: 21 FTP, 22 SSH, 25 SMTP (server-to-server mail), 587 SMTP submission (mail clients), 53 DNS, 80 HTTP, 443 HTTPS.

On the data tier: 3306 MySQL and MariaDB, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB. These database and cache ports should almost never be open to the whole internet - they belong on a private network or behind a firewall that only allows your application servers. If this checker reports 3306, 5432, 6379 or 27017 as open on a public IP, treat it as an incident: bind the service to a private interface or lock the port to known source IPs.

For web and mail hosts, seeing 80, 443, 25 and 587 open is normal and expected. Seeing 22 (SSH) open to the world is common but worth tightening - restrict it to your office or VPN range where you can.

Password generator

Firewalls, security groups and why we only check public hosts

Every reachable port is a door someone can knock on. The right posture is to expose only the ports a service genuinely needs from the internet and drop everything else at the firewall. Use this tool after any firewall, security-group, iptables, ufw or NAT change to confirm from outside that the change did what you intended - open ports are open and, just as important, ports you meant to close no longer answer.

This checker only probes publicly routable hosts and IPs. It deliberately refuses private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback (127.0.0.0/8), link-local and other reserved space. That is an SSRF safeguard: it stops the tool being used to scan networks it should not reach and reflects what a real external client can see. To test a service on your LAN or localhost, run a local check instead (for example nc, telnet or nmap from a machine on that network).

If you host with us, the ports open on your VPS are yours to control through the firewall in your panel - open a support ticket if a rule is not behaving as expected.

SSL / TLS checker · HTTP security headers

Glossary

TCP three-way handshake: The TCP three-way handshake opens a connection through three packets: the client sends SYN, the server replies SYN-ACK, and the client finishes with ACK. A port checker performs this handshake to test reachability.
Open port: An open port is one where the handshake completed and a service is listening behind it. The server replied SYN-ACK, confirming both that the host is reachable and that a process is bound to the port.
Closed port: A closed port is one where the host answered with a TCP reset (RST) because nothing is listening there. The host is reachable, but no service is bound to that port.
Filtered port: A filtered port is one where no reply arrives before the timeout, meaning a firewall or security group is silently dropping the packet. From outside, a filtered port is indistinguishable from a hidden service.
Firewall / security group: A firewall or cloud security group is a rule set that permits or blocks traffic to specific ports. A deny rule causes a port that has a running service to appear filtered from the public internet.
UDP: UDP is a connectionless transport protocol with no handshake, used by services such as DNS on port 53. Because there is no handshake to observe, a TCP port checker cannot probe UDP services.

Questions, answered.

What does this port checker test?+

It opens a TCP connection from our servers to the host and port you enter and reports whether the port is open, closed or filtered as seen from the public internet. It tests external reachability, not whether a process exists on the box - a service can be running and still show closed or filtered if it binds only to localhost or a firewall blocks it.

What is the difference between an open, closed and filtered port?+

Open means the TCP handshake completed and something is listening. Closed means the host answered with a reset, so it is reachable but no service is bound to that port. Filtered means no answer came back at all before the timeout, which indicates a firewall or security group is silently dropping the packet - from outside you cannot tell whether a service is hidden behind it.

Why does a port show closed when my service is running?+

The most common causes are that the service is bound to 127.0.0.1 (localhost) instead of 0.0.0.0 or the public interface, or that a host firewall (iptables, ufw), a cloud security group, or a NAT rule is blocking the port from outside. Confirm the listen address with a command like ss -tlnp on the server, then allow the port inbound in your firewall and re-test.

Can I check localhost or a LAN address like 192.168.1.10?+

No. This tool only probes publicly routable hosts and refuses private ranges (10.x, 172.16-31.x, 192.168.x), loopback (127.x) and other reserved space. That is an SSRF safeguard and it mirrors what a real external client can reach. To test a service on your own network, run a local check such as nc -vz host port, telnet, or nmap from a machine on that LAN.

Which ports should I check most often?+

The usual set is 22 (SSH), 80 and 443 (web), 25 and 587 (mail), 53 (DNS), and 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis) or 27017 (MongoDB) for data services. Database and cache ports should never be open to the whole internet - if any of them answer on a public IP, lock them down to your application servers or a private network.

Can this tool check UDP ports?+

No, it checks TCP only. TCP uses a three-way handshake (SYN, SYN-ACK, ACK) that gives a clear open or closed signal. UDP is connectionless, so there is no handshake to observe and an absence of reply cannot be interpreted reliably. For UDP services such as DNS or many game servers, use a UDP-aware tool like nmap -sU from a host that can reach the target.

Does an open port mean my server is insecure?+

Not by itself, but every open port is an attack surface someone can probe. The principle is least exposure: publish only the ports a service genuinely needs from the internet and firewall the rest. Restrict admin ports like SSH to a VPN or known IP range, and never leave database ports open to the world.

I changed a firewall or security-group rule - how do I confirm it worked?+

Run this checker against the public IP right after the change. Because the probe comes from outside your network, it shows exactly what an external client sees. Confirm the ports you meant to open now answer, and just as importantly that ports you meant to close no longer respond. This external verification catches rules that were applied to the wrong interface or never took effect.

Built by the ServerCake team

Cloud that speaks India.

These tools run on ServerCake infrastructure in India. When our cloud opens, you get VMs and managed databases priced in ₹, billed with GST, on India-resident infrastructure. Reserve your spot for early access.

Reserve your spot

More tools

Browse all tools