Cloudflare CDN怎么用？从接入、DNS到缓存验证

更新于 2026-11-01 · hgfastapp.lol

简答：Cloudflare CDN 的最短接入路径是：添加域名并核对 DNS 记录，在注册商处改成 Cloudflare 提供的 NS，再把网站的 A、AAAA 或 CNAME 设为 Proxied（橙色云朵），最后用 HTTPS 响应头和缓存状态验证。静态图片、CSS、JS 通常可直接缓存；登录、后台、购物车、支付和 API 不应直接套用“缓存所有内容”。

定义：Cloudflare CDN 是建立在 Cloudflare 反向代理网络上的内容分发服务，网站流量只有经过 Proxied 记录进入 Cloudflare 后，才能使用其缓存、HTTPS、WAF 和相关网络优化能力。

结论速查：先判断你要改的是哪里

很多人把注册商、Cloudflare 控制台和源站主机面板混在一起，结果是 NS 改错、DNS 记录遗漏，或者开了橙色云朵却仍然没有缓存。先按下面的分工定位操作入口。Cloudflare 的常见全量接入方式是：在 Cloudflare 添加域名、导入并核对 DNS 记录，再到域名注册商处修改 NS；完成后，Cloudflare 才成为该域名的权威 DNS 服务商。Cloudflare DNS 官方入门说明

你要完成的事情	操作位置	成功标准
添加网站	Cloudflare 控制台	域名出现在账户中，并获得两条 Cloudflare NS
配置源站地址	Cloudflare DNS	A、AAAA 或 CNAME 指向真实网站源站
启用 CDN 代理	Cloudflare DNS 的 Proxy status	网站记录显示橙色云朵，即 Proxied
修改权威 DNS	域名注册商	注册商 NS 与 Cloudflare 分配的 NS 一致
配置源站 HTTPS	Cloudflare SSL/TLS 与源站	访问 HTTPS 不出现 525、循环跳转或混合内容
判断是否命中缓存	浏览器开发者工具或 curl	响应头出现 CF-Cache-Status，并能区分 HIT、MISS、BYPASS 等状态

先试这一步：如果网站已经能打开但怀疑 CDN 没生效，先执行 curl -I https://你的域名/静态文件路径，检查响应头中的 CF-Cache-Status、server 和 location，不要一开始就清空全部缓存。

前置条件：接入前先备份 DNS 和源站信息

开始前准备好域名注册商账号、Cloudflare 账号、源站公网 IP 或主机商提供的 CNAME、源站 HTTPS 状态，以及当前 DNS 记录截图或导出文件。Cloudflare 官方提醒，修改 NS 前应先检查导入的 DNS 记录；如果遗漏网站、邮件或验证记录，激活后可能造成域名或邮件不可达。Cloudflare 添加域名官方步骤

网站记录：准备根域名和 www 对应的 A、AAAA 或 CNAME。
邮件记录：保留 MX、SPF、DKIM、DMARC 等记录；这些记录通常不应开启网页代理。
验证记录：TXT、用于域名验证的 CNAME 等记录按服务商要求保持 DNS-only。
DNSSEC：如果注册商处已启用 DNSSEC，修改 NS 前先确认迁移流程；Cloudflare 文档提示，NS 切换时 DNSSEC 配置不匹配可能导致域名不可达。
回退资料：记录原注册商 NS、原 DNS 服务商、源站 IP、主机面板中的 HTTPS 设置，便于故障时恢复。

如果你使用的是其他 CDN、托管平台或企业级 DNS 架构，不要直接照搬全量 NS 接入；先确认该平台要求的是修改 NS、添加 CNAME，还是使用部分接入方式。

最短流程：5步完成 Cloudflare CDN 接入

第1步：在 Cloudflare 添加域名

登录 Cloudflare 控制台，添加你实际拥有的域名。
选择常规的全量 DNS 接入方式时，等待 Cloudflare 导入现有 DNS 记录。
逐条检查 A、AAAA、CNAME、MX、TXT 和其他验证记录，特别是根域名、www、邮件子域名和 API 子域名。

Cloudflare 会分配两条权威 NS。此时不要只看到“记录已导入”就认为 CDN 已生效，因为域名仍可能由原 DNS 服务商回答查询。

第2步：在注册商处修改 NS

打开购买域名的注册商后台，而不是 Cloudflare 的 DNS 记录页面。
找到 Nameserver、DNS 服务器或域名服务器设置。
删除旧 NS，填入 Cloudflare 为该域名分配的两条 NS，保存。

修改 NS 后，Cloudflare 需要等待注册商和递归 DNS 更新。不要用“本地浏览器暂时打不开”判断全网状态；应分别从本机、公共 DNS 查询和 Cloudflare 控制台状态核对。

第3步：设置网站记录为 Proxied

只有实际承载 HTTP 或 HTTPS 网站流量的 A、AAAA、CNAME 记录才适合开启橙色云朵。Cloudflare 文档说明，Proxied 会让 HTTP/HTTPS 请求先进入 Cloudflare；DNS-only 则直接返回源站地址，不经过 CDN 缓存和网页代理。Cloudflare Proxy status 官方说明

