高墙之外❤️

PassWall2 UDP 不通怎么办？从节点到防火墙逐层排查

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

简答：PassWall2 UDP 不通时，不要一开始就反复切换核心或重装插件。先用同一节点做 TCP 与 UDP 对照，再检查 PassWall2 的 UDP 节点、UDP 转发端口、TPROXY 所需模块和防火墙规则；如果只有 UDP 53 或 UDP 443 异常，还要单独排查 DNS、QUIC 与 IPv6。本文只解决 PassWall2 的 UDP 连接排查，不覆盖安装、订阅获取或具体服务商可用性。

定义：PassWall2 UDP 不通，是指 TCP 访问可能正常，但经过路由器透明代理的 UDP 流量无法建立、持续转发或返回，例如游戏、语音、QUIC、DNS 或依赖 UDP 的隧道协议异常。

先做三步速查：确认到底是哪一段 UDP 出问题

本站是第三方使用指南站，不是 PassWall2 官方站。排查时先不要同时修改多个选项，否则即使恢复也无法判断原因。

  1. 同一节点做对照：先确认普通网页或其他 TCP 连接是否正常，再用同一节点测试出现问题的 UDP 应用。TCP 正常只能说明节点或核心具备部分连通性，不能证明 UDP 出站正常。
  2. 看 PassWall2 运行日志：在 LuCI 中打开 PassWall2 的运行日志或调试日志，复现一次故障后再查看。OpenWrt 的系统日志也可以通过 logread -f 持续查看；该命令读取系统日志环形缓冲区，具体用法可参考 OpenWrt 日志说明。
  3. 记录改动前状态：记下当前节点、核心、TCP/UDP 转发方式、UDP 不转发端口、DNS 和 IPv6 设置。每次只改一项，保存应用后重新测试。
现象与优先检查项
现象优先检查不要直接下的结论
所有 UDP 应用都不通UDP 节点、TPROXY 模块、透明代理规则、防火墙不等于节点一定失效
只有一个游戏或语音应用不通访问控制、分流规则、端口范围、IPv6不等于 PassWall2 的全部 UDP 都坏了
只有 DNS 或 UDP 53 异常直连 DNS、DNS 回环、UDP 不转发端口不等于代理核心未启动
只有 QUIC 或 UDP 443 异常节点是否支持 UDP、IPv6 绕过、应用是否回退 TCP不等于网页本身不可访问

第一层：核对 UDP 节点与协议能力

PassWall2 项目仓库列出的核心和协议支持范围包含 Xray、sing-box、Hysteria2、TUIC、WireGuard 等，但“界面能够选择某种协议”不等于当前节点、上游线路和服务端一定允许 UDP 转发。这个区别是排查的边界，不能仅凭节点名称判断。

  1. 打开 PassWall2 的节点列表，确认当前代理节点不是仅面向 TCP 的普通 HTTP、SOCKS 或传统传输配置。
  2. 如果使用 Hysteria2、TUIC 或 WireGuard 类 UDP 协议，先确认节点配置本身能在其他受控客户端中建立连接；不要把“节点延迟测试成功”当作 UDP 应用已经可用。
  3. 临时切换到一个已知能承载 UDP 的节点，只做一次对照测试。若 TCP 节点正常、UDP 节点失败，优先核对节点协议和服务端能力；若所有节点都失败，再回到路由器转发链路排查。

PassWall2 项目公开仓库提供了协议与依赖说明，可查看 PassWall2 项目仓库。仓库内容代表项目自述，不能替代当前节点服务端的能力说明。

第二层：检查 UDP 转发端口与流量嗅探配置

PassWall2 当前界面源码中把“UDP No Redir Ports”和“UDP Redir Ports”作为独立转发设置。其中，UDP 不转发端口的含义是把指定端口排除在代理转发之外，且优先级较高；UDP 转发端口则决定哪些 UDP 端口进入透明代理。字段名称和菜单位置可能随版本变化，应以当前 LuCI 页面为准。

  1. 先查看“UDP 转发端口”是否为覆盖目标应用的范围。为了降低变量，可以临时使用界面提供的全端口选项测试一次。
  2. 检查“UDP 不转发端口”是否误填了目标应用、UDP 443 或其他需要代理的端口。不要长期把全部 UDP 设为不转发，因为这会绕过 UDP 代理，测试结束后应恢复原值。
  3. 如果 DNS 单独异常，检查是否把 UDP 53 纳入了不转发或转发逻辑。PassWall2 的公开 Issue 记录过流量嗅探、TPROXY 与 UDP 53 规则组合导致 DNS 间歇异常的案例，但该 Issue 不能证明所有设备都会复现；可将其作为特定现象的优先检查项，而不是确定诊断。参考 PassWall2 UDP 53 与 TPROXY 相关 Issue。

