延迟高与丢包排查：区分 Wi-Fi、线路和目标服务

“能用但很慢”不能靠一个测速数字定位。视频可能受到目标 CDN 限制，网页可能慢在 DNS，游戏则更容易受抖动和丢包影响。先说明哪种操作卡住，再做少量有对照的测试，通常比一次测完上百个节点更有用。本文没有给任何服务商做实测排名；所有命令都是你可以在本机复现的诊断方法。

先把症状分成四类

现象	需要重点观察	最先做的对照
点击后等待很久，开始传输后正常	解析、连接、TLS、首字节等待	同一页面直连与代理、不同节点
下载开始快，随后持续降速	吞吐、拥塞、服务端限制	同一文件、同一时段、另一节点
语音断续、游戏忽快忽慢	抖动、应用协议、连接稳定性	有线与 Wi-Fi、不同网络
国内和代理网站都慢	局域网、宽带、设备负载	关闭代理后的正常直连访问

记录问题开始时间和时区、接入网络、是否晚高峰、是否正在备份或下载。测试期间暂停自己设备上明显的后台大流量任务，避免改变多个变量。

第一步：排除本地网络和设备负载

先关闭 TUN 和系统代理，按原网络方式访问两个平时可直连的网站。若它们也慢，先处理 Wi-Fi、路由器、宽带或终端问题。改用网线或靠近路由器做一次对照，并查看电脑 CPU、内存和网络使用情况；内核 CPU 持续满载也会影响代理表现。

在网络详情中查看实际默认网关，再测试到它的连通性。192.168.1.1 是地址示例，不能假定每台路由器都使用它。

# Windows：先从 ipconfig 找到当前网卡的默认网关
ipconfig
ping -n 20 192.168.1.1

# macOS：查看默认路由；Linux 通常可用 ip route
route -n get default
ping -c 20 192.168.1.1

连续请求出现明显超时或波动时，先用有线重测。网关也可能限制 ICMP，因此一次 ping 异常只是线索；应结合有线对照和实际网页表现。ping 测的是 ICMP 往返，不经过普通 HTTP/SOCKS 代理，不能用它直接代表代理出口延迟。Microsoft ping 说明

第二步：建立同条件的节点对照

恢复一个代理客户端，使用平时的规则模式。在客户端选择一个具体节点，确认受影响目标命中预期出站；自动策略组可能在测试中切换节点，做对照时应固定选择，测试后再恢复。

选择同一 HTTPS 目标，对每个节点执行三到五次实际请求，至少对比两个节点。不要把不同客户端、不同测试 URL 或 TCPing 与真连接结果混在一起排名。mihomo 的“统一延迟”等设置会影响计时口径，比较时也应保持一致。mihomo 全局配置说明

下面只请求小页面并输出时间，不是带宽测速；端口和目标按实际情况更换：

# macOS / Linux；Windows 用 curl.exe，并将 /dev/null 改为 NUL
curl -q --proxy http://127.0.0.1:7890 --noproxy localhost --connect-timeout 10 --max-time 30 --silent --show-error --output /dev/null --write-out 'http=%{http_code} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' https://example.com/

时间单位为秒，字段是从请求开始计时的累计值。经本地 HTTP 代理时，time_connect 主要反映到本地代理的 TCP 连接；TLS、首字节与总时间还包含后续路径及服务端处理，不能把相邻字段简单解释成某一段国际链路的精确延迟。http=000 通常表示未获得 HTTP 响应，应同时查看错误输出。curl 时间指标定义

-q 放在第一个参数位置，跳过默认 curl 配置文件，保持本次显式参数的测试口径。三到五次请求用于快速定位；需要据此比较或提交记录时，使用 20 次采样与 CSV 保存步骤，同时保留失败数。请求已经超时，即使输出了较短的首字节时间，也不能当作完整成功样本。

第三步：用四组对照缩小范围

每组只改一个条件，重复原来的操作：

1. 同网络、同目标、换节点：仅一个节点反复慢，优先检查该节点或它到目标的路径；可暂时切换其他节点。
2. 同网络、同节点、换目标：只有单个服务慢，检查该服务状态、出口地区与 CDN 路径。其他网站正常不能保证目标服务也正常。
3. 同设备、同节点、换接入网络：手机热点明显改善，范围缩小到原接入网络及其到入口的路径；注意热点测试流量费用。
4. 同网络、同节点、换时段：白天与晚间重复，不同日期再复核。高峰慢是拥塞线索，单次结果不能证明服务商超售或宽带运营商责任。

节点名称上的城市或“专线”标签不等于真实物理路径；距离近也不必然更快。线路类型的解释见 IEPL 原理与限制，长期比较应按线路性能测试方法记录。

第四步：按证据选择修复动作

• 局域网对照异常：优先使用有线、改善信号、减少本地并发；重启个人路由器前确认不会中断他人的必要连接。
• 只有一个节点异常：临时切换已验证可用的节点，将复现记录发给服务商。
• 目标错误直连或意外绕路：检查连接列表，修复对应规则或策略组，测试后恢复日常模式。
• 所有节点仅当前网络异常：检查路由器的 VPN、过滤、DNS 或多层代理；每次只停用一个个人配置进行比较，并恢复无效改动。
• 只有某个应用异常：检查该应用所需协议与客户端支持；系统代理不会自动接管所有 UDP 流量，详见系统代理排查。

下载卡住并不自动意味着 MTU 有问题。没有分片、路径或应用证据时，不要随意修改 MTU、TCP 注册表和全局拥塞参数；这些改动会扩大排查范围。

成功验证与记录模板

回到原应用执行相同任务：网页多次打开、视频连续播放或语音实际通话，并在原来容易出问题的时段复测。修复的目标是任务稳定完成，不是追求某个通用延迟阈值。保留以下记录即可，不必长时间消耗流量跑满带宽：

时间与时区	网络 / 连接方式	节点代号	目标 / 测试方式	结果	本次唯一改动
按实际填写	宽带 / 有线或 Wi-Fi	用代号，不放凭据	相同页面或应用任务	成功次数、错误及耗时范围	例如只换节点

这是一张空白记录模板，不是本站测速结果。恢复临时固定的策略组、日志级别及网络设置。求助时提供上述表格、客户端与内核版本、脱敏错误日志，并说明哪些对照已经排除；不要只发一张没有时间和测试目标的延迟截图。