Common router mistakes
- TCP vs UDP mismatch.
- Wrong public/external port.
- Forwarding to an old DHCP address.
- Wrong internal destination port.
- A second router or gateway exists upstream.
Troubleshooting guide
Why Is My Port Closed?
Use this order so each step removes a class of causes.
“Closed” can hide several different failures
When a simple port checker cannot connect, the useful question is not just “is the port closed?” but “where did the connection stop?” A browser-backed external TCP probe can strongly verify a successful path, but a failed connection can have several causes. Connection Vitals therefore uses reachable and not reachable unless stronger evidence identifies the blocker.
1. Confirm the service is listening on your LAN
Keep the target application running and connect to it from another device on the same home network. Use the server's LAN IP and the actual internal TCP port. If that fails, the public router rule is not the first problem.
- Confirm the application process is running.
- Confirm it listens on the expected port and interface.
- Check Windows/Linux/macOS firewall rules or appliance firewall settings.
- If the service runs in Docker, a VM or another container system, verify the host-to-guest port mapping.
2. Run an external TCP reachability check
Run the TCP Port Checker while the service is active. If Connection Vitals establishes the connection, the public TCP path is reachable. If it cannot, do not infer a single cause from that failure alone.
3. Check whether the router actually owns the public IPv4
Compare the router's WAN IPv4 with the public IPv4 shown by Connection Vitals. A WAN address in 100.64.0.0/10 strongly indicates CGNAT. An RFC1918 WAN address indicates another private NAT layer. Either can prevent a forwarding rule on the inner router from controlling the full inbound path.
4. Inspect the forwarding rule
Common host mistakes
- Service stopped after the rule was created.
- Firewall allows LAN but not the intended inbound path.
- Application bound only to localhost.
- Container/VM mapping does not match the router rule.
- Reverse proxy or TLS listener is on a different port.
5. Test from outside, not through a misleading local path
Some routers do not support NAT loopback/hairpinning consistently. A hostname or public IP can therefore behave differently when tested from inside the same LAN. Connection Vitals performs its TCP reachability check from Cloudflare infrastructure outside the browser's home path, which is the relevant direction for public inbound reachability.
6. Retest after one change
Change one variable at a time. If you simultaneously alter the port, firewall, forwarding destination and application binding, a successful retest will not tell you which change mattered. The fastest troubleshooting process is evidence → one change → same retest.
Measure before changing another rule
Use the TCP Port Checker while the service is listening. If the result is not reachable, the Port Forwarding Test adds WAN/public-IP evidence so you can separate local forwarding from upstream NAT.