每次改动后点击保存应用，并用同一设备、同一应用、同一节点重复测试。只看到端口监听或日志出现启动成功，不代表 UDP 已经完成代理出站。

第三层：核对 TPROXY、内核模块与防火墙规则

在使用 nftables 透明代理的系统上，UDP 通常依赖 TPROXY 相关处理链路。PassWall2 项目 Issue 中有案例指出，缺少 kmod-nft-tproxy 或 kmod-nft-socket 可能造成 TCP 正常而 UDP 透明转发失败；这是公开案例中的排查结果，不应直接视为所有固件的固定依赖。

  1. 先确认固件实际使用的防火墙后端。OpenWrt 22.03 及之后默认使用 firewall4，并由 nftables 生成规则，具体说明见 OpenWrt Firewall overview 与 OpenWrt nftables 说明。
  2. 通过固件实际包管理器检查模块，而不是只看某个命令是否存在。可以先查看已安装包数据库，再核对是否存在 kmod-nft-tproxy、kmod-nft-socket 或当前版本对应的同类模块。不同固件的包名、仓库和内核版本可能不同，查不到时不要强行安装不匹配的包。
  3. 在 SSH 中执行 fw4 print 和 nft list ruleset，搜索 PassWall2 相关链、TPROXY、UDP 端口和计数器。OpenWrt 文档将 fw4 print 作为检查生成规则的入口，并说明 nft list ruleset 可查看内核中的完整规则集，参考 OpenWrt Netfilter Management。
  4. 如果规则没有生成、应用计数器始终为零，优先检查透明代理模式、访问控制、接口范围和防火墙重载状态。不要直接手写覆盖 PassWall2 的规则；先恢复插件配置，再用最小改动验证。

PassWall2 源码还显示，TCP REDIRECT、TCP TPROXY、IPv6 TPROXY、UDP 转发端口和 nftables 选择之间存在条件关系，因此不同版本或固件显示的菜单不一定相同，不能照搬其他版本的截图或固定路径。可参考其当前配置页面源码：PassWall2 转发设置源码。

第四层：用日志和抓包判断请求是否进入代理

当设置看起来正确但 UDP 仍不通，应把问题拆成“客户端是否发包、路由器是否接到、透明代理是否接管、核心是否出站、返回包是否回来”五段。以下命令只用于观察，不会修改配置。

  • logread -f：实时观察 OpenWrt 系统日志；复现问题时重点看 PassWall2、核心、防火墙和 DNS 相关的新日志。
  • ss -lunp：查看 UDP 监听，但监听端口只能证明本机有进程占用端口，不能证明代理出站成功。
  • fw4 print：检查 firewall4 生成的规则；若系统不是 fw4，应以当前固件实际防火墙为准。
  • nft list ruleset：观察相关规则是否存在以及计数器是否变化。若规则计数器不变，可能是接口、访问控制、IPv6 或端口范围没有匹配。
  • tcpdump：如果固件已安装，可分别在 LAN、WAN 或目标接口抓取一次短时间流量。抓包只能帮助确认是否有包经过某接口，不能单独证明加密隧道中的远端 UDP 已成功到达。

建议每次只复现一个应用动作，例如打开一次语音连接或进入一次游戏房间，然后立即停止抓包并保存时间点。日志中的 timeout、connection refused 或 DNS error 都是线索，不应在没有对照测试时直接当作唯一根因。

第五层：排除 DNS、IPv6 与旁路由路径冲突

UDP 故障经常不是目标应用本身造成，而是 DNS 或 IPv6 让流量绕过了预期链路。先不要同时开启多个实验性功能。

  1. DNS：确认直连 DNS 没有指向会被再次代理的本机地址，检查 UDP 53 是否被重复接管。若只有域名访问失败、直接使用已知 IP 的测试结果不同，优先排查 DNS；但这仍不能证明目标 UDP 出站已经正常。
  2. IPv6：如果客户端优先使用 IPv6，而 PassWall2 只正确处理 IPv4，可能出现“TCP 测试正常、某些应用仍失败”。可以临时关闭客户端或路由器侧 IPv6 参与路径做一次对照，验证后再决定是否恢复，不要把关闭 IPv6 当成永久修复。
  3. 旁路由：核对客户端默认网关、DHCP 下发的 DNS、访问控制设备和主路由策略。旁路由只接管部分设备或部分接口时，单台设备的结果不能代表整个局域网。
  4. QUIC：如果仅 UDP 443 失败，观察应用是否能回退到 TCP；若回退后网页可用，只能说明应用存在替代路径，不代表 UDP 问题已解决。

