诊断工具与排障路径

第一步：固定问题

先记录：

• 失败对象：域名、IP、端口、URL 与协议。
• 时间和频率：持续失败、偶发、只在高峰出现。
• 范围：单进程、单主机、单网络还是跨地区。
• 最近变化：证书、DNS、路由、代理、系统更新、发布。
• 对照组：换网络、换设备、直接访问源站是否不同。

用一个最小请求替代复杂 GUI。例如浏览器失败时先尝试 curl -v，这样能看出失败发生在解析、连接、TLS 还是 HTTP。

本机配置与路由

Linux 常用：

ip address
ip route
ip route get 203.0.113.5
ss -lntup

macOS 常用：

ifconfig
route -n get 203.0.113.5
networksetup -getinfo Wi-Fi
lsof -nP -iTCP -sTCP:LISTEN

检查接口是否启用、地址与前缀是否合理、默认路由指向哪里、目标将从哪个接口发出。127.0.0.1 只代表本机；服务只监听环回地址时，远端不能通过网卡地址访问。

DNS：名称是否得到预期答案

dig api.example.com A
dig api.example.com AAAA
dig @1.1.1.1 api.example.com A
dig +trace api.example.com

比较系统配置解析器与指定公共解析器可以帮助定位缓存或企业 DNS 差异，但公共解析器未必拥有内部域名视图。关注响应状态、记录类型、TTL、权威信息和返回地址。

不要把 dig 成功等价为应用一定解析相同结果。应用可能使用系统搜索域、hosts 文件、自己的缓存或加密 DNS。必要时检查应用实际连接的地址。

可达性与路径

ping -c 4 203.0.113.5
traceroute 203.0.113.5

macOS 和不同 Linux 工具的选项略有差异。ping 成功证明回显请求和响应在当时可达，不证明 TCP 443 可用；失败也可能只是 ICMP 被限速。traceroute 中某一跳不响应而后续跳响应，通常说明该路由器不返回探测消息，不等于流量在那里中断。

判断丢包时应看终点和业务流，而不是只看中间路由器的 ICMP 响应率。路径可能负载均衡，连续探测也可能走不同路线。

端口与传输层

nc -vz api.example.com 443
curl --connect-timeout 5 -v https://api.example.com/

常见结果：

现象	初步含义	下一步
立即 connection refused	可达但无监听，或设备主动拒绝	查服务监听与目标端口
长时间超时	静默过滤、无路由、回程问题或严重丢包	查防火墙、路由、抓包
建连后立刻关闭	应用协议或访问策略不匹配	查服务日志与协议
偶发成功	负载均衡后端、路径或资源耗尽	分地址、分后端重复测试

服务端同时检查监听地址、连接队列、文件描述符和进程状态。只监听 IPv6 或只监听 127.0.0.1 都可能造成“本机能访问、远端不能”。

TLS 与证书

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com

检查证书链、有效期、主机名、协商版本、ALPN 和验证返回码。-servername 提供 SNI；遗漏它可能拿到同一 IP 上的默认证书。系统时间错误会让有效证书看似过期或尚未生效。

若命令行成功而浏览器失败，比较代理、信任库、客户端证书、HSTS 和浏览器扩展。不要以 -k 跳过验证作为修复，它只掩盖身份问题。

HTTP 与应用层

curl -v https://api.example.com/health
curl -I https://api.example.com/static/app.js
curl -L -v https://example.com/

查看状态码、重定向位置、Host、缓存字段、内容类型与响应时间。200 也可能携带业务错误；503 常指代理没有健康上游或服务过载；301/302 循环可能来自代理协议识别错误。

用 --resolve 可在保留 URL 主机名和 TLS SNI 的同时指定测试 IP：

curl --resolve api.example.com:443:203.0.113.5 \
  https://api.example.com/

这能区分 DNS 调度与某个后端，但不要长期写入错误地址绕过正式服务发现。

抓包：看实际发生了什么

sudo tcpdump -i any -nn 'host 203.0.113.5 and port 443'
sudo tcpdump -i any -nn -w capture.pcap 'host 203.0.113.5'

macOS 常选择明确接口如 en0，Linux 的 any 便于观察多接口但链路层信息可能不同。抓包重点寻找：

• DNS 查询有没有响应，应用最终选择哪个地址。
• SYN 是否发出，SYN+ACK 是否回来，是否反复重传。
• TLS Alert 出现在握手哪一步。
• TCP 是否有重复 ACK、重传、零窗口或 RST。
• ICMP 是否报告不可达或分组过大。

抓包看到“客户端发送了 SYN”只证明分组到达抓包点；要定位路径，最好在客户端、服务端或关键中间点同时观察。TLS 加密后通常看不到 HTTP 内容，但仍能分析握手和时序。

一个完整排障例子

现象：域名偶尔连接超时。

1. dig 发现域名轮询返回三个 IP。
2. 用 curl --resolve 分别测试，只有一个 IP 超时。
3. 客户端抓包显示发出 SYN 但无 SYN+ACK。
4. 故障后端抓包没有看到 SYN，正常后端可看到。
5. 比较路由与防火墙，发现新网段未加入入口 ACL。
6. 修复 ACL 后分别测试三个 IP，再测试正常 DNS 调度。

这个过程没有一开始就重启所有服务器，而是用地址拆分把“偶发”转化为“固定后端必现”，再用双端抓包缩小到入口之前。

排障工具的限制

工具返回的是一次观测，不是完整真相。缓存会改变路径，负载均衡会改变后端，防火墙会对 ICMP 和 TCP 区别处理，抓包位置也可能在硬件卸载前后看到不同分段。结论应由多条相互支持的证据构成。

最短运行手册

先 dig，再 route，再测实际端口，然后验证 TLS 与 HTTP；只有现有证据无法区分假设时再抓包。每一步都记录时间和目标地址。