Privoxy: Bridge an HTTP Proxy Client to a SOCKS Tunnel

An SSH dynamic tunnel, including PuTTY's dynamic forward, provides a SOCKS interface. An application that accepts only an HTTP proxy cannot use that port merely by calling it HTTP.

A local protocol bridge can sit between them. The application sends HTTP proxy requests to the bridge, and the bridge opens destination connections through the SOCKS service.

Privoxy documents this arrangement through its forwarding rules. For an existing local SOCKS5 tunnel, a configuration fragment is:

forward-socks5 / 127.0.0.1:1080 .

The application connects to Privoxy's HTTP listener, not port 1080. Keep that listener local under the intended access policy. The final dot in the rule has a documented meaning; it is not a placeholder for a missing internet hostname.

This is protocol translation

The Privoxy forwarding documentation explains SOCKS forwarding syntax and hostname handling. A plain TCP port forward does not perform the same translation: it transports the client's HTTP bytes unchanged to a SOCKS listener, which still expects a SOCKS negotiation.

The bridge also becomes part of the configuration you need to understand. Privoxy can have content-filtering and access settings of its own. Adding it is not the same as making the original application natively support SOCKS.

For HTTPS websites, the application usually asks the HTTP bridge for CONNECT, and the bridge obtains the destination connection through SOCKS. Normal website TLS remains an application-to-website relationship; the bridge does not need to impersonate the website to provide this path.

If the application can use SOCKS directly, the extra component may be unnecessary. Use the bridge to solve an actual protocol mismatch, with the listener and upstream clearly distinguished.