How to Set Up ProxyChains on Kali Linux with Tor

ProxyChains wraps compatible programs and redirects their TCP connections through the proxies listed in proxychains4.conf. On Kali, the usual pairing is ProxyChains plus the tor system service so tools such as curl can exit through a Tor circuit instead of your real IP.

This guide walks through installing and configuring ProxyChains, starting Tor, verifying the connection, and using ProxyChains on Kali Rolling. Each step states what you run and what a good result looks like.

How ProxyChains works on Kali Linux

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 TCP connections through the proxy chain defined in proxychains4.conf.

ProxyChains works with TCP connections made through normal application networking calls. It does not proxy UDP, ICMP, or raw-packet scans.

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.

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). Use proxychains4 --help or man proxychains4 for command-line options.

Configure proxychains4.conf for Tor

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

sudo nano /etc/proxychains4.conf

Choose strict_chain, dynamic_chain, or random_chain

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.

Configure Tor SOCKS on 127.0.0.1:9050

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], the default Kali file uses socks4 127.0.0.1 9050. For this guide, change it to SOCKS5:

socks5 127.0.0.1 9050

Tor supports both SOCKS4 and SOCKS5 on 127.0.0.1:9050. SOCKS5 is used here because it handles hostname-based requests cleanly and matches Tor's current client examples.

Use a custom proxychains4.conf file

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

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

Edit "$LAB/proxychains4.conf" so [ProxyList] contains only socks5 127.0.0.1 9050. You can use this file later with proxychains4 -f "$LAB/proxychains4.conf" <command> after Tor is running.

Start Tor and verify SOCKS 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:

sudo ss -tlnp | grep 9050

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

Verify ProxyChains is using Tor

After starting tor, verify that ProxyChains exits through Tor using the Tor Project API at check.torproject.org. Unset shell proxy variables first so they do not change the route you intend to test:

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY all_proxy no_proxy NO_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 can change as Tor builds new circuits, so your JSON line may show a different address on the next run.

How to use ProxyChains on Kali Linux

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

Lab environment used in the examples

The curl test below uses a VirtualBox pentest lab target on the host-only network 192.168.56.0/24. You do not need that lab to verify Tor egress with check.torproject.org above.

Export the target and clear shell proxy variables before the lab test:

TARGET=192.168.56.127
unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY all_proxy no_proxy NO_PROXY

On this lab, leftover HTTPS_PROXY values caused curl to chain to a corporate proxy after Tor when those variables were not cleared.

Test curl through ProxyChains

HTTP to Metasploitable through the Tor chain failed in this lab:

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.127:80 <--denied
000

The denied line and HTTP code 000 mean the chain never delivered a normal response.

Why Tor cannot reach private lab addresses

Tor exits cannot reach private lab addresses such as 192.168.56.x (RFC1918 private addresses). Use the direct host-only path for Metasploitable and other lab targets on that subnet.

Why some Nmap scans bypass ProxyChains

ProxyChains hooks normal dynamically linked TCP connect() calls. It supports TCP only. When Nmap runs with privileges, many default scan modes use raw packets rather than proxied TCP connections. SYN scans (-sS), UDP scans (-sU), ICMP discovery, ARP discovery, and other raw-packet operations do not travel through ProxyChains.

That is why a command such as proxychains4 nmap -Pn -p 22 "$TARGET" against a local Metasploitable host can still show sub-millisecond latency and the target's VirtualBox MAC address even though Tor cannot reach private lab addresses. The scan bypassed ProxyChains; it did not hairpin through a Tor exit.

For authorized port scans on Metasploitable, use direct Nmap on the lab network without Tor.

If an authorized assessment requires Nmap through ProxyChains, use TCP connect scanning (-sT). Raw-packet scan types such as SYN or UDP scans are not proxied.

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.

Add HTTP or SOCKS proxies to ProxyChains

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 an 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

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, which is the signal you want when testing egress through Tor.

The main pitfalls from this lab are easy to miss in prose: shell proxy environment variables can hijack curl after Tor, many Nmap scan modes bypass ProxyChains because they use raw packets, 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. When you finish testing, optionally stop Tor with sudo systemctl stop tor so idle circuits are not left running. Next steps in the course include deeper Nmap enumeration and the broader ethical hacking lab path.

References

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