How to Tell Whether a Closed Port Is Your Router, Your ISP or Your Host

You set up the service, you opened the port, and the checker still says closed. That word is not a diagnosis. It only says the connection did not get through. The block could be on the machine running the service, on your router, or upstream with your provider, and each needs a different fix. Work from the service outwards, and stop at the first place the connection fails.

First, is anything actually listening?

Check on the machine itself first. A port is only open when a program is running and waiting on it. If the service crashed, every outside check will report closed, and that result is correct.

On Linux, run ss -tlnp. On Windows, use PowerShell with Get-NetTCPConnection -State Listen. On macOS, lsof -iTCP -sTCP:LISTEN shows the same picture. Check the address it is bound to, as well as the port. A service bound to 127.0.0.1, or localhost, accepts connections only from that same machine. A service meant to be reached over the network usually needs to listen on all addresses, shown as 0.0.0.0. Then test it from the machine itself.

Second, does it work on your own network?

Next, try to reach the service from a second device on the same network, using the machine's private address and the port number.

If that fails while the test on the machine itself passed, the block is almost certainly the host firewall. Add an inbound rule for the exact port and protocol, TCP or UDP, and test again. If the local test works, the service and its firewall are fine, and the block is at the router or beyond it.

Third, the router: forwarding, the wrong address, or a second router

A router keeps your private network separate from the internet, so an incoming connection needs a port forwarding rule pointing at the right machine: the outside port, the protocol, the inside address, and the inside port.

The most common mistake is a stale inside address. Home networks often hand out private addresses automatically, and a machine can get a different one after a restart, leaving the rule pointing at the wrong machine. Give the server a fixed private address, reserved in the router. Also check the protocol. A TCP checker tells you nothing about a UDP service, and a TCP rule will not carry UDP traffic.

Also check for a second router. If your provider's modem is also a router, traffic is translated twice, and your rule never sees the incoming connection. Putting the provider's device in bridge mode removes the extra layer. Run our Port Checker against your public address only after the service is running and the rule is in place. It confirms the outside view, but it cannot say which device dropped the connection.

Fourth, the host: when the service runs on a rented server

If the service runs on a rented server, the firewall may live in two places: the operating system, and a separate firewall run by the provider, often called a security group. Both must allow the port.

Fifth, the ISP: shared addresses and blocked ports

If everything above passes and the outside check still fails, look upstream. Log in to your router and find its WAN address, the address your provider gave the router. Then check the address the internet sees you from, using our What's My IP tool. If the two are the same public address, port forwarding can work.

If they differ, something upstream is translating your traffic. That is often carrier-grade NAT, or CGNAT, where the provider shares one public address among many customers. Your router then gets a private or shared address, and no forwarding rule on it can be reached. A WAN address starting with 100.64 through 100.127 is a strong sign of CGNAT. A WAN address in the 10.x.x.x or 192.168.x.x ranges points to the same kind of upstream translation. If you see either pattern, ask your provider for a public IP address, or use a tunnel or a VPN with port forwarding. If the addresses match, CGNAT is not your problem.

Some providers also block specific incoming ports, commonly port 25 for mail, on residential connections. Ask your provider whether the port is blocked on your plan.

What "closed" and "filtered" actually tell you

A fast refusal means the packet reached a machine that answered, but nothing was listening, or a firewall rejected it. A timeout means the packet was silently dropped somewhere along the path. Our Port Checker reports those two together as closed or filtered, because a single outside check cannot honestly tell them apart. A TCP checker also cannot confirm a UDP service. Test UDP services with the application itself.

A worked example

You start a game server on a home PC, and you can join it, but a friend cannot. The listening list shows the server, bound to all addresses. A laptop on the same Wi-Fi network can join, so the host firewall is fine. The router rule points at an old private address, so you reserve a fixed address and update it, and the friend still cannot connect. The router's WAN address differs from the address shown by IP Lookup, and starts with 100.64, which points to CGNAT. No router change will fix that. Each step ruled out one suspect.

The decision order, in one list

• Listening? If the service is not in the listening list, or is bound only to localhost, fix the service.
• Local network? If a second device on the same network cannot connect, fix the host firewall.
• Router? Check the forwarding rule, the fixed private address, the protocol, and whether a second router is translating traffic twice.
• Cloud firewall? For a rented server, check the provider's security group as well as the operating system firewall.
• ISP? Compare the router's WAN address with your public address. A mismatch, or a WAN address in the 100.64 to 100.127 range, points to CGNAT. Check whether the provider blocks that port.
• Wrong test? If the service uses UDP, confirm it with the application itself, not a TCP check.

What to do first

Start with the listening check, because it takes a minute and rules out the most common cause: a service that is not waiting for connections. Then run the local network test before you change any router setting. Only check systems you own or have permission to test, and keep the ports you open to the ones a service genuinely needs.