海外网站访问慢怎么排查？从DNS、延迟到丢包逐步定位

在跨境业务、海外 SaaS、海外云服务以及全球化网站运维场景中，经常会遇到这样的问题：

同一个海外网站，有的人访问正常，有的人打开很慢；白天速度正常，到了晚上延迟突然升高；Ping 看起来没有明显异常，但网页加载仍然需要很长时间。

这类问题不能简单归结为“带宽不够”。

一次完整的网站访问，至少会涉及 DNS 解析、网络路由、TCP 建连、TLS 握手、服务器处理、内容传输和浏览器渲染 等多个环节。

因此，排查海外网站访问慢的问题，建议遵循一个基本原则：

先定位慢在哪一层，再处理对应的问题。

一个比较实用的排查顺序是：

DNS → Ping → 路由 → 丢包 → TCP/TLS → HTTP响应 → 服务器/CDN

下面逐步展开。

一、第一步：先判断到底是“网站慢”还是“网络慢”

遇到网站打开慢时，不建议一开始就修改 DNS、换线路或者调整服务器配置。

首先应该确认问题范围。

例如可以测试：

• 只有一个海外网站慢，还是所有海外网站都慢？

• 国内网站访问是否正常？

• 不同电脑访问是否一样？

• 手机网络和公司宽带结果是否一样？

• 不同运营商网络是否存在明显差异？

• 白天和晚高峰是否存在明显差异？

这一步非常重要。

如果所有海外网站都慢，更可能与本地出口、运营商链路或者跨境链路有关。

如果只有某一个网站慢，则应该重点排查该网站的 DNS、服务器、CDN、源站以及路由情况。

如果只有公司某一台电脑慢，则应该优先排查本机 DNS、代理、防火墙、浏览器和系统网络配置。

因此，网络排障的第一步不是“解决”，而是先确定故障边界。

二、第二步：检查DNS解析是否正常

访问：

https://www.example.com

浏览器首先需要知道 www.example.com 对应哪一个 IP 地址。

这个过程就是 DNS 解析。

如果 DNS 本身响应较慢、解析错误，或者返回了一个距离用户很远的节点，即使后面的网络质量很好，最终访问体验仍然可能很差。

1. 使用 nslookup 检查

Windows 可以执行：

nslookup example.com

Linux/macOS 可以使用：

dig example.com

重点观察：

解析是否成功
解析耗时是否异常
返回IP是否正确
不同DNS返回结果是否一致

如果网站使用 CDN，还需要注意：

不同 DNS 返回不同 IP 并不一定是异常。

CDN、Anycast、智能 DNS 等技术本身就可能根据用户所在地区、运营商以及网络情况返回不同节点。

真正需要关注的是：

DNS 是否把用户调度到了明显不合理的节点。

例如用户位于亚洲，却被解析到距离很远的欧美节点，那么后续 RTT 很可能明显增加。

三、尝试绕过DNS进行对比测试

判断是不是 DNS 问题，还有一个比较简单的方法：

直接测试目标IP。

假设：

nslookup example.com

得到：

203.0.113.10

可以测试：

ping 203.0.113.10

再与：

ping example.com

进行对比。

对于 HTTP/HTTPS 服务，还可以使用 curl 指定解析：

curl --resolve example.com:443:203.0.113.10 https://example.com/

这样可以在不修改系统 hosts 的情况下，让本次请求直接使用指定 IP。

如果指定 IP 后明显恢复正常，而通过正常 DNS 访问较慢，那么就应该进一步检查 DNS 调度、Local DNS、CDN 节点选择等问题。

四、第三步：使用Ping判断基础延迟

DNS没有明显异常后，可以继续测试网络延迟。

最常用的方法就是：

ping example.com

Windows可以执行：

ping example.com -n 20

Linux/macOS：

ping -c 20 example.com

不要只 Ping 一次。

建议连续测试20次甚至更多，因为网络问题很多时候不是持续性的，而是间歇性的。

