Proxy for Transparent Proxy / iptables
In most cases, when we talk about proxies, we mean “regular” or “non-transparent” proxies. They require explicit configuration in each application. But there is another, much more powerful approach — a transparent proxy.
This technology intercepts and redirects network traffic without the end user or their applications noticing. Programs on the user's computer are unaware that their traffic is passing through a proxy.
Analogy:
A regular proxy is like sending a package via a courier service that you have chosen and called yourself.
A transparent proxy is like if the entire post office wrapped all your packages by default and sent them on a special route without informing you.
The mechanism that makes this possible in the Linux world is called iptables. In this guide, we will figure out how it works, why it is needed, and how to set up such a system in practice.
⛔️ Important warning before you begin
This guide is intended for advanced users. You will be working with iptables and will have full root access to the system. An incorrect command can completely block your access to the network (including SSH).
Test in a VM: Always test such settings in a virtual machine first.
Have a plan B: Make sure you have console access to the server (not SSH) in case you block your own network.
Trusted provider: You are trusting all your traffic to the proxy server. Make sure you use a reliable and trusted provider. Do not proxy sensitive traffic (banking) without end-to-end encryption.
Compatibility: For new distributions (Ubuntu 22+, Fedora), check
iptables --version— if nft, switch:sudo update-alternatives --set iptables /usr/sbin/iptables-legacy. In containers (Docker), redsocks requires cap_net_admin; use --privileged.
Part 1. Why do you need a transparent proxy?
Transparent proxying is total control over traffic at the network level.
Corporate networks and Wi-Fi: For content filtering, data caching, and centralized security analysis.
Device management (IoT): You can proxy traffic from devices where you cannot configure a proxy manually (Smart TVs, game consoles, IoT gadgets).
Bypassing censorship for the entire network: Instead of configuring a VPN on each device, you can configure a router once to route all traffic through a proxy.
Part 2. How it works: iptables
iptables is a tool for managing network packets in the Linux kernel (Netfilter). We will use the nat (Network Address Translation) table.
The key point is to choose the right chain for interception:
PREROUTING chain: Intercepts traffic that passes THROUGH your server (transit traffic). This is your choice if you are configuring a gateway or router for other devices on the network.
OUTPUT chain: Intercepts traffic generated by the SERVER ITSELF (e.g., curl, apt-get, or scripts running locally).
Part 3. Practical implementation with redsocks
Simple REDIRECT cannot work with remote SOCKS5 proxies that require authentication. We will need redsocks.
redsocks is a daemon that accepts redirected iptables traffic and then establishes a connection to your remote proxy itself.
Note: The original redsocks is quite old (last updates ~2018). We recommend using the redsocks2 (REDSOCKS2) fork, which has fixes, new features (auto-redirect without blacklist, shadowsocks support, IPv6), and is up to date in 2025. If your distribution has the redsocks2 package, use it.
Otherwise:git clone https://github.com/semigodking/redsocks && cd redsocks && make && sudo make install
(or a similar fork REDSOCKS2).
Step 1: Collect proxy credentials
The first and most important step is to make sure you have the complete set of authorization data. These “keys” will allow your application or browser to connect to the proxy server and route traffic through it.
Be sure to have the following data ready:
IP address (host server)
Port for connection
Login and password for authorization
Protocol type (HTTP/HTTPS or SOCKS5)
Step 2. Installing redsocks
sudo apt update
sudo apt install redsocks # For the original; for redsocks2 — see above
Step 3. Configuring redsocks (TCP + DNS)
Open the configuration file sudo nano /etc/redsocks.conf. Change it to the following, substituting your proxy data. We will configure redsocks for TCP traffic, redudp for UDP/DNS, and dnstc for TCP-DNS (to capture rare TCP requests).
base {
log_debug = off;
log_info = on;
log = “file:/var/log/redsocks.log”; // Path to logs for debugging
daemon = on;
user = redsocks;
group = redsocks;
redirector = iptables;
}
// Section for TCP traffic (HTTP, HTTPS, etc.)
redsocks {
local_ip = 0.0.0.0;
local_port = 12345; // Port that redsocks will listen on for TCP
ip = 51.77.190.247; // IP address of your remote SOCKS5 proxy
port = 9595; // Port of your remote SOCKS5 proxy
type = socks5; // Use SOCKS5 (you can use http-connect for HTTP proxies or http-relay for pure HTTP)
login = “pcobLdlPkt-res-any”; // Proxy login
password = “PC_7CJ2WQqdHNm42dHWj”; // Proxy password
}
// Section for DNS traffic (UDP)
redudp {
local_ip = 0.0.0.0;
local_port = 10053; // Port that redsocks will listen on for DNS
ip = 51.77.190.247; // Same IP as SOCKS5 proxy
port = 9595; // Same SOCKS5 proxy port
type = socks5;
login = “pcobLdlPkt-res-any”; // Same login
password = “PC_7CJ2WQqdHNm42dHWj”; // Same password
}
// Section for TCP-DNS (to capture rare TCP requests)
dnstc {
local_ip = 127.0.0.1;
local_port = 5300;
}
Step 4. Configuring iptables (The most important step)
These rules are the core of our system. They will prevent leaks and infinite loops.
Important: iptables does not have a built-in “edit mode” like a text editor. Rules are stored in kernel memory and controlled via commands. Use iptables commands to view, delete, insert, or replace rules. For complex edits, dump the rules to a file, edit it, and reload it. This is especially convenient with iptables-persistent, where rules are stored in /etc/iptables/rules.v4.
Step 1. Viewing Current Rules
First, view the existing rules to understand what to edit.
# View all rules in the nat table with line numbers
sudo iptables -t nat -L -n -v --line-numbers
-t nat: nat table (for our REDIRECTs).-L: List of rules.-n: Numeric IPs (no DNS).-v: Verbose (packet counters).--line-numbers: Rule numbers (for deletion/insertion).
Example output:
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REDSOCKS all -- * * 0.0.0.0/0 0.0.0.0/0
Step 2. Simple editing: Delete, insert, and replace
For minor changes:
Delete a rule by number: Specify the chain and number.
# Delete rule #1 in PREROUTING
sudo iptables -t nat -D PREROUTING 1
Insert a new rule at a position: Use -I (insert).
bash# Insert at position 1 in PREROUTING (e.g., with additional ports) sudo iptables -t nat -I PREROUTING 1 -p tcp -m multiport --dports 80,443,8080 -j REDSOCKSReplace a rule: Use -R (replace).
# Replace rule #1 in PREROUTING
sudo iptables -t nat -R PREROUTING 1 -p tcp -m multiport --dports 80,443 -j REDSOCKS
Step 3. Editing via file (for complex changes)
Export the rules to a text file, edit, and reload.
Export rules:
sudo iptables-save > /tmp/iptables.rules # Temporary file
# Or for persistent: sudo nano /etc/iptables/rules.v4
Edit the file: Open in nano or vi. The file looks like this (example):
bash*nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :REDSOCKS - [0:0] -A REDSOCKS -d 1.2.3.4 -j RETURN -A REDSOCKS -d 10.0.0.0/8 -j RETURN # ... other exceptions -A REDSOCKS -p tcp -m multiport --dports 80,443 -j REDIRECT --to-port 12345 -A PREROUTING -j REDSOCKS -A PREROUTING -p udp --dport 53 -j REDIRECT --to-port 10053 -A PREROUTING -p tcp --dport 53 -j REDIRECT --to-port 5300 -A POSTROUTING -o eth0 -j MASQUERADE COMMITAdd/remove lines with -A, -I, etc. Save the file.
Load rules:
sudo iptables-restore < /tmp/iptables.rules
# For persistent: sudo netfilter-persistent reload
Step 4. Clear the rules (if you need to reset them)
Clear the chain:
sudo iptables -t nat -F REDSOCKS(flush).Remove the chain:
sudo iptables -t nat -X REDSOCKS.Complete nat cleanup:
sudo iptables -t nat -F(be careful!).
Tips: After making changes, check the rules (iptables -t nat -L) and test the traffic (curl, dig). For IPv6, use ip6tables. If the system is on nftables, edit /etc/nftables.conf and apply sudo nft -f /etc/nftables.conf.
Let's start configuring iptables:
# IMPORTANT: Specify the IP of your remote proxy
PROXY_IP="51.77.190.247"
# --- GENERAL CONFIGURATION ---
# Clear the REDSOCKS chain (if it exists, for testing)
sudo iptables -t nat -F REDSOCKS || true
sudo iptables -t nat -X REDSOCKS || true
# Create a new REDSOCKS chain for TCP
iptables -t nat -N REDSOCKS
# Exclude the proxy server itself to avoid an infinite loop
iptables -t nat -A REDSOCKS -d $PROXY_IP -j RETURN
# Ignore local and reserved networks
iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN
# --- CORRECTION: Only redirect WEB traffic ---
# We do NOT want to break SSH, FTP, etc. Only redirect HTTP and HTTPS.
# For email (25,465) or other ports, add to --dports
iptables -t nat -A REDSOCKS -p tcp -m multiport --dports 80,443 -j REDIRECT --to-port 12345
# (Optional) If you are sure you want to proxy ALL TCP traffic:
# iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-port 12345
# --- SELECT YOUR SCENARIO ---
# === SCENARIO A: Proxy for gateway (traffic from OTHER devices) ===
# Clients must use the server as their default gateway (via DHCP or statically)
# 1. Enable IP forwarding (permanently)
echo ‘net.ipv4.ip_forward=1’ | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
# 2. Apply rules to transit traffic
iptables -t nat -A PREROUTING -j REDSOCKS
# 3. Intercept DNS traffic (UDP 53) and send it to redsocks
iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-port 10053
# 4. Intercept TCP-DNS
iptables -t nat -A PREROUTING -p tcp --dport 53 -j REDIRECT --to-port 5300
# 5. Enable MASQUERADE (CRITICAL for the gateway)
# Replace eth0 with your EXTERNAL network interface
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# === SCENARIO B: Proxy for the server itself (LOCAL traffic) ===
# 1. Apply rules to local traffic
iptables -t nat -A OUTPUT -j REDSOCKS
# 2. Intercept local DNS traffic
iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-port 10053
# 3. Intercept TCP-DNS
iptables -t nat -A OUTPUT -p tcp --dport 53 -j REDIRECT --to-port 5300
Important: Do not apply both scenarios at the same time without a thorough understanding. Choose the one that suits your task.
Step 5. Start redsocks
sudo systemctl start redsocks
# Make sure the service is running
sudo systemctl status redsocks
Part 4. Problems and Advanced Solutions
DNS Leaks (UDP vs TCP)
This guide solves the problem by intercepting DNS requests over UDP (port 53) and TCP with dnstc. However, if the proxy does not support UDP-associate (for redudp), DNS will not pass — check the logs. For complete protection, check dnsleaktest.com.
Problem with HTTPS and SSL
redsocks does not have this problem. It works at the transport level (TCP) and does not attempt to decrypt your HTTPS traffic. It simply takes your already encrypted HTTPS packet and “wraps” it entirely in SOCKS5. The proxy owner cannot read your data.
Note on modern alternatives
redsocks is a powerful but rather old tool. In 2025, for new systems, especially those using nftables, more modern alternatives such as ss-redir (from shadowsocks-libev) or V2Ray/Xray are often recommended, which perform similar tasks with better performance and plugins. For UDP without redsocks, consider TPROXY in iptables/nftables. If in containers or on Android/routers (GL.iNet), redsocks works but requires custom firmware.
Part 5. Testing and Debugging
If something isn't working, here's your checklist:
Check your IP:
curl ifconfig.me(should show your SOCKS5 proxy's IP, not your server's).Check DNS:
dig google.comornslookup google.com. Check the IP address that responds. Check for leaks: Open browserleaks.com or dnsleaktest.com.Check redsocks logs: This is your best friend.
bashtail -f /var/log/redsocks.log # Or: journalctl -u redsocks
Look for connection or authentication error messages (e.g., ‘authentication failed’ — incorrect login/password).
Check proxy availability: Make sure your server can connect to the proxy server:
nc -zv 51.77.190.247 9595
# (Expected response: Connection to 51.77.190.247 9595 port [tcp/*] succeeded!)
Check ports:
ss -tuln(12345, 10053, 5300 should be listening).Check Firewall: Make sure ufw or firewalld are not blocking your new rules. If SSH is broken, disable all TCP forwarding.
Common Issues: ‘Connecting but not responding’ — check proxy-type (http-relay for HTTP). Endless loop? Make sure PROXY_IP is excluded.
Part 6. Saving iptables rules
iptables settings are reset on reboot. To make them permanent, install iptables-persistent.
sudo apt update
sudo apt install iptables-persistent
During installation, it will ask if you want to save the current rules. Agree. If you change the rules later, run the following to save them:
sudo netfilter-persistent save
To clear:sudo iptables -t nat -F REDSOCKS; sudo iptables -t nat -X REDSOCKS; sudo iptables -t nat -D PREROUTING/OUTPUT ...
(delete specific rules).
Conclusion
A transparent proxy with iptables is an incredibly powerful tool. Thanks to redsocks (or redsocks2), it can be configured to work with modern SOCKS5 proxies. The main thing is to remember about security, avoid intercepting all TCP traffic (by filtering ports), enable MASQUERADE for gateways, and always intercept DNS requests to avoid leaks.
FAQ
Connection not working? Check the proxy in the logs: ‘authentication failed’ — incorrect login/password.
Endless loop? Make sure PROXY_IP is excluded.
In containers? Redsocks requires cap_net_admin; use --privileged in Docker.
Doesn't work with my proxy? If HTTP — use type = http-connect for HTTPS compatibility.