US.KG 故障排查决策树：从注册、DNS 委派到 HTTPS 的分层排障方法

US.KG 故障排查决策树：从注册、DNS 委派到 HTTPS 的分层排障方法

【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG

在 US.KG（免费域名注册与 DNS 实践学习仓库）的教程附录中，故障排查决策树 提供了一套“一次只走一棵树、先记录观察再改配置”的分层排障方法。本文完整继承文档中的八棵决策树与回滚判断准则，并结合仓库中 DNS 故障排查、TTL 与缓存、部署连接、HTTPS、邮件 DNS 等章节的命令与检查要点，把每个决策节点落到可执行的dig/curl命令与验证证据上。读完本文，你可以面对“域名不解析、网站超时、HTTPS 失败、只有部分用户异常”等典型故障时，按确定的顺序逐层定位问题，并判断何时该回滚而不是继续诊断。

使用方法：一次一棵树，先取证后改配置

原文档给出的使用原则只有两句话，但决定了整套流程的可靠性：

1. Use one tree at a time（一次只走一棵树）——避免同时排查多个层级时把故障现象搅乱；
2. Record observations before changing configuration（修改配置前先记录观察）——每一步的查询结果都是后续判断和回滚的证据。

这与仓库 DNS 故障排查章节 开头的原则一致：“从委派（delegation）向最终服务逐层排查，不要一次改动多个层级”。配合 检查清单与模板附录 中的DNS Change模板（记录当前值、TTL、预期值、回滚值、回滚决策时间）使用，可以让每棵树的排查过程都有书面留痕。

下面的每个小节对应原文档的一棵树。决策树原样保留，随后补充该树上每个判定节点在本仓库中对应的验证命令和背景知识。

树 1：域名不解析（Domain Does Not Resolve）

Does Domain List show the expected active registration? |-- No -> Fix registration status first. `-- Yes | Does dig NS show the intended external nameservers? |-- No -> Check registration-level NS values and cached delegation. `-- Yes | Does each authoritative server answer SOA? |-- No -> Fix the external DNS zone or service availability. `-- Yes | Does the requested record exist on the authoritative server? |-- No -> Add or correct it in the external DNS zone. `-- Yes -> Compare recursive cache and TTL.

这棵树沿着“注册 → 委派 → 权威区 → 记录”的链路逐级下探，四个判定节点分别对应：

• Domain List 状态检查：先确认注册平台（教程中以 DigitalPlat 为例）控制台的域名列表中该域名处于预期的活跃注册状态。注册状态异常时，任何 DNS 层排查都没有意义。
• dig NS检查委派：执行dig NS example.dpdns.org确认返回的是注册处配置的外部权威 NS 集合。委派章节 中给出的dig +trace NS example.dpdns.org可以进一步看到父级到子域的委派链，委派结果应当指向注册服务商处配置的权威服务器。
• 每台权威服务器回答 SOA：逐一执行dig @ns1.dns-service.example SOA example.dpdns.org、dig @ns2.dns-service.example SOA example.dpdns.org，所有权威服务器都应能回答该区域。长期返回不同序列号或不同值，说明 DNS 服务商可能未同步区域。
• 直查记录并比较递归缓存：用dig @ns1.dns-service.example A www.example.dpdns.org直接问权威服务器；若权威答案正确而递归答案陈旧，属于 TTL 与缓存章节 描述的“权威状态与缓存状态分离”——等待比反复改记录更安全。注意负缓存：刚创建记录后，部分解析器可能仍按之前缓存的否定答案返回NXDOMAIN。

树 2：DNS 已解析但网站超时（DNS Resolves but Website Times Out）

Does the hostname return the intended address? |-- No -> Fix external DNS. `-- Yes | Is the server reachable on the network? |-- No -> Check routing and server availability. `-- Yes | Is port 80 or 443 listening? |-- No -> Start or configure the web server. `-- Yes | Do network and host firewalls allow the connection? |-- No -> Apply the reviewed firewall rule. `-- Yes -> Check virtual host, TLS, and application logs.

这棵树的关键前提是“DNS 只负责定位服务器”——域名能解析只说明链路的上半程正常。验证命令沿用 部署与连接章节 的做法：

