WordPress 配置 CDN，可以分三步完成：先保证域名记录和源站 HTTPS 正常，再让需要加速的请求经过 CDN，最后检查缓存、内容更新和实际业务。服务商显示“已激活”，只说明接入达到相应条件，不能代替最后的验证。
下面以 Cloudflare 的普通完整 DNS 接入为例，适用于已经正常运行的 WordPress 网站。原来的主机仍存放网站文件和数据库，CDN 在访问链路中提供代理、缓存等服务。若主机已经集成 CDN，先查现有配置；独立资源域名型 CDN 的接法不同，不要把本文的域名服务器步骤直接套过去。
先确定你准备让哪些内容经过 CDN
普通网站可以先从公开的图片、CSS 和 JavaScript 开始。这类文件常被不同访客请求，相比带有个人状态的页面，更容易判断是否适合共用缓存。
Cloudflare 默认不缓存 HTML 和 JSON，因此文章里的图片可能命中缓存，文章 HTML 仍然需要回源。这符合默认缓存行为，不能只因为页面显示 DYNAMIC 就判断配置失败。
如果网站主要慢在 WordPress 生成 HTML，静态资源 CDN 不一定解决最大的等待。先让基础接入稳定，再考虑源站页面缓存或合适的 HTML 边缘缓存方案。不要在第一次接入时同时开启所有缓存、脚本和图片优化，否则功能异常后很难定位是哪项改动引起。 缓存职责与动态页面排除，可先参照WordPress 缓存设置教程列清楚，再决定是否增加边缘缓存。
准备几条验收地址：一篇公开文章、一张属于自己域名的图片、登录页、草稿预览和测试表单。电商站再加入购物车、结算与账户页。接入前后用同一组对象检查，才能知道哪一层发生了变化。
接入前保存 DNS，并确认源站条件
先导出或记录现有 DNS，核对根域名、www、业务子域名的 A、AAAA 或 CNAME，以及 MX、TXT 等邮件与验证记录。自动扫描可能漏掉记录，必须与当前 DNS 服务商的配置对照。尤其要确认 AAAA 是否仍指向可用的 IPv6 源站，不能只看 A 记录正确就结束。
网站文件备份不能代替 DNS 备份。你还需要保存原权威域名服务器名称，确认能登录域名注册商、原 DNS 服务商和主机控制台。如果这些由不同服务商管理，提前弄清分别在哪个后台修改，避免接入出错时找不到恢复入口。
主机这边确认网站已经能通过正式域名正常使用 HTTPS，并且知道源站证书类型和到期情况。后面采用 Full (strict) 时，要验证 Cloudflare 到源站的 TLS 连接；浏览器当前能看到一个锁形图标，不足以说明新增代理后的两段连接都正确。
还应先检查是否已有其他反向代理、主机 CDN 或按设备区分的缓存。它们不是一定不能共存，但会增加需要排查的层次。记录现状，再决定保留哪层职责。
完成域名接入，分清 DNS 管理和代理开关
按 Cloudflare 完整接入文档与当前面板操作：添加域名，核对导入记录，取得分配给本域名的权威域名服务器，再到注册商处替换原值。不要复制其他网站的服务器名称，也不要把 NS 名称填进 A 记录。
普通迁移流程中，原来启用了 DNSSEC 的域名，需要先按注册商流程关闭旧配置，再替换域名服务器；接入激活后按新流程重新启用。旧验证链与新权威服务不匹配，可能导致解析失败。有专门 DNSSEC 连续迁移方案的环境，应由管理员按对应文档处理。
更换权威域名服务器，意味着 DNS 由新服务商管理；是否经过 Cloudflare 的网站代理，还取决于相关记录的代理状态。 支持代理的网站记录可以设为 Proxied，DNS only 则只提供解析。邮件服务等不应使用普通网站代理的对象，要保留合适的 DNS 状态。具体范围见代理状态说明。
根域名和 www 要分别核对。如果一端代理、一端未代理，测试不同入口可能得到不同结果。检查网站最终跳到哪个正式地址，再沿实际请求链验证；不要为了接 CDN 顺手改变原来的规范域名。
完成后确认面板状态和实际解析，再测试网页与邮件业务。WordPress 文件没有因此搬到 Cloudflare，站点地址也通常无需改成另一域名。对这两个地址设置有疑问时，先查看WordPress 常规设置，不要在接入过程中凭猜测修改。
HTTPS 要分别看浏览器到边缘、边缘到源站
浏览器访问 Cloudflare 边缘与 Cloudflare 访问源站，是两段连接。前一段需要边缘证书正常覆盖访问域名；后一段由加密模式及源站证书决定。
源站具备有效证书时，使用 Full (strict) 可以验证回源证书。官方要求包括证书未过期、主机名匹配，并由受信任 CA 或 Cloudflare Origin CA 签发，见 Full (strict) 文档。这里的 Full (strict) 是 TLS 模式，与上一节的 Full DNS setup 是两件事。
如果使用 Cloudflare Origin CA，要记住它主要供 Cloudflare 与源站之间使用。它不是普通浏览器普遍信任的公开证书。暂停 Cloudflare 或将记录改成 DNS only 后，访客可能直连源站并遇到证书不受信任提示。Origin CA 官方说明明确提示了这一情况。因此，准备回退方案时要把源站证书和直连条件一起记录，不能把“关掉代理”当成所有站点都安全可用的恢复方式。
遇到重定向循环，检查当前模式、源站的 HTTP/HTTPS 跳转，以及根域名与 www 的跳转方向。比如边缘和源站对协议的处理互相冲突，就可能一直来回跳转。应记录跳转链再处理，不能只不停清缓存；官方的重定向循环排查提供了相应分支。
用真实网络请求验证缓存，而不只看第二次打开快不快
打开浏览器开发者工具的 Network 面板，访问公开页面，选中其中一张来自自己代理域名的图片。检查完整请求 URL、请求方法、状态码和响应头中的 CF-Cache-Status。
先排除直接来自浏览器内存或磁盘缓存的结果。那说明本机复用了资源，不能据此判断这一刻边缘节点是否返回缓存。可在开发者工具中禁用浏览器缓存后重新请求，但也要注意工具可能改变请求头；遇到结果不同，记录实际请求条件再比较。
| 状态 | 此次响应说明什么 | 接下来如何判断 |
|---|---|---|
| HIT | 本次从 Cloudflare 缓存提供 | 核对版本和内容是否正确，不外推为全站都已缓存 |
| MISS | 符合缓存条件，但请求时没有可用缓存 | 对同一 URL 再观察，考虑刚清理或节点尚未填充 |
| DYNAMIC | 请求阶段被判断为不适合缓存 | 默认 HTML 常见；检查对象、规则和当前模式 |
| BYPASS | 响应或配置使其未被缓存 | 查看源站缓存指令和相关条件，不强行覆盖私有保护 |
| EXPIRED | 已有缓存过期，本次需要从源站获取 | 结合 TTL、更新频率与后续响应判断 |
状态含义可对照 Cloudflare 缓存响应文档。一条公开图片先 MISS 后 HIT，是一种正常过程；并非每次请求都保证命中，缓存节点、有效期和清理操作都会影响结果。
如果静态图片一直不命中，按顺序检查：请求是否真的属于已代理域名；完整 URL 和查询参数是否每次相同；是否刚刚清过缓存；源站是否返回不适合共享缓存的指令；是否有 Cookie、规则或开发模式改变处理方式。具体原因见未缓存响应排查。反复刷新一个每次都带不同参数的地址，不能当成同一个缓存对象的测试。
同一网页里的第三方视频、字体和脚本，也可能来自其他域名。自己的代理状态不会自动改变它们的 CDN；必须先看请求主机名，再判断问题属于哪一方。
HTML 边缘缓存要单独设计，不能用全站 HIT 作为目标
静态资源跑通后，可以再评估是否需要缓存公开 HTML。Cloudflare 的 APO 是面向 WordPress 的一种额外方案，能够处理通常默认不缓存的 HTML，但仍受请求、Cookie、插件响应头等条件影响。它不是打开普通代理就自动具有的效果，功能与条件应查看 APO 官方说明。
自定义 HTML 缓存规则之前，先列出不能在不同访客之间共用的响应：后台、登录、草稿预览、账户资料、购物车、结算，以及带有个人化内容的页面。路径排除只是其中一部分，还要结合登录与会话 Cookie、查询参数、请求方法和业务插件行为。只列出几个常见英文路径，不足以覆盖所有自定义地址和接口。
表单页也不能一概而论。有些表单可以出现在公开缓存页面上，但其令牌更新和提交接口需要按插件机制处理。不能因为文章正文可缓存，就假定其中所有交互都能无限期使用同一份 HTML。
验证时分别使用未登录访客和测试账户，检查公开内容是否一致、账户内容是否正确隔离、草稿是否仍只向有权限者显示。电商站还要实际加购并查看金额、数量和账户状态。看到私人内容混用或购物车不更新，应立即停止相关 HTML 缓存策略并排查，而不是继续调高缓存时间。
更新内容时，确认旧版本停在哪一层
WordPress 可能有页面缓存，Cloudflare 有边缘缓存，浏览器还有本地缓存。清除其中一层，不等于其他层也同步消失。
例如你改了文章介绍，但 WordPress 页面缓存仍保存旧版。此时只清 Cloudflare，下一次回源仍可能拿到旧页面并再次缓存。正确检查是先确认源站实际输出了新版，再让边缘重新获取，最后核对访客浏览器收到的结果。
按业务集成的流程清理相关缓存。如果只更新一个资源，优先考虑按完整 URL 清理；自定义缓存键和变体需要按实际规则处理，参见单文件清理说明。不要为每一次小修改都无判断地清掉全站缓存，那会增加后续回源请求。
验收时选择可明确识别的改动，如一处段落或图片版本，检查公开页面的最新输出。相同文件名被覆盖后浏览器仍可能持有旧文件，资源版本管理也需要与发布流程配合。开发模式、清边缘缓存和清浏览器缓存各有用途，不能互相替代。
接入出错时，先定位失败发生在哪一层
解析、证书和跳转分开处理
如果整个域名都无法解析，先查权威域名服务器、DNS 记录和 DNSSEC，清 WordPress 缓存没有帮助。若能解析但出现 TLS 错误，检查边缘证书与源站证书、主机名和回源模式。若只有部分 URL 跳转异常，保存实际跳转链，检查站点和边缘是否有冲突规则。
页面正常而表单失败，则比较提交请求及对应安全或缓存规则，确认是被拦截、接口异常，还是邮件发送环节出错。前台成功但邮件未到，继续沿表单邮件送达流程核查，不能仅凭接入时间相近就认定 CDN 是唯一原因。
回退前核对直连条件
需要恢复时，优先撤回明确导致故障的那项设置。若要回退权威 DNS，必须确认原 DNS 仍有完整且正确的记录，同时处理匹配的 DNSSEC 状态；若准备暂停代理，则先确认源站证书、访问限制和直连能力。回退也需要条件，不能在不了解当前链路时连续切换多处设置。
最终保留一份接入记录：正式域名、哪些记录代理、当前 TLS 模式、缓存策略与排除范围、怎样清理更新、验收过哪些业务。这样后续换主机或调整表单时，维护者才能知道 CDN 承担了什么。 若接入后还没找到真正的等待，可到WordPress 网站速度优化专题重新选诊断路线。
常见问题
WordPress 使用 CDN 必须安装插件吗？
不一定。Cloudflare 的普通代理接入可以在 DNS 与服务商面板完成。插件可能用于缓存清理、APO 或其他集成；独立资源域名型 CDN 则可能需要改写资源地址。按具体接入方式决定，不要因为用了 CDN 就重复安装功能相同的插件。
页面显示 DYNAMIC，是不是配置失败？
不一定。Cloudflare 默认不缓存 HTML，DYNAMIC 可能符合当前策略。分别确认域名代理、静态资源缓存和业务访问。公开页面没有 HTML 边缘缓存时，不必为了得到 HIT 而添加不完整的全站缓存规则。
更换域名服务器后，网站主机也换了吗？
没有。它改变的是权威 DNS 的管理位置。只要网站记录仍指向原源站，文件和数据库仍在原主机。迁移主机需要另外处理数据、配置和切换，不应与普通 CDN 接入混为一谈。
网站异常时，可以直接关闭 Cloudflare 吗？
要先看源站是否能被浏览器正常直连。使用 Origin CA 证书、限制了直连访问，或依赖边缘功能的站点，关闭代理可能带来新的问题。优先定位最近改动，准备好证书、DNS 与访问条件后，再选择对应恢复方式。