Workers 子域名能打开，自定义域名却返回错误。此时重新上传代码通常没有帮助，因为应用可用只证明一条入口成功，不能证明 DNS、域名绑定和证书都已经就绪。
本文以 Cloudflare 管理的域名绑定 Worker 为例。自定义域名与基于现有站点的 Worker Route 是不同产品路径，配置前先确认选择的是哪一种，不要同时添加互相竞争的规则。
将一次故障转换成可验证假设
假设默认入口显示新版本，根域名显示旧首页，www 无法建立 HTTPS 连接。这不是一个笼统的“部署失败”，而是三个入口具有不同状态。先分别保存状态码、正文版本标识、证书信息和查询结果，再提出假设：根域名可能仍由旧项目处理，www 可能尚未绑定或证书未就绪。每个假设有自己的验证动作，不需要先改应用代码。
默认入口正常可以排除部分构建和运行时故障，但不能证明自定义域名上的缓存已经更新。根域名返回旧正文时，比较响应头与控制面归属，确认究竟是旧应用还是新应用旧缓存。一个二百响应只说明有人回答请求，并不能说明回答者正确。可以在页面中加入非敏感部署版本，在诊断时比对实际版本，避免靠视觉记忆判断。
如果域名返回服务错误但 TLS 正常，继续查路由与应用；如果握手失败，暂时不分析页面 JavaScript。顺序排查减少了无关操作，也防止把两个问题一起改后无法知道哪个操作有效。每次修改记录目标、旧值、新值与时间，等待的是对应机制变化，不是固定等几分钟后盲目重试。
DNS 回答“名字指向哪里”
dig example.dev A
dig example.dev AAAA
dig www.example.dev CNAME查询结果需要与当前产品配置一起解释。代理模式下返回的地址不一定是传统源站 IP，不能把它直接当作 Worker 的独立服务器地址。还要查询权威 DNS 与多个递归解析器，区分配置未生效与本地缓存仍旧。
变更前记录现有记录的类型、名称、值、代理状态与 TTL。域名还可能承载邮件验证、MX 或其他子域名，不应为了修复网站删除整个区域。只修改已经明确冲突的精确记录，并保留可回滚信息。
本地解析器可能保留旧答案，另一个公共解析器已经看到新记录。查询权威服务器可以确认配置层的当前答案，递归查询可以观察用户路径的传播。不能仅因两者不同就删除并重建记录，重建可能再次延长缓存不一致。负缓存也存在，之前不存在的名称可能仍被缓存为不存在，因此记录创建时间和失败类型很重要。
域名使用哪些权威服务器也要确认。控制台中添加记录，但注册商委派仍指向其他提供商时，修改不会影响真实查询。DNSSEC 若在注册商与区域配置之间不一致，验证解析器可能拒绝答案，而未验证解析器看起来正常。要验证委派和签名链，不以单个客户端成功作为全部用户可达证据。
诊断命令输出可以包含地址、TTL 与状态，但不需要公开整份区域记录。域名区域可能包含内部服务名称和邮件验证信息，报告应只保留与目标有关的记录。读权限与写权限也应分开，普通排障不需要拥有删除整个区域的凭据。基础设施操作范围越窄，误删后的恢复成本越低。
域名绑定回答“由哪个应用响应”
部署配置中的自定义域名需要与 Cloudflare 控制面状态一致。如果存在其他 Worker、Pages 项目或旧站点配置使用同一名称，应先确认归属。错误信息中的“记录冲突”不是让你删除所有记录的指令，而是在提示同一个名字有多项责任。
绑定根域名与 www 是两个精确目标。成功绑定根域名不自动保证 www 可访问，反过来也一样。若两个入口都可用，应明确主域名与跳转策略，避免 canonical 和链接生成各自使用不同地址。
自定义域名把某个名称直接交给 Worker 处理，基于已有源站的 Route 则根据匹配规则让 Worker 参与请求路径。两者是否适合当前网站，应从请求流向与源站存在性判断。静态资产由 Worker 提供的个人站点可能采用前者；已有站点只需要部分请求增强时可能采用后者。不要把控制台中所有能输入域名的选项都当成同一种绑定。
路由通配规则还可能覆盖超出预期的路径。为整个域名添加规则时，邮件服务不会通过 HTTP 路由运行，但同域名的 API、验证路径和旧应用可能受影响。先列出该名称现有用途，再决定覆盖范围。绑定根域名和 www 时检查精确冲突对象，不迁移与此次网站无关的其他子域名。
版本化配置能够表达期望状态，控制面表示实际状态，二者需要定期核对。若手工操作后配置没有同步，下一次部署可能恢复旧状态；若配置包含已失效域名，部署又可能失败。写入配置前确认目标账户与区域，域名字符串正确不代表资源归属正确。将 Worker 名称、账户和公开入口同时记录，减少相同项目名导致的误操作。
TLS 回答“连接是否可信”
DNS 正确后，证书仍可能处于签发或验证阶段。检查证书域名、有效期与链，不要把应用返回状态码和 TLS 握手问题混为一谈。浏览器缓存的错误与终端工具结果可能不同，应记录具体时间与客户端。
CAA 记录会影响允许的证书签发机构，但不应看到证书问题就随意移除它。先根据平台提示和当前证书策略验证。DNSSEC 配置错误也可能导致某些解析器失败，需要看验证链，而不是只测试一台机器。
证书覆盖的名称、有效期和链应与访问入口匹配。根域名成功不说明 www 证书已覆盖；一个通配证书也不应被理解为覆盖所有任意层级名称。浏览器显示证书错误时，记录具体错误分类，而不是只截图“无法访问”。应用响应头在 TLS 完成之前不存在，不能靠修改 HTML 修复握手。
平台签发证书可能依赖域名验证和 DNS 状态，CAA 会限制允许签发的机构。先根据当前平台要求检查限制是否兼容，不直接删掉所有 CAA。修改安全约束应有原因和恢复计划。若证书仍在等待签发，观察控制面状态变化；若明确失败，读取失败原因再调整相应层。等待不能替代配置验证，配置修改也不能强迫签发立刻完成。
同时测试不同网络和客户端有助于识别本地缓存或网络过滤，但样本数量有限。公司网络失败而手机网络成功，可能是代理、解析器或安全设备行为，不能直接认定域名全局异常。记录共同点与差异，让诊断沿证据收敛，不不断重复部署同一版本。
把验收时刻与传播过程分开记录
DNS 修改完成、证书就绪、域名返回新应用和所有测试通过，可能发生在不同时间。记录每个阶段的证据，能区分操作成功与外部传播。部署工具报告上传成功仅证明代码进入平台，不证明公开域名已经可用；控制面显示绑定也不等于每个客户端已经清除旧解析。用户关心的是最终入口，报告应该明确当前完成到哪一步。
等待时只重复与假设有关的只读检查。例如绑定已正确、证书仍在签发，就查看签发状态与 HTTPS 握手；不要持续重新部署代码或删改 DNS。外部状态可能正常需要时间，重复写操作反而让诊断失去稳定条件。若状态明确报错，读取报错并调整精确目标，而不是把等待当成万能解法。
一次迁移还需要考虑原站流量。提前降低记录 TTL 只有在旧缓存到期后才影响新的缓存期限，不能在切换后立刻保证所有解析更新。平台代理和自定义域名的行为也可能与传统源站切换不同，必须按实际产品解释。不要把某篇 DNS 通用教程中的传播时间当成账户当前配置的服务承诺。
为异常设定升级路径：应用版本错误查部署归属，解析验证失败查委派与签名，握手失败查证书，正确版本的业务错误查应用日志。可以把证据汇总成一份简短事件记录，包含开始时间、精确目标、影响范围、验证结果和恢复动作。它不是为了给一次小改动增加流程，而是避免下一次维护者重做所有猜测。
最后验证邮件等无关服务保持不变。网站绑定不应修改 MX、TXT 验证或其他子域名，修改前后的相关记录快照可以证明操作范围。越是拥有整个区域管理权限，越要使用精确目标。成功打开网站而同时破坏邮件，不应被称为域名配置完成。
用一份证据表分离三种失败
假设权威服务器回答正确，公共递归解析器甲返回新结果，解析器乙仍然不存在，浏览器提示证书错误。不要把它们归成一个 DNS 问题。证据表逐行记录客户端、查询目标、失败阶段、时间和直接观察值：解析器乙尚未看到名称，是解析路径问题；已经到达边缘但证书名称不匹配，是 TLS 问题；握手完成后错误正文，是路由或应用问题。每一行对应的后续动作不同。
查询工具还需要说明从哪里得到答案。查询权威服务器验证当前配置，查询递归解析器观察缓存路径，系统解析观察这台机器实际使用的配置。企业代理或浏览器安全 DNS 可能与系统解析不一致。遇到终端正常、浏览器失败时，记录浏览器是否经过代理和独立解析器，而不是继续修改已经正确的区域记录。工具成功是一个样本，不能代替真实用户入口验证。
对于 SERVFAIL，先区分验证解析器与非验证路径。DNSSEC 链问题可能让某些解析器拒绝，而直接查询权威仍然有答案。需要核对注册商委派、DS 与区域签名状态，不在没有证据时禁用安全机制。域名管理面往往跨两个平台，一处显示启用不代表另一处与它一致。变更记录应包含相关链路，而非只保存某个控制台截图。
对 NXDOMAIN，核对精确名称及区域委派，再判断负缓存。根域名与 www 的创建时间不同，不能从根域存在推导 www 存在。对 timeout，考虑网络可达与解析服务器本身，不把超时等同于名称不存在。准确分类让等待与修改都有理由：缓存传播可以等待，委派错误需要精确调整，网络阻断需要换路径验证。
迁移入口前先确认域名承担的 HTTP 任务
一个根域名可能同时提供文章、API、身份回调和证书验证路径。迁移到新 Worker 时，应该列出这些路径当前由谁处理以及新架构是否继续支持。只验收首页，可能让文章正常而 OAuth 回调失效，或者让 webhook 返回静态缺失页。域名归属是名称级决策，请求功能却是路径级责任，两层都要列清楚。
Route 与自定义域名的选择可以据此推导。如果需要保留既有源站，只增强一部分路径，路由匹配更可能符合任务；若整个名称由 Worker 提供，直接绑定可能更明确。实际优先级与互相作用必须查看当前平台文档及控制面状态，不能用记忆中的规则判断所有账户。迁移计划应记录被移除的旧对象与保留的旧服务，不自动清空全部配置。
先在临时入口验证新应用的必要路径，再切换精确目标。临时入口不证明正式证书与路由就绪，但能缩小应用层不确定性。切换后按原清单请求每条任务，尤其使用合成认证与 webhook 负载，不拿生产写入接口做盲目测试。对于无法安全执行的任务，验证路由与部署配置并明确留出业务验收，而不是假装已经测试。
证书诊断要说明实际握手的名字
客户端连接的网络地址与 TLS 中验证的名称不是同一概念。通过代理地址访问时，证书验证仍然围绕请求域名；直接改成边缘 IP 浏览，往往不能模拟正常入口。使用支持明确服务器名称的诊断工具，检查名称覆盖和证书链。不要用关闭证书校验的成功请求证明 HTTPS 已经安全可用，它只能帮助区分某些网络与证书问题。
机器时钟错误也可能影响有效期判断。单一客户端认为证书尚未生效或已过期时，先核对本地时间与其他受控客户端。证书链在不同客户端信任库中的表现也可能不同，报告支持范围而不是用一台新浏览器代表全部设备。若目标用户使用特殊企业代理，还需要考虑代理证书，不将其问题直接归到平台签发失败。
为证书状态记录当前名称、签发状态、到期时间与管理责任。平台自动续期降低日常操作成本，不意味着无需关注失败。到期告警应对应实际公开入口，旧域重定向同样需要有效 HTTPS，浏览器在看到重定向前必须先完成握手。保留旧域的续费和证书责任，是链接迁移长期可达的一部分。
把控制面修改和可达验收分成两项结果
API 已接受绑定操作，可以记录“配置写入成功”，但尚未得到正确 HTTPS 正文时不要报告“网站已上线”。分阶段报告不会降低效率，反而让下一位维护者知道剩余问题在传播、签发还是应用。查询状态时采用有界间隔，避免高频重新执行写操作。外部系统状态不变并不是修改更多配置的理由。
若操作失败，保存精确错误类别与目标对象，不记录管理令牌。回滚需要能够恢复旧绑定，并验证旧应用版本重新可读；撤销新配置不能自动恢复所有旧关系。最终证据表同时包含根域、www、默认入口及关键路径，让上线结论对应明确范围。再检查未触及的邮件记录，证明操作没有扩大到用户未要求的基础设施。
按层验证，每步只改变一个因素
先请求 Worker 默认入口，确认应用版本；再查询目标名称，确认解析；然后检查控制面绑定；最后请求 HTTPS 并记录状态码、响应头和正文特征。若响应来自旧应用，即使是 200，也不算部署成功。
curl -I https://example.dev/
curl -I https://www.example.dev/writing/curl -I 只测试 HEAD，部分应用对 HEAD 与 GET 行为不同，因此验收还要获取真实页面。检查关键路径与 RSS，不要只看首页。对于跳转，核对 Location 是否保留路径，避免 www 深链接全部丢到根页面。
上线后把域名绑定写入版本化配置或明确操作记录，并与控制面状态核对。这样下次部署不会因为本地配置缺少域名而重新制造冲突。修改 DNS 是基础设施变更，应该有目标、证据和回滚，不是反复点击直到页面碰巧打开。
还可以构造一个双栈反例：IPv4 请求正确，IPv6 请求失败。先分别保存 A、AAAA 查询与两条连接的阶段结果，确认失败发生在解析、握手还是正文。传统源站迁移若遗漏旧 AAAA，可能让部分客户端继续到旧入口；平台代理产品又可能有不同的地址管理方式。不能看到这个现象就删除 AAAA，必须先核对当前记录由谁管理及产品要求。
浏览器可能自动尝试不同连接路径，最终成功掩盖了一条路径持续失败。受控工具可以分别选择地址族并记录连接目标，同时保持正确的 TLS 名称与 HTTP 主机。不要以直接浏览 IP 替代这个样本，它改变了证书和路由输入。比较两条路径时也固定时间与目标文章，避免新旧发布交错被误解为网络差异。
修复只针对已证实错误的对象，随后重复两条路径，并从先前失败的网络复测。若其中一种网络在测试环境不可用，报告“未覆盖”，不把另一条成功扩大为双栈完成。这个样本让可达性结论具有连接路径的范围；根域、www 和默认入口的归属验证仍然各自保留。