Skip to content
SumGuy's Ramblings
Go back

Proxy Chains and Anonymization: What Actually Works and What's Just Theater

Define Your Threat Model or Nothing Else Matters

Before you install proxychains or route your traffic through Tor, you need to answer one question: what are you protecting against?

This isn’t philosophical. The answer completely determines what tools you need:

If your threat model is the last one — truly anonymous browsing — I’m going to disappoint you early. IP anonymization is the easy part. Browser fingerprinting, behavioral analysis, and traffic correlation are the hard part, and most of what people call “anonymization tools” don’t touch them.

That said, let’s work through what’s actually available.

SOCKS5 Proxies: The Foundation

A SOCKS5 proxy is a relay: your client connects to the proxy server, tells it the destination, and the proxy makes the connection on your behalf. The destination sees the proxy’s IP, not yours.

SOCKS5 vs HTTP proxies:

For command-line tools:

# Using curl through a SOCKS5 proxy
curl --socks5-hostname proxy.example.com:1080 https://ipinfo.io

# With authentication
curl --socks5-hostname user:pass@proxy.example.com:1080 https://ipinfo.io

# Via environment variables (many tools respect these)
export ALL_PROXY=socks5h://user:pass@proxy.example.com:1080
curl https://ipinfo.io

The socks5h scheme means hostname resolution happens at the proxy, not locally — important for DNS leak prevention.

proxychains-ng: Chaining Proxies Together

proxychains-ng wraps any application and forces its traffic through a configured chain of SOCKS5/HTTP proxies.

apt install proxychains-ng
# /etc/proxychains4.conf

# Chain type: strict_chain means all proxies must work
# dynamic_chain skips dead proxies
# random_chain picks random proxies from the list
strict_chain

# Proxy DNS through the chain (prevents DNS leaks)
proxy_dns

# Quiet mode
quiet_mode

[ProxyList]
# format: type  host  port  [user  pass]
socks5  127.0.0.1  9050    # Tor
socks5  proxy1.example.com  1080  user  pass
socks5  proxy2.example.com  1080
# Run any command through the chain
proxychains4 curl https://ipinfo.io
proxychains4 nmap -sT -p 80 target.example.com
proxychains4 python3 script.py

With strict_chain, traffic goes through every proxy in order. If any proxy is down, the connection fails. With dynamic_chain, it skips dead proxies — useful for a long list, but you lose control over which nodes handle your traffic.

random_chain picks a random subset of proxies each connection. The number of proxies used per connection is controlled by chain_len = 2.

Tor as a SOCKS5 Proxy

Tor exposes a SOCKS5 interface on 127.0.0.1:9050 by default. You can route any SOCKS5-capable application through it.

apt install tor

# Tor starts automatically and listens on 9050
systemctl status tor

# Test it
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

torsocks: Transparent Tor Proxying

torsocks wraps applications the same way proxychains does, but specifically for Tor:

apt install torsocks

# Route a command through Tor
torsocks curl https://ipinfo.io
torsocks wget https://example.com/file.tar.gz
torsocks ssh user@hidden-service.onion

# Start a Tor-wrapped shell session
torsocks -i bash
# Now everything in this shell goes through Tor

torsocks intercepts network calls at the library level (via LD_PRELOAD). It also blocks UDP, since Tor doesn’t support UDP — preventing that leak vector.

Onion Routing Basics (Why Tor Works)

Tor routes your traffic through three volunteer-run relays:

  1. Guard/Entry node: Knows your real IP, doesn’t know the destination
  2. Middle relay: Knows neither your IP nor the destination
  3. Exit node: Knows the destination, doesn’t know your IP

Each relay only knows the previous and next hop. The exit node sees your traffic but doesn’t know who sent it. Your ISP sees you connecting to Tor but doesn’t know what you’re doing.

The weakness: if an adversary controls both your entry node and the exit node, traffic correlation attacks can de-anonymize you. This is hard to do randomly, trivial for a state-level actor watching a specific target.

Combining VPN + Tor

Two configurations, different purposes:

VPN then Tor (VPN → Tor)

Your traffic goes: You → VPN → Tor → Destination

Use this when: you want to hide Tor usage from your ISP (some ISPs throttle or flag Tor traffic), or you’re in a country where Tor itself is blocked.

# Connect VPN first, then use Tor normally
sudo wg-quick up wg0
torsocks curl https://check.torproject.org/api/ip

Tor then VPN (Tor → VPN)

Your traffic goes: You → Tor → VPN → Destination

This requires a VPN that accepts connections from within the Tor network — some providers explicitly support this.

When the Combination Hurts

VPN + Tor isn’t automatically better. If your VPN provider keeps logs, you’ve added a logged node to your chain. If your VPN is based in a jurisdiction that serves warrants, you’ve given law enforcement an anchor.

Adding hops adds complexity, and complexity adds attack surface. More proxies means more operators who might be compromised, more logs that might exist, more failure points.

I2P: The Alternative to Tor

I2P (Invisible Internet Project) is a network-within-a-network, primarily designed for anonymity within the network rather than anonymous access to the clearnet.

# Java required
apt install default-jre
# Download i2p from geti2p.net

# Or use i2pd (C++ implementation)
apt install i2pd
systemctl start i2pd

I2P’s strengths: peer-to-peer design, no central directory, better for hidden services within the network. Its weakness: clearnet exit is limited, less bandwidth, more complex to configure. For anonymous internet access, Tor is more practical. For private services you host yourself, I2P has interesting properties.

Browser Fingerprinting: The Part Everyone Ignores

Here’s the uncomfortable truth: routing your traffic through six proxies doesn’t matter if your browser tells every website exactly who you are.

A modern browser exposes:

The Electronic Frontier Foundation’s Cover Your Tracks test shows what your browser leaks. The number of bits of identifying information in a typical browser fingerprint can be 20-30 bits — meaning your browser is unique among millions of users, regardless of IP.

What actually helps:

# The Tor Browser: specifically designed to normalize fingerprints
# Uses Firefox with fingerprinting protections, standard window sizes, NoScript

# Brave Browser: good fingerprint protection, though not Tor-level

# For automated tools: use headless Chromium with specific flags
chromium --headless --disable-gpu \
  --no-sandbox \
  --disable-extensions \
  --incognito \
  --proxy-server=socks5://127.0.0.1:9050 \
  --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE localhost" \
  "https://ipinfo.io"

For real anonymity, you want the Tor Browser — not Firefox with uBlock Origin and the Tor SOCKS5 proxy configured. The Tor Browser normalizes screen size, disables fingerprinting vectors, and makes you look like every other Tor Browser user. Custom Firefox settings make you look unique.

Opsec Basics: The Human Layer

Technical anonymization fails constantly because of human behavior:

# Strip metadata from files before sharing
apt install mat2
mat2 document.pdf
mat2 photo.jpg
mat2 --inplace suspicious-file.docx

The Honest Assessment

What proxychains + Tor actually protects you from:

What it doesn’t protect you from:

The tools are real and functional. The threat models where they’re sufficient are narrower than most tutorials suggest.

Use Tor Browser for anonymous browsing, not Tor + regular Firefox. Use proxychains for specific command-line tools where you understand exactly what’s being proxied. Always start with threat model, then pick the tools.

The gap between “hides your IP” and “is anonymous” is enormous — and most people selling the former are implying the latter.


Share this post on:

Previous Post
Flowise vs Langflow: Build AI Pipelines Without Writing a Novel
Next Post
n8n vs Node-RED: Automate Everything Without Learning to Code (Much)