Redsocks is a small Linux daemon that turns a SOCKS5 or HTTP proxy into a transparent one. Firewall rules redirect outgoing TCP connections to a local Redsocks port; Redsocks reads each connection's original destination from the kernel and opens it through your proxy. Programs need no proxy setting and no wrapper, which makes it the tool for a CI runner, a build box or a container where you cannot touch every client.

Everything below ran on Debian 12 with redsocks 0.5, iptables 1.8.9 and nftables 1.0.6, against a local SOCKS5 proxy and an HTTP CONNECT proxy, both requiring a username and password. You need root and the ability to change NAT rules.

Install

sudo apt install redsocks

The package installs /etc/redsocks.conf. Check a config's syntax with redsocks -t -c FILE before you start it.

redsocks.conf

A minimal file for an authenticated SOCKS5 proxy, running in the foreground while you test:

base {
  log_info = on;
  log = stderr;
  daemon = off;
  redirector = iptables;
}

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

ip and port are the host and port from your order. Redsocks accepts a hostname there and uses one of its addresses, but your firewall rules must exclude that exact address, so an IP from getent hosts HOST keeps the two in step.

type takes socks5, socks4, http-connect or http-relay. For an HTTP proxy use http-connect: it tunnels any TCP port and sends the login. http-relay handles plain HTTP to port 80 only. redirector = iptables is the Linux setting; it also works with nftables rules, because Redsocks only asks the kernel for the original destination.

Start it with redsocks -c /etc/redsocks.conf. Once the rules work, set daemon = on and log to syslog.

Redirect rules with iptables

Rules in the nat table's OUTPUT chain catch connections made by this machine. Exclude the proxy itself first, or Redsocks' own connection to the proxy gets redirected back into Redsocks:

sudo iptables -t nat -N REDSOCKS
sudo iptables -t nat -A REDSOCKS -d IP -j RETURN
sudo iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -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 -j REDSOCKS

The private and link-local ranges keep your LAN, Docker networks and cloud metadata addresses direct; drop any line you want proxied. Flushing the whole OUTPUT chain to undo this also removes rules other software put there (Docker's embedded DNS lives in it), so undo only your own rules:

sudo iptables -t nat -D OUTPUT -p tcp -j REDSOCKS
sudo iptables -t nat -F REDSOCKS
sudo iptables -t nat -X REDSOCKS
``` `sudo iptables -t nat -L REDSOCKS -n -v` shows packet counters per rule, which tells you at a glance whether connections are reaching the REDIRECT line.

## The same with nftables

```plaintext
table ip redsocks {
  chain output {
    type nat hook output priority -100; policy accept;
    ip daddr { IP, 127.0.0.0/8, 10.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16 } return
    meta l4proto tcp redirect to :12345
  }
}

Load it with sudo nft -f redsocks.nft and remove it with sudo nft delete table ip redsocks.

Check the exit

curl -s "https://api.ipify.org?format=json"

No -x flag: the redirect does the work, and the IP should be your proxy's. Unlike ProxyChains, this holds for static binaries too; in our test busybox wget from busybox-static left through the proxy, where under ProxyChains it went direct.

The DNS caveat

Redsocks carries TCP only, and it learns each destination as an IP address after your machine has already resolved the name. Two things follow:

  1. The proxy never sees hostnames. Our proxy's log showed CONNECT 172.18.0.2:8080, not the name curl was given. Lookups, and any geo-aware DNS answer, come from your own resolver's point of view.
  2. DNS over UDP leaves directly. A plain dig @1.1.1.1 example.com was answered without touching Redsocks.

To push lookups through the proxy, force them onto TCP, which your rules already redirect:

  • options use-vc in /etc/resolv.conf, with a nameserver outside your excluded ranges. glibc then sends every query over TCP. This worked in our test.
  • The dnstc section, a stub that answers every UDP query with "truncated" so the client retries over TCP, plus a rule redirecting UDP port 53 to it. dig retried and went through the proxy. glibc's resolver gave up instead of retrying, so treat dnstc as tool-dependent.

The redudp section relays UDP, but only through a SOCKS5 server that implements UDP relay.

With ProxyHive

For a build server or a scraper host, a datacenter IP gives the whole machine one fixed exit. Its specs list HTTP, HTTPS and SOCKS5 with username and password authentication, which maps onto type = socks5 or type = http-connect; they say nothing about UDP relay, so plan on TCP and the DNS options above.