同一个站点，同一份代码，两份体检报告却截然不同：海外办公室打开只要几百毫秒，大陆的客户却反馈"时快时慢"“有时候干脆打不开”。这大概是出海团队问得最多的一个问题，而它几乎从来不是某一个单点的错。
先分清两类问题：不可用 ≠ 性能差
排查之前先做一件事：把反馈分成两类。
- 不可用：部分地区、部分运营商的用户解析失败或连接失败——这是可用性问题；
- 性能差：都能打开，就是慢——这是性能问题。
两者的排查路径完全不同。把"慢"当"挂"去查（或者反过来），是这类问题迟迟定位不了的最常见原因。
“慢"是分层的，从外到内五层拆
一次页面加载在大陆变慢，来源通常是这五层的叠加：
- DNS 调度：解析把大陆用户调到了境外节点。域名用的是全球 Anycast 没问题，但如果你的 DNS 服务商在大陆没有解析节点、或 GeoDNS 的分区策略粗糙，用户第一步就被送远了。
- 跨境链路：大陆到境外的公网链路质量本身有波动，晚高峰尤其明显。这一层你改不了，但要知道它的存在——它决定了"同样的架构，大陆的延迟下限就是更高”。
- CDN 覆盖与预热：CDN 开了不等于大陆快。大陆没有节点、静态资源没有预热、动态内容（甚至 HTML）从不缓存，每个请求都要回源，前面两层的问题就会被放大。
- 源站位置：源站在海外，意味着每次回源都走一遍跨境链路；源站在大陆或使用大陆友好的托管，回源路径完全不同。
- 前端资源体积：高延迟链路是放大器。海外 200ms 往返感觉不到的 3MB 页面，在 300ms+ 的链路上就是灾难。
“时好时坏"的机理：一个真实案例
我自己的博客（托管在海外边缘网络，大陆有真实流量）2026 年 9 月的数据：全月约 121 万请求，5xx 占 5.79%，几乎全是 504 网关超时。有意思的是它的分布：
- 全部是 GET 请求，每个小时都有 60–240 次的持续基线——不是某次故障，而是常态；
- 首页一个 URL 就占了近 3 万次 504；
- 按地区看，大陆、美国、法国最多（后两者明显是扫描流量）。
根因：HTML 从不被边缘缓存（cf-cache-status: DYNAMIC），每一个页面请求都裸奔回源。源站在扫描流量压力下偶发超时，所有未缓存的请求就一起变成 504——表现就是"时好时坏”。
修复也不复杂：给 HTML 加边缘缓存规则后，暖连接 TTFB 从 0.7–0.9 秒降到 0.26 秒，回源量断崖式下降，504 失去了土壤。这个案例的完整过程，我会在下一篇踩坑文里展开。
一套可以自己动手的自检清单
- 看解析落地：在大陆的机器或拨测节点上
dig你的域名，对比返回的 IP/CNAME 与海外是否一致、是否被调度到远端。 - 多地拨测：至少覆盖北京/上海/广州三个方向的运营商网络，测可用性（能不能连上）而不是只测延迟。
- 分地区 TTFB：用 Core Web Vitals 的真实用户数据（或 RUM 工具）看大陆访客的 TTFB 分布，而不是只看服务器侧监控。
- 资源瀑布图：在大陆网络环境打开一次页面，看瀑布图里哪一段最长——DNS、连接、等待首字节、还是资源下载。
- 确认缓存行为：检查响应头里的缓存状态（如
cf-cache-status），确认 HTML 和静态资源到底有没有被边缘缓存命中。
如果这五步做完你想要一份更系统的答案——基于真实测量数据、按优先级排序的改进项——可以看看下面这个免费诊断。