1. 概述：先确认问题范围与影响面

- 确认受影响的客户端/服务器、时间段与具体目标（例如：日本某 IP/域名）。
- 明确是所有流量受影响还是仅 SS（Shadowsocks）流量、TCP 或 UDP。
- 记录发生时段（精确到秒）和至少 3 个发生样本，以便复现与提交运营商工单。

2. 收集基础信息（必须）

- 在客户端/服务器上记录公网 IP、路由表（ip route）、默认网关、网卡名称。
- 保存 SS 服务端/客户端配置（端口、加密方式、udp_enabled、plugin 等）与日志（通常在 /var/log 或 systemd 日志）。
- 获取重现时刻的 ping/traceroute/mtr 输出，最好包含 -c（次数）和 -r（报告）参数，例如：mtr -r -c 100 1.2.3.4。

3. 使用逐跳检测定位丢包点（MTR / traceroute）

- 在受影响机器运行：mtr -r -c 100 <目标IP>，观察每跳的丢包率与延迟；若某一跳丢包高且后续跳维持，则该跳有问题。
- 若是 ICMP 被限制造成假阳性，换用 TCP 模式：mtr --tcp -P 443 <目标IP> 或使用 tcptraceroute。
- 记录时间戳与 hop IP，截图或保存到文件（mtr -r -c 100 > mtr.txt）。

4. 使用 ping / iperf3 进行链路稳定性与带宽测试

- ping -i 0.2 -c 200 <目标IP>，观察间歇性丢包与延迟抖动（jitter）。
- 若可控部署，使用 iperf3：在日本节点启动 iperf3 -s，在客户端运行 iperf3 -c -t 60 -i 10，观察吞吐、丢包（UDP 模式需加 -u）。
- 对比 SS 隧道内外的速率（直接对比能判断是否在加密/隧道层发生问题）。

5. 抓包分析（tcpdump / Wireshark）定位协议问题

- 在客户端或服务器上抓包：tcpdump -i eth0 host <目标IP> and \(tcp or udp\) -w capture.pcap。记录发生问题的时间段。
- 在 pcap 中查看重复 ACK、重传、ICMP Fragmentation Needed、TCP RTO 等信号。若看到大量 TCP Retransmissions，说明链路质量或 MTU 问题。
- 对于 SS（通常加密后为 TCP/UDP），也要抓取本地加密流量与解密后文件（需在服务端同时抓包）做对比。

6. 检查本地/服务器资源与 SS 程序状态

- 查看 CPU、内存、I/O：top/htop、vmstat、iostat，确认是否因资源耗尽导致丢包或响应慢。
- 检查 SS 服务端（ss-server、ssr、v2ray 等）日志：journalctl -u ss.service 或 /var/log/xxx，关注“connection reset”“timeout”等错误。
- 如果使用 UDP 转发，确认内核 UDP 缓冲区是否饱和：ss -s、netstat -su。

7. 内核与网络参数调优（实操命令）

- 临时生效（测试用）： sysctl -w net.ipv4.tcp_congestion_control=bbr sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_max=16777216 sysctl -w net.ipv4.tcp_mtu_probing=1
- 永久写入 /etc/sysctl.conf 并 sysctl -p。
- 若怀疑 MTU 导致分片/丢包，可在客户端或路由上设置 MSS clamp：iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu。

8. Shadowsocks 层面的优化与替代方案

- 优先使用稳定高效加密：aes-256-gcm 或 chacha20-ietf-poly1305；避免同时大量连接导致 CPU 瓶颈。
- 若丢包严重，考虑使用 UDP 转发/obfs 或 v2ray 的 mKCP，以在不稳定链路上提高容错（需测试，某些运营商对 kcp 有限速）。
- 开启 keepalive（timeout/fast_open）与调整并发限制，避免短时间大量连接导致的拥塞。

9. 与运营商沟通的正确方式和材料准备

- 提交工单时附上：mtr/traceroute 输出、tcpdump pcap（压缩）、发生时间戳、源/目的 IP、期望路由（若有）。
- 明确提出“请核查 CN2 专线到日本的 XX 路径在北京时间 XX 时段是否有丢包/丢包率统计”，并附上 hop IP 与 mtr 报表。
- 运营商常会要求重现步骤与时间窗口，保证在同时间段内持续抓包与 mtr。

10. 常见快速排查清单（Checklist）

- 验证是否为本地网络或 Wi‑Fi 问题（切换到有线或不同出口测试）。
- 比较不同时间段与不同目标（多个日本节点）以判断是否为局部节点问题。
- 若问题只在 SS 链路，先切换为直连或其他代理（v2ray/SSR）验证是否仍然丢包。

11. 问：如果 MTR 显示某跳大量丢包，但随后跳没有丢包，是否可以忽略？

答：不一定可以忽略。部分路由器对 ICMP 采样率低，会在路由器本身显示丢包但并不影响转发；判断要看后续跳是否延迟/丢包也高。如果后续稳定，多为该跳对 ICMP 限制，可关注实际业务流（TCP 传输是否有重传）。建议同时用 TCP 模式 mtr 或直接进行 TCP/UDP 业务测试。

12. 问：出现间歇性丢包，应该先联系运营商还是先调整参数？

答：先做好数据收集（mtr、ping、tcpdump、时间戳）并排查本地资源/配置（MTU、sysctl、SS 日志）。若本地排查无果，带上收集到的证据再联系运营商，提高问题定位效率。若业务紧急可同时并行调优与提交工单。

13. 问：调整内核参数后仍有丢包，有没有进一步建议？

答：可尝试：1) 更换日本目标节点或不同 CN2 机房对比；2) 在不同时间段连续抓包并比对；3) 使用多家 VPS/运营商做 cross-test；4) 将抓到的 pcap 与运营商工程师一起分析，确认是否为链路物理问题或中间策略丢弃。必要时考虑更换传输协议（如 mKCP、QUIC）或迁移到更稳定的线路供应商。

文章标签：cn2 链路 丢包 MTR 排查 MTU 调优 Shadowsocks 链路 优化 tcpdump 分析 日本 cn2 ss 链路 排查 更多»

来源：如何排查日本 cn2 ss 链路问题 提高连通性和降低丢包率的步骤