PassWall2 节点延迟测试不准怎么办？按现象分层排查

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

简答：PassWall2 的延迟数值只能用于初步筛选，不能单独代表代理认证、TLS 握手、网页访问或持续下载体验。先固定同一设备、网络、测试地址和时间，再分别检查 DNS、TCP 建连、URL 请求、代理内核和真实业务；不要直接套用未核实的 test.sh 参数或固定核心路径。PassWall2 官方仓库确认其包含节点连通性测试，并建议通过 logread 与 /tmp/log/passwall2.log 排查；截至 2026-11-08，具体测试行为仍需结合你安装的版本与核心核对。

定义：PassWall2 节点延迟测试不准，是指列表中的测试结果与节点实际代理访问表现不一致，包括全部超时、单节点超时、低延迟但网页慢、实际可用却无延迟或数值波动明显。

先做四步速查：不要只看一次最低延迟

本文为使用指南站整理，不是 PassWall2 官方文档。PassWall2 官方仓库说明其具备节点延迟与连通性测试功能，同时列出了 curl、tcping、resolveip 等相关依赖；但不同 OpenWrt 构建、插件版本和代理核心可能存在差异，以下命令只用于只读诊断，不能替代 LuCI 中的实际配置核对。查看 PassWall2 官方仓库

现象	优先检查	不要直接得出的结论
所有节点都超时	路由器 DNS、时间、curl、资源占用、测试地址和日志	不能直接认定所有节点失效
只有一个节点超时	节点参数、协议、TLS、账号状态和目标端口	不能直接认定 PassWall2 测试程序故障
延迟很低但网页慢	URL 请求、TLS、代理认证、分流、持续速度和丢包	不能把 TCP 建连时间当成网页体验
实际可用但列表无延迟	测试方式是否支持该协议、mux、URL 和核心日志	不能直接删除节点或关闭 mux
数值波动大	测试时段、并发下载、路由器负载、丢包和抖动	不能只保留一次最低值

固定条件：同一台路由器、同一条上联网络、同一测试地址，暂停下载、云同步和其他代理。
先看日志，再看数值：执行 logread -e passwall2；若存在文件，再查看 sed -n '1,160p' /tmp/log/passwall2.log。OpenWrt 的 logread 用于读取系统环形日志，PassWall2 官方仓库也列出该日志位置。查看 OpenWrt 日志说明
分层测试：先确认 DNS，再确认 TCP/端口，之后做一次 URL 请求，最后用网页、视频或下载等真实业务验证。
记录中位数、最大值、失败次数和测试时间。重复 5 次可以作为本文的记录模板，但不是 PassWall2 官方阈值，也不能据此承诺节点可用。

回滚：本节没有修改配置、规则、DNS、核心参数或文件，因此通常不需要回滚。若你为了排查临时开启了调试日志，完成后回到 LuCI 的日志设置关闭即可。

先分清 Ping、TCPing、URL 和真实业务测的是什么

Ping主要观察 ICMP 往返时间，但目标可能禁用 ICMP，或者实际代理链路根本不使用同一目标，因此 Ping 超时不等于节点一定不可用。

TCP 测试主要回答“到某个地址和端口能否建立 TCP 连接”。它不能证明代理认证成功，也不能证明 TLS、WebSocket、HTTP 请求或后续传输正常。

URL 测试会进一步涉及 DNS、TCP、TLS、HTTP 请求和可能的代理配置，因此更接近访问场景；但测试地址自身不可达、证书校验、重定向、分流规则或路由器上的 curl 异常，都可能造成误判。curl 官方文档明确区分连接耗时、TLS 握手耗时、响应状态码和下载速度；HTTP 返回 404 或 500 也不必然代表 curl 传输失败，不能把“非 200”简单当成成功或失败。查看 curl 官方参数说明查看 curl 官方 FAQ

真实业务验证才是最后一层：检查目标网页是否完整打开、登录或 API 请求是否成功、视频是否持续缓冲、下载速度是否能维持。低延迟但网页慢，可能发生在 TLS、代理认证、分流、首字节响应或持续传输阶段，而不一定是 TCP 建连本身。

按现象排查：OpenWrt 上的只读诊断步骤

一、所有节点都显示超时

确认路由器时间和时区基本正确。系统时间明显错误时，TLS 证书校验可能失败。
确认命令是否存在：command -v curl; command -v nslookup; command -v tcping。没有命令时不要直接复制其他版本的测试脚本参数，应先通过当前固件的软件包管理器和 PassWall2 依赖状态核对。
测试 DNS：nslookup example.com。把 example.com 替换成你有权访问、且从路由器网络可达的测试域名。若 DNS 失败，先处理 DNS，不要先换节点。
测试普通 HTTPS 请求：curl -L -o /dev/null --connect-timeout 8 --max-time 20 -w 'code=%{response_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n' https://example.com/。成功判据是命令完成并返回可解释的状态码与耗时；状态码本身不能单独作为“节点好坏”结论。
查看资源和日志：logread -e passwall2，并观察日志中是否出现核心启动失败、配置解析失败、DNS、TLS、超时或端口占用关键词。

