企业官网建设流程全解析

移动数据开着，网页转圈转到超时，切回家里的宽带，同一个地址秒开——这种情况我一年里能碰到七八次。第一次遇上时我以为是站点挂了，结果同事在隔壁工位刷得好好的；后来才慢慢摸清，问题几乎从来不在"整站"上，而是卡在某一条链路上：域名解析在蜂窝网络里拿到了不一样的答案、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 站点，手机流量和家里宽带走的路径差异比大多数人想的大得多。我整理过一张对照表，每次遇到"只有移动网络不行"的问题，就照着这张表逐项排除，效率比凭感觉试高很多。

这张表里最容易被忽略的是 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 回源链路有问题，就会出现这种单边故障。

排查分两步。先确认解析层面有没有 AAAA：

dig 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|via"

age是 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 按现象定位的排查速查表

排查做得多了，我总结出一张按现象反查原因的表，实际用起来比按理论顺序走要快得多。把它整理成下面这样，遇到问题时先对号入座，缩小范围再动手。

这张表不是万能钥匙，但它能把排查从"漫无目的试"变成"有假设地验证"。我实际排查时，七成以上的问题在前三行就能定位。

6.2 几个只有真踩过才知道的细节

第一个坑是用错网络做测试。很多人排查时在电脑上敲命令，敲完觉得一切正常，就断定"服务端没问题，是你手机的事"。这个逻辑是反的——问题恰恰只在移动网络出现，你在宽带上测一百遍都是正常的。所有验证动作都必须在出问题的那条链路上做，这是排查的前提，不是可选项。

第二个坑是过早下结论。看到 DNS 解析结果不对，就直接改解析，改完发现没用，因为真正的问题是 MTU；看到 443 不通，就去查防火墙，查完发现是 CDN 节点故障，只是恰好那台节点的 443 也不通。我的经验是至少验证两层再动手改，因为改错方向的成本比多查十分钟高得多，尤其是涉及解析和证书的改动，回滚起来很麻烦。

第三个坑是忽略"部分用户"这个信号。如果反馈是"我们都打不开"，那大概率是服务端问题；如果是"有的人能开有的人不能"，那大概率是调度或链路差异；如果只有一个人打不开，那大概率是本地缓存或设备问题。这个分布信息在排查初期就应该问清楚，但很多人上来就问"你能打开吗"，得到一个是或否就没了，白白浪费了最有价值的信息。

第四个坑是改完不验证旧连接。调整 MSS、改解析、换节点之后，旧连接可能还在按老参数跑，新连接才生效。这时候如果测试用的还是那条老连接，会得出"改了没用"的错误结论。我现在的固定动作是改完之后等一分钟、断开重连、再测，必要时清一下连接追踪表。

最后一个细节，关于记录。这类问题的排查过程往往跨了好几个小时、涉及好几条链路，中间还穿插着跟服务商的沟通。我的习惯是用一个文本文件按时间顺序记下每一步做了什么、看到什么结果，哪怕只是几行字。事后回头看，很多时候答案就藏在某一条被自己忽略的输出里。这个习惯谈不上什么技巧，但它救过我至少三次，尤其是在问题复现不稳定的时候——没有记录，你连上次测的是什么都不知道。