保留Cloudflare DNS，接入阿里云ESA与腾讯云 EdgeOne

版本：1.0　　资料核对日期：2026-10-17

这篇教程面向已经有网站或 Web 应用、希望接入或更换 CDN 的维护者。它不是把某次聊天中的配置逐条复制，而是把有用的实施顺序、操作细节和踩坑经验重新组织为可迁移的方法。

本文的基础路线是：权威 DNS 保留在 Cloudflare；需要加速的主机名以仅 DNS（灰云）CNAME 接入 ESA 或 EdgeOne；按照请求与资源的业务特征设置缓存、安全与协议，再经过验证上线。

你可以只用一家 CDN，也可以把不同业务交给不同 CDN。没有必要为了使用本教程而同时开通三家代理，更不需要先迁移 NS。

数据脱敏声明：本文域名均使用 example.com 等示例域名，源站地址、密钥、验证目标和账号数据均使用占位符。除明确注明来源的产品默认值、可配范围和协议常量外，示例参数均需按自己的环境选择；演示耗时不代表任何用户的实测结果。不存在可直接复用的真实回源密钥、API Key 或专属 CNAME。

证据边界：本文核对的是官方产品机制，没有替读者登录控制台或完成生产验收。命令只做文本/语法检查，不代表已在你的网络执行；Nginx 片段必须在你实际的版本和完整配置中通过测试。所谓“已配置”不等于“已生效”，“某次成功”不等于“所有网络稳定”。

界面与套餐：中国站、国际站、存量套餐及控制台版本可能不同。正文给出功能入口与核对字段；若账号没有某项能力，不要用别的同名功能勉强替代。具体限制以对应账号的控制台、订单与当前官方文档为准。

怎么阅读

• 第一次接入：先读第 1—4 章，再选择第 5 或第 6 章。
• 配置业务规则：按第 7—9 章的业务特征选择，不按软件名字机械套用。
• 根域名只负责跳转：也必须完成第 10 章，不能因为没有页面而省略证书。
• 需要优化协议：读第 11 章，不要先把所有开关打开。
• 正式上线：先完成第 12 章。出现问题按第 13 章分层排查。
• 确实需要同一域名按地区/运营商分流：另读第 14 章，不把它混入基础路线。

操作等级

标记	含义
【必须】	选择这条路线后，为连通、业务正确性或安全边界不可省略
【建议】	通常值得采用，但有前提和取舍
【可选】	优化或进阶能力，不启用也可完成基础接入
【条件必需】	只有对应业务或功能存在时才需要

文中的 [CF1]、[ESA1]、[EO1] 等标识对应文末官方资料索引。带“示例”字样的策略，是本文提供的起步设计，不是厂商承诺或适用于所有网站的硬性要求。

先完成一条最小正确链路

如果内容较多，按下面顺序推进即可：

1. 选一个主机名和一家 CDN，先不做多地区分流。
2. 备份原 DNS 与源站配置，写好回滚卡。
3. 在新 CDN 添加该主机名和真实源站，明确 HTTPS、Host 与 SNI。
4. 按需完成源站校验，再准备并验证边缘证书。
5. 动态和私有内容先不缓存；只为已确认公开的资源添加缓存。
6. 用临时绑定验证新链路，不切业务解析就完成 TLS 与业务测试。
7. 只修改这个主机名的灰云 CNAME，观察后再扩展。
8. 链路稳定后，一次只做一项协议或性能优化。

文中 YOUR_ORIGIN_IP、YOUR_EDGE_IP、YOUR_CDN_CNAME 等是待替换字段，不是合法的生产配置。所有厂商分配值均从你自己的当前控制台复制，不从教程推算；不要把业务 CNAME 与证书验证 CNAME 混用。

目录

1. 明确目标：DNS、CDN 与源站各负责什么
2. 接入前的盘点、备份与账号检查
3. 源站防护与回源身份校验
4. 两段 HTTPS：边缘证书与源站证书
5. 阿里云 ESA 的 CNAME 接入实操
6. 腾讯云 EdgeOne 的 CNAME 接入实操
7. 程序化动态接口、流式服务与长任务
8. 服务端渲染、CMS 与会话型网站
9. SPA、在线编辑器与富交互前端应用
10. 根域名、HTTPS 与规范重定向
11. HTTP/2、HTTP/3、压缩与其他开关
12. 切换前测试、小步上线与回滚
13. 常见故障与证据驱动的排查方法
14. 可选进阶：多线路 DNS 与境外 Cloudflare
15. 附录：配置卡、验收清单与官方来源

---

第 1 章　明确目标：DNS、CDN 与源站各负责什么

1.1 先认清四个角色

角色	负责什么	例子
域名注册商	域名注册、续费、父区委派 NS 等	你购买域名的服务商
权威 DNS	回答域名应指向哪里	Cloudflare DNS、DNSPod 等
CDN 边缘	接收 HTTP/HTTPS，按配置缓存、转发或执行防护	Cloudflare 代理、ESA、EdgeOne
源站	运行应用、生成响应、保存业务数据	云服务器、容器、负载均衡或托管应用

根域名是 example.com；源站是提供业务的服务器或应用。两者不是同一个概念。

Cloudflare 的橙云与灰云控制的是记录对应的代理行为：橙云流量经过 Cloudflare HTTP 代理；灰云由 DNS 返回目标，不因此经过其代理、缓存和 WAF。在本文的第三方 CDN 方案中，灰云目标是 ESA/EdgeOne 的接入域名，不是把用户直接指向源站。[CF1]

1.2 本教程采用的架构

                  查询解析
访客/客户端 ───────────────────> Cloudflare 权威 DNS
     │                              │
     │                    返回所选 CDN 的解析结果
     ▼
所选 CDN 边缘（ESA 或 EdgeOne）
     │  公开资源可能直接命中边缘缓存
     │  动态请求或缓存未命中才回源
     ▼
源站反向代理 ──> 业务应用/数据库/上游服务

这是按主机名分配服务，不是把三家 CDN 串联。通常一次访问进入其中一家边缘网络；若你有意叠加代理，就已经进入另一套架构，需要重新评估 TLS、缓存、客户端 IP、超时和故障定位，本文不默认采用。

1.3 一个组合示例，不是固定推荐

入口	功能	你可以选择的接入方式
example.com	规范跳转入口	保持 Cloudflare 代理，或由任一 CDN 接收并跳转
www.example.com	公开内容与会话型网站	选择业务验收合格的一家 CDN
api.example.com	程序化接口	选择接口、鉴权、长任务或流式测试合格的一家 CDN
app.example.com	富交互 Web 应用	选择资源发布和完整功能验收合格的一家 CDN

不要仅凭“API 用 A、静态用 B”决定供应商。同一家服务在不同地区、账号和时段的结果可能不同。本文要求你比较可复现的业务结果，而不是提供永远有效的厂商排名。

1.4 它不会自动实现什么

本路线不自动提供：

• 同一主机名的国内/国外或三网分别调度。
• 两家 CDN 之间的自动健康检查与故障切换。
• 免费套餐的 SLA 或无限性能。
• 源站地址从未暴露、源站免疫所有攻击。

如果只是准备好两家控制台但 DNS 仍指向原平台，新平台的规则不会自动给原链路提速。配置备用平台也需要持续检查证书、费用和可用性，不能无限期不管。

本章完成标准：你能画出每个主机名的 DNS、边缘、源站路径，并明确哪些入口仍走 Cloudflare 代理。

---

第 2 章　接入前的盘点、备份与账号检查

2.1 先按请求特征分类【必须】

一个网站可以同时属于多类。最小判断单位是一类请求/资源，不是一个软件品牌。

特征	常见业务	需要重点检查
带鉴权、包含个人数据或执行写入	业务 API、账户接口、订单、回调	共享缓存边界、鉴权、限流、错误响应
慢首字、持续输出或长时间任务	AI 推理、SSE、导出、任务网关	分层超时、无数据间隔、缓冲、完整结束
页面因登录或 Cookie 而不同	CMS、论坛、会员、电商	动态排除、身份隔离、可选公开 HTML 缓存
多个 JS/CSS 模块并依赖接口	SPA、管理台、编辑器、设计工具	版本化资源、HTML 更新、业务 API 与发布兼容
文件需要权限或短期签名	私有附件、简历导出、下载	不误入公共强缓存，过期和越权验证
仅执行规范跳转	根域名、旧域名入口	解析、TLS、跳转链、路径与参数保留

2.2 建立一份私有配置台账【必须】

在你自己安全的存储位置填写真实值。不要把填写后的台账公开分享。

项目	需要记录的内容
域名	根域名、子域名、主入口和历史入口
DNS	当前 NS、业务 A/AAAA/CNAME、代理状态、TTL
验证与邮件	TXT、MX、SPF/DKIM/DMARC、CAA、证书验证记录
源站	地址、监听端口、虚拟主机、回源 Host、SNI
TLS	边缘和源站证书分别覆盖哪些名称、到期时间、续期方式
安全	防火墙、回源校验、WAF、Bot、限流、健康检查
缓存	源站响应头、CDN 规则顺序、刷新机制、浏览器缓存
回滚	原目标、原代理状态、原规则与恢复入口

备份 DNS 区文件时，注意它通常不足以完整保存 WAF、重定向、代理外配置和源站设置；这些项目另行导出或记录。Cloudflare 的记录管理与导入导出功能见 [CF2]、[CF3]。

2.3 确认账号真实能力【必须】

操作前，在所选产品的当前套餐页面检查：

• CNAME 接入是否支持，能添加多少主机名。
• 加速区域是否符合业务与备案要求。
• 自动证书、DNS 委派、通配符、上传证书等能力。
• 缓存规则、Header 修改、源站证书认证、超时的可配范围。
• WAF 观察/评估、规则级例外与日志权限。
• 文件大小、上传、并发、长连接、带宽或业务用途限制。
• 是否必须实名认证，是否属于付费增值功能。

免费版、活动版和付费版不要混写。即使说明“流量不限量”，也不意味着无限吞吐、适合大文件分发或有 SLA。具体产品限制在第 5、6 章说明。

2.4 基线测试【建议】

切换之前先留下少量、可重复的业务结果：

1. 测试公开页面、登录页及一个实际动态请求。
2. 如果有流式业务，记录首字、结束状态及是否中断。
3. 如果有前端应用，记录首次访问与版本资源加载。
4. 写明时间、网络、代理状态、客户端版本及样本数量。

不发大并发压测，不使用真实支付或其他不可逆操作；写操作使用测试账号与可清理的数据。

本章完成标准：备份可用、业务分类完成、套餐限制明确，而且能按台账恢复原链路。

---

第 3 章　源站防护与回源身份校验

3.1 回源 Header 的作用与边界

本文示例使用：

X-Origin-Verify: YOUR_ORIGIN_SECRET

CDN 在发往源站的请求中设置/覆盖这个 Header，源站只接受匹配值。它用于校验“请求携带了授权秘密”，不是密码学意义上的 CDN 身份证明。

因此：

• 密钥泄露后，能到达源站的请求也可能携带它。
• 它不阻止 TCP/TLS 握手，也不能承担网络带宽型 DDoS 防护。
• 默认虚拟主机拒绝握手只是额外收敛面，不能保证源站地址不被发现。
• 如平台支持并适合业务，可评估回源 IP 白名单、私有回源或 mTLS；不要把公网开放 443 写成唯一方案。

这一节是可选防护设计；一旦启用，所有实际回源链路正确携带 Header 就变成条件必需。

3.2 生成密钥【采用该方案时必须】

在受控终端中，可用以下方式生成一个随机值：

openssl rand -hex 32

将结果放入密码管理器或秘密管理系统，不提交代码仓库、不回显到应用页面、不写入公开响应头。不要把教程中的 YOUR_ORIGIN_SECRET 当成实际密钥。

CDN 应使用 Set/设置/覆盖语义，确保访客自带的同名 Header 不会变成重复值。不把“仅当不存在时添加”直接视为等价。

3.3 安全实施顺序【必须】

前置检查：先保证当前回源不会明文传输秘密。

