What's the difference between a closed port and a filtered port?

It's the difference between a 'no' and silence, and it tells you two different things. A closed port answers: your machine received the connection attempt and actively refused it with a TCP RST packet, because nothing is listening there. That's a fast, clean rejection — the host is up, the port is just empty. A filtered port says nothing at all: a firewall somewhere dropped your packet, so you wait until the attempt times out. Closed means 'I'm here, that door has no room behind it.' Filtered means 'something between us ate your knock.' A good external check reports these separately, and the distinction decides where you look next — the service, or the firewall in front of it.

Why does a port look open on my server but closed from outside?

Because you're asking two different questions. Running netstat or ss on the box tells you what's listening locally; an external check tells you what's reachable across the internet. The gap between them is almost always one of three things: the service is bound to 127.0.0.1 instead of 0.0.0.0, so it only accepts local connections; a host or cloud firewall (ufw, a security group, a network ACL) is dropping the traffic; or a router upstream never forwarded the port. The service is genuinely running — it's just answering a door nobody outside can knock on.

I set up port forwarding but the port is still closed. What now?

Work the path from the outside in, because the failure can be at any hop. First confirm the service is actually listening and bound to all interfaces, not just localhost. Then check the host's own firewall. Then re-read the router's forwarding rule — right external port, right internal IP (which DHCP may have changed), right protocol (TCP vs UDP). If all of that is correct and it's still closed, suspect your ISP: many put home connections behind CGNAT, where you share a public IP and simply cannot forward a port, and some block inbound ports like 25 outright.

Is scanning my own ports legal?

Checking ports on infrastructure you own or are authorized to test is normal and fine — it's the same thing every hosting provider's status page does. What you should not do is scan hosts you don't control without permission; unsolicited scanning of third parties can violate terms of service and, in some places, the law. Point an open-port check at your own domain or IP, not at someone else's.

Views: 22

Open Port Check: How to See Which Ports Are Open

Open port check: see which ports are reachable from outside, tell filtered from closed, and fix port forwarding in order. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

What “Is My Port Open” Actually Asks

When you check whether a port is open, you are asking a very specific question: if a stranger on the internet sends a packet to this address on this port, does something answer? That is not the same as “is my service running,” and confusing the two costs people hours.

An open port is an invitation. It means a program is listening there and will start a conversation with anyone who connects. That is exactly what you want for the services meant to be public — 443 for HTTPS, 22 for the SSH you actually use — and exactly what you do not want for everything else. Every open port is a door into your machine, and the list of open ports is your attack surface as the rest of the world sees it. So an external port check does two jobs at once: it confirms the doors you meant to open are open, and it shows you the ones you forgot to close.

The key word is external. Your server knows what it’s listening on; that’s a local fact. Whether the internet can reach it is a completely different fact, decided by every firewall and router between the listener and the outside. An open-port check answers the second question, which is the one that matters when something is unreachable.

What the Three States Mean

A TCP port check comes back in one of three states, and each one points somewhere different.

Open. You sent a SYN, the port sent back SYN-ACK, the handshake completed. A program is listening and reachable. Done.

Closed. You sent a SYN and got an immediate RST — a reset. The host is up and reachable, but nothing is listening on that port, so the operating system refused the connection on the spot. This is a fast, definite “no.” In application terms it’s the ECONNREFUSED / “Connection refused” you see in logs. Closed is good news, oddly: it means the network path works and the machine is alive; you’ve just found an empty port.

Filtered. You sent a SYN and heard nothing. No SYN-ACK, no RST — just silence until the attempt times out. Something dropped your packet on the floor, almost always a firewall configured to discard rather than reject. This is the “Connection timed out” case, and it feels identical to “the server is down” even though the server may be perfectly healthy behind the firewall.

That refused-versus-timeout split is the single most useful thing an external check tells you, because it says who is failing. A RST comes from the host itself, so the packet reached the machine — your problem is the service or its binding. Silence means the packet never got a reply, so your problem is a firewall or a routing dead end in front of the machine. Same symptom to a user (“I can’t connect”), opposite fixes.

(UDP is murkier and worth a caveat: because UDP has no handshake, a silent UDP port could be open-and-not-replying or filtered — the two are genuinely hard to tell apart from outside. Closed UDP ports usually trigger an ICMP “port unreachable,” but firewalls often suppress even that. Treat UDP results as softer than TCP.)

Top 3 Reasons a Port You Expected Is Closed or Filtered

The service is listening on localhost only. The single most common self-inflicted case. A service bound to 127.0.0.1:5432 works perfectly from the machine and is invisible from everywhere else — an external check shows the port closed even though the process is up. The fix is binding to 0.0.0.0 (or a specific public interface), not localhost. Check this first, because it looks exactly like a firewall problem and isn’t.
A firewall is dropping the traffic. Host firewalls (ufw, firewalld, Windows Defender Firewall) and cloud controls (AWS security groups, GCP firewall rules, network ACLs) all sit in front of your listener. If any of them isn’t allowing the port inbound, you get the silent, filtered timeout. Cloud is the classic trap: the OS firewall is open, the service is listening, and a security group nobody remembered is quietly discarding every packet.
The router never forwarded the port (or can’t). On a home or small-office connection, the public IP lives on the router, not your machine. Without a port-forwarding rule the router has no idea which internal host should receive the connection, so it drops it. And sometimes forwarding is impossible: if your ISP uses CGNAT you don’t have a public IP to forward to, and some ISPs block inbound ports like 25 regardless of your config.

Diagnose with DechoNet

Port Check — run it against your domain or public IP and read the state per port. Open means reachable; closed means the host answered but nothing’s listening (look at the service and its binding); filtered/timeout means something in front of the host is dropping packets (look at firewalls and forwarding). This is the outside-in view your own netstat can’t give you.
DNS Lookup — before trusting a port result, confirm the name resolves to the IP you think it does. A port check against a hostname that points at an old server or a CDN edge is testing the wrong machine entirely.
HTTP Check — if 80 or 443 shows open but the site still fails, the port is fine and the problem has moved up to the application; check the actual response there.

Resolution Checklist

Decide which state you have: closed (RST / refused) points at the service; filtered (timeout / silence) points at a firewall or router.
Confirm the service is running and bound to 0.0.0.0 or a public interface, not 127.0.0.1. ss -tlnp shows the bind address.
Check every firewall in the path: the host firewall and, on cloud, the security group / network ACL. All of them must allow the port inbound.
On home/office networks, verify the router forwarding rule: correct external port, correct internal IP (reserve it via DHCP so it doesn’t drift), correct protocol.
Re-run Port Check from outside after each change so you’re testing reachability, not just a local netstat.
Close what you didn’t mean to expose. If a database or admin port shows open to the internet, that’s not a connectivity win — it’s a finding.

When to Escalate

If the port stays filtered after the service, host firewall, and router all check out, suspect the ISP: ask whether your connection is behind CGNAT (no forwardable public IP) or whether the specific port is blocked upstream. Neither is fixable from your side.
If a managed load balancer, cloud ingress, or corporate firewall owns the network path, the reachability decision lives with whoever controls that layer — escalate there rather than reconfiguring the host again.