PassWall2 TProxy 和 TUN 区别：怎么选、怎么查、怎么回滚

更新于 2026-11-09 · passwall.lol

简答：一句话结论：在 PassWall2 网关场景中，先优先核对当前版本实际提供的 TPROXY/REDIRECT 选项；TUN 属于虚拟网卡接管方式，是否能在你的 PassWall2、代理核心和固件组合中稳定使用，不能只看 sing-box 支持，而要以当前界面、生成配置和日志为准。普通家庭路由器通常先从 TPROXY 开始，遇到 QUIC、部分 UDP 或特殊应用无法接管时，再单独核验 TUN 或改用应用自身的代理能力。

定义：TProxy 是依靠 Linux 防火墙、策略路由和透明套接字接管流量，TUN 则是通过虚拟网卡把三层 IP 数据包交给代理核心处理；二者属于流量接管方式，不能与全局模式、规则模式或 DNS 分流直接画等号。

先看结论：你应该优先选哪一种

如果你的目标是让 OpenWrt 网关为局域网设备提供常规 TCP/UDP 透明代理，且当前 PassWall2 界面能够正常显示并启用 TPROXY，建议先使用 TPROXY。它更贴合网关侧的防火墙转发路径，便于按设备、端口和规则分流。

如果只有某些使用 QUIC、特殊 UDP、游戏或物联网协议的应用无法被现有规则接管，不要立即把问题归因于“TPROXY 性能不够”。先确认端口范围、UDP 转发、DNS、IPv6 和节点协议，再核对当前 PassWall2 后端是否真的生成了 TUN 配置。官方 PassWall2 仓库当前源码可以核实到的是 REDIRECT、TPROXY、IPv6 TProxy 和 ICMP 接管等选项；TUN 是否在你的安装包中可用，需要以当前版本的 LuCI 页面和运行配置为准。查看 PassWall2 当前透明代理选项源码

快速选择卡：先按现象判断，再做版本核验

现象或目标	先查什么	优先方向	不要直接下的结论
网页、常规 TCP 连接正常	TPROXY 规则、节点日志、DNS	继续使用 TPROXY	不能据此证明所有 UDP 都正常
部分 App 打不开，网页却正常	UDP 端口、QUIC、分流规则和 DNS	先补齐 UDP 排查	不一定需要 TUN
游戏或实时通信失败	UDP、NAT、节点协议、MTU	先测试 UDP 路径	不能只看网页测速
需要接管 ICMP 或特殊三层流量	当前核心和模式是否支持	核验 TUN 或其他专用能力	普通 TPROXY 不等于完整三层接管
启用后路由器断网	回滚开关、策略路由、DNS 和防火墙	恢复原模式再逐项测试	不要连续叠加多个接管模式

TProxy 和 TUN 到底差在哪里

1. TProxy：在防火墙转发阶段接管

TPROXY 通常由防火墙规则把符合条件的 TCP 或 UDP 流量送到透明代理监听端口，同时保留原始目标地址所需的信息。Linux 内核文档说明，TPROXY 与单纯的 REDIRECT 不同，它不依赖 NAT 修改目标地址，并且需要透明套接字以及相应的内核扩展。使用 nftables 时，相关能力通常对应 NFT_SOCKET 和 NFT_TPROXY；使用 iptables 时则对应 socket match 和 TPROXY target。查看 Linux 内核 TPROXY 文档

PassWall2 当前源码会通过检测运行中的模块来决定是否显示透明代理选项，并提供 REDIRECT、TPROXY、nftables/iptables 偏好以及 IPv6 TProxy 等配置。源码还把 IPv6 TProxy 标注为实验性功能，因此不能把 IPv4 TPROXY 正常运行直接推断为 IPv6 也一定可用。核对 PassWall2 透明代理字段

2. TUN：通过虚拟网卡接管三层数据包

TUN 会创建一个虚拟网络接口，把 IP 数据包交给代理核心，再由核心根据路由规则决定直连、代理或拒绝。sing-box 官方文档把 TUN 定义为一种入站类型，并提供 auto_route、strict_route、DNS 劫持、路由排除和 Linux 下的 auto_redirect 等能力。查看 sing-box TUN 入站文档

这意味着“sing-box 支持 TUN”与“PassWall2 当前界面已经完整支持 TUN”是两件事。当前 PassWall2 官方讨论中仍有人询问 sing-box TUN 支持，讨论回复还提到某个实现只能在全流量模式下工作；这只能作为版本核验线索，不能当作所有安装环境的稳定性结论。查看 PassWall2 TUN 相关讨论

3. REDIRECT 不是 TPROXY，也不是 TUN

