enhanced-FaaS-in-China：用一条 CNAME 换国内访问速度，但先看清这些坑

一条 CNAME 解决的是路由拥堵，不是带宽问题

部署在 Cloudflare、Vercel 或 Netlify 的网站，官方 anycast 会把中国大陆的流量大概率路由到东南亚节点，那里线路压力大，速度慢且不稳定。这个项目做的事情很简单：它维护了三个优选 CNAME 域名，分别对应三个平台，你只需把网站的 CNAME 记录改成它提供的域名，就能让国内用户访问到经过筛选的 IP。这些 IP 是项目通过定时测速挑选出来的，优先保证平均响应时间在 1 秒内，最长响应时间控制在 2 秒内，同时让返回非 200 状态码的省份尽量少于等于 2 个。注意，它优化的不是带宽，而是路由路径和稳定性。对于静态网页或轻量 API，效果明显；对于大文件下载或视频流，它帮不上忙。

工作机制：每 40 分钟测速一次，三网分流，境外走官方 IP

项目从多个来源收集 IP：Vercel 的 IP 来自公开 gist 和官方 CNAME 的 A 记录，Netlify 来自官方链接的 A 记录，Cloudflare 则收集付费用户的优选 IP。然后定时测试这些 IP 的速度，选择稳定且快的 IP 添加到域名的 A 记录。国内按电信、联通、移动三网做路线解析，国外统一使用官方提供的默认 IP，比如 Vercel 的 76.76.21.21、Netlify 的 75.2.60.5、Cloudflare 的 japan.com。整个更新周期大约是每 40 分钟一次。这个机制意味着你不需要自己维护任何脚本或服务器，项目方已经替你完成了测速和更新。但代价是你完全依赖项目方的 DNS 服务和它的判断标准，如果项目停止维护，你的 CNAME 记录会失效。

上手步骤：改 CNAME 前先确认 SSL 证书和域名托管位置

使用流程分两步。以 Vercel 为例：先把你的域名 CNAME 改为官方提供的域名，回到 Vercel 控制台确认 SSL 证书已经生成，然后再把 CNAME 改为 vercel-cname.xingpingcn.top。Netlify 对应 netlify-cname.xingpingcn.top，Cloudflare 对应 cf-cname.xingpingcn.top。这里有一个关键警告：如果你的域名托管在 Cloudflare 的 DNS 上，使用这个 CNAME 很可能遇到 403 错误。README 建议把域名托管到非 Cloudflare 平台，然后在 Cloudflare 中删除你的站点，再使用。如果必须把域名托管在 Cloudflare，比如为了用 Worker 或保护 VPS 源 IP，那么应该改用 Cloudflare 的 SaaS 功能，项目文档里有专门说明。另外，官方曾经提供过一个 verlify-cname.xingpingcn.top，但已经弃用，使用它会导致网站无法访问，因为该解析包含两个平台的 IP，平台会认为域名不属于你。

测速与验证：别用 itdog.cn，多平台交叉确认

项目 README 明确警告，不要直接用它的几个 CNAME 域名做测速，因为太多人测会被平台误判为 DDoS，虽然不影响 DNS 解析，但会产生假阴性。正确做法是：改完 CNAME 后，用多个测速网站测试，比如 boce.com、cesu.net、阿里云拨测，而不要用 itdog.cn，因为 itdog.cn 测出来的结果会出现大片的红，原因未知。测速时一定要加协议（http 或 https），并且对比多个平台的结果，因为测速网站本身也会偶尔抽风。如果你不想改 CNAME 就想预览效果，README 提供了一个方法：在测速网站上填写你的域名和项目的 CNAME 域名，模拟解析结果。这个验证步骤很重要，因为实际速度受你的域名、DNS 解析和回源方式影响，不一定能达到项目展示的测速对比效果。

已知限制：泉州被墙、华为云 DNS 误判、免费域名白名单

