开启 3 天免费试用
注册即可免费体验全部高级功能。
*仅限新用户；每位用户只能获得一次试用。
Linux 透明代理如何选择：REDIRECT、TPROXY 与 TUN
Ryan Foster
2026年10月11日· 8 分钟阅读
Linux 透明代理让流量进入代理，而不要求每个应用显式选择代理。REDIRECT 改写目标以交给本地监听，TPROXY 结合透明套接字与策略路由，TUN 则把路由到虚拟接口的 IP 包交给用户态程序。应按你控制的流量、实现支持的协议，以及能够安全恢复的网络状态选择。［1］［2］［3］
关键要点
- 捕获、路由投递和代理协议支持是三项独立责任。
- TPROXY 需要配套路由与应用支持，开一个端口不够。
- TUN 是 IP 接口，不代表加密或完整覆盖。
- 优先隔离的 network namespace，并保留独立管理通道。
Linux 透明代理选型应包括什么？
从一台获授权 Linux 主机或网关、一台测试客户端及一个自有目标开始。区分主机自产生流量与转发的局域网流量；网关 prerouting 和本机应用 output 属于不同入口，适用于其中一处的配置不能直接套用到另一处。
用自建方案规划框架确定网络所有者、维护窗口和恢复通道。如果只是让受支持应用使用设备代理，先比较系统代理与 TUN 的应用覆盖，再决定是否承担防火墙和策略路由维护。整机隧道与应用代理的范围也对应不同任务。
本文是机制比较，不是通用安装脚本。依据 Linux 内核 TPROXY、TUN 文档及 Xray 套接字选项说明实现边界，未声明作者完整端到端实验、吞吐结果或已验证发行版矩阵。采用某实现的操作前，先核对安装的内核、防火墙后端、代理版本与支持能力。［1］［2］［3］
Linux 透明代理路由为什么要与捕获分开？
把一次连接看作三个层次的交接：捕获选择进入代理的包，路由将其投递到正确监听或接口并保持返程一致，代理实现再理解传输协议、建立获允许的出站连接。
| 责任 | 管理员要问的问题 | 应收集的证据 |
|---|---|---|
| 捕获 | 哪些源、目标、协议和 hook 匹配？ | 限定规则计数及指定客户端 |
| 本地投递 | 为什么这个包会交给该进程？ | 监听地址、策略规则、路由、namespace |
| 代理处理 | 实现是否支持该传输协议？ | 版本化配置及单流诊断 |
| 返程 | 回复怎样到达原客户端？ | 客户端响应与预期路由 |
| 排除 | 哪些管理和代理自产流量绕过捕获？ | 管理通道不变及有限计数 |
计数增加只证明规则匹配，不证明代理转发成功；端口监听只证明有套接字，不证明包已投递。网页 TCP 请求正常只证明该请求，不能代替 UDP、DNS 或另一条路由上的应用验证。
选字段之前先画清角色，把 DNS 单独列为路径。客户端可能查询路由器解析器、应用自带解析器，或合成地址映射服务。Mihomo DNS 模式诊断解释了客户端答案为何可能不同于实际出站目标。
REDIRECT 与 TPROXY 适合哪些情况？
REDIRECT 通过目标转换把流量送到本地监听，接收实现必须正确恢复或以其他方式获得原目标。内核文档说明了目标转换的局限，包括原始目标处理；改端口不意味着任意应用都能保留正确目标。［1］
TPROXY 可以不采用同样的目标改写，把包交给透明套接字，但仍需要策略路由完成本地投递，并要求应用支持透明套接字。内核示例用于解释依赖，不是适合每台生产主机的完整防火墙。照搬标记或路由表编号，可能与已有所有者冲突。［1］
| 维度 | REDIRECT | TPROXY | TUN |
|---|---|---|---|
| 捕获对象 | 目标已转换的连接 | 交给透明套接字的指定包 | 路由到虚拟 IP 接口的包 |
| 原始目标 | 由实现正确恢复 | 保留在包地址中 | 用户态可从 IP 包读取 |
| TCP 与 UDP | 取决于监听；Xray redirect 文档为 TCP | Xray tproxy 文档支持 TCP 和 UDP | 取决于用户态栈与出站实现 |
| 路由归属 | Netfilter 路径与本地监听 | 标记、策略规则、本地投递路由 | 接口路由及排除项 |
| 权限边界 | 防火墙与相关套接字权限 | 防火墙、策略路由及透明套接字权限 | 接口创建配置与程序访问 |
| 常见失败 | 目标错误或不支持协议 | 缺投递路由或自我循环 | 路由过宽或不支持包处理 |
TPROXY UDP 支持须按实现核对：Xray 文档将 Linux redirect 描述为 IPv4/IPv6 TCP，将 tproxy 描述为 IPv4/IPv6 TCP 与 UDP，透明代理需要 root 或 CAP_NET_ADMIN。这是 Xray 的具体边界，不表示全部 REDIRECT 程序能力一样。实现结论应始终绑定对应来源。［2］
TUN 增加什么，又留下哪些问题？
TUN 让用户态程序读写 IP 包；内核把它与处理以太网帧的 TAP 区分。创建接口、分配路由和实现可工作的代理传输是不同工作。［3］
一个用户态栈可能把选定 TCP、UDP 流量转换为代理连接，另一个程序则实现不同隧道。接口名称或 tun 开关不能证明 DNS 覆盖、IPv6 转发、加密或断线阻断；这些属性要回到所选实现与观察路径核验。
默认路由送入接口时，尤其要明确归属。代理自身出站必须能到达远程端点，不能重新进入自己；管理、本地资源和返程也必须有明确设计。过宽路由若捕获控制连接，可能在诊断数据面之前就让你失联。
优先一次性虚拟机或专用 network namespace，让客户端、监听、接口和路由都有明确所有者。namespace 隔离可减少误碰，但主机防火墙、转发设置和物理接口仍是独立责任，不代表有权修改共享主机网络。
如何安全评估一条授权路径？
修改前写清实验契约：主机和 namespace、一台客户端源、自有目标、协议、预期路由、排除项、观测方法与逐项逆操作。管理通道放在捕获源或接口之外；没有独立控制台或可靠回退，就停在机制比较阶段。
以下只读命令可帮助记录 Linux 基线，不会创建代理；权限和输出可见性取决于环境。分享诊断时，私下保管地址、规则与进程信息。
uname -r
ip -brief address
ip rule show
ip route show table all
ss -lntup
防火墙检查工具必须与实际后端相符，不混用 legacy iptables 与 nftables 指令。新增对象前，记录已有表、标记、优先级和路由。端口或标记已被使用时，保留原服务，不覆盖对象或结束进程。
按所选实现有文档依据的方法排除代理自身出站套接字。排除可能依赖进程身份、标记、接口或目标，必须与投递路由一致。计数猛增、相同目标反复出现、资源迅速增长可能说明循环；停止实验并执行逆操作，不靠增大限制继续跑。
本文不提供可直接复制的防火墙规则。拓扑、后端、namespace、代理配置支持与回退必须一起冻结，规则才具备安全适用条件。概念表选出某机制，不构成临时增加全局规则的依据。
什么观察才能证明成功或失败？
在授权范围内安排正反例。需要 UDP 时选自有服务；DNS 查询只证明这次 DNS 交换，不代表所有 UDP 应用。日志限于测试元数据，不抓取他人内容。
| 检查方法 | 预期现象 | 失败处理 |
|---|---|---|
| 发起一条指定 TCP 连接 | 规则、监听、出站和响应一致 | 逐层追交接再改其他层 |
| 一次授权 UDP 交换 | 实现支持且回复回到客户端 | 检查实现和返程 |
| 重复排除的管理请求 | 管理不进入捕获 | 先移除测试捕获 |
| 观察代理自产出站 | 不递归进入代理 | 停止并修复排除 |
| 新 DNS 与 IPv6 检查 | 各自符合指定策略 | 标记未验证并限制范围 |
| 停止测试代理 | 失败或直连回退符合设计 | 拒绝非预期直连逃逸 |
涉及互联网出口时，检查该请求的公网出口，另测 DNS、IPv6、UDP 和断连行为。仅比较本地捕获机制时，IP 页面不能替代路由证据。捕获之外的系统解析问题另按Ubuntu DNS 归属检查处理。
恢复能力怎样影响选择？
优先能逐项命名并撤销、不会影响其他服务的机制。登记每条测试规则、路由、策略规则、接口、进程和临时配置，注明 namespace 与持久化所有者。恢复既要撤销运行态，也要移除启动来源，否则实验可能随重启返回。
按依赖关系的逆序，仅删除本次创建对象。不得用 nft flush ruleset、全清策略规则或重置主机默认路由作为通用清理。对象若已被另一所有者使用，应停下核对，不能盲删。
恢复后对照管理访问、普通路由、解析设置和原基线，确认无残留测试监听或路由，原本需要保留的代理已恢复。日常使用的代理或 VPN 客户端及其他客户端保持原状。浏览器能打开是辅助证据，不能替代对象清单对照。
总结
- 按协议支持、投递依赖和可恢复的对象归属选择。
- 分别观察捕获、路由、DNS 与代理处理。
- 只测试一条授权路径，排除管理流量。
- 撤销命名测试对象并确认恢复，再扩大覆盖。
常见问题
TPROXY 是否总比 REDIRECT 好？
TPROXY 提供不同的目标与投递语义，也增加策略路由责任。只有实现和协议需求确实需要、且能够恢复状态时才选择。
所有代理的 REDIRECT 都支持 UDP 吗？
UDP 能力取决于接收实现及原目标处理。Xray 的 redirect 文档为 TCP，不能从 Netfilter 功能名推断其他程序能力。
TUN 会加密捕获的流量吗？
TUN 只把 IP 包交给用户态，加密取决于程序和出站传输。主机上有接口，不代表已建立加密隧道。
为什么规则匹配但流量到不了监听？
规则命中只证明捕获。缺少策略路由、监听地址错误或 namespace 不一致，都可能在计数增加时仍无法投递。
可以复用内核示例的路由表 100 吗？
应先核对该表已有所有者及实现要求，再决定能否使用。文档示例解释依赖，并没有替你的系统预留编号。
网页正常能证明 UDP 与 IPv6 都被覆盖吗？
网页请求只证明自身路径和协议。应独立验证自有 UDP、IPv6 路由、DNS 与失败行为，再声明更大覆盖范围。
删除 namespace 就能完全恢复吗？
删除隔离 namespace 不会自动撤销主机侧规则与持久配置。必须逐项登记所有者，移除后确认原管理、路由和 DNS 状态。
免责声明：结论依据所列公开实现文档，未声明作者完成整体实验。实际变更必须获授权，冻结拓扑并保留可独立使用的恢复通道。
来源:
- 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 2026 年 10 月 11 日。
延伸阅读:
