Why the VNC Address Stays localhost

In a VNC-over-SSH setup, localhost is easy to misunderstand. It can look like a local testing value or a placeholder you should replace with the Mac IP. In a secured tunnel model, it is usually the exact value you want.

The viewer connects to a local port on the client side. SSH carries that traffic to the Mac. At the tunnel exit, the Mac connects to localhost:5900, which means its own loopback interface. The screen service is reached from the Mac side, not from the network side.

If you are on the same LAN, the SSH host might be the Mac LAN IP. If you are outside the network, the SSH host might be a public WAN IP, DDNS hostname, or mesh VPN address. That is the reachable endpoint for the tunnel.

The VNC target does not need to change with it. Once the tunnel lands on the Mac, the Mac still reaches its own screen service through localhost. That is why the same VNC address can work from a local network and from the internet.

If a firewall rule allows the screen port only from loopback, then the Mac LAN IP is intentionally not allowed. Entering the LAN IP as the VNC target can make the Mac try to reach its own service through a non-loopback path. The firewall sees that as network traffic, not loopback traffic, and drops it.

That failure is not a bug in the security model. It is the model doing its job. The screen port remains unreachable unless the connection arrives through the SSH path and terminates into the loopback destination.

Use the reachable address for SSH. Use localhost for VNC when lockdown is enabled. Forward SSH if you need internet access. Do not forward VNC.

HearthGate keeps this distinction visible in its help guides because it is the difference between "I can connect" and "my screen port is exposed."