我前两天刚把个人博客从Vercel 域名 阿里云 DNS的配置迁移到了阿里云域名 Cloudflare 托管 DNS Vercel 部署整个过程走了不少弯路尤其是 Cloudflare 和阿里云两边控制台的英文界面、DNS 传播等待、SSL 证书的奇怪状态着实折腾了几个小时。这篇文章就把我从头到尾的操作步骤、踩坑点和最终调优方案完整记录下来适合有小项目部署在 Vercel、想免费加一层 CDN 和网站防护的朋友参考。先说结论这套组合的最大价值在于把三件事分开管理——域名注册在阿里云国内访问管理方便DNS 解析和安全防护交给 Cloudflare免费套餐完全够用网站运行放在 Vercel免费部署和自动 HTTPS。三者各管一块出了问题互不牵连排查起来非常清晰。1. 为什么要在 Vercel 前面套一层 Cloudflare免费版能力边界很多人一开始不解Vercel 本身就带 HTTPS、带 CDN、带自动部署为什么还要多此一举接 Cloudflare我在实际对比之后发现Vercel 的免费方案确实够用但它在网站安全层面基本是空白尤其是这三个具体痛点缺少 Web 应用防火墙WAFVercel 免费版不提供自定义规则像恶意 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 三种加密模式区别表模式浏览器→CloudflareCloudflare→源站适用场景灵活FlexibleHTTPSHTTP源站没有 SSL 证书想省事但容易出循环问题完全FullHTTPSHTTPS但源站证书不受严格验证源站证书过期/自签名时过渡用完全严格HTTPSHTTPS且强制源站证书有效推荐使用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。根本原因通常是浏览器请求 CloudflareHTTPSCloudflare 回源到 Vercel如果开了 Flexible 模式这里走 HTTPVercel 检测到 HTTP 请求后强制跳转到 HTTPS返回给 Cloudflare 一个 301Cloudflare 又按照这个跳转再次请求 HTTPS于是形成循环。排查步骤我整理成固定顺序检查 SSL/TLS 加密模式改成完全严格这是 90% 循环问题的解法。检查 Vercel 项目设置里的强制 HTTPS开关。如果 Cloudflare 已经回源 HTTPSVercel 的强制 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和真实客户端 IPTrue-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.comURI 路径 包含/blog动作浏览器最长闲置时间设为 300 秒边缘最长闲置时间设为 300 秒然后打开忽略查询字符串配置完成保存后Concrete 页面会在 Cloudflare 边缘节点缓存 5 分钟期间相同 URL 的请求不会再回源到 Vercel。我实测下来对于个人博客这样的 TTL 设置很合适——既能保证内容更新后 5 分钟内可见又能明显减少回源次数。如果你的站点是纯静态的甚至可以把这个 TTL 拉长到 1 小时进一步降低负载。有个容易忽略的点如果你在 Vercel 侧的响应头里设置了Cache-Control: public, max-age60Cloudflare 会尊重这个响应头决定是否缓存。所以不要在两边设置互相矛盾的缓存策略否则看不出规则是否真的生效。我习惯的做法是缓存逻辑统一放在 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源站不可达一般是网络层面的问题可以先等几分钟再刷新。526SSL 握手失败。说明 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时返回的链路为301HTTP→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 传播还没完全生效多等一段时间再排查不要频繁改配置反而容易越弄越复杂。有遇到其他奇怪问题也欢迎在评论区留言我看到了会尽量补充到方案里。