proxychains-ng: LD_PRELOAD hooks, TCP only, and a changelog that reads like a bug list

It intercepts libc socket calls, so anything not dynamically linked is out of reach

The mechanism is one sentence long: ProxyChains is a UNIX program that hooks network-related libc functions in dynamically linked programs via a preloaded DLL, using dlsym() and LD_PRELOAD, and redirects the connections through SOCKS4a, SOCKS5 or HTTP proxies. Everything about its reliability follows from that design. The README calls the approach a hack outright, says it may not work with your program, and singles out scripts, programs that start numerous background daemons, and programs that use dlopen() to load modules, which it attributes to a bug in the glibc dynamic linker. What it says it should work with is simple compiled C or C++ dynamically linked programs. The boundary conditions matter more than the happy path. A statically linked binary never reaches the interposed symbols. A program that starts numerous processes, such as background daemons, may not work. A runtime that loads its networking stack through dlopen() may bypass it entirely. And when it does fail, the README's own advice is to stop fighting the preload and use an iptables-based solution instead, which it describes as much more dependable. That is a design limitation, not a configuration mistake, and it will not be fixed by editing proxychains.conf.

Building means configure, make, and two optional sudo targets

Installation is a plain autotools-shaped sequence with a hand-written configure script, and it needs a working C compiler, preferably gcc:

  # needs a working C compiler, preferably gcc
  ./configure --prefix=/usr --sysconfdir=/etc
  make
  [optional] sudo make install
  [optional] sudo make install-config (installs proxychains.conf)

Note that install and install-config are separate, and the config file is not installed by the ordinary install target. If you install the binary but skip install-config, there is no installed proxychains.conf to read proxy lists from. The README also tells you that you do not have to install at all, and can run the freshly built binary out of the source directory:

./proxychains4 -f src/proxychains.conf telnet google.com 80

That line is also the shortest possible smoke test in the project, since telnet has no proxy support of its own and the whole point is to proxify a program that lacks it. The source tree ships proxychains.conf inside src/, which is why the -f path points there, and the shipped configuration file is installed to the sysconfdir you passed to configure, so choosing --sysconfdir=/etc as shown puts it in a predictable place.

TCP only, so UDP and ICMP traffic never goes through the tunnel

The supported scope is stated in one line and it is easy to skim past: TCP only, no UDP and no ICMP. That single limitation decides whether proxychains-ng is the right tool for a given workload. Anything that resolves names over UDP and expects the answer through the tunnel, any voice or video call, any game traffic, any DNS query that escapes the hook, will either fail or go out directly. The project handles DNS in its own layer rather than leaving it to the operating system, and the changelog shows that layer being rebuilt several times. Version 4.0 replaced the dnsresolver script, which had required a dynamically linked dig binary to be present, with remote DNS lookup done through the proxy, which sped up lookups and made .onion addresses usable with TOR. Version 4.10 fixed a segfault in the DNS mapping code in programs with more than roughly 400 different lookups, a limit you can cross in a long-running crawler without noticing. Version 4.15 added proxy_dns_old to emulate the behavior of proxychains 3.1 and introduced a new proxy_dns_daemon feature flagged as experimental. So DNS behaviour is selectable and still settling, and nothing in this design makes UDP work.

Each release fixes a named class of program, so the version is the feature set

The changelog tells you which program classes were fixed in which release. Version 4.17, the newest release, adds a hook for the close_range function, fixing newer versions of OpenSSH, plus a fat-binary-m1 option for mac, a fix for OpenBSD preloading, a fix for a double close in multithreaded applications, and DNS error handling fixes in proxy_dns_old. Version 4.16 added the new DYLD hooking method for OSX Monterey and IPv6 localnet support. Earlier entries follow the same shape: 4.5 hooked close() to stop OpenSSH from corrupting its own internals, which had segfaulted the ssh client when proxified; 4.7 made the close hook return EBADF instead of EINTR, because a retrying program such as chromium could loop forever; 4.8 allowed programs that rely on LD_PRELOAD themselves to work; 4.14 added an alternative proto://user:pass@ip:port syntax for proxy lists and fixed an endless loop in round robin mode when every proxy was down. The practical consequence: this is not a version you can install once and forget. Each entry marks a program class that previously escaped the hook, and the release list is slow, with 4.15 in July 2021, 4.16 in January 2022 and 4.17 in January 2024.

The build defaults to no optimization, and the Makefile invites local overrides

The Makefile is a short, GNU make required, file noted in its own header as taken from musl, and two lines in it change what you get out of the compiler. The flag set begins with:

CFLAGS  += -Wall -O0 -g -std=c99 -D_GNU_SOURCE -pipe