curl -I http://example.dpdns.org curl -I https://example.dpdns.org

“DNS 查询成功但 HTTP 超时”通常指向服务器进程、防火墙或路由问题。排查顺序建议：

1. 用curl -I确认 80/443 是否有响应；超时（而非报错）一般对应网络路径或防火墙问题；
2. 在服务器本机确认 Web 服务进程在运行且端口在监听；
3. 检查网络层防火墙（云安全组/边界）与主机防火墙两层——两者独立生效，规则需要分别放行；
4. 两层防火墙都放行后，才去看虚拟主机配置、TLS 和应用日志。

树 3：出现了错误的网站（Wrong Website Appears）

Does DNS return the intended server? |-- No -> Correct the external DNS record. `-- Yes | Does curl with the Host header return the intended virtual host? |-- No -> Fix server_name or virtual-host ordering. `-- Yes | Is a proxy or browser cache serving old content? |-- Yes -> Inspect cache headers and purge only the correct cache. `-- No -> Check deployment directory and current revision.

“网站能打开但不是你要的那个”比“打不开”更容易误判，因为表面上链路是通的。树上第二个节点给出了最实用的定位手段：带上Host头直接访问服务器 IP，例如curl -I -H "Host: example.dpdns.org" http://<server-ip>。这能剥离 DNS 因素，单独验证 Web 服务器的server_name与虚拟主机顺序是否匹配请求主机名。

第三个节点区分两类“旧内容”：代理或浏览器缓存（检查响应头中的缓存字段，只清理正确的缓存层）与部署目录本身停留在旧版本。部署目录与版本号的核对方式见 部署与连接章节——文件同步后应在服务器上核对目标路径下的实际文件清单与部署修订记录。

树 4：HTTPS 失败（HTTPS Fails）

Does HTTP reach the intended server? |-- No -> Fix DNS, routing, firewall, or web server first. `-- Yes | Is port 443 listening? |-- No -> Configure the HTTPS virtual host. `-- Yes | Does the certificate cover the requested hostname? |-- No -> Issue or select the correct certificate. `-- Yes | Is the certificate current and chain trusted? |-- No -> Repair renewal or chain configuration. `-- Yes -> Check redirect loops, application errors, and mixed content.

这棵树把 HTTPS 问题拆成“连通性 → 端口 → 证书名 → 证书有效期与链”四层，最后一层才轮到重定向循环、应用错误和混合内容这类应用层问题。仓库 启用并验证 HTTPS 章节 为每个节点提供了具体命令：

# 节点 2/4：证书是否覆盖请求的主机名、有效期与颁发者 openssl s_client -connect example.dpdns.org:443 -servername example.dpdns.org </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName # 节点 4（最后）：HTTP/HTTPS 状态与重定向 curl -I http://example.dpdns.org curl -I https://example.dpdns.org

两个与树配套的实战要点：

• 证书必须覆盖每个对外提供 HTTPS 的主机名。按 记录类型章节 与 HTTPS 章节的说明，根域名与www是两个独立名字，签发时都要包含（如sudo acme-client --nginx -d example.dpdns.org -d www.example.dpdns.org，acme-client为占位命令）；
• 自动续期不是“第一张证书成功”就能证明的，需要跑客户端文档中的 dry-run/测试续期命令，并监控续期任务、到期时间、续期日志，以及可能破坏验证路径的端口和 DNS 变更。

树 5：www可用但根域名失败（wwwWorks but Root Fails）

Does the root have the intended A or AAAA record in external DNS? |-- No -> Create the required external DNS record. `-- Yes | Does the web server accept the root hostname? |-- No -> Add it to the virtual host. `-- Yes | Does the certificate cover the root hostname? |-- No -> Include it in certificate issuance. `-- Yes -> Check canonical redirect configuration.

这棵树的第一个节点就是最常见的根因：www上的 CNAME 并不会自动为根域名配置解析。DNS 故障排查章节 对此有明确提醒——www能工作不代表根域名有记录，需要单独检查根域名的A或AAAA记录。验证命令：

dig A example.dpdns.org dig AAAA example.dpdns.org dig CNAME www.example.dpdns.org

