How to force any app through a proxy, even one with no proxy setting

When an app has no proxy setting, you put something underneath it that grabs its connections and hands them to the proxy. On Windows and macOS that is Proxifier, or NetDetour, which has replaced ProxyCap. On Linux it is ProxyChains for a single command and Redsocks for anything ProxyChains cannot reach. If what you have is an SSH server rather than a proxy, sshuttle or plain ssh -D does the job, and Chisel covers networks where only web traffic gets out. None of them carry UDP, and every one of them can leak DNS unless you tell it not to.

The Linux tools below were run in throwaway containers against a proxy we started ourselves: proxychains-ng 4.17, Redsocks 0.5 on Debian 13, sshuttle 1.3.2, OpenSSH 10.6 and Chisel 1.12.0. Proxifier and NetDetour are desktop apps, so for those we quote their own documentation.

First, check whether it already reads a proxy variable

Plenty of “no proxy setting” apps have one, just not on screen. Most command-line tools read HTTPS_PROXY and HTTP_PROXY, and so does anything written in Go that uses the standard HTTP client. Try it before installing anything:

export HTTPS_PROXY=http://USER:PASS@IP:PORT
export HTTP_PROXY=$HTTPS_PROXY
the-app --whatever-it-does

If the app’s traffic now arrives from the proxy, stop here. The Windows and macOS proxy guides cover the system-wide settings, which some desktop apps follow too. The rest of this page is for apps that ignore all of that.

Which tool to use

Windows and macOS: Proxifier

Proxifier is the long-standing answer here, for Windows and macOS (and Android). Its own feature list puts it plainly: it can process all outgoing TCP connections. The setup, from its Windows documentation:

1. Profile → Proxy Servers → Add. Enter the Address and Port from your dashboard, and choose the Protocol. For SOCKS5 details pick SOCKS Version 5; for an HTTP proxy pick HTTPS, which is Proxifier’s name for an HTTP proxy that tunnels with CONNECT. Fill in the username and password, and click Check to run the built-in Proxy Checker.
2. Proxifier then asks whether to use this proxy by default. Say No if you only want one app proxied: the Default rule keeps sending everything else direct.
3. Profile → Proxification Rules → Add. Put the program’s file name in Applications (several names separated by ;, wildcards allowed), leave Target hosts and Target ports as Any, and set Action to the proxy you added. Leave the built-in Localhost rule alone; some apps need their loopback connections.
4. Profile → Name Resolution. By default Proxifier only resolves through the proxy when your system DNS is down. Untick the automatic mode and turn on Resolve hostnames through proxy if you do not want your own resolver to see every hostname the app looks up.

To watch it work, set Log → Output Level → Debug and start the app: each connection shows which rule it matched. For a one-off run without writing a rule, right-click the program’s .exe and use the Proxifier command in the context menu, which always sends that launch through the proxy you choose.

Two Proxifier warnings worth repeating. If the app already had a proxy configured, turn it off, or traffic goes through the proxy twice. And its docs note that many plain HTTP proxies refuse tunnels to arbitrary ports; when an app talks to something other than a web port, the SOCKS5 details are the safer choice. Use the host and port your dashboard lists for SOCKS5; do not guess one.

ProxyCap is now NetDetour

If an older guide sent you to ProxyCap: its site now redirects to NetDetour, which its maker describes as the replacement, with a 30-day trial like ProxyCap had. Both handle SOCKS, HTTPS-tunnelling and plain HTTP proxies, SSH, and resolving names at the proxy. The differences its own comparison lists: ProxyCap could pass UDP through a SOCKS proxy and spoke Shadowsocks; NetDetour can only block UDP, does not do Shadowsocks, and stores its configuration as XML. NetDetour runs on Windows, with a macOS command-line edition announced. The workflow is the same as Proxifier’s: add the proxy, then a rule that sends one program to it.

Linux, one command: ProxyChains

proxychains4 runs a program with a library preloaded that hooks its network calls, so the program connects through your proxy without knowing. On Debian and Ubuntu the package is proxychains4. Keep your own config file rather than editing the system one:

# ~/monkey-chains.conf
strict_chain
proxy_dns
remote_dns_subnet 224
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
socks5  IP  PORT  USER  PASS

For an HTTP proxy, the last line is http IP PORT USER PASS instead; ProxyChains tunnels everything through it with CONNECT. Then:

sudo apt install proxychains4
proxychains4 -q -f ~/monkey-chains.conf curl -s https://httpbin.org/ip
proxychains4 -q -f ~/monkey-chains.conf the-app

Leave out -q and ProxyChains prints one line per connection, which is the quickest way to see what the app is doing:

[proxychains] Strict chain  ...  IP:PORT  ...  example.com:443  ...  OK

Three things that caught us out in testing:

• The proxy line wants a numeric IP. Put a hostname first in [ProxyList] and ProxyChains refuses with proxy … has invalid value or is not numeric. A static ISP or datacenter address from your dashboard is already an IP.
• Statically linked programs ignore it. The hook only works on programs that load the system C library at start-up. A static build of BusyBox wget went straight past it in our test and timed out; most Go binaries are built the same way. For those, use Redsocks, or the proxy variables above if the program reads them.
• Programs with their own DNS resolver leak. With proxy_dns on, ProxyChains answers lookups itself with a placeholder address from 224.x.x.x and passes the real name to the proxy. Debian’s curl went along with that. Alpine’s curl, which resolves names with its own library, did not: it asked the local resolver directly, so the lookup never touched the proxy.

