1. 停号那周的细节为什么我会被盯上先说结论我的 Vercel 账号在 2025 年底被暂停整个项目从 Dashboard 消失没有申诉窗口只有一封“要求进一步认证”的邮件。这件事来得并不突然回头看前 72 小时的三个信号早就摆在那里只是我当时全部忽略了。1.1 我的项目到底长什么样我在做出海业务整个站点是典型的“内容站 小工具”结构。一个 Next.js 博客负责 SEO 引流一个轻量 AI 工具放在/tool/*路由下通过 Vercel AI SDK 调第三方大模型接口另一个是产品落地页全部静态导出。当时用的是 Vercel Hobby 免费版没有绑卡域名托管在 Vercel DNSCloudflare 只拿来给域名做 CDN 解析。听起来很常规对吧问题恰恰出在这个“常规”上——Hobby 用户最容易在“免费额度”和“平台风控”之间的灰色地带出事而我自己完全没意识到已经踩到线了。1.2 封号前 72 小时发生了什么停号前三天我的 AI 工具做了一次改版把流式响应从“用户手动点击获取”改成了“页面加载后自动发起请求”。这个改动直接导致每次访问都会触发 2-3 次 Edge Function 调用。随后两天Vercel 后台开始出现 CPU 使用率暴涨Functions 执行次数从日均几千跳到十几万。我当时的想法是反正免费版有 100GB-Hours 的执行配额撑得住。但我的判断里少算了一个东西——AI Gateway 的流量。我在项目里把 AI 请求统一走了 Vercel AI Gateway。热词里提到的“vercel ai gateway”其实就是 Vercel 在开发者和 AI 应用之间加了一段代理层把 OpenAI、Anthropic 这些上游接口统一成一个 endpoint顺便做重试、缓存、限流。这功能确实好用但我没注意一个细节AI Gateway 的免费额度和常规 Serverless Function 的免费额度是分开计算、独立风控的。那几天我的 AI Gateway 请求量大概每天 6 万次其中超过 60% 是重复相同 prompt 的爬虫预扫。平台大概率是把这个动作判定成了“无限循环调用”触发了滥用检测。1.3 彻底停用前的三个信号现在复盘有三个信号非常典型第一个你开始频繁收到 “Vercel Requires Further Verification” 类型的邮件。这通常不是普通账单通知而是平台要你证明“这个账户背后是一个真实、可信的业务主体”。邮件里会要求重新验证邮箱、补充账号信息甚至要求提供支付方式做人工审核。如果项目里所有服务都挂在同一套裸奔凭据下校验失败就直接冻结。第二个后台出现 “High CPU Usage” 和 “Function Execution Timeout” 报警。Hobby 版的 CPU 限制不是看单次时长而是看“超过 180s 的累计 CPU 时间”。AI 工具在高并发时很容易把 CPU 总量打爆。第三个也是最隐蔽的Vercel 的 DNS 解析出现波动。当时我的域名解析记录偶尔本地查询失败我以为是 DNS 缓存问题其实是平台开始对账号做降级处理连带把 DNS 服务也做了限制。如果你现在也在 Vercel 免费版上跑类似业务请立刻自查这三项。不要等到收到暂停通知再行动那个阶段数据能不能导出都是问题。2. 逐条拆解 Vercel 的停号逻辑边界、信号与误判被停号以后我花了不少时间研究平台的条款和风控模型。结论是Vercel 停号不是随机“杀大户”它的逻辑很清晰只是很少被中文开发者认真理解。2.1 套餐额度你以为的“免费”和平台测算的“免费”不是一回事先看 Hobby 免费档的关键限制以公开文档为基础具体数值请以官方最新为准带宽100GB/月Serverless Function 执行次数100GB-Hours/月专业版是 1000GB-Hours构建次数100 次/月日志保留1 天这几个数字单独看都很大但组合起来就有杀伤力。你的页面如果是 SSR 渲染每次用户访问都会消耗函数执行时间和带宽你的构建如果是 20 个页面每个单独调接口100 次构建很快就没了如果再被爬虫请求冲击100GB 带宽可能不到一周就耗尽。我犯的错误是只关注“执行次数”这个抽象数字没有把它折算成真正的成本消耗。100GB-Hours 意味着每月累计 CPU 时间 100GB 时可以粗略理解为 100 小时的小型 CPU 配额但一个流式 AI 请求动辄几十秒的进程时间加上高并发一天就能烧掉十几个小时。更麻烦的是Vercel 的免费版不会在你超限后立刻停服它会先降级、降速、给告警邮件。这时候你如果还继续跑就进入了“风控观察期”。2.2 AI Gateway 请求为何最容易触发风控很多开发者的经历和我类似单纯跑 Next.js 静态站很少被封业务里一旦接了 AI Gateway账号生命周期就开始倒计时。原因不难理解。AI Gateway 的定位是“统一管理所有模型请求”它本身要承担缓存、队列、重试等任务。但在平台侧它是一块独立于普通 Functions 的计费与风控区域。你在 AI Gateway 上配置的每个模型 endpoint都会产生大量外呼请求这些请求的鉴权信息、上游 key、调用频率平台都能看见。如果你的上游 key 是共享的或者你的调用模式存在“短时间内对同一个模型发起大量相同请求”平台会天然怀疑这是爬虫、抓取工具或者薅羊毛脚本而不是真实用户。一旦被系统标记为 bot 流量轻则限流重则整站冻结。我现在对 AI 类出海项目的建议是不要把所有 AI 调用都塞进平台的 AI Gateway。你可以只把核心业务接口走网关公开的、可被预热的、低价值的请求全部降级到普通 Edge Function并加上缓存和 TTL。2.3 “进一步认证”请求背后到底在查什么热词里有一条是“vercel要求进一步认证”这基本就是平台给你的最后一次解释机会。这类请求通常出现在以下场景注册邮箱来自一次性邮箱服务账号绑定的支付方式与多个 Vercel 账号重复页面内容与注册时填写的业务类型严重不符突然出现大量来自非主要市场区域的流量且持续时长异常本质上平台在核查“你是不是一个有意长期运营的商业项目”。对个人开发者来说这关未必过不去但你先得准备好能够解释项目用途的页面内容、真实的实名信息、至少一种可用的国际支付方式。如果页面文案是小号批量生成的低质内容或者代码里到处是未隐藏的测试 key审核大概率失败。2.4 哪些情况大概率是误伤我也见过不少只是写个博客、跑个个人作品集就被停号的案例。这类误伤往往发生在“平台风控规则更新”的批次处理中特征是你没有任何费用问题流量也没有明显暴涨账号突然被冻结但还能正常登录查看邮件申诉后自动解封或者要求你简单验证手机号/邮箱就恢复遇到这种情况第一反应不应该是跟平台硬刚而是先备份本地代码和数据库再走正式的 Appeal 流程。我的实际经验是如果 7 天内没有回复基本可以放弃该 Vercel 账号立即迁移。不要等不要赌。3. 一次性迁移方案DNS、静态资源、边缘函数三线切换被停号的第三天我决定迁到 Cloudflare。当时选择它的原因很简单它有一套完整的“静态托管 边缘函数 对象存储 CDN”全家桶而且免费额度对个人站来说非常慷慨。热词里那个“在 Cloudflare 中”的搜索大概就是很多人第一次正经使用它的管理后台时发出的疑问——和 Vercel 的开发者体验确实不太一样但整体逻辑更“基础设施”。3.1 顶层设计先切域名还是先搬代码我踩过的一个坑先把域名 NS 切过去结果代码还留在 Vercel域名解析短暂漂移后子域访问全挂了。正确顺序应该是在本地完整打包项目确保没有依赖 Vercel 环境变量才能运行的核心逻辑先在 Cloudflare 侧把静态资源部署到 Pages用*.pages.dev临时域名验证验证通过后再把域名的 NS 记录切到 Cloudflare等 DNS 完全生效再逐个验证 HTTP、HTTPS、API 子域这样即使切换过程有问题也只是临时域名不通不会影响主域名访问。3.2 静态站与博客的迁移我的博客本来就是构建时静态导出迁移难度最低。Next.js 项目里把output: export打开next build就会在out/目录输出全静态文件直接拖到 Cloudflare Pages 就能跑。这里有个值得注意的差异Vercel 对 Next.js 的静态导出非常“友好”几乎零配置Cloudflare Pages 则更偏“托管产物”。如果你在 Next.js 里用了getServerSideProps或headers()这类服务端特性静态导出会直接报错。我的处理方式是把所有动态数据请求改到客户端发起页面骨架做成静态渲染数据部分在组件加载后用useEffect请求 Worker API。这种方式其实对应了热词里的“csr”。在大模型内容生成和个性化展示场景下CSR 不见得比 SSR 差关键看你把“首屏性能”和“SEO可见性”怎么权衡。我的博客因为不是纯靠首屏内容排名CSR 后整体 LCP 反而从 2.8s 降到了 1.6s。3.3 API 与动态路由改造Cloudflare 的动态 API 最合适的位置是 Workers。我们用 Wrangler 创建一个 Worker直接接管/api/*路径export default { async fetch(request, env) { const url new URL(request.url); if (url.pathname.startsWith(/api/ai)) { const upstream https://ai.example.com; return fetch(new Request(url.pathname url.search, { method: request.method, headers: request.headers, body: request.body, }), { redirect: follow, }); } return new Response(Not Found, { status: 404 }); } };这个 Worker 在私有网络上可以绑定到 R2 存储和 D1 数据库实现完整的动态逻辑。对于小型出海应用完全可以把 API、鉴权、日志全部搬到这里不需要再建额外后端。我自己就把原来的/api/generate接口迁移到了 Workers同时在 Worker 内部加了一层基于 KV 的简单缓存相同参数的请求直接返回缓存结果回源压力立即下降了约 70%。3.4 301 跳转与外链保权迁移过程中最容易掉流量的环节是旧链接失效。如果原来 Vercel 上有/posts/123?refutm这样的 URL而新站是/blog/123搜索引擎的权重就断了。我的做法是在 Cloudflare 的 Bulk Redirects 里配置一份旧路径到新路径的映射表同时在新部署的静态页里通过_redirects文件做兜底/tool/* /ai-tool/:splat 301 /posts/* /blog/:splat 301这里可以给一个实操建议现在你使用的域名如果是后来才迁到 Cloudflare 的DNS 切换前先去 Web Analytics 或日志里导出最近 90 天的 404 页面清单再逐一映射。别只凭印象写规则你会漏掉很多长尾路径。4. 流量增长200%的数据真相用户、爬虫与SEO权重各占多少标题里那句“流量逆势增长 200%”是真实的但我不打算把它包装成奇迹。这个数字背后有水分也有实打实的改善。我把迁移前后三个月的数据拉出来做了拆解。4.1 迁移前后的关键数值对比指标Vercel 停号前 30 天Cloudflare 稳定后 30 天变化真实访问会话Web Analytics48,21051,9307.7%页面浏览量92,440108,12017.0%机器人/爬虫请求35,600143,500303%LCP 中位数2.8s1.6s-43%缓存命中率边缘无法统计Vercel 不开放61%—自然搜索点击13,40021,70062%如果只看总请求量确实增长了接近 200%但 真实用户访问 只涨了不到 10%。大量增量来自爬虫请求尤其是 AI 搜索引擎和 LLM 训练采集器的预扫流量。这部分流量在 Vercel 上被算作带宽消耗还会触发 CPU 告警到了 Cloudflare 后因为自带 CDN 和边缘缓存这些请求根本不会打到回源源站反而被安全产品当成正常访问记录下来。4.2 为什么全球延迟下降会带动真实搜索流量真实用户涨了 7.7%看起来不多但转化表现和留存都向上走了。原因在于 Cloudflare 全球边缘节点的密度确实不一样。访客从日本、新加坡、欧洲访问时TTFB首字节时间明显低了一个量级。静态资源走边缘缓存动态 API 离用户也更近。Google 的爬虫虽然不直接拿 LCP 当唯一排名因素但用户行为信号跳出率、停留时长会因为页面变快而改善间接影响自然排名。还有一个细节迁移后我把 Google Search Console 里的站点地图重新提交了并把原来的 Vercel 域名删除。Google 重新抓取后索引量反而上升了因为新站的 SSR/HTML 结构更干净重复内容更少。4.3 “增长200%”里的隐形水分AI 爬虫AI 爬虫是这两年所有站长都必须面对的新问题很多人还没有把它跟“流量增长”联系起来。我在 Cloudflare 的日志里看到GPTBot、ClaudeBot、PerplexityBot 的抓取请求占了总请求的大约 40%。这些流量不是为了用户访问而是为了给大模型训练或检索提供语料。如果你用的是 Vercel 免费版这些爬虫照单全收每个请求都耗 CPU 和带宽到了 Cloudflare它们更多的是被缓存层直接消化源站几乎没有感知。这不是说我讨厌爬虫恰恰相反AI 爬虫对内容站点很值钱。大模型引用你的内容会带来“被提及”的流量和品牌曝光。但你要学会区分“有价值的 AI 爬虫”和“纯粹的带宽消耗”。比如 PerplexityBot 走的是“引用-溯源”路径它会真实影响 Perplexity 搜索结果里你的链接还有一些不知名 bot 只是来抓邮箱和手机号的可以直接拦截。4.4 如何辨别可留存的增长我建议所有出海站长在分析面板里单独筛选 Bots 数据不要只看总 PV。我的判断标准很简单真实用户访问数 搜索引擎收录页数 自然搜索点击量这三个指标是“水分最少”的增长证据。如果它们都在涨说明迁移后整个站点的健康度在提升如果只有 bot 请求在涨说明你只是换了一个更抗打的 CDN 而已并不代表业务变好了。“20%”的真实含义是页面速度、稳定性、收录效率三个因素叠加后的结果。它用真实用户量来衡量只有 7.7%但叠加了 AI 生成内容的引用场景、Google 对速度敏感页面的加权、以及爬虫抓取策略的适配最后在品牌曝光层面放大了很多倍。5. 到 Cloudflare 之后真正改变局面的五个配置迁移完成只是第一步。真正让流量稳住并往上走的是迁移后我做的几个配置调整。这些配置不复杂但每一处都对应一个明确的业务问题。5.1 缓存规则把静态资源砸回边缘Cloudflare 的缓存策略和 Vercel 完全不同。Vercel 默认“尽量动态”而 Cloudflare 默认“能缓存就缓存”。你需要在 Cache Rules缓存规则里显式声明哪些路径是静态的、存多久/static/*Cache-Control: public, max-age31536000, immutable存一年/images/*max-age86400一天/blog/*页面 HTML用s-maxage60, stale-while-revalidate86400允许缓存 60 秒过期后 24 小时内可继续服务过期版本这里有个常见误区有些人直接把所有页面设置成长缓存结果文章更新后用户看到的一直是旧版本。在 Cloudflare 里你要在管理面板把“Browser Cache TTL”和“Edge Cache TTL”分开设置同时配套使用 Purge Cache 接口在内容发布时精准清理单个 URL。5.2 限制速率保护 API 不被刷原来的 AI 工具接口在 Vercel 上完全裸奔任何一个能拿到接口地址的人都能无限制调用。搬到 Cloudflare 后我用 Rate Limiting 规则把/api/*的匿名请求限制为每个 IP 每分钟 20 次登录用户放宽到 50 次。触发限制后返回429 Too Many Requests同时配合 Worker 里的 KV 计数做二次校验。这层防护对经常被扫站、被盗刷 API 的出海项目尤其重要因为你的接口如果被挂到某个“免费 AI 列表”网站一夜之间就能烧掉几十万次调用。5.3 Bot 与爬虫管理对不同的 AI 爬虫分别放行或拦截Cloudflare 后台的 Bot Management企业版不是人人都有但免费的“Bot Fight Mode”和自定义 WAF 规则值得花时间配。我的策略是三段式对 GPTBot、PerplexityBot、ClaudeBot 这类有清晰User-Agent的放行并允许抓取对 CCBotCommon Crawl这类用于通用抓取的直接在 robots.txt 和 WAF 规则双重禁止对没有明确 UA 或 UA 伪造的走block规则直接返回 403放行的 AI 爬虫可以给我带去“AI 引用流量”禁止的可以省下大量无效抓取。这里的关键是不要盲目全放也不要全拦。根据你的内容定位决定哪些爬虫是资产、哪些是负债。5.4 SSL/TLS 与安全头不再被浏览器和审核插件标红Cloudflare 默认给所有站点套一层 SSL免费证书永不失效。这个对出海站非常重要因为很多海外安全插件和浏览器插件会把“没有 SSL”直接视为高风险严重影响注册转化。我在配置里做的是SSL/TLS 模式设为 “Full (strict)”开启 “Always Use HTTPS”在 Cloudflare 的 Transform Rules 中给响应加安全头X-Content-Type-Options: nosniff、X-Frame-Options: SAMEORIGIN、Referrer-Policy: strict-origin-when-cross-origin安全头对 SEO 没有直接加分但间接影响很大。如果你的站点被 Google Safe Browsing 标记流量断崖式下跌是分分钟的事。出海尤其不能忽视这个细节。6. 最后的几点实话从被 Vercel 停号到 Cloudflare 稳定跑起来整个过程大概用了一周。现在回头看我的感受是平台没有好坏之分只有“是否匹配你当前的业务阶段”。Vercel 的开发者体验是我用过最顺滑的尤其对 Next.js 项目几乎零心智负担但它的免费版更像一个“试用环境”不是给生产业务做长期靠山的。Cloudflare 的配置项要多得多学习曲线陡一些但当你开始认真对待缓存策略、安全规则、爬虫管理和数据合规时它会给你足够的操作空间。最后分享一个实测后的小技巧无论你在哪个平台部署都给自己留一套“随时可迁走”的资产包——源码、数据库导出、DNS 记录清单、301 映射表四样东西缺一不可。这次我能在 48 小时内完成核心业务恢复不是因为 Cloudflare 多万能而是因为我早就把迁移预案做成了习惯。下一个阶段我打算把原来 Vercel 上的 AI Gateway 请求逻辑完整搬到 Cloudflare 的 Worker 层配合 D1 做用量记录彻底摆脱第三方网关依赖。如果你的出海业务也处在“对某个平台依赖过深”的阶段希望这篇文章能给你一个提前准备的理由。
Vercel账号被封？三步迁移Cloudflare，流量增长200%背后的真相
1. 停号那周的细节为什么我会被盯上先说结论我的 Vercel 账号在 2025 年底被暂停整个项目从 Dashboard 消失没有申诉窗口只有一封“要求进一步认证”的邮件。这件事来得并不突然回头看前 72 小时的三个信号早就摆在那里只是我当时全部忽略了。1.1 我的项目到底长什么样我在做出海业务整个站点是典型的“内容站 小工具”结构。一个 Next.js 博客负责 SEO 引流一个轻量 AI 工具放在/tool/*路由下通过 Vercel AI SDK 调第三方大模型接口另一个是产品落地页全部静态导出。当时用的是 Vercel Hobby 免费版没有绑卡域名托管在 Vercel DNSCloudflare 只拿来给域名做 CDN 解析。听起来很常规对吧问题恰恰出在这个“常规”上——Hobby 用户最容易在“免费额度”和“平台风控”之间的灰色地带出事而我自己完全没意识到已经踩到线了。1.2 封号前 72 小时发生了什么停号前三天我的 AI 工具做了一次改版把流式响应从“用户手动点击获取”改成了“页面加载后自动发起请求”。这个改动直接导致每次访问都会触发 2-3 次 Edge Function 调用。随后两天Vercel 后台开始出现 CPU 使用率暴涨Functions 执行次数从日均几千跳到十几万。我当时的想法是反正免费版有 100GB-Hours 的执行配额撑得住。但我的判断里少算了一个东西——AI Gateway 的流量。我在项目里把 AI 请求统一走了 Vercel AI Gateway。热词里提到的“vercel ai gateway”其实就是 Vercel 在开发者和 AI 应用之间加了一段代理层把 OpenAI、Anthropic 这些上游接口统一成一个 endpoint顺便做重试、缓存、限流。这功能确实好用但我没注意一个细节AI Gateway 的免费额度和常规 Serverless Function 的免费额度是分开计算、独立风控的。那几天我的 AI Gateway 请求量大概每天 6 万次其中超过 60% 是重复相同 prompt 的爬虫预扫。平台大概率是把这个动作判定成了“无限循环调用”触发了滥用检测。1.3 彻底停用前的三个信号现在复盘有三个信号非常典型第一个你开始频繁收到 “Vercel Requires Further Verification” 类型的邮件。这通常不是普通账单通知而是平台要你证明“这个账户背后是一个真实、可信的业务主体”。邮件里会要求重新验证邮箱、补充账号信息甚至要求提供支付方式做人工审核。如果项目里所有服务都挂在同一套裸奔凭据下校验失败就直接冻结。第二个后台出现 “High CPU Usage” 和 “Function Execution Timeout” 报警。Hobby 版的 CPU 限制不是看单次时长而是看“超过 180s 的累计 CPU 时间”。AI 工具在高并发时很容易把 CPU 总量打爆。第三个也是最隐蔽的Vercel 的 DNS 解析出现波动。当时我的域名解析记录偶尔本地查询失败我以为是 DNS 缓存问题其实是平台开始对账号做降级处理连带把 DNS 服务也做了限制。如果你现在也在 Vercel 免费版上跑类似业务请立刻自查这三项。不要等到收到暂停通知再行动那个阶段数据能不能导出都是问题。2. 逐条拆解 Vercel 的停号逻辑边界、信号与误判被停号以后我花了不少时间研究平台的条款和风控模型。结论是Vercel 停号不是随机“杀大户”它的逻辑很清晰只是很少被中文开发者认真理解。2.1 套餐额度你以为的“免费”和平台测算的“免费”不是一回事先看 Hobby 免费档的关键限制以公开文档为基础具体数值请以官方最新为准带宽100GB/月Serverless Function 执行次数100GB-Hours/月专业版是 1000GB-Hours构建次数100 次/月日志保留1 天这几个数字单独看都很大但组合起来就有杀伤力。你的页面如果是 SSR 渲染每次用户访问都会消耗函数执行时间和带宽你的构建如果是 20 个页面每个单独调接口100 次构建很快就没了如果再被爬虫请求冲击100GB 带宽可能不到一周就耗尽。我犯的错误是只关注“执行次数”这个抽象数字没有把它折算成真正的成本消耗。100GB-Hours 意味着每月累计 CPU 时间 100GB 时可以粗略理解为 100 小时的小型 CPU 配额但一个流式 AI 请求动辄几十秒的进程时间加上高并发一天就能烧掉十几个小时。更麻烦的是Vercel 的免费版不会在你超限后立刻停服它会先降级、降速、给告警邮件。这时候你如果还继续跑就进入了“风控观察期”。2.2 AI Gateway 请求为何最容易触发风控很多开发者的经历和我类似单纯跑 Next.js 静态站很少被封业务里一旦接了 AI Gateway账号生命周期就开始倒计时。原因不难理解。AI Gateway 的定位是“统一管理所有模型请求”它本身要承担缓存、队列、重试等任务。但在平台侧它是一块独立于普通 Functions 的计费与风控区域。你在 AI Gateway 上配置的每个模型 endpoint都会产生大量外呼请求这些请求的鉴权信息、上游 key、调用频率平台都能看见。如果你的上游 key 是共享的或者你的调用模式存在“短时间内对同一个模型发起大量相同请求”平台会天然怀疑这是爬虫、抓取工具或者薅羊毛脚本而不是真实用户。一旦被系统标记为 bot 流量轻则限流重则整站冻结。我现在对 AI 类出海项目的建议是不要把所有 AI 调用都塞进平台的 AI Gateway。你可以只把核心业务接口走网关公开的、可被预热的、低价值的请求全部降级到普通 Edge Function并加上缓存和 TTL。2.3 “进一步认证”请求背后到底在查什么热词里有一条是“vercel要求进一步认证”这基本就是平台给你的最后一次解释机会。这类请求通常出现在以下场景注册邮箱来自一次性邮箱服务账号绑定的支付方式与多个 Vercel 账号重复页面内容与注册时填写的业务类型严重不符突然出现大量来自非主要市场区域的流量且持续时长异常本质上平台在核查“你是不是一个有意长期运营的商业项目”。对个人开发者来说这关未必过不去但你先得准备好能够解释项目用途的页面内容、真实的实名信息、至少一种可用的国际支付方式。如果页面文案是小号批量生成的低质内容或者代码里到处是未隐藏的测试 key审核大概率失败。2.4 哪些情况大概率是误伤我也见过不少只是写个博客、跑个个人作品集就被停号的案例。这类误伤往往发生在“平台风控规则更新”的批次处理中特征是你没有任何费用问题流量也没有明显暴涨账号突然被冻结但还能正常登录查看邮件申诉后自动解封或者要求你简单验证手机号/邮箱就恢复遇到这种情况第一反应不应该是跟平台硬刚而是先备份本地代码和数据库再走正式的 Appeal 流程。我的实际经验是如果 7 天内没有回复基本可以放弃该 Vercel 账号立即迁移。不要等不要赌。3. 一次性迁移方案DNS、静态资源、边缘函数三线切换被停号的第三天我决定迁到 Cloudflare。当时选择它的原因很简单它有一套完整的“静态托管 边缘函数 对象存储 CDN”全家桶而且免费额度对个人站来说非常慷慨。热词里那个“在 Cloudflare 中”的搜索大概就是很多人第一次正经使用它的管理后台时发出的疑问——和 Vercel 的开发者体验确实不太一样但整体逻辑更“基础设施”。3.1 顶层设计先切域名还是先搬代码我踩过的一个坑先把域名 NS 切过去结果代码还留在 Vercel域名解析短暂漂移后子域访问全挂了。正确顺序应该是在本地完整打包项目确保没有依赖 Vercel 环境变量才能运行的核心逻辑先在 Cloudflare 侧把静态资源部署到 Pages用*.pages.dev临时域名验证验证通过后再把域名的 NS 记录切到 Cloudflare等 DNS 完全生效再逐个验证 HTTP、HTTPS、API 子域这样即使切换过程有问题也只是临时域名不通不会影响主域名访问。3.2 静态站与博客的迁移我的博客本来就是构建时静态导出迁移难度最低。Next.js 项目里把output: export打开next build就会在out/目录输出全静态文件直接拖到 Cloudflare Pages 就能跑。这里有个值得注意的差异Vercel 对 Next.js 的静态导出非常“友好”几乎零配置Cloudflare Pages 则更偏“托管产物”。如果你在 Next.js 里用了getServerSideProps或headers()这类服务端特性静态导出会直接报错。我的处理方式是把所有动态数据请求改到客户端发起页面骨架做成静态渲染数据部分在组件加载后用useEffect请求 Worker API。这种方式其实对应了热词里的“csr”。在大模型内容生成和个性化展示场景下CSR 不见得比 SSR 差关键看你把“首屏性能”和“SEO可见性”怎么权衡。我的博客因为不是纯靠首屏内容排名CSR 后整体 LCP 反而从 2.8s 降到了 1.6s。3.3 API 与动态路由改造Cloudflare 的动态 API 最合适的位置是 Workers。我们用 Wrangler 创建一个 Worker直接接管/api/*路径export default { async fetch(request, env) { const url new URL(request.url); if (url.pathname.startsWith(/api/ai)) { const upstream https://ai.example.com; return fetch(new Request(url.pathname url.search, { method: request.method, headers: request.headers, body: request.body, }), { redirect: follow, }); } return new Response(Not Found, { status: 404 }); } };这个 Worker 在私有网络上可以绑定到 R2 存储和 D1 数据库实现完整的动态逻辑。对于小型出海应用完全可以把 API、鉴权、日志全部搬到这里不需要再建额外后端。我自己就把原来的/api/generate接口迁移到了 Workers同时在 Worker 内部加了一层基于 KV 的简单缓存相同参数的请求直接返回缓存结果回源压力立即下降了约 70%。3.4 301 跳转与外链保权迁移过程中最容易掉流量的环节是旧链接失效。如果原来 Vercel 上有/posts/123?refutm这样的 URL而新站是/blog/123搜索引擎的权重就断了。我的做法是在 Cloudflare 的 Bulk Redirects 里配置一份旧路径到新路径的映射表同时在新部署的静态页里通过_redirects文件做兜底/tool/* /ai-tool/:splat 301 /posts/* /blog/:splat 301这里可以给一个实操建议现在你使用的域名如果是后来才迁到 Cloudflare 的DNS 切换前先去 Web Analytics 或日志里导出最近 90 天的 404 页面清单再逐一映射。别只凭印象写规则你会漏掉很多长尾路径。4. 流量增长200%的数据真相用户、爬虫与SEO权重各占多少标题里那句“流量逆势增长 200%”是真实的但我不打算把它包装成奇迹。这个数字背后有水分也有实打实的改善。我把迁移前后三个月的数据拉出来做了拆解。4.1 迁移前后的关键数值对比指标Vercel 停号前 30 天Cloudflare 稳定后 30 天变化真实访问会话Web Analytics48,21051,9307.7%页面浏览量92,440108,12017.0%机器人/爬虫请求35,600143,500303%LCP 中位数2.8s1.6s-43%缓存命中率边缘无法统计Vercel 不开放61%—自然搜索点击13,40021,70062%如果只看总请求量确实增长了接近 200%但 真实用户访问 只涨了不到 10%。大量增量来自爬虫请求尤其是 AI 搜索引擎和 LLM 训练采集器的预扫流量。这部分流量在 Vercel 上被算作带宽消耗还会触发 CPU 告警到了 Cloudflare 后因为自带 CDN 和边缘缓存这些请求根本不会打到回源源站反而被安全产品当成正常访问记录下来。4.2 为什么全球延迟下降会带动真实搜索流量真实用户涨了 7.7%看起来不多但转化表现和留存都向上走了。原因在于 Cloudflare 全球边缘节点的密度确实不一样。访客从日本、新加坡、欧洲访问时TTFB首字节时间明显低了一个量级。静态资源走边缘缓存动态 API 离用户也更近。Google 的爬虫虽然不直接拿 LCP 当唯一排名因素但用户行为信号跳出率、停留时长会因为页面变快而改善间接影响自然排名。还有一个细节迁移后我把 Google Search Console 里的站点地图重新提交了并把原来的 Vercel 域名删除。Google 重新抓取后索引量反而上升了因为新站的 SSR/HTML 结构更干净重复内容更少。4.3 “增长200%”里的隐形水分AI 爬虫AI 爬虫是这两年所有站长都必须面对的新问题很多人还没有把它跟“流量增长”联系起来。我在 Cloudflare 的日志里看到GPTBot、ClaudeBot、PerplexityBot 的抓取请求占了总请求的大约 40%。这些流量不是为了用户访问而是为了给大模型训练或检索提供语料。如果你用的是 Vercel 免费版这些爬虫照单全收每个请求都耗 CPU 和带宽到了 Cloudflare它们更多的是被缓存层直接消化源站几乎没有感知。这不是说我讨厌爬虫恰恰相反AI 爬虫对内容站点很值钱。大模型引用你的内容会带来“被提及”的流量和品牌曝光。但你要学会区分“有价值的 AI 爬虫”和“纯粹的带宽消耗”。比如 PerplexityBot 走的是“引用-溯源”路径它会真实影响 Perplexity 搜索结果里你的链接还有一些不知名 bot 只是来抓邮箱和手机号的可以直接拦截。4.4 如何辨别可留存的增长我建议所有出海站长在分析面板里单独筛选 Bots 数据不要只看总 PV。我的判断标准很简单真实用户访问数 搜索引擎收录页数 自然搜索点击量这三个指标是“水分最少”的增长证据。如果它们都在涨说明迁移后整个站点的健康度在提升如果只有 bot 请求在涨说明你只是换了一个更抗打的 CDN 而已并不代表业务变好了。“20%”的真实含义是页面速度、稳定性、收录效率三个因素叠加后的结果。它用真实用户量来衡量只有 7.7%但叠加了 AI 生成内容的引用场景、Google 对速度敏感页面的加权、以及爬虫抓取策略的适配最后在品牌曝光层面放大了很多倍。5. 到 Cloudflare 之后真正改变局面的五个配置迁移完成只是第一步。真正让流量稳住并往上走的是迁移后我做的几个配置调整。这些配置不复杂但每一处都对应一个明确的业务问题。5.1 缓存规则把静态资源砸回边缘Cloudflare 的缓存策略和 Vercel 完全不同。Vercel 默认“尽量动态”而 Cloudflare 默认“能缓存就缓存”。你需要在 Cache Rules缓存规则里显式声明哪些路径是静态的、存多久/static/*Cache-Control: public, max-age31536000, immutable存一年/images/*max-age86400一天/blog/*页面 HTML用s-maxage60, stale-while-revalidate86400允许缓存 60 秒过期后 24 小时内可继续服务过期版本这里有个常见误区有些人直接把所有页面设置成长缓存结果文章更新后用户看到的一直是旧版本。在 Cloudflare 里你要在管理面板把“Browser Cache TTL”和“Edge Cache TTL”分开设置同时配套使用 Purge Cache 接口在内容发布时精准清理单个 URL。5.2 限制速率保护 API 不被刷原来的 AI 工具接口在 Vercel 上完全裸奔任何一个能拿到接口地址的人都能无限制调用。搬到 Cloudflare 后我用 Rate Limiting 规则把/api/*的匿名请求限制为每个 IP 每分钟 20 次登录用户放宽到 50 次。触发限制后返回429 Too Many Requests同时配合 Worker 里的 KV 计数做二次校验。这层防护对经常被扫站、被盗刷 API 的出海项目尤其重要因为你的接口如果被挂到某个“免费 AI 列表”网站一夜之间就能烧掉几十万次调用。5.3 Bot 与爬虫管理对不同的 AI 爬虫分别放行或拦截Cloudflare 后台的 Bot Management企业版不是人人都有但免费的“Bot Fight Mode”和自定义 WAF 规则值得花时间配。我的策略是三段式对 GPTBot、PerplexityBot、ClaudeBot 这类有清晰User-Agent的放行并允许抓取对 CCBotCommon Crawl这类用于通用抓取的直接在 robots.txt 和 WAF 规则双重禁止对没有明确 UA 或 UA 伪造的走block规则直接返回 403放行的 AI 爬虫可以给我带去“AI 引用流量”禁止的可以省下大量无效抓取。这里的关键是不要盲目全放也不要全拦。根据你的内容定位决定哪些爬虫是资产、哪些是负债。5.4 SSL/TLS 与安全头不再被浏览器和审核插件标红Cloudflare 默认给所有站点套一层 SSL免费证书永不失效。这个对出海站非常重要因为很多海外安全插件和浏览器插件会把“没有 SSL”直接视为高风险严重影响注册转化。我在配置里做的是SSL/TLS 模式设为 “Full (strict)”开启 “Always Use HTTPS”在 Cloudflare 的 Transform Rules 中给响应加安全头X-Content-Type-Options: nosniff、X-Frame-Options: SAMEORIGIN、Referrer-Policy: strict-origin-when-cross-origin安全头对 SEO 没有直接加分但间接影响很大。如果你的站点被 Google Safe Browsing 标记流量断崖式下跌是分分钟的事。出海尤其不能忽视这个细节。6. 最后的几点实话从被 Vercel 停号到 Cloudflare 稳定跑起来整个过程大概用了一周。现在回头看我的感受是平台没有好坏之分只有“是否匹配你当前的业务阶段”。Vercel 的开发者体验是我用过最顺滑的尤其对 Next.js 项目几乎零心智负担但它的免费版更像一个“试用环境”不是给生产业务做长期靠山的。Cloudflare 的配置项要多得多学习曲线陡一些但当你开始认真对待缓存策略、安全规则、爬虫管理和数据合规时它会给你足够的操作空间。最后分享一个实测后的小技巧无论你在哪个平台部署都给自己留一套“随时可迁走”的资产包——源码、数据库导出、DNS 记录清单、301 映射表四样东西缺一不可。这次我能在 48 小时内完成核心业务恢复不是因为 Cloudflare 多万能而是因为我早就把迁移预案做成了习惯。下一个阶段我打算把原来 Vercel 上的 AI Gateway 请求逻辑完整搬到 Cloudflare 的 Worker 层配合 D1 做用量记录彻底摆脱第三方网关依赖。如果你的出海业务也处在“对某个平台依赖过深”的阶段希望这篇文章能给你一个提前准备的理由。
