Troubleshooting guide

Port Forwarding Not Working

Do not keep changing router settings until you know which layer failed.

Diagnose the path, not just the router rule

A forwarding rule is only one link in the chain between an internet client and the application on your LAN. If any earlier or later link is broken, repeatedly editing the same router screen will not fix the problem. Use evidence in a fixed order so each step removes a class of causes.

Important: a failed TCP connection does not prove the port is “closed.” It can also mean the service is not listening, the host firewall blocked it, the forwarding rule points at the wrong device, another NAT exists upstream, or the probe timed out. Connection Vitals reports not reachable unless it has stronger evidence.

1. Prove the service works locally

From another device on the same LAN, connect to the server using its local IP address and the actual service port. Keep the service running while you test. If local access fails, stop here: the public router path is not the first blocker.

Confirm the application is running and listening on the expected TCP port.
Confirm it is bound to the LAN interface, not only 127.0.0.1 or localhost.
Check the host operating-system firewall.
Make sure the server still has the LAN IP used by the forwarding rule; a DHCP change can silently break an old rule.

2. Test the public TCP path from outside

Use the Port Forwarding Test while the application is listening. A successful external TCP connection is strong evidence that the internet-facing path reaches a listening endpoint. If it is not reachable, continue down the chain instead of guessing.

3. Compare router WAN IPv4 with public IPv4

Open the router status page and copy the active WAN/Internet IPv4. Compare it with the public IPv4 detected by Connection Vitals. If the WAN address is inside 100.64.0.0/10, carrier-grade NAT is strongly indicated. If it is an RFC1918 address such as 10.x.x.x, 172.16–31.x.x or 192.168.x.x, another private NAT layer exists upstream.

A public-looking WAN address that differs from the detected public address is not enough by itself to declare CGNAT. Re-check that you copied the active WAN interface before drawing that conclusion.

4. Verify the forwarding rule itself

Router side

Protocol is TCP for a TCP service.
Public/external port is the one you are testing.
Destination IP is the current LAN address of the server.
Destination/internal port matches the application.
No second router or modem-router layer needs the same path configured.

Server side

Application is still listening during the probe.
Host firewall permits the inbound connection.
Container/VM port mapping reaches the correct guest or container.
Reverse proxy or TLS listener is configured on the port you exposed.
No security software is silently dropping the connection.

5. Change one thing and retest

Do not change UPnP, firewall rules, NAT rules and application settings at the same time. Make one change, rerun the same external test, and keep the change only if the evidence moves in the expected direction. That makes troubleshooting reproducible instead of trial-and-error.

Run Port Forwarding Test Check CGNAT

Use the matching test at each step

Start with the Port Forwarding Test. If the public probe fails, compare WAN and public IPv4 with the CGNAT Test or Double NAT Test. If the address path is clean, continue with the local listener, forwarding destination and host firewall.