Reach an Existing HTTP or SOCKS Proxy Through SSH
Reach a remote loopback HTTP or SOCKS proxy through SSH without exposing its listener publicly.
If relay.example.net already runs SOCKS on its own 127.0.0.1:1080, forward access rather than expose that listener publicly:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Endpoint | Role |
|---|---|
Laptop 127.0.0.1:1081 | The SOCKS address to configure in the laptop application. |
Relay 127.0.0.1:1080 | The existing proxy reached from the SSH server side. |
The local-forwarding syntax assigns the fixed destination to the server side. An HTTP proxy on remote loopback port 3128 or an intranet endpoint such as proxy.internal.example:8080 works on the same principle. Configure the client for that existing HTTP protocol and account; carrying it through SSH does not create SOCKS or a TLS-enabled HTTPS listener.
The existing service still chooses supported protocol versions, authentication, destinations and final exit. If another SSH process created that remote proxy, both processes must remain alive. A laptop→relay→gateway route leaves the website seeing the last outward connection, not an identity allocated by local port 1081.
Keep the laptop binding explicitly local. Wider exposure changes who can reach the service, and SSH login does not add a SOCKS password to the listener. For refusal, check the laptop listener, SSH transport and remote proxy as separate stages.