在下发 Header 前，先确认当前 CDN 到源站使用 HTTPS，并按该平台支持的方式验证源站身份；浏览器地址栏是 HTTPS 不足以证明这一点。当前为 Cloudflare 时，核对适用的 Full (strict) 及证书前提；Flexible 的访客 HTTPS 仍可能通过 HTTP 回源。[CF14]

若现有链路尚未满足要求，先按第 4 章修正回源 TLS 并验收，再回到本节添加秘密。

第一步：只改当前正在服务的 CDN。

如果当前仍走 Cloudflare 橙云，可在站点的规则页面找到“转换规则／修改请求标头”，创建请求 Header 规则：

• 范围：将要启用校验、且授权使用该密钥的主机名。
• 动作：设置静态值。
• 名称：X-Origin-Verify。
• 值：你生成的秘密。

Cloudflare 的控制台创建方式见 [CF4]。不要把它误配成响应 Header，否则会泄露给访客。

第二步：验证当前 CDN 已正确带标头。

使用受控调试或源站日志仅记录“校验通过/未通过”的结果，避免记录完整秘密。确认普通业务仍能访问。

第三步：在源站启用校验。

下面是 Nginx/OpenResty 逻辑片段，不是完整虚拟主机配置。先备份；使用面板或容器管理时，应编辑其实际持久化配置，避免重启后丢失。

在 http {} 上下文中定义：

map $http_x_origin_verify $origin_allowed {
    default 0;
    "YOUR_ORIGIN_SECRET" 1;
}

在需要保护的业务 server {} 中加入：

if ($origin_allowed = 0) {
    return 403;
}

请先将占位符替换为秘密，再测试与重载。该片段不应整块覆盖你已有的 TLS、代理、PHP、访问控制或日志设置。Nginx 的 map 与 return 语义见 [N1]、[N2]。

执行顺序不能忽略：服务器级 rewrite 指令先于 location 选择运行；仅新增一个健康检查或 ACME location，不能绕过上面的拒绝逻辑。例外必须纳入受控的校验条件，或放在真正独立、最小权限的入口。需要保护的源站跳转，校验应在提前结束请求的 return 之前。[N2]

如果后端应用不需要该秘密，可在实际 proxy_pass 代理范围内清除它，减少进入应用日志或调试回显的机会：

proxy_set_header X-Origin-Verify "";

这条指令只在本层完成校验后使用。新增 proxy_set_header 可能改变从上层继承的整组头设置，必须一起核对并保留既有 Host、客户端地址等所需头；PHP/FastCGI 或其他代理方式应按其独立配置处理，不能把该指令视为通用删除器。[N5]

这里选择 403，便于在接入期诊断。若后续确实要用 Nginx 的 444 直接关闭连接，应理解它不是正常 HTTP 响应，CDN 可能展示自己的源站错误；它不天然比 403 更能抵御网络攻击。

第四步：先测试配置，再用原部署方式平滑重载。

nginx -t

确认无误后，采用你现有的服务、面板或容器重载流程。只有在当前环境确实使用该命令管理同一个 Nginx 实例时，才执行：

nginx -t && nginx -s reload

OpenResty 的可执行文件路径可能不同，不要在宿主机测试一个无关实例。[N3]

第五步：为新 CDN 配置同样的回源校验，完成切流前测试。

不要先切流再补 Header，也不要先移除当前 CDN 的规则。

3.4 防火墙怎么处理

如果原来只允许 Cloudflare 回源地址段，新 CDN 即使带正确 Header 也可能连不上。

优先核对目标产品正式支持的回源地址范围、私有访问或认证方式，并只开放所需端口和范围。动态地址池、健康检查和 IPv6 都要纳入清单。不要不经盘点就把所有端口或所有 IPv6 放开。

确需将 HTTPS 暴露到公网时，明确接受的网络层风险，并保留防火墙、连接资源保护和监控；Header 是应用层控制的一部分，不是防火墙替代品。

3.5 根域名、健康检查和证书验证不能遗漏

• 根域名在源站执行跳转：它也是回源请求，需要匹配正确虚拟主机和校验规则。
• 根域名在 CDN 边缘直接跳转：正常跳转不需要回源，不要为此制造一个不必要的源站依赖。
• 健康检查：配置它携带授权标头，或使用独立、最小权限且不返回敏感数据的健康端点。
• HTTP 文件验证：启用校验后要检查验证访问是否可达；不要为解决证书问题把整个站点加白。

默认站点如原已使用 ssl_reject_handshake，不要为了新 CDN 随手删除。合法回源应携带正确的 SNI；该指令还需要当前 Nginx 版本支持。[N4]

3.6 轮换与回滚

轮换可采用短期同时接受新旧两个秘密：源站先增加新值，逐个 CDN 更新，确认后撤销旧值。不要在 CDN 还未更新完时直接删除旧值。

若启用源站校验导致全站失败，先恢复刚才修改的校验片段并重新测试配置，而不是把全部安全策略清空。备份中包含秘密，应限制访问。

3.7 正反向验证要分别做【必须】

只在自己有权限管理的源站上进行低频验证：

• 经当前 CDN 的正常业务请求，不手工添加回源秘密，应成功。
• 经新 CDN 的切流前请求，同样不手工添加秘密，应成功。
• 若网络策略允许直达源站，缺少或使用错误秘密的请求，应被网络层或业务层拒绝；记录具体在哪一层，不强求都显示 403。
• 运维用正确秘密直连源站时，仍使用匹配名称的 Host/SNI，并验证源站证书；如果是 Origin CA，应使用你明确下载并信任的正确 CA 链进行这项受控测试，而不是用 -k 冒充证书通过。
• 根域名如果边缘直接重定向，单独确认它不依赖回源；如果源站负责跳转，则纳入上述测试。

本章完成标准：普通 CDN 请求成功、无授权直连请求被拒绝、健康检查正常，而且测试输出中没有秘密。

---

第 4 章　两段 HTTPS：边缘证书与源站证书

4.1 先分清是哪一段失败

浏览器/SDK ── TLS A ──> CDN 边缘 ── TLS B ──> 源站
          边缘证书                    源站证书

浏览器看到的是 TLS A 的证书。边缘证书正常，不证明 TLS B 已经正确校验；反之，源站证书正常也不证明业务域名已在 CDN 上接入。[CF5]

4.2 原有 Cloudflare Origin CA 证书能否沿用

Cloudflare Origin CA 主要用于 Cloudflare 与源站之间，不是浏览器通常信任的公共证书。将记录改成直连源站的灰云 A 记录，可能立即出现不受信任证书错误。[CF6]

接入其他 CDN 时按下面顺序处理：

1. 查看目标 CDN 的源站证书认证、信任库与名称校验能力。
2. 核对源站证书的名称、链、有效期和回源 SNI。
3. 若平台支持符合要求的自定义信任链，可按官方步骤配置后验证。
4. 若无法建立明确可信关系，优先部署适合该链路的公共 CA 证书，并启用平台提供的严格校验能力。

仅仅“HTTPS 能连上”不等于源站身份被验证。如果产品/套餐不提供严格校验，应将该限制写入风险台账，不把“关闭校验”宣传成更安全的长期方案。

公共证书也不必然造成续签死锁。DNS-01 不依赖请求走到同一个 HTTP 服务器，还可通过支持的 DNS API 或验证委派实现自动化；手工一次 TXT 验证通常不等于后续自动续期。[AC1]

4.3 分清所有权验证与证书验证

记录用途	证明什么	处理原则
CDN 添加站点时的归属验证	你有权接入这个域名	按当前控制台要求添加和保留
证书 DCV	证书申请者控制相应名称	与证书生命周期一起管理
Google 等平台 TXT	第三方业务验证	不因更换 CDN 而随手删除
邮件、CAA 等记录	邮件与签发授权等	原样盘点，避免误改

不要把某次添加成功就理解为验证记录以后一定没用。两家 CDN 若要求同一个 _acme-challenge 名称指向不同 CNAME，不能在同一名称放两个不同 CNAME；应选择平台支持的不同验证方式或重新设计证书管理。[DNS1]、[AC1]

4.4 切流前先准备边缘证书【必须】

对每个将接收访问的主机名，在目标 CDN 完成：

1. 添加主机名。
2. 选择当前账号支持的证书来源。
3. 如使用 DNS 验证或 DNS 委派，逐字复制平台给出的名称、类型和目标。
4. 在当前实际权威 DNS中添加记录。基础路线的 NS 未变，所以这里仍是 Cloudflare。
5. 验证 CNAME 记录设为仅 DNS，不误开代理。
6. 等待证书显示有效并已部署，再实际验证 TLS。

DNS 委派便于业务解析尚未切换时预先签发，但是否支持、需要哪条记录以及自动续期条件，都按各平台正文操作。不要自行拼接厂商 CNAME。

4.5 通配符不等于根域名

*.example.com 这一匹配项覆盖 www.example.com 这类一层子域名，不覆盖 example.com，也不覆盖 a.b.example.com。若同一张证书同时含 example.com 和 *.example.com 两个 SAN，才可覆盖对应两种名称。[CF6]

所以，根域名即使只返回跳转，接收 https://example.com 的边缘也需要匹配它的有效证书。TLS 握手发生在 HTTP 重定向之前。

4.6 验证记录与扁平化

Cloudflare 支持根域名 CNAME 扁平化；因此根域名查询不到直接 CNAME 答案，并不能单独证明配置失败。另一方面，对所有 CNAME 开启扁平化，可能干扰第三方验证记录要求返回原始 CNAME 的场景。[CF7]

基础做法是：不要为了业务根域名而把所有验证 CNAME 一并扁平化。检查平台诊断要求与公开 DNS 答案。

4.7 证书失败时先检查什么

• 名称是否重复拼接了域名后缀。
• CNAME 目标是否多出占位符、空格，或以错误的点开头。
• 验证记录是否加在真正的权威 DNS。
• 是否误开代理、错误扁平化、与同名记录冲突。
• CAA 是否允许所选 CA；签发是否受限或仍在部署。
• 源站证书与边缘证书是否被混为一谈。

不要在未核对错误原因时反复删证书申请，也不要因为业务 DNS 尚未指向某 CDN 就断言 DNS 委派一定无法签发。

本章完成标准：每个接入名称的边缘证书有效，回源 TLS 的信任条件清楚，续期验证记录有台账。

---

第 5 章　阿里云 ESA 的 CNAME 接入实操

5.1 先检查资格，不把免备案写成免实名

进入 ESA 当前账号的套餐和接入页面，确认权限与费用。阿里云接入文档将账号实名认证列为前提；全球（不包含中国内地）区域无需域名 ICP 备案，不代表整个产品免实名认证，也不豁免源站本身的合规要求。[ESA1]

若账号不满足当前准入条件，应处理资格或选择其他合适方案，不能靠调整 DNS 绕过限制。免费版仍有性能、资源和规则数量限制，并不提供性能/SLA 承诺；先核对规则和证书配额，再设计配置。[ESA2]

5.2 添加管理站点【必须】

1. 登录 ESA，进入 站点管理 → 新增站点。
2. 输入要管理的域名，例如 example.com。
3. 选择符合业务与备案条件的加速区域；本文非内地区域示例选择全球（不包含中国内地）。
4. 接入方式选择 CNAME，不选择会迁移权威 DNS 的 NS 接入。
5. 根据当前账号已有套餐或购买页面完成绑定，确认付费项目后再提交。
6. 按站点概况等页面给出的归属验证要求，在 Cloudflare 添加对应记录，再返回验证。

完成归属验证不切换当前业务。添加管理站点也不表示根域名及所有子域名已经接入，实际使用的名称仍要逐项配置。[ESA1]

5.3 添加业务名称与源站【必须】

进入站点 DNS → 记录 → 添加记录。在 CNAME 接入下，此处配置用于告诉 ESA 如何服务和回源；Cloudflare 仍是公网权威 DNS。

字段	IP 源站示例
主机名	www、api、app；根域名按界面支持的 @/根名称填写
源站类型	选择当前界面提供的 IP 方式，如 A/AAAA
源站值	将 YOUR_ORIGIN_IP 替换为自己的服务器地址
代理加速	为实际要接入的业务开启
ESA 分配 CNAME	保存后逐项复制到私有台账，暂不修改 Cloudflare 业务解析

