网站在线。
电脑：正常。
手机连 Wi-Fi：正常。
换浏览器：正常。
监控：绿色。
很好。
我关掉 Wi-Fi，让手机切到移动数据。
网站打不开了。
这是学习一个事实最快的方法之一：
“互联网”并不是一张单独的网。
它更像很多网络勉强达成协议，决定互相转发数据。
打开一个网站，要经过不少层
Browser
↓
DNS
↓
Wi-Fi ISP / mobile carrier
↓
internet routing
↓
CDN edge
↓
origin
↓
application从 Wi-Fi 切到移动数据，里面几层都可能一起改变。
家庭 Wi-Fi 可能使用一个 DNS、一条 IPv4 路由和某个 CDN 节点；移动运营商可能改用另一个 DNS、优先 IPv6、经过 CGNAT，再被导向另一处 CDN 边缘。
手机没换，浏览器没换，域名也没换。
换的是互联网路径。
DNS 是很早就应该检查的一层
域名通常需要先解析成地址。IPv4 常见 A 记录，IPv6 常见 AAAA 记录。
不同网络使用不同 DNS Resolver，它们的缓存、更新时间、过滤规则和地理返回结果都可能不同。
于是你刚改完 DNS，Wi-Fi 已经拿到新地址，移动网络还在怀念旧世界。
DNS 缓存非常擅长让开发者怀疑现实。
IPv6 会制造非常漂亮的“只在移动网络坏”
很多移动网络大量使用 IPv6，而家庭网络情况更复杂。
假设：
A record = correct
AAAA record = wrongWi-Fi 走 IPv4，一切正常。移动网络优先 IPv6，于是浏览器自信地朝错误地址出发。
HTML 没变，JavaScript 没变，站点却像“只针对移动数据坏掉”。
这就是为什么网络故障里同时检查 A 和 AAAA 很重要。
“Google 能开”不代表“我的站就必须能开”
两个网络都能上网，不代表它们到每个目标的路径都健康。
路由可能遇到丢包、错误宣告、拥塞、过滤或某段互联异常。另一路径却完全正常。
所以“其他网站都能开”只能证明其他网站能开。
Google 对这个结论应该挺满意。
CGNAT 还会影响限流和风控
IPv4 地址有限，移动运营商经常让许多用户通过 Carrier-Grade NAT 共享少量公网 IPv4。
普通浏览通常没问题，但对 IP 限流、P2P、风控、地理判断等会有影响。一个防护系统可能看到大量用户从同一个公网 IP 出现，然后误以为这个 IP 突然非常勤奋。
CDN 会让不同用户到不同地方
CDN 的目标就是让用户连接较近的边缘节点。因此两个用户访问同一域名，可能抵达不同机房。
这通常很快，也很棒。
但它意味着：
“我电脑能开”不能证明每条区域路径都健康。
同样，Pages 的内部部署 URL 正常，也不能完全证明自定义域名正常。生产检查必须打真实生产域名。
HTTPS 还有自己的一道门
DNS 和路由之后，TLS 还会检查证书、主机名、信任链和协议协商。证书链不完整、旧设备信任库不同或中间设备异常，都可能制造“安全连接失败”。
这时 JavaScript 甚至还没获得登场资格。
有时候不是打不开，而是慢得像打不开
Wi-Fi 往往低延迟、高带宽、信号稳定。移动数据会遇到基站切换、信号波动、丢包和更高延迟。
一个页面如果要发几十个小请求，在 Wi-Fi 上也许很顺，移动网络上却能把每次握手和往返延迟积累成肉眼可见的等待。
性能不只看“JS 包多大”，请求数量和连接成本也很重要。
我现在会怎么对照测试
- Wi-Fi 与移动数据。
- IPv4 与 IPv6。
- 系统 DNS 与另一个可信 Resolver。
- 真实生产域名。
- 无缓存新会话。
- 代理关闭与开启后的差异。
不需要改一行文案都跑全套。但改了 DNS、证书、CDN、Worker、代理路由或自定义域名之后，网络路径本身就是功能的一部分。
几个简单命令
nslookup example.com
dig example.com
curl -4 -I https://example.com
curl -6 -I https://example.com
curl -IL https://example.com它们不会自动修复故障，但能告诉你该怀疑哪一层。
不要一次改五件事
网络问题最容易让人急。换 DNS、改代理、切 SSL 模式、改 Worker 路由、清缓存一起做，网站突然好了。
很好。
是哪一项修好的？不知道。
现在你拥有一个能工作的站，以及五个没人能解释的配置变化。
最后
网站在 Wi-Fi 上正常，只能证明它在那个时间、通过那条网络路径正常。
移动网络可能使用不同 DNS、不同 IP 协议、不同路由、不同 CDN 节点。
Web 在一切正常时把这些机械结构藏得很好。
直到你关掉 Wi-Fi。
然后互联网突然决定给出第二意见。