The -O0 means the compiled output is unoptimized unless you change it, which suits debugging the preload library but costs throughput in a proxy that sits in front of every connection. The file anticipates this. It includes config.mak if that file exists, and appends $(USER_CFLAGS) and $(MAC_CFLAGS) to CFLAGS, so the intended override path is a local config.mak rather than editing the tracked Makefile. The rest of the layout tells you what the project produces. Two binaries are built, proxychains4 and proxychains4-daemon, and the preloaded shared object is named through a variable:

LDSO_PATHNAME = libproxychains4.$(LDSO_SUFFIX)
PXCHAINS = proxychains4
PXCHAINS_D = proxychains4-daemon

The object lists are equally informative: the main program compiles src/common.o and src/main.o, the daemon adds a set of objects under src/daemon including hsearch.o, sblist.o, daemon.o and udpserver.o, and the library itself pulls in core.o, libproxychains.o, allocator_thread.o, rdns.o, hostsreader.o, hash.o and debug.o. Installation is driven by ./tools/install.sh, and a zsh completion file, completions/zsh/_proxychains4, is installed into the zsh site-functions directory.

Proxy types, chain types, and the auth each one expects

Version 3.0 laid the groundwork that later releases extended: DNS resolving through the proxy, support for SOCKS4, SOCKS5 and HTTP CONNECT proxy servers, with authentication types of user/pass for SOCKS and basic for HTTP. The chain model lets you compose them, and the documented feature list opens with the ability to mix different proxy types in the same chain, for example your host to socks5 to http, with the multi-hop case drawn as your_host to proxy1 to proxy2 to target_host. Chain behavior has grown too: 4.7 introduced a round_robin chaintype, and 4.14 fixed an endless loop in that mode when all proxies were down, which is a failure mode worth remembering since a dead proxy list and a hung proxy list look the same from the outside. 4.15 added a raw proxy type and a dnat feature. The list file gained flexibility too, with the alternative proto://user:pass@ip:port syntax from 4.14 and, in that same release, hostnames allowed as proxy list entries under specific circumstances. Two edge behaviors are documented rather than hidden: 4.14 skips connection attempts to null-routed IPs, and 4.8 began rejecting wrong entries in the config file instead of accepting them.

The warning block tells you to verify your exit IP before trusting anything

The README carries an attention block that is unusual in its bluntness, and it belongs in any evaluation. It says the program can be used to circumvent censorship, that doing so can be very dangerous in certain countries, and that you should always make sure ProxyChains works as expected before using it for anything serious. The suggested test is concrete: connect to a what-is-my-ip service such as ifconfig.me and confirm the connection is not using your real IP. The README is careful that this involves both the program and the proxy you are going to use, which is the part people skip. A correct hook through a proxy that logs or misroutes is still an exposure, and a failed hook through a working proxy is a silent leak. The disclaimer is equally explicit that the authors and maintainers take no responsibility for abuse or misuse. For a reader weighing this tool, that block reframes the whole project: the failure mode is not a crash or a slow connection, it is traffic leaving from the address you believed you had left. That is why the seven documented use cases, from getting outside a LAN only through a proxy server to reaching hidden tor onion services, are all cases where a silent leak matters.

The SourceForge page is stale, so releases come from GitHub

The repository metadata points its homepage at the SourceForge file listing for proxychains-ng, and the project description says plainly that the sf.net page is not currently updated and that releases should be taken from the GitHub release page instead. That is a small line with real consequences for anyone trying to establish what they are running. The release list on GitHub holds three recent entries: v4.17 dated 2024-01-21, v4.16 dated 2022-01-23 and v4.15 dated 2021-07-24, which lines up with the 4.17 README being the one at the repository root. The default branch is master, and the last push is dated 2026-10-06, with the project not archived, so work continues on the branch even though the newest tagged release is older. The gap between those two dates is the thing to plan around. A distribution package may be carrying any of those three releases, each of which fixes a different set of programs, and the README version banner is the fastest way to tell what you have, since printing the version number on startup was added back in 4.8. The tree itself is small and legible: src/ for the code, tests/, tools/ for the install script, completions/ for the zsh completion, plus AUTHORS, COPYING under GPL-2.0, TODO, VERSION, Makefile and configure.

Editorial conclusion

Use it when you must route one specific TCP client program through a proxy that has no proxy support of its own, and check the program against the changelog before you trust it. Do not use it for UDP traffic, for statically linked binaries, or as your only path to a network, since the README itself points at an iptables-based approach when the preload fails. Whatever you do, verify the exit address before you rely on it, exactly as the README asks.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. rofl0r/proxychains-ng on GitHub