源站为域名、对象存储或负载均衡时，采用对应类型的配置，不强套 A 记录。每个名称使用它自己的分配值，不能让未接入名称 CNAME 到已接入业务名来代替接入。[ESA1]

避免回源循环：源站域名不能又解析回当前业务的 CDN 接入链路。若源站填写域名，先画出它最终解析到哪里。

5.4 明确回源协议、Host、SNI【必须】

到 规则 → 回源规则，按实际主机名创建规则。部分设置也可能出现在记录编辑或全局回源配置中；冲突时检查有效规则。

项目	本文的起步目标
条件	主机名等于正在接入的实际名称
回源协议	源站 TLS 配好后，明确 HTTPS
回源端口	实际 TLS 端口，标准示例为 443
回源 Host	源站用于路由应用的名称
SNI	按证书和平台支持方式匹配 TLS 名称需求

源站地址是连接目标，Host 是 HTTP 请求字段，SNI 用于 TLS 名称选择。ESA 的 Host 默认行为与源站类型有关，不要一律假设等于访问域名。[ESA3]

5.5 验证源站证书，不只选 HTTPS

入口：SSL/TLS → 源站证书。核对有效期、名称和受信任链要求，按功能说明配置认证。

ESA 官方说明 HTTPS 回源默认不自动校验证书；开启认证后失败可能返回 502。使用 Cloudflare Origin CA 时，不能直接假设它在 ESA 的信任范围，也不要为消除错误就永久关闭认证。按第 4 章选择证书与信任方案。[ESA4]

有秘密或敏感业务时，必须形成可信的回源方案。具体匹配采用哪个名称，以当前功能说明和实际握手为准，不凭 Host/SNI 的名称相似就认定认证已经通过。

5.6 设置 ESA 到源站 Header【采用第 3 章方案时必须】

1. 规则 → 转换规则 → 修改请求头。
2. 选择 ESA 到源站 → 新增规则。
3. 规则名称可为 origin-verification。
4. 条件限制到共享这套授权机制的主机名；需要回源的根域名也纳入。
5. 将 X-Origin-Verify 设置/修改为静态秘密，确保覆盖访客传来的同名字段，而不是产生多个值。
6. 保存，检查其他规则是否覆盖或重复添加该头。

仅在实际回源时执行。缓存 HIT 直接从边缘响应，不能证明这个标头已正确注入；应使用本来就不缓存的安全测试端点验证。[ESA5]

5.7 提前准备边缘证书【必须】

1. SSL/TLS → 边缘证书，选择当前账号支持的申请或上传方式。
2. 核对 CA、免费配额及域名范围，不默认所有下拉选项都免费。
3. 需要根域名和通配符时，显式核对最终名称包含 example.com 与 *.example.com。
4. 采用持续验证委派时，进入 托管 DCV，复制控制台给出的名称、类型和目标。
5. 在 Cloudflare 添加对应记录，验证 CNAME 保持仅 DNS。
6. 返回验证，等待签发和部署，再做切流前 TLS 测试。

输入框如会自动附加后缀，以最终标签预览为准，避免生成两个 example.com。业务加速 CNAME 与托管 DCV 的 CNAME 分别保存，不能互换。托管 DCV 用于自动签发和续签，前提是相应配置持续有效。[ESA6]

5.8 缓存规则：先排除，再优化

入口：规则 → 缓存规则 → 新增规则；当前版本如归在缓存模块，寻找同名功能。

A．私有接口绕过【对应业务必须】

• 名称：api-bypass。
• 自定义条件：主机名等于 api.example.com。
• 动作：绕过缓存 → 绕过全部。
• 不再创建覆盖该接口的缓存全部策略。

B．会话及动态内容绕过【对应业务必须】

• 限定实际业务主机名。
• 加入第 8 章整理的动态路径、会话 Cookie、Authorization 或参数条件。
• 逻辑应为“主机名 AND（路径 A OR 路径 B OR 会话条件）”，别让某个 OR 分支丢失 Host 约束。
• 动作：绕过全部。
• 套餐无法表达必要排除时，暂不启用宽泛 HTML 缓存。

C．公开静态目录【建议】

• 条件：实际主机名 AND 已确认公开的资源目录。
• 优先遵循源站；有明确发布策略时再自定义边缘 TTL。
• 保留影响内容的查询参数，浏览器缓存单独评估。

D．公开 HTML【可选】

• 仅在第 8 章条件成立后添加。
• 限定公开页面集合，短 TTL 起步，验收更新与身份隔离。

ESA 先判断缓存资格，再处理过期策略，强制 TTL 不等于解除所有资格限制。忽略源站模式会改变部分缓存头的处理；本文不对 Authorization、Set-Cookie 与所有强制策略组合给出未经核实的保证。私有内容使用明确绕过。[ESA7]

5.9 ESA 优先级：靠前、按子功能生效

规则高于同功能全局设置；列表越靠前，优先级越高。缓存规则按子功能取优先命中且非空的配置，不是命中一条后所有子项全部停止。[ESA8]

上方：接口、私有、动态及会话请求绕过
中间：确认公开的静态资源策略
下方：已验证的公开 HTML 或其他通用策略

尽量使规则不重叠。每次修改后同时检查缓存资格、TTL、缓存键及浏览器缓存，不能只看一个子功能。

5.10 回源超时【长任务条件必需】

入口：规则 → 回源规则 → 新增规则 → 回源超时时间，限制到所需业务。

官方定义为七层 HTTP 请求时间，不含 TCP 建连；默认 30 秒，最长 300 秒，官方建议不超过 60 秒。更长设置应有业务理由，并核对资源与套餐能力。[ESA9]

不要把它直接等同 Nginx 的相邻读取超时。公开说明未充分覆盖本文所有 SSE 心跳与计时组合，因此需要真实测试，不能保证心跳无限延长连接。

5.11 处理安全误报【有证据再做】

进入 安全防护 → WAF → 白名单规则。先查事件，再匹配必要主机名与路径，优先跳过指定类别或规则 ID。

白名单“全部规则”指对应 WAF 与 Bots 管理范围，不能扩写为全部 ESA 安全功能或 DDoS。免费版有条数限制；API 名称本身不是可信身份，不默认全站跳过。[ESA10]

表达不了所需最小例外时，评估精确业务隔离、接口设计或更合适的能力；保留应用鉴权与限流。

5.12 网络与协议最后调优

• HTTP/2 与 HTTP/2 回源分别配置；针对特定不缓存回源慢症状，可关闭回源 HTTP/2 做对比，不是 API 一律关闭。[ESA-H2]
• 中国大陆网络－接入优化不是免费版实名后即有的开关。本次官方条件包括非内地区域、企业版加购及按流量计费。[ESA11]
• IPv6 是客户端接入能力，不由此推导源站必须有 IPv6；WebSocket 等还需核对套餐与业务。[ESA11]

5.13 根域名边缘跳转示例【选择 ESA 根入口时】

先添加根名称并部署覆盖 example.com 的边缘证书，再到 规则 → 重定向规则 → 新增规则：

• 规则名称：apex-to-www。
• 条件：主机名等于 example.com。
• 单一重定向：选择动态。
• 目标表达式：concat("https://www.example.com", http.request.uri.path)。
• 保留查询字符串：明确开启，不依赖默认值。
• 状态码：先用 302 对网页验证，确认无误后按规范化需求改为 301。

动态目标必须填写合法表达式，不把变量名称当作普通字符串。用带路径与查询参数的入口验证，再发布永久策略。[ESA-REDIRECT]

本章完成标准：源站、证书、校验与规则准备完成，通过第 12 章切流前测试后，再改业务 CNAME。

---

第 6 章　腾讯云 EdgeOne 的 CNAME 接入实操

6.1 先看套餐与区域

主要步骤参照中国站 product/1552 文档；部分机制以标明的 EdgeOne 官方站点说明补充。中国站、国际站、存量套餐的权益不混为一张表。

免费版对视频或其他大型文件业务有用途限制，可能限制或暂停不符合要求的使用。本文未找到足够官方依据支持“先不限速，持续下载再固定限为 500KB/s”的统一说法，不把流量不限量等同无限性能。[EO-FREE]

6.2 添加站点与实际主机名【必须】

1. 从服务总览/网站安全加速进入添加站点，输入管理域名。
2. 选择符合账号资格、区域与套餐要求的配置。
3. 选择 CNAME 接入，完成提示的站点归属验证，不迁移注册商 NS。
4. 域名服务 → 域名管理 → 添加域名。
5. 逐项添加实际接收流量的名称；根域名按界面支持的 @/根名称填写。
6. 配置源站类型与真实地址，逐项复制其分配的业务 CNAME。

IP/普通域名源站与对象存储的默认 Host 可能不同。添加根管理站点不等于所有子域名都自动接入，也不能把业务 CNAME 当成回源地址。[EO1]

6.3 回源协议、Host 与 SNI

字段	IP 源站示例
源站	自己实际的 YOUR_ORIGIN_IP
回源协议	源站证书配好后，明确 HTTPS
端口	实际 TLS 端口，标准示例为 443
回源 Host	源站应用实际要求的名称
SNI	按产品支持方式与证书要求核对

配置位于域名编辑及规则引擎对应回源操作。官方源站 FAQ 说明 SNI 默认跟随回源 Host，控制台不支持独立修改；如果源站要求两者不同，先核实可行方案，不寻找不存在的字段。[EO-ORIGIN]

6.4 源站证书认证要核对权限

官方说明该功能默认不校验，需基础版及以上套餐。文档列出的指定 CA 方式检查签发 CA 与有效期，不能自行扩写成浏览器式完整主机名验证。需要严格名称校验的业务，还应核实实际支持项并选择满足要求的回源方案。[EO-CERT]

有权限时，在 域名服务 → 域名管理 → 对应域名 HTTPS 编辑 → 源站证书校验 配置，再验证可信链和名称等实际支持的检查。

免费账号如无此能力，不能在验收表勾选“已严格验证源站身份”。传输秘密或敏感业务时，采用能建立可信回源的方案或评估合适套餐，不把缺少认证当成优点。

6.5 回源秘密 Header【采用对应方案时必须】

1. 站点加速 → 规则引擎 → 创建规则 → 新增空白规则。
2. HOST 等于授权名称，多个名称按界面提供的逻辑表达。
3. 操作选择 修改 HTTP 回源请求头。
4. 选择设置/覆盖，名称 X-Origin-Verify，值填自己保管的秘密。
5. 保存并发布，通过不缓存请求验证。

设置与增加不是同一动作：存在同名头时应实现覆盖和唯一值，不产生多个秘密字段。不要误配成节点响应头。源站应按第 3 章控制秘密的后续传递；这是本文的纵深防护建议，不是 EdgeOne 自动行为。[EO-HEADER]

客户端地址头是否已经自动携带，按本产品说明核对，不盲目再追加同名字段；源站仍需可信代理边界。

6.6 先申请并部署边缘证书【必须】

入口：域名服务 → 域名管理 → 对应域名 HTTPS 配置 → 边缘 HTTPS 证书配置。

1. 选择账号支持的免费申请或上传证书。
2. CNAME 接入且功能可用时，选择 DNS 委派验证。
3. 获取该名称实际生成的验证内容。
4. 在 Cloudflare 添加指定验证 CNAME，保持仅 DNS。
5. 返回验证并保存部署，等待证书有效及部署完成。
6. 按正确业务名称做 TLS 测试，不用加速 CNAME 的名字代替业务名。

这是委派证书验证子域名，不是迁移整域 NS，可用于先签证书再切业务 CNAME。自动续期依赖验证持续有效；接入方式变更等还有专门条件，不能承诺无条件永久续期。[EO-SSL]

根域名需要自己的证书名称覆盖，www 配置完成不代表根域名完成。

6.7 建立业务缓存规则

入口：站点加速 → 规则引擎 → 创建规则/新增空白规则。

私有接口【必须】

• HOST 等于 api.example.com。
• 操作：节点缓存 TTL → 不缓存。
• 有长任务时再按证据设置回源超时，不对所有接口一律拉到最大。

