香港cn2 晚上 抽风 导致访问不稳定的排查与解决建议

1.

概述与问题定位思路

- 目标：确定是链路拥塞、路由抖动、ISP策略还是目标侧问题。
- 思路：先本地排查→链路探测（延迟、丢包、抖动）→对比时间段（白天/晚上）→逐跳定位→与ISP沟通并验证修复。
- 要准备：终端能执行命令（Linux/Mac/Windows）、公网MTR/traceroute、iperf3、tcpdump、SSH与截图工具。

2.

准备工作：收集必需信息

- 收集时间段、影响范围（单IP/整站/部分用户）、开始时间、持续时长。
- 列出受影响的目标IP/域名、源IP、访问端口、协议（TCP/UDP/ICMP）。
- 保存基线：白天正常时的 mtr/traceroute、ping、http curl 响应时间作为对比。

3.

第一步：本地快速检测（3~5分钟）

- ping 目标 100 次：ping -c 100 <目标IP>，查看丢包率与延迟分布。
- traceroute/tracert：Linux 使用 traceroute -I <目标IP>（ICMP），Windows 使用 tracert。记录每跳延迟异常点。
- mtr（更细）：mtr -rwzbc 100 <目标IP>，导出结果用于分析丢包在哪一跳开始。

4.

第二步：持续观测/重现（10~30分钟）

- 使用 mtr --report-cycles 或 mtr -r -c 300 收集更长时间数据。
- 如果有多个出口，分别在不同出口、不同设备上测试以排除本地设备问题。
- 用 curl -I -v 或 wget 测试 HTTP/S 响应头与握手延迟，记录失败/超时信息。

5.

第三步：确认是否为夜间时段特有（对比分析）

- 比对白天与晚上 mtr/traceroute 的丢包/延迟差异。
- 检查是否每晚固定时间段（例如 20:00~02:00）发生，若是，倾向于链路拥塞或调度任务（ISP或目标网络）。

6.

第四步：深度排查：抓包与端口测试

- tcpdump 抓包（若能在源端）：sudo tcpdump -i eth0 host <目标IP> and port <端口> -w /tmp/cap.pcap，分析重传、RST 或长时间握手。
- 使用 iperf3 测试吞吐（若对端可配合）：iperf3 -c <目标> -t 60 -P 4，观察带宽波动。
- 检查 MTU/分片问题：ping -M do -s 1472 <目标IP> 检测是否存在分片导致延迟抖动。

7.

第五步：路由与BGP层面检测

- 使用公共 Looking Glass / routeviews：查看到目标的 BGP 路径是否有频繁切换。
- 在本地查看路由缓存：ip route get <目标IP> 或使用 bgp 工具（若为运营商/大型客户）。
- 若发现晚间路径切换频繁，可能是ISP做流量工程或对等关系不稳定。

8.

第六步：逐项排除本地设备与策略

- 检查防火墙/IPS：临时放通相关端口或禁用深度检测以排除误判丢包。
- 检查队列管理（SQM/HTB）与QoS策略是否在夜间触发限速。
- 交换机端口错误计数、CRC、丢包：查看 ifconfig/ip -s 或交换机 CLI。

9.

第七步：与ISP沟通的材料与步骤（模板化）

- 必备附件：mtr/traceroute（白天/夜晚）、tcpdump pcap、iperf 报告、故障发生时间段、受影响IP、影响范围截图。
- 在工单里明确要求：确认 PE-PE 链路拥塞、BGP 路由收敛、是否有流量清洗或策略。提供明确时间戳便于ISP查日志。
- 建议在工单中要求做 1) PE 抓包 2) 接口流量曲线 3) BGP 层面日志（邻居重启、Prefix Flap）。

10.

临时缓解措施（可快速实施）

- 切换到备用出口/备用线路（如果有多线路）并验证是否稳定。
- 使用第三方 CDN 或 TCP 代理（如 Cloudflare、加速器）把流量绕过受影响链路。
- 在应用层做重试策略：短连接重试、增加超时与指数退避，尽量减少用户感知。

11.

长期与架构级建议

- 多线路与多运营商冗余（CN2 与其它骨干混合），并配置智能路由切换（BGP with health-check）。
- 部署海外/香港节点的负载均衡+CDN，重要业务使用港澳独立链路或专线。
- 建立持续监控：Prometheus+Grafana 收集 ping/mtr/iperf 报表并设置告警。

12.

自动化监控与告警示例脚本

- 简单 cron 脚本：每 5 分钟运行 mtr -n -c 20 <目标IP> 并解析丢包阈值，超过 3% 发邮件/Webhook。
- 推荐指标：丢包>1%（长期）/瞬时丢包>5%/延迟跳升>100ms 为异常触发条件。

13.

与ISP谈判与升级时的策略

- 提供证据链（时间/数据/抓包）。请求将问题升级到 NOC/骨干维护组。
- 若是链路拥塞，要求 ISP 提供改路、扩容或 QoS 调整时间表以及临时流量工程方案。
- 若 ISP 主动更改路由或做 BGP 政策，要求变更窗口与回滚计划。

14.

常见误区与注意事项

- 不要只凭单次 ping 就结论，需用持续多次和多点对比。
- ICMP 丢包不总等于业务丢包，部分设备对 ICMP 限速，需结合 TCP 测试（curl/iperf）。

15.

常见问答一 - 为什么只在晚上抽风？

答：晚间通常是流量高峰，若上游骨干或 PE 口带宽接近饱和会出现排队丢包；也可能是 ISP 在夜间做流量工程或定时任务导致路径切换。需要用夜间/白天的 mtr/traceroute 对比证实。

16.

常见问答二 - 我不是网络工程师，如何快速给 ISP 提供有用信息？

答：准备三样核心文件：1) 夜间与白天各一份 mtr 报告（文字版），2) 若能抓包则提供 pcap，3) 明确影响时间段与受影响 IP 列表。清楚列出“复现步骤”和“期望处理”可大幅提高工单效率。

17.

常见问答三 - 临时最有效的应对方案是什么？

答：最快的应对通常是切换到备用出口或使用 CDN/加速器把访问绕开问题链路；同时向 ISP 提交带齐证据的工单并要求骨干抓包与流量图分析以完成根因修复。

来源：香港cn2 晚上 抽风 导致访问不稳定的排查与解决建议