An SSH Forwarded Port Is Not Always a SOCKS Proxy
Distinguish an SSH fixed local forward from a dynamic SOCKS listener before configuring an application.
You create an SSH tunnel, put 127.0.0.1 and its port into a browser's proxy settings, and nothing loads. The listener may be working perfectly. It may simply be waiting for the wrong kind of traffic.
| Forward | What the local application sends | Destination choice |
|---|---|---|
-L | The target service's ordinary protocol | Fixed in the SSH command |
-D | A SOCKS negotiation, then application traffic | Requested by the SOCKS client |
For a single web server, this is a fixed forward:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Visit http://127.0.0.1:9080/ as a website. Do not label port 9080 as SOCKS: it forwards bytes to the one web server named in the command. Opening a site under a different hostname can also affect its virtual hosting, redirects, or cookies.
For a SOCKS listener, the shape changes:
ssh -N -D 127.0.0.1:1080 [email protected]Configure the application to use SOCKS at 127.0.0.1:1080. Entering that address directly into the browser's address bar sends a web request to a SOCKS listener, another protocol mismatch.
The OpenSSH manual documents both forms. There is a useful exception: forwarding an existing HTTP proxy with -L produces a local port that speaks HTTP proxy protocol, because its fixed destination is itself an HTTP proxy. The service at the far end determines what belongs on a fixed forward. Forwarding an existing proxy through SSH keeps that proxy's protocol and account.