项目 README 列出了几个真实存在的问题。第一，浙江、福建、河南的个别 ISP 访问可能失败，目前似乎只有泉州被墙，而且官方 CNAME 也有同样问题，这可能是 ISP 限制导致的，和你的域名关系很大。第二，项目使用的华为云 DNS 存在误判风险，本来是中国大陆用户访问，却被识别为国外用户，然后解析到默认的境外路线，比如 japan.com。这意味着即使你设置了优选 CNAME，部分用户可能还是会被解析到慢速节点。第三，如果你使用免费二级域名（eu.org、us.kg）或便宜的 .xyz、.top 域名，可能因为运营商的白名单机制被墙，这种问题只能通过换域名解决。这些限制不是项目本身能修复的，你需要提前评估自己的域名和用户分布。

自定义扩展：增加新平台需要重写爬虫，不是改配置那么简单

如果你想增加第三个平台，比如 Render 或 Railway，README 说明需要自己准备测速工具和一个域名，然后重写 crawler.py，在 platforms_to_test 目录下新建一个 .py 文件，仿照其他文件重写 run_sub() 方法，最后修改 config.py 配置。这意味着项目的扩展性是有边界的：它不是一个插件化的系统，而是为三个特定平台做了硬编码。如果你对 Python 不熟悉，或者不想维护自己的测速基础设施，那么你只能使用项目提供的三个平台。另外，项目根目录下有三个 JSON 文件，里面是实时更新的 IP 列表，你可以自己同步到自己的 A 记录，但 README 提醒这些 IP 每 40 分钟更新一次，如果你手动同步，需要考虑更新频率和自动化方式。

替代方案：自己用 dnspod 或 NS1 做精准路线解析

如果你不满意项目默认的路线解析精度，README 提供了两个替代方案。一是使用 dnspod 作为权威 DNS 服务器，然后手动添加项目提供的 Vercel.json 或 Netlify.json 里的 IP 到 A 记录，按路线配置。二是使用 NS1.COM，它支持根据 ASN 进行路线解析，项目作者还维护了一个 china-mainland-asn 列表，你可以参考它来设置 ASN 规则。这两种方案的区别在于：项目默认的华为云 DNS 是按地理位置或运营商大致分流，误判率较高；而 dnspod 和 NS1 提供更精细的控制，你可以精确到具体 ASN 或省份。代价是你需要自己维护 A 记录，并且要定期更新 IP 列表，因为项目方的 IP 会每 40 分钟变化一次。如果你对国内网络环境有深入了解，并且愿意投入维护时间，这个方案更可靠。

维护与许可：MIT 协议，但依赖外部服务，停更风险需自担

项目采用 MIT 许可证，这意味着你可以自由使用、修改和分发，甚至商用，只要保留版权声明。从维护角度看，项目没有发布过正式 release，更新频率未知，但 README 显示 IP 列表每 40 分钟更新一次，说明后端有自动化任务在运行。然而，项目依赖多个外部服务：华为云 DNS、测速工具、IP 来源 gist 等。如果这些外部服务发生变化，或者项目作者停止维护，你的 CNAME 记录就会失效，网站将无法访问。因此，在使用前你应该备份官方 CNAME 记录，以便随时回滚。另外，README 提到 Netlify 支持上传自己的证书，如果遇到证书问题，可以申请一个自动续期的证书。这些操作需要你具备基本的 DNS 和证书管理知识，否则遇到问题可能无从下手。

编辑结论

如果你的网站部署在 Vercel、Netlify 或 Cloudflare Pages，且主要访客在中国大陆，这个项目值得一试。它只需要改一条 CNAME 记录，成本极低，但前提是你的域名没有托管在 Cloudflare 的 DNS 上，否则会遇到 403 错误。你还需要接受两个事实：一是泉州等个别地区可能被运营商屏蔽，这并非项目能解决的；二是它使用华为云 DNS 做路线解析，存在误判风险，可能把你的国内用户解析到境外 IP。建议先按 README 里的方法，用 boce.com 或阿里云拨测对比官方 CNAME 和优选 CNAME 的实际速度，再决定是否切换。如果你的域名是免费二级域名或便宜的 .xyz、.top，请先确认没有被运营商白名单机制屏蔽，否则换 CNAME 也无济于事。对于追求精准分路线解析的用户，这个项目默认的路线判断不够可靠，你应该自己使用 dnspod 或 NS1 并导入项目提供的 IP 列表。

官方来源

1. Official README
2. Project repository