proxychains4: A tool for forcing network connections to go through proxy servers

I use proxychains4 in nearly every engagement where I need to route tool traffic through a pivot point without rewriting each tool’s proxy settings by hand. It’s one of those utilities that quietly sits underneath a huge amount of red team tradecraft. Here’s my complete rundown.

What Is proxychains4?

proxychains4 (often just called proxychains-ng) is a tool that forces any TCP connection made by a given application through a chain of one or more proxies — SOCKS4, SOCKS5, or HTTP CONNECT proxies. It works via LD_PRELOAD, intercepting the dynamic library calls a program makes (connect(), getaddrinfo(), etc.) and redirecting them through the configured proxy chain instead of a direct connection.

Crucially, it does this without modifying the target application’s source code. Any dynamically linked binary — nmap, curl, ssh, msfconsole — can be proxied transparently.

The “4” distinguishes proxychains-ng (the actively maintained fork, providing proxychains4 binary) from the older, largely abandoned original proxychains project.

Architecture and Internal Working

proxychains4 operates through:

  1. Dynamic library interposition — using LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libproxychains4.so, it hooks libc’s networking functions before the target program’s own calls execute.
  2. Configuration file (/etc/proxychains4.conf or ~/.proxychains/proxychains.conf) — defines the proxy list and chaining behavior.
  3. Chaining modes:
    • dynamic_chain — uses proxies in order, skips dead ones, requires at least one live proxy
    • strict_chain — uses proxies in exact order, fails if any is down
    • random_chain — picks a random proxy from the list per connection
    • round_robin_chain — rotates through proxies in sequence

Installation

sudo apt update
sudo apt install proxychains4

Verify:

proxychains4 --version

Configuration

Edit /etc/proxychains4.conf:

sudo nano /etc/proxychains4.conf

Key sections:

dynamic_chain
#strict_chain
#random_chain

proxy_dns

tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
socks5  127.0.0.1 1080

proxy_dns is important — it forces DNS resolution through the proxy too, preventing DNS leaks that would otherwise reveal your real resolver.

Syntax

proxychains4 [-f config_file] <command> [args...]

Complete Command Examples and Output

Basic usage — proxy an nmap scan through a SOCKS5 proxy (e.g., from an SSH dynamic forward):

First, establish the SOCKS proxy via SSH:

ssh -D 1080 -N labuser@10.10.10.5

Then run nmap through it:

proxychains4 nmap -sT -Pn -p 80,443 192.168.50.10

Output:

[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.16
[proxychains] Dynamic chain  ...  127.0.0.1:1080  ...  192.168.50.10:80  ...  OK
[proxychains] Dynamic chain  ...  127.0.0.1:1080  ...  192.168.50.10:443  ...  OK

Nmap scan report for 192.168.50.10
PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Note: proxychains forces -sT (full TCP connect scan) since SYN scans (-sS) require raw sockets that can’t be proxied.

Chaining multiple proxies:

[ProxyList]
socks5 127.0.0.1 1080
socks5 172.16.1.5 1080
http   192.168.1.20 8080
proxychains4 curl http://internal-app.local/

Using a custom config file for a specific engagement:

proxychains4 -f ~/engagements/client-a/proxychains.conf ssh admin@10.20.30.5

Real-World Use Case (Authorized Pentest)

On internal engagements, I frequently land an initial foothold on one segment and need to reach a second, isolated segment only visible from that foothold. My workflow:

  1. Get a shell on a pivot host (e.g., via a phishing-delivered payload or an exploited service, in an authorized scope).
  2. Set up a SOCKS proxy from that pivot — either with ssh -D, a Meterpreter socks_proxy module, or Chisel.
  3. Configure /etc/proxychains4.conf with that SOCKS endpoint.
  4. Run proxychains4 nmap, proxychains4 crackmapexec, or proxychains4 impacket-secretsdump against hosts in the second segment — all without ever installing tools on the pivot itself.
  5. Document the full pivot chain and internal reachability in the final report as evidence of insufficient network segmentation.

This lets me use my full local toolset against a network I can only reach through a single compromised jump host, which is exactly how a real attacker would operate post-foothold.

Automation and Integration

proxychains4 pairs naturally with:

ssh -f -N -D 1080 pivot-user@10.10.10.5 && proxychains4 nmap -sT -p- 192.168.60.0/24

Performance Optimization

Troubleshooting

Best Practices

Common Mistakes

FAQ

Does proxychains4 work with UDP traffic? Not reliably for most tools — SOCKS5 technically supports UDP associate, but proxychains-ng’s practical use case is almost entirely TCP-based tools.

Can I chain a SOCKS proxy with an HTTP proxy? Yes, mixed chains are supported in the [ProxyList] section.

Why does my scan take much longer through proxychains? Each connection now involves the extra network hop(s) and proxy negotiation overhead; this is expected, especially with strict_chain and multiple hops.

Is proxychains4 the same as proxychains (original)? No — proxychains-ng (installed as proxychains4) is the actively maintained fork with more chaining modes and better reliability than the original abandoned project.

Summary

proxychains4 is the connective tissue that lets your entire existing toolkit operate through a pivot without rewriting a single tool’s proxy settings. In authorized internal pentests, it’s essential for demonstrating real lateral reachability from a single foothold, and it integrates cleanly with SSH tunnels, Chisel, and Metasploit’s SOCKS modules.

References

Exit mobile version