会话网站与富交互应用

• 公开资源规则限制到第 8/9 章核实的目录。
• 接口、管理、私有文件与会话内容设置明确不缓存。
• 检查 HOST 与路径/Cookie 等组合没有丢掉域名约束。
• 不具备必要排除条件时，暂不启用全域 HTML 缓存。

自定义节点 TTL 时检查“强制缓存”状态。强制策略可能覆盖源站缓存意图；保守起步遵循源站，仅对已经证明公开的资源考虑覆盖。[EO-CACHE]

不默认忽略所有查询参数。修改后用不同版本、语言或业务参数验证正文正确，不仅查看 HIT。

6.8 优先级有官方文档口径差异，不拿私有数据试错

规则引擎概述写明：同级 IF 自上而下执行，下方操作可覆盖上方；同组 IF/Else IF/Else 只执行命中分支；重定向、强制 HTTPS 可中断后续操作。[EO-RULES]

但中国站《EdgeOne 内容缓存规则》同时明确写有：规则引擎内缓存规则从上往下匹配，最上方优先级最高。[EO-CACHE2]

两页对缓存重叠时的描述并不一致。本文不擅自把其中一页称为旧版，也不发布一张未经账号验证的通用排序表。

安全的起步方法：

1. 私有接口主机名只配置不缓存，不再添加命中它的缓存规则。
2. 公开静态目录和动态/私有目录明确分开；公开规则排除会话、认证、签名及其他私有条件。
3. 暂不创建覆盖整个网站的 HTML 强缓存。
4. 如果必须使用重叠规则，在没有用户数据的专门测试路径中，通过支持的诊断工具和实际响应核对有效策略；必要时向厂商确认当前引擎与缓存子功能行为。
5. 未能验证排除规则绝不会被覆盖，就不发布该缓存设计。

规则优先级不应是隔离私有数据的唯一防线；平台缓存规则的顺序也不等于独立安全模块的执行顺序。

6.9 回源超时与 HTTP/2 要分开

为对应 HOST 创建规则，动作选择 回源超时时间。官方当前 HTTP 应答超时为 5—600 秒，默认 15 秒，覆盖无应答数据或部分响应中断的情况，超时可返回 524；120 秒只是其中一个可选值。[EO-TIMEOUT]

这项可调配置不适用于 HTTP/2 回源。文档说明 HTTP/2 有 600 秒无帧收发的连接超时，当前不可调整；不能将连接级条件解读成每个请求必然成功或每个流都拥有同样独立时限。[EO-TIMEOUT]

测试 HTTP/2 回源前先核对源站。官方提示“协议跟随＋客户端 HTTP”可能走 H2C，源站不支持时会失败；明确 HTTPS 回源与这项明文 H2C 问题分开处理，不假定自动回退能弥补不兼容。[EO-H2]

6.10 安全规则与免费版：先看真实动作

本次中国站套餐表对免费版的关键边界如下，实施时仍须按账号复核：[EO-PLAN]

功能	不应作出的假设
托管规则	免费规则集/评估能力不等于全部付费规则集
基础访问管控	观察、拦截不等于有放行动作
精准匹配自定义规则	不默认免费版支持付费精准规则能力
防护例外完整请求跳过	免费版不能按付费能力的步骤强行添加

出现误报时：

1. 在 安全防护 → Web 防护 及事件分析找到实际命中模块。
2. 有例外权限时，按支持的条件创建最小范围例外，只跳过必要目标。
3. 观察/评估只改变所选模块，不宣传成全局跳过。
4. 免费版无法表达所需例外时，评估隔离业务、支持的精确调整、其他通过验收的链路或适合套餐。
5. 没有日志时不断言一定是 Bot/CC，也不默认存在可关闭的独立 Bot 总开关。

接口放宽后仍保留应用鉴权与合理限流；不能用“能调用了”证明安全边界仍正确。

6.11 根域名边缘跳转

先接入根名称并部署有效证书，再在规则引擎匹配 HOST 等于 example.com，选择 访问 URL 重定向：

• 固定目标为 HTTPS 的 www.example.com。
• 使用平台支持的方式保留原路径和必要查询参数。
• 先临时验证，再选需要的永久状态码。

不要把“回源 URL 重写”当作浏览器重定向；前者不必改变用户地址栏。变量与目标字段以当前配置项说明为准。[EO-REDIRECT]

本章完成标准：套餐权限、有效缓存与回源协议清楚，证书和真实业务通过切流前测试后，再修改 Cloudflare 对应记录。

---

第 7 章　程序化动态接口、流式服务与长任务

7.1 识别自己的服务，而不是照抄“API 站”

这类服务可能由浏览器、SDK、脚本或第三方系统调用，返回结果可能带鉴权、包含个人数据、执行写入，或等待上游任务。例子包括 AI 推理、业务 REST API、订单网关、任务查询、支付回调。

不是所有 API 都长连接，不是所有 GET 都公共可缓存，也不是所有 JSON 都动态私有。你需要回答：

1. 同一个 URL，不同用户是否得到不同内容？
2. 请求是否改变状态？是否允许重复执行？
3. 是否持续输出，还是等待完成后一次返回？
4. 首字前会等多久，输出期间最长可能多久没有数据？
5. 是否涉及大请求体、上传或私有下载？

本文先采用保守的“不共享缓存”接口基线；公共只读查询需要缓存时，另行设计身份、缓存键和有效期。

7.2 建立接口规则【必须】

若 api.example.com 主要提供私有业务接口：

字段	起步配置
匹配	主机名等于 api.example.com
节点缓存	不缓存／绕过缓存
缓存键	不为解决命中率而忽略鉴权或业务参数
浏览器/客户端缓存	私有敏感响应由应用明确设置不存储策略
回源	使用第 4—6 章已验证的 TLS、Host、SNI 和校验标头
安全	保留鉴权与合理限流，例外仅针对证实误报的范围

在 ESA 的缓存规则中创建对应主机名规则并选择绕过；在 EdgeOne 规则引擎中选择节点缓存 TTL 的不缓存行为。具体字段和覆盖顺序见平台章节，不能认为创建了规则就不受后续规则影响。

应用对不能存储的响应可输出：

Cache-Control: no-store

no-store 与 no-cache 不同：后者允许保存，但复用前需要重新验证；private 针对共享缓存，不代表浏览器也绝不保存。RFC 9111 定义这些语义。[H1]

注意：添加新规则或响应头不保证已经误缓存的数据立即消失。如先前发生私有响应误缓存，停止相关缓存、清除受影响对象，按数据泄露事件评估影响；不能只刷新后宣布没有风险。

7.3 分清五层超时【长请求条件必需】

层	要查什么	典型证据
客户端	连接、读取、总请求时长	SDK 异常、客户端时间线
CDN 到源站	建连、应答、空闲连接、协议条件	CDN 状态码、请求标识、规则生效状态
反向代理	上游读取/写入与缓冲	Nginx/OpenResty 错误日志
业务应用	任务时长、连接限制、取消机制	应用日志、任务状态
上游服务	排队、推理、速率及错误	上游请求标识与错误体

120 秒只可能是其中一个配置值。它不自动改变其他层，也不表示“请求总共最多 120 秒”或“120 秒内必定成功”。EdgeOne 的 HTTP 应答超时和 HTTP/2 回源连接超时分开说明，见 [EO-TIMEOUT]。

Nginx 的 proxy_read_timeout 是相邻读取操作之间的超时，不是整个响应总时长。一个持续产生数据的请求可能运行更久；某个间隔超过设置则仍会失败。[N5]

起步方法是先观察合理业务的首字与最长无数据间隔，再在产品允许范围内留出余量，同时检查应用资源。不要把所有超时无限延长，长期悬挂连接也会消耗资源。

7.4 SSE 的代理配置示例【仅对应协议需要】

SSE 按 text/event-stream 流式发送事件，事件按协议边界解析。它与 WebSocket 是不同机制；启用 WebSocket 开关不是 SSE 修复方法。[SSE1]

如果你自己的 Nginx/OpenResty 位于 CDN 与应用之间，可在已经存在的流式接口 location中评估以下增量配置：

proxy_http_version 1.1;
proxy_buffering off;
proxy_cache off;
proxy_read_timeout 180s;

proxy_http_version 1.1 在这里指你管理的 Nginx 到后端应用，不是要求 CDN 必须使用 HTTP/1.1 回源。它是便于在常见代理环境起步验证的示例；已有其他受支持且通过验收的上游协议时，不机械覆盖。

这里 180s 是演示值，必须按实际允许的无数据间隔和上游行为重新选择。不要为了加入这三行，创建一个会覆盖认证、路由或上传配置的新 location /。proxy_cache off 只控制这一层 Nginx，不会自动关闭 CDN 缓存。

应用也可按所用代理链的支持情况返回：

Content-Type: text/event-stream
Cache-Control: no-store
X-Accel-Buffering: no

X-Accel-Buffering 是 Nginx 控制机制，不是保证所有 CDN 都禁用缓冲的通用标准；还要检查代理是否忽略该头、是否存在其他缓冲层。[N5]

对于压缩，先测是否影响分片及时送达。可在拥有明确路径的实验范围暂时停用相关压缩再对比，不对整个站点关闭所有压缩。若使用心跳，应使用协议与应用支持的无业务副作用形式，并确认客户端接受；心跳也不能改变所有厂商的总时长上限。

7.5 机器客户端与安全挑战

程序客户端可能不能完成需要浏览器执行的挑战；但发生网络错误并不自动证明 CDN WAF 拦截。

按以下顺序取证：

1. 保存失败时间、请求标识、HTTP 状态及 Content-Type。
2. 判断收到的是业务 JSON、HTML 挑战页，还是根本没有 HTTP 响应。
3. 在 CDN 安全事件中按时间与标识查具体命中模块。
4. 再关联源站与应用日志，确认请求是否已到达。
5. 只调整已证实的误报规则，保留鉴权和业务限流。

“观察/评估”通常只作用于所设置的模块，不是整条安全流水线的全局放行。免费版没有例外能力时，采用账号实际支持的最小调整、隔离接口域名、选择其他通过验收的方案，或评估套餐；不要寻找并不存在的开关。

7.6 一个低负载流式测试方法

先准备一个脱敏、无副作用、符合接口文档的测试请求体，例如保存为 request.json。不要把本文文件名理解为特定 API 格式。

在受控目录创建本地 curl 配置保存低权限测试认证信息，避免把 Key 直接写入共享脚本。创建前先执行 umask 077，再用本地编辑器写入配置，防止文件创建到 chmod 之间权限过宽：

header = "Authorization: Bearer YOUR_TEST_API_KEY"

保存为 api-test.curl 后限制权限：

chmod 600 api-test.curl

确认占位符已经在私下替换为低权限测试凭证，再调用一个实际存在的接口：

curl -q --config ./api-test.curl \
  --noproxy '*' \
  --no-buffer --show-error \
  --connect-timeout 10 --max-time 300 \
  --dump-header ./api-response.headers \
  --header 'Content-Type: application/json' \
  --data-binary @request.json \
  'https://api.example.com/YOUR_STREAM_PATH'

这是 POST 示例；其他方法按服务文档改。不要让 curl 自动跟随跨主机名跳转并携带秘密。配置文件、响应头与终端输出均可能敏感，不公开，不使用 -v 后直接分享完整日志。[CURL1]

--no-buffer 只减少 curl 自身输出缓冲，不能证明上游无缓冲。--max-time 300 是本次客户端测试的总时长上限，也不是生产最佳值。

验收至少包含：正常小请求、合理慢首字、持续流、完整结束、错误鉴权；按实际负载重复少量样本。不能用一次 200 判定整个流完整。

7.7 不要盲目重试写请求

支付、创建订单、扣减额度及任务提交可能不是幂等操作。失败时先确认服务端是否已执行；只有应用具备幂等键或官方明确允许时，才设计自动重试。也不要用 CDN 挑战绕过来替代正确的鉴权设计。[H2]

本章完成标准：接口不会误入共享缓存，失败可定位到层，流式业务能及时输出并完整结束，写操作不会因错误重试重复执行。

---

第 8 章　服务端渲染、CMS 与会话型网站

