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:
- Hiding from your ISP that you visited a website: VPN handles this. Tor handles this. Proxychains might handle this.
- Hiding from a website that your real IP visited it: Any working proxy handles this.
- Hiding from a state-level adversary with access to multiple network nodes: This is hard. Most consumer tools don’t help as much as their marketing suggests.
- Hiding from a website that you are the person browsing it: Almost impossible. Your browser leaks enough to identify you regardless of IP.
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:
- SOCKS5 handles any TCP/UDP traffic, not just HTTP
- SOCKS5 supports authentication
- SOCKS5 doesn’t modify your traffic (no headers added)
- HTTP proxies only handle HTTP and often add forwarding headers
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:
- Guard/Entry node: Knows your real IP, doesn’t know the destination
- Middle relay: Knows neither your IP nor the destination
- 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
- Your ISP sees VPN traffic, not Tor
- Tor entry node sees VPN server’s IP, not yours
- VPN provider sees you’re using Tor (but not what you’re doing there)
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
- The destination sees the VPN’s IP (useful if the site blocks Tor exit nodes)
- The VPN provider sees traffic from a Tor exit node, not your real IP
- Tor exit node traffic is encrypted to the VPN (prevents exit node snooping)
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:
- User agent string — browser version, OS
- Screen resolution and color depth
- Installed fonts — a shockingly unique identifier
- Canvas fingerprint — how your GPU renders a specific canvas element
- WebGL renderer — identifies your GPU model
- Timezone and language settings
- Plugin and extension list
- Battery status (yes, really)
- TCP/IP fingerprint — OS-level network stack characteristics
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:
- Logging into accounts: You route through Tor then log into Gmail. Google now knows the Tor exit node was you.
- Consistent behavior: Same hours, same patterns, same writing style.
- Cross-contamination: Using the same device for anonymous and non-anonymous activities. The Tor Browser opened while your regular browser is logged into everything.
- Metadata: File attachments can contain author names, GPS coordinates, timestamps.
# 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:
- ISP seeing which sites you visit
- Websites seeing your real IP
- Casual surveillance
What it doesn’t protect you from:
- Browser fingerprinting
- Behavioral correlation
- Logging by any node in the chain
- Timing attacks if someone watches both ends
- Your own mistakes (logging into accounts, metadata)
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.