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 失败、只有部分用户异常”等典型故障时按确定的顺序逐层定位问题并判断何时该回滚而不是继续诊断。使用方法一次一棵树先取证后改配置原文档给出的使用原则只有两句话但决定了整套流程的可靠性Use one tree at a time一次只走一棵树——避免同时排查多个层级时把故障现象搅乱Record observations before changing configuration修改配置前先记录观察——每一步的查询结果都是后续判断和回滚的证据。这与仓库 DNS 故障排查章节 开头的原则一致“从委派delegation向最终服务逐层排查不要一次改动多个层级”。配合 检查清单与模板附录 中的DNS Change模板记录当前值、TTL、预期值、回滚值、回滚决策时间使用可以让每棵树的排查过程都有书面留痕。下面的每个小节对应原文档的一棵树。决策树原样保留随后补充该树上每个判定节点在本仓库中对应的验证命令和背景知识。树 1域名不解析Domain Does Not ResolveDoes 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。树 2DNS 已解析但网站超时DNS Resolves but Website Times OutDoes 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 超时”通常指向服务器进程、防火墙或路由问题。排查顺序建议用curl -I确认 80/443 是否有响应超时而非报错一般对应网络路径或防火墙问题在服务器本机确认 Web 服务进程在运行且端口在监听检查网络层防火墙云安全组/边界与主机防火墙两层——两者独立生效规则需要分别放行两层防火墙都放行后才去看虚拟主机配置、TLS 和应用日志。树 3出现了错误的网站Wrong Website AppearsDoes 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与虚拟主机顺序是否匹配请求主机名。第三个节点区分两类“旧内容”代理或浏览器缓存检查响应头中的缓存字段只清理正确的缓存层与部署目录本身停留在旧版本。部署目录与版本号的核对方式见 部署与连接章节——文件同步后应在服务器上核对目标路径下的实际文件清单与部署修订记录。树 4HTTPS 失败HTTPS FailsDoes 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.orgacme-client为占位命令自动续期不是“第一张证书成功”就能证明的需要跑客户端文档中的 dry-run/测试续期命令并监控续期任务、到期时间、续期日志以及可能破坏验证路径的端口和 DNS 变更。树 5www可用但根域名失败wwwWorks but Root FailsDoes 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 FailDo 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 ArriveDoes 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 章节 的“接收和发送邮件是独立功能”这一区分一致。各节点对应的验证命令# 节点 1MX 是否返回配置的邮件交换器 dig MX example.dpdns.org # 节点 2MX 目标主机名是否可解析到地址记录 dig A mx1.mail-system.example节点 1 的常见错误对应 记录类型章节 中的规则MX 目标必须是带地址记录的主机名不能是CNAME也不能把 IP 直接写进 MX 值数字小的优先。若 MX 层都正确但收不到信进入节点 3 之后的日志排查——注意 邮件 DNS 章节 提醒此时还应检查垃圾邮件处理SPF/DKIM/DMARC 的认证结果与对齐情况而不只是投递日志。分享证据前按该章节要求移除邮件正文、收件人等个人信息。树 8部署失败Deployment FailsDid 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解析正常但超时走树 2内容不对走树 3HTTPS 相关走树 4www/根域名不对称走树 5用户间不一致走树 6邮件走树 7变更引入的问题走树 8。逐节点取证。每个节点都有对应命令dig NS、dig ns SOA、dig ns type name、curl -I、openssl s_client按 DNS 故障排查章节 的“收集证据”清单保留精确的主机名与记录类型、dig NS输出、权威直查结果、预期与实际值、变更时间与旧 TTL、相关的 HTTP 状态。区分权威状态与缓存状态再下结论。权威答案是旧的就改权威区权威答案正确而递归答案旧的等待 TTL 过期比反复编辑记录更安全见 TTL 与缓存章节。对照回滚准则做决策。满足第五条中的任何一条优先回滚并记录证据再重新诊断不满足则沿树继续。用模板留痕。把变更、时间轴、恢复步骤写入 检查清单与模板附录 的对应模板供下次故障和交接使用。延伸阅读TTL、缓存与传播理解“等待”何时是正确动作的底层依据DNS 故障排查五步法与NXDOMAIN/SERVFAIL等状态码的含义部署与连接域名、启用并验证 HTTPS树 2、树 4、树 8 对应的操作章节邮件 DNSMX、SPF、DKIM 与 DMARC树 7 的完整背景检查清单与模板 与 工作簿把决策树落到可重复执行的日常运维中入口见 附录索引。【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考