8.1 哪些网站适用

只要同一 URL 的内容可能随登录状态、权限、会话、购物车或用户而变化，就需要本章的方法。WordPress、其他 CMS、论坛、会员站、电商和带用户中心的业务站都是例子。

服务器用 PHP、Java、Python 或 Node.js 并不决定能否缓存；关键是响应能否安全复用给另一个请求者。

8.2 先建动态排除清单【必须】

功能	排除内容	如何确认
登录与会话	登录、登出、认证回调、账户	查看实际请求路径与会话 Cookie
管理	后台、预览、编辑、发布	测试账号完整操作流程
交易	购物车、结账、订单、支付	测试环境确认行为
个性化	收藏、通知、私有内容、会员页面	两个身份访问同一地址
动态接口	AJAX、REST、搜索或个性化推荐	开发者工具查看请求
请求条件	Authorization、会话 Cookie、预览等参数	应用文档与实际响应

保守起步可让全部带会话或认证的请求绕过共享缓存。即使误伤少量可公开缓存的资源，通常也比先缓存私有页面再补洞更容易控制。后续优化应逐项证明安全。

8.3 WordPress 只是一个转换示例

WordPress 中可先检查：

• /wp-admin/ 与 /wp-login.php。
• /wp-json/、/wp-admin/admin-ajax.php 与插件增加的接口。
• 预览、搜索、评论相关路径与参数。
• 登录 Cookie 前缀 wordpress_logged_in_ 及实际启用插件的会话标记。[WP1]

这不是完整的所有插件排除表。电商、会员或缓存插件还会改变行为。路径大小写、前缀与正则的语法应按对应平台确认；例如不能把“路径包含 wp-admin”误当成严格的路径边界。

迁移到其他 CMS 时，将这些路径和 Cookie 全部替换为那套系统的值。不要只改域名就套用。

8.4 第一步只缓存已证明公开的静态资源【建议】

安全的起步规则可以是：

主机名 = www.example.com
AND 方法 = GET/HEAD（平台支持时显式限制）
AND 路径属于已确认的公开资源目录
AND 不属于动态、私有或签名下载范围
动作：遵循源站缓存策略；必要时为该公开目录设置有依据的边缘 TTL

与“所有 .js/.png 都缓存”相比，明确公开目录更可控。动态应用可能有伪装成静态后缀的路由；私有图片也仍然是私有数据。

示例起点：版本化、不会原地覆盖的公共资源可用较长 TTL；普通公开图片先选择与你的更新频率相符的较短 TTL。不要把统一 30 天当成性能保证。

默认保留查询参数。例如 theme.css?ver=2 与 theme.css?ver=3 可能是不同版本。只有确认某些参数纯属跟踪、不会改变内容时，才按明确名单忽略；签名、权限、分页、语言等参数不能随手删掉。

8.5 公开 HTML 缓存是可选进阶

先满足下面条件：

• 页面对未登录用户确实一致，不含个人状态或敏感令牌。
• 已排除登录、预览、管理、交易、接口与其他动态请求。
• 有内容发布后的刷新机制。
• 明确查询参数、语言等变体如何进入缓存键。
• 已理解平台的强制缓存行为，不覆盖源站对私有内容的声明。

才可为明确的公开页面集合测试较短缓存，例如 5 分钟；若发布频率和刷新机制允许，再延长。5 分钟是本文的实验起点，不是每个站点的推荐值。

不要只创建 Host = www.example.com → 全部缓存，然后假设另一条排除规则总会挡住。必须确认各平台最终的规则优先级与请求行为。

Set-Cookie 也不是跨所有代理实现的自动不缓存保证。HTTP 标准本身没有把它当成绝对禁存标志；安全边界应由明确策略和厂商实际行为共同保证。[H1]

8.6 安全误报不要靠后台全局放行

如果发布技术文章时遇到 403：

1. 找到具体失败请求，不只看编辑器界面。
2. 查安全事件和命中规则。
3. 判断它是业务权限拒绝、CSRF 失败还是 WAF 误报。
4. 必要时限制到具体动作、路径或规则做例外，仍保留应用登录与权限检查。

不提前让所有 /admin 或整个主机名跳过所有安全模块。

8.7 缓存与身份隔离验收【必须】

准备匿名窗口、用户甲、用户乙和管理员：

• 同一地址得到各自正确内容，互不出现对方账户与状态。
• 登录后刷新、登出后再访问，状态正确。
• 发布或更新内容后，按预期刷新。
• 预览、评论、表单、购物车等实际功能正常。
• 正文、会话相关响应头与实际身份状态必须同时正确；特别检查未把某个用户的 Set-Cookie 从共享缓存重放给另一身份。仅正文一致或正确不足以证明隔离通过。[H1]

清除边缘缓存通常不会清除所有客户端已保存的数据；浏览器缓存策略与版本化发布也要一起设计。

本章完成标准：公开内容能按预期复用，动态和不同身份内容保持隔离，发布更新可控。

---

第 9 章　SPA、在线编辑器与富交互前端应用

9.1 为什么不能把它当成“纯静态站”

React/Vue 应用可能大量加载 JS、CSS 和字体，但登录、编辑、保存、导出、上传及分享仍由后端处理。在线简历系统只是其中一种；管理台、设计工具、在线文档与 SaaS 控制台同样适用。

将整个主机名强缓存，会把业务接口、私有文件和 HTML 入口一并拖进错误策略。应拆成四层：

层	示例	起步原则
公开版本化资源	/assets/app-<hash>.js	确认公开且 URL 随内容变化后再长缓存
HTML 入口	/、前端路由入口	短缓存或重新验证，确保更新及时
动态接口	登录、编辑、保存、任务	按第 7 章处理
私有文件	导出文档、个人附件、签名下载	单独设计权限与缓存，不按扩展名强缓存

9.2 先核对实际资源目录

打开浏览器开发者工具的 Network：

1. 清楚区分 HTML、JS/CSS、字体、图片与 Fetch/XHR。
2. 查看失败资源的实际 URL、状态码与返回 Content-Type。
3. 找出真正的公共静态目录。
4. 看资源文件名是否随内容改变，而不是只看名字里有一串字符。
5. 确认下载与接口不混在同一路径。

不要把任何带 hash 的文件都认定为公共资源：私有文件也可能使用内容哈希命名。

9.3 静态资源配置示例【建议】

满足“公开、版本化、同 URL 不覆盖更新”后，源站可采用如下示例策略：

Cache-Control: public, max-age=2592000, immutable

这里 2592000 秒为 30 天的演示值。immutable 表示有效期内不期望内容变化，不是身份授权机制；不适用于原地覆盖的同名文件。[H3]

在对应 CDN 中，将规则限定到已核实的主机名与公共资源目录，优先遵循源站。确需自定义 TTL 时，分别考虑边缘缓存和浏览器缓存，避免把调试中的全量强缓存留在生产。

9.4 HTML 入口与版本发布

公开、非个性化入口可以先采用重新验证策略示例：

Cache-Control: no-cache

含会话或敏感数据的入口则需要更严格策略，不能照抄上述示例。对 Vite 等版本化构建，旧页面在资源已删除时可能出现动态导入失败；官方部署说明也提醒避免让缓存 HTML 引用不存在的资源。[APP1]

推荐的发布顺序是：

1. 上传新版本静态资源。
2. 确认资源可访问且 Content-Type 正确。
3. 发布引用新资源的 HTML。
4. 按范围刷新 HTML 缓存。
5. 保留旧资源至少覆盖预定的旧页面与会话兼容窗口。
6. 出现问题时回滚 HTML，并确保旧资源仍可用。

不要先删除旧资源，再把还在 CDN 或浏览器中的旧 HTML 留给用户。

9.5 导出、上传和任务处理【有对应功能时必须】

PDF 导出可能是：直接返回文档、提交任务后轮询、或返回签名下载地址。三者的超时、缓存与权限不同。

• 上传：核对请求体限制、客户端时长、应用处理及允许格式。
• 同步导出：核对整条链路超时，不只调某一个 CDN。
• 异步导出：验证任务权限、状态接口和结果有效期。
• 下载：验证未授权、不同身份与过期链接，不让私有结果进入公共缓存。

这里列的是需要你确认的检查项，不假设每个在线编辑器都支持相同功能或拥有相同上限。

9.6 完整验收【必须】

• 新用户首次访问能否完整加载，而不是只测试本机二次刷新。
• 前端深层路由直接打开和刷新是否正常。
• 登录、编辑、保存、重新载入的数据是否一致。
• 上传、导出、分享与权限控制是否正常。
• 更新版本后是否引用新资源，旧会话是否仍可用。
• 静态资源是冷缓存、CDN 命中还是浏览器命中，分开记录。

可选预热只作用于确认公开的少量关键资源；不要预热需要登录的页面或私有下载，也不通过高并发请求制造负载。

本章完成标准：首次访问正常、业务功能完整、私有内容不泄露，而且新旧版本切换不会制造白屏。

---

第 10 章　根域名、HTTPS 与规范重定向

10.1 根域名要从一开始就列入清单【必须】

不要只测试 www.example.com、api.example.com 和 app.example.com。用户直接输入 example.com 时，会先访问另一个主机名；DNS、接入配置和证书都要覆盖它。

以下三种设计均可选择，但同一时刻要清楚实际采用哪一种：

设计	DNS 与代理	跳转处理
保留 Cloudflare 根入口	根记录保持已验证的橙云代理路径	使用 Cloudflare 重定向规则，或已验证的源站跳转
根入口交给 ESA	@ 仅 DNS CNAME 到根域名实际分配的 ESA 目标	ESA 边缘跳转，或正确回源后跳转
根入口交给 EdgeOne	@ 仅 DNS CNAME 到根域名实际分配的 EdgeOne 目标	EdgeOne 边缘跳转，或正确回源后跳转

若根域名只由一家 CDN 接收，不要求另一家重复配置；若 DNS 分流让两家都可能接收，则两边都必须可用。不要把根记录指向 www 的 CDN 目标后，就以为 CDN 自动认识 example.com。

10.2 推荐结果：一个明确的规范目标

对于网页示例，目标为：

https://example.com/articles/demo?lang=zh
                   ↓
https://www.example.com/articles/demo?lang=zh

除非业务明确要求丢弃，否则保留路径和查询参数；不要把所有文章入口都跳回首页。固定规范目标主机名，避免从未经信任的请求参数构造跳转主机。

在 Cloudflare，可到规则中的重定向规则/Single Redirects，匹配根主机名，使用支持保留路径的动态目标，并选择保留查询字符串；当前向导的字段以官方步骤为准。[CF8]

在 ESA/EdgeOne，同样选择平台的 URL 重定向能力，填固定目标主机与 HTTPS；需要动态保留的部分使用该平台支持的变量，不把 Nginx 的 $request_uri 原样填进云控制台。两家具体入口见平台章节。

先用临时重定向验证，确认路径、参数和业务都正确后，再按需要发布永久重定向。301/308 可能被客户端缓存，改错后不是只刷新 CDN 就能让所有用户立即恢复。[H2]

10.3 源站跳转示例【仅源站确实负责跳转时】

在已有、证书和校验配置完整的根域名 server 中，跳转逻辑可写为：

return 301 https://www.example.com$request_uri;

这只是逻辑片段，不是缺省完整站点。$request_uri 保留原请求 URI；固定 www.example.com 避免把任意 Host 拼入目标。[N2]、[N7]

如果已在边缘完成跳转，正常路径无需回源，因此该跳转的性能不取决于 HTTP/2 回源开关。

10.4 强制 HTTPS 是另一件事

协议升级把 HTTP 改为 HTTPS；规范跳转把根主机名改为 www，两者不能互相替代。合理设计可合并跳转，减少多次往返。

HTTP 首次请求若在到达边缘前已经不可达，边缘就不能凭空发出可被客户端收到的重定向。HTTPS 也不意味着网络路径“绝对无法拦截”。不要用强制 HTTPS 解释所有蜂窝网络故障。

接口客户端直接配置 HTTPS 地址，不把含认证信息的 POST 先发到 HTTP 再依赖重定向。301/302 对 POST 的处理与 307/308 的保留方法语义不同，必须按客户端及接口约定设计。[H2]

