首先要做的是对目标IP/域名做基础网络探测,判断链路是否通、延迟和丢包是否在可接受范围。常用工具包括 ping、traceroute(或 tcptraceroute)、mtr。
建议的步骤:1) 使用 ping -c 20 <目标IP> 测量平均延迟和丢包率;2) 使用 mtr -r -c 100 <目标IP> 进行往返和逐跳丢包观测;3) 使用 tcptraceroute 或 traceroute -T -p 443 来模拟TCP三次握手路径,避免ICMP被限流带来的误判。
判断标准示例:平均延迟 < 100ms、单跳丢包持续>5%需要关注、频繁抖动(jitter)说明链路不稳。若出现完全不可达,应进一步确认DNS解析和目标端口是否被拦截。
ping -c 20 1.2.3.4
mtr -r -c 100 1.2.3.4
tcptraceroute 1.2.3.4 443 或 traceroute -T -p 443 1.2.3.4
ICMP 丢包不等于 TCP 不通,但若 TCP traceroute 也在某跳被截断,说明中间存在策略或防护设备干预。
在对高防节点测试时避免短时间内大量并发探测以免触发防护策略,尽量控制测试频率并与运维沟通。
应用层检测能直接说明 CDN 节点对业务的真实响应情况。推荐使用 telnet(简单判断)、openssl s_client(SSL/TLS 握手)和 curl -v(HTTP 完整交互)。
步骤:1) telnet <目标IP> 80/443 检查是否能建立 TCP 连接;2) openssl s_client -connect <目标IP>:443 -servername <域名>,查看证书链、SNI 是否成功;3) curl -I --resolve <域名>:443:<目标IP> https://<域名>/ 检查返回头与状态码。
若 TCP 可建联但 TLS 握手失败,可能是 SNI 或证书绑定问题;若 HTTP 返回 403/503,可能是高防策略或白名单限制。
telnet 1.2.3.4 443
openssl s_client -connect 1.2.3.4:443 -servername www.example.com
curl -I --resolve www.example.com:443:1.2.3.4 https://www.example.com/
成功:TCP 三次握手正常,TLS 握手完成并返回有效证书,HTTP 200/206。异常:SSL 握手超时、证书不匹配、HTTP 403/503 常提示第三层或WAF策略拦截。
在测试 HTTPS 时务必带上正确的 SNI,否则 CDN 多宿主场景会返回默认证书或错误响应。
长时测试能揭示防护设备在高并发或长期小包流量下的行为。推荐使用 mtr(长时模式)、iperf3(带宽/丢包)和持续的 ping 记录。
实施方案:1) 在测试端运行 mtr 连续 1 小时以上(mtr --interval 1 -c 3600);2) 使用 iperf3 -c <目标> -t 300 测试 TCP 性能,再用 UDP 模式(-u -b <带宽>)测试丢包;3) 在多个不同公网出口或第三方探针(如 RIPE Atlas、第三方 VPS)上并行测试,确认是否为单点问题。
如果在高负载或短时突发下出现丢包上升或连接被重置,可能是高防设备触发流量阈值或连接数限制。
mtr --interval 1 -c 3600 1.2.3.4
iperf3 -c 1.2.3.4 -t 300
iperf3 -c 1.2.3.4 -u -b 50M -t 120
稳定性评估以丢包率、平均 RTT、抖动变化趋势为主。若丢包随流量增长明显上升,应怀疑防护阈值或QOS策略。
长时测试需提前与对端或CDN运营沟通以避免被误判为攻击,并建议在非峰时段开展大流量测试。
路由层分析依赖 traceroute、AS 路径查询和 Looking Glass(LG)/BGP 路由查询工具。通过比对多点路由信息可以判断是否经过 CN2 专线。
步骤:1) 使用 traceroute/tcptraceroute 从多个地域(美东/美西/国内不同运营商出口)探测路径;2) 在 BGP 查询网站(如 bgp.he.net、Hurricane Electric)或运营商 Looking Glass 上查询目标 IP 的 AS 路径和路由公告;3) 若路径在中间出现“电信专线”跳数少且延迟低,且 BGP 列表中显示 CN2 相关策略路由,基本可以判定为走 CN2。
注意:CN2 的判定并非单靠跳数,有时需要运营商提供的节点名单或 CDN 厂商确认。
traceroute -T -p 443 1.2.3.4
在 bgp.he.net 输入目标 IP 查看 AS Path 和 geolocation
CN2 路径通常表现为跨境延迟更稳定、回程对称更好。但若中间存在防火墙或高防集群,traceroute 可能在某跳变为不可见,应结合多点数据判断。
若需法律或合规层面的路由确认,请通过正式渠道向 CDN 或承载运营商索取证书或路由清单。
当发现连接异常时,应按标准故障单流程排查:确认范围、复现、定位、缓解、根因与恢复。
具体流程:1) 确认影响范围(是否所有用户或部分IDC/ASN);2) 用不同出口与第三方探针复现问题并收集 pcap、mtr、traceroute、curl -v 等日志;3) 检查是否触发 WAF/高防 策略(如大量 SYN/短时请求、异常 User-Agent、速率超标);4) 临时缓解:降低探测速率、临时放行源IP到白名单或调整防护策略;5) 将采集到的证据提供给 CDN/高防 运维,要求协同回溯并调整规则。
修复建议包括:合理分散探测节点,调整并发与速率策略,使用合法认证的探测账号或白名单,必要时由 CDN 提供流量/防护日志以定位触发规则。
tcpdump -i any host 1.2.3.4 and \(tcp or icmp\) 抓包

提供:mtr 长时报告、traceroute/tcptraceroute 路径、curl/openssl 输出、应用访问日志与时间戳
针对误判常见措施为:临时宽松策略、白名单、速率分段、细化WAF规则(基于URI/请求头/来源IP),并在修复后恢复严格策略并进行回归测试。
与 CDN/高防 协同排查时务必同步时间精度(NTP)并提供完整时间线,避免因时间偏差导致日志对不上。