DNS解析明明成功，业务为什么还是连不上？从记录到连接的排查顺序

很多“网站打不开”的问题第一反应是查防火墙但有些故障在更早的地方域名解析结果和客户端实际使用的地址并不一致。先确认客户端到底拿到了什么不要只看浏览器提示。先分别查询 A 和 AAAA 记录dig example.com A noall answer dig example.com AAAA noall answer如果同时返回 IPv4 和 IPv6客户端可能优先尝试 IPv6。服务器只开放了 IPv4 时浏览器会先等待 IPv6 失败再回退到 IPv4看起来就像“偶尔打不开”。可以用 curl -4 -v https://example.com/ 和 curl -6 -v https://example.com/ 分别验证。还要注意 DNS 缓存。权威服务器已经更新不代表本机、企业 DNS 或运营商缓存立即更新。dig 指定DNS服务器 example.com 可以用来比较不同解析链路但不要把某个公共 DNS 的结果当成所有用户的结果。解析正确连接仍可能走错地址确认地址后用路由查询判断系统准备从哪个接口出去ip route get 203.0.113.10多网卡、VPN 和策略路由环境中目标地址相同出口接口可能不同。路由正确也不代表安全组、代理或 NAT 已放行。此时再用curl --connect-timeout 5 -v https://example.com/把问题分成 TCP 连接失败、TLS 握手失败和 HTTP 响应错误。收到 404 或 503 时DNS 和 TCP 通常已经不是首要问题继续改解析记录只会扩大排查范围。别忽略 Host 和 SNI一台 IP 上可能托管多个站点。直接访问 IP即使 TCP 成功也可能因为 Host 或 TLS SNI 不匹配而落到默认站点。测试特定解析结果时可以保留域名同时指定目标地址curl --resolve example.com:443:203.0.113.10 https://example.com/ -v这个命令同时携带正确的域名和 SNI适合判断“某个地址上的站点是否正常”比直接把 URL 改成 IP 更接近真实访问。一套稳定顺序建议按照“记录内容 → 地址族 → 本机缓存 → 路由出口 → TCP → TLS → HTTP”的顺序排查。每一步记录实际输出不要同时修改 DNS、路由和防火墙否则很难知道哪项变化产生了影响。如果你想把网络基础、Linux 和安全排错串成一套实验路径可以参考马士兵网络安全课程学习入口