安全回滚与最小改动顺序

建议按以下顺序回滚，避免留下难以解释的混合状态：

  1. 恢复 UDP 转发端口、UDP 不转发端口、DNS、IPv6 和访问控制的原始值。
  2. 暂时关闭刚启用的 IPv6 TPROXY、流量嗅探或其他实验性选项，只保留一个简单的 IPv4 透明代理路径。
  3. 重启或重新应用 PassWall2，然后用同一设备和同一节点测试 TCP 与 UDP。
  4. 如果仍失败，再核对内核模块、核心启动日志和 nftables 规则，不要直接删除系统防火墙规则。
  5. 确认恢复后，再一次只开启一个功能，并记录开启前后的日志与规则差异。

如果切换到 TCP 节点后网页恢复，但 UDP 应用仍不能用，这通常只能说明 TCP 路径可用；如果切换节点、核心和防火墙模式后现象完全不变，才更值得检查客户端网关、固件内核或上游网络。上述判断属于排查顺序，不是对具体设备的确定诊断。

结论：按“节点—端口—核心—规则—DNS/IPv6”顺序最省时间

PassWall2 UDP 不通最有效的处理方式不是直接重装，而是先用同一节点区分 TCP 与 UDP，再检查 UDP 节点能力、UDP 转发和不转发端口，随后核对 TPROXY 模块、nftables 规则、核心日志，最后排除 DNS、IPv6 与旁路由路径。每一步都要保留原设置、只改一个变量，并用同一应用重复验证。

如果你还无法定位，可以整理以下信息再继续排查：固件版本、PassWall2 版本、使用的核心、TCP/UDP 转发方式、是否启用 IPv6 TPROXY、相关模块检查结果、复现时间点和脱敏后的日志。不要公开订阅链接、密码、私钥或完整节点配置。

常见问题

PassWall2 TCP 正常但 UDP 不通，最先检查什么？

先检查当前节点是否具备 UDP 转发能力，再检查 UDP 转发端口和 UDP 不转发端口。随后核对 TPROXY 相关模块与 nftables 规则，不要先假定是 DNS 或节点失效。

把 UDP 不转发端口设置为 53 能解决 UDP 问题吗？

它只会让指定 UDP 端口绕过代理转发，可能用于定位 DNS 回环或特定规则冲突，不能修复一般性的 UDP 出站故障。测试后应恢复原设置，并重新验证 DNS 与目标应用。

PassWall2 里能看到 UDP 端口监听，是否说明 UDP 已经正常？

不能。端口监听只说明本机有进程占用该端口，仍需确认客户端请求进入规则、核心完成出站并收到返回包。应结合日志、规则计数器和必要的短时抓包判断。

必须安装 kmod-nft-tproxy 和 kmod-nft-socket 吗？

不能一概而论。公开 Issue 中有固件因缺少相关模块而出现 UDP 透明转发失败的案例，但实际依赖取决于固件、防火墙后端和当前 PassWall2 配置。应先查看已安装包数据库与运行日志，再按当前固件仓库选择匹配版本。

只有 IPv6 网络下的应用不通，应该怎么做？

先做一次 IPv4 与 IPv6 对照，检查是否启用了 IPv6 TPROXY、节点是否支持 IPv6，以及客户端是否绕过路由器代理。临时关闭 IPv6 参与路径只能用于定位，验证后应根据日志和规则决定是否恢复。

相关阅读

参考资料

  1. PassWall2 项目仓库
  2. PassWall2 转发设置源码
  3. PassWall2 UDP 53 与 TPROXY 相关 Issue
  4. PassWall2 TPROXY 内核模块相关 Issue
  5. OpenWrt Firewall overview（openwrt.org）
  6. OpenWrt nftables 说明（openwrt.org）
  7. OpenWrt Netfilter Management（openwrt.org）
  8. OpenWrt 日志说明（openwrt.org）