Setup ProxyChains on Kali Linux with Tor SOCKS

ProxyChains forces command-line programs to connect through the proxies you list in proxychains4.conf. On Kali, the usual pairing is ProxyChains plus the tor system service so curl, nmap, and similar tools exit through a Tor circuit instead of your real IP.

This guide walks through setup on Kali Rolling: install packages, point [ProxyList] at Tor SOCKS, verify with the Tor Project API, and see what happens when you aim the chain at a host-only lab target. Each step states what you run and what a good result looks like.

What is ProxyChains in ethical hacking?

ProxyChains (the proxychains4 package on Kali) is a TCP proxifier. You prefix a command with proxychains4, and the tool tries to redirect that program’s outbound connections through the proxy chain defined in proxychains4.conf.

In penetration testing labs, that pattern helps you:

• Test how a tool behaves when egress leaves through Tor or a corporate proxy
• Practice reading chain logs (Strict chain ... OK) during authorized assessments
• Separate browser Tor (Tor Browser) from CLI tooling that needs the same network path

ProxyChains is not a VPN and not a magic cloak. Forensics can still correlate timing, application behavior, and mistakes such as DNS leaks or forgotten shell proxy variables. Treat it as a routing wrapper, not a promise of “100% anonymity.”

ProxyChains vs Tor Browser vs the tor service

Three components show up together in Kali guides but do different jobs:

Installing Tor Browser does not configure ProxyChains. Installing tor with apt does not give you Tor Browser. For browser work, see Install Tor Browser on Kali Linux. This article focuses on proxychains4 plus the system tor daemon.

Compare ProxyChains chain modes

proxychains4.conf supports one active chain mode at a time. Uncomment exactly one of the chain lines near the top of the file:

Kali’s default file enables strict_chain and proxy_dns. With one Tor entry in [ProxyList], strict and dynamic behave the same until you add more proxies.

Kali lab setup

Set lab variables once so later commands stay copy-paste friendly. You need Kali on the same host-only network as Metasploitable 2.

Export the target for the examples below:

TARGET=192.168.56.114

Clear shell proxy variables before ProxyChains tests. On this lab, leftover HTTPS_PROXY values caused curl to chain to a corporate proxy after Tor:

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY no_proxy NO_PROXY

Install ProxyChains and Tor on Kali Linux

Both packages live in default Kali repositories. Install them together so [ProxyList] can point at a local Tor SOCKS port:

sudo apt update
sudo apt install -y proxychains4 tor

Confirm the versions apt recorded on this image:

dpkg -l proxychains4 tor | grep -E '^ii'

ii  proxychains4   4.17-3.1     amd64        redirect connections through socks/http proxies (proxychains-ng)
ii  tor            0.4.9.11-1   amd64        anonymizing overlay network for TCP

The main config file is /etc/proxychains4.conf. The wrapper command is proxychains4 (not the legacy proxychains name some older blogs use).

proxychains4 -h is not a help flag. ProxyChains treats -h as a program name and errors:

proxychains4 -h 2>&1 | head -3

[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
proxychains: can't load process '-h'. (hint: it's probably a typo): No such file or directory

Use man proxychains4 or read /etc/proxychains4.conf comments when you need syntax reminders.

Configure proxychains4.conf for Tor SOCKS

Open the system config with root privileges. You will adjust chain mode, DNS handling, and [ProxyList]:

sudo nano /etc/proxychains4.conf

On Kali Rolling 2026.2, these lines are already active near the top and middle of the file:

grep -n '^strict_chain\|^proxy_dns\|^tcp_read_time_out\|^\[ProxyList\]\|^socks' /etc/proxychains4.conf | head -10

18:strict_chain
60:proxy_dns
92:tcp_read_time_out 15000
158:[ProxyList]
161:socks4 	127.0.0.1 9050

Keep strict_chain and proxy_dns enabled. proxy_dns sends DNS lookups through the proxy chain instead of resolving names locally first, which reduces a common DNS leak path when the chain is working.

In [ProxyList], switch the Tor line from socks4 to socks5:

socks5 127.0.0.1 9050

Tor’s default SOCKS port on Kali listens on 127.0.0.1:9050. SOCKS5 matches what Tor documents for client applications and behaved reliably with curl in this lab.

For a personal test file without editing /etc, copy the config and pass -f:

LAB=/tmp/proxychains-lab
mkdir -p "$LAB"
sudo cp /etc/proxychains4.conf "$LAB/proxychains4.conf"

Edit "$LAB/proxychains4.conf" so [ProxyList] contains only socks5 127.0.0.1 9050. On proxychains-ng 4.17, use:

proxychains4 -f "$LAB/proxychains4.conf" curl -s --max-time 25 https://check.torproject.org/api/ip

