如何实测香港服务器CN2与CMIN2的回程路由节点？

实测香港服务器 CN2 与 CMIN2 的回程路由，应当从香港服务器向中国内地的电信、联通、移动测试点发起探测，记录经过的公网跳点，再结合跳点所属网络、目的端时延、丢包和晚高峰表现判断。内地电脑向香港服务器执行一次 traceroute，主要观察的是去程，不能直接证明香港服务器的回程线路。

下面以 Debian、Ubuntu 系香港 Linux 服务器为操作环境，使用 traceroute、mtr 和 ping 完成节点采集，并用 TCP 探测和实际业务请求交叉验证。测试需要两台待比较的香港服务器、经过授权的内地测试点，以及相同的采样安排；不需要修改生产路由，也不应为完成测试而关闭防火墙。所有结果表和输出片段均用于说明记录方法，不代表 A5IDC 或某一产品的实际测试成绩。

面向香港服务器承载内地访问业务的场景，A5数据提供香港物理服务器租用，涵盖CN2线路与国际带宽等不同产品方案，为跨境访问提供网络资源基础。其香港产品覆盖入门建站、Xeon Gold及AMD EPYC平台，配有SSD或NVMe存储，部分配置提供大容量内存，可承载企业网站、业务后台、数据库和接口服务，将网络线路与应用运行所需的计算、存储资源衔接起来。

一、准备测试环境：把服务器、目的地和指标对应起来

1. 确认两台服务器的比较条件

将待测服务器分别标记为 HK-CN2 和 HK-CMIN2，标签只代表待验证的线路声明，不代表已经确认了实际路径。

测试前保存以下信息：

优先比较规格接近、没有限速状态的服务器。如果两台机器的带宽不同，仍可比较路由和时延，但不要直接用下载速度推断线路优劣。

IPv4 与 IPv6 必须分开测试。下文命令以 IPv4 为例，不能用 IPv4 的结果替代 IPv6 验收。

2. 准备内地测试点

基础测试至少覆盖电信、联通、移动各一个公网目的地址；需要评估跨地区业务时，再扩展到华南、华东、华北等主要用户区域。

测试点应满足以下条件：

• 由自己管理或已获得测试授权，能够确认其实际运营商。
• 公网地址在采样期间保持稳定。
• 若进行 TCP 探测，使用已开放、允许测试的真实业务端口。
• 能观察目的主机负载，排除主机自身异常。
• 尽量直接使用公网 IP，避免域名解析到 CDN 或其他入口。

公网 DNS 地址可以辅助排查，但不宜作为唯一目的地：任播地址可能在不同位置响应，且其 ICMP 策略未必代表普通业务网络。家庭宽带若不能接收入站探测，也不要直接探测其私网地址或为了测试临时暴露管理服务；应更换已授权、可达的目的主机。

3. 设定采样计划

可以从以下验收采样规模开始，再按业务重要性增加：

• 连续采样 3 天，覆盖工作日。
• 每天安排业务低峰、日间和晚高峰三个窗口，例如北京时间 09:00、15:00、21:00。
• 每个目的地执行 100 次 ICMP 探测，并补充 100 次 TCP 路径探测。
• 两台香港服务器在相同窗口测试相同目的地，尽量同步开始。
• 单台服务器顺序测试，避免同时对大量地址发包。

这些数量是操作建议，不是线路合格标准。100 次采样只能反映该窗口的表现，不能据此承诺全天质量。不同目的地顺序测试会产生时间差，因此每一份日志都要保留实际开始时间，不能只写“晚高峰测试”。

二、逐步采集：从本机出口到完整回程节点

1. 安装工具并检查本机状态

以下安装命令适用于 Debian、Ubuntu，需有 sudo 权限。安装会更新软件包索引并增加诊断工具，生产机应先确认变更窗口；其他发行版不要直接套用包名。

sudo apt-get update
sudo apt-get install --no-install-recommends \
  mtr-tiny traceroute iputils-ping curl python3 whois

确认工具版本与系统支持的参数：

mtr --version
mtr --help
traceroute --version

再记录服务器时间、地址、路由和负载：

date -u +'%Y-%m-%dT%H:%M:%SZ'
timedatectl status
ip -br address
ip route show
uptime

