一分钟自测：先确认协议，再查三项

自测的目标不是把链路调到最优，而是先定位问题出在哪一层。协议层、链路层与本机层，处理方式完全不同。

能定位的三件事

当前用的哪种协议、掉速发生在哪一层、换档之后是否恢复。这三件事决定了要不要联系支持、联系谁。

做不到的两件事

无法提升物理带宽上限，也无法绕过目标站点的出口策略。前者由宽带决定，后者由目标方决定。

• 整个过程不需要安装额外工具，客户端诊断页已包含全部读数。
• 进阶判据需要命令行，Windows 用 PowerShell、macOS 与 Linux 用终端，命令在对应小节给出。
• 所有读数建议记录两次，间隔至少 10 分钟，单次读数不可信。

判据按可靠性排序：面板最直观，端口表最准确，抓包特征最硬，握手耗时最省事。任选两个交叉验证即可。

大多数人只需要前两条。第三条适合排查「面板说用的是 A，实际跑的是 B」这类异常；第四条适合在没有工具的环境里快速判断。

最快的一条，两秒出结果。面板第一行会同时显示协议、端口与传输层，三个值要一起看。

这一条几乎不会骗人：连接表里对端端口与传输层是内核记录的事实，不是界面文案。

1. Windows：在 PowerShell 执行 netstat -ano | findstr ESTABLISHED。看对端 443 与高位 UDP 端口。
2. macOS 与 Linux：执行 ss -tunp 或 netstat -an | grep ESTABLISHED。关注 UDP 行。
3. 对端端口 443 且为 TCP：Trojan（也可能是 OpenVPN TCP 模式，看是否有 TLS 记录）。
4. 对端为 UDP 高位端口：Hysteria2 或 WireGuard，再按是否有 TLS 记录区分。
5. 对端 51820/UDP 或自定义高位 UDP：WireGuard。对端 UDP 443 且带 QUIC 特征：Hysteria2。

抓包是最硬的判据，四种协议的首包差异明显。下面给出每种协议一眼能认的特征。

抓包命令分三平台。Windows 用 pktmon 或 Wireshark，macOS 用 sudo tcpdump -i en0 -n udp or tcp port 443。Linux 用 sudo tcpdump -i any -n。抓 10 秒足够，体积约 2 MB。

没有工具时，用握手耗时倒推协议。本文的数值区间在三个出口上都验证过，误差 ±6 毫秒。

• 用诊断页的「三条链路复测」就能拿到首包耗时，不需要抓包。
• 同一出口重复三次取中位，单次读数受调度影响可能偏差 10 毫秒以上。
• 不同出口的区间要按往返时延等比换算，东京乘 1.08，洛杉矶乘 3.8。

三项按顺序查，因为它们的排查成本递增、误判概率递减。前两项在客户端内就能看到，第三项需要一次对照实验。

MTU 问题的典型特征是「小包正常、大包异常」。ping 一个大包即可验证，不需要专业工具。

1. Windows 执行 ping -f -l 1472 目标地址。Linux 与 macOS 执行 ping -M do -s 1472 目标地址。
2. 若提示需要分片或超时，把 1472 依次减到 1442、1412、1382，直到能通。
3. 能通的值再加上 28 字节的开销即为实际 MTU，例如 1412 + 28 = 1440。
4. 把实际 MTU 减去隧道封装开销（WireGuard 60 至 80 字节）即为客户端应设的值。
5. 设置后复测一次大文件传输，看重传率是否下降。

实测对照：MTU 从 1,420 降到 1,280 时，大文件传输的有效吞吐下降 11%。重传率从 0.3% 升到 1.9%。这个代价在下载 10 GB 文件时相当于多花 7 分钟。

丢包分三段：本地无线、运营商出口、跨境段。三段的排查方式不同，误判最容易发生在把本地问题当成跨境问题。

这是唯一需要「切换一次」的排查。判断标准很简单：切到 Trojan 后速度是否回升到带宽的 50% 以上。

1. 在当前协议下跑一次 60 秒单流测速，记录读数。
2. 切到 Trojan（443/TCP），等 10 秒，再跑一次同样的测速。
3. 若读数提升到原来的 3 倍以上，判定为 UDP 限速，长期固定 Trojan。
4. 若无变化，说明不是 UDP 限速，回到 MTU 与丢包两项复查。
5. 若 Trojan 反而更慢，说明 TCP 侧也有策略限制，考虑用 Hysteria2 的混淆模式。

把前面所有读数汇总成一张表，左边的组合对应右边的动作。表中覆盖 89% 的现场情况。

判读时先看两列的配合关系。丢包 2% 以上而吞吐仍在带宽的 70% 以上，说明链路尚可，只是协议不够抗丢包。丢包低于 0.5% 而吞吐只有 8%，则与协议无关，去查 MTU 与 UDP 限速。这两种情况的采样条件相同，动作完全不同。

• 实测对照：同一条香港线路，WireGuard 在 3% 丢包下吞吐 318 Mbps，切到 Hysteria2 后 588 Mbps。采样条件与本文表 7 一致。
• 若两次复测的读数差异超过 15%，先怀疑测量环境，例如后台更新或无线干扰，而不是先改客户端设置。

单次读数没有意义，能对比的读数才有。复测的关键是固定变量：同一节点、同一时段、同一测速目标。

• 同一节点：换节点后读数不可比，因为落地与回程都变了。
• 同一时段：跨越晚高峰的两次读数不可比，跨境丢包有明确的时间规律。
• 同一目标：测速目标服务器不同会引入额外变量，建议固定一个纯 IP 目标。
• 同一时长：60 秒单流是本文的统一口径，10 秒的读数受慢启动影响偏乐观。
• 记录三次取中位：单次读数受系统调度影响，三次中位更稳。
• 把每次复测的协议与节点写进文件名，例如 1031-TYO03-hy2.csv，两周后仍能一眼对上。
• 复测前后各拍一张诊断页截图，图片比文字更容易看出哪一列发生了变化，也便于发给支持人员。

单次测速时长

60 秒单流

复测间隔

至少 10 分钟

读数取值

三次中位

记录方式

CSV 导出

对比基准

同一节点同一时段

下表只列必要的命令，全部为系统自带工具，不需要安装。执行前确认已连接到目标节点。

• 抓包需要管理员或 root 权限，普通权限下会提示无法打开设备，这不是工具故障。
• 测 MTU 时目标地址应选一个可达的境外 IP，用本地网关测出来的值偏大。
• 查 DNS 时若返回的是客户端内置的解析地址，说明接管正常，不必再改系统设置。
• 看 CPU 时关注单核而不是总占用：OpenVPN 的瓶颈永远是单核，总占用 25% 也可能已经打满一个核。

命令执行完把输出复制到诊断日志的备注里，后续对比时能直接看到当时的原始状态，比回忆「当时好像挺慢」可靠得多。

这些做法看起来像在排查，实际上在制造新的变量，让问题更难定位。

还有一个容易忽略的变量是时间本身：同一台机器在不同日期的手握耗时可能相差 10 毫秒以上。服务端版本、内核与拥塞算法都会变。因此本文给出的都是区间而不是单点值，判断时看是否落在区间内，不要追求精确复现某一个数字。

• 四个判据
• MTU 分片
• 丢包三段
• UDP 限速
• 判读表
• 固定变量复测

自测完成之后，如果结论是「协议不匹配网络」，去四协议对照表找合适的档位；如果是「选路没选对」，看选路与线路里的阈值说明。