准备接入 ZuCDN 时，最容易被低估的工作不是填写控制台，而是确认手里的域名和源站信息是否真实、完整、可以验证。域名写错一个字符、源站只允许旧节点访问、HTTPS 证书没有覆盖回源主机名，都可能让一份看起来正确的配置在发布后无法工作。
因此，不要等到切换 CNAME 时才临时查资料。更稳妥的方式是先建立一张接入信息表，把域名侧、源站侧和变更侧的信息分别确认，再进入 ZuCDN 控制台创建网站配置。不同版本控制台的字段名称可能有所差异，具体选项应以实际界面和官方说明为准。
先确定真正需要加速的域名
网站名称、注册域名和加速域名不是同一个概念。假设用户访问的是 www.example.com，那么通常需要配置和切换的是 www.example.com，而不是笼统地填写 example.com。静态资源使用 static.example.com、接口使用 api.example.com 时，也要分别判断它们是否需要接入。
建议为每个候选域名记录当前用途、现有解析记录、访问协议、业务负责人和计划切换时间。不要把暂时无法确认用途的子域名一起改动。根域名是否能够使用 CNAME，还取决于 DNS 服务商对根域名记录的支持方式，不能直接套用子域名的操作步骤。
- 确认域名已经注册并处于正常状态，没有过期、锁定或解析暂停。
- 确认自己拥有 DNS 修改权限，并知道解析由哪一家 DNS 服务商托管。
- 查询当前记录类型、记录值和 TTL，保存切换前快照。
- 确认域名是否同时存在 A、AAAA、CNAME 或其他可能冲突的记录。
- 确认 HTTPS 证书覆盖的是准确主机名，通配符证书的覆盖边界也要核对。
用公共查询确认当前解析
以下命令适用于安装了 dig 的 Linux 或 macOS 终端，作用是只读查询域名当前的 CNAME、A、AAAA 和权威 DNS 信息，不会修改解析。风险很低，但本地递归 DNS 可能返回缓存结果，因此验证时还应查询权威服务器或多个公共 DNS。命令不产生配置变更，无需回滚。
dig www.example.com CNAME +short
dig www.example.com A +short
dig www.example.com AAAA +short
dig example.com NS +short验证结果时，要把输出和 DNS 控制台中的记录逐项比较。若查询结果为空，不代表域名一定故障，也可能是对应类型没有记录。可以去掉 +short 查看状态码、应答区和 TTL。如果系统没有 dig，可在 Windows 终端使用 nslookup -type=CNAME www.example.com 做只读查询，同样无需回滚。
源站信息不能只写一个 IP
源站是 ZuCDN 回源请求最终到达的位置。一个可用的源站条目至少要说明地址类型、端口、协议和主机名要求。如果源站由云负载均衡、反向代理或其他 CDN 提供，还要确认它是否允许被新的回源请求访问，以及是否会形成 CDN 之间的循环回源。
源站地址可以是 IP，也可能是可解析的域名。若使用域名作为源站，应确认它不会再解析回当前加速域名，否则请求可能在代理链路中循环。还应记录源站 IPv4、IPv6 的实际支持情况，不能因为业务域名有 AAAA 记录就默认源站也具备可用的 IPv6 服务。
- 源站地址是固定 IP、负载均衡地址还是源站域名。
- HTTP 与 HTTPS 分别监听哪个端口，非标准端口是否允许外部访问。
- 回源时需要携带哪个 Host，源站虚拟主机是否依赖该值匹配站点。
- HTTPS 回源时，源站证书是否有效，证书名称是否与校验使用的主机名匹配。
- 源站防火墙、安全组、WAF 或访问控制是否限制来源地址。
- 源站是否存在强制跳转、路径重写、鉴权、限速或基于请求头的规则。
- 健康检查使用哪个路径，该路径是否不依赖登录状态并能稳定返回。
绕过公共解析直接测试源站
下面的 curl 示例适用于安装了 curl 的 Linux、macOS 或 Windows 终端。它通过 --resolve 临时把指定主机名连接到源站 IP，只影响这一次命令，不修改系统 hosts 和公共 DNS。它的作用是验证源站能否按目标域名正确提供 HTTPS 内容。风险在于命令会真实访问源站，若测试路径会触发写操作、发送通知或产生大计算量，不应使用；建议选择只读健康检查路径。
curl -I --resolve www.example.com:443:192.0.2.10 https://www.example.com/health执行后应检查连接是否成功、HTTP 状态码是否符合预期、是否发生异常重定向，以及响应头中的服务是否来自目标源站。因为该命令不持久化任何修改，停止执行即可，不需要回滚。如果测试失败，可增加 -v 查看 TLS 和连接过程，但输出可能包含内部地址、证书信息或请求头，分享日志前需要脱敏。
不要为了让测试通过而直接使用 -k 忽略证书校验。这个参数只能帮助区分网络连通问题和证书问题，不能证明 HTTPS 回源配置安全。若临时用于诊断，应在诊断结束后移除，并以不带 -k 的命令重新验证。
把回源行为写成明确规则
很多接入故障来自一句含糊的描述，例如按原协议回源。真正实施时，需要明确访客使用 HTTP 和 HTTPS 时分别怎样回源，是否允许源站 HTTP，是否由源站负责跳转，以及源站证书由谁维护。缓存策略、查询参数、Cookie 和鉴权头也会影响动态页面，但在不了解 ZuCDN 当前控制台能力时，不应预设具体功能名称。需要调整时，应以实际界面提供的配置项为准。
对 WordPress 网站，还要特别标记登录、后台、预览、定时任务和接口路径。这里不是要求默认设置某种缓存规则，而是提醒维护者识别哪些请求包含用户状态或管理操作，再结合实际业务和产品文档决定处理方式。未经验证就把所有页面按同一方式处理，可能造成登录状态、草稿预览或内容更新表现异常。
操作前还要确认变更条件
- 降低 DNS TTL 前先保存原值，并预留至少一个旧 TTL 周期让缓存自然过期。
- 记录当前 A、AAAA 或 CNAME 值，准备可以直接恢复的回滚记录。
- 确认源站监控、错误日志和访问日志可用，切换期间有人能够查看。
- 选择业务低峰窗口，暂停与域名解析、证书或源站网络相关的并行变更。
- 准备测试 URL，至少覆盖首页、静态文件、一个正常内容页和一个不存在的路径。
- 明确判断失败的阈值，例如持续出现回源超时、证书错误或关键页面不可用时立即回滚。
信息提交后的交叉验证
在 ZuCDN 中保存或发布配置后，先不要立即修改公共 DNS。应根据控制台实际提供的目标地址或验证方式进行预检查。检查加速域名拼写、源站协议、端口、回源 Host 和证书关联是否与信息表一致。如果平台提供配置状态或错误提示，应等待状态明确，再进入 CNAME 切换阶段。
源站日志也是重要证据。预检查请求到达源站时，确认 Host、路径和状态码正确；请求完全没有出现时，应排查网络访问控制、端口和地址；请求到达但返回 403、404 或跳转异常时，应重点检查虚拟主机、WAF、鉴权与重写规则。
常见准备错误及处理方式
- 把控制台中的网站备注名当成加速域名，处理方式是回到 DNS 和浏览器地址栏核对完整主机名。
- 只记录源站 IP，没有记录回源 Host，导致共享 IP 上命中错误站点。
- 源站域名与加速域名互相解析，形成潜在回源环路。
- 只测试首页，忽略静态资源、接口、重定向和错误页。
- 防火墙仅允许旧服务访问，却在发布后才发现新链路无法回源。
- 源站 HTTPS 可以在浏览器打开，但证书名称、证书链或有效期不满足回源校验要求。
回滚不是删除配置
接入阶段最直接的流量回滚通常是把 DNS 记录恢复到切换前的值，而不是仓促删除 ZuCDN 中的网站配置。恢复后要考虑 DNS 缓存仍可能让部分用户继续访问新链路，所以在旧 TTL 尚未完全过去前，应尽量同时保持新旧路径可用，并继续观察两侧日志。
如果问题来自源站临时限制，应优先恢复经过验证的访问规则，不要为了应急把源站端口长期开放给所有来源。涉及防火墙白名单时，应依据 ZuCDN 官方公布且当前有效的信息操作；无法确认来源范围时，联系官方支持核实，不能猜测地址段。
留下一份可复用的接入档案
完成准备后，把域名、原解析、目标记录、TTL、源站地址、协议端口、回源 Host、证书负责人、测试 URL、变更时间和回滚负责人统一存档。敏感凭据不要写进普通表格或聊天记录，账号密码、私钥和令牌应存放在专用的秘密管理位置。
这份档案的价值不只在第一次接入。后续更换源站、更新证书、调整 DNS 或排查异常时，团队能够快速判断哪一项发生了变化。ZuCDN 接入准备做得越具体，正式切换时需要临场猜测的事情就越少。
延伸阅读