主要观察三个指标：

平均延迟、延迟波动、丢包率。

例如：

Minimum = 168ms
Maximum = 175ms
Average = 171ms
Lost = 0%

说明网络虽然存在一定物理距离带来的延迟，但是整体比较稳定。

如果结果是：

Minimum = 150ms
Maximum = 650ms
Average = 280ms
Lost = 5%

那么问题就比较明显。

相比单纯的平均延迟，“延迟突然从150ms跳到600ms”往往更值得关注，因为这通常意味着链路存在拥塞或者抖动。

五、不要看到海外延迟高就认为网络有问题

跨区域网络存在物理距离限制。

例如从中国大陆访问美国、欧洲等地区的数据中心，RTT 本身就会明显高于访问本地服务器。

所以：

高延迟 ≠ 网络故障。

更重要的是观察：

延迟是否稳定
是否突然升高
是否存在明显抖动
是否伴随丢包
不同时间段差异是否很大

例如一条线路长期稳定在180ms，实际体验可能比一条平时130ms、但经常跳到500ms的线路更好。

对于企业业务而言，网络的稳定性和可预测性往往比单次最低延迟更重要。

六、第四步：使用Tracert查看路由路径

Ping只能告诉我们：

客户端到目标服务器的最终结果怎么样。

但它无法直接告诉我们问题发生在哪里。

这时就需要使用路由跟踪。

Windows：

tracert example.com

Linux：

traceroute example.com

macOS：

traceroute example.com

它会显示数据包经过的多个网络节点，例如：

本地网关
↓
运营商城域网
↓
运营商骨干网
↓
国际出口
↓
海外运营商
↓
海外IDC
↓
目标服务器

如果前几跳延迟很低，但从某个节点开始延迟突然明显增加，就可以进一步判断问题可能出现在对应链路之后。

七、如何正确理解Tracert里的“*”

很多人在运行 Tracert 后看到：

* * *

就认为这里发生了丢包。

其实并不一定。

部分路由器可能：

• 禁止ICMP响应

• 对ICMP进行限速

• 不返回TTL超时报文

• 对Traceroute探测报文优先级较低

因此：

中间某一跳不响应，并不代表真实业务流量也无法通过。

判断链路是否真的存在问题，需要继续观察后面的节点。

如果某一跳显示丢包，但是之后所有节点都恢复正常，那么很可能只是该节点限制了 ICMP 响应。

反过来，如果从某一跳开始出现异常，并且这种异常一直延续到最终服务器，就值得重点关注。

八、第五步：使用MTR进一步分析延迟和丢包

如果需要比 Ping 和 Traceroute 更详细的信息，可以使用 MTR。

MTR 可以理解为：

Ping + Traceroute 的组合工具。

Linux可以安装：

sudo apt install mtr

或者：

yum install mtr

然后执行：

mtr example.com

也可以生成统计报告：

mtr -rwzc 100 example.com

MTR通常会显示：

Loss%
Snt
Last
Avg
Best
Wrst
StDev

其中重点关注：

Loss%

丢包率。

Avg

平均延迟。

Wrst

最大延迟。

StDev

延迟波动程度。

相比单纯 Ping 最终服务器，MTR最大的价值是：

能够观察整条路径上的延迟变化。

九、MTR丢包应该怎么看？

这是网络排障中非常容易误判的地方。

例如：

Hop 5    Loss 30%
Hop 6    Loss 0%
Hop 7    Loss 0%
Target   Loss 0%

不能简单认为 Hop 5 出现了30%的真实转发丢包。

因为如果 Hop 5 真正丢弃了30%的转发数据包，那么理论上后续节点也应该受到影响。

这种情况更可能是：

该路由器限制了ICMP响应。

真正需要重点关注的是类似：

Hop 5    Loss 8%
Hop 6    Loss 8%
Hop 7    Loss 9%
Target   Loss 8%

