In this article
A local SSH tunnel provides a route to a service inside the Pod. It requires a suitable SSH transport and does not replace application authentication.
To reach a private local service inside a Runpod Pod, use local forwarding over a suitable full TCP SSH connection. The application can listen on loopback inside the Pod while your browser connects to a loopback port on your own computer. Verify ordinary SSH login before adding the tunnel.
Keep the three ports distinct
The route contains an external SSH port from Connect, an internal application port and an available local laptop port. They have separate roles and need not match. Do not use the application port as the SSH-server connection port by mistake.
Basic proxied access has limitations, so verify forwarding support for the selected transport. The presence of an ssh command alone does not establish the capabilities of every provider-specific connection path.
Use an explicit loopback forwarding rule
If the application listens on 127.0.0.1:8888 inside the Pod and local port 8899 is free, the source example is:
ssh -N -L 127.0.0.1:8899:127.0.0.1:8888 root@HOST -p SSH_PORT -i PRIVATE_KEYReplace HOST and SSH_PORT with current parameters and PRIVATE_KEY with your local private-key path. The user depends on the image. Open the local browser address on port 8899 and keep the tunnel running during the session.
Retain the local 127.0.0.1 binding when only this computer needs access. The private key does not need to be copied into the Pod or pasted into the application’s web interface.
Confirm the application is actually listening
Check the service locally inside the Pod before blaming the tunnel. If it failed during initialization, forwarding will not start it. Inspect the process log and confirm its address and port.
This is different from publishing through an HTTP proxy, where the application normally needs a reachable container interface. A loopback setting chosen deliberately for a tunnel cannot simply be reused as an assumed public-proxy configuration.
Diagnose and close the route
When SSH works but the page does not, check the local port conflict, destination address and running service. An application may redirect to another host or require a token. Keep its authentication enabled: the tunnel controls transport, not application accounts.
Local forwarding connects the laptop to a remote service; it does not publish a laptop service back into the cloud. After work, close SSH and verify the local listener has gone. Following a Pod replacement or restart, re-check Connect parameters and retain a secret-free port diagram for the next operator.
Turn the check into a practical next step
A local SSH tunnel provides a route to a service inside the Pod. It requires a suitable SSH transport and does not replace application authentication.
For the documented details, consult the primary documentation; configuration reference. Continue with runpod ssh public key setup and cloud gpu jupyter ssh tunnel.