通常设为 Proxied：根域名、www、博客、静态站点、网页应用和 HTTP/HTTPS API。
通常设为 DNS-only：MX、TXT、邮件相关主机名、域名验证记录，以及不兼容 HTTP 反向代理的非网页服务。
不要混淆：DNS 记录存在，不等于流量一定经过 Cloudflare；是否经过 CDN 取决于记录是否可代理以及 Proxy status。

第4步：配置 SSL/TLS

访问者到 Cloudflare 和 Cloudflare 到源站是两段连接。源站至少应能在 443 端口提供 HTTPS，生产站点优先让源站使用有效证书，并根据源站证书情况选择 Full 或 Full (strict)。Cloudflare 对加密模式的定义是：Full 会加密到源站但不验证源站证书；Full (strict) 会验证源站证书。Cloudflare SSL/TLS 加密模式

源站有公开可信证书：优先考虑 Full (strict)。
源站暂时只有自签名或 Cloudflare Origin CA 证书：可核对 Full (strict) 所需的证书链、主机名和有效期；不要用长期降低安全性的方式掩盖证书问题。
出现 525：先检查源站 443 端口、证书、SNI、TLS 版本和防火墙是否允许 Cloudflare 回源。
出现重定向循环：检查源站是否强制 HTTPS、应用是否正确识别代理后的 HTTPS，以及 Cloudflare 加密模式是否与源站配置一致。

第5步：等待状态更新并验证域名

先访问根域名和 www，再检查静态资源、登录页、邮件和 API。不要只看页面能否打开，还要确认请求是否经过 Cloudflare、源站是否收到正确的 Host，以及缓存是否符合预期。

缓存怎么配：静态资源、公开页面与动态路径分开处理

Cloudflare 默认会缓存许多静态文件，例如图片、CSS、JavaScript、字体、压缩包和视频等；HTML 和 JSON 默认不会按普通静态文件自动缓存。具体行为还会受请求方法、源站 Cache-Control、Set-Cookie、查询字符串和 Cache Rules 影响。Cloudflare 默认缓存行为

内容类型	建议	原因
图片、CSS、JS、字体	先使用默认缓存，发布时给文件加版本号	适合边缘缓存，减少源站重复请求
公开且不含用户状态的 HTML	确认内容确实公开后，再用 Cache Rules 精确匹配	HTML 默认不缓存，强制缓存需自行承担内容更新和隐私风险
登录、账户、后台	绕过缓存	避免会话、CSRF 或 Set-Cookie 被错误处理
购物车、结算、支付	绕过缓存	页面与用户、订单状态相关，不能复用其他用户的响应
API 和带身份验证的请求	默认绕过，按接口设计单独评估	响应可能依赖 Cookie、Authorization 或请求体

Cache Rules 需要对应 DNS 记录处于 Proxied 状态。一个安全的规则顺序是：先为登录、账户、购物车、结算、支付和 API 路径设置绕过，再考虑对明确公开的页面设置缓存。Cloudflare 的动态内容排错文档也建议，对这些动态路径设置 bypass 或 disable caching，并检查响应是否保留 Set-Cookie。Cloudflare 动态内容与登录问题排查

