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:

• Metasploit — route msfconsole traffic through a SOCKS proxy created by auxiliary/server/socks_proxy.
• CrackMapExec / NetExec — proxychains4 netexec smb 192.168.50.0/24 -u admin -p Password1.
• Chisel — for reverse SOCKS pivoting through restrictive firewalls, then feeding that SOCKS port into proxychains.
• Scripting a full pivot in one line:

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

Performance Optimization

• Lower tcp_connect_time_out and tcp_read_time_out for faster failure detection on dead hosts during large scans, but not so low that you get false negatives on slow internal links.
• Use dynamic_chain instead of strict_chain for scanning — a single dead proxy shouldn’t halt an entire chain.
• Avoid full-range scans (-p-) through proxychains for large subnets; the TCP connect overhead per port multiplies quickly. Scan common ports first, then target specific hosts for deeper scans.

Troubleshooting

• “Connection refused” for every host: verify the proxy itself is actually listening (ss -tlnp | grep 1080) before blaming proxychains.
• DNS resolves to your local network instead of the target’s: add proxy_dns to the config; without it, name resolution happens locally and can leak or fail.
• SYN scans silently fail: nmap requires raw sockets for -sS; proxychains only supports TCP connect-based traffic, so use -sT.
• Statically linked binaries don’t get proxied: LD_PRELOAD interposition only works on dynamically linked executables; static binaries bypass proxychains entirely.

Best Practices

• Keep a separate proxychains config per engagement/pivot chain to avoid cross-contaminating traffic between client environments.
• Always enable proxy_dns to avoid DNS leakage outside the intended chain.
• Prefer dynamic_chain for general use, strict_chain only when you need a guaranteed specific path for evidentiary/reporting purposes.
• Test the proxy chain with a simple curl or nmap -Pn -p 80 before running large or long scans through it.

Common Mistakes

• Forgetting the target requires -Pn in nmap, since ICMP ping probes don’t route through a SOCKS proxy.
• Assuming UDP scans work through proxychains — they generally do not, since SOCKS4/5 in this context is primarily used for TCP.
• Leaving a stale proxy entry in the config from a previous engagement, causing confusing partial failures.

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

• proxychains-ng GitHub: https://github.com/rofl0r/proxychains-ng
• Kali Linux tool page: https://www.kali.org/tools/proxychains-ng/
• Man page: man proxychains4 (or proxychains4 --help)