故障排查流程图
用结构化的思维框架处理故障，比随机尝试更快找到根因。
总体排查思路：分层定位
graph TD
A[用户反馈站点有问题] --> B[确认问题范围]
B --> C{只有你自己看到？}
C -->|是| D[本地问题
清除缓存/换网络/换浏览器] C -->|否| E[确认全球还是局部] E --> F{全球都有问题？} F -->|是| G[从 DNS 层开始排查] F -->|否| H[局部问题
CDN 节点/ISP 问题] G --> I[DNS → 网络 → SSL → 应用 → 内容]
清除缓存/换网络/换浏览器] C -->|否| E[确认全球还是局部] E --> F{全球都有问题？} F -->|是| G[从 DNS 层开始排查] F -->|否| H[局部问题
CDN 节点/ISP 问题] G --> I[DNS → 网络 → SSL → 应用 → 内容]
排查原则：从底层到上层，逐层排除。
完整排查流程
第一层：DNS 层
# 1. 域名能解析吗？
dig example.com A +short
# 无结果 → DNS 问题
# 2. 解析结果是否正确？
dig @8.8.8.8 example.com A +short
# 结果不是你的服务器 IP → DNS 记录错误或未传播
# 3. NS 记录是否正确？
dig example.com NS +short
# 不是你的 DNS 托管商 → NS 配置错误
第一层通过标准：dig example.com A +short 返回正确的服务器 IP。
第二层：网络层
# 1. 服务器 IP 是否可达？
ping 203.0.113.5
# 超时/无响应 → 服务器宕机或防火墙拦截
# 2. TCP 端口是否开放？
nc -z -v 203.0.113.5 443
# Connection refused → 443 端口未监听
# 3. 路由追踪（找到在哪一跳出问题）
traceroute example.com
第二层通过标准：ping 有响应，443 端口可连接。
第三层：SSL 层
# 1. SSL 握手是否成功？
echo | openssl s_client -connect example.com:443 -servername example.com 2>&1 | head -20
# 看是否有 Verify return code: 0 (ok)
# 2. 证书是否过期？
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
# 3. 证书域名是否匹配？
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject
第三层通过标准：SSL 握手成功，证书有效，域名匹配。
第四层：应用层
# 1. HTTP 响应状态是否正常？
curl -s -o /dev/null -w "%{http_code}" https://example.com
# 200 → 正常
# 301/302 → 跳转（检查跳转目标是否正确）
# 4xx → 应用错误（路由/权限问题）
# 5xx → 服务器错误（应用崩溃/数据库连接失败）
# 2. 跳转是否正确？
curl -I http://example.com
# Location: https://example.com/ → 正确的 HTTP→HTTPS 跳转
# 3. 检查服务器日志
tail -100 /var/log/nginx/error.log
tail -100 /var/log/nginx/access.log | grep " 5[0-9][0-9] "
第四层通过标准：HTTP 200，应用正常响应。
快速诊断清单（60 秒版）
# 30 秒内完成基础诊断
echo "=== DNS ===" && dig example.com A +short
echo "=== HTTP ===" && curl -s -o /dev/null -w "%{http_code}" https://example.com
echo "=== SSL ===" && echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates 2>/dev/null
echo "=== Ping ===" && ping -c 3 example.com | tail -1
常见故障 → 根因速查表
| 症状 | 最可能的根因 | 第一个排查命令 |
|---|---|---|
| DNS_PROBE_FINISHED_NXDOMAIN | DNS 记录不存在 | dig example.com A +short |
| ERR_CONNECTION_TIMED_OUT | 服务器宕机/防火墙 | ping example.com |
| ERR_CONNECTION_REFUSED | 端口未监听 | nc -z 203.0.113.5 443 |
| NET::ERR_CERT_DATE_INVALID | 证书过期 | openssl s_client 查日期 |
| NET::ERR_CERT_COMMON_NAME_INVALID | 证书域名不匹配 | 检查证书 Subject |
| 502 Bad Gateway | 后端应用挂了 | 查 Nginx error.log |
| 504 Gateway Timeout | 后端响应太慢 | 查数据库/应用日志 |
| 邮件退信 | SPF/DKIM 验证失败 | MXToolbox SuperTool |
| 部分地区打不开 | CDN 节点问题/DNS 未完全传播 | dnschecker.org |
真实案例：一次完整的四层排查过程
场景：某电商站点从 GoDaddy 迁移域名到 Cloudflare 两天后，客户反馈"网站打不开"，但运营人员在自己电脑上看是正常的。
第一步：确认问题范围
用户说"打不开"，但我本地是好的 → 不是全局故障，是局部/传播问题
# 用 Google 的公共 DNS 检查
dig @8.8.8.8 example.com A +short
# 返回：104.21.xx.xx（Cloudflare IP，正确）
# 用本地 DNS 检查
dig example.com A +short
# 返回：203.0.113.45（GoDaddy 旧服务器 IP，错误！）
根因定位：本地 ISP 的 DNS 缓存仍在使用旧 NS 记录，TTL 还没过期。客户用的是同一 ISP，同样的缓存问题。
第二步：确认 NS 传播状态
dig example.com NS +short
# 返回：ns1.godaddy.com（还未切换到 Cloudflare！）
发现真正问题：NS 记录在域名注册商处没有保存成功（操作员以为保存了但其实没有）。这不是缓存问题，而是配置根本没生效。
修复步骤：
- 登录 GoDaddy 域名管理，确认将 NS 改为 Cloudflare 的 4 条 NS 记录
- 等待 NS 传播（4–48 小时）
- 用 dnschecker.org 监控全球 NS 传播进度
- 传播完成后，用 dig 验证：
dig example.com NS +short
# → chloe.ns.cloudflare.com（正确）
dig @8.8.8.8 example.com A +short
# → 104.21.xx.xx（Cloudflare CDN IP）
结论：整个排查从"用户说打不开"到"确认根因是 NS 未保存"只用了 5 分钟，因为第一层就找到了差异（本地 DNS 和公共 DNS 返回不同结果）。分层排查的价值是排除无关因素，快速缩小问题范围。
常见误区
| 误区 | 正确做法 |
|---|---|
| "清除浏览器缓存就解决了" | DNS 缓存在操作系统层，浏览器缓存清除无效——需要 ipconfig /flushdns（Windows）或 sudo dscacheutil -flushcache（Mac） |
| "等 24 小时肯定传播完了" | NS 变更传播时间取决于旧 NS 的 TTL，可能超过 48 小时——用 dnschecker.org 监控而非猜测 |
| "本地访问正常就没问题" | 本地 DNS 和全球 DNS 可能返回不同结果——总是用 dig @8.8.8.8 验证 |
| "502 是 DNS 问题" | 502 说明 DNS 和网络层都通了，是后端应用挂了——从 Nginx error.log 入手 |
本章执行清单
- [ ] 保存本章的快速诊断脚本到你的运维手册
- [ ] 测试所有命令在你的环境中是否可用（
dig、curl、openssl） - [ ] 在 dnschecker.org、MXToolbox、SSL Labs 建立你的站点监控收藏夹
- [ ] 设置站点监控告警（推荐：UptimeRobot 免费版，每分钟检查一次）
下一章：电商与独立站运营实战——把所有知识用到 Shopify、Cloudflare、GitHub Pages 的实际配置中。