10.5 重定向验收矩阵

请求	示例期望
http://example.com/	转到 HTTPS 的规范主机名
https://example.com/	证书通过，转到规范主机名
http://www.example.com/	转到 HTTPS 的 www
https://www.example.com/	正常页面，不循环
带路径和参数的上述入口	路径和必要参数按约定保留

HTTPS 入口必须先通过 TLS，再有资格谈 HTTP 跳转；使用不匹配证书时，用户可能根本收不到 301。

本章完成标准：根域名没有遗漏、TLS 正确、跳转不降级、不循环且不意外丢路径。

---

第 11 章　HTTP/2、HTTP/3、压缩与其他开关

11.1 两个 HTTP/2 方向要分开

客户端 ── 客户端 HTTP/2 ──> 边缘 ── HTTP/2 回源 ──> 源站

客户端与边缘协商什么，不决定边缘与源站使用什么。HTTP/2 支持多个流，但不意味着所有请求永远只共用一条连接，也不意味着一个慢流必然阻塞所有流。RST_STREAM 与整连接关闭不是一回事。[H4]

11.2 使用“可验收基线”，不用全局神奇开关表

下表是本文的实施建议，不是两家厂商共同承诺的默认值：

功能	起步方法	开启或调整前要验证
客户端 HTTP/2	【建议】支持时启用并测试	TLS、客户端兼容、实际协商结果
HTTP/2 回源	【可选】保留当前已验证基线，单变量对比	源站协议、回源 TLS、产品超时和回退机制
HTTP/3	【可选】按支持情况试用	UDP 可达、客户端回退、真实业务结果
强制 HTTPS	网页【建议】，接口使用 HTTPS【必须】	边缘证书、回源协议、跳转链
Gzip/Brotli 等	公开文本资源【建议】按协商压缩	MIME、已有压缩、CPU 与实际传输体积
流式压缩	【条件评估】不照搬静态策略	首字和分片是否被延后
IPv6	不默认开或关，按可用链路决定	DNS AAAA、证书、客户端路径、回源方向
OCSP 装订	【可选】按证书与平台支持配置	不承诺固定减少多少毫秒
HSTS	初次迁移【建议暂缓】	所有受影响主机名 HTTPS 长期稳定
WebSocket/gRPC	【条件必需】业务确实使用时配置	套餐、协议、源站和超时
客户端 IP 传递	日志/风控需要时【条件必需】	可信代理范围与防伪造处理

HTTP/3 的使用与回退不代表弱网一定提速；分别验证目标网络，不能把开启作为业务成功的替代品。[H5]

11.3 HTTP/2 回源怎么决定

采用这个实验顺序：

1. 固定测试网络、接口、请求体和时间窗口。
2. 记录当前已验证协议的业务成功率与耗时。
3. 查本平台 HTTP/2 回源要求、适用协议、超时与回退行为。
4. 确认源站在正确 SNI 与证书条件下支持 h2。
5. 小范围改变一个开关。
6. 重复相同的低负载业务样本，比较错误、首字、总耗时与资源占用。
7. 改善不明确或出现异常就恢复原值。

阿里云关于特定不缓存场景回源变慢的文档，建议关闭 HTTP/2 回源做对比；这是排障方法，不是所有 API 永久关闭的定律。[ESA-H2]

EdgeOne 应按它自己的官方回源协议与超时规则判断，不能从 ESA 的案例推导它必须开或必须关。[EO-TIMEOUT]

11.4 别把 X-Forwarded-For 当成自动可信

正确链路应说明：

• 哪个可信边缘写入或追加哪个客户端地址头。
• 源站只信任哪些直接连接方。
• 多层代理时，从哪一端按什么规则还原地址。
• 谁负责限流，使用的地址是否可被客户端伪造。

Nginx 的 set_real_ip_from、real_ip_header 和递归处理需要配合受信任代理范围。不要配置“信任全互联网”，再用任意请求里的 X-Forwarded-For 做安全决策。[N6]

如果某产品不能提供可维护的可信边界，应改用它支持的认证和接入设计，或不将还原后的地址直接用于关键授权。

11.5 HSTS 要考虑回退窗口

HSTS 会让浏览器在后续访问中坚持 HTTPS。启用 includeSubDomains 或 preload 会扩大影响，不能在只验证了 www 时就对全域发布。先确认根域名、业务子域和历史入口全部符合预期，再评估策略与生命周期。[CF9]

11.6 在两家平台里具体去哪里设置

下面只说明操作落点。先按前文决定是否需要，不把表格当作必须全部开启的清单。全局操作会影响多个主机名；首次迁移优先缩小到当前验证范围。

配置	ESA 操作	EdgeOne 操作
客户端 HTTP/2	速度和网络 → 优化 → 速度优化 → HTTP/2	站点加速 → 网络优化 → HTTP/2；按主机名配置时用规则引擎 HTTP/2 动作
HTTP/2 回源	同页的独立 HTTP/2 回源开关；需细分时核对网络优化规则	规则引擎 → HOST 条件 → HTTP/2 回源 → 保存并发布
强制 HTTPS	SSL/TLS → 边缘证书 → 强制 HTTPS；需细分时查对应规则	站点加速 → HTTPS → 强制 HTTPS；也可在规则引擎按 HOST 配置
资源压缩	速度和网络中的速度优化页签 → Gzip/Brotli/Zstd；资源压缩文档当前也可能把父入口称为速度监测	站点加速 → 文件优化 → 智能压缩；按主机名配置时使用对应规则动作

ESA 协议开关见 [ESA-PROTOCOL]，强制 HTTPS 见 [ESA-HTTPS]，资源压缩见 [ESA-COMPRESS]；EdgeOne 对应见 [EO-CLIENTH2]、[EO-H2]、[EO-HTTPS]、[EO-COMPRESS]。

HTTP/2 不应对所有业务无条件开启。EdgeOne 客户端 HTTP/2 文档提示 512 KB 流控窗口相关的大文件上传性能限制；这不是“免费版最大文件 512 KB”，也不是“下载限速 500KB/s”。存在附件上传、图片输入或大请求体时，按该文档与实际上传测试决定协议基线。[EO-CLIENTH2]

压缩不等于所有内容都压缩。按客户端 Accept-Encoding、响应 Content-Type、大小、已有 Content-Encoding 和平台限制协商；不能因为开关开了就承诺固定比例缩小。ESA 资源压缩有大小及源站响应条件；EdgeOne 的智能压缩与内容压缩是不同能力，后者有额外开通条件，不能互相代称。[ESA-COMPRESS]、[EO-COMPRESS]、[EO-CONTENTCOMPRESS]

验证用已确认公开的小型 JS/CSS 资源，对比 Content-Encoding 与实际传输，避免拿已压缩图片判断文本压缩效果。流式响应则重复第 7 章的首字、分片与结束测试，不从静态文件结果推导。

本章完成标准：每个开关有业务理由、适用方向、来源与回滚点，不靠开启数量衡量优化效果。

---

第 12 章　切换前测试、小步上线与回滚

12.1 先检查测试工具与代理环境

curl --version

查看是否支持你要验证的 HTTP/2/HTTP/3，不支持时换用具备相应构建能力的工具，不要把工具不支持误当服务器不支持。[CURL1]

记录系统代理、浏览器代理和 TUN 状态。--noproxy '*' 可避开 curl 的常规代理使用，但不能保证绕过系统级隧道、透明代理或 DNS 劫持。

如果解析得到测试/保留地址，先确认是否来自代理 Fake-IP。不要把代理虚拟地址当成厂商公网边缘地址，也不要承诺 dig @某公共DNS 一定能绕过透明劫持。

12.2 优先临时绑定，不永久改 hosts【建议】

从目标产品控制台复制本主机名的实际 CNAME，解析并选择用于本次测试的真实边缘地址。它只是当下测试点，不是长期固定 IP。

dig +short YOUR_CDN_CNAME A

将下例里的 YOUR_EDGE_IP 替换为刚取得并确认的公网地址：

curl -q --noproxy '*' \
  --resolve 'www.example.com:443:YOUR_EDGE_IP' \
  --connect-timeout 10 --max-time 30 \
  --silent --show-error \
  --dump-header ./edge-check.headers \
  --output /dev/null \
  --write-out 'code=%{http_code} peer=%{remote_ip} http=%{http_version} total=%{time_total}\n' \
  'https://www.example.com/'

--resolve 只为这次命令设置指定主机名和端口的地址，URL 仍保留业务名，便于按正确 Host、TLS SNI 和名称进行验证。不要改成直接访问 https://IP 后只补 Host；那不是等价的 TLS 名称测试。[CURL1]

命令以 curl -q 开头，避免自动读取默认 curl 配置；-q 必须是第一个选项。显式指定的测试配置中也不要添加 insecure 或 location。这里没有 -k：上线验收不能忽略边缘证书错误。也没有自动 -L，先逐跳检查重定向；第二跳是另一个主机名时，必须单独准备它的测试映射，不能以为第一条 resolve 覆盖所有域名。

静态资源可直接这样验证；动态与流式请求则把同样的 resolve 加到对应的真实业务命令中。不要往边缘测试请求里手工加入回源秘密，否则会掩盖“CDN 自己未注入 Header”的配置错误。

12.3 如果一定要用 hosts

先备份，只增加可识别的本次测试块，逐个主机名核对。测试完仅删除自己新增的行。

不要执行“删除所有包含 example.com 的行”这类宽泛清理命令，因为同一文件可能有本次之前的有效配置。清理后确认系统和浏览器不再固定到测试地址。

12.4 获取正常链路的分阶段耗时

对无副作用的公开 URL：

curl -q --noproxy '*' \
  --connect-timeout 10 --max-time 30 \
  --silent --show-error --output /dev/null \
  --write-out 'code=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  'https://www.example.com/'

这些是自请求开始累计的时间：例如 TLS 阶段的近似增量是 time_appconnect 减 time_connect；不要把每个字段直接称为互不重叠的阶段时长。连接复用、代理、缓存与协议也会影响解释。[CURL1]

time_starttransfer 是首个响应字节时间，不自动等于 AI 的第一个业务 token；流式首字需要在实际客户端或事件处理程序另行记录。

12.5 正式修改 Cloudflare 业务记录【必须按台账操作】

先只切一个已经验收的主机名。

1. 打开 Cloudflare，对应站点 → DNS → 记录。
2. 保存该名称现有的记录值、代理状态和 TTL。
3. 检查同名旧 A/AAAA 与其他冲突记录。按确认的接入设计修改/移除冲突项，不碰其他名称。
4. 将业务记录改为 CNAME。
5. 名称填对应前缀，例如 www；目标逐字复制目标 CDN 为该主机名分配的地址。
6. 代理设为仅 DNS（灰云）。
7. 保存，分别验证权威答案、递归答案、TLS 和实际业务。

名称	类型	目标	代理状态
www	CNAME	YOUR_WEB_CDN_CNAME	仅 DNS
api	CNAME	YOUR_API_CDN_CNAME	仅 DNS
app	CNAME	YOUR_APP_CDN_CNAME	仅 DNS

这些记录不要求同时切换，也不要求都指向同一厂商。TXT、MX、验证 CNAME 和其他未迁移业务继续保留。不要复制样例里的占位符进真实 DNS。[CF2]

根域名如果继续 Cloudflare 代理，保持已验证的根记录与跳转；如果交给其他 CDN，按第 10 章先添加根主机名及证书，再处理 @ CNAME。

12.6 不要把 DNS 变化当即时开关

DNS 缓存、客户端连接与现有会话可能让旧新链路短期并存。降低 TTL 需要在原 TTL 到期后才对已有缓存体现效果，不能改完就假设全网立即刷新。Cloudflare 对代理记录 TTL 与本地缓存也有明确说明。[CF1]

在过渡窗口中：

• 旧平台继续保留必要证书和配置。
• 新旧链路均应能处理该名称的正常请求。
• 观察实际错误分布，不因少数节点仍走旧平台就反复改 DNS。
• 不承诺“10 秒生效”或“全球 15 分钟结束”。

12.7 回滚要恢复完整路径

