国际网络延迟排查实战：为什么千兆宽带访问海外服务仍然有 100ms+？

一、先说结论：带宽和延迟不是一回事

很多用户会把“网速”理解成一个指标，但工程上至少要拆成四个维度：

千兆宽带主要提升的是本地接入带宽，不等于访问海外服务器时 RTT 会自动降低。

举个例子：

本地宽带：1000 Mbps 访问本省服务器：5ms 访问东京服务器：40-120ms 访问美国西海岸服务器：130-200ms 访问欧洲服务器：180-300ms

这些数字背后不是简单的“宽带快不快”，而是地理距离、光纤路径、运营商出口、BGP 路由、目标服务部署位置共同作用的结果。

二、RTT 是什么：为什么 Ping 显示的是往返时间

我们常说的 Ping，一般指 RTT，也就是 Round-Trip Time，往返时间。

它包含：

本地设备发包 -> 本地路由器 -> 运营商网络 -> 国际出口 -> 海外网络 -> 目标服务器 -> 目标服务器回包 -> 沿路径返回本地设备

所以 Ping 不是单程时间，而是往返时间。

如果你看到：

ping = 100ms

可以粗略理解为：

本地到目标再回来的总耗时约 100ms

这个值越低，交互越及时；但它不直接代表下载速度，也不直接代表网页总加载时间。

网页加载还涉及 DNS、TCP 连接、TLS 握手、HTTP 首字节、静态资源、浏览器渲染等阶段。

三、物理距离决定延迟下限

真空中的光速约为：

300,000 km/s

但互联网不是在真空中传输，绝大多数长距离通信依赖光纤。光在光纤中的传播速度会受到介质折射率影响，常见估算约为：

200,000 km/s

换算一下：

光纤中 100 km 单程约 0.5ms 光纤中 100 km 往返约 1ms

如果两地直线距离是 3000 km，仅传播时间的理论 RTT 下限约为：

3000 km * 2 / 200000 km/s = 0.03s = 30ms

但现实中的光纤不会完全按直线铺设，数据包也不会只经过一根光纤。

现实链路通常要乘上一个路径系数：

理论 RTT ≈ 地理距离 * 2 / 光纤传播速度 * 路径系数

路径系数可以粗略取：

1.3 - 1.8

如果发生明显绕路，系数可能更高。

四、用 Python 估算理论延迟下限

下面写一个简单脚本，用地理距离估算理论 RTT。

脚本文件：latency_floor.py

defestimate_rtt(distance_km:float,path_factor:float=1.5)->float:fiber_speed_km_per_s=200_000rtt_seconds=distance_km*2/fiber_speed_km_per_s*path_factorreturnrtt_seconds*1000routes=[("Beijing -> Tokyo",2100),("Shanghai -> Singapore",3800),("Guangzhou -> Los Angeles",11600),("Beijing -> Frankfurt",7400),]forname,distanceinroutes:forfactorin(1.3,1.5,1.8):print(f"{name}factor={factor}:{estimate_rtt(distance,factor):.1f}ms")print()

运行：

python latency_floor.py

示例输出：

Beijing -> Tokyo factor=1.3: 27.3ms Beijing -> Tokyo factor=1.5: 31.5ms Beijing -> Tokyo factor=1.8: 37.8ms Guangzhou -> Los Angeles factor=1.3: 150.8ms Guangzhou -> Los Angeles factor=1.5: 174.0ms Guangzhou -> Los Angeles factor=1.8: 208.8ms

这个脚本不能替代真实测速，但它能帮你建立一个“延迟不可能低到哪里去”的基本认知。

如果从国内访问北美服务，你期待稳定 20ms，本身就不现实；如果访问东亚节点却长期 180ms，那就可能存在绕路或拥堵。

五、为什么实际延迟往往高于理论值

真实网络里的延迟由多项组成：

传播延迟 + 路由器转发延迟 + 排队延迟 + 协议处理延迟 + 链路绕行延迟 + 丢包重传成本 + 目标服务响应成本

1. 光纤路径不是直线

城市之间的光纤要沿道路、海缆、管线、交换中心铺设，不可能按地图上两点直线走。

2. 数据包要经过多个路由节点

每一跳都会带来处理和排队成本。

3. 国际出口可能拥堵

晚高峰时，跨境流量集中，部分运营商出口或互联点容易出现排队。

4. BGP 不一定选择最低延迟路径

BGP 更关注可达性、策略、成本、自治系统关系，不保证选择最低 RTT 的路径。

5. CDN 调度可能不理想

同一个域名可能解析到不同 CDN 节点。DNS、ECS、Anycast、运营商网络都会影响实际入口。

六、BGP 路由为什么可能绕远

BGP 是互联网核心路由协议之一。它解决的是“不同自治系统之间怎么到达对方”的问题。

但 BGP 的最优路径不一定等于物理最短路径。

一个简化例子：

理想路径： 北京 -> 东京 实际路径： 北京 -> 上海 -> 香港 -> 新加坡 -> 东京

这类绕路会带来：

更高 RTT 更多中间跳 更高抖动风险 更高丢包概率 晚高峰更不稳定

为什么会绕？

七、合理延迟范围要看目标区域

不同地区不能用同一标准判断。

下面是经验参考，不是绝对标准：

如果你访问的是远程桌面、游戏或会议，稳定性比绝对平均值更重要。

180ms 稳定链路 > 120ms 但频繁跳到 500ms 的链路

八、第一步：不要只测一个 IP

国际网络排障最忌讳只测一个目标。

建议至少测四类目标：

本地网关 国内公共 IP 海外公共 IP 真实业务域名

Windows：

ping 192.168.1.1-n 50 ping 223.5.5.5-n 50 ping 1.1.1.1-n 50 ping github.com-n 50

Linux/macOS：

ping-c50192.168.1.1ping-c50223.5.5.5ping-c501.1.1.1ping-c50github.com

判断逻辑：

九、PowerShell 脚本：批量采集延迟样本

下面脚本适合 Windows 用户一次性采集多个目标的 min、avg、max、丢包率。

脚本文件：multi_ping_probe.ps1

$Targets= @("192.168.1.1","223.5.5.5","1.1.1.1","github.com","cloudflare.com")$Count= 30$Output=".\multi_ping_probe.csv"foreach($Targetin$Targets){$Samples= @()$Lost= 0for($i= 1;$i-le$Count;$i++){$Ping=Test-Connection-ComputerName$Target-Count 1-ErrorAction SilentlyContinueif($Ping){$Samples+=[double]$Ping.ResponseTime}else{$Lost++}Start-Sleep-Milliseconds 300}if($Samples.Count-gt0){$Min=[Math]::Round(($Samples|Measure-Object-Minimum).Minimum,2)$Avg=[Math]::Round(($Samples|Measure-Object-Average).Average,2)$Max=[Math]::Round(($Samples|Measure-Object-Maximum).Maximum,2)}else{$Min=""$Avg=""$Max=""}[PSCustomObject]@{Time =(Get-Date).ToString("yyyy-MM-dd HH:mm:ss")Target =$TargetCount =$CountReceived =$Samples.Count Lost =$LostLossPercent =[Math]::Round(($Lost/$Count)*100,2)MinMs =$MinAvgMs =$AvgMaxMs =$Max}|Export-Csv-Path$Output-Append-NoTypeInformation-Encoding UTF8}Write-Host"Saved to$Output"

运行：

powershell-ExecutionPolicy Bypass-File.\multi_ping_probe.ps1

建议在不同时间段运行：

上午一次 下午一次 晚高峰一次 深夜一次

如果晚高峰海外目标明显变差，而本地网关和国内 IP 正常，说明跨境出口或海外路径更值得关注。

十、Python 脚本：用 CSV 对比不同时段

如果你每天采集一次，可以用 Python 汇总多个 CSV。

脚本文件：compare_latency_csv.py

importcsvimportglobfromcollectionsimportdefaultdictdefread_rows(pattern):rows=[]forpathinglob.glob(pattern):withopen(path,newline="",encoding="utf-8-sig")asfile:reader=csv.DictReader(file)forrowinreader:row["_file"]=path rows.append(row)returnrowsdefto_float(value):try:returnfloat(value)exceptException:returnNonedefmain():rows=read_rows("*.csv")grouped=defaultdict(list)forrowinrows:target=row.get("Target")avg=to_float(row.get("AvgMs"))max_ms=to_float(row.get("MaxMs"))loss=to_float(row.get("LossPercent"))iftargetandavgisnotNone:grouped[target].append((avg,max_msor0,lossor0,row["_file"]))fortarget,itemsingrouped.items():print(f"\n#{target}")items=sorted(items,key=lambdaitem:item[0])foravg,max_ms,loss,file_nameinitems:print(f"{file_name}: avg={avg:.1f}ms max={max_ms:.1f}ms loss={loss:.2f}%")if__name__=="__main__":main()