示例匹配思路可以写成：/login*、/account*、/cart*、/checkout*、/api/* 先绕过缓存；公开页面只在确认不含登录状态、个性化内容和敏感数据后再纳入缓存。字段名称和控制台菜单可能随版本调整，实际保存前以当前 Cloudflare 控制台显示为准。

验证方法：用 DNS、HTTP 响应头和浏览器三层确认

1. 验证 NS 是否已经切换

macOS 或 Linux 可执行：

dig NS example.com +short

Windows PowerShell 可执行：

nslookup -type=NS example.com

将 example.com 替换为你的域名。结果应能看到 Cloudflare 分配的 NS。若注册商页面已保存但查询仍显示旧 NS，先检查是否修改了正确的域名、是否存在 DNSSEC 冲突，以及本地递归 DNS 是否仍缓存旧结果。

2. 验证网站记录是否经过代理

执行：

dig A www.example.com +short

如果记录处于 Proxied，查询结果通常不会直接显示你在 Cloudflare DNS 表中填写的源站 IP，而会返回 Cloudflare 的代理地址。DNS-only 则会返回记录对应的源站地址。该判断只能作为线索，最终还要结合 Cloudflare 控制台的 Proxy status 和 HTTP 响应头。

3. 验证 HTTPS 和缓存

执行：

curl -I https://www.example.com/assets/app.css

重点看：

HTTP/2 200 或 HTTP/3 200：说明该请求完成了 HTTPS 访问，但不单独证明缓存命中。
CF-Cache-Status: HIT：该响应从 Cloudflare 缓存返回。
MISS：本次未命中，可能需要首次回源或资源尚未缓存。
DYNAMIC、BYPASS：资源被判定为动态或规则要求绕过缓存。
出现 301、302：继续检查 location 指向是否形成 HTTP 与 HTTPS 之间的循环。

如果测试的是登录页或 API，看到未缓存并不一定是故障，反而可能说明绕过规则正在生效。验证缓存时应优先选择公开静态文件，并连续请求同一个完整 URL。

分层排错：打不开、旧内容、登录异常分别处理

域名打不开或显示 DNS 错误

确认注册商处的 NS 是否与 Cloudflare 分配的两条 NS 完全一致。
确认 Cloudflare DNS 中存在根域名和实际访问主机名的 A、AAAA 或 CNAME。
检查是否误删 MX、TXT 或第三方验证记录。
如果启用了 DNSSEC，核对 DS 记录与新权威 DNS 是否匹配；不确定时先按官方迁移流程处理。
用不同网络或公共 DNS 查询，区分本地缓存问题和权威 DNS 问题。

网站能打开，但 CDN 没有生效

确认访问的主机名对应记录是 Proxied，而不是 DNS-only。
确认该记录确实服务 HTTP/HTTPS；邮件和非网页服务不应强行代理。
用 curl -I 检查响应头，而不是仅凭页面加载速度判断。
检查源站是否自行设置了 Cache-Control: private、no-store、no-cache 或 Set-Cookie。
检查 Cache Rules 是否命中，必要时使用 Cloudflare Rules simulator。

更新后仍显示旧内容

先确认源站文件确实已更新，再优先按单个 URL 清理缓存，而不是直接清空整个站点。Cloudflare 官方建议优先使用 single-file purge；清理请求返回成功只表示 Cloudflare 接受了请求，之后还要重新请求资源，并检查 CF-Cache-Status 是否不再是旧的 HIT。Cloudflare 清理缓存官方说明

登录、表单或购物车异常

检查相关路径是否被设置为 Cache Everything 或 Eligible for cache。
为 /login、/account、/cart、/checkout 和 API 路径添加绕过规则。
检查响应是否仍包含源站应返回的 Set-Cookie。
确认 WAF、挑战或限速规则没有打断登录提交和 API 请求。
修正规则后，再清理受影响 URL 的缓存并重新测试。

HTTPS 报错或反复跳转

检查源站是否监听 443、证书是否覆盖访问的主机名、源站防火墙是否允许回源，以及应用是否正确识别反向代理后的 HTTPS。若源站只支持 HTTP，虽然某些模式可以暂时建立访客到 Cloudflare 的 HTTPS，但更稳妥的长期方案仍是让源站具备正确的 HTTPS 配置。

边界与延伸：Cloudflare CDN不等于所有网络问题都会消失

Cloudflare CDN 主要优化经过其网页代理的 HTTP/HTTPS 请求。它不能替代源站扩容、数据库优化、应用代码排错、邮件服务器配置，也不会自动修复源站到用户之间所有线路、DNS、MTU、丢包或跨网络连接问题。若源站本身响应慢、TCP/TLS 握手失败、IPv6 配置错误，开启 CDN 后仍可能复现。

还要注意三类边界：

代理边界：只有可代理的 A、AAAA、CNAME 网页记录能使用网页 CDN；MX、TXT 等记录不是 CDN 流量入口。
缓存边界：缓存命中只代表某个请求对象符合缓存条件，不代表整站所有页面都被缓存。
源站边界：即使用户访问的是 Cloudflare 地址，Cloudflare 仍可能需要回源；源站端口、证书、防火墙、Host 和应用状态必须正确。

截至 2026-11-01，控制台菜单、规则名称和部分计划能力可能继续调整。涉及版本、套餐、规则数量或具体权限时，应以当前 Cloudflare 控制台和官方文档显示为准；本文不提供未经实测的速度、延迟或可用性承诺。

常见问题

Cloudflare CDN怎么用，必须修改域名 NS 吗？

最常见的全量接入方式需要把域名 NS 改成 Cloudflare 分配的两条 NS，这样 Cloudflare 才成为权威 DNS 服务商。若使用部分接入或其他企业 DNS 架构，流程可能不同，应以当前账户支持的接入方式为准。

灰色云朵和橙色云朵有什么区别？

橙色云朵表示 Proxied，HTTP/HTTPS 流量会经过 Cloudflare，可使用网页代理、缓存和相关安全能力；灰色云朵表示 DNS-only，查询通常返回源站地址，不经过 Cloudflare 的网页 CDN。邮件、TXT 验证和非网页服务通常保持 DNS-only。

为什么 Cloudflare CDN接入后 HTML 没有 HIT？

HTML 默认不会像常见静态文件那样自动缓存，且 private、no-store、no-cache、max-age=0、Set-Cookie 或绕过规则都可能使响应不缓存。只有明确公开、没有用户状态的页面，才适合通过 Cache Rules 单独评估缓存。

清理缓存后为什么还是看到旧页面？

先确认清理的是完整 URL、源站内容确实已更新，并重新请求后检查 CF-Cache-Status。Cloudflare 说明清理请求成功只代表请求被接受，不等于浏览器、本地 DNS、源站应用缓存或其他缓存层已经同步。

Cloudflare CDN会不会影响登录和支付？

如果把登录、账户、购物车、结算、支付或带身份验证的 API 错误缓存，可能导致会话、Cookie 或表单状态异常。正确做法是为这些路径设置绕过缓存，并用响应头确认 Set-Cookie 和动态响应仍然存在。