Open Port Checker - Test Any Port Online

What this tool actually measures

This checker opens a plain TCP connection from our server to the host and port you enter, then reports whether the three-way handshake completed. Nothing more is sent: no banner is read, no protocol is spoken, no payload is delivered. The Response Time column is the time that handshake took in milliseconds, which is mostly network round-trip plus however long the remote host took to accept.

The attempt is abandoned after a 3-second timeout. A host that is slow but alive can therefore be reported as closed if it needs longer than three seconds to answer, which occasionally happens with long-haul links or an overloaded server.

Because the test is TCP-only, UDP services cannot be checked here. Port 53 is in the common-port list because DNS also listens on TCP, but a DNS resolver that serves UDP only will come back closed. The same applies to anything else UDP-based.

Use this on infrastructure you own or have written permission to test. Private and reserved IP ranges are rejected by the server, so this cannot be pointed at a LAN, a loopback address or internal infrastructure.

Open, closed and filtered are three different things

This is the single most misread part of any port test. There are three real outcomes on the network, but a TCP connect test can only distinguish two of them:

Open — the handshake completed. Something is listening on that port and accepted the connection. This is unambiguous: an open result is a real, reachable listener.

Closed — the host is reachable and actively refused the connection, usually with a TCP RST. Nothing is listening on that port, but the machine itself answered.

Filtered — a firewall silently dropped the packet. No RST comes back, no answer at all, so the connection simply hangs until it times out. Dropping rather than refusing is the normal default for a hardened firewall, because it gives an unauthorised prober nothing to work with.

Our result column shows only Open or Closed, and closed covers both of the last two cases. The clue that separates them is the response time: a genuine refusal comes back in roughly the same few milliseconds as an open port on the same host, because a RST travels at network speed. A filtered port burns the full timeout. So if port 443 answers Open in 40 ms and port 22 reports Closed after about 3000 ms, port 22 is almost certainly firewalled rather than vacant.

Your service is running but the port shows closed

A service that works perfectly when you test it on the box but reports closed from outside is nearly always one of these five things, roughly in order of how often it turns out to be the cause:

The daemon is bound to 127.0.0.1 instead of 0.0.0.0. This is the classic one. A process listening on loopback only is invisible to the rest of the world no matter how open your firewall is. MySQL ships this way deliberately, and Redis has bound to loopback by default since 3.2. Check the listen or bind directive in the service config, not the firewall.
A host firewall is dropping the packet. On Linux that is usually ufw, firewalld or raw nftables rules; adding a rule for your application is not enough if a default DROP policy sits earlier in the chain.
A cloud security group or network ACL has not been updated. AWS security groups, Azure NSGs, GCP VPC firewall rules and most VPS control panels filter traffic before it ever reaches the instance, so the operating system sees nothing and your host-level rules look fine.
NAT or port forwarding is incomplete. Behind a router, an open port on the internal machine means nothing until the router forwards the external port to that internal address. Many consumer ISPs also place customers behind carrier-grade NAT, where inbound forwarding is impossible at any price without a static or public address.
The provider blocks the port upstream. Outbound port 25 is blocked by almost every residential ISP and most cloud providers to limit spam, and some residential plans block inbound 80 and 443 to discourage hosting. Nothing you configure on the server can lift a block applied one hop before it.

Work through the layers from the inside out: confirm the process is listening on the right address, then the host firewall, then the cloud or router layer, then the provider. Testing from outside after each change tells you which layer was responsible.

Why an outside test differs from netstat or ss

Running ss -tlnp or netstat -tlnp on the server answers a different question from this tool. The local command lists sockets the kernel has bound and the address each one is bound to. It knows nothing about whether packets from the internet can reach them, because every firewall, security group and NAT device sits between the two.

That gap is exactly why both views are needed. If ss shows 0.0.0.0:8080 listening but an outside test says closed, the socket is fine and the problem is somewhere in the path — a firewall or a missing forward. If ss shows 127.0.0.1:8080, you have already found the bug and no firewall work is required. And if ss shows nothing at all, the service is not running and no amount of network configuration will help.

Testing from your own laptop is also not the same as testing from the internet. Office and home networks apply their own egress filtering, and a port that works from the same subnet may be reachable only because the traffic never crossed the firewall you are trying to validate. An independent vantage point is the point of a hosted checker.

Ports that should never face the public internet

Several entries in the common-port list are included so you can confirm they are not reachable. Database and remote-access ports exposed to the public internet are found by automated scanners within hours, and a few of them historically shipped with no authentication at all:

6379 Redis — before protected mode arrived in 3.2, a Redis instance on a public interface accepted commands from anyone, and attackers used CONFIG SET to write SSH keys straight to disk. Bind it to loopback or a private network and require a password.
27017 MongoDB — older releases bound to all interfaces with authorisation disabled, which produced waves of wiped-and-ransomed databases. Enable authorisation and keep it off public addresses.
3306 MySQL and 5432 PostgreSQL — reachable database ports invite credential-stuffing and exploit attempts against the server itself. Applications should reach them over a private network, a VPN or an SSH tunnel.
3389 RDP — a favourite entry point for ransomware crews running password spraying. Put it behind a VPN or a gateway and never leave it open to the world.
23 Telnet, 5900 VNC and 445 SMB — Telnet sends credentials in clear text, plain VNC is weakly authenticated, and exposed SMB is how worms such as WannaCry propagated. Use SSH instead of Telnet, tunnel VNC, and keep SMB on the local network.

The ports that normally should be open on a public server are a short list: 80 and 443 for web traffic, 22 for administration if it is not behind a VPN, and the mail ports if you genuinely run mail. Everything else reachable from outside deserves a reason.

Frequently asked questions

The port is open but my application still does not work. Why?

Open means the TCP handshake succeeded, nothing more. A listener can accept connections while the application behind it returns errors, speaks the wrong protocol, presents an expired certificate or sits behind a proxy that is misconfigured. Once a port tests open, the network is no longer the problem and the investigation moves to the application and its logs.

Can I check a port on my home router or local network?

Only by its public IP address. The check runs from our server on the internet, and private and reserved ranges — 192.168.x.x, 10.x.x.x, 172.16–31.x.x, 127.x.x.x — are rejected, since from here they would resolve to our own infrastructure rather than yours. Testing a port forward from outside is a valid use: enter the public address the forward points to.

Why does a closed port sometimes take three seconds?

That is the timeout expiring. A refused connection answers almost immediately; a firewalled one answers never, so the attempt runs the full three seconds before being abandoned. A slow closed result is a strong hint that the packet is being dropped rather than refused.

Does scanning all common ports look like an attack?

Twenty-one sequential TCP connections is ordinary diagnostic traffic and far below the volume that triggers automated defences. Even so, an intrusion-detection system on the target may log the connections, and some hosting providers treat unsolicited scans as an abuse matter. Run it against infrastructure you own or have been authorised to test.

Can this tell me what software is listening on an open port?

No. The connection is closed as soon as the handshake completes, so no banner is read and no version is detected. The Service column is simply the conventional name registered for that port number — it is a label, not a measurement, and a host is free to run anything it likes on any port.