ProxyChains (and ProxyChains-NG): a tool for anonymizing traffic and network testing

In a world where data privacy and access to resources are often restricted by geo-blocks or corporate policies, tools like ProxyChains become indispensable helpers. ProxyChains — or more precisely its modern fork ProxyChains-NG — is an open utility for Unix-like systems (Linux, macOS, etc.) that allows redirecting the network traffic of any application through a chain of proxy servers. It is especially popular among developers, pentesters, and security enthusiasts. In this article we’ll go over what ProxyChains can do, why it’s useful for developers, provide usage examples, and discuss its limitations.

Briefly: what ProxyChains-NG is and how it works

ProxyChains is a program that “wraps” an application’s TCP connections and forces them to go through a sequence of proxy servers (SOCKS4, SOCKS5, HTTP/HTTPS).

Mechanism on Linux: ProxyChains-NG uses LD_PRELOAD. It injects its library into the application, intercepts system calls for networking (for example, connect()), and redirects them through the proxies specified in the configuration file.

Supported chaining modes:

• strict_chain — traffic goes strictly through the list; if one proxy fails — the chain doesn’t work. This mode is enabled in the project’s default config.
• dynamic_chain — if a proxy is unavailable, it is skipped; convenient when there are several proxies in the list and resilience is needed.
• random_chain — selects a random proxy from the list for each connection.

Important: the original proxychains (version 3.x) is obsolete. Today it’s recommended to use proxychains-ng (in packages the binary is often called proxychains4).

Installation and basic setup

On Debian/Ubuntu/Kali:

sudo apt update
sudo apt install proxychains4
# the command to run — proxychains4

On Debian and Ubuntu the package is named proxychains4 (this is proxychains-ng; in Debian 13 — version 4.17); the proxychains package is the old 3.1 branch.

The configuration file is usually located at /etc/proxychains4.conf. Example ProxyList section:

[ProxyList]
# Tor
socks5 127.0.0.1 9050
# HTTP proxy
http 192.168.1.100 8080

DNS proxying is controlled by the proxy_dns directive. In the default proxychains-ng config it is enabled; check that the line in your package’s config is not commented out:

proxy_dns

With proxy_dns the application receives a placeholder IP from a service subnet (the remote_dns_subnet parameter, default 224), and when connecting proxychains sends the proxy the hostname itself — the proxy determines the address. Therefore DNS requests do not go to the provider’s DNS server.

Why ProxyChains is convenient for a developer

ProxyChains is not only about anonymity. For a developer it’s useful in several practical scenarios:

• Testing service behavior from different geolocations. Quickly check how an API/site behaves when requests come from IPs in the US, EU, Asia, etc., without setting up a VPN or changing application configs.
• Debugging and pentesting. You can verify that an application doesn’t leak its real IP and test behavior under different network conditions.
• Convenience for CLI utilities. Instead of configuring proxies in every tool, add the proxychains4 prefix.
• Integration with Tor. Simple way to route traffic through Tor (with additional anti-leak measures).

Limitations to keep in mind:

• Does not work with statically linked binaries (for example, many Go binaries).
• Does not intercept raw sockets and UDP (by default) — meaning some types of traffic (ICMP/ping, UDP DNS requests, VoIP) are not proxied.
• Can potentially increase latency and reduce connection speed.

Practical usage examples

Run any tool with the proxychains4 prefix:

1. Check external IP:

proxychains4 curl ifconfig.me

This returns the IP of the last hop in the chain.

2. Scanning with nmap (TCP Connect scan only):

proxychains4 nmap -sT -p 80,443 example.com

Important: nmap -sS (SYN scan) uses raw sockets and will not work. ProxyChains supports -sT (TCP Connect) because it uses the normal connect().

3. SSH through a chain:

proxychains4 ssh user@remote-server.com

4. Downloading via Tor:

• Run tor locally.

• In /etc/proxychains4.conf add:

  Copy

  socks5 127.0.0.1 9050
  proxy_dns

• Run:

proxychains4 wget https://example.com/file.zip

DNS and HTTP traffic will go through Tor (provided proxy_dns is enabled).

Drawbacks and critical limitations

1. DNS leaks — the primary risk

In the default proxychains-ng config proxy_dns is enabled, and hostnames are resolved by the proxy. A leak happens in two cases: if proxy_dns is commented out (this can occur in modified configs) or if the application resolves addresses itself, bypassing the system resolver — for example, it sends DNS queries over UDP directly. Such traffic is not intercepted by proxychains, and requests go to the DNS server bypassing the proxy, revealing which sites you are opening. Test the behavior of a specific utility, for example with tcpdump -i any port 53.

2. Works only with TCP

ProxyChains is intended for TCP. UDP, ICMP and raw sockets are not proxied. To proxy UDP you need other tools (for example, tun/tap solutions or VPNs, or specific UDP tunnels).

3. Compatibility

Does not work with statically compiled binaries (they do not pick up LD_PRELOAD) and with programs that create raw sockets. Many modern Go utilities are often compiled statically — keep this in mind when planning tests.

4. Performance degradation

Each additional proxy adds latency. For latency-sensitive tasks (streaming, gaming, real-time) ProxyChains is not suitable.

5. Security of the proxy chain

Proxies in the chain can log or modify traffic. Use trusted nodes and remember that the last node (exit node) sees unencrypted traffic if you are not using TLS/HTTPS over the proxy.

Useful tips and best practices

• Ensure proxy_dns remains enabled if you want real anonymity.
• Test the configuration: first proxychains4 curl ifconfig.me, then proxychains4 dig +short example.com @8.8.8.8 and compare results.
• For applications that don’t work with LD_PRELOAD, use the application’s built-in proxy settings or bring up a local tun/tap (VPN).
• Do not mix untrusted proxies with sensitive data — sending login/passwords over HTTP through an untrusted proxy is a bad idea.
• For large-scale testing of geo-dependent behavior it’s better to have a pool of trusted proxies from different regions (or use commercial services).

Short comparison: ProxyChains vs VPN vs SOCKS-proxy (table)

Conclusion

ProxyChains-NG is a powerful and lightweight tool for developers and pentesters: it simplifies testing from different geolocations, helps check for IP leaks, and gives flexibility when working with CLI tools. But it is not universal: be aware of DNS leaks, lack of support for UDP/raw sockets, incompatibility with statically compiled binaries, and risks associated with untrusted proxies.

If you plan to use ProxyChains in serious work, enable proxy_dns, test your tools’ behavior, and use trusted proxies or Tor combined with TLS encryption. For full proxying of all traffic (including UDP) consider VPN solutions or bringing up a local tunnel.