Linux, anything else: Redsocks and iptables

Redsocks works one layer down. iptables redirects a program’s TCP connections to Redsocks, and Redsocks forwards them to the proxy, so it does not matter how the program was built. The neat way to aim it at one app is to run that app as its own user and redirect only that user. On Debian or Ubuntu, sudo apt install redsocks iptables, then set the redsocks block of /etc/redsocks.conf:

redsocks {
	local_ip = 127.0.0.1;
	local_port = 12345;
	ip = IP;
	port = PORT;
	type = socks5;
	login = "USER";
	password = "PASS";
}

For an HTTP proxy, use type = http-connect; with the same login lines; Debian’s build worked with both types in our test. Then create the user and the rules, and run the app as that user:

sudo useradd -m scraper
sudo systemctl restart redsocks

sudo iptables -t nat -N REDSOCKS
sudo iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 12345
sudo iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner scraper -j REDSOCKS

sudo -u scraper curl -s https://httpbin.org/ip
sudo -u scraper ./the-app

Only the scraper user’s connections are redirected, so Redsocks’ own connection to the proxy is not caught in a loop, and nothing else on the machine changes. Swap 192.168.0.0/16 for your own LAN range. The rules vanish on reboot unless you save them with your distribution’s iptables tooling.

What Redsocks does not do is DNS. The app still looks names up with your normal resolver, which therefore sees every hostname, and the connection then goes to the proxy by IP. For many jobs that is fine; when it is not, use ProxyChains, sshuttle or a SOCKS client that sends the name to the proxy instead.

You have an SSH server, not a proxy: sshuttle and ssh -D

A VPS you can SSH into is already a way out. Two ways to use it, both tested against a plain OpenSSH server:

# Everything on this machine, DNS included, through the server:
sudo sshuttle -r you@SERVER 0/0 --dns

# Or a local SOCKS5 proxy on port 1080, for tools that take one:
ssh -N -D 127.0.0.1:1080 you@SERVER
curl -s -x socks5h://127.0.0.1:1080 https://httpbin.org/ip

sshuttle needs root on your side and Python on the server, and it prints Connected to server. when the tunnel is up. The ssh -D route needs nothing extra, and pairs well with ProxyChains: put socks5 127.0.0.1 1080 in the [ProxyList] and any dynamically linked program follows. Either way, the traffic leaves with the server’s own address, a single hosting IP. Whether that is enough is a question the DIY proxy server guide answers.

Only web traffic gets out: Chisel

Chisel carries TCP inside an HTTP and WebSocket connection, encrypted with SSH, to a Chisel server you run. It is for your own networks and servers: reaching a service on your VPS from a network where only web ports are open, for instance. Check that you are allowed to do that where you are. On the server:

chisel server --port 8080 --socks5 --auth monkey:CHANGE-ME

The server prints a fingerprint at start-up. Pin it on the client, and ask for a local SOCKS5 port:

chisel client --fingerprint FINGERPRINT --auth monkey:CHANGE-ME http://SERVER:8080 socks
curl -s -x socks5h://127.0.0.1:1080 https://httpbin.org/ip

The socks remote listens on 127.0.0.1:1080. If the only way out is through an HTTP proxy, the client can reach the server through it with --proxy http://USER:PASS@IP:PORT; we checked that path with an authenticated proxy in between. A wrong password shows up on the client as Authentication failed.

What none of them can proxy

• UDP. In our test, a dig query over UDP under ProxyChains went straight out, with no chain line printed, while the same query with +tcp went through the proxy. That covers DNS over UDP, HTTP/3 (browsers fall back to TCP when it fails), most games and voice chat, and WebRTC media. Of the desktop tools, ProxyCap could hand UDP to a SOCKS proxy; its successor only blocks it.
• Programs that bypass the layer the tool hooks. Static binaries escape ProxyChains. Programs running as another user escape a Redsocks owner rule. Services started by the system rather than by you may escape a desktop tool’s per-app rules; Proxifier has a separate page on services and other users for that.
• Apps that check where they are connected. A program that pins a server’s IP or certificate and refuses anything else will break rather than go through a proxy, whatever you put under it.

DNS leaks, tool by tool

A DNS leak is when the connection goes through the proxy but the hostname lookup does not. The site sees the proxy; your ISP’s resolver still sees every name.

The socks5h part matters more than it looks; the socks5h entry explains the one letter. For ProxyChains there is a neat check: ask curl which address it connected to.

proxychains4 -q -f ~/monkey-chains.conf curl -s -o /dev/null -w '%{remote_ip}\n' https://example.com/

224.0.0.1 means the name went to the proxy. A real address means it was resolved on your machine.

The one-line “does it work” check

Run curl -s https://httpbin.org/ip the same way you run the app: under the same proxychains4 command, as the same Redsocks user, or with a Proxifier rule that covers curl.exe too. The origin it prints should be the proxy’s address, not yours. Then start the app and watch the tool’s own log (Proxifier’s Debug output, ProxyChains without -q, Redsocks’ log) to see its connections actually pass through. If the check works and the app does not, the app is in one of the categories above.

Which proxy to point them at

For an app that logs into something, or anything you will run for days, a static address is simplest: a datacenter or ISP IP from us comes as a numeric IP and port, which is exactly what ProxyChains and Redsocks want, and our lines speak HTTP and SOCKS5. Rotating residential suits scraping jobs that want a new exit per connection, and all of these tools pass that through untouched. Got an app that fights every method on this page? Describe it in Discord; someone has probably lost an evening to it already.