Direct / public path
Manual port forwarding, DDNS to a forwarded service, and many reverse-proxy setups expose a public TCP endpoint. These are probe-testable from outside the home network.
Troubleshooting guide
Remote Access Not Working
The right test depends on whether you expect a public inbound endpoint at all.
First identify the path you are actually using
“Remote access” can describe very different network designs. Some methods require a public inbound TCP endpoint; others are specifically designed to work without one. A port checker is useful only for the first group, so the fastest diagnosis starts by classifying the path.
Relay / overlay path
Tailscale, vendor remote-access systems and application relays may establish outbound or overlay connectivity without a publicly forwarded port. A failed public port test can be completely normal here.
1. Confirm the destination works locally
Before testing the internet path, connect to the service from another device on the same LAN. If local access fails, investigate the application, host firewall, binding, container or VM networking first. External routing cannot repair a service that is unavailable locally.
2. If you expect a public endpoint, probe it externally
For a direct path, use the Remote Access Diagnosis or the TCP Port Checker. A successful TCP connection proves that an endpoint on that public IP and port accepted the connection. It does not automatically prove authentication, application configuration or every higher-layer feature works.
If the probe fails, compare the router WAN IPv4 with the detected public IPv4. This separates local forwarding problems from upstream NAT problems such as CGNAT or double NAT.
3. If you use a relay or overlay, do not chase an open public port
For Tailscale-style access, verify that both devices are enrolled and online, the destination service listens on the overlay/LAN interface you intend to use, access-control policy permits the connection, and the destination firewall allows the traffic. For vendor-mediated NAS or media-server access, verify the product's remote-access status and whether it reports a direct or relayed path.
Security: do not expose an administration interface or Remote Desktop to the public internet merely to make a port checker report success. Prefer an authenticated VPN/overlay or a properly secured reverse proxy when that is the safer design for the service.
A quick decision tree
- Works locally? If no, fix the service/LAN first.
- Direct public endpoint expected? If yes, run an external TCP probe.
- Probe fails? Compare WAN and public IPv4, then inspect forwarding/firewall/binding.
- Relay/overlay expected? Skip public-port diagnosis and verify enrollment, relay status, policy and local service.
- After any fix: retest the same path from outside the LAN.
Jump to the path you use
For a public TCP endpoint, start with the Remote Access Test. For an arbitrary self-hosted service, use the Home Server Remote Access Test. If the path is Tailscale, use the overlay-specific troubleshooter instead of chasing an open public port.