可能分支：如果路由器直连 HTTPS 都失败，优先查上联、DNS、时间或测试地址；如果直连成功但 PassWall2 测试失败，再核对节点协议、核心、分流和测试请求是否真的经过代理。

二、只有某个节点异常

重新核对服务器地址、端口、UUID 或密码、TLS/SNI、Path、传输方式和协议字段。不要把 Xray 的临时配置命令套到 sing-box，也不要假设核心固定在 /usr/bin/xray；PassWall2 官方源码显示其会按节点类型生成不同核心配置，实际使用的核心和路径需从日志、进程或当前配置中确认。查看 Xray 配置生成源码查看 sing-box 配置生成源码

三、节点实际可用，但列表没有延迟

先不要删除节点，也不要盲目关闭 mux。PassWall2 官方 issue 中确实有人提出 mux 节点的 URLTest 可靠性问题，但这是特定版本、协议和配置下的功能请求，不等于所有版本都存在同一缺陷。应记录 PassWall2 版本、OpenWrt 版本、核心、节点协议、mux 状态和日志，再到官方仓库核对当前 issue 或修复状态。查看官方 mux URLTest issue

四、延迟很低但网页仍然慢

把列表延迟降级为初筛指标，继续检查 URL 请求耗时、TLS 握手、首字节响应、持续下载速度、丢包和分流。若仅有部分域名慢，优先检查 DNS 与规则；若所有业务都慢，检查节点负载、路由器 CPU/内存、上联带宽和高峰时段。不要用一次低延迟结果推导长期稳定性。

五、怀疑 FakeDNS、规则或代理未接管

分别验证“路由器自身请求”“局域网设备请求”“目标域名是否命中代理规则”和“出口地址是否变化”。只看 PassWall2 节点列表无法证明终端设备已经经过代理。需要临时修改规则时，先导出或备份当前配置；完成测试后恢复原规则，不要裸删 geoip.dat、geosite.dat 或未知符号链接。

记录模板：把“不准”变成可复核证据

建议为每个节点记录以下字段，而不是只保存一个延迟数字：

日期与时间：使用固定格式，例如 2026-11-08 21:00，并注明是否高峰。
环境：路由器型号、OpenWrt 版本、PassWall2 版本、Xray 或 sing-box 版本、上联方式。
测试条件：设备、网络、测试域名、是否启用 mux、是否启用 FakeDNS、是否使用旁路由。
结果：测试是否完成、状态码、DNS 耗时、TCP 连接耗时、TLS 耗时、总耗时、失败次数和日志关键词。
真实业务：网页是否完整打开、API 是否成功、视频是否持续播放、下载是否能维持，而不是只写“感觉快”或“感觉慢”。

如果需要重复测试，可以用 5 次作为一个便于人工比较的样本组，再记录中位数和最大值；这只是本文的记录建议，不是 PassWall2、OpenWrt 或任何节点服务的合格线。最终选择主用节点时，应综合连通率、抖动、丢包、持续速度和真实业务结果。

结论：延迟测试适合初筛，不适合单独验收

PassWall2 节点延迟测试“不准”，多数时候不是一个数字就能解释的问题。先判断是全部超时、单节点异常、实际可用但无延迟、低延迟却慢，还是结果波动；再按 DNS、TCP、URL、代理核心和真实业务分层验证。

截至 2026-11-08，PassWall2 官方仓库确认了节点测试、日志位置和相关依赖，但没有在所核对的资料中给出适用于所有版本的统一延迟阈值、固定测试次数或通用的 test.sh 参数。因此，无法核实的脚本调用、核心路径和“达到某数值就合格”的说法都不应直接复制执行。

常见问题

PassWall2 延迟很低，为什么网页还是慢？

列表延迟通常只覆盖某一层连接测试，未必包含代理认证、TLS、分流、首字节响应和持续传输。应继续用固定 URL 检查总耗时，并用网页、视频或下载做真实业务验证。

PassWall2 所有节点都超时，是不是节点全部失效？

不能直接这样判断。先检查路由器时间、DNS、curl 是否存在、测试地址是否可达、CPU/内存和 PassWall2 日志；如果路由器自身的 HTTPS 请求也失败，应先排查本地网络。

可以直接执行 /usr/share/passwall2/test.sh url_test_node 吗？

不建议直接执行。本文没有核实该参数格式、节点 ID 获取方式和当前版本兼容性；应先查看当前安装版本的脚本帮助、LuCI 调用方式或源码，不能把其他版本示例当成通用命令。

节点实际可用但 PassWall2 显示超时，应该关闭 mux 吗？

不要盲目关闭。官方 issue 中有关于 mux 节点 URLTest 可靠性的特定功能请求，但是否影响你的版本、协议和核心需要单独核对。先记录版本、节点协议、mux 状态和日志，再决定是否调整。

PassWall2 测试多少次才算准确？

PassWall2 官方资料中未核实到统一测试次数或合格阈值。可以把 5 次作为本文建议的记录样本，但应保存中位数、最大值、失败次数和测试时间，不能把它当成官方标准。