Testing guide
How to Test Port Forwarding
A useful port-forwarding test checks the service, protocol, LAN target, firewalls, router path, and test location in the right order. A closed-port result alone cannot tell you which part failed.
The most important rule: something must be listening
A router can forward arriving packets, but it cannot make an inactive application answer. If you test a port while the intended service is stopped, the result will usually be closed, refused, or timed out even when the forwarding rule is otherwise correct. Start the real service first and confirm it is listening on the expected local interface and port.
Testing with an unrelated temporary service can be useful for an experienced operator, but it proves only that temporary service's path and configuration. It does not verify that the final application uses the same protocol, port, or bind address.
Test sequence
Work from the application outward
Step 1
Start the application or service
A port is not open merely because a router rule exists. The server, game, camera service, or other application must be running while you test.
Step 2
Confirm the listening port and protocol
Check the application documentation and its current configuration. Port 25565/TCP and port 25565/UDP are different network endpoints.
Step 3
Verify the target LAN address
The forwarding rule must point to the current LAN IP of the device running the service. A DHCP reservation helps stop that address changing later.
Step 4
Check device and router firewalls
The operating-system firewall must allow the service, and the router must allow the forwarded traffic. Avoid disabling either firewall globally just to make a test pass.
Step 5
Test from outside your LAN
Use mobile data or another external connection. Testing from the same Wi-Fi can fail or behave differently when a router lacks NAT loopback or hairpin support.
Step 6
Interpret the result in context
Reachable is strong evidence for that TCP path at that moment. Refused, timed out, or inconclusive results require more checks and do not prove CGNAT by themselves.
TCP and UDP need different tests
TCP has a connection handshake, so a remote checker can attempt a connection and report whether the target accepted, refused, or failed to answer. UDP has no equivalent handshake. A silent UDP service can look identical to a firewall dropping packets, which makes generic UDP checking much less conclusive.
The CGNATCheck Port Checker performs a best-effort TCP reachability probe. If your application uses UDP, use its own documented external test method or logs instead of assuming a TCP result applies.
Why the same-LAN test can mislead you
Entering your public IP while connected to the same home Wi-Fi asks the router to send local traffic out toward its public side and back inside. Routers that support NAT loopback or hairpin NAT may handle this. Others do not, so the connection can fail even though a genuinely external client would succeed.
Prefer an external test from mobile data or another internet connection. Make sure the testing device is not silently switching back to the home Wi-Fi during the test.
Confirm the public IPv4 path before blaming the rule
Classic IPv4 port forwarding expects unsolicited traffic to reach the router that owns the rule. If that router has a private WAN, sits behind another router, or receives an address in 100.64.0.0/10, the traffic may stop at an upstream NAT layer first. Compare the router WAN and public IPv4 with the CGNAT checker and review CGNAT versus double NAT if the values do not line up.
Reachable
The tested TCP path answered
This is strong evidence that the TCP port reached a listening endpoint at that moment. It does not prove the application behind it is authenticated, healthy, or safe.
Refused or closed
A device actively rejected it
The service may not be listening, the wrong device may receive the forward, or a firewall may reject the connection. Recheck the local endpoint first.
Timeout or inconclusive
No clear answer returned
Filtering, CGNAT, double NAT, a wrong route, an inactive service, or packet loss can all produce silence. One timeout cannot identify which cause applies.
Common mistakes that invalidate the test
- The service was stopped or bound only to localhost.
- The router rule used TCP while the application required UDP, or the reverse.
- The target device received a new LAN address after the rule was created.
- The external and internal port numbers were confused.
- The test was run from inside the same LAN without loopback support.
- A second router or ISP gateway also needed configuration.
- The router WAN address was private or in shared CGNAT space.
- The application's connection model did not actually rely on a public inbound port.
Test safely
Do not expose a router admin panel, NAS administration page, remote desktop service, camera interface, or other sensitive control surface merely to obtain an open result. Prefer authenticated, patched services designed for remote access. Remove temporary rules after testing and continue with the complete guide to why port forwarding fails if the path remains closed. If the address path itself is the blocker, compare cautious solution options only after the free checks are complete.
