我前两天刚把个人博客从"Vercel 域名 + 阿里云 DNS"的配置迁移到了"阿里云域名 + Cloudflare 托管 DNS + Vercel 部署"，整个过程走了不少弯路，尤其是 Cloudflare 和阿里云两边控制台的英文界面、DNS 传播等待、SSL 证书的奇怪状态，着实折腾了几个小时。这篇文章就把我从头到尾的操作步骤、踩坑点和最终调优方案完整记录下来，适合有小项目部署在 Vercel、想免费加一层 CDN 和网站防护的朋友参考。
先说结论：这套组合的最大价值在于把三件事分开管理——域名注册在阿里云（国内访问管理方便），DNS 解析和安全防护交给 Cloudflare（免费套餐完全够用），网站运行放在 Vercel（免费部署和自动 HTTPS）。三者各管一块，出了问题互不牵连，排查起来非常清晰。
1. 为什么要在 Vercel 前面套一层 Cloudflare：免费版能力边界
很多人一开始不解：Vercel 本身就带 HTTPS、带 CDN、带自动部署，为什么还要多此一举接 Cloudflare？我在实际对比之后发现，Vercel 的免费方案确实够用，但它在网站安全层面基本是空白，尤其是这三个具体痛点：
- 缺少 Web 应用防火墙（WAF）：Vercel 免费版不提供自定义规则，像恶意 IP 扫描后台路径、频繁请求 API 接口这类行为，只能靠自己在代码里写中间件处理，效率低还容易漏。
- 缺少自定义缓存规则：Vercel 的默认缓存策略针对
_next/static这类静态资源设计得很好，但动态页面（SSR）默认不缓存，免费版每月的函数调用次数和带宽有上限，稍微有点流量就见底。 - 源站 IP 可能暴露：如果你在 Vercel 上部署了后端 API 或者使用了自定义服务器，源站 IP 一旦泄露，被 DDoS 攻击时免费版没有防护能力，网站直接不可用。
Cloudflare 免费套餐目前包含的 WySP（网站安全防护）功能，包括无限流量的 CDN 加速、免费 Universal SSL 证书（自动续期）、基础 WAF 规则（5 条自定义规则）、DDoS 防护和 Bot 对抗模式。这些能力单独买任何一个商业 WAF 都不便宜，但在 Cloudflare 免费版里全都包含。唯一的限制是免费版节点主要部署在海外，国内访问速度没有明显优势，但对海外访客为主的项目来说，提速效果很显著。
这里我还要解释一个容易被忽略的概念：Cloudflare 和 DNS 托管服务不是同一个东西。虽然 Cloudflare 会接管你的 DNS 解析（在你的域名 DNS 服务器指向它的服务器），但前提是你的域名注册商必须支持修改 NS 记录，阿里云完全可以做到。换句话说，域名还在阿里云续费和实名认证，只是解析服务从阿里云切换到了 Cloudflare，两边的控制台职责不同。这个切换随时可以改回，不需要担心域名被锁定之类的问题。
2. 核心三步走：修改 NS、添加站点记录、开启代理模式
从"阿里云域名 + 阿里云 DNS"切换到"阿里云域名 + Cloudflare DNS"，本质上是两步：先在阿里云把 DNS 服务器改成 Cloudflare 分配的那组 NS 地址，再在 Cloudflare 里把域名添加为站点并手动配置解析记录。这两步顺序不能反——如果先把域名加进 Cloudflare 而阿里云那边的 NS 还没改，Cloudflare 会一直提示域名等待之类的状态，实际上却不生效。
2.1 阿里云域名控制台：把 DNS 服务器改成 Cloudflare 的 NS
先在 Cloudflare 注册账号并添加站点，Cloudflare 会给你分配两个 NS 地址（通常是xxx.ns.cloudflare.com和yyy.ns.cloudflare.com）。记录好这两个域名之后，登录阿里云域名控制台，进入"域名列表"，找到你的域名，点击"管理"→"DNS 修改"。这里有两个选项：一个是"修改 DNS 服务器"，另一个是"修改 DNS 解析"（也就是修改解析记录本身）。我们要用的是前者，改成 Cloudflare 给的那两个 NS 地址。
实际操作中要注意一个细节：阿里云默认会校验 NS 地址格式，部分情况下会提示"请填写正确格式"。我遇到过一次，原因是把 Cloudflare 给的地址中包含了末尾的点（比如xxx.ns.cloudflare.com.），去掉末尾的点就可以了。另外，修改 NS 后全球生效需要一段时间，短则几分钟，长则 24 小时，我在实际测试中一般 0.5 到 2 小时内就能在dig命令下看到新 NS 生效，但你可以用下面的命令验证：
dig example.com NS +short如果返回结果是 Cloudflare 的那两个 NS 地址，说明切换成功。如果还是阿里云的alidns.com那组地址，说明还在传播中，多等一会儿再查。等待期间网站访问不受影响，因为老的解析记录还在继续工作。
2.2 Cloudflare 添加站点并确认 Vercel 的 CNAME 记录
NS 切换生效后，回到 Cloudflare 控制台，域名状态会从"待处理"变成"活跃"。此时需要手动把 Vercel 的解析记录加进来。进入 Cloudflare 域名的"DNS"管理页面，默认会显示几条系统自动扫描到的记录（通常是从旧 DNS 迁移过来的），但 Vercel 的 CNAME 记录不一定在里面，需要自己添加：
- 类型：CNAME
- 名称：
@（代表裸域名）或www，如果你想让www.example.com也走 Cloudflare，就分别添加两条 - 目标：
cname.vercel-dns.com（这是 Vercel 官方推荐的接入点，指向这个域名会把流量分发到 Vercel 的边缘网络） - 代理状态：选择"已代理"（橙色云朵），这个必须选，否则 Cloudflare 只做 DNS 解析，流量的防护和加速全都没有
添加完成后，回到 Vercel 控制台的"Domains"页面，确认example.com和www.example.com都显示为"Valid Configuration"。如果显示"Invalid"或者"Pending"，不要慌，多半是 DNS 传播还没完成，等 5~10 分钟刷新一下即可。如果一直无效，排查一下 Cloudflare 里的记录是否把名称写错——例如裸域名用了www，那就永远无法验证通过。
2.3 开启橙色云朵代理：为什么这一步决定了整个方案的成败
Cloudflare 的"已代理"状态（橙色云朵）和"仅 DNS"状态（灰色云朵）的区别，我用一个生活化类比说明：灰色云朵就像你写了一封信直接寄给对方地址，邮局只负责查地址（DNS 解析），不管信件内容；橙色云朵就像你把信先送到了小区保安亭，保安会帮你检查信件、盖上验证章（WAF、SSL 加密）再转送给住户，后续邮件往来也都走保安中转。
实际测试下来，开橙色云朵之后会发生三件事：第一，用户的请求先到距离他最近的 Cloudflare 节点，再由该节点回源到 Vercel，链路多了一步，但对海外用户来说因为 CDN 节点分布广，整体时延反而更低；第二，Cloudflare 会缓存合适的静态资源，减少 Vercel 的流量消耗；第三，源站 IP 对用户不可见，所有请求都是从 Cloudflare 的 IP 段发出，这样即使有人扫描你的源站 IP，也只能扫到 Vercel 的泛化 IP，攻击难度大增。
有个容易踩的坑：如果你之前已经在 Vercel 控制台把域名绑定好，并且 Vercel 那边强制要求 CNAME 必须指向cname.vercel-dns.com，那么在 Cloudflare 里添加记录时目标地址一定不要写成裸的vercel.app域名。虽然 Vercel 也能解析，但证书校验时可能因为域名的 CNAME 链不合格而出现 SSL 错误。用官方给定的目标地址最稳妥。
3. SSL/TLS 配置：从 Flexible 到 Full (strict) 的完整理由
Cloudflare 接管代理后，浏览器和 Cloudflare 之间的连接是 HTTPS，但 Cloudflare 回源到 Vercel 的连接方式取决于你设置的 SSL/TLS 加密模式，这一步如果配置不对，网站要么打不开，要么出现重定向循环。很多人照着教程只做了前两步，就卡在第三步，所以单独拿出来讲。
3.1 三种加密模式区别表
| 模式 | 浏览器→Cloudflare | Cloudflare→源站 | 适用场景 |
|---|---|---|---|
| 灵活（Flexible） | HTTPS | HTTP | 源站没有 SSL 证书，想省事但容易出循环问题 |
| 完全（Full） | HTTPS | HTTPS，但源站证书不受严格验证 | 源站证书过期/自签名时过渡用 |
| 完全（严格） | HTTPS | HTTPS，且强制源站证书有效 | 推荐使用，Vercel 场景必须用它 |
我推荐选择"完全（严格）"。原因在于：Vercel 的每个项目域名都自动配置了有效证书，而且这个证书是经过 CA 签发的正式证书，不是自签名，所以完全满足"严格"模式下的证书验证要求。选择 Full（不带 strict）虽然也能跑通，但失去了对源站证书的校验作用，万一哪天 Vercel 证书异常，问题会被 Cloudflare 的缓存掩盖，实际服务挂了你在外面看还是"正常"的状态。为避免这种"假健康"，直接用 Full (strict) 最合适。
具体操作：在 Cloudflare 域名管理页面，左侧菜单点"SSL/TLS"→"概述"，把加密模式改为"完全（严格）"。改完保存即可，不需要额外等待，边缘节点几秒钟内就会生效。
3.2 开启 Always Use HTTPS 和 Automatic HTTPS Rewrites
在"SSL/TLS"→"边缘证书"页面，有两个开关值得一起打开：
- Always Use HTTPS：开启后，用户访问
http://example.com时，Cloudflare 会返回 301 跳转自动带上 HTTPS，不需要在 Vercel 那边配置重定向规则。 - Automatic HTTPS Rewrites：开启后，Cloudflare 会扫描网页内容里硬编码的
http://链接，自动改写为https://，避免混合内容（Mixed Content）导致的浏览器警告。
这两个开关在免费版里都是可用的，也是我强烈建议开满的。实际测试中，Automatic HTTPS Rewrites 对压缩后的 HTML 内容也有效，因为是边缘层做替换，不需要改代码。唯一要注意的是如果你引用了第三方域名的资源（比如外部图片、iframe 嵌入），Cloudflare 只会改写 HTML 内容里的链接，不会去改 JavaScript 文件里的字符串，所以外部资源如果本身不支持 HTTPS，还是要手动处理。
3.3 证书状态异常的处理思路
接入后第一次配置，最常见的问题是 Cloudflare 控制台里"SSL/TLS"页面显示"正在验证"或者"正在部署"。这大概率是因为 Cloudflare 的 Universal SSL 证书正在签发，通常需要几分钟到一小时不等。这段时间网站访问 HTTPS 可能报证书错误，但 HTTP 还是能访问。
我的经验是：如果证书状态一直卡在"正在验证"，先去确认域名的 NS 是否已经生效（用dig example.com NS查询），再确认 DNS 记录里的 A 记录或 CNAME 记录是否存在且正确。如果都正常，可以尝试点击"重新验证"或者等待 30 分钟后刷新。千万不要在证书还没签发成功的时候开启"Always Use HTTPS"，那样会让用户全部卡在 HTTPS 请求上，直接打不开网站。先等证书变成"活跃"状态再开那个开关，顺序很重要。
4. 重点避坑：重定向循环、真实访客 IP 丢失和缓存穿透
光把域名跑通不算完，真正的问题往往出现在"看起来通"之后。这一节我把最容易出现的三个坑和排查方法整理出来，尤其是重定向循环，在我的测试环境里几乎必现，如果不解释清楚，新手很容易以为是 Cloudflare 的问题。
4.1 重定向循环：根源和完整排查步骤
重定向循环的表现：浏览器提示"页面无法正常工作，将你重新定向的次数过多"（ERR_TOO_MANY_REDIRECTS）。根本原因通常是：浏览器请求 Cloudflare（HTTPS），Cloudflare 回源到 Vercel（如果开了 Flexible 模式，这里走 HTTP），Vercel 检测到 HTTP 请求后强制跳转到 HTTPS，返回给 Cloudflare 一个 301，Cloudflare 又按照这个跳转再次请求 HTTPS，于是形成循环。
排查步骤我整理成固定顺序：
- 检查 SSL/TLS 加密模式，改成"完全（严格）"，这是 90% 循环问题的解法。
- 检查 Vercel 项目设置里的"强制 HTTPS"开关。如果 Cloudflare 已经回源 HTTPS，Vercel 的强制 HTTPS 可以关闭，两者叠加时反而容易出现不可预期的跳转。
- 检查 Cloudflare 侧有没有"重定向规则"（比如把
example.com重定向到www.example.com），同时 Vercel 侧也设置了类似的 301，两个方向冲突就会循环。 - 用
curl -I跟踪响应头，如果连续两次出现相同的Location字段，说明已经陷入循环。
我的实测建议：把 Cloudflare 的 SSL 模式设为 Full (strict)，然后 Vercel 侧关闭"强制 HTTPS"。因为 Cloudflare 边缘层已经强制 HTTPS 进入，回源也是 HTTPS，最终用户不需要 Vercel 再做一次跳转。这样可以最大化避免循环。
4.2 真实访客 IP 丢失：不开启这个配置，你在 Vercel 看到的全是 Cloudflare 的 IP
网站装了统计工具或者想按 IP 做地区区分的时候，经常会发现所有访客都来自美国的某个 IP——这不是用户真的在美国，而是 Cloudflare 代理后的边缘节点 IP。要拿到真实访客 IP，需要做两件事：
第一，在 Cloudflare 的"网络"页面，找到"IP 地理位置"（IP Geolocation）和"真实客户端 IP"（True-Client-IP Header）这两个选项，都打开。Cloudflare 会在请求头里自动加入CF-Connecting-IP字段携带真实 IP，并加入CF-IPCountry字段携带访客国家代码。
第二，在 Vercel 的代码层读取这些字段。比如 Next.js 的一个 API 路由里可以这样取：
export function getClientIp(req: Request) { const cfConnectingIp = req.headers.get('cf-connecting-ip'); if (cfConnectingIp) return cfConnectingIp; const xForwardedFor = req.headers.get('x-forwarded-for'); return xForwardedFor ? xForwardedFor.split(',')[0].trim() : 'unknown'; }注意一个问题：Vercel 的边缘网络会自己改一层x-forwarded-for，所以它表达的真实 IP 不一定准确。优先读取 Cloudflare 提供的cf-connecting-ip字段更靠谱。如果你在 Vercel 上跑的是 Python/Flask 这类应用，对应改request.headers.get('cf-connecting-ip')即可。
4.3 缓存穿透：配置了缓存规则但不生效
Cloudflare 的默认缓存规则对 HTML 页面不太友好，如果不额外配置，动态页面几乎不会被缓存，每个请求都会回源到 Vercel，这对于免费版配额来说是一种浪费。要解决缓存穿透，可以在 Cloudflare"缓存"→"缓存规则"里新建规则：
- 规则名称：Cache blog pages
- 匹配条件：主机名 等于
example.com，URI 路径 包含/blog - 动作：浏览器最长闲置时间设为 300 秒，边缘最长闲置时间设为 300 秒，然后打开"忽略查询字符串"
配置完成保存后，Concrete 页面会在 Cloudflare 边缘节点缓存 5 分钟，期间相同 URL 的请求不会再回源到 Vercel。我实测下来，对于个人博客，这样的 TTL 设置很合适——既能保证内容更新后 5 分钟内可见，又能明显减少回源次数。如果你的站点是纯静态的，甚至可以把这个 TTL 拉长到 1 小时，进一步降低负载。
有个容易忽略的点：如果你在 Vercel 侧的响应头里设置了Cache-Control: public, max-age=60，Cloudflare 会尊重这个响应头决定是否缓存。所以不要在两边设置互相矛盾的缓存策略，否则看不出规则是否真的生效。我习惯的做法是：缓存逻辑统一放在 Cloudflare 规则里，Vercel 侧不特别设置缓存相关响应头，省得两个系统打架。
5. 关于域名选购和备案的实务经验
文章开头提到以阿里云购买域名为例，这里把选域名和备案的实务经验补充一下，因为网上很多教程默认你已经有域名，但实际很多人卡在这一步。
5.1 阿里云域名选购的常见注意点
购买域名时，阿里云会引导你先选域名后缀（.com、.cn、.net 等），再填写域名主体。个人站点我推荐优先选.com，原因很简单：通用性强、搜索引擎权重高、续费价格相对稳定。.cn域名便宜不少，但会有实名备案要求，可能在管理上多一道手续。.dev、.app这类新顶级域名虽然好看，但部分后缀要求强制 HTTPS，如果后面要套 Cloudflare 做特殊测试，反而多了一层限制。
阿里云购买域名的流程里有一项是"域名持有者信息模板"——如果你是企业注册，需要填写营业执照上的主体信息，个人注册则填身份证信息。这里有个建议：域名持有者信息务必和备案主体保持一致（如果将来要备案的话），否则后续做网站备案时会卡在主体不一致的问题上。我在去年帮朋友处理过一个域名，就是因为持有者信息和备案主体不一致，白白等了半个月重新实名。
5.2 备案问题要不要考虑
国内服务器部署网站基本都要求备案，但 Vercel 是海外服务商、服务器也在海外，所以通过 Vercel 部署网站是不需要备案的。Cloudflare 的 DNS 服务和 CDN 节点主要也在海外，也不涉及国内备案。所以如果你用我这套方案，阿里云这边只承担域名注册和实名认证，不需要额外折腾备案流程。
唯一需要留意的是：域名实名认证一般在你购买当天或者第二天就能通过，但部分敏感词汇的域名可能会触发人工审核，时间会拉长。我建议不要在购买后立刻切换 DNS，等实名认证状态变成"成功"再操作，否则阿里云那边可能会因为实名未过而锁定域名解析修改权限。这是我实际踩过的小坑，分享出来。
5.3 域名续费与隐私保护
阿里云域的续费价在首年优惠后会回升，一些.com域名续费可能比首年贵不少。这件事不用太焦虑，域名本身就是细水长流的东西。如果你预算紧张，可以关注阿里云的双十一、618 这类大促节点，通常会有续费优惠券；也可以一次性续费多年，部分后缀支持长达 10 年的续费，提前锁定低价。
另一个容易被忽略的设置是"域名隐私保护"。阿里云这边默认可能不显示你的注册信息在 WHOIS 查询结果里，但如果你不需要暴露联系方式，记得检查一下是否开启了隐私保护服务。自从 GDPR 之后，很多注册商都默认开启，但保不齐有些域名后缀强制展示真实信息。如果不慎暴露，垃圾邮件和域名收购推销会接踵而至。
6. 性能和安全调优：免费套餐上限内的实用技巧
基础配置跑通之后，再分享几个我实测有效的免费套餐优化技巧，能让你的网站在不增加成本的情况下更快、更稳。
6.1 缓存规则 + Brotli 压缩的叠加效果
Cloudflare 免费版默认支持 Brotli 压缩（比 gzip 压缩率更高），但不会自动对所有内容启用。在"速度"→"优化"页面，把 Brotli 打开，同时开启"自动压缩"（Auto Minify）下的 CSS、JavaScript 和 HTML 选项。首次请求时 Cloudflare 会按压缩后的体积回源，边缘缓存的也是压缩后的版本，整体传输体积能下降不少。
我随便测了一个静态博客：未压缩的 HTML 是 12KB，开启 Brotli 后传输体积变成 3KB 左右；CSS 从 200KB 降到 60KB 左右。体积小意味着用户拿到首字节的时间更短，对移动端网络环境尤其友好。
6.2 WAF 自定义规则的三种常用配置
Cloudflare 免费版的自定义 WAF 规则（在"安全性"→"WAF"→"自定义规则"页面）虽然只有 5 条额度，但足够覆盖个人网站的常见安全需求：
- 拦截后台路径扫描：配置条件为 URI 路径包含
/wp-login.php或/admin.php（即使你没装 WordPress，攻击者也会扫这些路径），动作选"阻止"。 - 拦截异常国家来源：如果你的博客主要服务国内读者，可以设置一个规则，来源地区不在中国时执行"质询"（对用户弹出验证码）。免费版 5 条规则里这个比较占名额，可以根据情况决定是否启用。
- 频率限制（Rate Limiting）：免费版提供一条基础速率限制规则，可以针对登录接口按 IP 限制请求次数，比如每 10 秒超过 5 次就直接拦截 30 分钟。
配上这些规则后，会发现 WAF 的"事件"页面每天都有一堆被拦截的记录。不要因此慌张，这正是 WAF 在干活的证明。偶尔翻一下事件日志，把误伤的合法请求（比如自己的 IP）加入白名单即可。
6.3 Bot Fight Mode 的取舍
Cloudflare 免费版里有一个"爬虫对抗模式"（Bot Fight Mode），默认开启后会试图识别并拦截机器人流量。在个人博客环境下，我实测它对垃圾评论、采集站确实有防御作用，但对搜索引擎爬虫也有一定误伤风险。尤其是 Googlebot 的请求来源 IP 时常变化，Cloudflare 的机器学习模型偶尔会把它判成机器人。
我的取舍方案是：关闭"爬虫对抗模式"，依靠 WAF 规则里更明确的地址特征来拦截恶意请求。这样对 SEO 更友好，也让真正需要访问的爬虫不被误杀。如果你后续被采集站骚扰得厉害，再针对特定 UA 源特征单独加规则，精度更高。
7. 常见报错与排错路径：dig、curl、浏览器开发者工具的组合拳
整套方案就算配置正确，运行过程中也难免会遇到各种报错。这一节把我遇到过的最典型的几类问题和对应的排查路径整理出来，希望你能按图索骥少走冤枉路。
7.1 网站显示 521/522/523/526 错误
这些错误码都发生在 Cloudflare 回源到 Vercel 的过程中：
- 521：源站拒绝连接。最常见原因是 Vercel 项目被暂停或者自定义域名没有绑定成功。去 Vercel 控制台看 Domains 页面有没有红色的错误提示。
- 522：连接超时。Vercel 的 edge network 暂时不可达，或者 Vercel 项目的 region 不在 Cloudflare 默认回源区域。不过 Vercel 免费版总体比较稳定，这个错误相对少见。
- 523：源站不可达，一般是网络层面的问题，可以先等几分钟再刷新。
- 526：SSL 握手失败。说明 Cloudflare 回源时用 HTTPS 访问 Vercel，但证书验证不通过。回到"SSL/TLS"→"概述"，确认是"完全（严格）"模式，并确认 Vercel 侧的证书有效。
一个通用排查技巧：把 Cloudflare 的 SSL 临时改成"完全"，看看错误是否消失。如果消失，说明问题出在源站证书有效性上，而不是网络链路。但记得排查后要改回 Full (strict)，否则又回到"假健康"的状态。
7.2 DNS 已经生效但页面还是打不开
这种情况很常见：dig example.com A返回的是 Cloudflare 的 IP，但浏览器访问还是超时或者报错。优先检查几件事：
- Cloudflare 控制台里有没有配置对应的 A 记录或 CNAME 记录？如果域名在 Cloudflare 里真实存在，但没有对应记录，那么 DNS 查询结果只是 Cloudflare 的兜底页面，网站自然打不开。
- Vercel 侧的自定义域名是否成功验证？在 Vercel 的 Domains 页面，如果一个域名显示"Invalid"，说明 Vercel 拒绝为这个域名提供服务，需要检查 CNAME 目标是否正确。
- 本机 DNS 缓存是否更新？可以打开无痕窗口测试，或者切换手机 4G 网络访问，排除本地浏览器缓存干扰。
7.3 用浏览器开发者工具确认站点是否真走 Cloudflare
打开 Chrome 开发者工具 → Network → 刷新页面 → 点击主文档请求 → 查看 Response Headers。如果出现server: cloudflare和cf-ray: xxxxx这两个头，说明请求确实经过了 Cloudflare 边缘节点。如果没有这两个头，说明你在 Cloudflare 里的记录可能配成了"仅 DNS"（灰色云朵），没有开启代理。
另一个有用的是cf-cache-status头：HIT表示命中了边缘缓存，MISS表示未命中但已回源，DYNAMIC表示这个请求没有被缓存（动态内容）。我平时优化缓存规则时，就是靠这个头判断当前页面到底有没有被 Cloudflare 缓存住。
7.4 补充：Vercel 和 Cloudflare 的双层重定向问题
还有个容易遇到的现象：当你同时开启了 Vercel 侧的"强制 HTTPS"和 Cloudflare 侧的"Always Use HTTPS"时，不太会出现循环，但多余的跳转会让用户多等几百毫秒。我用curl -I实测过，请求http://example.com时返回的链路为：301（HTTP→HTTPS，由 Cloudflare 完成）→ 200（后续请求），这个链路是正常的。但如果返回了 301→301→301 的多层跳转，就说明 Vercel 和 Cloudflare 在两处都做了重定向，最好只保留一层。整体来看，个人网站保留 Cloudflare 的 Always Use HTTPS 即可，Vercel 侧可以关闭强制 HTTPS。
8. 日常运维：Free 计划的配额监控和故障自检
这套方案搭建完成后，日常运维的工作量非常小，但有几个需要定期关注的点，这里讲一下我的习惯。
8.1 Cloudflare 免费版配额怎么看
Cloudflare 免费版目前没有明确的带宽超额限制，但每天请求数有一个相当大的上限，个人博客基本不会触发。如果你担心，可以在"分析"→"流量"里看到 Web 分析数据，虽然没有直接给出请求数配额，但从页面访问量趋势能间接判断异常。如果某天访问量突然暴增，结合 WAF 事件日志查看是否有大量被拦截的请求，大概率是有人在刷你网站或者采集。
8.2 定期检查 SSL 证书状态和域名的 NS 配置
Cloudflare 的 Universal SSL 证书是自动续期的，整体不需要手工操作，但以防万一，我每月会打开一次"SSL/TLS"页面确认证书状态是"活跃"。如果哪天变成"待验证"或者 "过期"，第一件事去阿里云域名控制台看 NS 是否还是 Cloudflare 的那两个 NS 地址。出现这种情况多半是域名到期未续费、实名认证异常，或者被人为改动过 NS。
8.3 域名到期和续费的提醒策略
域名注册最怕的就是到期忘记续费被抢注。阿里云域名控制台支持开启"域名到期提醒"，可以手机短信和邮件双提醒。我个人的习惯是提前 30 天续费，同时给域名设一个自动续费功能，绑定支付宝或者银行卡，省得每次手动操作。如果你有多域名管理需求，阿里云的"域名批量管理"页面可以一次续费多个域名，比一个个点方便很多。
8.4 遇到突发故障时的排查顺序
网站突然打不开，我的排查顺序固定为：
- 先打开浏览器开发者工具看 Response Headers——有没有
server: cloudflare，有没有cf-ray。 - 如果有，说明 Cloudflare 正常，问题在回源或 Vercel 侧；如果连不掉 Cloudflare，问题在 DNS 或者网络链路。
- 用
dig example.com A查看解析结果，看是否指向 Cloudflare IP，判断 DNS 是否还在阿里云那边。 - 用
curl -I https://example.com看响应状态码，是 521 还是 522，再按 7.1 的对应表处理。 - 最后再去 Vercel 控制台看部署日志和 Domains 页面状态。
这个顺序基本覆盖了 90% 的故障场景，剩下的个例问题再开 Ticket 联系两边客服。
以上就是完整的一次"阿里云域名 + Cloudflare + Vercel"三端协作方案的全部内容。我个人实际体验下来，这套架构最重要的收获不是省下了 CDN 的钱，而是把网站安全性和可控性提升了一个档次，同时让"域名注册、DNS 安全、网站托管"三者职责清晰，各管一段。如果你也正好打算从零搭建个人项目网站，或者正在为 Vercel 裸奔的安全性发愁，可以完全按照这篇文章的步骤操作一遍。配置过程中如果遇到和我文章里描述不完全一致的情况，多半是因为 DNS 传播还没完全生效，多等一段时间再排查，不要频繁改配置，反而容易越弄越复杂。
有遇到其他奇怪问题也欢迎在评论区留言，我看到了会尽量补充到方案里。