本步验证：系统时间应正确，公网出口应与待测产品对应，服务器没有明显的高负载。UTC 日志可以跨机器统一对齐；制定北京时间采样表时，应注明北京时间为 UTC+8。

2. 确认目标地址使用哪个出口

以下地址为文档示例地址，不可作为真实测试目标。执行前必须替换为已授权的内地公网 IP；端口也要替换为该主机允许测试的实际端口。

TARGET='203.0.113.10'
PORT='443'

ip route get "$TARGET"

输出通常会包含网关、网卡和源地址，例如：

203.0.113.10 via 192.0.2.1 dev eth0 src 192.0.2.10

这是结构示例，表示系统准备经 eth0 使用所列源地址发包，不代表公网路径已经确定。

多网卡、多公网 IP 或策略路由环境尤其要检查 src。若探测走了管理网卡，测到的就不是待验收线路。只有确认地址确实绑定在本机后，才考虑使用 mtr -a 本机源IP 指定探测源地址，不要为了方便临时修改默认路由。

3. 用 traceroute 获取路径轮廓

先做低频路径探测：

traceroute -4 -n -I -q 1 -w 2 -m 30 "$TARGET"

参数含义如下：

• -4：只测 IPv4。
• -n：直接显示 IP，避免反向 DNS 查询干扰阅读。
• -I：使用 ICMP 探测。
• -q 1：每跳一次探测，先控制发包量。
• -w 2：等待响应最多约 2 秒。
• -m 30：最多探测 30 跳。

如果 ICMP 不完整，再补充 TCP 探测：

sudo traceroute -4 -n -T -p "$PORT" -q 1 -w 2 -m 30 "$TARGET"

TCP 探测应指向已授权的目的地址和端口，不用于扫描端口范围。

本步验证：观察是否到达目的 IP、是否出现可重复的公网跳点。中间出现 * 只表示这一跳未在等待时间内回复；若后续跳点和目的地址正常响应，不应把它直接当作链路中断。

4. 用 MTR 采集重复样本

下面的命令同时保存基础信息、ICMP 时延和两种路径报告。应在两台待测服务器上使用不同的 LABEL，对同一个目的地址运行。

LABEL='HK-CN2'
STAMP=$(date -u +'%Y%m%dT%H%M%SZ')
OUT="$HOME/route-check/${LABEL}_${STAMP}"
mkdir -p "$OUT"

{
  date -u +'%Y-%m-%dT%H:%M:%SZ'
  printf 'label=%s target=%s port=%s\n' "$LABEL" "$TARGET" "$PORT"
  ip route get "$TARGET"
  uptime
} > "$OUT/meta.txt"

LC_ALL=C ping -4 -n -c 100 -i 1 "$TARGET" \
  > "$OUT/ping.txt" 2>&1

sudo mtr -4 -n -r -w -c 100 -i 1 "$TARGET" \
  > "$OUT/mtr-icmp.txt" 2>&1

sudo mtr -4 -n -r -w --tcp -P "$PORT" -c 100 -i 1 "$TARGET" \
  > "$OUT/mtr-tcp.txt" 2>&1

printf '日志目录：%s\n' "$OUT"

以上探测顺序执行，一个目的地通常需要数分钟；路径超时可能使耗时增加。MTR 默认会对多个 TTL 发出探测，因此“100 次”不是整次任务只发送 100 个网络包。

本步验证：打开日志，确认没有权限错误、未知参数或目标填写错误，并检查目的端一行是否有有效响应。TCP 与 ICMP 路径可以不同，这可能来自策略路由、负载均衡或过滤，应分别保留，而不是只挑更好看的结果。

三、核对节点归属：怎样识别 CN2 与 CMIN2

1. 先识别网络，再判断线路声明是否得到支持

CN2、CMIN2 是网络和线路层面的概念，不是仅凭某个 IP 字符串就能完整确认的产品属性。

这些是核对入口，不是完整地址清单。香港服务器还可能包含本地接入、跨网互联和内地落地段；应沿路径连续观察，而不是在报告中只截取一个“符合预期”的节点。

2. 查询实际出现的公网跳点

从日志选取公网跳点后，可以查询 IP 到 ASN 的映射。下列地址仍为示例，必须替换：

HOP_IP='192.0.2.20'
whois -h whois.cymru.com " -v $HOP_IP"

