SSH Local Forward to an Existing HTTP Proxy: Two Loopbacks

Your approved proxy runs on a jump host where it listens only on loopback, so nothing outside that machine can reach it. You do not need a VPN or a new proxy; you need one port of that machine carried to one port of yours. A local forward does exactly that, and it takes one command plus one application setting. The confusion usually comes from mixing up which loopback address belongs to which machine.

Decide whether a fixed proxy already exists

This technique forwards a service that is already running. If the remote host merely has an SSH daemon and no proxy, no amount of forwarding creates one, and the connection will be refused from the remote side. Confirm the proxy is bound, its port, and whether it listens on 127.0.0.1 or on a specific interface address, because that address is what the forward must target.

Confirming this first saves you from debugging a tunnel that was never connected to anything.

Build the forward and read the command

The form you want binds a loopback port on your laptop and connects it, from the server's side, to the proxy's address as the server sees it.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

The -N suppresses a remote command and -T suppresses termios allocation, because you want a tunnel rather than a shell. The first loopback address is where the laptop listens; the second is resolved from the SSH server, so 127.0.0.1 there means the proxy on that machine. ExitOnForwardFailure makes the command fail loudly if the local port is already taken, instead of starting a session that forwards nothing. Write the target address as the server resolves it, because a name that only your laptop can resolve will fail on the far side.

The server's own policy applies before any of this works. AllowTcpForwarding must permit it, and PermitOpen may restrict which destinations and ports a session may reach, so a forward that the client accepts can still be refused by the server. The refusal shows up as a forwarding or channel error on the client, and reading that message is faster than editing the command.

Point one application at the forward

Configure the application to use an HTTP proxy at http://127.0.0.1:13128, with credentials if the remote proxy requires them. Keep the application's own certificate verification for HTTPS destinations, since the proxy tunnel does not replace it. This is a fixed forward of one service, so the application must be told about a proxy rather than left to discover one.

A quick check before configuring anything permanent: curl -x http://127.0.0.1:13128 -I https://example.com, which exercises the HTTP CONNECT method the proxy must support.

Keep the authority where it was

The remote proxy still decides which destinations and methods it permits, and an SSH login should not quietly grant every account a general web relay. Binding to 127.0.0.1 on the laptop avoids publishing the port to your local network, and it does not make the port private from other processes on the same machine. Replacing that bind with a wildcard address to share the proxy is how an unmanaged open relay gets created.

The SSH transport protects the hop to the server. Past that point the proxy opens its own connection, so a plain HTTP request to a destination stays plain beyond the server even though the first segment was encrypted.

Verify both ends, then clean up

Local tunnel setup and remote service success are different results, and the command's exit status only tells you about the first. Check that the listener exists with ss -ltn, then make a permitted application request and a request the proxy should refuse. If both behave as expected, the path is real; if the tunnel is up and every request fails, the proxy is refusing or cannot reach the destination.

When you finish, stop the owning SSH process, remove the proxy setting from the application, and confirm the local port is gone rather than leaving a listener that outlives the task.