用CF搭建Serverless代理:0元搞定外网出口
朋友问我:你手机连不上GitHub,咋办?我:我租了个”代理”,0元。他用CF搭了个Serverless HTTP代理出口,机器在本地,路在云端——这是”为什么不上云”的姊妹篇。
TL;DR
CF Workers是Serverless的免费额度天花板:10万次请求/月、无需VPS、5分钟上线。但坑也多:.workers.dev域名解析到专用IP会不通,得绑自定义域名走CDN IP;WAF会403拦截;cfut_和cfat_ token混淆会8000096报错。用CF搭Serverless代理,不是”上云”,是”借云”——数据留在本地,出口借云穿墙。
一、起因:手机连不上GitHub
Hermes在Termux里跑,要访问GitHub、Google、DuckDuckGo。手机在国内网络,这些站点要么被墙要么不稳定。
朋友问:”你租个VPS做代理呗,一年一千多。”
我:”不用,CF有免费额度,5分钟搞定。”
这就是Serverless的价值:不用买机器,不用管运维,按量付费(免费额度内0元)。但坑也不少,今天把这套”借云穿墙”的架构和踩过的坑,摊开讲一遍。
二、CF Workers:Serverless的免费额度天花板
CF Workers的免费额度:
- 10万次请求/月,够用。Hermes日常调用(搜索、爬虫、API)一天几百次,一个月几千次,远没到上限。
- 无需VPS:代码跑在CF全球边缘节点上,没有”机器”要管。
- 5分钟上线:Dashboard里粘贴代码,点Deploy,DNS生效,完事。
对比VPS:
- VPS要买、要配、要管、要防挂。CF Workers零运维。
- VPS固定成本一年一千多。CF Workers免费额度内0元。
Serverless的核心逻辑:不用为”机器”付费,只为”跑起来的那一刻”付费。 免费额度内,跑起来也是0元。
三、架构:机器在本地,路在云端
1 | Hermes/Curl → https://proxy.dingdao.me/proxy?url=<目标URL> |
关键点:自定义域名走CDN IP(104.x),稳定。
为什么不用CF默认的.workers.dev子域名?因为它解析到Workers专用IP(173.x/108.x),某些网络不通。绑自定义域名后走CDN IP,实测稳定。
这就是”机器在本地,路在云端”:
- 机器:Hermes、数据库、日志、持仓,全在手机上。
- 路:CF Worker做HTTP代理出口,数据经CF边缘节点传到目标网站。
数据没进CF的机房,只借了CF的”路”。 这是Serverless和VPS的本质区别——你租的是”带宽”,不是”机器”。
四、踩过的坑(按频率排序)
坑1:.workers.dev域名不通
CF默认子域名解析到Workers专用IP,Termux网络不通。
解决:Dashboard → DNS → 添加CNAME(proxy.dingdao.me → Worker)→ 等1-2分钟生效。
坑2:部署后403/1010(WAF拦截)
CF的WAF默认Security Level高,会拦”可疑请求”。
解决:Dashboard → Security → WAF → Security Level调低到Low → 关Bot Fight Mode。
坑3:Error 1031(代码不完整)
CF Dashboard预览面板报1031,根因是Worker代码被截断(移动端屏幕小,一次性粘贴大段代码容易漏)。
排查:检查export default/addEventListener('fetch', ...) + async fetch + 闭合括号是否完整。
坑4:cfut_ vs cfat_ token混淆
CF有两类token:
cfut_:API Token,操作DNS/Workers/Pages/R2cfat_:R2 S3兼容令牌,只能用于R2对象存储
用cfat_调Pages API会报8000096(Token没Pages部署权限)。
排查:curl https://api.cloudflare.com/client/v4/user/tokens/verify,看permissions是否为空。
坑5:Pages Direct Upload API manifest路径错
manifest.routes[].script必须指向functions/子目录下的文件,不能放根目录。
五、实测可用站点
| 站点 | 状态 | 备注 |
|---|---|---|
| GitHub API | ✅ | 需透传User-Agent |
| Wikipedia | ✅ | 需默认UA,否则403 |
| DuckDuckGo HTML | ✅ | 网页搜索可用 |
| Bing Search | ✅ | v6自动跟随重定向 |
| Arxiv API | ✅ | 论文搜索正常 |
| HackerNews API | ✅ | JSON数据正常 |
| Google Search | ⚠️ | 代理没问题,Google自身429限流 |
| SearXNG公共实例 | ❌ | 全部403/429/Bot拦截 |
结论:CF Worker做HTTP代理出口,能覆盖90%的日常需求。 剩下的10%(Google限流、SearXNG全挂),是目标站自己的反爬,跟代理无关。
六、新设备5分钟部署
- CF Dashboard → Workers & Pages → Create Worker
- 粘贴v6模板代码,改API_KEY
- Save and Deploy
- DNS添加CNAME → 自定义域名指向Worker
- 验证:
curl https://proxy.dingdao.me/health -H "Authorization: Bearer ***"
注意:创建的是Workers不是Pages。 进错入口是新手第一坑。
七、安全提醒
- API_KEY是访问密钥:知道URL+Key的人就能用你的免费额度。定期轮换。
- Worker代码只允许http/https协议:防止SSRF。
- 敏感头过滤:Authorization/Cookie/Proxy-Authorization等不透传到目标站。
八、Serverless vs VPS:本质区别
| 维度 | VPS | CF Worker(Serverless) |
|---|---|---|
| 机器 | 租整台 | 没有机器,跑在边缘节点 |
| 成本 | 固定一年一千多 | 免费额度内0元 |
| 运维 | 配、管、防挂 | 粘贴代码,点Deploy |
| 数据 | 在VPS机房 | 留在本地,只借带宽 |
| 灵活性 | 受机器限制 | 全球边缘节点,NAT穿透 |
Serverless的核心逻辑:你租的是”带宽”,不是”机器”。 数据留在本地,出口借云穿墙。这是”为什么不上云”的正面回答——不是不上云,是只借云的路,不租云的机器。
九、CF Manager:多账户统一管理
CF免费额度最大化,一个技巧是多账户(业务隔离、额度叠加、新功能灰度)。但官方Dashboard不支持多账户统一管理。
CF Manager(开源项目)解决这个痛点:
- 多账户Zone汇总 + DNS CRUD
- 跨账户一键部署Worker
- KV/D1/R2存储管理
- 隧道和回源可视化编辑
- AI工作台(对话/文生图/TTS/翻译)
启示:CF的Serverless生态比想象中深,不只是”粘个Worker”,还有一整套多账户+存储+隧管的工具链。
十、结语:借云,不租云
朋友问”为什么不租VPS”,我现在的回答是:
VPS是租机器,CF Worker是借带宽。 数据留在手机里,出口借CF边缘节点穿墙。免费额度内0元,5分钟上线,零运维。
不是不上云,是只借云的路,不租云的机器。 这是Serverless的精髓,也是我”数据在自己手里”那条底线的延伸。
作者:小道 · 环境:Termux on Android 13 · 2026-09-26
关联阅读:《为什么不在云上跑,一台手机就是AI服务器》 · 系列:AI Agent实战笔记(技术线)