该查询依赖外部服务可用性，会向查询服务发送所查 IP。结果用于辅助识别网络归属，必要时再通过相应地址注册机构的查询、供应商提供的拓扑和出口说明交叉核对。

查询时注意三项边界：

1. 跳点回复使用的接口地址，不一定完整代表转发流量经过的全部网络。
2. 把 traceroute 各跳 IP 映射成 ASN，得到的是观测路径的归属线索，不是直接读取到的 BGP AS_PATH。
3. IP 地理库和主机名可能陈旧，不能只凭其显示“香港”“广州”就认定物理位置。

本步验证：报告应同时列出原始跳点、ASN 查询结果和判断依据。归属查不到或与其他信息冲突时，标记“待核验”，不要自动补成预期线路。

3. 给路径判断划定适用范围

一个有效判断可以写成：

在所列日期、IPv4 地址和测试窗口内，香港测试机至广州电信测试点的可见回程中，连续出现与 CN2 相关的网络节点；另两个运营商目的地的路径单独记录。

如果只看到少数节点，或者跨境段大部分不响应，应写成“部分路径具有相关网络特征，尚不足以完整确认”。两种写法都比“已经证明三网全程走某线路”更接近探测证据的能力边界。

四、验证回程质量：把节点、统计值和业务体验分开看

1. 以目的端统计为主，不只看中间节点

MTR 常见字段包括 Loss%、Snt、Last、Avg、Best、Wrst 和 StDev。其中，目的端的丢包和时延更接近可达性结果，中间节点主要用于定位变化发生的位置。

下面是经过简化的示意数据：

Hop  Address        Loss%  Snt  Avg(ms)  Wrst(ms)
 5   192.0.2.5        65%  100       18        30
 6   192.0.2.6         0%  100       19        31
 7   203.0.113.10      0%  100       21        35

第 5 跳没有回复大量探测包，但后续跳点及目的端没有相同丢包现象，更可能是该设备限制诊断响应，而不是它丢弃了相同比例的业务流量。

如果某一跳开始升高的丢包、时延持续延伸到目的端，并在多轮、不同协议测试中重复出现，才更值得怀疑该段附近存在拥塞或转发问题。即便如此，也不能简单将相邻两跳的 RTT 差值当作两台路由器之间的单向时延：每一跳的回复路径可能不同。

2. 增加 P95，避免平均值掩盖尾部波动

对已保存的 ping.txt，可用 Python 计算成功响应样本的 P95。以下代码采用最近秩法：

python3 - "$OUT/ping.txt" <<'PY'
import math
import re
import sys

text = open(sys.argv[1], encoding="utf-8", errors="replace").read()
values = [float(x) for x in re.findall(r"time=([\d.]+)\s*ms", text)]

if not values:
    raise SystemExit("未找到 time= 格式的成功响应，请检查日志。")

ordered = sorted(values)
p95 = ordered[math.ceil(len(ordered) * 0.95) - 1]
print(f"成功响应样本数: {len(values)}")
print(f"平均 RTT: {sum(values) / len(values):.2f} ms")
print(f"P95 RTT: {p95:.2f} ms")
print(f"最大 RTT: {max(values):.2f} ms")
PY

该脚本只统计 time= 格式的成功响应，不把超时记为某个固定时延；极低时延下出现的 time< 也不纳入。丢包率应同时读取原始 ping 汇总，不能因成功响应的 P95 较低就忽略超时。

建议每个采样窗口至少保留目的端丢包率、平均 RTT、P95 RTT、最大 RTT，以及路径是否变化。MTR 的 StDev 可以辅助观察离散程度，但不要将它与业务监控中的“抖动”字段混用，除非两者计算定义相同。

3. 用真实请求补充验证

路由清晰不等于应用体验一定良好。若香港服务器已经提供获授权的 HTTPS 测试文件，可从内地测试点发起下载，验证香港向内地返回数据时的表现。

以下命令在内地测试机执行，URL 必须替换为真实测试资源：

curl -4 --connect-timeout 5 --max-time 30 \
  -o /dev/null -sS \
  -w 'remote_ip=%{remote_ip} http_code=%{http_code} connect=%{time_connect} tls_done=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} speed_Bps=%{speed_download}\n' \
  'https://your-test-host.example/test-file.bin'

使用同一大小的文件、同样的并发数，先从单连接开始。不要使用生产大文件反复压测，也不要让测试抢占业务带宽。

