Open Port Check

Open, closed, filtered — three answers, not two

A TCP connection starts with one packet: a SYN. What comes back decides everything, and there are exactly three outcomes worth distinguishing.

Open: The SYN was answered with SYN-ACK. Something is listening and willing to talk. This is the only result that proves a service is reachable from the internet.
Closed: The answer was RST — a refusal. This is far more informative than it looks: the packet arrived. The host is up, it is reachable, and your routing and NAT are fine. Nothing is listening on that port, that is all.
Filtered: Nothing came back at all. The packet was swallowed somewhere along the way — a firewall configured to drop rather than refuse, a provider blocking the port, or a router with no forwarding rule for it.

Closed and filtered are opposite diagnoses. Closed says "the packet reached the machine, fix the service". Filtered says "the packet never got there, fix the path". A checker that collapses both into "not open" has answered half the question, and it is the half you already knew.

Why testing from your own machine proves nothing

The most common way people convince themselves a port is open is to test it locally — telnet localhost 8080, or a browser pointed at their own machine. That test succeeds no matter how thoroughly the port is blocked from outside, because it never leaves the computer. Every layer that could be the problem is skipped: the host firewall's inbound rules, the router's port forwarding, the provider's filtering, and the question of whether you have a public address at all.

A check from outside is the only one that answers the real question, because it travels the same path a genuine visitor would.

The chain a packet has to survive

When a port is filtered, the fault is in one of five places. Work through them in this order, because the list is sorted by how often each turns out to be the culprit:

The service is bound to the wrong address. By far the most common cause, and the most frustrating to find. A process listening on 127.0.0.1:8080 is invisible to the network, even though every local test passes and the log looks perfect. Check with ss -tlnp — if the address column shows 127.0.0.1 rather than 0.0.0.0 or [::], nothing else you change will help.
The host firewall. Modern distributions ship with one enabled. It usually drops rather than rejects, which is exactly what produces a filtered result.
The router. Port forwarding needs the rule, the right internal address, and the right protocol. Internal addresses handed out by DHCP change; a forwarding rule written six months ago may now point at a device that is no longer there.
Your provider. Inbound port 25 is blocked on virtually every consumer connection, and 80, 443 and 445 are commonly blocked too. This is policy, not a fault, and no configuration on your side changes it.
You do not have a public address. If your router's WAN address differs from the address this site sees, there is another layer of NAT between you and the internet, and inbound connections cannot reach you at all. See below.

When port forwarding cannot work at all

IPv4 ran out of free addresses years ago, and providers responded by sharing what they had. Under carrier-grade NAT your router does not get a public address; it gets one from the range reserved for exactly this purpose by RFC 6598, 100.64.0.0/10, and the operator translates it again on the way out. Hundreds of subscribers can be behind one public address.

There is no inbound path in that arrangement. The public address does not belong to you, so nothing can be forwarded to you: self-hosting, game servers, inbound VPN and remote access to a home NAS all stop working, and no setting in your router will change it. The test takes ten seconds — compare the WAN address on your router's status page with the address shown on our main page. If they differ, and especially if the router shows something starting with 100., that is your answer. The remedies are asking the provider for a public address (often a paid option), using IPv6 if it is available, or a tunnel service that gives you a reachable endpoint elsewhere.

Ports you should think twice about exposing

An open port is not automatically a problem — a web server needs 80 and 443 open. But some services were designed for trusted networks and behave accordingly when they are reachable from the whole internet:

Port	Service	Why it matters
22	SSH	Reachable is fine, password authentication is not. Automated login attempts start within minutes of a port opening. Keys only, and no root login.
3389	RDP	Exposed RDP is one of the most reliable ways ransomware gets into a network. It belongs behind a VPN, not on the open internet.
445	SMB	File sharing was never designed for the internet. It should never be reachable from outside, and most providers block it for you.
3306 · 5432	MySQL · PostgreSQL	A database should be reachable by your application, not by everyone. Bind it to localhost or a private network.
6379 · 27017 · 9200	Redis · MongoDB · Elasticsearch	All three historically shipped with no authentication and listened on all interfaces. Mass compromises of exposed instances are a recurring event, not a theoretical risk.
23	Telnet	Unencrypted, including the password. Its main remaining use is as an entry point for botnets scanning consumer devices.
21	FTP	Also unencrypted, and awkward through NAT because of its second data connection. SFTP does the same job over SSH.

Why we do not scan ranges

Checking a handful of ports on a host is diagnostics. Sweeping a range is scanning, and the distinction is not academic: port scans are what abuse complaints are made of, and a service that offers them gets its own address blocked by exactly the networks its users want to reach. So this tool accepts a short list of individual ports, refuses ranges, caches results briefly, and logs every target it is asked about.

The same reasoning is why the field starts filled in with your own address. Checking your own ports covers essentially every legitimate reason to be here — "did my forwarding work", "is 25 open on my server", "is my new firewall rule doing what I meant". Checking somebody else's is occasionally legitimate and frequently not, and defaults should make the common honest case the easy one.

After the check

An open port tells you a service is reachable; it does not tell you the service is healthy. If the port is open but the site does not load, the problem has moved up a layer — to TLS, to a virtual host, or to the application itself. Our website check looks at exactly that. If the port is filtered and you want to know whether the host is reachable at all, ping answers a narrower question quickly, with the caveat that plenty of hosts drop ICMP on purpose.

Frequently asked questions

The service is running, so why does the port show as filtered?

Most often because the service is listening on 127.0.0.1 instead of all interfaces. It works perfectly in every local test and is completely invisible from the network. Check the listening address first — on Linux, ss -tlnp shows it. After that, look at the host firewall, then the router forwarding rule, in that order.

What is the difference between closed and filtered?

Closed means your packet reached the machine and was actively refused with a RST: routing, NAT and forwarding all work, and nothing is listening on that port. Filtered means nothing came back at all, so the packet was dropped silently somewhere on the way. They point at opposite halves of the problem, which is why we report them separately.

Why can I not open any port at all, no matter what I configure?

Compare the WAN address on your router with the address this site shows you. If they differ, your provider is using carrier-grade NAT and the public address is shared with other subscribers, so there is no inbound path to your router to forward. No router setting changes this. The options are a public address from your provider, IPv6 if you have it, or a tunnel service.

Can I check ports on someone else's server?

The field accepts any host, but keep it to systems you are responsible for. Checking a few ports is diagnostics; sweeping ranges is scanning, and it generates abuse complaints for whoever appears to be doing it. That is why this tool takes a short list of individual ports rather than ranges, and logs every target.

Is having an open port dangerous?

Only if what is behind it is. A web server needs 80 and 443 open and that is entirely normal. The risk comes from services designed for trusted networks — remote desktop, file sharing, databases and caches — which are attacked automatically within minutes of becoming reachable. If you must expose one, put it behind a VPN rather than on the open internet.

My port 25 will not open. Is that my fault?

No. Inbound and outbound port 25 is blocked by virtually every consumer provider, and by many hosting providers by default, specifically to limit spam from compromised machines. It is a policy decision on their side. Business plans sometimes allow it on request; otherwise mail has to go out through a relay.

Why does the result sometimes appear instantly?

Because we cache the result for the same address and port list for a short time. Pressing "check" repeatedly is a natural thing to do while you are fixing something, and without the cache each press would send a fresh burst of connection attempts at the target — which is exactly the behaviour that gets a checking service blocked.