REDIRECT、TPROXY 和 TUN 位于不同实现层。REDIRECT 通过 NAT 类方式把连接转到本地端口，配置简单但对原始目标地址、UDP 和部分复杂流量存在限制；TPROXY 依赖透明套接字和策略路由；TUN 则通过虚拟接口接收三层数据包。全局模式、规则模式和分流模式描述的是“流量如何选择出口”，而 TPROXY、REDIRECT、TUN 描述的是“流量如何进入代理核心”，不要把这两组概念混用。

按流量类型比较：TCP、UDP、QUIC、ICMP 和 IPv6

不同流量的核验重点

流量类型	TPROXY 关注点	TUN 关注点	测试限制
TCP/HTTPS	防火墙规则、监听端口、原始目标地址和策略路由	虚拟接口、自动路由、回环排除	网页能打开只能证明部分 TCP 链路可用
UDP	UDP 重定向端口、TPROXY 规则、节点是否支持 UDP	虚拟网卡、UDP 会话、MTU 和 NAT	一次 UDP 成功不代表长连接和实时业务稳定
QUIC	重点检查 UDP 443 是否被接管，必要时按应用测试 TCP 回退	理论上更适合从三层路径统一接收，但仍受核心、规则和版本限制	不能仅凭 TCP 测试判断 QUIC
ICMP/PING	需要确认是否启用了 ICMP/ICMPv6 接管，且源码提供了对应开关	sing-box TUN 支持对 ICMP 做路由匹配，但实际仍取决于配置	Ping 通不等于网页、UDP 或业务连接通
IPv6	需要单独核对 IPv6 TProxy、内核能力和节点 IPv6 支持	需要配置 IPv6 地址、路由和排除项	IPv4 正常不能推断 IPv6 正常

对于 QUIC、游戏和实时通信，优先看实际业务使用的 UDP 端口和日志，而不是只看节点延迟。延迟、吞吐和 CPU 占用没有固定的 TPROXY 与 TUN 排名；路由器 CPU、代理核心、节点协议、加密方式、规则数量、MTU 和并发连接都会改变结果。sing-box 文档称 Linux 下的 TUN 配合 auto_redirect 可以改善路由并提升性能，但这属于其自身实现说明，不能直接等同于 PassWall2 所有版本都具备相同配置和表现。核对 TUN 的 auto_route 与 auto_redirect 条件

在 PassWall2 中核对当前环境：可照做的最小步骤

先记录回滚点。进入 PassWall2 当前配置页面，记下原来的 TCP Proxy Way、IPv6、ICMP、DNS、分流和端口设置。一次只改一个接管方式，保留可以恢复管理页面的本地连接。
确认系统包管理器和固件信息。通过 SSH 以管理员权限执行 ubus call system board，再执行 opkg --version 和 apk --version。哪个命令存在，取决于固件的包管理方式；不要把适用于另一种包管理器的安装命令直接复制过来。PassWall2 官方仓库同时说明了 IPK 与 APK 安装路径，因此安装包格式和依赖应按当前固件核对。查看 PassWall2 官方仓库的安装说明
检查透明代理相关能力。执行 lsmod | grep -E 'nft_tproxy|nft_socket|xt_TPROXY|xt_socket'。如果没有输出，不要立即断定内核不支持，因为某些能力可能以内置方式编译；继续查看 nft list ruleset 和 PassWall2 日志。目标是确认规则是否实际生成，而不是只看模块名称。
确认 PassWall2 页面显示什么。在当前 LuCI 页面查看 TCP Proxy Way 是否有 REDIRECT、TPROXY，是否显示 IPv6 TProxy、ICMP 或 ICMPv6 选项。页面没有出现 TUN 选项时，不要把 sing-box 的通用 TUN 配置片段直接粘贴进 PassWall2。
先用 TPROXY做基线测试。保存并应用后，依次测试一个普通 TCP 网站、一个明确使用 UDP 的业务、DNS 查询和局域网设备访问。每次记录时间、设备、节点、IPv4/IPv6、TCP/UDP、是否命中规则和日志关键词，不设定“无失败就是合格”这类未经核实的阈值。
出现异常时回滚。如果启用后路由器无法访问管理页面，先通过有线局域网或 SSH 恢复上一份配置，停止 PassWall2，再恢复原有 DNS 和防火墙状态。不要同时切换 TUN、DNS、MTU、IPv6 和分流规则，否则无法判断真正原因。

常见的局部成功判据包括：PassWall2 进程正常运行、规则表中出现对应链、访问日志能看到目标流量、DNS 查询返回预期结果、UDP 业务不再立即超时。每一项只能证明一个局部环节，最终仍要结合目标 App、设备和网络条件复测。

按场景选择：家庭网关、旁路由、游戏、电视和 IoT

