01电信与联通，都要把交接段读完整
电信路径经过香港联通，可见 AS10099 与 AS9929，之后进入电信 163（AS4134），最后到上海电信 AS4812。这里的 9929 是前段骨干特征，不能省去后续电信 163，也不能据此写成 CN2 GIA。
联通方向在 AS9929 之后还可见 AS4837，再进入北京联通 AS4808。移动则经过 AS58807 与广州 AS9808，再到北京移动 AS56048。本次移动可见的是 CMIN2，不能与 AS58453 的 CMI 混写。
| 目标 | 本次可见骨干 | 终点 RTT / 跳号 |
|---|---|---|
| 上海电信 DNS | AS10099 → AS9929 → AS4134 → AS4812 | 180 ms / 13 跳 |
| 北京联通主机 | AS9929 → AS4837 → AS4808 | 176 ms / 19 跳 |
| 北京移动 DNS | AS58807 → 广州 AS9808 → AS56048 | 152 ms / 15 跳 |
02单跳地理标签，不能替代机器所在地
样机自身的 ipinfo 城市为洛杉矶，公告 ASN 为 AS8796 Fastnet Data。网关一跳响应约 2–4 ms，地理库却标注肯塔基；现有信息不足以支持这个城市判断，因此本文没有据此改写样机位置或宣称发生跨州绕行。
理解路线时，地理库适合提供辅助线索，仍需结合连续跳点、ASN 与时延。看到某个美国城市名字，不等于流量一定经过那个城市的实体机房。
03移动读数较低，只代表这三个目标的一次比较
本次移动终点约 152 ms，低于联通约 176 ms 和电信约 180 ms。它描述的是这台机器到固定目标的探测往返等待，不代表所有移动用户都会获得更低延迟，也不能由此计算下载速度。
三条均到终点，可以确认本次连通性；如果应用需要连续交互，仍应以实际访问地区和协议下的响应为准。这份短时 ICMP 记录没有提供持续稳定性数据。
04已确认 AMD Optimised，仍按本次路径记录
站长已确认产品为 Los Angeles AMD Optimised VPS。因此，本文可以明确对应到这条洛杉矶产品系列；具体配置没有逐项列出，也没有对同系列所有规格逐台测试。
本次电信回程依然按实际看到的 9929 转 163 记录，不因产品名含 Optimised 就补写 CN2 或 GIA。联通与移动同样保留本次可见的 AS9929、AS4837 与 AS58807，产品身份和路由证据各自说明不同的信息。
本文只有一台洛杉矶实例的三条轨迹，不把其他机器计为已测，也不覆盖大阪、香港、东京或法兰克福。即使其他实例使用相近地址，也不能替它补写三网结果。
05这次回程测试怎样读？
本批测试在 2026 年 11 月 1 日 16:48–16:50（北京时间）完成，使用 nexttrace 的 IPv4 ICMP 探测。三项目标分别为上海电信 DNS（AS4812）、北京联通公网主机（AS4808）、北京移动 DNS（AS56048）。它们不是三地家宽样本，也不能代表这些运营商的所有用户。
本文延迟取原始记录终点一跳显示的第一组采样，按报告保留整数毫秒；它是探测往返时延（RTT），不是单向传输时间，也不是连续测试均值。路由方向是服务器到目标，用户到服务器的去程可能不同。表内只提取可见骨干，箭头之间可能还有省略或不响应的跳点。
终点有回复，说明这一次探测到达了目标。单次记录不能得出吞吐、长期丢包率、晚高峰稳定性、IPv6 或网页加载速度的结论。本文没有测试 CPU、磁盘、流媒体解锁或 IP 质量。