如果原来是 Cloudflare 橙云 A 指向源站，回滚需要恢复：

1. 原记录类型、地址与代理状态。
2. Cloudflare 边缘证书、回源 TLS 模式和业务规则。
3. 当前源站 Header 校验所需的 Cloudflare 请求头规则。
4. 原回源范围的防火墙可达性。
5. 相关缓存、重定向与业务验收。

只把 CNAME 改回源站 A，却留在灰云，可能导致直连暴露、Origin CA 不受信任或缺失回源 Header。不能把它当成无损恢复。

优先回滚发生问题的主机名或新规则，不恢复无关配置。回滚也受缓存影响；不要立即删除新平台配置，让已解析到新地址的请求突然无服务。

本章完成标准：每个已切换入口通过实际业务验证，原值可恢复，过渡期新旧路径不会因提前清理而失效。

---

第 13 章　常见故障与证据驱动的排查方法

13.1 每次只回答一个层级的问题

域名是否解析
  → 到达哪个地址/代理
  → TLS 是否通过
  → HTTP 返回了什么
  → CDN 是否命中缓存或安全规则
  → 源站是否收到请求
  → 应用与上游是否完成业务

保存“失败样本”，而不只保存成功样本。至少记录时间与时区、测试网络、主机名、方法、错误码、请求标识和脱敏后的错误内容。不要分享 Authorization、Cookie、请求中的个人信息或回源秘密。

13.2 根域名打不开，www 正常

依次检查：

1. 根记录到底指向哪家平台。
2. 那家平台是否添加 example.com 这个主机名。
3. 边缘证书是否包含根域名。
4. 是边缘跳转还是回源跳转。
5. 如回源，Host/SNI、虚拟主机、回源 Header 是否包含根域名。
6. Location 是否为正确 HTTPS 地址，是否循环或丢路径。

不能用“www 200”证明根域名正常，也不能靠 CNAME 到 www 解决 CDN 未接入根名称的问题。

13.3 403、HTML 挑战页与程序客户端失败

• 先看响应是谁产生：应用、源站代理还是 CDN。
• 关联安全事件，查具体规则与处置。
• 检查是否本来就是无效 Key、权限或 CSRF 失败。
• 命中安全规则后只处理已证实的误报，不凭“非浏览器客户端”推断一定是 Bot。
• 某模块处于评估状态，不代表其他模块没有拦截。

13.4 5xx、连接断开和超时

相同数字在不同平台可能含义不同。先确认厂商，再查对应错误说明和请求标识：

证据	下一步
根本未连到边缘	查 DNS、网络路径、客户端代理与端口
边缘 TLS 失败	查接入名称、证书部署、协议
源站未收到请求	查边缘规则、安全事件、回源解析、防火墙和 SNI
源站立即拒绝	查回源校验、虚拟主机与应用权限
已有部分流式数据再断开	查最后数据时间、客户端/代理/上游错误与取消
应用完成但客户端失败	查边缘/客户端链路及响应格式

一个 520 不能单独证明缺 Header，一个 530 也不该跨厂商套用同一解释。先记录实际错误页和日志，再修改。

13.5 Ping 丢包是否代表业务丢包

Ping 使用 ICMP。节点不回应可能来自协议过滤、限速或真实网络问题；仅凭 Ping 不能断言 HTTPS 不可用，也不能反过来保证 TCP 丢包率为零。

使用低频 TCP 与真实 HTTPS/业务请求辅助判断。macOS 等提供 nc 的环境可验证某个已确认边缘地址的端口：

nc -vz -w 5 YOUR_EDGE_IP 443

它只证明当次 TCP 连接是否建立，不验证 TLS、Host、应用或流式完整性。十次成功也不能推出网络永远无丢包。

13.6 RTT 更低，为什么 API 或页面仍然慢

拆开比较：

• DNS 是否慢或受代理影响。
• TCP/TLS 是否重复建立。
• 首字前应用是否排队或等待上游。
• 资源是否缓存未命中、体积过大或依赖串行加载。
• 流式是否被缓冲，客户端是否等待完整响应。
• 路由与拥塞是否只出现在特定网络或时段。

RTT 从 200ms 降到 50ms 不自动代表整个页面或生成任务快四倍。也不能凭 200ms 就确定绕行了哪个国家；路由推断需要相应网络证据。

13.7 DNS 回滚后出现 NXDOMAIN 或 SERVFAIL

基础路线没有修改 NS，出现问题时先核对具体记录；出现 SERVFAIL 时，即使 NS 未变，也应检查 DNSSEC 签名及验证链。确实迁移过权威 DNS 时，再重点核对父区委派、新旧权威服务、DS 衔接与缓存。[CF15]

• NXDOMAIN：确认哪台权威/递归服务器回答，记录是否真的存在，是否仍有负缓存。
• SERVFAIL：检查 DNSSEC 验证、委派与权威服务可达性，不一概归为 TTL。
• 刚改回 NS 就删旧 DNS 区：仍使用旧委派的递归解析器可能收到错误。

应恢复仍在使用的合法权威服务和已验证业务记录，而不是随便添加一条直连源站 A 就当作修复。[CF10]、[CF11]

13.8 遇到套餐不可用功能

保留准确的限制记录：产品站点、套餐、日期、功能名称与界面提示。

• 例外规则不可用：不把观察、基础规则或全局关闭冒充完全等效替代。
• 网络优化不能开启：先看套餐、付费、区域与实名等实际条件，不归因于一个因素。
• 某项日志不可用：降低可以作出的结论强度，不能凭空补出命中模块。

13.9 一个合格的故障记录

现象：什么操作失败，失败比例如何
环境：时间、网络、客户端与代理状态
已知设置：实际生效配置，不是记忆中的默认值
原始证据：脱敏响应、请求标识和可关联日志
候选原因：明确哪些仍是假设
验证动作：一次改变一个因素
修复结果：业务样本是否恢复
回归范围：其他身份、路径、网络是否受影响

本章完成标准：可以说明证据支持哪个结论、尚不能排除什么，而不是每次都宣布找到新的“唯一根因”。

---

第 14 章　可选进阶：多线路 DNS 与境外 Cloudflare

14.1 什么时候才需要

只有当你明确要求同一主机名在不同地区、运营商或故障状态下进入不同 CDN，并愿意维护多套策略时，再设计这条路线。

按主机名改灰云 CNAME 不是 GeoDNS；多个同名目标也不等于有健康检查的自动故障切换。DNS 调度常依赖递归解析器地址与产品的 ECS 等能力，不能保证与每个终端实际位置完全一致。[DNS2]

14.2 迁移 NS 与保留 Cloudflare CDN 是不同问题

把权威 DNS 移走后，不能随便填写一个 .cdn.cloudflare.net 地址就认为原免费代理仍受支持。Cloudflare 官方 CNAME partial setup 的可用套餐和限制需要单独满足；本次核对的文档列为 Business 或 Enterprise，不是免费版普遍能力。[CF12]

Cloudflare for SaaS 也不是同一个功能：它涉及 SaaS 提供方 zone、回退源/自定义源、流量目标、逐主机名验证与证书。官方要求正确建立回退源，且主机名与证书验证都完成；不要沿用“在即将迁走的 zone 随手添加一个 origin 就行”的简化步骤。[CF13]

本章提供设计边界与迁移顺序，不给未经账号、域名关系与资格核验的 SaaS 一键配方。若不满足条件，继续使用基础路线，而不是强行拼接记录。

14.3 真正实施前的独立检查单

1. 选择支持所需线路、默认兜底与费用的权威 DNS。
2. 确认每个主机名在每一家可能接收请求的 CDN 都已接入、证书与回源均可用。
3. 完整导入必要记录，逐项核对 TXT、MX、CAA 与证书委派。
4. 使用该域名实际获分配的 NS，不复制示例或其他域名的服务器名称。
5. 按 DNS 服务商的迁移流程处理 DNSSEC/DS，避免失配；不把禁用 DNSSEC 当成所有迁移的固定第一步。
6. 在切换前分别直接查询新权威服务器，验证区内容。
7. 明确默认、地区、运营商与故障兜底的覆盖关系。
8. 设置监控和可恢复的旧配置后再修改委派。
9. 新旧权威服务在过渡窗口都持续提供正确答案，观察后才退役旧服务。

14.4 回滚别提前删旧区

改回 NS 后，已有递归缓存不会立即全部更新。保存旧服务直至可以确认不再需要；若启用了 DNSSEC，回滚也要同时保持正确的验证链。旧区被删时，不用未经验证的源站直连记录“止血”，否则可能只修 DNS、却破坏 TLS 和回源防护。[CF10]、[CF11]

本章完成标准：这是一套单独设计、测试和回滚的方案，而不是基础教程的最后一个顺手动作。

---

第 15 章　附录：把教程变成自己的配置清单

附录 A　每个主机名一张配置卡

以下模板填写真实值后就是私有运维资料，不要作为公开教程附件。

业务主机名：
业务特征：公开静态 / 会话页面 / 私有接口 / 流式 / 上传导出 / 跳转
权威 DNS：
目标 CDN 与套餐：
业务 CNAME（从自己的控制台复制）：
边缘证书名称、状态与到期：
续期方式与所需 DNS 验证记录：
源站地址与端口：
回源协议：
回源 Host / SNI：
源站证书与验证方式：
回源校验方式（只记录秘密引用，不粘贴秘密）：
动态/私有内容排除：
公开可缓存资源：
边缘 TTL / 浏览器 TTL / 缓存键：
安全规则与有依据的最小例外：
各层超时与适用协议：
客户端 HTTP/2 / 回源 HTTP/2 / 其他协议：
真实客户端 IP 信任边界：
上线时间与测试网络：
原记录、代理状态和恢复方法：

附录 B　按业务选择规则，不按软件选开关

特征	最先做的配置	可选优化	不能省略的验证
私有动态接口	明确绕过共享缓存、鉴权与合理限流	精确缓存已证明公共的只读查询	身份、写入与错误响应
流式/长任务	分层超时、输出及时性、错误证据	协议复用、合适心跳与任务异步化	首字、分片、完整结束
会话型页面	动态排除与多身份隔离	公开 HTML 短缓存与刷新机制	登录/登出、发布和交易
公开版本化资源	正确资源路径与响应头	长 TTL、压缩、少量预热	首次访问、更新与回滚
私有下载	权限、有效期与共享缓存边界	按受控业务需求设计下载	未授权、过期与身份隔离
跳转入口	接入名称、TLS 和规范目标	边缘直接跳转	全协议入口与 URI 保留

这些配置可以按路径组合在同一网站里；如果不同功能对安全、缓存、超时的要求难以隔离，可以评估拆分主机名，而不是增加一条覆盖整个域名的万能规则。拆分前同时评估 Cookie、跨域、登录与前端配置变化，不只改 DNS。

附录 C　上线前后验收表

基础链路

• [ ] 已备份旧记录、代理状态和规则。
• [ ] 当前 NS 未被基础路线意外修改。
• [ ] CNAME 来自本主机名控制台，不是样例或其他域名。
• [ ] 无冲突的同名旧 A/AAAA，未误改其他业务。
• [ ] TXT、MX、CAA 与证书验证记录完整。
• [ ] 正确主机名的边缘 TLS 验证通过，未使用跳过证书校验验收。
• [ ] 回源地址、端口、Host、SNI、证书和防火墙相互匹配。
• [ ] 启用回源校验的每一条回源路径都能通过。

业务与安全

• [ ] 匿名、测试用户甲、用户乙及管理员没有串内容。
• [ ] 接口鉴权、错误码、写入和回调按业务设计工作。
• [ ] 有流式业务时，首字、分片和结束都通过。
• [ ] 有上传/导出时，大小、时长和权限通过。
• [ ] 静态资源、HTML 与私有内容缓存边界明确。
• [ ] 规则重叠与最终生效行为已验证。
• [ ] 需要安全例外的，有具体事件依据，未盲目全站跳过。

入口与发布

• [ ] 根域名、www、HTTP、HTTPS 和实际路径都测试。
• [ ] 不降级、不循环，不意外丢失路径与必要参数。
• [ ] 新资源先就绪，旧资源有兼容保留窗口。
• [ ] 新用户首次访问与新版本切换正常。
• [ ] 回滚值齐全，过渡期旧平台没有提前删除。