家庭主路由：先用 TPROXY 做小范围测试，优先接管一台设备或一组明确端口。确认 DNS、局域网访问和管理页面正常后，再扩大范围。
旁路由：先确认客户端网关、主路由静态路由、回程路径和 DNS 指向。旁路由中即使 TPROXY 或 TUN 本身工作正常，网关路径错误也会表现为部分设备断网。
游戏和实时通信：先确认节点支持 UDP，检查 UDP 端口、MTU、NAT 类型和日志。若仅有某类 QUIC 或 UDP 业务失败，再核对 TUN 是否在当前版本、核心和固件组合中真正可用。
智能电视和 IoT：设备通常不能单独安装客户端，因此更依赖网关侧透明代理。建议从单设备、单规则开始，保留局域网直连和设备发现流量，避免把所有局域网广播、管理地址和本地服务一并送入代理。
IPv6 网络：把 IPv4 和 IPv6 分开验证。若当前节点或规则没有明确支持 IPv6，先关闭对应接管或设置合理的直连策略，避免出现 IPv4 正常但 IPv6 绕过规则或连接失败的情况。

选择的核心不是“哪一个模式永远更快”，而是当前设备、内核、代理核心、规则和目标流量是否匹配。PassWall2 官方源码对 IPv6 TProxy 标注了实验性提示，这类功能应先在单设备和可回滚环境中验证。查看源码中的 IPv6 TProxy 和 ICMP 选项

常见故障：为什么看似启用了 TPROXY，却没有真正接管

页面有选项，但规则没有生成：检查 nftables/iptables 偏好、内核扩展、服务重启状态和日志，避免只看 LuCI 保存成功提示。
TCP 正常、UDP 不通：检查 UDP Redir Ports、节点 UDP 能力、UDP 规则和 QUIC 使用的端口；不要只更换 TUN。
IPv6 绕过或断网：单独查看 IPv6 路由、DNS AAAA 结果和 IPv6 TProxy 状态。IPv6 功能在源码中有实验性提示，需按当前版本核验。
切换后所有设备断网：优先恢复原接管方式，检查策略路由和 DNS 回环。确认基线恢复后，再只改 TPROXY、TUN 或规则中的一个变量。
日志显示核心启动，但业务失败：核心启动只说明进程和配置完成，不代表流量已进入正确的入站。需要同时看防火墙规则、监听端口、访问日志和目标业务。

如果你使用的是 sing-box 后端，还可以在核心配置检查能力允许的情况下使用 sing-box check 检查生成配置；但 PassWall2 生成配置的位置、启动参数和权限可能随版本变化，命令应以当前系统实际安装的核心帮助信息为准，不要套用其他平台的路径。

常见问题

PassWall2 应该选 TProxy 还是 TUN？

普通 OpenWrt 网关建议先核对并使用当前界面提供的 TPROXY，尤其是网页、常规 TCP/UDP 和家庭设备分流场景。只有在特定 UDP、QUIC 或三层流量无法接管，并且当前版本、代理核心和固件明确支持 TUN 时，再进行 TUN 验证。

TUN 一定比 TProxy 快吗？

不能这样判断。性能取决于路由器 CPU、代理核心、节点协议、加密、规则数量、MTU 和并发连接。sing-box 官方文档提到 Linux 下 TUN 配合 auto_redirect 可以改善路由和性能，但这不是所有 PassWall2 版本和固件组合的实测保证。

为什么网页能打开，但某些 App 或 QUIC 不能用？

网页通常主要验证 TCP 和 DNS，不能代表 UDP、QUIC、IPv6 或长连接都正常。应先检查 UDP 端口、节点 UDP 能力、分流规则、DNS 和 MTU，再确认当前接管方式是否生成了对应规则。

PassWall2 页面没有 TUN 选项，能不能手动添加 sing-box TUN 配置？

不建议直接粘贴。sing-box 本身支持 TUN，但 PassWall2 是否会正确生成、启动并维护相应配置，需要结合当前版本和后端核对。手动改运行文件还可能在保存、重启或订阅更新后被覆盖。

lsmod 看不到 nft_tproxy，是不是 TPROXY 不支持？

不一定。某些固件可能把能力编译进内核，而不是作为独立模块加载。应结合 nft list ruleset、包管理器提供的内核包、PassWall2 页面显示和日志判断，不能只凭一次 lsmod 输出下结论。

启用 TPROXY 或 TUN 后断网，怎么恢复？

先通过有线局域网或 SSH 进入路由器，停止或回滚 PassWall2，恢复原来的 DNS、防火墙和策略路由，再重新启动网络服务。恢复后一次只改一个选项，并先用单台设备验证。