后续两个节点分别对应：Web 服务器的虚拟主机是否接受根主机名（server_name中同时列出example.dpdns.org与www.example.dpdns.org），以及证书是否包含根主机名。全绿后，最后检查的是规范重定向（canonical redirect）配置——按 部署与连接章节 的做法，选定根域名或www之一作为主 URL，在 HTTPS 对两个名字都生效后，用 308 之类的重定向把另一个名字指回主 URL（参考 HTTPS 章节 中的 Nginx 重定向示例）。

树 6：只有部分用户失败（Only Some Users Fail）

Do failing users receive a different DNS answer? |-- Yes -> Compare TTL, resolver cache, IPv4, and IPv6. `-- No | Do they use a different protocol path or network? |-- Yes -> Test IPv6, proxy, firewall, and regional routing. `-- No | Do they receive different HTTP cache or application content? |-- Yes -> Inspect cache keys and headers. `-- No -> Collect exact client error and timestamp.

“部分用户异常”是最难排查的一类故障，因为每个用户看到的网络状态都不同。这棵树把差异来源收敛到三类：DNS 答案不同、协议/网络路径不同、HTTP 缓存或应用内容不同，最后才是收集精确客户端错误与时间戳。

第一类节点直接对应 TTL 与缓存章节 的核心内容：递归解析器按 TTL 缓存答案，更新权威记录不会清除已缓存的答案，负答案同样会被缓存。该章节给出的 TTL 选择表解释了为什么迁移期各用户看到的状态不一致：

场景	示例 TTL	权衡
稳定的生产记录	3600 到 86400	查询少，紧急变更慢
计划中的迁移	300 到 600	切换快，DNS 查询多
临时测试	60 到 300	迭代快，查询量大

并且提醒：迁移前应至少提前一个旧 TTL 时长降低 TTL，临时降低 TTL 对已经按旧 TTL 缓存的副本无效。定位时可用dig A example.dpdns.org +noall +answer查看答案中IN前的剩余 TTL（秒）——答案被缓存时它会在多次查询间递减。此外浏览器和操作系统可能保留连接或 DNS 状态，先用命令行 DNS 工具测试；重启浏览器并不能修复错误的权威记录。

第二类节点对应 IPv6 与 IPv4 指向不同服务器的经典陷阱：记录类型章节 明确说只在服务器可通过 IPv6 到达时才发布AAAA，一条失效的 IPv6 路径会让偏好 IPv6 的客户端看到站点“时好时坏”；部署与连接章节 则要求 IPv4 和 IPv6 分别验证。

树 7：邮件不到达（Email Does Not Arrive）

Does dig MX return the issued mail exchangers? |-- No -> Fix MX records in external DNS. `-- Yes | Do MX target hostnames resolve? |-- No -> Fix mail-host address records. `-- Yes | Does the mail system accept the recipient and domain? |-- No -> Fix mail-system configuration. `-- Yes -> Inspect delivery logs, rejection response, and spam handling.

这棵树先确认入站路由（MX），再确认目标可解析，最后才进入邮件系统本身，与 邮件 DNS 章节 的“接收和发送邮件是独立功能”这一区分一致。各节点对应的验证命令：

# 节点 1：MX 是否返回配置的邮件交换器 dig MX example.dpdns.org # 节点 2：MX 目标主机名是否可解析到地址记录 dig A mx1.mail-system.example

节点 1 的常见错误对应 记录类型章节 中的规则：MX 目标必须是带地址记录的主机名，不能是CNAME，也不能把 IP 直接写进 MX 值；数字小的优先。若 MX 层都正确但收不到信，进入节点 3 之后的日志排查——注意 邮件 DNS 章节 提醒，此时还应检查垃圾邮件处理（SPF/DKIM/DMARC 的认证结果与对齐情况），而不只是投递日志。分享证据前按该章节要求移除邮件正文、收件人等个人信息。

树 8：部署失败（Deployment Fails）