如果从某一跳开始出现丢包，并一直延续到目标服务器，那么该节点附近的链路就值得进一步分析。

十、第六步：分解TCP、TLS和HTTP耗时

有时候会出现一种情况：

Ping正常
MTR正常
没有明显丢包

但是网页依然打开很慢。

这时候就不能继续只盯着 Ping。

因为浏览器访问 HTTPS 网站还涉及：

DNS解析
↓
TCP连接
↓
TLS握手
↓
HTTP请求
↓
服务器处理
↓
首字节返回
↓
内容下载

可以使用 curl 进行分阶段测速。

例如：

curl -o /dev/null -s -w \
"DNS: %{time_namelookup}\n\
TCP: %{time_connect}\n\
TLS: %{time_appconnect}\n\
TTFB: %{time_starttransfer}\n\
Total: %{time_total}\n" \
https://example.com

这样就能得到类似：

DNS: 0.025
TCP: 0.182
TLS: 0.356
TTFB: 1.250
Total: 1.680

然后再判断瓶颈在哪里。

十一、不同阶段慢，代表什么？

可以按照下面的思路判断。

DNS耗时高

重点检查：

DNS服务器
Local DNS
DNS缓存
智能DNS调度
CDN节点解析

TCP连接耗时高

重点检查：

网络RTT
跨境路由
链路绕行
丢包
运营商互联质量

TCP建立连接本身就受到 RTT 影响，因此远距离访问天然比本地访问更慢。

TLS耗时高

可能与：

RTT较高
TLS版本
证书链
连接复用
服务器TLS配置

有关。

HTTPS建立安全连接需要进行额外通信，因此在高延迟网络下会更加明显。

TTFB高

TTFB（Time To First Byte）指客户端从发出请求到收到服务器第一个字节所经历的时间。

如果：

DNS正常
TCP正常
TLS正常

但：

TTFB = 2s

那么就不能继续把问题全部归咎于网络。

应该进一步检查：

Web服务器
应用程序
数据库
API
磁盘IO
CPU
缓存
源站负载

十二、第七步：检查服务器自身是否存在性能瓶颈

如果网络链路没有明显问题，就需要登录服务器检查资源。

Linux可以通过：

top

或者：

htop

观察CPU和内存。

查看磁盘：

iostat

查看网络连接：

ss -s

还可以检查：

CPU是否长期100%
内存是否不足
Swap是否频繁使用
磁盘IO是否过高
网络带宽是否跑满
TCP连接数是否异常
Web服务并发是否达到上限
数据库是否存在慢查询

很多“网站访问慢”，最终并不是网络慢，而是服务器本身响应慢。

十三、第八步：检查CDN是否真正发挥作用

如果海外网站已经部署 CDN，还需要确认用户是否真正命中了合理的边缘节点。

可以使用：

nslookup example.com

查看解析结果。

同时结合 HTTP Response Headers 判断是否命中 CDN 缓存。

不同 CDN 厂商返回的 Header 不同，常见可能包括：

X-Cache
CF-Cache-Status
Age
Via
Server

例如：

X-Cache: HIT

通常表示命中了缓存。

如果大量静态资源始终：

MISS

则可能频繁回源。

这时候即使部署了 CDN，实际效果也可能并不理想。

需要检查：

缓存规则
Cache-Control
资源TTL
Query String
Cookie
回源策略
节点调度

十四、海外网站访问慢，一个非常重要的变量：跨境链路

普通网站访问慢和海外网站访问慢最大的区别之一，就是：

跨境网络链路更加复杂。

一次请求可能经过：

企业局域网
→ 国内运营商
→ 国内骨干网
→ 国际出口
→ 国际骨干网络
→ 海外运营商
→ 海外IDC
→ 服务器

链路越长，潜在的不确定因素越多。

常见问题包括：

国际出口拥塞
跨运营商绕路
高峰期链路抖动
跨区域路由不合理
海外服务器距离过远
运营商互联质量差异

因此，如果发现：

