深度解析：Vercel 为什么会被墙？从 SNI 阻断看 Serverless 时代的“连坐”逻辑
对于国内的前端开发者来说，Vercel 几乎是部署个人博客、开源文档和 Next.js 项目的“默认选项”。然而，许多人在兴冲冲地拿到 xxx.vercel.app 的链接后，却发现一个残酷的现实：国内访客根本打不开你的网站。
很多人的第一反应是：“Vercel 这么好用的技术平台，GFW（防火长城）为什么要针对它？”
事实上，这是一个巨大的认知误区。GFW 根本不在乎 Vercel 这家公司，它甚至不知道 Vercel 是干嘛的。GFW 真正封锁的，是 Vercel 提供的“免费共享域名（*.vercel.app）”。
这篇文章，我们将剥开网络封锁的技术外衣，从底层协议、审查逻辑到基础设施的商业模式，深度剖析这场发生在 Serverless 时代的“猫鼠游戏”。
一、 从“技术圣地”到“法外之地”：Vercel 的原罪
要理解 Vercel 为什么被盯上，首先要明白它提供了怎样“诱人”的基础设施。作为一个现代化的前端部署平台，Vercel 拥有三个让开发者狂喜，但也让审查机制极其头疼的特性：
- 零门槛与免备案：在国内，提供任何 Web 服务都必须经过严格的 ICP 备案。但 Vercel 作为海外服务，只需一个邮箱即可注册，瞬间生成一个全球可访问的子域名。
- 强制 HTTPS 加密：Vercel 默认配置最高级别的 SSL 证书，所有数据传输均被加密。
- Serverless / Edge Functions：允许开发者编写后端逻辑，并分发到全球边缘节点运行。
当“免费、免备案、加密、可执行后端代码”这四个要素叠加时，Vercel 不可避免地沦为了互联网上的“公共厕所”。
大量用户利用 Vercel 的 Edge Functions 配合 WebSocket 协议，搭建免费的 V2Ray/Trojan 翻墙节点，白嫖 Vercel 的全球 CDN 流量；同时，由于 *.vercel.app 域名可以随时生成、随时抛弃，它也成为了博彩、钓鱼、色情等灰黑产网站的天然温床。
当每天有几百万条指向 *.vercel.app 的请求中，混杂着大量翻墙和违规流量时，GFW 的自动化审查机制必然会将其标记为“高危目标”。
二、 GFW 的技术困境与“连坐”逻辑
既然 vercel.app 下藏污纳垢，GFW 为什么不精准打击违规网站，非要连累写正经博客的普通开发者？这背后是 GFW 面临的巨大技术困境，以及最终选择的“连坐”策略。
1. 封 IP？投鼠忌器
Vercel 本身并不拥有庞大的物理机房，其底层基础设施大量依赖 AWS（亚马逊云）和 Cloudflare 等巨头。如果 GFW 简单粗暴地拉黑 Vercel 使用的 IP 段，将导致无数正常的跨国企业、跨境电商甚至外企的中国区业务瞬间瘫痪。为了封堵几个翻墙节点而切断国际贸易的数字动脉，这个代价是不可接受的。
2. 看内容？HTTPS 加密导致 DPI 失效
在 HTTP 时代，GFW 可以通过 DPI（深度包检测）技术，扫描网页内容中的“敏感词”进行精准阻断。但在 Vercel 全面 HTTPS 化的今天，传输内容对中间人而言只是一堆乱码。GFW 无法区分你是在传输正常的 React 代码，还是在传输翻墙协议的数据包。
3. 终极杀招：SNI 阻断（连坐机制）
封 IP 会误伤，看内容又看不见，GFW 最终将目光锁定了 TLS 协议的一个设计缺陷：SNI（Server Name Indication）。
在建立 HTTPS 连接的 TLS 握手第一阶段，客户端必须明文发送 SNI 字段，告诉服务器“我要访问哪个域名”（例如 myblog.vercel.app），以便服务器返回正确的证书。
GFW 的逻辑变得非常简单：
“我虽然看不见你们加密传输的内容，但我看到每天有海量 SNI 请求指向
*.vercel.app，且其中包含大量违规流量。既然无法精准剥离，那我就直接把vercel.app这个字符串加入 SNI 黑名单！”
这就是“连坐”的本质。 只要你的 TLS 握手请求中带有 vercel.app，GFW 就会立刻伪造 RST（重置）包，强行掐断连接。你的技术博客和别人的翻墙节点，在 GFW 的黑名单机制下，共享了同一份“死刑判决书”。
三、 被一锅端的“白嫖圈”
如果你认为只有 Vercel 遭遇了这种待遇，那就太小看 GFW 的黑名单厚度了。事实上，整个“免备案 Serverless 白嫖圈”都未能幸免：
- **GitHub Pages (
*.github.io)**：因被大量用于搭建翻墙节点和敏感内容，github.io早就遭遇了严重的 SNI 阻断和 DNS 污染。 - **Netlify (
*.netlify.app)**：Vercel 的直接竞品，同样的免费配方，同样的 SNI 阻断待遇。 - **Cloudflare Pages (
*.pages.dev) / Workers (*.workers.dev)**：由于搭建代理节点过于便利，CF 的默认子域名在国内也是重点照顾对象。
发现规律了吗？GFW 封锁的从来不是某一家具体的科技公司，而是“免费 + 免备案 + 提供共享子域名”这种商业模式。 在这种模式下，平台无法（或不愿）承担内容审查的成本，最终只能由防火墙在边界上进行一刀切的兜底。
四、 破局与启示：自定义域名的“护城河”效应
理解了底层逻辑，破局之道便呼之欲出。为什么技术圈公认的最佳实践是 “花 10 块钱买个自定义域名，绑定到 Vercel 上”？
当你把域名从 myblog.vercel.app 换成 blog.yourdomain.com 时，你实际上在 GFW 面前完成了一次 “身份洗白”：
- 脱离连坐：你的 TLS 握手 SNI 变成了干净的
blog.yourdomain.com。GFW 的黑名单里没有这个域名，连接自然畅通无阻。（注：需配合 Cloudflare 等 CDN 开启代理模式，隐藏 Vercel 的真实 IP，防止 IP 被连带封锁）。 - 建立数字主权：你不再是
vercel.app这个“公共厕所”里的一个隔间，而是拥有了自己的“私人别墅”。只要你的网站本身不涉及违规内容，GFW 的自动化爬虫和黑名单机制根本不会注意到你。
免费的，往往是最贵的
Vercel 被墙的事件，给所有开发者上了一堂深刻的基础设施课。
在技术世界里，“免费”往往意味着你让渡了部分控制权，并与其他用户共享了声誉风险。 当你使用平台的默认子域名时，你实际上是在为平台上那些滥用规则的人“背书”，并随时准备为他们承担被连坐封锁的代价。
花几十块钱一年注册一个属于自己的域名，不仅是为了绕过 GFW 的 SNI 阻断，更是作为一个独立开发者，保护自己代码主权、建立个人品牌的最廉价、也最有效的护城河。
基础设施的尽头是妥协与规范。别再抱怨 Vercel 为什么被墙了，去买个域名，把命运握在自己手里吧。