附录 D　公开教程与截图脱敏表

发布前逐项检查：

• [ ] 真实根域名、子域名、源站域名和 IP 已替换。
• [ ] 厂商专属 CNAME、DCV 目标和账号/站点标识已替换。
• [ ] Header 秘密、API Key、Authorization、Cookie、签名 URL 已删除或使用占位符。
• [ ] 私钥、证书上传内容、个人邮箱、用户信息、支付和订单数据未出现。
• [ ] 命令输出、浏览器地址栏、页面侧栏、开发者工具和二维码都已检查。
• [ ] 图片元数据、附件名和文档属性不携带个人路径或身份。
• [ ] 演示参数清楚标注，不伪装成生产实测。
• [ ] 分享日志前检查请求体与响应体，避免包含他人的数据。

最好使用专门演示环境重新截图。密钥如果已经进入公开资料，遮挡截图不等于撤回泄露，应实际轮换。

附录 E　本文保留的经验与舍弃的结论

从多轮实操中真正值得推广的是：根域名不能漏、证书与回源要分层、切换前先测试、动态内容先保护、规则冲突要验收、保留回滚与证据。

本文没有沿用以下说法：

• 某厂商天然永不误拦爬虫或接口。
• 共享 Header 让源站彻底隐身、任何攻击都无效。
• 源站证书在任意 CDN 上自动可信。
• 强制 HTTPS 能绕过一切网络阻断。
• Ping 失败就是业务失败，或几次成功就代表零丢包。
• 超时设为某个数字、HTTP/2 全开或全关就能治好所有故障。
• 免费不限流量等于不限性能、长期保证可用。
• 修改记录后必然立即生效，回滚只需改一个值。

结束语：先让链路正确、身份与数据隔离正确，再优化缓存和协议；一次只改变可观察的一项，并用自己的业务验证结果。这样换一个站点、应用框架或 CDN，方法仍然成立。

---

官方资料索引

以下均为产品、标准或工具的原始文档。索引用于追溯对应机制，不代表厂商为本文每个起步策略背书。网站界面、套餐与上限可能变化，实施时再打开核对。URL 以代码形式保留，便于复制。

Cloudflare

• [CF1] Proxy status：代理与仅 DNS 的边界、代理记录 TTL 与缓存注意事项。https://developers.cloudflare.com/dns/proxy-status/
• [CF2] Manage DNS records：新增、修改与删除记录。https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/
• [CF3] Import and export records：区文件导入导出。https://developers.cloudflare.com/dns/manage-dns-records/how-to/import-and-export/
• [CF4] Create a request header transform rule in the dashboard：请求头设置、覆盖与部署。https://developers.cloudflare.com/rules/transform/request-header-modification/create-dashboard/
• [CF5] SSL/TLS Concepts：边缘与源站 TLS 概念。https://developers.cloudflare.com/ssl/concepts/
• [CF6] Cloudflare origin CA：Origin CA 用途、信任边界与域名覆盖。https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/
• [CF7] Set up CNAME flattening：根域名与验证 CNAME 的扁平化注意事项。https://developers.cloudflare.com/dns/cname-flattening/set-up-cname-flattening/
• [CF8] Create a redirect rule in the dashboard：重定向规则创建与动态目标。https://developers.cloudflare.com/rules/url-forwarding/single-redirects/create-dashboard/
• [CF9] HTTP Strict Transport Security (HSTS)：HSTS 前提与回退风险。https://developers.cloudflare.com/ssl/edge-certificates/additional-options/http-strict-transport-security/
• [CF10] General DNS issues：DNS 失败、NXDOMAIN 与缓存排查。https://developers.cloudflare.com/dns/troubleshooting/dns-issues/
• [CF11] Zone stuck in Pending Nameserver Update：委派、实际分配 NS 和 DNSSEC 检查。https://developers.cloudflare.com/dns/zone-setups/troubleshooting/pending-nameservers/
• [CF12] CNAME setup (Partial)：外部权威 DNS 下接入 Cloudflare 的套餐与条件。https://developers.cloudflare.com/dns/zone-setups/partial-setup/
• [CF13] Configuring Cloudflare for SaaS：回退源、自定义主机名、验证与流量目标。https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/
• [CF14] Full (strict) encryption mode：经过验证的回源 TLS 与证书条件。https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/
• [CF15] Troubleshooting DNSSEC：签名、DS 与验证链异常排查。https://developers.cloudflare.com/dns/dnssec/troubleshooting/

阿里云 ESA

• [ESA1] 添加网站并接入 ESA：接入前提、区域、CNAME 接入及逐名称配置。https://help.aliyun.com/zh/edge-security-acceleration/esa/getting-started/add-your-website-to-esa
• [ESA2] 免费版套餐：性能限制、SLA、规则与证书配额。https://help.aliyun.com/zh/edge-security-acceleration/esa/product-overview/free-plan
• [ESA3] 回源规则概述：回源协议、Host 与 SNI 等分项入口。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/back-to-source-rule-overview/
• [ESA4] SSL/TLS 概述：边缘/回源及源站证书认证。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/ssl-tls-overview/
• [ESA5] 修改回源请求头：ESA 到源站的 Header 转换。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/modify-outgoing-request-header
• [ESA6] 托管 DCV：证书 DNS 验证委派与自动签发/续签。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/managed-dcv
• [ESA7] 默认缓存规则：缓存资格、过期策略与源站响应头处理。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/default-cache-rule
• [ESA8] 规则相关功能的特性说明：规则和全局、位置与子功能的生效关系。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/how-esa-rules-take-effect
• [ESA9] 回源超时时间：七层请求超时、默认、上限及建议。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/configuring-the-back-to-origin-request-timeout-period
• [ESA10] 白名单规则：跳过范围、使用步骤与套餐限制。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/whitelist-rules
• [ESA-H2] ESA 回源慢—HTTP/2 回源：特定场景关闭回源 HTTP/2 的对比排障。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/esa-slow-back-to-source-http-2-back-to-source
• [ESA11] 配置网络优化：IPv6、WebSocket、上传与中国大陆网络接入优化。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/network-optimization
• [ESA-REDIRECT] 请求重定向：动态目标表达式、路径与查询参数保留。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/request-redirects
• [ESA-PROTOCOL] 配置协议优化：客户端 HTTP/2、HTTP/3 与 HTTP/2 回源的独立设置。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/protocol-optimization/
• [ESA-HTTPS] 强制 HTTPS：边缘协议跳转及证书前提。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/force-https
• [ESA-COMPRESS] 设置资源压缩：算法、MIME、大小、协商与操作入口。https://help.aliyun.com/zh/edge-security-acceleration/esa/user-guide/content-compression

腾讯云 EdgeOne

• [EO1] 添加加速域名：主机名、源站类型、Host 与接入配置。https://cloud.tencent.com/document/product/1552/90433
• [EO-ORIGIN] 源站配置相关问题：回源 SNI 与 Host 的关系。https://edgeone.ai/zh/document/67728
• [EO-CERT] 源站证书校验：指定 CA、检查范围、套餐与步骤。https://cloud.tencent.com/document/product/1552/125145
• [EO-HEADER] 修改 HTTP 回源请求头：设置、增加、删除与默认传递头。https://cloud.tencent.com/document/product/1552/71012
• [EO-SSL] 使用免费证书部署至 EdgeOne 域名：DNS 委派、提前签发及续期条件。https://cloud.tencent.com/document/product/1552/90437
• [EO-CACHE] 节点缓存 TTL：缓存功能及规则引擎配置步骤。https://cloud.tencent.com/document/product/1552/70777
• [EO-CACHE2] EdgeOne 内容缓存规则：默认行为、强制缓存与该页所写优先级。https://cloud.tencent.com/document/product/1552/87651
• [EO-RULES] 规则引擎概述：分支、覆盖顺序、中断动作；与缓存专题有口径差异，见正文 6.8。https://edgeone.ai/zh/document/46151
• [EO-TIMEOUT] 回源超时时间：HTTP 应答超时及 HTTP/2 回源例外。https://cloud.tencent.com/document/product/1552/104992
• [EO-H2] HTTP/2 回源：源站兼容、H2C 与 HTTPS 条件。https://cloud.tencent.cn/document/product/1552/71008
• [EO-PLAN] 套餐选型对比（中国站）：功能及安全动作权限。https://cloud.tencent.com/document/product/1552/94165
• [EO-FREE] 免费版套餐使用说明（中国站）：用途、限制、自动降级与 SLA。https://cloud.tencent.com/document/product/1552/118985
• [EO-REDIRECT] 访问 URL 重定向：边缘跳转、Host、路径与查询参数。https://cloud.tencent.com/document/product/1552/71006
• [EO-CLIENTH2] HTTP/2：客户端访问、设置步骤、上传流控提示与统计。https://cloud.tencent.com/document/product/1552/70780
• [EO-HTTPS] 强制 HTTPS 访问：全局/主机名规则与证书前提。https://cloud.tencent.com/document/product/1552/88875
• [EO-COMPRESS] 智能压缩：开关、协商与生效限制。https://cloud.tencent.com/document/product/1552/70748
• [EO-CONTENTCOMPRESS] 内容压缩：与智能压缩的区别、开通和规则条件。https://cloud.tencent.com/document/product/1552/122770

源站、工具与应用

• [N1] Nginx map module：map 上下文与匹配。https://nginx.org/en/docs/http/ngx_http_map_module.html
• [N2] Nginx rewrite module：if、return 与 444。https://nginx.org/en/docs/http/ngx_http_rewrite_module.html
• [N3] Nginx command-line parameters：配置测试与信号。https://nginx.org/en/docs/switches.html
• [N4] Nginx SSL module：TLS 虚拟主机与 ssl_reject_handshake。https://nginx.org/en/docs/http/ngx_http_ssl_module.html
• [N5] Nginx proxy module：缓冲、缓存、读取超时与 X-Accel-Buffering。https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• [N6] Nginx realip module：可信代理与真实客户端地址。https://nginx.org/en/docs/http/ngx_http_realip_module.html
• [N7] Nginx core module：request_uri 等变量。https://nginx.org/en/docs/http/ngx_http_core_module.html
• [CURL1] curl manual：配置文件、resolve、计时、代理、输出与超时选项。https://curl.se/docs/manpage.html
• [AC1] Let's Encrypt — Challenge Types：HTTP-01、DNS-01 与验证委派。https://letsencrypt.org/docs/challenge-types/
• [WP1] WordPress — Cookies：登录 Cookie 与应用行为。https://developer.wordpress.org/advanced-administration/wordpress/cookies/
• [APP1] Vite — Building for Production：动态导入失败、旧资源与 HTML 缓存。https://vite.dev/guide/build.html

HTTP、SSE 与 DNS 标准

• [H1] RFC 9111 — HTTP Caching：缓存控制、共享缓存、认证请求与 Set-Cookie。https://www.rfc-editor.org/rfc/rfc9111.html
• [H2] RFC 9110 — HTTP Semantics：方法、幂等性与重定向。https://www.rfc-editor.org/rfc/rfc9110.html
• [H3] RFC 8246 — HTTP Immutable Responses：immutable 的语义。https://www.rfc-editor.org/rfc/rfc8246.html
• [H4] RFC 9113 — HTTP/2：流、流控、连接与 RST_STREAM。https://www.rfc-editor.org/rfc/rfc9113.html
• [H5] RFC 9114 — HTTP/3：HTTP/3 协议与连接。https://www.rfc-editor.org/rfc/rfc9114.html
• [SSE1] WHATWG HTML — Server-sent events：事件流 MIME 与处理。https://html.spec.whatwg.org/multipage/server-sent-events.html
• [DNS1] RFC 1034 — Domain Names: Concepts and Facilities：CNAME 与 DNS 基础。https://www.rfc-editor.org/rfc/rfc1034.html
• [DNS2] RFC 7871 — Client Subnet in DNS Queries：ECS 与基于网络位置的调度信息。https://www.rfc-editor.org/rfc/rfc7871.html