How to check if a port is open
And why a service that is clearly running can still be unreachable.
"Is the port open?" usually means one specific thing: can a computer on the public internet open a connection to my IP address on that port number? That single question hides four or five separate things that all have to line up. This guide covers how to test it and how to work through each layer when the answer is no.
The quick test
Open the ShittyRobots.com front page, find the Port Checker, type the port number, and run it. The check is made from an outside server to the public IP shown at the top of the page, so it reflects what the rest of the internet sees — not what works from inside your own network. A test from your own machine to localhost or to your LAN IP will happily succeed even when the port is firewalled off from the world, which is why an external check is the only one that answers the real question.
Reading the result
Open means the connection completed. Something is listening on that port and every device in the path — your computer's firewall, your router, and your ISP — allowed the connection through.
Closed or not reachable means the attempt was refused or simply timed out. A refusal usually means the packet reached your network but nothing was listening. A timeout usually means the packet was dropped silently by a firewall or never arrived. The checker cannot always tell those apart, so treat "closed" as "not usable from outside" and start working through the list below.
Why a running service still shows closed
Roughly in the order worth checking:
1. No port-forwarding rule on the router
On a home connection, your router has the one public IP and every device behind it has a private one (192.168.x.x or 10.x.x.x). An inbound connection hits the router, and unless you have created a port-forwarding rule that says "send port 25565 to 192.168.1.50," the router has nowhere to send it and drops it. Add a rule mapping the external port to the internal device's IP and the same (or chosen) internal port. Give that device a static/reserved address first, or the rule will point at the wrong machine after the next reboot.
2. A firewall on the device
The operating system firewall may allow the app to make outbound connections while still blocking inbound ones. On Windows, add an inbound rule for the port or the program. On Linux, check ufw, firewalld, or raw iptables/nftables. On macOS, check the application firewall. Security software from third parties can add its own layer on top.
3. The service is bound to localhost only
Many servers listen on 127.0.0.1 by default, which accepts connections only from the same machine. It needs to listen on 0.0.0.0 (all interfaces) or the machine's LAN address to accept connections from elsewhere. This is a config setting in the service, often called bind, listen, or host.
4. Your ISP blocks the port
Residential ISPs commonly block inbound port 25 (SMTP) to fight spam, and some block 80 and 443 to discourage home web hosting. If a well-known port refuses to work no matter what you change, try a high, uncommon port (for example 8080 instead of 80) and see if that succeeds. If it does, the low port is being blocked upstream.
5. Carrier-grade NAT (CGNAT)
If the public IP on the ShittyRobots front page does not match the "WAN" or "Internet" IP shown in your router's status page, your ISP is putting you behind carrier-grade NAT: you share one public address with many other customers and have no way to accept unsolicited inbound connections. No amount of port forwarding fixes this. Options are to ask the ISP for a real (often "static") public IP, or to use a relay such as a VPN with port forwarding, a reverse tunnel, or a service like Tailscale or ngrok.
6. Nothing is actually listening
Confirm the service is running and on the port you think it is. On the host itself, ss -tlnp (Linux), netstat -an (Windows/macOS), or lsof -i :PORT will show what is bound where.
A sane order of operations
Verify the service is listening on all interfaces → confirm the device firewall allows the port → add the router forwarding rule to that device's reserved IP → re-run the external check → if a common port still fails, test a high port to rule out an ISP block → if even a high port fails and your router's WAN IP is not public, you are behind CGNAT.
Common ports, for reference
22 SSH, 80 / 443 web, 3389 Windows Remote Desktop, 5900 VNC, 32400 Plex, 25565 Minecraft, 51820 WireGuard, 27015 many game servers. When verifying a forwarding rule, test the exact external port from the rule.
Next: How to tell if your VPN is leaking →
← Back to the diagnostics tool