Did configuration validation pass? |-- No -> Do not reload; fix or restore configuration. `-- Yes | Does the local application or static directory work? |-- No -> Fix deployment files or application process. `-- Yes | Does the public virtual host work? |-- No -> Check proxy, permissions, firewall, and logs. `-- Yes -> Verify DNS, TLS, and external monitoring.

这棵树是“自内向外”验证：先验证配置合法性，再验证本机应用/静态目录，最后才验证公网虚拟主机。它与 部署与连接章节 的操作序列一一对应：

• 配置验证：在服务器重载前执行sudo nginx -t；验证失败时按树上的指示“不要重载；修复或恢复配置”——这与 HTTPS 章节 中“先sudo nginx -t再sudo systemctl reload nginx”的测试前置要求一致；
• 本地验证：文件同步后用find /var/www/example.dpdns.org -maxdepth 2 -type f -print核对部署文件是否落在目标路径，并确认本地应用或静态目录可工作；注意 部署与连接章节 对rsync --delete的警告：确认源与目标路径前不要使用--delete；
• 公网验证：通过curl -I检查公网虚拟主机，异常时按树上列举的顺序检查代理、权限、防火墙和日志；全通后再回到 DNS、TLS 和外部监控做收尾确认。

何时回滚（When to Roll Back）

原文档在八棵树之后给出了五条回滚优先准则，建议原样保留为操作规范：

• 用户影响显著时；
• 存在已知的可用旧状态时；
• 预计诊断时间将超过可接受的宕机时间时；
• 本次变更很可能是原因时；
• 回滚不会销毁必需的证据或数据时。

回滚的具体做法在 部署与连接章节 的 Rollback 小节有落地步骤：恢复先前的 DNS 值或服务器文件、在缓存的 DNS 答案过期前保持旧服务继续运行、重试前先记录故障证据。这与 TTL 与缓存章节 的迁移流程互为镜像——“迁移期间保持旧服务可用”既是上线策略，也是回滚策略。

为了让回滚决策有据可依，建议同时使用 检查清单与模板附录 中的三个模板：

• DNS Change模板：在任何 DNS 变更之前记录当前值、当前 TTL、预期值、回滚值和回滚决策时间，使“已知可用的旧状态”在变更那一刻就被写下来；
• Website Deployment清单：覆盖备份、配置测试、DNS 变更前健康检查、HTTP/HTTPS 状态验证，以及“回滚窗口被有意关闭”这一收尾项；
• Incident Timeline模板：按 UTC 时间轴记录检测、遏制、恢复、验证与根因，配合证据保留要求，避免事后丢失判断依据。

把决策树用成流程：一次完整的排障工作流

把八棵树合起来看，仓库附录给出的是一套可复用的故障处理流程，而不是八个孤立答案：

1. 识别症状，选定一棵树。域名不解析走树 1；解析正常但超时走树 2；内容不对走树 3；HTTPS 相关走树 4；www/根域名不对称走树 5；用户间不一致走树 6；邮件走树 7；变更引入的问题走树 8。
2. 逐节点取证。每个节点都有对应命令（dig NS、dig @ns SOA、dig @ns <type> <name>、curl -I、openssl s_client），按 DNS 故障排查章节 的“收集证据”清单保留：精确的主机名与记录类型、dig NS输出、权威直查结果、预期与实际值、变更时间与旧 TTL、相关的 HTTP 状态。
3. 区分权威状态与缓存状态再下结论。权威答案是旧的就改权威区；权威答案正确而递归答案旧的，等待 TTL 过期比反复编辑记录更安全（见 TTL 与缓存章节）。
4. 对照回滚准则做决策。满足第五条中的任何一条，优先回滚并记录证据，再重新诊断；不满足则沿树继续。
5. 用模板留痕。把变更、时间轴、恢复步骤写入 检查清单与模板附录 的对应模板，供下次故障和交接使用。

延伸阅读

• TTL、缓存与传播：理解“等待”何时是正确动作的底层依据；
• DNS 故障排查：五步法与NXDOMAIN/SERVFAIL等状态码的含义；
• 部署与连接域名、启用并验证 HTTPS：树 2、树 4、树 8 对应的操作章节；
• 邮件 DNS：MX、SPF、DKIM 与 DMARC：树 7 的完整背景；
• 检查清单与模板 与 工作簿：把决策树落到可重复执行的日常运维中，入口见 附录索引。

【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG