Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
Linux Transparent Proxy: REDIRECT, TPROXY, or TUN?
Ryan Foster
October 11, 2026· 11 min read
A Linux transparent proxy receives traffic without each application explicitly selecting a proxy. REDIRECT changes a packet's destination toward a local listener, TPROXY combines transparent sockets with policy routing, and TUN passes routed IP packets to a userspace program. Choose by the traffic you own, the protocols your implementation supports, and the network state you can safely restore.［1］［2］［3］
Key Takeaways
- Capture, route delivery, and proxy protocol support are separate responsibilities.
- A TPROXY listener needs suitable routing and application support, not just a port.
- TUN is an IP interface, not a promise of encryption or complete coverage.
- Prefer an isolated network namespace and preserve independent management access.
What should a Linux transparent proxy decision include?
Start with one authorized Linux host or gateway, one test client, and one destination you control. Distinguish locally generated traffic from forwarded LAN traffic. A gateway's prerouting path and a host application's output path are different entry points; a configuration for one is not automatically suitable for the other.
Use the self-hosting planning framework to name the network owner, maintenance window, and recovery channel. If you only want supported applications to use a device proxy, compare system-proxy and TUN application coverage before becoming the owner of firewall and policy-routing rules. Device-wide and explicit app-proxy tasks also differ in which traffic a tunnel can cover.
This is a mechanism comparison, not a universal installation recipe. It uses the Linux kernel's TPROXY and TUN references and Xray's documented socket options to illustrate implementation boundaries. No author end-to-end experiment, throughput result, or tested distribution matrix is claimed. Check the installed kernel, firewall backend, proxy version, and supported features before applying an implementation's instructions.［1］［2］［3］
How does Linux transparent proxy routing deliver captured traffic?
Think of a connection as a handoff across three layers. Capture selects which packets enter the proxy path. Routing delivers those packets to the intended listener or interface and keeps return traffic coherent. The proxy then needs to understand the transport and establish an allowed outbound connection.
| Responsibility | Administrator's question | Evidence to collect |
|---|---|---|
| Capture | Which source, destination, protocol, and hook match? | Scoped rule counters and the selected client |
| Local delivery | Why does the selected packet reach this process? | Listener address, policy rule, route, namespace |
| Proxy handling | Can this implementation handle that transport? | Versioned configuration and per-flow diagnostics |
| Return path | How does the reply reach the original client? | Client response and the intended route |
| Exclusions | Which management and proxy-owned flows bypass capture? | Unchanged management and bounded counters |
A counter increasing establishes a rule match, not successful proxy forwarding. A listening port establishes a socket, not delivery to it. A working TCP web request establishes that request, not UDP support, DNS handling, or the behavior of an application using a different route.
Draw these roles before choosing fields. Include DNS as its own path: the client's lookup may reach a router resolver, an application-controlled resolver, or a synthetic-address mapping service. The Mihomo DNS-mode diagnostic explains why the address seen by a client may differ from the eventual outbound destination.
When are REDIRECT and TPROXY appropriate?
REDIRECT uses destination translation to bring traffic to a local listener. The receiving implementation must recover or otherwise obtain the original destination correctly. The kernel documentation discusses the limitations of destination translation, including original-destination handling; do not assume changing a port preserves every application's intended target.［1］
TPROXY can deliver traffic to a transparent socket without the same destination rewrite. Its design still requires policy routing for local delivery and application support for transparent sockets. The kernel's examples explain those dependencies; they are not a complete, safe firewall for every production host. Copying an example mark or routing-table number into a busy system can collide with an existing owner.［1］
| Dimension | REDIRECT | TPROXY | TUN |
|---|---|---|---|
| Capture object | Destination-translated flow | Selected packet delivered to transparent socket | Packet routed to virtual IP interface |
| Original destination | Implementation must recover it appropriately | Retained in packet addressing | Available in IP packet handled by userspace |
| TCP and UDP | Depends on listener; Xray redirect documents TCP | Xray tproxy documents TCP and UDP | Depends on userspace stack and outbound implementation |
| Route ownership | Netfilter path and local listener | Packet marks, policy rules, local-delivery routes | Interface routes and exclusions |
| Privilege boundary | Firewall and relevant socket permissions | Firewall, policy routing, transparent socket permissions | Interface creation/configuration and program access |
| Common failure | Wrong target or unsupported transport | Missing delivery route or recapture loop | Overbroad route or unsupported packet handling |
For TPROXY UDP support, check the selected implementation: the Xray reference describes redirect for IPv4/IPv6 TCP and tproxy for IPv4/IPv6 TCP and UDP on Linux, with root or CAP_NET_ADMIN required for transparent proxying. That is a documented Xray boundary, not a statement that every REDIRECT-based program has identical support. Keep implementation-specific conclusions attached to their source.［2］
What does TUN add, and what does it leave unresolved?
TUN provides an interface through which a userspace program reads and writes IP packets. The kernel distinguishes it from TAP, which handles Ethernet frames. Creating or attaching the interface and assigning routes are different from implementing a working proxy transport.［3］
A userspace stack may translate selected TCP or UDP flows into proxy connections, while another program may implement a different tunnel design. Neither the interface name nor a tun switch proves DNS coverage, IPv6 forwarding, encryption, or a kill switch. Verify those properties in the selected implementation and your observed path.
Route ownership becomes especially important when a default route is sent into the interface. The proxy's outbound traffic needs a way to reach its remote endpoint without reentering itself. Management traffic, local resources, and the return path must remain intentional. A broad route that captures the control channel can lock you out before you can diagnose the data plane.
Prefer a disposable VM or a dedicated network namespace whose client, listeners, interfaces, and routes have a clear owner. Namespace isolation limits accidental overlap, but host firewall changes, forwarding configuration, and physical interfaces remain separate responsibilities. Do not treat a namespace as permission to modify shared host networking.
How can you evaluate one authorized path safely?
Write an experiment contract before changing anything: named host and namespace, one client source, owned destination, protocol, expected route, exclusions, observation method, and exact inverse changes. Keep the management channel outside the captured source or interface. If no independent console or reliable rollback exists, stop at the comparison.
Read-only inventory can help describe the existing Linux host. These commands do not create a proxy; privileges and output visibility depend on your environment. Keep addresses, rules, and process details private when sharing diagnostics.
uname -r
ip -brief address
ip rule show
ip route show table all
ss -lntup
Choose the firewall inspection tool matching the installed backend rather than mixing legacy iptables instructions with an nftables ruleset. Record existing tables, marks, priorities, and routes before reserving any new object. An already used mark or port belongs to its existing service; do not overwrite it or kill that process.
Keep the proxy's outbound sockets out of the captured set using the selected implementation's documented mechanism. Exclusion may depend on a process identity, mark, interface, or destination, and must agree with route delivery. High counters, repeated identical destination logs, or rapid resource growth can indicate a loop; stop the test and apply its inverse changes rather than increasing limits.
This article intentionally supplies no copy-and-paste firewall rules. The topology, backend, namespace, supported proxy configuration, and rollback have to be fixed together before such commands are safe. Do not improvise a global rule merely because the conceptual table has identified a preferred mechanism.
Which observations establish success or failure?
Use positive and negative cases within your authorized test scope. Select an owned UDP service if UDP matters; a DNS query is evidence for that DNS exchange, not every UDP application. Keep logs limited to test metadata and avoid capturing other users' content.
| Check method | Expected observation | Failure action |
|---|---|---|
| Make one selected TCP connection | Intended rule, listener, outbound, and reply agree | Trace each handoff before changing another layer |
| Send one authorized UDP exchange | Transport is supported and the reply reaches the client | Check implementation support and return routing |
| Repeat an excluded management request | Management stays outside capture | Remove test capture before further work |
| Inspect proxy-owned outbound traffic | It does not recursively enter the proxy | Stop test and repair the exclusion |
| Make a fresh DNS and IPv6 check | Each follows its separately specified policy | Mark unverified paths and restrict deployment scope |
| Stop the test proxy | Failure or direct fallback matches the stated design | Reject an unintended direct escape |
If internet egress is part of the experiment, inspect that request's public exit and separately test DNS, IPv6, UDP, and disconnect behavior. If only a local capture mechanism is being compared, an exit-IP page is not a useful substitute for route evidence. For system resolver problems outside capture, use the Ubuntu DNS ownership checks.
How should recovery affect your choice?
Favor the mechanism whose objects you can name and remove without touching another service. Record each test rule, route, policy rule, interface, process, and temporary configuration, including the namespace and persistent owner. Recovery needs to remove both runtime changes and their startup source, otherwise the experiment can return after reboot.
Remove only objects created for the test, in the inverse order appropriate to their dependencies. Never use nft flush ruleset, clear all policy rules, or reset the host's default routes as a general cleanup. If an object has acquired another owner, stop and reconcile rather than deleting it blindly.
After recovery, compare management access, ordinary routing, resolver settings, and the retained baseline. Confirm no test listener or route is still active and that an intended persistent proxy was restored. Leave your everyday proxy or VPN client and other unrelated clients unchanged. A successful browser request after cleanup is useful, but it does not replace the inventory comparison.
Summary
- Choose from protocol support, delivery requirements, and recoverable ownership.
- Keep capture, routing, DNS, and proxy handling separately observable.
- Limit an experiment to one authorized path and exclude management traffic.
- Remove named test objects and verify recovery before widening coverage.
FAQ
Is TPROXY always better than REDIRECT?
TPROXY offers different destination and delivery semantics, but it also adds policy-routing responsibilities. Choose it when your implementation and transport requirements justify those responsibilities and you can restore the resulting state.
Does REDIRECT support UDP in every proxy?
UDP support depends on the receiving implementation and its destination handling. Xray's documented redirect mode is TCP; do not generalize another program's capabilities from a Netfilter feature name.
Does TUN encrypt the intercepted traffic?
TUN delivers IP packets to userspace; encryption depends on the program and outbound transport. An interface existing on the host is not evidence that an encrypted tunnel has been established.
Why can packets match a rule but never reach the listener?
A rule match is only capture evidence. Missing policy routing, an incorrect listener address, or a namespace mismatch can prevent local delivery even while the counter increases.
Can I reuse routing table 100 from a kernel example?
Only use a table after checking its existing owner and your implementation's requirements. Documentation examples illustrate dependencies and do not reserve identifiers on your system.
Does a working web page prove UDP and IPv6 coverage?
A web request proves its own path and protocol. Test owned UDP exchanges, IPv6 routing, DNS, and failure behavior separately before making a broader coverage claim.
Is deleting a network namespace enough to restore everything?
Deleting an isolated namespace does not automatically undo host-side rules or persistent configuration. Inventory every changed owner and verify the original management, routing, and DNS state after removal.
Disclaimer: Conclusions follow the listed public implementation references. No complete author experiment is claimed; apply changes only with authorization, a fixed topology, and an independently usable recovery channel.
Sources:
- Linux kernel — Transparent proxy support — https://cdn.kernel.org/doc/html/latest/networking/tproxy.html
- Project X — Sockopt — https://xtls.github.io/en/config/transports/sockopt.html
- Linux kernel — Universal TUN/TAP device driver — https://docs.kernel.org/networking/tuntap.html
Sources checked 11 October 2026.
Related articles:
