Guide

How to check if a port is open

Three possible answers, and what each one tells you to change.

The test only means something from outside

Checking a port from the machine running the service tells you almost nothing. The connection never leaves the host: it does not cross the host firewall the way external traffic does, it does not reach your router, and it never touches your provider's network. A service can pass that test perfectly and be completely invisible to the internet.

A useful port check is made from somewhere else, across the same path a real client would take. That is what makes the answer meaningful — and it is also why the answer sometimes contradicts what you see locally.

Three answers, three different problems

Result	What happened	Usual cause	What to do
Open	A TCP connection completed	A service is listening and reachable	Nothing to fix — confirm it is the service you intended to expose
Closed	The host answered, refusing the connection	The host is reachable but nothing is listening on that port	Start the service, or check which address and port it bound to
Filtered	Nothing answered at all	A firewall dropped the packet without replying	Work outward: host firewall, router, then the provider

The distinction between closed and filtered is the single most useful thing a port check tells you, and it is routinely ignored.

Closed is a reply. Something at that address received the packet and sent back a refusal, which means the network path works end to end and the only missing piece is a listening service. That is a small problem with an obvious fix.

Filtered is silence. The packet was sent and nothing came back at all, which means something in the path discarded it deliberately rather than answering. Firewalls behave this way on purpose: a refusal confirms that a host exists, and dropping the packet reveals nothing. Filtered is therefore a network problem, not a service problem, and starting the service will not change it.

Working outward from the service

A filtered result has one cause somewhere along the path, and the reliable way to find it is to check each layer in order rather than guessing. Each of these can produce exactly the same symptom.

Layer	The question to ask
The service	Is it running, and bound to 0.0.0.0 rather than 127.0.0.1?
Host firewall	Does ufw, firewalld, iptables or Windows Defender allow it?
Cloud security group	On a VPS or cloud host, is there an inbound rule?
Router	Is there a port-forward to the right internal address?
The provider	Is the port blocked upstream, or are you behind CGNAT?

The bind address catches almost everyone once

A service bound to 127.0.0.1 accepts connections only from the machine it runs on. A service bound to 0.0.0.0 accepts them on every interface. Many packages default to the former for safety, and the resulting symptom is precise: it works locally, and every external check reports filtered or closed.

On Linux, ss -ltnp shows what is listening and on which address. A line reading 127.0.0.1:8080 is the whole explanation; a line reading 0.0.0.0:8080 or *:8080 means the service is willing and the problem is further out.

Carrier-grade NAT is the one you cannot configure around

If your provider has put you behind carrier-grade NAT, inbound connections cannot reach you at all. Your router holds an address in 100.64.0.0/10, the real public address is shared with other customers, and the translation happens on equipment you have no access to. No port forward, no firewall rule and no router setting changes this.

The diagnostic takes ten seconds: compare the address your router reports on its WAN interface with the address an IP lookup reports for you. If they differ and the router's is in that range, stop troubleshooting locally and ask your provider for a public address.

Which ports are worth exposing

An open port is not a vulnerability. It is a service that is reachable, which is the entire purpose of running a server. What matters is which service, whether it is current, and whether it authenticates.

Ports serving public protocols behind maintained software — 443 for HTTPS, 22 for SSH with keys rather than passwords — are ordinary. Ports exposing databases and management interfaces are not: 3306, 5432, 6379, 27017 and 9200 should almost never be reachable from the internet, and finding one open is usually a misconfigured cloud security group rather than a decision anybody made.

The useful habit is to check what is open from outside occasionally, rather than to assume the firewall rules you wrote are the firewall rules in effect. Configuration drifts; an external check is the only thing that reflects reality.

Why some ports cannot be checked

A check that connects to arbitrary ports on arbitrary hosts is a port scanner, and a public one would be used to scan networks its users do not own. Restricting checks to public addresses and a fixed list of well-known service ports keeps the tool useful for the question people actually have — "is my service reachable?" — without making it a scanning service.

Frequently asked questions

What is the difference between closed and filtered?

Closed means something answered and said no: the host is reachable, the packet arrived, and the operating system replied that nothing is listening on that port. Filtered means nothing answered at all — the packet went into the network and no response came back, so a firewall almost certainly dropped it silently. Closed tells you the service is not running; filtered tells you the packet never got far enough to find out.

Why does my port look open locally but closed from outside?

Because those are two different tests. Connecting to your own machine never leaves it — the traffic goes through the loopback interface, past your router, your ISP and any firewall between them. A test from outside crosses all of those. A service bound to 127.0.0.1 rather than 0.0.0.0 produces exactly this result: it works perfectly from the same machine and is invisible to everyone else.

I forwarded the port and it still shows filtered. What now?

Check whether you are behind carrier-grade NAT before changing anything else. If the address shown on your router does not match the address a lookup site reports for you, and the router address begins 100.64 through 100.127, then port forwarding cannot work at any setting — the second translation happens on equipment you do not control. Ask your provider for a public address; some offer one on request, some charge, and some cannot.

Can I check a port on someone else’s server?

You can check whether a public service is reachable, and that is a normal, unremarkable thing to do — it is exactly what every client on the internet does before it connects. Scanning a range of ports, or a range of hosts, is a different activity with different legal and contractual implications depending on where you and the host are. This tool checks one port on one public host at a time, deliberately.

Why is a well-known port blocked on my home connection?

Residential ISPs commonly block inbound port 25 to limit spam, and some block 80 and 443 to discourage home servers. That block is upstream of your router, so nothing you configure locally will change it. The usual workaround is to run the service on a high port, or to put it somewhere with a public address and no such policy.

Does an open port mean I am at risk?

Not by itself. An open port means a service is listening and reachable — which is the point of a web server. The risk lives in what that service is, whether it is patched, and whether it requires authentication. An open 443 serving a current web server is fine; an open 3306 exposing a database to the internet is a serious problem regardless of how ordinary the port looks.

Try it yourself

Everything above is easier to follow against a real answer.