1. 把“打不开”切成两半故障域的划分群里最常出现的对话是这样的用户截一张浏览器报错图说“网站挂了”前端说“接口没返回”后端说“我这边服务好好的”运维说“服务器 CPU 才 3%”。三方都没有说错但谁也没有解决问题。原因很简单——大家说的“打不开”根本不是同一件事。域名访问这条路上至少有四段彼此独立的环节名字变成 IP、IP 找到机器、机器上的端口能进、端口后面的程序能给出正确回应。任何一段断掉用户看到的都是同一个白屏或同一句“无法访问此网站”。我这几年处理这类问题的第一原则就是先确定故障域再谈修复。所谓故障域就是“解析侧”和“服务侧”这两大块。解析侧负责把域名翻译成地址服务侧负责在地址上真的开门做生意。这两块的排查工具、责任方、修复动作完全不同——解析侧要改记录、等 TTL、找域名服务商服务侧要查进程、查端口、查安全策略、查证书。把这两件事混在一起查最典型的后果就是明明服务器端口没开你却在反复刷 DNS 缓存明明解析还没生效你却在重启服务。时间全耗在错误的方向上。这篇文章想解决的就是这个“分流”问题。它适合所有需要面对“网站打不开”这句话的人自己搭过站、买过域名、配过证书的独立开发者需要半夜接告警的后端和运维以及要给客户一个说法的技术支持。你不需要背下 DNS 协议栈也不需要精通网络分层只要掌握一套固定的判断顺序加上几条随手就能敲的命令就能在三到五分钟内把范围缩小到某一侧然后直奔根因。下面这套方法我在很多次线上事故和搬迁项目里用过它不是教科书式的完整理论而是“先分清在哪再去修”的实操路线。1.1 地址栏回车之后那几百毫秒里发生了什么要看懂后面的排查逻辑得先知道一次成功的访问大概经过哪些步骤因为报错信息基本都能对应到其中某一步。你在地址栏敲下域名并回车浏览器第一步不是发请求而是查“这个名字对应哪个 IP”。它会依次看自己的缓存、操作系统的 DNS 缓存、本机的 hosts 文件都没有命中才去问系统配置的递归 DNS 服务器递归服务器再从根、顶级域一路问到你这个域名真正的权威服务器拿到记录后逐层缓存并回传。这一步走完浏览器才拿到一个 IP 地址。拿到 IP 之后是建立连接向那个 IP 的 443或 80端口发起 TCP 握手如果是 HTTPS 还要做 TLS 握手校验证书里的域名是否和你访问的域名一致。握手成功才发送 HTTP 请求服务器或者它前面的网关、缓存层、负载均衡处理后返回状态码和内容。整个链路里前面那段属于“解析域”后面从握手开始的全属于“服务域”。这个划分的价值在于浏览器给出的错误文案其实已经告诉你断点在哪里了。DNS_PROBE_FINISHED_NXDOMAIN、ERR_NAME_NOT_RESOLVED、找不到服务器 IP 地址——这是名字没翻译出来解析域的问题。ERR_CONNECTION_REFUSED、连接被拒绝——名字翻译出来了但那个 IP 上没人监听这个端口服务域的问题。ERR_CONNECTION_TIMED_OUT、响应时间过长——包发出去了没回应可能是防火墙丢包、路由不通也可能是机器根本不存在。ERR_CERT_DATE_INVALID、您的连接不是私密连接——连接通了TLS 层出问题。新手最容易犯的错是把所有“打不开”都归为“DNS 没生效”因为这是唯一一个他们听说过名字的环节。实际上纯 DNS 故障在所有“站点打不开”的案例里占比并不高更多时候是证书过期、端口没放通、后端进程崩了。所以第一件事永远是读错误文案别跳过它。1.2 三条断点解析、连接、响应我把整条链路简化成三个断点形成一个可以死记硬背的判断框架。第一断点是“名字到 IP”用nslookup或dig验证第二断点是“IP 到端口”用telnet、nc或curl --resolve验证第三断点是“端口到内容”看 HTTP 状态码和响应体。三个断点依次为“通”或“不通”组合起来其实只有几种情况每一种都对应明确的故障域和下一步动作。第一断点解析第二断点端口第三断点响应故障域定位典型原因查不到记录无法测试无法测试解析域记录未添加、记录被删、权威服务器故障、域名状态异常查到记录但 IP 不对连到错误机器可能返回错误页面解析域记录写错、旧记录未清理、多线路配置不一致查到正确记录连接被拒无法测试服务域服务未启动、监听地址错误、端口未放通查到正确记录连接超时无法测试服务域偏网络安全策略拦截、路由不通、机器宕机查到正确记录连接成功5xx服务域后端异常、上游不可达、超时配置过短查到正确记录连接成功证书报错服务域TLS证书过期、域名不匹配、SNI 配置缺失查到正确记录连接成功返回别人的站点服务域虚拟主机默认站点兜底、Host 头未正确匹配这张表我建议你抄在便签上。它的好处是只要前两个断点的结论出来你基本就不用再猜了。比如“查到正确记录 连接被拒”那就别再折腾 DNS 了去服务器上看进程和监听端口反过来“完全查不到记录”你去重启 Web 服务一百次也没用。1.3 一个反直觉的结论多数“解析问题”其实不是解析问题这一点值得单独强调。很多人在改完解析记录后十分钟发现没生效就认定“DNS 出问题了”然后开始疯狂刷缓存、换网络、重启路由器。但 DNS 有 TTL生存时间机制你改的是权威服务器上的记录各地递归服务器还握着旧值的缓存这属于完全正常的设计行为不是故障。TTL 设成 3600 秒就意味着最长要等一小时这个等待是写在协议里的预期不是“出问题”。真正的解析故障有明确的特征查不到记录NXDOMAIN、查到的 IP 和你配置的完全不一样、不同公共 DNS 查出来的结果互相矛盾、权威服务器本身不响应。这些才是需要动手改的。而“改了还没生效”“只有我这台电脑打不开”“刚重启路由器就好了”这类现象多半是缓存和本地配置处理的思路完全不同。分不清这一层你就会把正常的传播等待当成事故来处理越处理越乱。2. 解析域自查从本机缓存一路问到权威服务器确定了方向在解析侧接下来的动作要按“由近及远”的顺序来也就是从你自己的机器开始一层层往外推。这个顺序不能反如果先去看权威服务器的配置你可能会发现配置完全正确然后陷入“配置是对的为什么打不开”的死循环而真正的原因可能是你本机 hosts 文件里三年前留下的一行测试记录。2.1 第一条命令先问“这个名字现在指向谁”不管什么系统nslookup 你的域名是最快的起点。Windows 自带Linux 和 macOS 也基本都有。它输出两部分上面是它用的 DNS 服务器地址下面是解析结果。先看下面——如果有 A 记录并且 IP 和你预期一致说明从你这台机器出发的解析链路是通的问题在服务域直接跳到第三节。如果返回“找不到”“Non-existent domain”“NXDOMAIN”或者返回的 IP 完全不对那就在解析域里继续往下挖。dig的信息量更大我更推荐在有条件时用它dig example.com A short dig example.com Ashort只输出答案适合快速看结果不带参数则给出完整应答重点看几个字段status是NOERROR还是NXDOMAINANSWER SECTION里有几条记录最关键的SERVER字段告诉你这次查询实际问的是哪台递归服务器。很多人排查半天最后发现本机配置的 DNS 指向了一个早就下线的内网地址所有查询都在超时后被静默忽略表现就是“什么都查不到”。还有一个常见坑nslookup在某些系统上会同时对 A 和 AAAA 发起查询如果 IPv6 那条超时整个命令会卡好几秒才返回看起来像“DNS 很慢”。用dig example.com A明确指定类型可以避免这种干扰。2.2 换一台递归服务器再查一次这一步能省下大量时间本机查出来的结果只能代表“你这台机器看到的视图”。要判断是全局问题还是局部问题最有效的一招是换一个公共递归服务器再查一遍dig 某个公共DNS地址 example.com A short如果本机查不到、公共 DNS 能查到说明问题在你本地这条链路上本机缓存、路由器、内网 DNS如果两边都查不到问题在权威侧如果两边查到的 IP 不一样那就是多线路解析或者缓存还没同步属于“部分用户能开、部分用户不能开”的经典成因。这个对比动作只需要十秒钟但它能直接决定你接下来是去清本机缓存还是去域名服务商后台改记录。我见过太多次“整个团队在会议室里争论解析到底生效没有”其实只要两台机器各敲一条命令五秒就能定论。2.3dig trace找到权威服务器也就找到了责任分界点当两边都查不到记录时需要确认“权威服务器上到底有没有这条记录”。dig trace会把从根到顶级的整条查询路径打印出来dig example.com A trace输出的最后几行通常是权威服务器的应答。如果最后显示NXDOMAIN且来自你域名所配置的权威服务器那就是记录本身不存在——可能是没添加、被误删、或者在某个子域层级上写错了。如果trace在中途就断了、某一步一直超时那可能是权威服务器不可达或者域名状态异常这种情况通常需要去域名服务商的控制台看域名本身的状态而不是继续在记录内容上打转。这一步还有个副产品你能明确看到这个域名当前委托给了哪几台权威服务器。如果你在控制台改记录但改的是另一套权威服务器的配置比如域名已经迁到新服务商但域名的 NS 记录还指着旧的那你的修改永远不会生效。这类“改了没反应”的案例根因往往就在这里。2.4 记录类型对不上那些看起来像解析故障的配置错误有时候记录是存在的查询也返回NOERROR但页面还是打不开。这时候要检查记录类型是否匹配A 记录缺失只有 CNAMECNAME 指向的目标如果本身没有 A 记录或者指向了一个已被删除的地址解析会失败。CNAME 链越长越脆弱任何一环断掉整体就断。AAAA 记录指向了不通的 IPv6 地址这是最隐蔽的一类。A 记录正常但同时也存在一条指向早已下线地址的 AAAA 记录。支持 IPv6 的客户端会优先尝试那条路超时后才回落到 IPv4表现就是“页面能开但极慢”或者“部分用户直接打不开”。现代浏览器有回落机制会缓解但服务端和老旧客户端不一定有。CNAME 和 A 记录冲突同一个名字上同时存在 CNAME 和其他记录在 DNS 规范里是不允许的不同递归服务器的处理方式不一致结果就是各地表现不同。泛解析把错误掩盖了配置了*泛解析后任何拼错的子域名都会返回同一个 IP看起来“解析都正常”实际上你测的可能是一个根本不存在的子域。我的习惯是拿到域名后先完整看一遍所有记录而不是只查 A。dig example.com ANY noall answerANY查询在很多服务器上会被限制返回能拿到多少算多少配合控制台后台的记录列表一起看基本不会有遗漏。2.5 hosts 文件与本地缓存那个“只有我打不开”的经典场景如果同事都能打开只有你的机器不行先别怀疑 DNS先看 hosts。这个文件优先级高于 DNS 查询里面任何一行残留记录都会覆盖真实解析WindowsC:\Windows\System32\drivers\etc\hostsLinux / macOS/etc/hosts打开看一眼有没有你正在排查的域名有就注释掉。我遇到过最典型的一次是某个项目为了本地联调把正式域名写进了 hosts 指向测试机联调结束没人清理半年后正式环境迁移只有这位同事的电脑坚持访问旧地址排查了两个小时。排除 hosts 之后清系统 DNS 缓存# Windows ipconfig /flushdns # macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Linuxsystemd-resolved sudo resolvectl flush-caches浏览器自己还有一层缓存有些浏览器内置了 DNS 缓存和连接复用必要时用无痕窗口或者换一个浏览器交叉验证。这一步听起来很基础但在“刷新一下就好了”的场景里它命中的概率高得惊人。3. 服务侧检查端口通不通服务活不活解析侧确认无误——名字能正确翻译成 IP——接下来的问题全部落在服务侧。这里的排查逻辑和解析侧完全不同解析侧是“读配置”服务侧是“做探测”。你要做的是依次验证端口是否可达、TLS 是否正常、HTTP 是否返回了合理的响应。三者中任何一环出问题用户看到的现象都是“打不开”但修复动作差别很大。3.1 端口连通性telnet、nc、curl怎么选最直接的探测是看目标 IP 的端口能不能连上telnet 203.0.113.10 443 # 或 nc -zv 203.0.113.10 443连上会显示Connected或succeeded被拒绝Connection refused说明包到达了主机但那个端口上没有程序在监听——这就是服务没起来或者监听在了 127.0.0.1 而不是 0.0.0.0。如果一直卡住直到超时那是另一种情况包在路上被丢掉了通常是安全策略、防火墙或路由的问题跟进程无关。这两者的区别非常重要因为它直接决定你该找谁拒绝 你的事服务/配置超时 链路的事策略/网络。很多人在“超时”的情况下反复重启服务重启一百次也没用因为请求根本没到机器上。telnet在不少新系统上默认没装nc的参数各家实现还不一样所以我更常用curl它一个工具能覆盖后面所有步骤curl -sv --max-time 10 https://example.com/ -o /dev/null-v会打印完整的握手过程包括 DNS 解析出的 IP、TCP 连接、TLS 握手、请求头和响应头。这是排查服务侧最好用的一条命令因为它把三个断点的信息一次性全给你了。看输出时按顺序读先看Trying x.x.x.x:443这一行确认连的是哪个 IP再看有没有Connected再看 TLS 握手有没有报错最后看响应状态码。3.2curl --resolve绕开 DNS 直连指定服务器这是我认为最值得掌握的一个技巧。当你怀疑“解析已经指到新机器了但新机器本身有问题”时可以把域名和 IP 的对应关系临时写进 curl让它跳过 DNS 直接打指定 IP同时保留正确的 Host 头和 SNIcurl -I --resolve example.com:443:203.0.113.10 https://example.com/这一条命令的价值在于它把“解析”这个变量彻底固定住了。如果--resolve指定新 IP 能正常返回 200而正常访问不行那问题 100% 在解析还没生效或者解析指错了如果--resolve指定新 IP 也打不开那问题 100% 在新机器上跟 DNS 一点关系没有。一次对比双向排除比任何推理都可靠。同样的思路在线路切换、灰度验证、证书部署验证时都用得上。比如证书换了新的但用户还在报错你可以用--resolve直连某一台确认新证书是否真的装上了而不用等 DNS 传播。3.3 证书与 SNI最像“解析问题”的一类假故障证书问题是我见过误判率最高的一类。用户看到“您的连接不是私密连接”第一反应往往是“域名解析错了”因为浏览器有时会提示“该证书不属于此网站”。但实际上证书不匹配根本原因通常是服务端配置而不是解析。判断方法很直接openssl s_client -connect 203.0.113.10:443 -servername example.com /dev/null 2/dev/null | openssl x509 -noout -subject -dates-servername这个参数是关键。一台服务器上跑了多个站点时服务端要靠 SNI 里的域名来决定返回哪张证书。如果缺了这个参数或者服务端没配 SNI它会返回默认站点的证书于是证书上的域名和你访问的域名不符浏览器直接拦下。这种情况下解析完全正常就是配置问题。看输出的dates也能立刻判断是不是过期。证书过期在浏览器里的表现有时非常像“网站挂了”尤其是在移动端报错页可能只显示一句“无法访问”。所以只要看到和 TLS 相关的报错第一件事就是查有效期这个动作三秒钟能排掉相当一部分事故。另外还有一个容易被忽略的点服务端系统时间不准。证书校验依赖时间如果服务器时钟漂移你自己用浏览器访问可能正常但服务端之间的调用会报“证书尚未生效”或者“证书已过期”。这种情况在容器环境里偶有发生值得在疑难杂症时顺手date一下。3.4 5xx 的真实含义走到这一步解析早就通了如果curl拿到了一个 5xx 状态码恭喜你这说明前面所有环节都是通的名字解析成功、TCP 连接成功、TLS 握手成功、HTTP 请求被接收并处理了——只是处理失败了。很多人看到 502 还在查 DNS这是纯粹的方向性错误。状态码含义通常的排查方向502网关从上游收到了无效响应后端进程崩了、上游端口不对、上游主动断连503服务暂时不可用后端全部不健康、连接池耗尽、限流触发504网关等待上游超时后端处理太慢、超时阈值设得太短、数据库慢查询521 / 522 / 523中间层连不上源站源站地址配错、源站端口未放通、源站证书异常403被拒绝访问控制、来源校验、路径权限404找不到路由配置、路径重写规则、默认站点兜底521、522 这类自定义状态码来自中间层缓存层或转发层它们的含义非常明确中间层自己活得很好是它连不上你的源站。这时候要查的是“中间层配置里写的源站地址和端口对不对”“源站有没有对中间层的出口地址放行”而不是继续查用户侧的 DNS。还有一个很隐蔽的情况返回 200 但内容是错的。比如所有域名都返回同一个默认站点页面或者返回一个“欢迎使用”的安装引导页。这类现象说明请求到了服务器但 Host 头没有被正确匹配到对应的站点配置服务器用了默认站点用保底。问题在虚拟主机配置同样属于服务域。4. 现象翻译把“打不开”拆成可执行的线索排查效率的差距很多时候不在于命令敲得多熟练而在于能不能把用户那句模糊的“打不开”翻译成结构化的线索。用户说“打不开”的时候实际上包含了大量信息只是他自己不知道哪些有用。你要做的是主动追问几个固定问题把现象收敛到具体的故障域。4.1 追问清单五个问题定方向我通常会问这几件事顺序固定浏览器上具体显示什么要原文或截图不要“就是打不开”这种转述。错误码是最有价值的信息。是所有页面都打不开还是只有某个页面首页能开、某个接口 502那根本不是解析问题是那一个服务的问题。是所有人都打不开还是只有部分人这个问题的答案直接决定故障域的范围。换个网络比如手机流量能打开吗能打开说明是本地链路或本地缓存不能打开说明是服务端或全局解析。最近改过什么换服务器、改解析、续证书、发版本、调安全策略——任何一项都值得怀疑。这五个问题问完八成的情况已经能定位到某一侧了。剩下的两成用第二节和第三节的命令去验证。这套流程的好处是它不依赖经验直觉任何人照着问都能得到可用的结论。4.2 “部分地区打不开”先分是线路还是节点这是最容易被误判成“解析问题”的场景因为“部分地区”听起来很像 DNS 传播不一致。但实际原因至少有三类需要用不同方法区分多线路解析导致的分裂域名给不同运营商配了不同的 IP某条线路的 IP 已经失效。判断方法是查不同公共 DNS 看返回的 IP 是否不同然后逐个curl --resolve测。缓存层节点差异接了内容分发后不同地区走不同节点。判断方法是多次解析看返回的 IP 是否在变然后针对具体节点测连通性。源站出口策略源站对某些回源地址段做了限制导致某些节点拿不到内容。区分这三类的关键动作是抓一个打不开的用户的所在地然后用解析工具看那个地区会返回哪个 IP最后对这个 IP 单独做连通性测试。如果那个 IP 本身就连不上是解析指错了地址如果那个 IP 能连上但内容不对是节点或回源的问题。4.3 改了记录为什么迟迟不生效TTL 与负缓存这是被问得最多的问题值得单独说清楚。你在控制台把 A 记录从旧 IP 改成新 IP点了保存控制台显示“已生效”但用户还在访问旧地址。原因有四个层次第一层是TTL。权威服务器告诉递归服务器“这条记录可以缓存 N 秒”在这 N 秒内递归服务器不会再来问它直接给你旧值。这是设计行为。想要快速切换唯一正确的做法是提前把 TTL 调小等旧 TTL 过期后再改记录改完再调回来。临时抱佛脚改记录等待时间是躲不掉的。第二层是负缓存。如果你之前查的是一个还不存在的子域名返回了 NXDOMAIN这个“不存在”的结论也会被缓存一段时间。等你把记录加上了递归服务器还在负缓存的窗口里继续告诉你“不存在”。这解释了那种“明明加了记录却还是查不到”的怪现象。第三层是中间层自己的缓存。有些转发层会按自己的策略缓存解析结果不完全遵守你设的 TTL。这种情况只能联系服务方确认或者临时换一条解析路径验证。第四层是客户端缓存。浏览器、操作系统、甚至某些客户端软件都有自己的缓存你改了服务端用户机器上还留着一份。这也是为什么“清一下缓存就好了”这种建议虽然听起来敷衍但确实是有效的。有一个实用技巧切换前把 TTL 降到 60 秒观察至少两个旧 TTL 周期再动手改指向。这个动作能让你的切换窗口从一小时压到几分钟代价只是提前一天操作。4.4 那张“看起来没问题”的配置往往有一个字段是错的排查到最后绝大多数根因都不是什么复杂机制而是一个具体的、肉眼可见的字段错误。我整理了几种高频的写法问题你可以对照着检查末尾多了一个点example.com.和example.com在有些控制台里含义不同前者是绝对域名后者可能被拼上默认后缀结果变成example.com.yourdomain.com。CNAME 指向了相对名字同样会被拼接默认后缀指向一个不存在的目标。端口写进了记录DNS 记录里不能带端口example.com:8080这样的写法在部分控制台会被当成非法或错误解析。复制粘贴带进了空格行首行尾的空格在部分界面里不可见但会导致校验失败或者记录被截断。同一个名字有两条冲突记录为了“保险”同时留了旧 IP 和新 IP结果流量随机分到两台机器一台是旧的表现就是“时好时坏”。“时好时坏”这个现象特别值得警惕它几乎总是意味着有多条记录同时存在而其中一部分是无效的。单条记录要么通要么不通不会时通时不通。遇到间歇性故障第一件事就是数一数这个域名到底有几条 A 记录。5. 一次迁移事故的完整排查链路下面这个案例是我自己经手的为了让过程可复现细节做了脱敏处理涉及的地址和域名均为示例值。选它是因为它同时踩了两个坑而且最初的判断方向是错的正好能说明“先分故障域”这个习惯有多重要。5.1 现象与最初那个错误的判断某个站点从旧服务器迁移到新服务器操作流程看起来完全标准新机器部署好、证书装好、本地用 IP 加 Host 头测试通过、控制台改 A 记录、等待。改完两小时后反馈开始进来一部分用户能正常访问另一部分用户仍然打开的是旧页面还有少数用户直接报“无法访问”。当时的第一个判断是“解析还没传播完”理由是“有人能打开就说明新服务器没问题”。这个判断有一半是对的——新服务器确实没问题——但结论错了因为“有人能打开”并不能推出“打不开的人只是还没轮到”。这个推理漏洞很常见把“存在成功样本”当成“服务端正常”的证据然后就把所有失败都归到解析传播上于是白白等了两个小时。转机出现在有人问了一句“打不开的那几个人是不是都是同一个地方的”一核对确实集中在某一类网络环境下。这个信息立刻把“随机传播”这个假设推翻了一半——如果是传播未完成分布应该是随机的不该有这种聚集性。5.2 分层验证四条命令锁定范围接下来按第二节和第三节的顺序做了四件事大概花了六分钟。第一步查新老两台机器的记录dig example.com A short dig 公共DNS example.com A short本机查到的是新 IP公共 DNS 查到的也是新 IP。这一步说明解析记录本身已经更新了而且主流的递归服务器都拿到了新值。到这里从“记录内容”这个角度看解析是没问题的。第二步查 AAAA。这一步是转折点dig example.com AAAA short返回了一条 IPv6 地址而且这个地址属于旧服务器。也就是说迁移时只改了 A 记录AAAA 记录被完整地留在了旧地址上。支持 IPv6 的客户端优先走这条路而旧服务器上的服务已经被停掉了表现就是连接超时也就是用户看到的“无法访问”。那些能正常打开的用户恰好走的是 IPv4 路径。第三步验证这个假设curl -6 -I --max-time 10 https://example.com/ curl -4 -I --max-time 10 https://example.com/强制走 IPv6 时超时强制走 IPv4 时返回 200。假设成立。第四步排除“旧服务器上其实还有服务”这种可能curl -I --resolve example.com:443:旧服务器IP https://example.com/直连旧 IP 返回连接被拒确认旧服务确实已下线。整条链路到这里闭环了。5.3 根因与修复一条没被清理的记录根因很明确迁移清单里只列了 A 记录没有列 AAAA 记录。这条 IPv6 记录可能是很久以前做双栈测试时留下的之后一直没人管因为它“不影响使用”——在旧服务器还活着的时候AAAA 指向旧服A 指向旧服两边都能通问题就被掩盖了。迁移把 A 改走AAAA 留在原地问题才暴露出来。修复动作有两步先把 AAAA 记录改成新服务器的 IPv6 地址如果新服务器有或者直接删掉这条记录如果暂时不打算支持 IPv6然后等待旧 TTL 过期。改完之后再用dig AAAA和curl -6双向验证确认一致。这里有个决策点值得说明删掉还是改成新地址。如果新服务器没有 IPv6 出口硬填一个不可达的地址只会制造更隐蔽的问题所以直接删除更稳妥如果新服务器支持双栈那就改成新地址保留双栈能力。判断依据是新机器上是否真的监听了 IPv6用ss -lntp | grep 443看监听地址是0.0.0.0还是::一看便知。5.4 复盘五个以后再也不会犯的细节这次事故之后我把几个教训写进了团队的自检清单第一迁移清单必须列全所有记录类型。A、AAAA、CNAME、MX、TXT 全都要过一遍不能只看 A。TXT 记录里的域名校验信息如果丢了会影响其他服务的验证流程。第二“有人能打开”不能作为服务端正常的证据。只能说明“至少有一条路径是通的”剩下几条路径是否有问题必须单独验证。第三现象有聚集性就一定不是随机传播。传播未完成的表现是分散的聚集在某个地区、某种网络、某个客户端版本说明有确定性的原因。第四切换前先看dig ANY的完整输出。哪怕服务器只返回一部分也比你只查 A 看到的信息多。我现在养成了习惯接手任何一个域名先完整看一遍记录而不是直奔 A 记录。第五验证必须用不同协议栈各跑一遍。IPv4 通、IPv6 不通这种半通状态最难排查因为大部分工具默认只走其中一条。6. 把判断固化成清单别靠临场反应排查能力的高低很多时候不体现在知不知道某个命令而体现在顺序是否固定。临场反应式的排查每次都要重新想“我现在该查什么”容易漏、容易绕圈固定顺序的排查哪怕状态不好、半夜三点被叫起来也能机械地走完流程把范围一步步缩小。下面这份清单是我自己用的版本你可以直接拿去改成适合自己环境的。6.1 上线与迁移前的自检清单检查项具体动作通过标准记录完整性dig 域名 ANY比照控制台记录列表所有类型记录都指向新目标无遗留双栈一致性分别dig A和dig AAAA有 AAAA 时必须指向可用地址否则删除目标可达性curl --resolve 域名:443:新IP返回预期状态码内容正确证书有效性openssl s_client -servername域名匹配、未过期、链完整TTL 预降提前一天把 TTL 调到 60切换窗口可控冲突记录确认同名下只有一组目标地址不存在新旧并存默认站点用未配置的 Host 头访问看返回不会误返回其他站点内容监听地址ss -lntp看端口绑定绑定在对外地址非仅回环这份表格看着简单但它覆盖了我遇到的绝大多数迁移事故。尤其是“冲突记录”和“监听地址”这两项出问题的频率远超预期——前者造成间歇性故障后者造成“本机测试正常、外面访问不通”的诡异现象。6.2 一段可以随手复用的排查脚本我把前面几步串成了一个脚本放在跳板机上出问题时改两个变量直接跑#!/usr/bin/env bash DOMAINexample.com IP203.0.113.10 echo 1. A 记录 dig short $DOMAIN A echo 2. AAAA 记录 dig short $DOMAIN AAAA echo 3. 换公共 DNS 复查 dig short ${PUBLIC_DNS:-223.5.5.5} $DOMAIN A echo 4. 直连指定 IP跳过解析 curl -sI --max-time 10 --resolve $DOMAIN:443:$IP https://$DOMAIN/ | head -n 1 echo 5. 默认路径访问 curl -sI --max-time 10 https://$DOMAIN/ | head -n 1 echo 6. 证书信息 openssl s_client -connect $IP:443 -servername $DOMAIN /dev/null 2/dev/null \ | openssl x509 -noout -subject -dates第 4 步和第 5 步的对比是这个脚本的核心如果第 4 步通、第 5 步不通问题在解析如果两步都不通问题在服务端如果两步都通但用户还在报错那就该去查缓存和中间层了。这一组对比能在十秒内给出方向剩下的事就好办了。脚本里的公共 DNS 地址请换成你环境中实际可用的不同网络环境下可用的地址可能不一样这一点在受限网络里尤其要注意。6.3 我个人的几条经验最后分享几个不在文档里、但实际用起来很省时间的习惯。别在第一次判断时就下结论。我的经验是第一次形成的判断有相当比例是错的所以要主动找一个能证伪它的动作。比如你判断“是 DNS 没生效”那就去找一个“解析已经生效”的证据如果找不到判断就不成立。这个思维习惯比任何工具都有价值。先看错误文案再看日志。用户的截图里往往已经写着答案只是被当成噪音忽略了。我见过太多次日志翻了半小时最后发现浏览器上明明白白写着“证书已过期”。改完必验证而且要用不同路径验证。改完记录用本机查一遍是不够的要换公共 DNS 查、要直连 IP 测、要分别用 IPv4 和 IPv6 试。因为你的本机缓存可能是最后一个更新的本机看到的结果最不具代表性。把每次事故的根因记下来。不是为了流程而是因为同类问题会重复出现。我这份清单里超过一半的条目都是某次具体事故之后加进去的。第一条 AAAA 记录就是那次迁移之后补上的。给自己留一个“最小可复现”的测试域名。一个只配了 A 记录、指向一台最简静态页面的域名在不清楚是环境问题还是配置问题时用它做对照实验非常有效。如果它能打开而你的目标域名打不开两者配置的差异就是答案。
1. 把“打不开”切成两半故障域的划分群里最常出现的对话是这样的用户截一张浏览器报错图说“网站挂了”前端说“接口没返回”后端说“我这边服务好好的”运维说“服务器 CPU 才 3%”。三方都没有说错但谁也没有解决问题。原因很简单——大家说的“打不开”根本不是同一件事。域名访问这条路上至少有四段彼此独立的环节名字变成 IP、IP 找到机器、机器上的端口能进、端口后面的程序能给出正确回应。任何一段断掉用户看到的都是同一个白屏或同一句“无法访问此网站”。我这几年处理这类问题的第一原则就是先确定故障域再谈修复。所谓故障域就是“解析侧”和“服务侧”这两大块。解析侧负责把域名翻译成地址服务侧负责在地址上真的开门做生意。这两块的排查工具、责任方、修复动作完全不同——解析侧要改记录、等 TTL、找域名服务商服务侧要查进程、查端口、查安全策略、查证书。把这两件事混在一起查最典型的后果就是明明服务器端口没开你却在反复刷 DNS 缓存明明解析还没生效你却在重启服务。时间全耗在错误的方向上。这篇文章想解决的就是这个“分流”问题。它适合所有需要面对“网站打不开”这句话的人自己搭过站、买过域名、配过证书的独立开发者需要半夜接告警的后端和运维以及要给客户一个说法的技术支持。你不需要背下 DNS 协议栈也不需要精通网络分层只要掌握一套固定的判断顺序加上几条随手就能敲的命令就能在三到五分钟内把范围缩小到某一侧然后直奔根因。下面这套方法我在很多次线上事故和搬迁项目里用过它不是教科书式的完整理论而是“先分清在哪再去修”的实操路线。1.1 地址栏回车之后那几百毫秒里发生了什么要看懂后面的排查逻辑得先知道一次成功的访问大概经过哪些步骤因为报错信息基本都能对应到其中某一步。你在地址栏敲下域名并回车浏览器第一步不是发请求而是查“这个名字对应哪个 IP”。它会依次看自己的缓存、操作系统的 DNS 缓存、本机的 hosts 文件都没有命中才去问系统配置的递归 DNS 服务器递归服务器再从根、顶级域一路问到你这个域名真正的权威服务器拿到记录后逐层缓存并回传。这一步走完浏览器才拿到一个 IP 地址。拿到 IP 之后是建立连接向那个 IP 的 443或 80端口发起 TCP 握手如果是 HTTPS 还要做 TLS 握手校验证书里的域名是否和你访问的域名一致。握手成功才发送 HTTP 请求服务器或者它前面的网关、缓存层、负载均衡处理后返回状态码和内容。整个链路里前面那段属于“解析域”后面从握手开始的全属于“服务域”。这个划分的价值在于浏览器给出的错误文案其实已经告诉你断点在哪里了。DNS_PROBE_FINISHED_NXDOMAIN、ERR_NAME_NOT_RESOLVED、找不到服务器 IP 地址——这是名字没翻译出来解析域的问题。ERR_CONNECTION_REFUSED、连接被拒绝——名字翻译出来了但那个 IP 上没人监听这个端口服务域的问题。ERR_CONNECTION_TIMED_OUT、响应时间过长——包发出去了没回应可能是防火墙丢包、路由不通也可能是机器根本不存在。ERR_CERT_DATE_INVALID、您的连接不是私密连接——连接通了TLS 层出问题。新手最容易犯的错是把所有“打不开”都归为“DNS 没生效”因为这是唯一一个他们听说过名字的环节。实际上纯 DNS 故障在所有“站点打不开”的案例里占比并不高更多时候是证书过期、端口没放通、后端进程崩了。所以第一件事永远是读错误文案别跳过它。1.2 三条断点解析、连接、响应我把整条链路简化成三个断点形成一个可以死记硬背的判断框架。第一断点是“名字到 IP”用nslookup或dig验证第二断点是“IP 到端口”用telnet、nc或curl --resolve验证第三断点是“端口到内容”看 HTTP 状态码和响应体。三个断点依次为“通”或“不通”组合起来其实只有几种情况每一种都对应明确的故障域和下一步动作。第一断点解析第二断点端口第三断点响应故障域定位典型原因查不到记录无法测试无法测试解析域记录未添加、记录被删、权威服务器故障、域名状态异常查到记录但 IP 不对连到错误机器可能返回错误页面解析域记录写错、旧记录未清理、多线路配置不一致查到正确记录连接被拒无法测试服务域服务未启动、监听地址错误、端口未放通查到正确记录连接超时无法测试服务域偏网络安全策略拦截、路由不通、机器宕机查到正确记录连接成功5xx服务域后端异常、上游不可达、超时配置过短查到正确记录连接成功证书报错服务域TLS证书过期、域名不匹配、SNI 配置缺失查到正确记录连接成功返回别人的站点服务域虚拟主机默认站点兜底、Host 头未正确匹配这张表我建议你抄在便签上。它的好处是只要前两个断点的结论出来你基本就不用再猜了。比如“查到正确记录 连接被拒”那就别再折腾 DNS 了去服务器上看进程和监听端口反过来“完全查不到记录”你去重启 Web 服务一百次也没用。1.3 一个反直觉的结论多数“解析问题”其实不是解析问题这一点值得单独强调。很多人在改完解析记录后十分钟发现没生效就认定“DNS 出问题了”然后开始疯狂刷缓存、换网络、重启路由器。但 DNS 有 TTL生存时间机制你改的是权威服务器上的记录各地递归服务器还握着旧值的缓存这属于完全正常的设计行为不是故障。TTL 设成 3600 秒就意味着最长要等一小时这个等待是写在协议里的预期不是“出问题”。真正的解析故障有明确的特征查不到记录NXDOMAIN、查到的 IP 和你配置的完全不一样、不同公共 DNS 查出来的结果互相矛盾、权威服务器本身不响应。这些才是需要动手改的。而“改了还没生效”“只有我这台电脑打不开”“刚重启路由器就好了”这类现象多半是缓存和本地配置处理的思路完全不同。分不清这一层你就会把正常的传播等待当成事故来处理越处理越乱。2. 解析域自查从本机缓存一路问到权威服务器确定了方向在解析侧接下来的动作要按“由近及远”的顺序来也就是从你自己的机器开始一层层往外推。这个顺序不能反如果先去看权威服务器的配置你可能会发现配置完全正确然后陷入“配置是对的为什么打不开”的死循环而真正的原因可能是你本机 hosts 文件里三年前留下的一行测试记录。2.1 第一条命令先问“这个名字现在指向谁”不管什么系统nslookup 你的域名是最快的起点。Windows 自带Linux 和 macOS 也基本都有。它输出两部分上面是它用的 DNS 服务器地址下面是解析结果。先看下面——如果有 A 记录并且 IP 和你预期一致说明从你这台机器出发的解析链路是通的问题在服务域直接跳到第三节。如果返回“找不到”“Non-existent domain”“NXDOMAIN”或者返回的 IP 完全不对那就在解析域里继续往下挖。dig的信息量更大我更推荐在有条件时用它dig example.com A short dig example.com Ashort只输出答案适合快速看结果不带参数则给出完整应答重点看几个字段status是NOERROR还是NXDOMAINANSWER SECTION里有几条记录最关键的SERVER字段告诉你这次查询实际问的是哪台递归服务器。很多人排查半天最后发现本机配置的 DNS 指向了一个早就下线的内网地址所有查询都在超时后被静默忽略表现就是“什么都查不到”。还有一个常见坑nslookup在某些系统上会同时对 A 和 AAAA 发起查询如果 IPv6 那条超时整个命令会卡好几秒才返回看起来像“DNS 很慢”。用dig example.com A明确指定类型可以避免这种干扰。2.2 换一台递归服务器再查一次这一步能省下大量时间本机查出来的结果只能代表“你这台机器看到的视图”。要判断是全局问题还是局部问题最有效的一招是换一个公共递归服务器再查一遍dig 某个公共DNS地址 example.com A short如果本机查不到、公共 DNS 能查到说明问题在你本地这条链路上本机缓存、路由器、内网 DNS如果两边都查不到问题在权威侧如果两边查到的 IP 不一样那就是多线路解析或者缓存还没同步属于“部分用户能开、部分用户不能开”的经典成因。这个对比动作只需要十秒钟但它能直接决定你接下来是去清本机缓存还是去域名服务商后台改记录。我见过太多次“整个团队在会议室里争论解析到底生效没有”其实只要两台机器各敲一条命令五秒就能定论。2.3dig trace找到权威服务器也就找到了责任分界点当两边都查不到记录时需要确认“权威服务器上到底有没有这条记录”。dig trace会把从根到顶级的整条查询路径打印出来dig example.com A trace输出的最后几行通常是权威服务器的应答。如果最后显示NXDOMAIN且来自你域名所配置的权威服务器那就是记录本身不存在——可能是没添加、被误删、或者在某个子域层级上写错了。如果trace在中途就断了、某一步一直超时那可能是权威服务器不可达或者域名状态异常这种情况通常需要去域名服务商的控制台看域名本身的状态而不是继续在记录内容上打转。这一步还有个副产品你能明确看到这个域名当前委托给了哪几台权威服务器。如果你在控制台改记录但改的是另一套权威服务器的配置比如域名已经迁到新服务商但域名的 NS 记录还指着旧的那你的修改永远不会生效。这类“改了没反应”的案例根因往往就在这里。2.4 记录类型对不上那些看起来像解析故障的配置错误有时候记录是存在的查询也返回NOERROR但页面还是打不开。这时候要检查记录类型是否匹配A 记录缺失只有 CNAMECNAME 指向的目标如果本身没有 A 记录或者指向了一个已被删除的地址解析会失败。CNAME 链越长越脆弱任何一环断掉整体就断。AAAA 记录指向了不通的 IPv6 地址这是最隐蔽的一类。A 记录正常但同时也存在一条指向早已下线地址的 AAAA 记录。支持 IPv6 的客户端会优先尝试那条路超时后才回落到 IPv4表现就是“页面能开但极慢”或者“部分用户直接打不开”。现代浏览器有回落机制会缓解但服务端和老旧客户端不一定有。CNAME 和 A 记录冲突同一个名字上同时存在 CNAME 和其他记录在 DNS 规范里是不允许的不同递归服务器的处理方式不一致结果就是各地表现不同。泛解析把错误掩盖了配置了*泛解析后任何拼错的子域名都会返回同一个 IP看起来“解析都正常”实际上你测的可能是一个根本不存在的子域。我的习惯是拿到域名后先完整看一遍所有记录而不是只查 A。dig example.com ANY noall answerANY查询在很多服务器上会被限制返回能拿到多少算多少配合控制台后台的记录列表一起看基本不会有遗漏。2.5 hosts 文件与本地缓存那个“只有我打不开”的经典场景如果同事都能打开只有你的机器不行先别怀疑 DNS先看 hosts。这个文件优先级高于 DNS 查询里面任何一行残留记录都会覆盖真实解析WindowsC:\Windows\System32\drivers\etc\hostsLinux / macOS/etc/hosts打开看一眼有没有你正在排查的域名有就注释掉。我遇到过最典型的一次是某个项目为了本地联调把正式域名写进了 hosts 指向测试机联调结束没人清理半年后正式环境迁移只有这位同事的电脑坚持访问旧地址排查了两个小时。排除 hosts 之后清系统 DNS 缓存# Windows ipconfig /flushdns # macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Linuxsystemd-resolved sudo resolvectl flush-caches浏览器自己还有一层缓存有些浏览器内置了 DNS 缓存和连接复用必要时用无痕窗口或者换一个浏览器交叉验证。这一步听起来很基础但在“刷新一下就好了”的场景里它命中的概率高得惊人。3. 服务侧检查端口通不通服务活不活解析侧确认无误——名字能正确翻译成 IP——接下来的问题全部落在服务侧。这里的排查逻辑和解析侧完全不同解析侧是“读配置”服务侧是“做探测”。你要做的是依次验证端口是否可达、TLS 是否正常、HTTP 是否返回了合理的响应。三者中任何一环出问题用户看到的现象都是“打不开”但修复动作差别很大。3.1 端口连通性telnet、nc、curl怎么选最直接的探测是看目标 IP 的端口能不能连上telnet 203.0.113.10 443 # 或 nc -zv 203.0.113.10 443连上会显示Connected或succeeded被拒绝Connection refused说明包到达了主机但那个端口上没有程序在监听——这就是服务没起来或者监听在了 127.0.0.1 而不是 0.0.0.0。如果一直卡住直到超时那是另一种情况包在路上被丢掉了通常是安全策略、防火墙或路由的问题跟进程无关。这两者的区别非常重要因为它直接决定你该找谁拒绝 你的事服务/配置超时 链路的事策略/网络。很多人在“超时”的情况下反复重启服务重启一百次也没用因为请求根本没到机器上。telnet在不少新系统上默认没装nc的参数各家实现还不一样所以我更常用curl它一个工具能覆盖后面所有步骤curl -sv --max-time 10 https://example.com/ -o /dev/null-v会打印完整的握手过程包括 DNS 解析出的 IP、TCP 连接、TLS 握手、请求头和响应头。这是排查服务侧最好用的一条命令因为它把三个断点的信息一次性全给你了。看输出时按顺序读先看Trying x.x.x.x:443这一行确认连的是哪个 IP再看有没有Connected再看 TLS 握手有没有报错最后看响应状态码。3.2curl --resolve绕开 DNS 直连指定服务器这是我认为最值得掌握的一个技巧。当你怀疑“解析已经指到新机器了但新机器本身有问题”时可以把域名和 IP 的对应关系临时写进 curl让它跳过 DNS 直接打指定 IP同时保留正确的 Host 头和 SNIcurl -I --resolve example.com:443:203.0.113.10 https://example.com/这一条命令的价值在于它把“解析”这个变量彻底固定住了。如果--resolve指定新 IP 能正常返回 200而正常访问不行那问题 100% 在解析还没生效或者解析指错了如果--resolve指定新 IP 也打不开那问题 100% 在新机器上跟 DNS 一点关系没有。一次对比双向排除比任何推理都可靠。同样的思路在线路切换、灰度验证、证书部署验证时都用得上。比如证书换了新的但用户还在报错你可以用--resolve直连某一台确认新证书是否真的装上了而不用等 DNS 传播。3.3 证书与 SNI最像“解析问题”的一类假故障证书问题是我见过误判率最高的一类。用户看到“您的连接不是私密连接”第一反应往往是“域名解析错了”因为浏览器有时会提示“该证书不属于此网站”。但实际上证书不匹配根本原因通常是服务端配置而不是解析。判断方法很直接openssl s_client -connect 203.0.113.10:443 -servername example.com /dev/null 2/dev/null | openssl x509 -noout -subject -dates-servername这个参数是关键。一台服务器上跑了多个站点时服务端要靠 SNI 里的域名来决定返回哪张证书。如果缺了这个参数或者服务端没配 SNI它会返回默认站点的证书于是证书上的域名和你访问的域名不符浏览器直接拦下。这种情况下解析完全正常就是配置问题。看输出的dates也能立刻判断是不是过期。证书过期在浏览器里的表现有时非常像“网站挂了”尤其是在移动端报错页可能只显示一句“无法访问”。所以只要看到和 TLS 相关的报错第一件事就是查有效期这个动作三秒钟能排掉相当一部分事故。另外还有一个容易被忽略的点服务端系统时间不准。证书校验依赖时间如果服务器时钟漂移你自己用浏览器访问可能正常但服务端之间的调用会报“证书尚未生效”或者“证书已过期”。这种情况在容器环境里偶有发生值得在疑难杂症时顺手date一下。3.4 5xx 的真实含义走到这一步解析早就通了如果curl拿到了一个 5xx 状态码恭喜你这说明前面所有环节都是通的名字解析成功、TCP 连接成功、TLS 握手成功、HTTP 请求被接收并处理了——只是处理失败了。很多人看到 502 还在查 DNS这是纯粹的方向性错误。状态码含义通常的排查方向502网关从上游收到了无效响应后端进程崩了、上游端口不对、上游主动断连503服务暂时不可用后端全部不健康、连接池耗尽、限流触发504网关等待上游超时后端处理太慢、超时阈值设得太短、数据库慢查询521 / 522 / 523中间层连不上源站源站地址配错、源站端口未放通、源站证书异常403被拒绝访问控制、来源校验、路径权限404找不到路由配置、路径重写规则、默认站点兜底521、522 这类自定义状态码来自中间层缓存层或转发层它们的含义非常明确中间层自己活得很好是它连不上你的源站。这时候要查的是“中间层配置里写的源站地址和端口对不对”“源站有没有对中间层的出口地址放行”而不是继续查用户侧的 DNS。还有一个很隐蔽的情况返回 200 但内容是错的。比如所有域名都返回同一个默认站点页面或者返回一个“欢迎使用”的安装引导页。这类现象说明请求到了服务器但 Host 头没有被正确匹配到对应的站点配置服务器用了默认站点用保底。问题在虚拟主机配置同样属于服务域。4. 现象翻译把“打不开”拆成可执行的线索排查效率的差距很多时候不在于命令敲得多熟练而在于能不能把用户那句模糊的“打不开”翻译成结构化的线索。用户说“打不开”的时候实际上包含了大量信息只是他自己不知道哪些有用。你要做的是主动追问几个固定问题把现象收敛到具体的故障域。4.1 追问清单五个问题定方向我通常会问这几件事顺序固定浏览器上具体显示什么要原文或截图不要“就是打不开”这种转述。错误码是最有价值的信息。是所有页面都打不开还是只有某个页面首页能开、某个接口 502那根本不是解析问题是那一个服务的问题。是所有人都打不开还是只有部分人这个问题的答案直接决定故障域的范围。换个网络比如手机流量能打开吗能打开说明是本地链路或本地缓存不能打开说明是服务端或全局解析。最近改过什么换服务器、改解析、续证书、发版本、调安全策略——任何一项都值得怀疑。这五个问题问完八成的情况已经能定位到某一侧了。剩下的两成用第二节和第三节的命令去验证。这套流程的好处是它不依赖经验直觉任何人照着问都能得到可用的结论。4.2 “部分地区打不开”先分是线路还是节点这是最容易被误判成“解析问题”的场景因为“部分地区”听起来很像 DNS 传播不一致。但实际原因至少有三类需要用不同方法区分多线路解析导致的分裂域名给不同运营商配了不同的 IP某条线路的 IP 已经失效。判断方法是查不同公共 DNS 看返回的 IP 是否不同然后逐个curl --resolve测。缓存层节点差异接了内容分发后不同地区走不同节点。判断方法是多次解析看返回的 IP 是否在变然后针对具体节点测连通性。源站出口策略源站对某些回源地址段做了限制导致某些节点拿不到内容。区分这三类的关键动作是抓一个打不开的用户的所在地然后用解析工具看那个地区会返回哪个 IP最后对这个 IP 单独做连通性测试。如果那个 IP 本身就连不上是解析指错了地址如果那个 IP 能连上但内容不对是节点或回源的问题。4.3 改了记录为什么迟迟不生效TTL 与负缓存这是被问得最多的问题值得单独说清楚。你在控制台把 A 记录从旧 IP 改成新 IP点了保存控制台显示“已生效”但用户还在访问旧地址。原因有四个层次第一层是TTL。权威服务器告诉递归服务器“这条记录可以缓存 N 秒”在这 N 秒内递归服务器不会再来问它直接给你旧值。这是设计行为。想要快速切换唯一正确的做法是提前把 TTL 调小等旧 TTL 过期后再改记录改完再调回来。临时抱佛脚改记录等待时间是躲不掉的。第二层是负缓存。如果你之前查的是一个还不存在的子域名返回了 NXDOMAIN这个“不存在”的结论也会被缓存一段时间。等你把记录加上了递归服务器还在负缓存的窗口里继续告诉你“不存在”。这解释了那种“明明加了记录却还是查不到”的怪现象。第三层是中间层自己的缓存。有些转发层会按自己的策略缓存解析结果不完全遵守你设的 TTL。这种情况只能联系服务方确认或者临时换一条解析路径验证。第四层是客户端缓存。浏览器、操作系统、甚至某些客户端软件都有自己的缓存你改了服务端用户机器上还留着一份。这也是为什么“清一下缓存就好了”这种建议虽然听起来敷衍但确实是有效的。有一个实用技巧切换前把 TTL 降到 60 秒观察至少两个旧 TTL 周期再动手改指向。这个动作能让你的切换窗口从一小时压到几分钟代价只是提前一天操作。4.4 那张“看起来没问题”的配置往往有一个字段是错的排查到最后绝大多数根因都不是什么复杂机制而是一个具体的、肉眼可见的字段错误。我整理了几种高频的写法问题你可以对照着检查末尾多了一个点example.com.和example.com在有些控制台里含义不同前者是绝对域名后者可能被拼上默认后缀结果变成example.com.yourdomain.com。CNAME 指向了相对名字同样会被拼接默认后缀指向一个不存在的目标。端口写进了记录DNS 记录里不能带端口example.com:8080这样的写法在部分控制台会被当成非法或错误解析。复制粘贴带进了空格行首行尾的空格在部分界面里不可见但会导致校验失败或者记录被截断。同一个名字有两条冲突记录为了“保险”同时留了旧 IP 和新 IP结果流量随机分到两台机器一台是旧的表现就是“时好时坏”。“时好时坏”这个现象特别值得警惕它几乎总是意味着有多条记录同时存在而其中一部分是无效的。单条记录要么通要么不通不会时通时不通。遇到间歇性故障第一件事就是数一数这个域名到底有几条 A 记录。5. 一次迁移事故的完整排查链路下面这个案例是我自己经手的为了让过程可复现细节做了脱敏处理涉及的地址和域名均为示例值。选它是因为它同时踩了两个坑而且最初的判断方向是错的正好能说明“先分故障域”这个习惯有多重要。5.1 现象与最初那个错误的判断某个站点从旧服务器迁移到新服务器操作流程看起来完全标准新机器部署好、证书装好、本地用 IP 加 Host 头测试通过、控制台改 A 记录、等待。改完两小时后反馈开始进来一部分用户能正常访问另一部分用户仍然打开的是旧页面还有少数用户直接报“无法访问”。当时的第一个判断是“解析还没传播完”理由是“有人能打开就说明新服务器没问题”。这个判断有一半是对的——新服务器确实没问题——但结论错了因为“有人能打开”并不能推出“打不开的人只是还没轮到”。这个推理漏洞很常见把“存在成功样本”当成“服务端正常”的证据然后就把所有失败都归到解析传播上于是白白等了两个小时。转机出现在有人问了一句“打不开的那几个人是不是都是同一个地方的”一核对确实集中在某一类网络环境下。这个信息立刻把“随机传播”这个假设推翻了一半——如果是传播未完成分布应该是随机的不该有这种聚集性。5.2 分层验证四条命令锁定范围接下来按第二节和第三节的顺序做了四件事大概花了六分钟。第一步查新老两台机器的记录dig example.com A short dig 公共DNS example.com A short本机查到的是新 IP公共 DNS 查到的也是新 IP。这一步说明解析记录本身已经更新了而且主流的递归服务器都拿到了新值。到这里从“记录内容”这个角度看解析是没问题的。第二步查 AAAA。这一步是转折点dig example.com AAAA short返回了一条 IPv6 地址而且这个地址属于旧服务器。也就是说迁移时只改了 A 记录AAAA 记录被完整地留在了旧地址上。支持 IPv6 的客户端优先走这条路而旧服务器上的服务已经被停掉了表现就是连接超时也就是用户看到的“无法访问”。那些能正常打开的用户恰好走的是 IPv4 路径。第三步验证这个假设curl -6 -I --max-time 10 https://example.com/ curl -4 -I --max-time 10 https://example.com/强制走 IPv6 时超时强制走 IPv4 时返回 200。假设成立。第四步排除“旧服务器上其实还有服务”这种可能curl -I --resolve example.com:443:旧服务器IP https://example.com/直连旧 IP 返回连接被拒确认旧服务确实已下线。整条链路到这里闭环了。5.3 根因与修复一条没被清理的记录根因很明确迁移清单里只列了 A 记录没有列 AAAA 记录。这条 IPv6 记录可能是很久以前做双栈测试时留下的之后一直没人管因为它“不影响使用”——在旧服务器还活着的时候AAAA 指向旧服A 指向旧服两边都能通问题就被掩盖了。迁移把 A 改走AAAA 留在原地问题才暴露出来。修复动作有两步先把 AAAA 记录改成新服务器的 IPv6 地址如果新服务器有或者直接删掉这条记录如果暂时不打算支持 IPv6然后等待旧 TTL 过期。改完之后再用dig AAAA和curl -6双向验证确认一致。这里有个决策点值得说明删掉还是改成新地址。如果新服务器没有 IPv6 出口硬填一个不可达的地址只会制造更隐蔽的问题所以直接删除更稳妥如果新服务器支持双栈那就改成新地址保留双栈能力。判断依据是新机器上是否真的监听了 IPv6用ss -lntp | grep 443看监听地址是0.0.0.0还是::一看便知。5.4 复盘五个以后再也不会犯的细节这次事故之后我把几个教训写进了团队的自检清单第一迁移清单必须列全所有记录类型。A、AAAA、CNAME、MX、TXT 全都要过一遍不能只看 A。TXT 记录里的域名校验信息如果丢了会影响其他服务的验证流程。第二“有人能打开”不能作为服务端正常的证据。只能说明“至少有一条路径是通的”剩下几条路径是否有问题必须单独验证。第三现象有聚集性就一定不是随机传播。传播未完成的表现是分散的聚集在某个地区、某种网络、某个客户端版本说明有确定性的原因。第四切换前先看dig ANY的完整输出。哪怕服务器只返回一部分也比你只查 A 看到的信息多。我现在养成了习惯接手任何一个域名先完整看一遍记录而不是直奔 A 记录。第五验证必须用不同协议栈各跑一遍。IPv4 通、IPv6 不通这种半通状态最难排查因为大部分工具默认只走其中一条。6. 把判断固化成清单别靠临场反应排查能力的高低很多时候不体现在知不知道某个命令而体现在顺序是否固定。临场反应式的排查每次都要重新想“我现在该查什么”容易漏、容易绕圈固定顺序的排查哪怕状态不好、半夜三点被叫起来也能机械地走完流程把范围一步步缩小。下面这份清单是我自己用的版本你可以直接拿去改成适合自己环境的。6.1 上线与迁移前的自检清单检查项具体动作通过标准记录完整性dig 域名 ANY比照控制台记录列表所有类型记录都指向新目标无遗留双栈一致性分别dig A和dig AAAA有 AAAA 时必须指向可用地址否则删除目标可达性curl --resolve 域名:443:新IP返回预期状态码内容正确证书有效性openssl s_client -servername域名匹配、未过期、链完整TTL 预降提前一天把 TTL 调到 60切换窗口可控冲突记录确认同名下只有一组目标地址不存在新旧并存默认站点用未配置的 Host 头访问看返回不会误返回其他站点内容监听地址ss -lntp看端口绑定绑定在对外地址非仅回环这份表格看着简单但它覆盖了我遇到的绝大多数迁移事故。尤其是“冲突记录”和“监听地址”这两项出问题的频率远超预期——前者造成间歇性故障后者造成“本机测试正常、外面访问不通”的诡异现象。6.2 一段可以随手复用的排查脚本我把前面几步串成了一个脚本放在跳板机上出问题时改两个变量直接跑#!/usr/bin/env bash DOMAINexample.com IP203.0.113.10 echo 1. A 记录 dig short $DOMAIN A echo 2. AAAA 记录 dig short $DOMAIN AAAA echo 3. 换公共 DNS 复查 dig short ${PUBLIC_DNS:-223.5.5.5} $DOMAIN A echo 4. 直连指定 IP跳过解析 curl -sI --max-time 10 --resolve $DOMAIN:443:$IP https://$DOMAIN/ | head -n 1 echo 5. 默认路径访问 curl -sI --max-time 10 https://$DOMAIN/ | head -n 1 echo 6. 证书信息 openssl s_client -connect $IP:443 -servername $DOMAIN /dev/null 2/dev/null \ | openssl x509 -noout -subject -dates第 4 步和第 5 步的对比是这个脚本的核心如果第 4 步通、第 5 步不通问题在解析如果两步都不通问题在服务端如果两步都通但用户还在报错那就该去查缓存和中间层了。这一组对比能在十秒内给出方向剩下的事就好办了。脚本里的公共 DNS 地址请换成你环境中实际可用的不同网络环境下可用的地址可能不一样这一点在受限网络里尤其要注意。6.3 我个人的几条经验最后分享几个不在文档里、但实际用起来很省时间的习惯。别在第一次判断时就下结论。我的经验是第一次形成的判断有相当比例是错的所以要主动找一个能证伪它的动作。比如你判断“是 DNS 没生效”那就去找一个“解析已经生效”的证据如果找不到判断就不成立。这个思维习惯比任何工具都有价值。先看错误文案再看日志。用户的截图里往往已经写着答案只是被当成噪音忽略了。我见过太多次日志翻了半小时最后发现浏览器上明明白白写着“证书已过期”。改完必验证而且要用不同路径验证。改完记录用本机查一遍是不够的要换公共 DNS 查、要直连 IP 测、要分别用 IPv4 和 IPv6 试。因为你的本机缓存可能是最后一个更新的本机看到的结果最不具代表性。把每次事故的根因记下来。不是为了流程而是因为同类问题会重复出现。我这份清单里超过一半的条目都是某次具体事故之后加进去的。第一条 AAAA 记录就是那次迁移之后补上的。给自己留一个“最小可复现”的测试域名。一个只配了 A 记录、指向一台最简静态页面的域名在不清楚是环境问题还是配置问题时用它做对照实验非常有效。如果它能打开而你的目标域名打不开两者配置的差异就是答案。
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化