Reachable
The TCP path is externally reachable. If the app still fails, investigate the application layer, authentication, hostname or client configuration.
Test one TCP port from outside your network. A positive result is verified reachability; a negative result continues into diagnosis.
Verify whether one TCP port on this connection can accept a connection from the public internet.
The public IP shown here is detected from this browser request. External probes are restricted to that same public IP.
A successful connection is strong positive evidence that the public TCP path reaches a listening service. A failed connection is not a precise cause by itself. Continue with local-service, forwarding and WAN/public-IP checks before changing router settings.
The TCP path is externally reachable. If the app still fails, investigate the application layer, authentication, hostname or client configuration.
The path failed. Confirm the service works locally, then inspect port forwarding, firewall rules and upstream NAT.
A failed port alone does not prove CGNAT. Compare the router WAN IPv4 with the public IPv4 using the dedicated check.
Connection Vitals established a TCP connection from outside your network to the detected public IP and selected port.
No. A failed TCP connection can be caused by the service not listening, router forwarding, a firewall, upstream NAT, CGNAT or another path problem.
No. The public probe is intentionally restricted to the public IP detected from your own browser request.
A bare TCP result is more useful when paired with the application state that should be listening.
Check the incoming peer port while qBittorrent is actually running.
Check reachability without confusing an open socket with a successful RDP login.
Check the server TCP endpoint while the Java server is running.
Work through listener, NAT, forwarding, firewall and binding in order.