ZuCDN 网站配置显示已发布，不等于访问链路已经全部正常。发布状态只能说明配置流程到达了某个阶段，真实请求还要经过 DNS、网络连接、TLS、HTTP 处理和源站应用。任意一层出现偏差，用户看到的都可能是打不开、证书警告、错误页面或内容异常。
发布后的检查应像排查一条链路，从外向内逐层确认，而不是遇到问题就反复修改配置。每改一次，变量都会增加，原本清晰的故障现场反而更难判断。下面采用六层检查法，适合新配置上线、源站调整或规则修改后的验收。控制台名称和可用字段可能随版本变化，操作时以实际界面为准。
第一层，配置是否处于可验证状态
进入 ZuCDN 控制台对应网站页面，确认加速域名、源站地址、回源协议、端口和回源 Host 与变更单一致。如果界面提供发布状态、更新时间或错误信息，应记录下来。不要因为页面上出现成功字样就跳过其他检查，也不要在状态仍显示处理中时连续重复发布。
需要重点核对的是配置对象。团队可能存在测试域名、正式域名和历史站点，名称相近时很容易把修改发布到错误对象。可以将完整域名、源站末段、发布时间与工单逐项比对。如果涉及 HTTPS，再确认关联证书覆盖当前域名并处于有效期内。
发布后暂缓连续编辑
有些问题只是配置传播尚未完成，有些则是明确错误。判断依据应来自控制台状态、实际请求和时间记录。没有确认前连续改协议、端口、Host 和 DNS，会让日志中混入多批不同请求。更好的做法是记录发布时刻，按既定等待时间观察，再决定是否进入下一轮修改。
第二层，域名是否指向预期目标
如果公共 DNS 尚未切换，可以根据 ZuCDN 实际提供的预览或测试方式进行验证；如果已经切换，应查询 CNAME 链和最终地址。不要只查看本机浏览器，因为浏览器、操作系统和本地网络都可能保留缓存。
以下命令适用于安装了 dig 的 Linux 或 macOS 环境，作用是只读查看 CNAME 链、地址和 DNS 跟踪信息。+trace 会直接查询多级 DNS 服务器，输出较多，也可能被网络策略限制。命令不修改 DNS，风险较低；在受限网络中应遵守安全策略。验证后无需回滚。
dig www.example.com CNAME +short
dig www.example.com A +short
dig www.example.com AAAA +short
dig www.example.com +trace检查时要回答三个问题。权威 DNS 返回的记录是否正确，递归 DNS 是否已经更新，IPv4 与 IPv6 是否走向一致。若旧 AAAA 仍存在，部分用户可能通过 IPv6 绕过新链路，表现为同一网站在不同网络下结果不同。
第三层，连接和证书是否正常
DNS 正确后，检查 80 和 443 端口能否建立连接，HTTPS 是否返回匹配域名的证书。证书问题常见表现包括名称不匹配、证书过期、链不完整或 SNI 下返回了其他站点证书。
下面命令适用于带 OpenSSL 的 Linux 或 macOS，作用是查看服务器在指定 SNI 下返回的证书信息。它不会修改远端配置。风险是输出包含证书和域名元数据，日志外发前应脱敏；无需回滚。
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null输出较长时，应关注连接是否建立、证书链、验证结果、有效期以及域名覆盖范围。若只在不带 SNI 的测试中失败，而浏览器正常，可能是测试方式不完整；因此命令中必须保留 -servername。不要用关闭证书校验作为上线通过标准。
第四层，HTTP 行为是否符合设计
连接成功后，再检查 HTTP。一个站点返回 200 也可能是错误的默认页面，因此状态码、响应头和内容要一起判断。建议选择一组固定探针，覆盖首页、文章、静态资源、后台入口、接口和不存在的路径。
以下 curl 命令适用于 Linux、macOS 或 Windows。它们分别检查响应头、自动跟随跳转并输出最终地址，以及保存一次只读页面响应。风险在于请求会进入真实网站，测试 URL 必须无写入副作用；保存的文件可能含页面数据，应存放在受控目录并按规范删除。命令不修改服务端，服务端无需回滚；本地文件可在验证后删除。
curl -I https://www.example.com/
curl -L -sS -o /dev/null -w '%{http_code} %{url_effective}n' https://www.example.com/
curl -sS -D headers.txt -o page.html https://www.example.com/example-post/验证成功的标准应由网站自身定义。首页通常希望返回正常页面，但不存在路径应保持合理的 404，而不是一律返回 200。静态资源的 Content-Type 要正确，跳转次数不应异常增长，最终域名和协议应符合站点规范。检查完本地文件时，可执行 rm -- headers.txt page.html。该删除命令适用于当前目录且仅删除明确列出的测试文件；执行前用 pwd 和 ls -l -- headers.txt page.html 确认路径，风险是同名文件可能被误删。若需要可恢复操作，应改为移动到受控临时目录，而不是直接删除。
第五层，回源是否命中正确站点
外部请求返回 502、503、504、403 或错误的站点内容时，需要把注意力转到回源链路。检查源站地址是否可达、端口是否监听、回源协议是否匹配、Host 是否让源站命中正确虚拟主机，以及防火墙或 WAF 是否拒绝请求。
可以在具备授权的管理终端上直接测试源站，但不要修改公共 DNS 或系统 hosts。下面的 curl 命令使用 --resolve 仅覆盖单次请求的解析，适用于安装了 curl 的环境。作用是比较源站直连结果与公开域名结果。风险是会绕过公共访问链路直达源站，必须确保测试者获得授权，并选择只读路径；命令不持久化配置，无需回滚。
curl -I --resolve www.example.com:443:192.0.2.10 https://www.example.com/
curl -I https://www.example.com/两次响应都要记录时间、状态码、Location 和内容类型。直连源站正常而公开访问失败，问题更可能位于 ZuCDN 配置、链路或相关访问控制；两边都失败，应优先检查源站应用。直连返回其他站点时，通常要核对 Host、SNI 和源站虚拟主机，而不是盲目更换 IP。
源站日志能够进一步缩小范围。公开请求没有到达日志，可能是连接、地址或访问控制问题；请求到达但返回 403，应检查应用权限、WAF 或鉴权；返回 404 时要核对 Host、路径重写和站点根目录；出现超时则要检查应用依赖、数据库和上游服务。日志中可能含 IP、Cookie、查询参数和令牌，复制或分享前必须脱敏。
第六层，WordPress 业务是否完整
技术状态正常之后，还要从 WordPress 的真实使用路径验收。不要只看首页。登录状态、后台、文章预览、REST API、静态资源和定时任务对请求处理方式的要求不同，任何缓存或规则调整都应依据实际业务验证，不能假定所有 WordPress 站点配置相同。
- 使用测试账户登录和退出，确认会话没有异常串用或反复失效。
- 打开一篇已发布文章，检查图片、样式、脚本、字体和分页。
- 在授权条件下创建测试草稿并预览，不要直接修改正式文章。
- 检查后台常用页面，确认没有持续 403、重定向循环或空白响应。
- 访问站点实际使用的 REST API 只读端点，核对状态码和响应类型。
- 提交评论、表单、支付或其他写操作时，只能使用隔离测试数据并获得业务授权。
- 检查站点规范化跳转，避免 http、https、www 和非 www 之间循环。
用症状反推故障层
完全无法解析域名，应从 DNS 记录、权威服务器和域名状态查起。能够解析但连接超时，应检查目标地址、网络路径、端口和访问控制。浏览器出现证书警告，应检查 SNI、证书覆盖和证书链。统一出现 502 或 504，应关注回源连通、协议和源站响应时间。
只有后台或登录异常，更可能涉及 Cookie、会话、鉴权或针对路径的处理规则。页面正常但图片和脚本失败，应查看资源 URL、状态码、跨域、混合内容和 Content-Type。部分地区或部分网络异常，应同时比较 DNS 递归结果、IPv4、IPv6 和网络路径，不要立即认定为源站故障。
常见误判会拖慢排查
- 看到 200 就判定成功，却没有确认返回的是目标页面还是默认页。
- 用浏览器无痕模式代替 DNS 验证，无痕模式并不会清除所有系统和网络缓存。
- 源站直连正常就认定发布配置正常，实际上回源 Host 或访问控制仍可能不同。
- 为了快速通过 HTTPS 测试长期忽略证书错误，留下真实安全风险。
- 一次修改多项配置，故障恢复后也不知道是哪项起作用。
- 把缓存中的旧页面当成 DNS 未生效，或者把 DNS 缓存误当成页面缓存。
配置发布后的回滚策略
如果新配置导致关键业务异常，应恢复最近一份已验证的配置，而不是继续叠加临时规则。若故障发生在公共 DNS 切换之后，可以按预案把 DNS 恢复为原记录；若 DNS 未变，只需撤销本次 ZuCDN 配置变更或恢复旧版本。控制台是否支持版本回退以及具体入口，应以实际界面为准。
回滚前保存故障时间、请求样本、状态码、DNS 答案和必要日志。回滚后重复六层检查，确认恢复的不只是首页。DNS 回滚存在缓存传播期，因此旧链路和新链路可能短时间并存，不应立即删除仍可能被访问的配置，也不应马上收紧源站到无法服务残余请求。
把一次检查变成长期基线
验收结束后，保留测试 URL、预期状态码、证书到期时间、DNS 记录、源站信息和正常响应特征。下一次发布可以直接与基线比较，而不是重新凭感觉判断。监控至少应覆盖域名解析、HTTPS 可用性、关键页面状态和源站健康，具体指标与告警阈值由业务重要程度决定。
ZuCDN 网站配置发布后的检查，不是寻找一个成功标志，而是建立完整证据链。配置对象正确、DNS 指向正确、TLS 身份正确、HTTP 行为正确、回源路径正确、WordPress 业务正确，这六层都得到验证，发布才算真正完成。
延伸阅读