国内网站正常，但多个海外网站在特定时段同时变慢，

就应该把重点放到跨境链路质量和运营商路由上，而不是反复修改浏览器或者网站配置。

十五、不要只测试单一时间点

网络故障排查还有一个常见错误：

只测试一次。

比如上午10点运行：

ping
mtr
traceroute

全部正常，于是认为网络没有问题。

但真实问题可能只发生在：

20:00—23:00

这种情况通常与网络高峰期拥塞有关。

因此，对于间歇性访问慢的问题，建议至少记录：

上午
下午
晚高峰
故障发生时
故障恢复后

几组数据。

最好保存：

Ping结果
MTR结果
Traceroute结果
DNS结果
curl耗时

然后进行横向比较。

十六、多地区、多运营商对比测试也很重要

如果运营的是全球化网站，不能只从办公室的一台电脑进行测试。

例如网站服务器位于美国，可以分别从：

中国电信
中国联通
中国移动
香港
新加坡
日本
美国
欧洲

进行拨测。

如果：

美国 → 服务器：20ms
日本 → 服务器：100ms
新加坡 → 服务器：180ms
中国大陆 → 服务器：300ms+

那么问题很可能不是服务器本身，而是不同地区到服务器之间的网络路径存在明显差异。

对于跨境业务，这种多地域、跨运营商测试往往比单点测速更有参考价值。

十七、一个比较实用的排查流程

实际运维时，可以按照下面的流程逐步执行：

网站访问慢
    ↓
检查是否只有单个网站异常
    ↓
检查DNS解析
    ↓
Ping目标服务器
    ↓
检查延迟和丢包
    ↓
Traceroute查看路由
    ↓
MTR持续测试
    ↓
curl拆分DNS/TCP/TLS/TTFB耗时
    ↓
检查CDN节点和缓存
    ↓
检查服务器CPU/内存/IO/带宽
    ↓
多地区、多运营商对比
    ↓
定位客户端、DNS、网络、CDN还是源站问题

不要跳过前面的基础步骤直接下结论。

十八、常见现象与排查方向

实际排障过程中，可以通过现象快速缩小范围。

现象	优先排查方向
域名打开慢，IP正常	DNS
Ping延迟一直很高	路由/物理距离
Ping延迟忽高忽低	链路拥塞/网络抖动
最终节点持续丢包	网络链路
Ping正常但网页慢	TCP/TLS/HTTP/服务器
TTFB很高	Web应用/数据库/源站
只有晚上慢	高峰期拥塞
只有某运营商慢	运营商互联/路由
只有某个地区慢	CDN调度/区域路由
静态文件慢	CDN/缓存/链路
API接口慢	应用/数据库/回源
所有海外服务都慢	本地出口/跨境链路

十九、建立一套标准化网络排障方法

海外网站访问慢，本质上并不是一个单一问题。

它可能发生在：

DNS层
网络层
传输层
TLS层
HTTP层
CDN层
应用层
服务器层

因此，比较高效的处理方式不是不断“换DNS”“重启路由器”或者“升级带宽”，而是建立标准化的排障流程。

可以把整个过程简单概括为：

先DNS，后网络；先延迟，后丢包；再看路由，最后分析应用。

基础排查使用：

nslookup / dig
ping
traceroute / tracert
MTR

进一步定位使用：

curl
浏览器开发者工具
服务器监控
CDN日志
云拨测

通过这些工具逐层拆解，通常就能够判断问题究竟发生在客户端、DNS、运营商链路、国际网络、CDN还是源站服务器。

对于需要长期运行的海外业务，除了故障发生后的排查，更建议建立持续监控机制，对 DNS解析耗时、RTT、丢包率、TCP连接时间、TTFB和整体可用性进行长期观测。

因为很多网络问题并不是“完全不可用”，而是从偶发抖动逐渐发展成持续性的性能问题。

能够提前发现这些变化，往往比故障发生后再进行排查更有价值。