移动网络打不开而WiFi正常：DNS、443端口与CDN调度排查-北京尧图网络

前几天在群里看到有人丢了一句我们站点只有用手机流量打不开连着 WiFi 一切正常配图是一张白屏截图。这种只有移动网络不行的问题我处理过不少次每次的根因都不一样有一次是解析结果差了十万八千里有一次是 443 端口在某个省份的链路上被中间设备掐断了握手还有一次纯粹是 CDN 把某批用户调度到了一个回源已经挂了半天的节点上。所以看到这个标题我第一反应不是去查 DNS而是先问清楚你说的打不开是圈圈转完给个报错还是转都不转直接白屏这两个症状指向的方向完全不同。这篇内容适合手里有站点、有 App 后端、或者单纯被这类问题折磨过的朋友看我会把 DNS、443 端口、CDN 这三段拆开讲每一步给出可复现的命令和判断标准尽量让你看完就能自己走一遍排查链路。1. 别急着改配置先确认移动网络到底指哪一段链路很多人一上来就说移动网络有问题但这句话太粗了。移动网络只是一个大类它背后是运营商的无线上网卡、基站、核心网、省网出口、互联互通节点这一整条链任何一段的差异都可能造成只有它不行。在动手之前我一般会把问题限定成一个可验证的命题是同一个域名在同一个时刻通过 A 路径能访问、通过 B 路径不能访问。只有把这个对照建立起来后面的排查才有意义。1.1 一条请求在手机上要穿过五道门从你点开链接到页面出来中间至少要过五道门第一道是域名解析手机把你的域名交给运营商的递归服务器拿到一个或一组 IP第二道是路由选路手机拿到 IP 之后数据包要经过基站、核心网、省网出口才能到达目标 IP 所在的网络第三道是TCP 握手向目标 IP 的 443 端口发起连接第四道是TLS 握手协商加密参数、校验证书第五道才是HTTP 请求与响应包括 CDN 节点是否命中缓存、是否回源成功。这五道门里前面的门没过后面的门根本不会响。我强调这个顺序是因为很多人的排查是跳跃的一边怀疑 CDN 有问题一边连 TCP 都没连上。你要是连 443 都没握上手去查 CDN 缓存命中率纯属浪费时间。所以正确的做法是从第一道门开始逐门验证找到第一道失败的门就停下来深挖不要同时怀疑五个东西。1.2 WiFi 和移动数据走的是两套完全不同的路径为什么同样的手机、同样的浏览器切个网络就天差地别因为这两条路径上几乎没有共享的组件。WiFi 通常走的是固网宽带出口 IP 属于某一家固网运营商递归 DNS 大概率是路由器下发的或者公共解析服务移动数据走的是无线接入网出口 IP 属于移动运营商递归 DNS 是运营商自己分配的很多还带本地缓存和调度策略。这两条路径在互联互通层面可能走着完全不同的线路甚至在某些时段拥塞程度差好几倍。更关键的是CDN 和大型站点普遍会根据来源 IP 的网段来做调度。你在 WiFi 下拿到的 IP 属于固网段被调度到就近的固网节点切到移动数据来源 IP 变成移动网段调度系统会给你换一个看起来更近的节点而这个节点未必是健康的。所以只有移动网络打不开这件事八成不是移动网络坏了而是移动网络的路径把你带到了一个平时没人走、也没人巡检的角落。理解这一点后面的排查思路就顺了。提示排查前先固定变量。同一个手机、同一个浏览器、同一时间点、访问同一个 URL只切换网络。别一边换网络一边换设备那样得出的结论没有参考价值。2. DNS 排查先回答解析出来的 IP 对不对我把 DNS 放在第一位不是因为它最容易出问题而是因为它最容易验证一条命令就能出结果。如果两条路径解析出来的 IP 完全一致那你基本可以把 DNS 这一层排除掉把精力放到后面的端口和调度上如果解析结果差异很大那问题很可能就出在这里后面几步甚至可以跳过。2.1 移动网络下递归解析的真实路径很多人以为解析就是查一次记录其实在移动网络里一次解析往往要经过好几层缓存手机本地的 DNS 缓存、运营商递归服务器的缓存、上级缓存最后才到权威服务器。任何一层缓存里的记录过期时间设置得不合理或者某一层缓存了错误的负结果你拿到的就是错的。运营商递归服务器的缓存策略往往比公共解析服务更激进为了省流量和省时延它们会把记录留得比 TTL 更久。这就导致一个很典型的现象你在源站改了记录固网用户十分钟就生效了移动网络用户过了两小时还是老 IP。这时候你去问为什么只有移动网络不行答案就是缓存还没过期。所以我在排查时一定会确认两件事当前解析结果是什么以及这个结果是不是权威服务器给出的。后者需要用指定解析服务器的方式去验证不能只看本地默认结果。2.2 三组命令对照出解析差异真正有效的做法是在同一条链路上分别用默认解析和指定解析去查然后对比。下面这几组命令是我常用的注意short只是让输出更干净正式排查时建议去掉看完整的应答段和 TTL。# 1) 用当前网络的默认 DNS 解析模拟用户的真实体验 dig www.example.com A short # 2) 指定一个公共解析服务看干净的解析结果应该是什么 dig 8.8.8.8 www.example.com A # 3) 直接问权威服务器拿到未经缓存污染的答案 dig ns1.example.com www.example.com A norecurse # 4) 看 CNAME 链路很多 CDN 的调度藏在 CNAME 里 dig www.example.com CNAME trace第 4 条命令尤其值得单独说。大量站点用的是 CNAME 接入方式www先 CNAME 到一个调度域名再由调度域名解析出具体节点 IP。如果 CNAME 链路在某一层断了或者某一层返回了NXDOMAIN你看到的现象就是域名解析失败。用trace可以把整条链路一层层打出来哪一层出了问题一目了然。在手机侧你也可以用系统自带的工具做交叉验证。安卓上可以用nslookup类的应用iOS 上可以用一些网络诊断工具核心目的只有一个确认手机在当前网络下实际拿到的是哪一组 IP。2.3 解析异常的四种典型形态我把常见的解析异常归成四类每一类的表现和处置方式都不一样混在一起看很容易误判。异常形态典型表现判断依据处置方向解析到错误 IP能 ping 通但页面不对或直接超时与权威结果比对不一致联系解析服务商清理缓存解析为空报找不到服务器返回 NOERROR 但无 A 记录检查记录配置与 CNAME 链路解析到内网地址连接被拒或直接超时返回 10.x / 192.168.x 段检查是否存在解析污染或配置错误解析超时转圈很久才失败dig无应答重试才成功检查递归服务器可达性与链路质量第一类解析到错误 IP最隐蔽。有时候你会解析到一个完全不相干的地址连接也能建立但返回的是一个奇怪的页面或者直接超时。这种情况用权威查询一比对就能发现。第二类解析为空通常是 CNAME 链路的某一环没配置好或者记录被人误删。第三类要注意正常的公网站点不应该解析到内网段一旦出现要么是配置写错了要么是链路中间有设备在干扰解析两种情况都得查。第四类解析超时往往不是 DNS 本身的问题而是链路质量差UDP 53 端口丢包严重重试一次就成功了这种问题在弱信号环境下特别常见。3. 443 端口分清连不上还是连上又断了如果解析结果没问题下一步就是端口。现在绝大多数站点走 HTTPS也就是 443 端口。这里有一个非常关键但经常被忽略的区分TCP 连接根本没建立起来和TCP 建立了但 TLS 握手失败是两个完全不同的问题排查方向也完全相反。前者是网络层或传输层的问题后者是加密协商层的问题。3.1 用 curl -v 把一次握手切成四段curl -v是我最常用的第一把刀因为它会把整个过程打印得非常清楚。你不需要抓包光看输出就能定位到断在哪一步。# 完整输出握手过程只看关键行 curl -v --connect-timeout 10 https://www.example.com/ 21 # 只测 TCP 连通性不发起 TLS curl -v --connect-timeout 10 telnet://www.example.com:443 # 强制指定协议版本排查协议协商问题 curl -v --tlsv1.2 https://www.example.com/输出里你会看到几个关键节点Trying x.x.x.x...表示正在发起连接Connected to ...表示 TCP 握手成功TLS handshake相关的行表示正在协商SSL certificate verify ok表示证书校验通过最后是 HTTP 状态行。如果卡在Trying之后长时间没动静那是 TCP 层不通如果Connected之后卡住那是 TLS 层协商出问题如果证书校验报错那就是证书链的问题。我特别强调--connect-timeout这个参数。默认的超时时间很长你在弱网环境下等一分钟才知道失败排查效率极低。设成 10 秒快速失败快速重试反而更容易看出规律。3.2 TLS 层的三个高频断点在移动网络下TLS 握手失败的比例明显高于固网原因主要集中在三个地方。第一个是 SNI 相关的处理。现代浏览器和客户端在 TLS 握手的 ClientHello 里会带上 SNI 字段告诉服务器我要访问的是哪个域名。一些中间设备在处理这个字段时行为不一致可能导致握手被中断或者被重定向。表现是直接访问 IP 能连上访问域名就失败。验证方法是把 SNI 显式指定出来openssl s_client -connect www.example.com:443 -servername www.example.com -brief如果加上-servername就通了不加就不通那问题基本就定位在 SNI 处理上。第二个是证书链不完整。有些站点的证书只部署了叶子证书没有带上中间证书。桌面浏览器因为自带了一套中间证书库能自动补全所以你在电脑上看一切正常但手机系统或者某些客户端没有这套补全机制校验就会失败。表现是电脑能开手机报证书错误。验证方法是看openssl s_client输出里的Verify return code如果是unable to get local issuer certificate那就是链不完整。第三个是协议版本和加密套件协商失败。老旧的客户端只支持某些旧协议服务器如果只开了新协议协商就会失败。这种情况在移动端反而少见因为手机系统版本普遍较新但在一些定制设备上仍然会遇到。用--tlsv1.2之类的参数强制指定版本就能快速判断是不是这个原因。3.3 抓包之外的取证手段不是每个人都有条件在手机上抓包所以我会准备几个不需要抓包的替代手段。第一是换端口测如果 443 不通但 80 通说明目标主机的网络是可达的问题出在 443 这个端口上第二是换协议测用telnet或nc直连 443看能不能建立连接第三是换路径测用mtr或者traceroute看数据包在哪一跳开始丢。# 看路径上哪一跳开始异常 mtr -rw -c 20 www.example.com # 直接测端口连通性 nc -zv -w 5 www.example.com 443mtr的输出里如果某一跳开始持续出现高丢包或者超时而后面几跳又恢复正常那说明这一跳只是不响应探测包不代表链路断了如果从某一跳开始后面全部超时那才是真的断了。这个判断经验很重要很多人看到中间某一跳 100% 丢包就慌了其实那只是设备策略。4. CDN 与调度为什么同一个域名在不同网络里指向不同机房走到这一步解析没问题、端口也通但页面就是打不开或者加载极慢那大概率是 CDN 调度的问题。现在的站点很少是单机部署绝大多数都挂在 CDN 后面而 CDN 的核心能力就是给不同的人分配不同的节点。这个能力在提升体验的同时也制造了一类特有的故障大部分用户正常一小部分用户被分配到了有问题的节点。4.1 ECS 与运营商线路调度CDN 决定给你哪个节点靠的是调度系统。调度系统最重要的输入之一就是你的来源 IP。为了更精准很多调度方案会使用 EDNS Client Subnet也就是在 DNS 查询里携带客户端子网信息让权威服务器能根据真实用户网段返回最合适的节点。这个机制在固网下工作得很好但在移动网络下会遇到麻烦运营商的递归服务器往往位于省级甚至大区级它携带的子网信息可能粒度很粗或者干脆不带导致调度系统只能按递归服务器所在的位置来分配节点。结果就是你人在城市 A但被分配到了城市 B 甚至更远的节点。这个节点可能负载很高可能回源链路拥塞也可能干脆处于亚健康状态。固网用户因为子网信息准确很少被分到这类节点所以只有移动网络不行这个现象就出现了。验证方法是在不同网络下分别解析对比拿到的节点 IP然后查这些 IP 的归属和机房位置# 在不同网络下分别执行记录结果 dig www.example.com A short # 查 IP 归属用任意 whois 服务 whois 203.0.113.10 | grep -i -E netname|country|descr如果移动网络下拿到的节点明显更远或者和固网拿到的完全不是一批那调度差异就确认了。这时候你能做的通常是联系 CDN 服务商说明这个网段的调度不合理请他们调整调度策略或者把这个网段加白。4.2 单节点故障造成的局部性打不开比调度不合理更常见的是单节点故障。CDN 有几百上千个节点任何一个节点出问题受影响的只是被调度到该节点的那部分用户。如果你的用户里移动网络占比不高那这个故障在整体监控上看就是成功率轻微下降很容易被忽略但对那部分用户来说就是 100% 打不开。我遇到过好几次这种情况节点本身还在响应健康检查所以没有从调度池里摘除但它的回源链路已经断了导致所有未命中缓存的请求全部超时。已缓存的静态资源还能返回动态接口就全挂了。表现是页面框架能出来但数据一直在转圈。这种半死不活的节点最难查因为从监控大盘上看一切正常。判断方法只有一个锁定具体节点。先在移动网络下解析出 IP然后直接对这个 IP 发起请求带上正确的 Host 头# 绕过 DNS直接打指定节点验证节点本身是否正常 curl -v -H Host: www.example.com https://203.0.113.10/ --resolve www.example.com:443:203.0.113.10 -o /dev/null -w %{http_code} %{time_total}\n--resolve这个参数非常好用它能让你在不改 hosts 文件、不影响系统解析的前提下把某个域名强制指向指定 IP。多试几个节点如果只有某一个节点返回 5xx 或者耗时异常问题就锁定了。4.3 用多线路拨测做交叉验证如果没有条件在真实手机上反复切换网络可以用第三方的多线路拨测服务做交叉验证。这类服务通常覆盖多个运营商、多个省份能从不同出口去请求你的域名并给出解析结果、连接耗时、首字节时间、HTTP 状态码。把结果按运营商分组看如果某一家运营商的成功率明显低于其他家那问题就在这条链路上而不是你的服务端。我自己做这套验证时会看三个指标解析耗时、TCP 连接耗时、首字节时间。解析耗时高说明 DNS 有问题TCP 连接耗时高说明网络链路有问题前两个都正常但首字节时间高说明是服务端处理慢或者回源慢。这三个指标一分开问题基本就定位到哪一层了。5. 几个容易被忽略的软性原因前面四节讲的都是硬问题有明确的失败点。但实际排查中还有一类问题特别烦人没有明确报错就是慢就是偶尔失败。这类问题往往和协议栈、链路特性有关用常规的连通性测试是测不出来的。5.1 IPv6 优先与假死现在很多手机在移动网络下会优先拿到 IPv6 地址。如果站点同时有 A 和 AAAA 记录但 IPv6 那条链路实际上是断的或者质量极差就会出现一个经典现象客户端优先尝试 IPv6等了很久超时然后回退到 IPv4页面才打开。用户感受到的就是要等十几秒才出来或者有时候能开有时候不能。这个问题之所以隐蔽是因为你用 IPv4 去测一切正常用 IPv6 去测也能 ping 通但实际 TCP 连接就是建立不起来。验证方法是禁用 IPv6 再试# 强制走 IPv4 curl -4 -v https://www.example.com/ # 强制走 IPv6 curl -6 -v https://www.example.com/如果-4秒开、-6卡住那就是 IPv6 链路的问题。处置方式要么是修好 IPv6 的回程链路要么是临时把 AAAA 记录摘掉让客户端直接走 IPv4。长期来看还是应该修好因为 IPv6 在移动网络下的覆盖越来越广摘记录只是权宜之计。5.2 MTU 黑洞这个坑更隐蔽。移动网络的 MTU 往往比固网小尤其是经过某些隧道封装之后。如果路径上的设备对 ICMP 的需要分片消息做了过滤就会出现所谓的 MTU 黑洞小包能过大包直接丢而且没有任何反馈。表现是首页能打开但图片加载不出来或者接口小数据量正常大数据量就卡死。判断方法是看请求大小和失败的关系。如果小文件秒下、大文件卡住就要高度怀疑 MTU。可以手动把 MTU 调小来验证# 发送指定大小的包做分片测试找出实际可用的 MTU ping -c 3 -s 1400 -M do www.example.com ping -c 3 -s 1200 -M do www.example.com-M do表示禁止分片如果 1400 失败、1200 成功那实际可用的 MTU 就在两者之间。这个测试在桌面端做比较方便手机端就只能通过观察大小文件表现差异来间接判断了。5.3 HTTP/3 的 UDP 443现在不少站点启用了 HTTP/3走的是 UDP 443 端口。有些移动网络对 UDP 的处理策略比较保守会限速甚至直接丢弃导致 HTTP/3 连接建立失败。客户端通常会在失败后回退到 HTTP/2但这个回退是有超时的用户就会感受到明显的延迟。验证方法是强制指定协议版本# 强制使用 HTTP/2走 TCP curl --http2 -v https://www.example.com/ # 强制尝试 HTTP/3 curl --http3 -v https://www.example.com/如果--http3失败而--http2正常那基本可以确认是 UDP 443 的问题。处置思路有两个一是调整服务端的 Alt-Svc 策略让客户端更谨慎地尝试 HTTP/3二是接受现状因为客户端有回退机制只是体验上会差一点。5.4 运营商透明缓存最后说一个比较边缘但确实存在的情况。部分运营商会做透明的 HTTP 缓存把热门资源缓存在自己网内。这个机制在大多数时候是好事能加速访问但如果缓存里的内容过期了没更新或者缓存了错误的内容用户就会看到页面是几天前的版本或者资源加载一半报错。判断方法是看响应头里有没有异常的缓存标识比如Via、X-Cache、Age这些字段出现了不是你配置的取值。如果发现有额外的缓存层可以在资源 URL 上加版本号或者查询参数绕开缓存。根治方法还是上 HTTPS端到端加密之后透明缓存就没法插手了。6. 把排查过程固化成一张表这套流程我走过很多次之后整理成了一张对照表遇到类似问题时按顺序往下走就行。表格里的验证方式都是可以立即执行的不需要额外准备环境。层级现象特征验证方式常见根因DNS报找不到服务器、解析超时默认解析与权威解析对比缓存过期、CNAME 链路断裂路由TCP 连接超时、无响应mtr查看丢包跳数链路拥塞、互联互通质量差TCP连接被拒、长时间无响应nc -zv测端口端口不通、中间设备拦截TLS证书错误、握手中断openssl s_client证书链不全、SNI 异常CDN局部用户失败、节点返回 5xx--resolve直打节点单节点故障、调度不合理协议栈大文件卡顿、偶发超时强制 IPv4/IPv6、调 MTUMTU 黑洞、IPv6 链路差缓存内容陈旧、资源加载不全查看Via、Age响应头透明缓存未刷新用这张表的时候有个原则从上往下走遇到第一个不符合预期的就停下来深挖不要跳着看。我见过太多人一上来就去查 CDN 日志结果发现连 DNS 都没解析对白白浪费半天。注意所有验证动作都要在同一时间段完成。网络问题是高度时变的早上九点测出来的结果和晚上八点可能完全不同。如果你的结论建立在跨时段的数据上那这个结论大概率是错的。还有一点经验值得单独提保留现场。发现问题的时候第一件事是把当时的解析结果、curl -v的完整输出、mtr的记录都存下来最好连时间戳一起。很多问题等你准备好工具再复现它就消失了。我吃过好几次亏等我把环境搭好一切都正常了只能干瞪眼。我个人在实际操作中的体会是这类只有某个网络不行的问题最忌讳的是先入为主。有人一上来就认定是 DNS有人一口咬定是 CDN然后所有的验证都在往自己预设的方向找证据。真正高效的做法是把链路拆成几段每段设定一个明确的通过标准用数据说话。上面那张表里的每一行通过标准都很清楚解析结果一致、TCP 能握手、TLS 校验通过、节点响应正常。哪一行没过问题就在哪一行中间没有模糊地带。另外再分享一个小技巧如果你手上有一台能连移动网络的设备装一个能看请求详情的工具把失败的那次请求从头到尾记录下来比你在电脑上猜半天都有用。真实用户侧的完整链路数据永远比你在机房里做的任何模拟都更接近真相。

移动网络打不开而WiFi正常：DNS、443端口与CDN调度排查

相关推荐

Windows 11退出Microsoft账户：彻底剥离云权限的四层清理法

HIL总线仿真实战：CAN、CAN FD与车载以太网方案详解

高校AI落地：高优先级场景评估与实施路径指南

更多资讯

3 步把旧平衡车改造成可编程双电机动力源：hoverboard-firmware-hack-FOC FOC 固件实践指南

LinkSwift 网盘直链下载助手完整指南：8 大网盘真实下载地址一键获取方法

Plain Craft Launcher 2插件开发指南：扩展启动器功能的完整教程

第三章对社会与人类的深远影响：在变革中寻找共生之道

第二章潜在应用场景拓展：大模型渗透万物的未来图景

ABP中HttpClient的POST及GET请求方式

今日更新

Verilog实现FPGA密码锁：矩阵键盘与状态机设计实战

数据服务监控运维实战：从指标体系到告警治理与故障排查

FreeRTOS任务通知实战详解：内核原理、API与避坑指南

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？