移动数据开着网页转圈转到超时切回家里的宽带同一个地址秒开——这种情况我一年里能碰到七八次。第一次遇上时我以为是站点挂了结果同事在隔壁工位刷得好好的后来才慢慢摸清问题几乎从来不在整站上而是卡在某一条链路上域名解析在蜂窝网络里拿到了不一样的答案、443 端口在某个出口被掐断、或者 CDN 把这个运营商的用户调度到了一个正在带病工作的边缘节点。这篇就把我这些年从 DNS、443 端口到 CDN 三层挨个排查的完整方法摊开讲包括每一步用什么命令、看到什么结果说明什么、以及哪些是我踩过坑之后才总结出来的判据。适合自己维护站点、做前端联调、或者单纯被只有手机流量打不开折磨过的朋友看完至少能自己定位到是哪一层出的问题而不是在群里干喊你那边能打开吗。1. 先把打不开拆成可观测的失败点1.1 浏览器那句报错其实已经告诉你在第几层大部分人排查时的第一反应是刷新、换浏览器、清缓存这套动作做完没效果就卡住了。真正有效的起点是把打不开这个模糊感受翻译成一个具体的失败点。移动端浏览器给出的错误码虽然各家措辞不同但指向的层次非常明确我在排查时基本靠它决定下一步往哪儿走。DNS_PROBE_FINISHED_NXDOMAIN或者找不到服务器说明域名根本没解析出 IP问题在 DNS 层跟 443、跟 CDN 回源都没关系直接跳到第 2 节。ERR_CONNECTION_TIMED_OUT是 TCP 三次握手没完成SYN 发出去没有任何回应典型的端口不通或被中间设备静默丢包看第 3 节。ERR_CONNECTION_RESET是对方回了 RST说明包到了、但被主动拒绝可能是服务端限流、也可能是链路上的设备插了一手。ERR_SSL_PROTOCOL_ERROR、ERR_CERT_AUTHORITY_INVALID、ERR_CERT_COMMON_NAME_INVALID这三个都属于 TCP 通了、TLS 握手阶段炸了看 3.2。ERR_HTTP2_PROTOCOL_ERROR更靠后连接和握手都成了是应用层帧出了问题。提示移动端浏览器的报错页面能展开看详细错误码很多人只看标题就关掉了。这个错误码是整条排查链上信息量最大的一个输入值得多花十秒钟确认。我一般会把上面这几类失败点写成一张小纸条贴在显示器边上因为排查时人很容易慌一慌就开始瞎试。有了这张对应关系看到报错基本能砍掉七成的排查范围不用从头扫一遍。1.2 蜂窝网络和宽带到底差在哪几个地方同样是访问一个 HTTPS 站点手机流量和家里宽带走的路径差异比大多数人想的大得多。我整理过一张对照表每次遇到只有移动网络不行的问题就照着这张表逐项排除效率比凭感觉试高很多。差异点蜂窝网络固定宽带常见故障表现接入网基站到核心网链路更长光猫到局端链路短丢包、抖动更明显出口 IP大区共享出口NAT 层级多多为独立或小范围共享CDN 调度到远端节点MTU常在 1400 上下隧道开销大一般为 1500大包被丢小页面正常大页面卡死DNS递归服务器由运营商指定可自选家庭路由常改过解析结果与预期不符IPv6普及率高常优先走 v6视路由器配置而定单边可达导致部分网络失败中间设备链路环节多策略更复杂相对简单特定端口或特征被限速这张表里最容易被忽略的是 MTU 和 IPv6 两行。前者导致的现象特别迷惑首页能打开一进详情页或者一上传图片就卡住后者导致的现象更迷惑WiFi 下好好的切到流量就挂因为宽带路由器压根没开 v6问题被掩盖了。这两个坑我在第 3 节会展开讲它们是我踩过最深的两次。还有一点值得先说明所谓只有移动网络打不开很多时候并不是整个蜂窝网络都不行而是某一家运营商的某一段出口不行。同一间办公室里同事用另一家运营商的卡就能打开这种部分人不行的现象恰恰是 CDN 调度差异最典型的表现反过来说如果所有蜂窝网络都不行、只有宽带行那更可能是域名解析或者服务端对移动端出口 IP 段做了策略。2. DNS 排查解析结果在蜂窝网络里迷路了吗2.1 为什么同一个域名两种网络解析出的 IP 不一样这是最常见的一类原因也是最容易被误判成服务器挂了的一类。域名解析不是查一本固定的电话簿递归解析服务器会根据自己的位置、缓存状态、以及请求里携带的客户端子网信息返回不同的结果。运营商的递归服务器通常部署在大区机房它替成千上万个用户去问权威服务器权威服务器看到的来源是这台递归服务器的地址于是返回一个离这台递归服务器最近的节点 IP。问题就出在这儿这台递归服务器可能在省会而你在城郊它返回的节点对你来说未必是最优的甚至可能是一个已经下线但缓存还没过期的旧地址。更麻烦的是如果递归服务器没有正确携带客户端子网信息权威侧就只能按递归服务器的位置做粗粒度调度调度结果可能偏得很离谱。我遇到过一次特别典型的某站点在宽带下解析到同城节点延迟十几毫秒切到流量后解析到一个跨了大半个国家的节点延迟飙到一百多页面加载超时。站点本身完全健康纯粹是调度把人送错了地方。2.2 四路对照实验把解析链路摊开看排查 DNS 我固定做一个四路对照分别在两种网络下、对两种递归服务器各查一次四组结果摆在一起问题基本无所遁形。命令很简单# 第一路用系统默认 DNS 解析蜂窝网络下执行 dig short example.com A # 第二路指定一个公共递归服务器解析 dig 223.5.5.5 example.com A short # 第三路同时看 CNAME 链路别只看最终 A 记录 dig example.com A noall answer # 第四路查 AAAA确认 IPv6 解析情况 dig example.com AAAA short第一路和第二路的结果如果一致说明运营商递归服务器和公共递归服务器的判断相同DNS 层大概率没问题可以往下走。如果两者不一致就要看差在哪儿是 IP 完全不同调度差异还是第一路返回空解析失败还是第一路返回了明显不属于该服务商网段的地址缓存过期或配置错误。第三路看 CNAME 链路是我后来加上的因为很多站点前面挂了一层调度域名最终 A 记录是调度系统动态给出的。有些递归服务器在 CNAME 链路的中间某一步就解析失败了表现出来就是完全没有记录而不是记录不对。这两种情况的处理方式完全不同前者要找权威侧确认链路是否完整后者要等缓存过期或者联系运营商刷新。第四路容易被跳过但很关键。如果蜂窝网络下 AAAA 有记录、而宽带下没有那说明问题可能出在 IPv6 路径上而不是 DNS 本身。这时候要做的不是改 DNS而是去测 v6 连通性具体方法在 3.4。注意做对照实验时一定要把手机的数据网络和 WiFi 彻底分开关闭WiFi 助理这类会在 WiFi 信号弱时自动切到蜂窝数据的功能否则你根本不知道自己测的是哪条链路。我第一次排查时就被这个功能坑了半小时数据全是乱的。2.3 解析异常的三种典型成因和处置方式对照实验结果出来后常见的成因无非三类处置方式差别很大。第一类是递归缓存未过期。站点换了 CDN 服务商或者下线了旧节点权威侧的记录已经更新但运营商递归服务器还抱着旧记录不放TTL 没到就不刷新。表现出来就是只有部分网络解析到旧 IP而旧 IP 已经不通了。处置方式有两个一是等 TTL 自然过期二是临时调低权威侧的 TTL 再变更。我现在的习惯是任何涉及 IP 变更的操作提前一天把 TTL 从 3600 降到 300变更完观察一天再调回去这样即使出问题影响窗口也就五分钟。第二类是调度依据缺失。权威侧拿不到客户端子网信息只能按递归服务器位置调度。这种情况自己改不了只能推动服务商在权威侧开启客户端子网支持或者在调度策略上做兜底——比如对识别不出位置的请求返回一个覆盖范围更广的任播地址。作为站点维护方能做的排查是用两路结果对比如果蜂窝网络解析到的节点和宽带解析到的节点地理距离明显不合理基本可以判定是这类问题。第三类是CNAME 链路在某类递归服务器上中断。有些调度服务商的 CNAME 目标域名在部分递归服务器上无法完成解析报 SERVFAIL。这时候dig的返回会是空的但加trace能看到断在哪一步dig trace example.com A这个命令会从根开始一级级问下来输出很长但断点位置一目了然。我一般只在怀疑链路问题时才用日常排查用前四路就够了。处置上如果是自己可控的域名最直接的办法是把 CNAME 扁平化减少中间层级如果必须保留多层就在权威侧配置好胶水记录减少额外查询。这些操作听起来琐碎但真出问题时能省下大量沟通成本。3. 443 端口排查TCP 和 TLS 到底卡在哪一步3.1 先分清连不上和连上了但握手失败很多人的排查停在ping 得通吗这一步但 ping 用的是 ICMP跟 443 端口通不通完全是两回事。ICMP 通只能说明 IP 层可达TCP 层可能被拦得干干净净。正确的做法是直接对 443 做连通性测试我用得最多的是 curl 的详细模式和 openssl 的连接测试。# 看 TCP 连接和 TLS 握手全过程 curl -v --connect-timeout 8 https://example.com/ -o /dev/null # 只测 TCP 层不涉及 TLS curl -v telnet://example.com:443 --connect-timeout 8 # 绕过 DNS直接指定 IP 测试 curl -v --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null第一个命令的输出信息量最大。如果卡在Trying 203.0.113.10...之后就没了说明 TCP SYN 发出去没有回应是端口不通或者被静默丢弃。如果出现Connected to example.com之后卡在 TLS 阶段那 TCP 是通的问题在握手往下看 3.2。如果直接Connection reset by peer说明对方回了 RST可能是服务端限流、也可能是链路上的设备主动拒绝。第二个命令专门剥离 TLS把问题范围缩到最小。有些时候 curl 的 HTTPS 报错信息混杂了 DNS、TCP、TLS 三层的原因单独测一次 telnet 能立刻区分开。第三个命令是我排查 CDN 问题时的主力工具。用--resolve把域名强行绑到指定 IP可以绕过 DNS 直接验证某个节点的可用性后面第 4 节会反复用到。3.2 TLS 握手四件套SNI、协议版本、证书链、加密套件TCP 通了但握手失败我一般按四个方向查顺序是从外到内。SNI 是否正常携带。现在一台服务器上跑几十个站点是常态服务端靠 TLS 握手第一个包里的 SNI 字段决定出示哪张证书。如果客户端没带 SNI服务端要么返回默认证书域名对不上报证书错误要么直接中断连接。移动端某些老旧浏览器或者 App 内置的 WebView 在这个环节会有差异。验证方法openssl s_client -connect 203.0.113.10:443 -servername example.com -showcerts带上-servername和不带结果对比一下如果带上就正常、不带就报错说明服务端没有配默认证书需要补一张兜底证书。这个改动很小但能救掉一批老客户端。协议版本和加密套件是否匹配。有些服务端为了安全把 TLS 1.0/1.1 关掉了只留 1.2 以上而部分老旧移动设备只支持到 1.1握手直接失败。反过来也有服务端配置过严导致某些加密套件协商不上的情况。测试时指定版本试一遍openssl s_client -connect example.com:443 -servername example.com -tls1_2 openssl s_client -connect example.com:443 -servername example.com -tls1_3两个版本分别试哪个能通、哪个不能通结论很直接。我一般不主张为了兼容老旧设备把协议降到 1.0那是拿安全换兼容更合理的做法是引导升级或者在边缘层做协议适配。证书链是否完整。这是我最常遇到、也最容易被误判的一类。服务端如果只配了站点证书、没配中间证书桌面浏览器因为本地缓存过中间证书所以一切正常而全新的移动设备本地没有缓存就会报证书颁发机构不受信任。表现出来就是我电脑能开、手机不行而且换一台从没访问过的电脑也打不开。验证方法openssl s_client -connect example.com:443 -servername example.com -showcerts 2/dev/null | grep -c BEGIN CERTIFICATE正常应该返回 2 或 3站点证书加一至两张中间证书。如果只返回 1那就是链不完整需要把中间证书补上。这个问题的隐蔽性在于它跟网络类型没有直接关系但因为移动设备更新换代快、本地缓存少所以表现出来就像是移动网络专属故障。证书有效期和域名匹配。这两个属于基础项但真出问题时排查起来一样费劲。openssl的输出里会明确写出Not After和subject扫一眼就能确认。我见过一次因为证书自动续期脚本静默失败证书过期了两天而恰好那两天只有新设备访问出问题老设备因为会话复用还在正常工作查了半天才想起来看有效期。注意用openssl s_client测试时一定不要漏掉-servername参数。现代服务端几乎都依赖 SNI 选择证书不加这个参数测出来的结果不能代表真实浏览器行为很容易得出错误结论。3.3 MTU 和分片蜂窝网络里最隐蔽的一刀这一类问题我把它排在最坑第一位因为它表现出来的现象跟网络故障完全不像。典型症状是首页能打开图片加载不出来或者登录请求发不出去一直在转圈或者小接口正常、大接口超时。很多人第一反应是服务端接口慢实际上一查是包太大被丢了。蜂窝网络的链路层开销比以太网大MTU 常常在 1400 到 1450 之间而服务端和大多数客户端默认按 1500 来算。当一个大包发出去路径上某台设备发现超过自己的 MTU 又不允许分片就会静默丢弃。关键点是静默——它不回 ICMP 的需要分片消息于是发送方一直重传、一直失败表现出来就是卡死。验证方法很朴素用 ping 逐步试探最大可通包长# 1472 28 1500以太网标准 ping -M do -s 1472 example.com # 逐步往下降找临界值 ping -M do -s 1400 example.com ping -M do -s 1372 example.com-M do表示禁止分片-s是数据部分长度加上 28 字节的 IP 和 ICMP 头就是实际包长。如果 1472 通、1400 不通说明问题不在 MTU如果 1472 不通、1400 通那基本可以确认 MTU 偏小。找到临界值之后怎么处理客户端侧调不了运营商的链路参数能做的是在服务端或者边缘层把 TCP 的 MSS 调小让服务端主动按更小的包发# 在服务端网卡上设置 MSS 钳制 iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --set-mss 1360改完之后要清掉连接追踪里的旧会话否则老连接还按原来的 MSS 走。这个操作我在三四个项目里做过每次都是“改完立刻见效”但代价是稍微牺牲一点传输效率属于典型的用性能换可用性。3.4 IPv6 单边可达造成的个别网络打不开这一类问题的迷惑程度不亚于 MTU。现在的移动网络 IPv6 普及率很高很多移动端会优先走 v6而家里的宽带路由器可能压根没开 v6或者开了但上游不支持。于是同一台设备、同一个域名在流量下走 v6、在 WiFi 下走 v4两条路径的健康状况完全不同。症状很有辨识度只有蜂窝网络打不开而且不是所有蜂窝网络都不行是开了 v6 的那部分不行。如果服务端的 v6 地址配置有误、或者 v6 回源链路有问题就会出现这种单边故障。排查分两步。先确认解析层面有没有 AAAAdig example.com AAAA short有记录的话再强制走 v6 和 v4 分别测一次curl -6 -v https://example.com/ -o /dev/null --connect-timeout 8 curl -4 -v https://example.com/ -o /dev/null --connect-timeout 8如果-6超时、-4正常问题就在 v6 路径上。这时候再往下查是服务端 v6 监听没开、防火墙没放行、还是上游 v6 路由有问题。工具上可以用traceroute -6看断在哪一跳不过移动网络的 v6 路由经常不响应探测看到一堆星号是常态不要据此下结论。处置方式要看具体情况。如果是自己服务端的问题把 v6 监听和防火墙补齐就行如果短时间内修不好可以在 DNS 侧临时把 AAAA 记录摘掉让所有流量回落到 v4先把可用性救回来再从容修复。这个先摘 AAAA的操作我做过不止一次属于应急手册里的常备项。4. CDN 排查为什么只有某个节点出问题4.1 CDN 是怎么把不同网络的人分到不同节点的理解调度原理才能理解为什么只有移动网络不行。CDN 的调度系统主要看两样东西用户用的哪家递归服务器、以及用户出口 IP 落在哪个网段。移动网络的出口 IP 是大区共享的一个出口后面可能挂着几十万用户调度系统看到这个 IP会把它归到某个大区的节点池里。问题就在于这个大区可能划得很粗。如果调度系统把某个运营商的整个省份都归到一个节点池而那个池子里恰好有一台节点在带病工作——磁盘满了、回源超时、证书没同步——那么这个省的所有该运营商用户就全挂了而其他运营商的用户完全无感。这种故障在监控上很难被发现因为监控探针通常部署在几个固定的机房探针走的路径跟真实用户完全不同。我经历过一次某台边缘节点的回源配置错了导致缓存未命中时全部超时。监控显示站点可用率 99.9%因为探针访问的资源大部分命中了缓存但真实用户里有一家运营商的用户几乎全挂因为他们的请求恰好被调度到那台节点而且访问的是动态接口、全部未命中缓存。还有一种情况是节点池容量不足。某个大区的节点数量本来就少赶上晚高峰流量上涨新连接建不上表现出来就是晚上打不开、白天正常。这种问题在 CDN 侧看是容量问题在用户侧看就是玄学。4.2 用本地域名绑定做节点对照实验排查 CDN 问题核心思路是绕过 DNS直接打节点。只要能拿到该网络下解析出的节点 IP就能一个个测过去判断是单节点问题还是全网问题。第一步在出问题的网络下拿到解析结果。注意这一步必须用出问题的网络来做用宽带查到的 IP 没有意义dig short example.com A第二步把拿到的 IP 逐个用--resolve绑定测试。如果解析出多个 IP全部测一遍curl -v --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null --connect-timeout 8 curl -v --resolve example.com:443:203.0.113.11 https://example.com/ -o /dev/null --connect-timeout 8如果某个 IP 超时、其他 IP 正常那就是单节点故障结论很明确直接找服务商处理这台节点。如果所有 IP 都不通那问题不在节点上要么是这个网络到这批 IP 的路径有问题要么是服务端整体有问题。第三步反过来验证。用宽带解析出的 IP在移动网络下测试。如果移动网络访问宽带解析出的 IP 是通的那就彻底坐实了调度把你送到了一个坏节点这个结论。这种情况下临时解法是在客户端侧修改解析结果但更合理的做法是推动 CDN 侧把坏节点摘掉。提示--resolve参数不会修改系统解析只影响当前这一次 curl 请求非常安全可以放心在生产环境之外的机器上反复试。4.3 回源、缓存和中间设备的暗坑节点本身健康但内容出不来这种情况要往缓存和回源方向查。最常见的三类。缓存键不一致导致命中率异常。有些站点的缓存键里带了Accept-Encoding、User-Agent这类字段移动端浏览器的请求头和桌面端差异很大结果就是移动端全部未命中、全部回源。回源链路一旦有点慢移动端就表现为超时而桌面端因为命中缓存所以飞快。排查方法是看响应头里的缓存命中标识对比两种网络下的返回curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ | grep -i -E x-cache|age|viaage是 0 或者没有、x-cache显示 MISS说明没命中缓存。如果两种网络下命中状态差很多那就是缓存键设计的问题需要精简缓存键里的可变字段。回源超时导致的边缘等待。边缘节点缓存未命中时要去源站取如果源站响应慢边缘节点会一直等用户侧看到的就是转圈。这种情况下节点本身是好的问题在回源链路。判断方法是看响应时间命中缓存的请求几十毫秒未命中的请求几秒甚至超时两个群体的差异极其明显。这时候要优化的是源站响应速度或者边缘的回源策略比如开启回源超时后的旧内容兜底。中间设备的策略差异。蜂窝链路上可能有一些设备会基于请求特征做处理比如对没有User-Agent的请求、对特定方法的请求采取不同策略。这类问题最难查因为现象不稳定、时好时坏。我的做法是用最小化请求做二分先用一个最朴素的 GET 请求测然后逐步加上请求头看加到哪一个开始出问题。这个过程笨但有效我靠它定位过一起因为请求头里某个字段触发的间歇性失败。5. 客户端和应用层的那些坑5.1 HTTP/3 与 UDP 443 的隐患现在很多站点开了 HTTP/3走的是 UDP 443。浏览器第一次访问时走 TCP拿到响应后如果看到Alt-Svc头就会记住这个站点支持 HTTP/3后续访问尝试走 UDP。问题在于UDP 在部分链路上的待遇和 TCP 完全不同可能出现 UDP 被限速、被丢弃、或者被中间设备特殊处理的情况。症状很有特点第一次访问正常第二次开始变慢或者超时清掉浏览器数据后又恢复正常过几次又开始出问题。这就是典型的记住了 HTTP/3、但 HTTP/3 路径不通、回落机制又不够快。验证方法是临时禁用 HTTP/3 再测# 强制使用 HTTP/1.1绕开 HTTP/3 curl -v --http1.1 https://example.com/ -o /dev/null --connect-timeout 8 # 尝试 HTTP/2 curl -v --http2 https://example.com/ -o /dev/null --connect-timeout 8如果--http1.1和--http2都正常只有默认行为可能协商到 HTTP/3异常那基本可以锁定是 UDP 路径问题。这种情况下的处置短期可以在边缘侧关掉 HTTP/3 或者缩短 Alt-Svc 的有效期长期要看具体链路的 UDP 质量不能一概而论。注意判断 HTTP/3 问题时一定要清掉客户端的 Alt-Svc 缓存否则你改了服务端配置客户端还在按旧记录尝试走 UDP会误以为改动无效。移动端浏览器清缓存的入口藏得比较深可能要清整个应用数据。5.2 缓存、预解析和浏览器自身的行为排查到这一步还没解决就该怀疑客户端自己了。有几类行为会造成看起来是网络问题的假象。DNS 预解析缓存。移动端浏览器和系统都会缓存解析结果缓存时间可能远超 DNS 记录的 TTL。站点换了 IP客户端还在用旧的表现出来就是只有我这台手机不行。验证方法是换一台从没访问过的设备或者用无痕模式加清空应用数据再试。如果新设备正常、老设备异常那就是本地缓存问题。Service Worker 或离线缓存。有些站点注册了 Service Worker它会在本地拦截请求、按自己的策略返回缓存内容。如果缓存策略写得有问题可能出现网络请求根本没发出去的情况。排查时可以在浏览器开发者工具里看网络面板如果请求显示from ServiceWorker而不是真实网络请求那问题就在这儿。这个坑我踩过一次查了两小时网络最后发现请求压根没出门。页面协议混用。HTTPS 页面里引用 HTTP 资源桌面浏览器可能给出警告后继续加载移动端浏览器可能直接阻止。表现出来就是页面框架出来了但内容空白。这个用开发者工具的控制台一看就能发现属于基础项但确实经常被忽略。系统时间和时区。证书校验依赖本地时间如果设备时间偏差过大证书会被判为无效。移动设备一般自动同步时间但某些定制系统或者手动改过时间的设备会出问题。这个排查起来最简单看一眼系统时间就能排除我习惯把它放在最前面做三十秒能省掉半小时。6. 速查表和我踩过的坑6.1 按现象定位的排查速查表排查做得多了我总结出一张按现象反查原因的表实际用起来比按理论顺序走要快得多。把它整理成下面这样遇到问题时先对号入座缩小范围再动手。现象最可能的原因首选验证动作报找不到服务器 / NXDOMAINDNS 解析失败或 CNAME 中断dig trace看断点换了 IP 后只有部分网络不通递归缓存未过期对比两路dig结果连接超时、无任何回应443 端口不通或被丢弃curl telnet://测 TCP连接被重置服务端限流或链路设备拒绝换 IP 用--resolve复测证书报错、电脑正常手机异常证书链不完整openssl -showcerts数证书张数首页能开、大页面卡死MTU 偏小导致大包被丢ping -M do -s探临界值只有开 v6 的网络失败IPv6 单边不可达curl -6与curl -4对比只有某家运营商全挂CDN 调度到故障节点--resolve逐 IP 测试缓存命中率异常低缓存键包含可变请求头对比响应头age与命中标识第一次正常、后续变慢HTTP/3 的 UDP 路径异常--http1.1强制降级对比只有单台设备不行本地解析缓存或离线缓存换设备或清应用数据复测这张表不是万能钥匙但它能把排查从漫无目的试变成有假设地验证。我实际排查时七成以上的问题在前三行就能定位。6.2 几个只有真踩过才知道的细节第一个坑是用错网络做测试。很多人排查时在电脑上敲命令敲完觉得一切正常就断定服务端没问题是你手机的事。这个逻辑是反的——问题恰恰只在移动网络出现你在宽带上测一百遍都是正常的。所有验证动作都必须在出问题的那条链路上做这是排查的前提不是可选项。第二个坑是过早下结论。看到 DNS 解析结果不对就直接改解析改完发现没用因为真正的问题是 MTU看到 443 不通就去查防火墙查完发现是 CDN 节点故障只是恰好那台节点的 443 也不通。我的经验是至少验证两层再动手改因为改错方向的成本比多查十分钟高得多尤其是涉及解析和证书的改动回滚起来很麻烦。第三个坑是忽略部分用户这个信号。如果反馈是我们都打不开那大概率是服务端问题如果是有的人能开有的人不能那大概率是调度或链路差异如果只有一个人打不开那大概率是本地缓存或设备问题。这个分布信息在排查初期就应该问清楚但很多人上来就问你能打开吗得到一个是或否就没了白白浪费了最有价值的信息。第四个坑是改完不验证旧连接。调整 MSS、改解析、换节点之后旧连接可能还在按老参数跑新连接才生效。这时候如果测试用的还是那条老连接会得出改了没用的错误结论。我现在的固定动作是改完之后等一分钟、断开重连、再测必要时清一下连接追踪表。最后一个细节关于记录。这类问题的排查过程往往跨了好几个小时、涉及好几条链路中间还穿插着跟服务商的沟通。我的习惯是用一个文本文件按时间顺序记下每一步做了什么、看到什么结果哪怕只是几行字。事后回头看很多时候答案就藏在某一条被自己忽略的输出里。这个习惯谈不上什么技巧但它救过我至少三次尤其是在问题复现不稳定的时候——没有记录你连上次测的是什么都不知道。 
长河君 · 2026/10/23 5:32:06 · 阅读 1.2k 手机流量打不开网页：DNS、443端口与CDN三层排查指南
移动数据开着网页转圈转到超时切回家里的宽带同一个地址秒开——这种情况我一年里能碰到七八次。第一次遇上时我以为是站点挂了结果同事在隔壁工位刷得好好的后来才慢慢摸清问题几乎从来不在整站上而是卡在某一条链路上域名解析在蜂窝网络里拿到了不一样的答案、443 端口在某个出口被掐断、或者 CDN 把这个运营商的用户调度到了一个正在带病工作的边缘节点。这篇就把我这些年从 DNS、443 端口到 CDN 三层挨个排查的完整方法摊开讲包括每一步用什么命令、看到什么结果说明什么、以及哪些是我踩过坑之后才总结出来的判据。适合自己维护站点、做前端联调、或者单纯被只有手机流量打不开折磨过的朋友看完至少能自己定位到是哪一层出的问题而不是在群里干喊你那边能打开吗。1. 先把打不开拆成可观测的失败点1.1 浏览器那句报错其实已经告诉你在第几层大部分人排查时的第一反应是刷新、换浏览器、清缓存这套动作做完没效果就卡住了。真正有效的起点是把打不开这个模糊感受翻译成一个具体的失败点。移动端浏览器给出的错误码虽然各家措辞不同但指向的层次非常明确我在排查时基本靠它决定下一步往哪儿走。DNS_PROBE_FINISHED_NXDOMAIN或者找不到服务器说明域名根本没解析出 IP问题在 DNS 层跟 443、跟 CDN 回源都没关系直接跳到第 2 节。ERR_CONNECTION_TIMED_OUT是 TCP 三次握手没完成SYN 发出去没有任何回应典型的端口不通或被中间设备静默丢包看第 3 节。ERR_CONNECTION_RESET是对方回了 RST说明包到了、但被主动拒绝可能是服务端限流、也可能是链路上的设备插了一手。ERR_SSL_PROTOCOL_ERROR、ERR_CERT_AUTHORITY_INVALID、ERR_CERT_COMMON_NAME_INVALID这三个都属于 TCP 通了、TLS 握手阶段炸了看 3.2。ERR_HTTP2_PROTOCOL_ERROR更靠后连接和握手都成了是应用层帧出了问题。提示移动端浏览器的报错页面能展开看详细错误码很多人只看标题就关掉了。这个错误码是整条排查链上信息量最大的一个输入值得多花十秒钟确认。我一般会把上面这几类失败点写成一张小纸条贴在显示器边上因为排查时人很容易慌一慌就开始瞎试。有了这张对应关系看到报错基本能砍掉七成的排查范围不用从头扫一遍。1.2 蜂窝网络和宽带到底差在哪几个地方同样是访问一个 HTTPS 站点手机流量和家里宽带走的路径差异比大多数人想的大得多。我整理过一张对照表每次遇到只有移动网络不行的问题就照着这张表逐项排除效率比凭感觉试高很多。差异点蜂窝网络固定宽带常见故障表现接入网基站到核心网链路更长光猫到局端链路短丢包、抖动更明显出口 IP大区共享出口NAT 层级多多为独立或小范围共享CDN 调度到远端节点MTU常在 1400 上下隧道开销大一般为 1500大包被丢小页面正常大页面卡死DNS递归服务器由运营商指定可自选家庭路由常改过解析结果与预期不符IPv6普及率高常优先走 v6视路由器配置而定单边可达导致部分网络失败中间设备链路环节多策略更复杂相对简单特定端口或特征被限速这张表里最容易被忽略的是 MTU 和 IPv6 两行。前者导致的现象特别迷惑首页能打开一进详情页或者一上传图片就卡住后者导致的现象更迷惑WiFi 下好好的切到流量就挂因为宽带路由器压根没开 v6问题被掩盖了。这两个坑我在第 3 节会展开讲它们是我踩过最深的两次。还有一点值得先说明所谓只有移动网络打不开很多时候并不是整个蜂窝网络都不行而是某一家运营商的某一段出口不行。同一间办公室里同事用另一家运营商的卡就能打开这种部分人不行的现象恰恰是 CDN 调度差异最典型的表现反过来说如果所有蜂窝网络都不行、只有宽带行那更可能是域名解析或者服务端对移动端出口 IP 段做了策略。2. DNS 排查解析结果在蜂窝网络里迷路了吗2.1 为什么同一个域名两种网络解析出的 IP 不一样这是最常见的一类原因也是最容易被误判成服务器挂了的一类。域名解析不是查一本固定的电话簿递归解析服务器会根据自己的位置、缓存状态、以及请求里携带的客户端子网信息返回不同的结果。运营商的递归服务器通常部署在大区机房它替成千上万个用户去问权威服务器权威服务器看到的来源是这台递归服务器的地址于是返回一个离这台递归服务器最近的节点 IP。问题就出在这儿这台递归服务器可能在省会而你在城郊它返回的节点对你来说未必是最优的甚至可能是一个已经下线但缓存还没过期的旧地址。更麻烦的是如果递归服务器没有正确携带客户端子网信息权威侧就只能按递归服务器的位置做粗粒度调度调度结果可能偏得很离谱。我遇到过一次特别典型的某站点在宽带下解析到同城节点延迟十几毫秒切到流量后解析到一个跨了大半个国家的节点延迟飙到一百多页面加载超时。站点本身完全健康纯粹是调度把人送错了地方。2.2 四路对照实验把解析链路摊开看排查 DNS 我固定做一个四路对照分别在两种网络下、对两种递归服务器各查一次四组结果摆在一起问题基本无所遁形。命令很简单# 第一路用系统默认 DNS 解析蜂窝网络下执行 dig short example.com A # 第二路指定一个公共递归服务器解析 dig 223.5.5.5 example.com A short # 第三路同时看 CNAME 链路别只看最终 A 记录 dig example.com A noall answer # 第四路查 AAAA确认 IPv6 解析情况 dig example.com AAAA short第一路和第二路的结果如果一致说明运营商递归服务器和公共递归服务器的判断相同DNS 层大概率没问题可以往下走。如果两者不一致就要看差在哪儿是 IP 完全不同调度差异还是第一路返回空解析失败还是第一路返回了明显不属于该服务商网段的地址缓存过期或配置错误。第三路看 CNAME 链路是我后来加上的因为很多站点前面挂了一层调度域名最终 A 记录是调度系统动态给出的。有些递归服务器在 CNAME 链路的中间某一步就解析失败了表现出来就是完全没有记录而不是记录不对。这两种情况的处理方式完全不同前者要找权威侧确认链路是否完整后者要等缓存过期或者联系运营商刷新。第四路容易被跳过但很关键。如果蜂窝网络下 AAAA 有记录、而宽带下没有那说明问题可能出在 IPv6 路径上而不是 DNS 本身。这时候要做的不是改 DNS而是去测 v6 连通性具体方法在 3.4。注意做对照实验时一定要把手机的数据网络和 WiFi 彻底分开关闭WiFi 助理这类会在 WiFi 信号弱时自动切到蜂窝数据的功能否则你根本不知道自己测的是哪条链路。我第一次排查时就被这个功能坑了半小时数据全是乱的。2.3 解析异常的三种典型成因和处置方式对照实验结果出来后常见的成因无非三类处置方式差别很大。第一类是递归缓存未过期。站点换了 CDN 服务商或者下线了旧节点权威侧的记录已经更新但运营商递归服务器还抱着旧记录不放TTL 没到就不刷新。表现出来就是只有部分网络解析到旧 IP而旧 IP 已经不通了。处置方式有两个一是等 TTL 自然过期二是临时调低权威侧的 TTL 再变更。我现在的习惯是任何涉及 IP 变更的操作提前一天把 TTL 从 3600 降到 300变更完观察一天再调回去这样即使出问题影响窗口也就五分钟。第二类是调度依据缺失。权威侧拿不到客户端子网信息只能按递归服务器位置调度。这种情况自己改不了只能推动服务商在权威侧开启客户端子网支持或者在调度策略上做兜底——比如对识别不出位置的请求返回一个覆盖范围更广的任播地址。作为站点维护方能做的排查是用两路结果对比如果蜂窝网络解析到的节点和宽带解析到的节点地理距离明显不合理基本可以判定是这类问题。第三类是CNAME 链路在某类递归服务器上中断。有些调度服务商的 CNAME 目标域名在部分递归服务器上无法完成解析报 SERVFAIL。这时候dig的返回会是空的但加trace能看到断在哪一步dig trace example.com A这个命令会从根开始一级级问下来输出很长但断点位置一目了然。我一般只在怀疑链路问题时才用日常排查用前四路就够了。处置上如果是自己可控的域名最直接的办法是把 CNAME 扁平化减少中间层级如果必须保留多层就在权威侧配置好胶水记录减少额外查询。这些操作听起来琐碎但真出问题时能省下大量沟通成本。3. 443 端口排查TCP 和 TLS 到底卡在哪一步3.1 先分清连不上和连上了但握手失败很多人的排查停在ping 得通吗这一步但 ping 用的是 ICMP跟 443 端口通不通完全是两回事。ICMP 通只能说明 IP 层可达TCP 层可能被拦得干干净净。正确的做法是直接对 443 做连通性测试我用得最多的是 curl 的详细模式和 openssl 的连接测试。# 看 TCP 连接和 TLS 握手全过程 curl -v --connect-timeout 8 https://example.com/ -o /dev/null # 只测 TCP 层不涉及 TLS curl -v telnet://example.com:443 --connect-timeout 8 # 绕过 DNS直接指定 IP 测试 curl -v --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null第一个命令的输出信息量最大。如果卡在Trying 203.0.113.10...之后就没了说明 TCP SYN 发出去没有回应是端口不通或者被静默丢弃。如果出现Connected to example.com之后卡在 TLS 阶段那 TCP 是通的问题在握手往下看 3.2。如果直接Connection reset by peer说明对方回了 RST可能是服务端限流、也可能是链路上的设备主动拒绝。第二个命令专门剥离 TLS把问题范围缩到最小。有些时候 curl 的 HTTPS 报错信息混杂了 DNS、TCP、TLS 三层的原因单独测一次 telnet 能立刻区分开。第三个命令是我排查 CDN 问题时的主力工具。用--resolve把域名强行绑到指定 IP可以绕过 DNS 直接验证某个节点的可用性后面第 4 节会反复用到。3.2 TLS 握手四件套SNI、协议版本、证书链、加密套件TCP 通了但握手失败我一般按四个方向查顺序是从外到内。SNI 是否正常携带。现在一台服务器上跑几十个站点是常态服务端靠 TLS 握手第一个包里的 SNI 字段决定出示哪张证书。如果客户端没带 SNI服务端要么返回默认证书域名对不上报证书错误要么直接中断连接。移动端某些老旧浏览器或者 App 内置的 WebView 在这个环节会有差异。验证方法openssl s_client -connect 203.0.113.10:443 -servername example.com -showcerts带上-servername和不带结果对比一下如果带上就正常、不带就报错说明服务端没有配默认证书需要补一张兜底证书。这个改动很小但能救掉一批老客户端。协议版本和加密套件是否匹配。有些服务端为了安全把 TLS 1.0/1.1 关掉了只留 1.2 以上而部分老旧移动设备只支持到 1.1握手直接失败。反过来也有服务端配置过严导致某些加密套件协商不上的情况。测试时指定版本试一遍openssl s_client -connect example.com:443 -servername example.com -tls1_2 openssl s_client -connect example.com:443 -servername example.com -tls1_3两个版本分别试哪个能通、哪个不能通结论很直接。我一般不主张为了兼容老旧设备把协议降到 1.0那是拿安全换兼容更合理的做法是引导升级或者在边缘层做协议适配。证书链是否完整。这是我最常遇到、也最容易被误判的一类。服务端如果只配了站点证书、没配中间证书桌面浏览器因为本地缓存过中间证书所以一切正常而全新的移动设备本地没有缓存就会报证书颁发机构不受信任。表现出来就是我电脑能开、手机不行而且换一台从没访问过的电脑也打不开。验证方法openssl s_client -connect example.com:443 -servername example.com -showcerts 2/dev/null | grep -c BEGIN CERTIFICATE正常应该返回 2 或 3站点证书加一至两张中间证书。如果只返回 1那就是链不完整需要把中间证书补上。这个问题的隐蔽性在于它跟网络类型没有直接关系但因为移动设备更新换代快、本地缓存少所以表现出来就像是移动网络专属故障。证书有效期和域名匹配。这两个属于基础项但真出问题时排查起来一样费劲。openssl的输出里会明确写出Not After和subject扫一眼就能确认。我见过一次因为证书自动续期脚本静默失败证书过期了两天而恰好那两天只有新设备访问出问题老设备因为会话复用还在正常工作查了半天才想起来看有效期。注意用openssl s_client测试时一定不要漏掉-servername参数。现代服务端几乎都依赖 SNI 选择证书不加这个参数测出来的结果不能代表真实浏览器行为很容易得出错误结论。3.3 MTU 和分片蜂窝网络里最隐蔽的一刀这一类问题我把它排在最坑第一位因为它表现出来的现象跟网络故障完全不像。典型症状是首页能打开图片加载不出来或者登录请求发不出去一直在转圈或者小接口正常、大接口超时。很多人第一反应是服务端接口慢实际上一查是包太大被丢了。蜂窝网络的链路层开销比以太网大MTU 常常在 1400 到 1450 之间而服务端和大多数客户端默认按 1500 来算。当一个大包发出去路径上某台设备发现超过自己的 MTU 又不允许分片就会静默丢弃。关键点是静默——它不回 ICMP 的需要分片消息于是发送方一直重传、一直失败表现出来就是卡死。验证方法很朴素用 ping 逐步试探最大可通包长# 1472 28 1500以太网标准 ping -M do -s 1472 example.com # 逐步往下降找临界值 ping -M do -s 1400 example.com ping -M do -s 1372 example.com-M do表示禁止分片-s是数据部分长度加上 28 字节的 IP 和 ICMP 头就是实际包长。如果 1472 通、1400 不通说明问题不在 MTU如果 1472 不通、1400 通那基本可以确认 MTU 偏小。找到临界值之后怎么处理客户端侧调不了运营商的链路参数能做的是在服务端或者边缘层把 TCP 的 MSS 调小让服务端主动按更小的包发# 在服务端网卡上设置 MSS 钳制 iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --set-mss 1360改完之后要清掉连接追踪里的旧会话否则老连接还按原来的 MSS 走。这个操作我在三四个项目里做过每次都是“改完立刻见效”但代价是稍微牺牲一点传输效率属于典型的用性能换可用性。3.4 IPv6 单边可达造成的个别网络打不开这一类问题的迷惑程度不亚于 MTU。现在的移动网络 IPv6 普及率很高很多移动端会优先走 v6而家里的宽带路由器可能压根没开 v6或者开了但上游不支持。于是同一台设备、同一个域名在流量下走 v6、在 WiFi 下走 v4两条路径的健康状况完全不同。症状很有辨识度只有蜂窝网络打不开而且不是所有蜂窝网络都不行是开了 v6 的那部分不行。如果服务端的 v6 地址配置有误、或者 v6 回源链路有问题就会出现这种单边故障。排查分两步。先确认解析层面有没有 AAAAdig example.com AAAA short有记录的话再强制走 v6 和 v4 分别测一次curl -6 -v https://example.com/ -o /dev/null --connect-timeout 8 curl -4 -v https://example.com/ -o /dev/null --connect-timeout 8如果-6超时、-4正常问题就在 v6 路径上。这时候再往下查是服务端 v6 监听没开、防火墙没放行、还是上游 v6 路由有问题。工具上可以用traceroute -6看断在哪一跳不过移动网络的 v6 路由经常不响应探测看到一堆星号是常态不要据此下结论。处置方式要看具体情况。如果是自己服务端的问题把 v6 监听和防火墙补齐就行如果短时间内修不好可以在 DNS 侧临时把 AAAA 记录摘掉让所有流量回落到 v4先把可用性救回来再从容修复。这个先摘 AAAA的操作我做过不止一次属于应急手册里的常备项。4. CDN 排查为什么只有某个节点出问题4.1 CDN 是怎么把不同网络的人分到不同节点的理解调度原理才能理解为什么只有移动网络不行。CDN 的调度系统主要看两样东西用户用的哪家递归服务器、以及用户出口 IP 落在哪个网段。移动网络的出口 IP 是大区共享的一个出口后面可能挂着几十万用户调度系统看到这个 IP会把它归到某个大区的节点池里。问题就在于这个大区可能划得很粗。如果调度系统把某个运营商的整个省份都归到一个节点池而那个池子里恰好有一台节点在带病工作——磁盘满了、回源超时、证书没同步——那么这个省的所有该运营商用户就全挂了而其他运营商的用户完全无感。这种故障在监控上很难被发现因为监控探针通常部署在几个固定的机房探针走的路径跟真实用户完全不同。我经历过一次某台边缘节点的回源配置错了导致缓存未命中时全部超时。监控显示站点可用率 99.9%因为探针访问的资源大部分命中了缓存但真实用户里有一家运营商的用户几乎全挂因为他们的请求恰好被调度到那台节点而且访问的是动态接口、全部未命中缓存。还有一种情况是节点池容量不足。某个大区的节点数量本来就少赶上晚高峰流量上涨新连接建不上表现出来就是晚上打不开、白天正常。这种问题在 CDN 侧看是容量问题在用户侧看就是玄学。4.2 用本地域名绑定做节点对照实验排查 CDN 问题核心思路是绕过 DNS直接打节点。只要能拿到该网络下解析出的节点 IP就能一个个测过去判断是单节点问题还是全网问题。第一步在出问题的网络下拿到解析结果。注意这一步必须用出问题的网络来做用宽带查到的 IP 没有意义dig short example.com A第二步把拿到的 IP 逐个用--resolve绑定测试。如果解析出多个 IP全部测一遍curl -v --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null --connect-timeout 8 curl -v --resolve example.com:443:203.0.113.11 https://example.com/ -o /dev/null --connect-timeout 8如果某个 IP 超时、其他 IP 正常那就是单节点故障结论很明确直接找服务商处理这台节点。如果所有 IP 都不通那问题不在节点上要么是这个网络到这批 IP 的路径有问题要么是服务端整体有问题。第三步反过来验证。用宽带解析出的 IP在移动网络下测试。如果移动网络访问宽带解析出的 IP 是通的那就彻底坐实了调度把你送到了一个坏节点这个结论。这种情况下临时解法是在客户端侧修改解析结果但更合理的做法是推动 CDN 侧把坏节点摘掉。提示--resolve参数不会修改系统解析只影响当前这一次 curl 请求非常安全可以放心在生产环境之外的机器上反复试。4.3 回源、缓存和中间设备的暗坑节点本身健康但内容出不来这种情况要往缓存和回源方向查。最常见的三类。缓存键不一致导致命中率异常。有些站点的缓存键里带了Accept-Encoding、User-Agent这类字段移动端浏览器的请求头和桌面端差异很大结果就是移动端全部未命中、全部回源。回源链路一旦有点慢移动端就表现为超时而桌面端因为命中缓存所以飞快。排查方法是看响应头里的缓存命中标识对比两种网络下的返回curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ | grep -i -E x-cache|age|viaage是 0 或者没有、x-cache显示 MISS说明没命中缓存。如果两种网络下命中状态差很多那就是缓存键设计的问题需要精简缓存键里的可变字段。回源超时导致的边缘等待。边缘节点缓存未命中时要去源站取如果源站响应慢边缘节点会一直等用户侧看到的就是转圈。这种情况下节点本身是好的问题在回源链路。判断方法是看响应时间命中缓存的请求几十毫秒未命中的请求几秒甚至超时两个群体的差异极其明显。这时候要优化的是源站响应速度或者边缘的回源策略比如开启回源超时后的旧内容兜底。中间设备的策略差异。蜂窝链路上可能有一些设备会基于请求特征做处理比如对没有User-Agent的请求、对特定方法的请求采取不同策略。这类问题最难查因为现象不稳定、时好时坏。我的做法是用最小化请求做二分先用一个最朴素的 GET 请求测然后逐步加上请求头看加到哪一个开始出问题。这个过程笨但有效我靠它定位过一起因为请求头里某个字段触发的间歇性失败。5. 客户端和应用层的那些坑5.1 HTTP/3 与 UDP 443 的隐患现在很多站点开了 HTTP/3走的是 UDP 443。浏览器第一次访问时走 TCP拿到响应后如果看到Alt-Svc头就会记住这个站点支持 HTTP/3后续访问尝试走 UDP。问题在于UDP 在部分链路上的待遇和 TCP 完全不同可能出现 UDP 被限速、被丢弃、或者被中间设备特殊处理的情况。症状很有特点第一次访问正常第二次开始变慢或者超时清掉浏览器数据后又恢复正常过几次又开始出问题。这就是典型的记住了 HTTP/3、但 HTTP/3 路径不通、回落机制又不够快。验证方法是临时禁用 HTTP/3 再测# 强制使用 HTTP/1.1绕开 HTTP/3 curl -v --http1.1 https://example.com/ -o /dev/null --connect-timeout 8 # 尝试 HTTP/2 curl -v --http2 https://example.com/ -o /dev/null --connect-timeout 8如果--http1.1和--http2都正常只有默认行为可能协商到 HTTP/3异常那基本可以锁定是 UDP 路径问题。这种情况下的处置短期可以在边缘侧关掉 HTTP/3 或者缩短 Alt-Svc 的有效期长期要看具体链路的 UDP 质量不能一概而论。注意判断 HTTP/3 问题时一定要清掉客户端的 Alt-Svc 缓存否则你改了服务端配置客户端还在按旧记录尝试走 UDP会误以为改动无效。移动端浏览器清缓存的入口藏得比较深可能要清整个应用数据。5.2 缓存、预解析和浏览器自身的行为排查到这一步还没解决就该怀疑客户端自己了。有几类行为会造成看起来是网络问题的假象。DNS 预解析缓存。移动端浏览器和系统都会缓存解析结果缓存时间可能远超 DNS 记录的 TTL。站点换了 IP客户端还在用旧的表现出来就是只有我这台手机不行。验证方法是换一台从没访问过的设备或者用无痕模式加清空应用数据再试。如果新设备正常、老设备异常那就是本地缓存问题。Service Worker 或离线缓存。有些站点注册了 Service Worker它会在本地拦截请求、按自己的策略返回缓存内容。如果缓存策略写得有问题可能出现网络请求根本没发出去的情况。排查时可以在浏览器开发者工具里看网络面板如果请求显示from ServiceWorker而不是真实网络请求那问题就在这儿。这个坑我踩过一次查了两小时网络最后发现请求压根没出门。页面协议混用。HTTPS 页面里引用 HTTP 资源桌面浏览器可能给出警告后继续加载移动端浏览器可能直接阻止。表现出来就是页面框架出来了但内容空白。这个用开发者工具的控制台一看就能发现属于基础项但确实经常被忽略。系统时间和时区。证书校验依赖本地时间如果设备时间偏差过大证书会被判为无效。移动设备一般自动同步时间但某些定制系统或者手动改过时间的设备会出问题。这个排查起来最简单看一眼系统时间就能排除我习惯把它放在最前面做三十秒能省掉半小时。6. 速查表和我踩过的坑6.1 按现象定位的排查速查表排查做得多了我总结出一张按现象反查原因的表实际用起来比按理论顺序走要快得多。把它整理成下面这样遇到问题时先对号入座缩小范围再动手。现象最可能的原因首选验证动作报找不到服务器 / NXDOMAINDNS 解析失败或 CNAME 中断dig trace看断点换了 IP 后只有部分网络不通递归缓存未过期对比两路dig结果连接超时、无任何回应443 端口不通或被丢弃curl telnet://测 TCP连接被重置服务端限流或链路设备拒绝换 IP 用--resolve复测证书报错、电脑正常手机异常证书链不完整openssl -showcerts数证书张数首页能开、大页面卡死MTU 偏小导致大包被丢ping -M do -s探临界值只有开 v6 的网络失败IPv6 单边不可达curl -6与curl -4对比只有某家运营商全挂CDN 调度到故障节点--resolve逐 IP 测试缓存命中率异常低缓存键包含可变请求头对比响应头age与命中标识第一次正常、后续变慢HTTP/3 的 UDP 路径异常--http1.1强制降级对比只有单台设备不行本地解析缓存或离线缓存换设备或清应用数据复测这张表不是万能钥匙但它能把排查从漫无目的试变成有假设地验证。我实际排查时七成以上的问题在前三行就能定位。6.2 几个只有真踩过才知道的细节第一个坑是用错网络做测试。很多人排查时在电脑上敲命令敲完觉得一切正常就断定服务端没问题是你手机的事。这个逻辑是反的——问题恰恰只在移动网络出现你在宽带上测一百遍都是正常的。所有验证动作都必须在出问题的那条链路上做这是排查的前提不是可选项。第二个坑是过早下结论。看到 DNS 解析结果不对就直接改解析改完发现没用因为真正的问题是 MTU看到 443 不通就去查防火墙查完发现是 CDN 节点故障只是恰好那台节点的 443 也不通。我的经验是至少验证两层再动手改因为改错方向的成本比多查十分钟高得多尤其是涉及解析和证书的改动回滚起来很麻烦。第三个坑是忽略部分用户这个信号。如果反馈是我们都打不开那大概率是服务端问题如果是有的人能开有的人不能那大概率是调度或链路差异如果只有一个人打不开那大概率是本地缓存或设备问题。这个分布信息在排查初期就应该问清楚但很多人上来就问你能打开吗得到一个是或否就没了白白浪费了最有价值的信息。第四个坑是改完不验证旧连接。调整 MSS、改解析、换节点之后旧连接可能还在按老参数跑新连接才生效。这时候如果测试用的还是那条老连接会得出改了没用的错误结论。我现在的固定动作是改完之后等一分钟、断开重连、再测必要时清一下连接追踪表。最后一个细节关于记录。这类问题的排查过程往往跨了好几个小时、涉及好几条链路中间还穿插着跟服务商的沟通。我的习惯是用一个文本文件按时间顺序记下每一步做了什么、看到什么结果哪怕只是几行字。事后回头看很多时候答案就藏在某一条被自己忽略的输出里。这个习惯谈不上什么技巧但它救过我至少三次尤其是在问题复现不稳定的时候——没有记录你连上次测的是什么都不知道。