症状排查闭环 规范排查流程
晚上网页经常转圈，先查什么：晚高峰连接故障全流程排查
典型用户症状：白天一切正常，但到了晚上 20:30 - 22:30，打开 Google、GitHub、Notion 等海外网页时加载条死死卡在头部，或者频繁报错 ERR_CONNECTION_TIMED_OUT。
🔍 可能引发该症状的底层技术原因
- 当前节点为普通公网中转或直连，遭遇晚高峰国际骨干网拥塞与丢包（丢包率 > 15%）
- 节点入口或出口服务器在晚高峰遭受大量并发冲击导致 CPU/带宽爆满
- 本地 Wi-Fi 2.4G 频段遭遇邻居信道干扰，引发本地物理丢包
- 客户端自动测速（URL-Test）失效，切换到了假活的失效节点
按步骤诊断与处理流程
1 第 1 步：排除本地 Wi-Fi 干扰
切换到 5GHz Wi-Fi 或插网线。打开命令行执行 ping 路由器网关 (如 192.168.1.1)，确认本地局域网无丢包且时延 < 3ms。
验证标准：本地局域网平稳后继续排查下一步。
2 第 2 步：测量应用层真实 HTTP 失败率
打开本站 HTTP 耗时诊断工具，连续发起 15 次受控测试。
验证标准：若失败率 > 0% 或中位耗时跳变超过 500ms，说明该节点已被晚高峰拥塞波及。 立即前往 HTTP 请求耗时测试 →
3 第 3 步：切换至纯内网专线节点 (IEPL/IPLC) 并比对
在客户端中切换至标有 IEPL/IPLC 的香港或日本专线节点，使用本站「我的连接对照」工具记录两轮差异。
验证标准：专线节点应在 15 次测试中维持 0 失败，且中位耗时稳定在 150-220ms 以内。 启动两轮连接对照 →
⚠️ 排查完成后的恢复建议
若切换节点后仍卡顿，请在客户端中重置代理规则分组为系统默认（Global/Rule 恢复），避免错误的自定义拦截规则导致请求被 drop。
工程师终端一键排查命令速查
若图形界面排查无果，可直接打开终端（macOS Terminal / Windows PowerShell）执行以下标准探测命令定位故障层级：
# 1. 验证本地局域网与网关连通性 (若时延 > 5ms 或丢包则为本地 Wi-Fi 故障) ping -c 4 192.168.1.1
# 2. 验证系统代理端口是否处于正常监听状态 (7890 端口排查) curl -Iv --proxy http://127.0.0.1:7890 https://1.1.1.1/cdn-cgi/trace
# 3. 验证远端 DNS 是否发生污染 (对比国外权威 DNS 返回 IP) nslookup www.google.com 8.8.8.8