The environment variable PROXYCHAINS_CONF is ignored; the log still shows /etc/proxychains4.conf if you rely on that name alone. PROXYCHAINS_CONF_FILE also works.

Start the tor service and verify port 9050

ProxyChains only works when the first hop in [ProxyList] is reachable. Start the Tor daemon and confirm it is active:

sudo systemctl start tor

systemctl is-active tor

active

Check that Tor is listening on the SOCKS port ProxyChains will use:

ss -tlnp | grep 9050

LISTEN 0      4096       127.0.0.1:9050       0.0.0.0:*    users:(("tor",pid=281138,fd=6))

When you finish lab work, stop the service so idle Tor circuits are not left running:

sudo systemctl stop tor

Verify Tor egress with check.torproject.org

After unsetting shell proxy variables and starting tor, ask the Tor Project API whether your connection exited through Tor:

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY
proxychains4 curl -s --max-time 25 https://check.torproject.org/api/ip

[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  check.torproject.org:443  ...  OK
{"IsTor":true,"IP":"45.95.169.104"}

IsTor:true means the request left through the Tor network. The exit IP changes each time Tor builds a new circuit, so your JSON line will show a different address on the next run.

Direct curl to the same URL without ProxyChains may fail on networks that intercept TLS. On this lab, plain curl returned no body and exited with code 60 (certificate verify failed) while ProxyChains through Tor succeeded.

Run Nmap and curl through ProxyChains

Prefix the tool you already use with proxychains4. The wrapper prints a chain line for each connection attempt.

Internal lab targets and Tor

Tor is for internet egress, not your VirtualBox host-only subnet. HTTP to Metasploitable through the Tor chain failed in this lab:

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY
proxychains4 curl -s --max-time 15 "http://${TARGET}/" -o /dev/null -w '%{http_code}\n'

[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
[proxychains] Strict chain  ...  127.0.0.1:9050  ...  192.168.56.114:80 <--denied
000

The denied line and HTTP code 000 mean the chain never delivered a normal response. Scan and browse TARGET directly on the lab LAN without Tor when the goal is local enumeration.

Nmap through ProxyChains on the lab host

proxychains4 nmap can still report open ports on a local target, but sub-millisecond latency usually means the traffic did not hairpin through a distant Tor exit:

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY
proxychains4 nmap -Pn -p 22 "$TARGET"

[proxychains] DLL init: proxychains-ng 4.17
Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-02 10:38 -0400
Nmap scan report for 192.168.56.114
Host is up (0.0010s latency).

PORT   STATE SERVICE
22/tcp open  ssh
MAC Address: 08:00:27:EB:8C:B9 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.70 seconds

For authorized port scans on Metasploitable, prefer direct Nmap on the lab network. Use ProxyChains when you deliberately need egress through Tor or another proxy chain.

Record the ProxyChains log lines in your notes when a test must show which hop carried traffic. For reports, pair chain logs with the Tor API JSON when you need proof of exit through Tor.

Optional HTTP proxies in the chain

You can list http, socks4, socks5, and authenticated entries in [ProxyList] for multi-hop chains. Example syntax (commented in the default file):

# http 192.168.1.10 8080
# socks5 127.0.0.1 9050

Public “free proxy” lists are a poor default for security work:

• You do not control who logs traffic on the far end
• Dead entries break strict_chain until you remove them
• Malicious proxies can strip TLS or inject content

If you chain Tor after an HTTP proxy for a authorized test, enable dynamic_chain and verify DNS with proxy_dns still enabled. Prefer infrastructure you own or contractual access to over scraped lists.

ProxyChains troubleshooting

References

• proxychains-ng on GitHub
• Tor Project — Tor manual
• Tor Project — check if connected to Tor
• Debian proxychains4 package

Summary

You installed proxychains4 and tor on Kali, confirmed strict_chain and proxy_dns in proxychains4.conf, and pointed [ProxyList] at Tor SOCKS on 127.0.0.1:9050. Starting the tor service and running proxychains4 curl against check.torproject.org produced IsTor:true with a changing exit IP, which is the signal you want when testing egress through Tor.

The main pitfalls from this lab are easy to miss in prose: shell HTTP_PROXY variables can hijack curl after Tor, PROXYCHAINS_CONF does not select an alternate file on 4.17, and Tor will not behave like a LAN path to Metasploitable on 192.168.56.x. Use direct Nmap and curl on host-only targets; use ProxyChains when the exercise is outbound routing or multi-hop proxy behavior.

For browser-only anonymity work, stay with Tor Browser. For CLI tooling, keep the tor daemon running when you need SOCKS, unset proxy environment variables in the same shell, and read the Strict chain log lines before you trust a result. Next steps in the course include deeper Nmap enumeration and the broader ethical hacking lab path.