先别急着重装

遇到“DNS 源站故障”时，最容易做错的是同时重装、换账号、清缓存和换网络。先保留现场，再从成本最低、最容易恢复的一层开始。

简短结论：无法解析、TLS 失败和源站 5xx 是三类问题；先保存浏览器原始错误再选择工具。

编辑部为什么这样建议

服务打不开时，先留住错误和时间线。删配置、重装、换账号一起做，恢复往往会更慢。

今天就要处理，可以这样排

先用十分钟完成“查询域名解析”，随后只做“记录响应 IP”。如果现象已经改变，先复测，不要为了把清单做完又引入新的变量。

仍未解决时再进入“测试 HTTPS 状态”，最后用“对照权威状态页与另一解析器”验证能否恢复。整个过程中要守住这条边界：不要因一个公共 DNS 的结果就修改全网设置。

从最容易排除的地方开始

  1. 查询域名解析先保留原始提示和发生时间，这会决定后面查平台、账号还是网络。
  2. 记录响应 IP这一轮只动一个条件；同时清缓存、换账号和换网络，结果就失去解释力。
  3. 测试 HTTPS 状态把成功与失败都记下来，稳定复现比偶尔恢复更有价值。
  4. 对照权威状态页与另一解析器如果这一步没有改变现象，恢复原设置再进入下一层。

结果落在哪一层

现象已经改变回到上一步复测，确认变化确实跟随刚才修改的条件。
现象完全没变解析失败只处理 DNS，已有 IP 的 5xx 转向源站。

什么时候才该换方向

解析失败只处理 DNS，已有 IP 的 5xx 转向源站。

有一个坑需要提前说

不要因一个公共 DNS 的结果就修改全网设置。

价格、地区、版本和平台政策会变化；涉及这些信息时，请在操作当天重新核对官方页面。本文没有覆盖的地区或环境，不自动沿用同一结论。

读完通常还会问

DNS 源站故障第一步应该做什么？

查询域名解析

什么时候值得改用另一种方案？

解析失败只处理 DNS，已有 IP 的 5xx 转向源站。

这篇文章依据什么

本文用《Cloudflare 1.1.1.1 设置》核对公共 DNS 配置与设备入口，再用《Cloudflare Status》确认Cloudflare 网络与产品事件。两份资料解决的是不同事实边界；如果其中一份更新，应先重查对应段落，而不是只改页面日期。

Cloudflare 1.1.1.1 设置
公共 DNS 配置与设备入口；核验日期 2026-09-07。
Cloudflare Status
Cloudflare 网络与产品事件；核验日期 2026-09-07。