运行：

python compare_latency_csv.py

这个脚本的作用是把“感觉晚上慢”变成可比较的数据。

十一、Traceroute：看数据包走了哪些节点

Windows：

tracert github.com tracert 1.1.1.1

Linux/macOS：

traceroutegithub.comtraceroute1.1.1.1

Traceroute 适合观察：

跳数是否异常多 是否从国内绕到很远地区 是否某一段开始延迟突增 是否目标服务入口和预期地区不一致

示意：

正常路径： 本地 -> 运营商 -> 国际出口 -> 东京 -> 目标 绕行路径： 本地 -> 运营商 -> 上海 -> 香港 -> 新加坡 -> 东京 -> 目标

如果你访问东亚服务却出现明显新加坡、欧洲或北美方向的绕行，延迟自然会变高。

十二、MTR：比 Traceroute 更适合看稳定性

Traceroute 是一次性路径探测，MTR 更适合持续观察。

Linux/macOS：

mtr-rwzc100github.com

参数说明：

关注列：

注意：中间节点丢包不一定代表业务丢包。很多路由器会限制 ICMP 响应。判断时要看最后一跳、目标服务体验和其他工具输出。

十三、pathping：Windows 下结合路径和丢包

Windows 用户可以用：

pathping github.com

它会先追踪路径，再统计每一跳丢包情况。

缺点是运行较慢，适合问题复现时记录证据。

如果你要反馈给网络服务方，可以保存输出：

pathping github.com > pathping-github.txt

十四、curl：拆解 DNS、TCP、TLS 和 HTTP 阶段

有时候用户说“延迟高”，其实慢在 HTTP 首字节或目标服务后端。

可以用 curl 拆解：

curl-o/dev/null-s-w\"dns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\nremote_ip=%{remote_ip}\ncode=%{http_code}\n"\https://github.com

Windows：

curl.exe-o NUL-s-w"dns=%{time_namelookup}`nconnect=%{time_connect}`ntls=%{time_appconnect}`nfirst_byte=%{time_starttransfer}`ntotal=%{time_total}`nremote_ip=%{remote_ip}`ncode=%{http_code}`n"https://github.com

指标解释：

如果connect高，说明链路层面更可疑；如果first_byte高，可能是服务端或 CDN 响应慢。

十五、DNS 和 CDN 会让“目标位置”变复杂

同一个域名可能解析到不同 IP。

Resolve-DnsNamegithub.comResolve-DnsNamegithub.com-Server 1.1.1.1Resolve-DnsNamegithub.com-Server 8.8.8.8

Linux/macOS：

diggithub.comdiggithub.com @1.1.1.1diggithub.com @8.8.8.8

如果不同 DNS 返回不同 IP，不一定是异常，也可能是 CDN 正常调度。

但如果解析到了非常远的节点，或者实际连接 IP 与预期地区不一致，就可能影响延迟。

十六、Python：解析多个域名并测试 TCP 建连耗时

下面脚本会解析域名，然后测试 443 端口 TCP 建连耗时。

脚本文件：tcp_connect_probe.py

importsocketimporttime TARGETS=["github.com","api.github.com","cloudflare.com",]PORT=443TIMEOUT=5defconnect_time(host,port):started=time.perf_counter()try:withsocket.create_connection((host,port),timeout=TIMEOUT):returnTrue,(time.perf_counter()-started)*1000,""exceptExceptionasexc:returnFalse,(time.perf_counter()-started)*1000,repr(exc)forhostinTARGETS:ok,elapsed,error=connect_time(host,PORT)print(f"{host}:{PORT}ok={ok}connect={elapsed:.2f}ms error={error}")

运行：

python tcp_connect_probe.py

这个脚本比普通 Ping 更贴近 HTTPS 业务，因为它真正尝试建立 TCP 连接。

十七、用 Python 计算路径效率

假设你知道两地直线距离和实际 RTT，可以估算一个路径效率指标。

脚本文件：route_efficiency.py

deftheoretical_rtt_ms(distance_km,path_factor=1.5):fiber_speed=200_000returndistance_km*2/fiber_speed*path_factor*1000defefficiency(distance_km,measured_rtt_ms):ideal=theoretical_rtt_ms(distance_km)returnideal,measured_rtt_ms/ideal cases=[("Tokyo",2100,120),("Singapore",3800,180),("Los Angeles",11600,210),("Frankfurt",7400,280),]forregion,distance,measuredincases:ideal,ratio=efficiency(distance,measured)print(f"{region}: ideal~{ideal:.1f}ms measured={measured:.1f}ms ratio={ratio:.2f}x")

输出示例：

Tokyo: ideal~31.5ms measured=120.0ms ratio=3.81x Los Angeles: ideal~174.0ms measured=210.0ms ratio=1.21x

如果某个近距离区域的 ratio 很高，说明路径可能明显绕行或拥堵。

十八、案例 1：访问日本服务却有 180ms

现象：

目标服务在日本 本地访问 Ping 180ms 晚高峰更严重 下载速度正常

排查：

ping 192.168.1.1-n 50 ping 223.5.5.5-n 50 ping 1.1.1.1-n 50 tracert 目标域名

判断：

处理思路：

换网络环境对比 换 DNS 对比 CDN 调度 避开晚高峰测试 对比不同线路或节点 记录 pathping / mtr 证据

十九、案例 2：远程桌面不跟手

现象：

远程桌面能连 画质不算差 但鼠标拖动明显慢半拍 打字时偶尔连击或卡顿

远程桌面对延迟和抖动非常敏感。

排查：

ping 远程桌面服务器IP-n 100 pathping 远程桌面服务器IP

如果平均延迟已经接近 250ms，再叠加抖动，体感一定不好。

优化建议：

二十、案例 3：游戏服务器 Ping 不高但技能慢

游戏里不要只看平均 Ping。

要同时看：

丢包 抖动 P95/P99 延迟 服务器 Tick 客户端帧率 目标区域

命令：

ping 游戏服务器IP-n 200 tracert 游戏服务器IP

如果游戏 UI 显示 80ms，但每隔几秒出现 300ms 尖峰，体感会明显比稳定 120ms 更差。

二十一、案例 4：GitHub 页面能开但 Git clone 慢

现象：

GitHub 首页可以打开 但 clone 大仓库时经常 timeout git pull 偶尔 reset

排查：

gitls-remote https://github.com/git/git.gitcurl-Ihttps://github.compinggithub.com-n100

如果网页能打开但 Git 慢，可能是：

大文件传输受吞吐影响 TCP 重传放大高 RTT 成本 TLS 或 HTTP/2 连接被重置 目标服务限流或临时异常

可临时测试：

gitconfig--globalhttp.version HTTP/1.1gitls-remote https://github.com/git/git.git

不要把所有 Git 慢都归因于 DNS。高 RTT 和轻微丢包也会显著拖慢大仓库传输。

二十二、怎么判断“异常延迟”

判断异常要结合目标区域、业务类型和时间段。

可以用下面的检查清单：

目标服务器在哪个国家或区域？ 理论距离大概是多少？ 当前平均 RTT 是否明显高于同地区经验值？ 最大 RTT 是否远高于平均 RTT？ 晚高峰是否明显变差？ 是否只有一个网站慢？ 换 DNS 后目标 IP 是否变化？ 换网络后是否改善？ 是否存在丢包？ 是否存在路由绕行？

如果多项都指向跨境路径问题，就可以进一步考虑线路优化。

二十三、线路优化到底优化什么

线路优化不是突破光速，也不是把 10000 公里变成 100 公里。

它主要尝试减少：

不必要的绕路 拥堵出口排队 高丢包路径 高抖动路径 不理想 CDN 入口

比如普通公网路径：

用户 -> 本地运营商 -> 拥堵出口 -> 多段绕行 -> 目标服务

优化后可能变成：

用户 -> 就近入口 -> 更稳定中继链路 -> 目标服务

稳如狗APP这类工具的价值，不是让远距离访问没有物理延迟，而是尽量减少公共网络里的绕路、排队和不稳定因素，让跨区域访问更接近合理延迟范围。

二十四、用同一套指标做前后对比

开启或切换线路前后，建议用同一套命令比较。

ping wenrugou.net-n 100 tracert wenrugou.net curl.exe-o NUL-s-w"dns=%{time_namelookup}`nconnect=%{time_connect}`ntls=%{time_appconnect}`nfirst_byte=%{time_starttransfer}`ntotal=%{time_total}`n"https://wenrugou.net

记录：

平均延迟 最大延迟 P95/P99 丢包率 traceroute 跳数 curl connect 时间 curl first_byte 时间 真实业务成功率

如果平均延迟只降低一点，但最大延迟、P99 和丢包明显改善，实时体验也可能提升很多。

二十五、测试线路优化前后链路差异的样例

下面是一个偏工程化的测试模板，适合验证工具开启前后的变化。

1. 关闭优化工具，采集基线数据 2. 开启稳如狗APP，选择目标业务常用区域 3. 重新执行同一组命令 4. 对比 avg / max / p95 / p99 / loss / curl connect 5. 再用真实业务验证，例如会议、远程桌面、游戏或 Git

公开站点连通性样例：

curl.exe-I https://www.wenrugou.net

不要只看一次测试结果，至少重复 3 轮，尤其要覆盖晚高峰。

二十六、排障记录模板

遇到国际网络延迟异常时，可以这样记录：

问题时间： 所在城市： 运营商： 网络环境：家庭宽带 / 公司网络 / 手机热点 连接方式：Wi-Fi / 有线 目标服务： 目标区域： 本地网关 ping min/avg/max： 国内公共 IP ping min/avg/max： 海外公共 IP ping min/avg/max： 业务域名 ping min/avg/max： 丢包率： traceroute 路径： curl dns/connect/tls/first_byte/total： 是否晚高峰更明显： 换 DNS 后是否变化： 换网络后是否变化： 使用线路优化工具后是否变化： 结论：

示例：

问题时间：2026-06-26 21:30 所在城市：上海 运营商：某宽带 目标服务：远程办公系统 目标区域：东京 本地网关：1/2/5ms 国内公共 IP：10/18/35ms 海外公共 IP：80/140/310ms 业务域名：90/165/420ms traceroute：疑似绕行香港后再到东京 结论：本地网络正常，跨境路径晚高峰抖动明显

二十七、常见误区

1. 误区：千兆宽带一定低延迟

千兆宽带提升吞吐，不会消除物理距离。

2. 误区：Ping 低就一定不卡

还要看抖动、丢包、最大延迟和业务协议。

3. 误区：Traceroute 中间一跳丢包就是故障

中间路由器可能限制 ICMP，重点看最终目标和实际业务。

4. 误区：换 DNS 一定能解决海外延迟

DNS 影响目标入口，但如果链路本身绕行或拥堵，换 DNS 未必有效。

5. 误区：所有海外服务都应该用同一个节点

不同业务目标区域不同，最优线路也可能不同。

二十八、总结

国际网络延迟不是一个单纯的“宽带快慢”问题，而是物理距离、光纤传播速度、BGP 路由、国际出口、CDN 调度、丢包抖动和目标服务状态共同决定的结果。

本文可以总结为几条实践原则：

1. 先理解物理延迟下限，不要期待突破光速。
2. 只看平均 Ping 不够，要看最大值、P95、P99、丢包和抖动。
3. 先测本地网关，再测国内公共 IP，再测海外目标，逐层定位。
4. Traceroute、MTR、pathping 能帮助判断是否绕路或在哪一段变差。
5. curl 可以拆解 DNS、TCP、TLS 和 HTTP 阶段，避免把服务端慢误判成网络慢。
6. DNS/CDN 调度会影响实际入口，解析结果也要纳入排查。
7. 线路优化的目标不是消除距离，而是减少绕路、拥堵和不稳定路径。

如果你经常做跨境办公、远程开发、海外学术访问、国际服游戏或视频会议，建议把本文的脚本和排障模板保存下来。真正高效的网络优化，不是凭感觉换来换去，而是用数据判断问题发生在哪一层，再选择对应的解决办法。

参考资料

1. 原文《为什么物理距离决定延迟下限：国际骨干网与光纤传播极限》：https://www.wenrugou.net/international-network-latency-guide.html
2. 网络工具箱：https://www.wenrugou.net/tools
3. iperf3 官方文档：https://iperf.fr/
4. MTR 项目说明：https://www.bitwizard.nl/mtr/