Cloudflare CDN 终于支持 CNAME 接入了？这才是我们想要的打开方式！

大家好！

以前谈到 Cloudflare CDN，很多朋友的第一反应往往是：“好用是好用，但必须要把域名 NS 指过去，太麻烦了。”

确实，Cloudflare 传统的接入方式要么是改域名的 NS 服务器，要么是针对子域名使用 SaaS 模式（需要验证 TXT 记录，有时候还挺折腾）。但如果你只是想给某个子域名（比如 img.example.com）加点速，完全不想动主域名的 DNS 解析，或者主域名在 Cloudflare 不支持的注册商那边，这时候是不是就没办法了？ 其实不然，Cloudflare 早就悄悄支持了一种“类通用 CDN”的接入方式——CNAME 接入。

图1：Cloudflare DNS 配置面板概览

今天就来把这个冷门但极度实用的姿势分享给大家，特别是那些不想交钱买企业版却又想保留自主 DNS 控制权的朋友，这篇干货千万别错过。

传统方式的痛点

咱们先回顾一下以前的痛点，看看这新功能到底解决啥问题了。

1. NS 托管模式：这是最省心的方式，直接接管全家桶。但问题在于，你一旦把 NS 切过去，所有的 DNS 解析都要在 CF 面板里重新配置。如果你的主域名下面挂着几十个业务，迁移成本极高，而且很多公司或项目也不允许随意交出 DNS 控制权。
2. SaaS 模式：以前针对子域名有一种 CNAME Flattening（CNAME 托管）的玩法，但这玩意儿有时候会有兼容性问题，而且逻辑上还是有点绕，不像传统的 CDN 厂商（比如阿里云 CDN、AWS CloudFront）那样，直接给你一个 CNAME 记录，你填完就完事。

敲黑板：什么是 CNAME 接入？

Cloudflare 的这个功能，官方叫法可能涉及到 Dedicated Hostnames（专用主机名） 或者是针对企业/特定付费功能的边缘配置。简单来说，就是Cloudflare 给你的目标域名分配了专用的 IP 地址，不再依赖共享 IP 的 SaaS 校验逻辑。

图2：在原 DNS 服务商处配置 CNAME 指向

这意味着什么？意味着你可以像配置其他 CDN 一样：

• 不改 NS：主域名依然在阿里云、腾讯云、CloudNS 随便哪里躺着。
• 不签 TXT：不需要为了验证域名所有权去扯皮。
• 纯 CNAME：在你的 DNS 服务商那里，把子域名的 CNAME 记录指向 Cloudflare 给你的域名，搞定！

实操教程：如何配置？（保姆级）

虽然入口可能藏在侧边栏的“Network”或者其他高级选项里（视 CF 版本更新而定，企业版和部分升级后的 Free/Pro 计划可见性不同），但核心逻辑是不变的。以下是通用的配置思路：

第一步：添加站点（如果是新站）

在 CF 面板添加一个站点（比如 example.com）。**注意：**这里添加只是为了获取 CF 的分配资源，如果你不打算接管 NS，在后续的 DNS 设置页面，千万不要去复制它的 NS 服务器去域名注册商那里修改。忽略那些 NS 提示即可。

第二步：寻找 SSL/TLS 或 Speed > Optimization 中的 CNAME 设置

在较新的控制面板或者针对开启了特定功能的账户中，找到 Traffic 或 Network 相关的设置。

我们要找的是 “CNAME Flattening” 的高级形态，或者是 “Redirects” 之外的路由规则。但最稳的方式其实是通过 SSL/TLS for SaaS 的思路演变而来的 Dedicated Hostnames。

划重点：在 SSL/TLS -> Edge Certificates 页面下方，以前有个“Custom Hostnames”或者在 Advanced 里有相关选项。如果没有，可能需要确认你的账户权限或是否开启了专用证书功能。

第三步：配置目标域名

你需要告诉 Cloudflare：“嘿，我打算把 cdn.yourdomain.com 接进来”。

1. 输入你的子域名（例如：api.test.com）。
2. Cloudflare 会验证你是否拥有该域名（通常需要添加一条 TXT 记录，仅此一次验证，验证完可删）。
3. 验证通过后，Cloudflare 会为这个专门的子域名颁发证书，并分配一个接入点。

第四步：DNS 解析回填

这是最后一步，也是最像“传统 CDN”的一步。

回到你的原 DNS 服务商（比如阿里云 DNS）：

• 主机记录：api
• 记录类型：CNAME
• 记录值：指向 Cloudflare 提供的那个专用域名（通常是你的站点名加上 CF 的后缀，比如 something.cloudflare.net 或者根据指引填写的值）。

保存，等待生效！

这样，当用户访问 api.test.com 时，请求会先经过你的 DNS 解析到 CF 边缘节点，享受到 CF 的 WAF、缓存和加速，全程不需要动主域名的 NS。

适用场景与注意事项

✅ 什么时候用这个姿势？

1. 混合云架构：主业务在阿里云，静态资源想挂 CF，但不想改 DNS 解析商。
2. 不想迁移 DNS：域名服务商有特殊优惠（比如 Namecheap 优惠码），不想因为用 CF 而 NS 迁移导致优惠失效或管理分散。
3. 规避审查/封锁：部分运营商针对 CF 共享 IP 封杀较严，专用 IP（如果有）或专用 Hostname 模式有时候会有奇效（因人而异）。

⚠️ 避坑指南

1. 证书问题：因为是 CNAME 接入，SSL 证书通常由 Cloudflare 边缘节点重新签发。请确保你的源站配置好 SSL，且 CF 面板上的 SSL 模式设为“Full (Strict)”或者“Full”，视源站证书情况而定。
2. 缓存规则：由于不走正统的 DNS 代理模式，部分 Page Rules 里的基于 DNS 解析的匹配规则可能需要调整，建议多用基于 URL 路径的规则。
3. 功能阉割：某些极度依赖 DNS 管理层面的功能（比如 CF 的 Email Obfuscation 邮件保护等）可能会在 CNAME 接入的子域上失效，这些功能本质上是改 DNS 记录实现的。

总结

虽然 Cloudflare 官方最推荐的就是 NS 托管，毕竟生态闭环体验最好，但对于我们这些“既要又要”的折腾党来说，通过 CNAME 方式接入 Cloudflare 绝对是一个必备的技能树。

它打破了我们对 Cloudflare “要么全接，要么别用”的刻板印象，让它在混合部署场景下变得更加灵活。下次如果有项目不想动主域名 DNS，但又想蹭一把 Cloudflare 的免费 CDN 和 WAF，不妨试试这个方法！

如果大家在配置过程中遇到找不到入口、报错或者证书不信任的问题，欢迎在评论区留言，咱们一起探讨解决！