结果解释要对应方向和单位：

• 下载时，文件数据主要由香港发往内地，可补充验证回程业务质量。
• time_connect 包含连接往返；time_appconnect 是从请求开始到 TLS 完成的累计时间，不是纯 TLS 耗时。
• TTFB 还受服务器处理、缓存和连接状态影响，不能全部归因于网络。
• speed_download 单位为字节/秒。按十进制口径，Mbps＝字节/秒 × 8 ÷ 1,000,000。
• 文件太小、带宽上限不同或使用 CDN，都可能使结果偏离原始服务器线路表现。

访问域名后应核对 remote_ip，确认请求落在待测服务器。若要固定解析，可使用 curl 的 --resolve，但仍需保持正确的域名、证书和 HTTPS 校验，不应通过关闭证书验证来掩盖配置问题。

五、处理异常并形成同口径结果

1. 常见异常的处理顺序

出现异常时，先停止扩大测试量，再检查目标和本机状态。不建议通过缩短间隔、增加并发来“测得更明显”，这可能触发防护策略，甚至影响业务。

若需要供应商协查，提交源 IP、目的 IP、UTC 时间、协议和端口、完整路径、目的端统计及业务失败记录。只有中间一跳高丢包的截图，通常不足以支持定位。

2. 按“线路 × 运营商 × 地区 × 时间”整理

不要将三家运营商的结果合并为一个平均分，也不要用一天中较好的一轮替代全部采样。

可采用以下记录表：

结果应分别回答两个问题：

1. 线路身份是否获得支持？ 可见节点及网络归属是否与交付说明一致，哪些部分仍不可见？
2. 业务质量是否达到要求？ 主要用户所在地区和运营商，在规定窗口内是否满足时延、丢包、成功率及速率要求？

CN2 应重点核对其相关网络路径和电信方向表现，同时检查联通、移动方向是否有跨网波动；CMIN2 应重点核对 CMIN2 相关网络证据和移动方向表现，同时测试电信、联通方向。两者都不能仅凭名称推导“三网相同质量”。

产品选择应基于实际用户分布。若用户主要来自移动网络，应提高移动样本的权重；若三网用户均衡，则需要按三网分别验收。采购时还应确认测试 IP 是否与实际交付产品使用相同出口策略，以及带宽、流量计费和测试权限是否一致。

六、验收与回滚检查项

验收前逐项检查

• [ ] 探测由香港服务器发往内地测试点，未将去程记录当作回程证据。
• [ ] 两台服务器使用相同目的地、地址族、协议、端口和采样窗口。
• [ ] 日志包含源地址、目的地址、准确时间和完整命令结果。
• [ ] CN2 与 CMIN2 的判断有节点归属依据，没有仅凭一跳或一个主机名定性。
• [ ] ICMP、TCP 和业务请求结果分别保存，差异已有解释。
• [ ] 丢包以目的端和业务表现为重点，没有把中间节点限速直接判为线路故障。
• [ ] 已覆盖主要运营商、用户地区和晚高峰，并保留路径变化记录。
• [ ] 报告明确写出采样范围、未验证部分及业务验收阈值。

测试结束后的恢复检查

本文操作不修改系统路由、网卡和防火墙，正常完成后无需执行网络配置回滚。收尾时应检查：

• [ ] 停止手工启动的持续探测；前台任务可用 Ctrl+C 结束，后台任务只终止已确认的测试进程。
• [ ] 若额外创建了定时任务，移除该测试项，不覆盖其他运维任务。
• [ ] 若临时部署了测试文件或服务，按原变更记录恢复，并确认业务不再引用。
• [ ] 若经审批增加过访问规则，只撤销对应规则，不清空整套防火墙配置。
• [ ] 保留原始日志和结果表；对外提交前隐藏账号、内部主机名等敏感信息。
• [ ] 若需要卸载诊断工具，先检查它们是否为测试前已安装或被其他任务使用，不直接批量卸载。
• [ ] 检查服务器负载、带宽和业务监控已恢复到测试前状态。

完成这些检查后，得到的应是一份有方向、有节点依据、有时间范围、能复查的回程验收记录。它可以支持 CN2 与 CMIN2 在具体目的地上的选择，而不是把某次探测结果扩大为所有地区、所有时段的线路保证。