Cloudflare 免费备用线路入门：PROXYIP、VPS 到底怎么选？

重要提醒：

• 本文只讨论个人学习、开发测试和备用线路思路。
• Cloudflare 条款明确限制在未获书面许可时使用其服务提供 VPN 或类似代理服务。本文仅讨论个人学习和网络测试思路，不建议将 Workers/Pages 部署成对外或长期使用的代理服务；发布和使用前请自行核对 Cloudflare 条款、所在地法律法规、公司/学校网络政策和目标服务政策。
• 公共 PROXYIP 不可信，不建议处理支付、客户数据、生产 API Key 或其他敏感信息。

今天我测试了一轮基于 Cloudflare Workers/Pages 的免费备用线路，也顺手把它和 VPS 方案做了对比。最后得到的经验是：

• Cloudflare + edgetunnel + 合适的 PROXYIP，可以作为低成本备用方案。
• PROXYIP 主要影响“Worker 到目标网站”的出口质量，不是万能加速开关。
• 美国西海岸节点值得作为第一轮候选，但不是固定答案，最终要看实测。
• 长时间跑 Codex、Claude Code、OpenClaw 这类任务，质量合格的 VPS 通常更可控。

我们今天的最后一轮测试里，Codex、OpenAI、Claude、GitHub、npm 的短请求都能稳定返回；但海外 ping 仍有丢包，大文件下载出现过超时。所以它适合备用和短任务，不适合直接当成长期生产线路。

一、先搞清楚：这个免费方案到底是什么？

我们用的是开源项目 edgetunnel：

https://github.com/cmliu/edgetunnel

它的思路是：把一段代理程序部署到 Cloudflare Workers 或 Cloudflare Pages 上。客户端先通过代理协议连到 Cloudflare，再由 Worker 使用出站 TCP 能力访问目标主机或服务。这里的“目标服务”可以理解为 OpenAI、Claude、GitHub、npm 等地址。

你可以先把路径理解成：

你的电脑/手机
  -> Clash / Sing-box / Shadowrocket 等客户端
  -> Cloudflare 入口节点
  -> edgetunnel Worker
  -> 目标网站

但这里有一个小白最容易误解的地方：Worker 不是一台 VPS，也不是你完全拥有的服务器。它是运行在 Cloudflare 平台上的边缘函数，能做什么连接、能跑多久、能用多少资源，都受 Cloudflare 规则限制。

Cloudflare 官方文档里，Workers TCP sockets 的 connect() 是出站 TCP 能力，不是让 Worker 变成通用入站 TCP 服务器；同时它不能连 Cloudflare 自有 IP、localhost、私网地址等目标，25 端口也默认不可用。白话说：它不是万能转发器，有些目标天然连不了，不是你操作错了。

Workers 免费计划还有请求数、CPU、内存和单次请求内同时建立的出站连接上限，TCP socket、fetch、KV 等都会消耗相关连接额度。长连接也不是无限可靠：客户端断开、平台运行时更新、资源限制都可能中断请求。

官方资料：

• TCP sockets：https://developers.cloudflare.com/workers/runtime-apis/tcp-sockets/
• Workers limits：https://developers.cloudflare.com/workers/platform/limits/
• Cloudflare terms：https://www.cloudflare.com/terms/

这就引出了今天最关键的配置：PROXYIP。

二、PROXYIP 是什么？

小白先记住一句话：

优选 IP 管入口，PROXYIP 管出口。

更完整的路径是：

你的电脑/手机
  -> Cloudflare 入口/优选 IP
  -> edgetunnel Worker
  -> PROXYIP / 上游反代
  -> OpenAI / Claude / GitHub / npm

优选 IP 主要影响“你本地到 Cloudflare”的入口质量。PROXYIP 主要影响“Cloudflare Worker 到目标服务”的出口质量。

edgetunnel 里的 PROXYIP 更准确地说，是一个上游反代/中转地址。当 Worker 直连目标失败、被限制，或者效果不好时，它可以把连接交给 PROXYIP 再访问目标服务。

但 PROXYIP 只能在 edgetunnel 支持的上游转发模式下生效，不是绕过所有 Cloudflare socket 限制的万能方案。

所以，如果你的 PROXYIP 选得不好，可能会出现：

• Codex 或 Claude 短对话能用，一跑长任务就断。
• GitHub 首页能打开，但 raw.githubusercontent.com 拉文件慢。
• npm registry 能返回，但安装包时超时。
• TLS 握手失败、连接重置、下载速度忽快忽慢。

公共 PROXYIP 通常不是 Cloudflare 官方资源，你无法确认它是谁维护、是否记录元数据、是否被滥用、是否被目标服务风控。目标服务看到的出口 IP 可能就是这个公共上游，IP 信誉会直接影响 OpenAI、Anthropic、GitHub、npm 的风控、限速或封禁结果。它适合临时测试，不适合长期承载敏感账号和生产任务。

三、这次测试给出的经验

这次测试不是实验室基准，只是一次实际使用环境下的经验样本。样本条件是：本地 WSL/Clash Verge 代理环境，经 Cloudflare/edgetunnel 方案访问 AI 和开发工具服务，重点观察短请求成功率、响应时间、GitHub/npm 可达性和下载稳定性。测试目标主要是：

• Codex 服务地址
• OpenAI API
• Claude / Anthropic API
• GitHub
• raw.githubusercontent.com
• registry.npmjs.org
• 小文件和 10MB 级下载

最后一轮大概表现是：

• Codex、OpenAI、Claude、GitHub、npm 短请求都成功。
• Claude/OpenAI/Codex 响应大多在几秒内返回。
• GitHub/raw 请求能成功，但比 API 请求慢。
• 10MB 下载出现过 60 秒超时，也出现过低速完成。
• 海外 ICMP ping 仍有丢包。

所以我的判断是：它可以作为 AI 工具的备用线路，也可以做短任务；但不适合长时间无人值守跑任务。

这次比较有价值的经验是：当用途是 OpenAI、Claude、Codex、GitHub、npm 时，美国西海岸节点值得作为第一轮候选区域，例如 Los Angeles、San Jose、San Francisco、Seattle。我们测试到的几个西海岸节点比部分亚洲节点更稳定，目标服务也更倾向按美国出口处理；但这取决于 IP 地理库、ASN、IP 信誉和目标服务策略。

但这不是铁律。日本、新加坡、美国中部、美国东部也都可以测。最终判断标准不是节点名字，而是：

PROXYIP -> 你的目标服务

这一段是否稳定。

四、免费方案适合谁？

适合：

• 想学习 Cloudflare Workers、代理入口、出口节点这些概念的人。
• 需要一个临时备用线路的人。
• 偶尔访问 OpenAI、Claude、GitHub、npm 的个人用户。
• 还不确定自己是否需要 VPS 的新手。

不适合：

• 长时间无人值守跑 Codex、Claude Code、OpenClaw。
• 大量下载 GitHub release、Docker 镜像、npm 包。
• 多人共享、高并发、大流量。
• 处理生产账号、客户数据、支付信息、公司机密。

平台限制也要单独记住：Cloudflare 免费 Workers 有每日请求限制、CPU/内存限制、单次请求内出站连接限制，免费服务也可能因为条款或平台策略变化而不可用。这类限制不是“你配置错了”，而是平台边界。

五、开始前确认清单

动手前先确认你有这些东西：

• 一个 Cloudflare 账号。
• 一个可以托管到 Cloudflare 的域名，建议用二级域名。
• 一个代理客户端：Clash Verge、Sing-box、Shadowrocket、Surge 等。
• 一个自己记得住但别人猜不到的后台密码。
• 基本安全意识：不截图泄露订阅链接，不把密码写进公开仓库。

小白建议从 Pages 上传或 GitHub 连接部署开始，比手动管理 Worker 更直观。

再强调一遍：不要对外提供、转售或公开共享这类服务；公共节点只做临时测试，不要承载敏感数据。

六、Cloudflare + edgetunnel 免费搭建流程概览

下面是搭建流程概览，不是逐按钮截图教程。不同版本界面会变，具体部署字段以 edgetunnel README 和 Cloudflare 当前后台提示为准；如果你是第一次操作，建议优先走 GitHub Fork 后连接 Pages 这条路线。

1. 准备项目

打开 edgetunnel 项目：

https://github.com/cmliu/edgetunnel

你可以选择多种部署方式，但新手建议只走一条主线：

Fork edgetunnel -> Cloudflare Pages 连接 GitHub 仓库 -> 配置 ADMIN 和 KV -> 重新部署 -> 绑定自定义域名

熟悉 Worker 的用户，也可以直接用 _worker.js 部署 Workers。下载压缩包上传 Pages 也能做，但不同版本和 Cloudflare 页面会有细节差异，小白更容易卡在上传范围、构建命令和输出目录上。

2. 创建 Cloudflare Pages 项目

在 Cloudflare 后台大致路径是：

Workers & Pages -> Create application -> Pages

如果按新手主线，选择连接 GitHub，并选中你 Fork 后的 edgetunnel 仓库。部署成功后，先不要急着导入客户端，先配置变量和 KV。变量或 KV 改完后，通常要重新部署一次，生产环境才会拿到最新配置。

3. 设置管理员密码

在项目设置里找到环境变量，大致路径是：

Workers & Pages -> 你的项目 -> Settings -> Environment variables

添加变量：

ADMIN=你的强密码

注意：

• 不要用弱密码。
• 不要把 ADMIN 写进公开 GitHub 仓库。
• 不要截图发到群里。
• 如果有 Production/Preview 环境区分，正式使用要确认变量设置在生产环境。

4. 创建并绑定 KV

先创建 KV namespace，再绑定到项目。

大致路径：

Workers & Pages -> KV -> Create namespace

然后回到你的 Pages/Workers 项目：

Settings -> Bindings -> Add binding -> KV namespace

变量名通常填：

KV

KV 绑定后，重新部署一次项目。

5. 绑定自定义域名

建议用二级域名，例如：

proxy.example.com

Cloudflare 项目里找到 Custom domains，按提示添加域名并等待证书生效。

如果域名还不在 Cloudflare 管理，需要先把域名 DNS 接入 Cloudflare，或按提示添加 CNAME 记录。不要直接用根域名，也不要把代理后台和你公开网站混在同一个域名上。

6. 登录后台

访问：

https://proxy.example.com/admin

输入你设置的 ADMIN 密码。

如果打不开后台，优先检查：

问题	先检查
域名打不开	DNS 是否生效、证书是否生效、Pages 是否部署成功
后台密码不对	ADMIN 是否设置在生产环境、是否重新部署
配置保存失败	KV 是否创建并绑定为 KV
订阅导入失败	订阅格式是否选对、客户端是否支持该协议
节点能连但 OpenAI/GitHub 慢	PROXYIP 或出口质量

7. 生成订阅并导入客户端

后台一般会提供 Clash、Sing-box、Surge 等订阅。选择你客户端支持的格式导入。不知道选哪个时，Clash Verge 先选 Clash，sing-box 客户端选 sing-box，Shadowrocket/Surge 选对应名称。

导入后不要只看客户端里的延迟，那个通常只能说明入口还行。你还要测真实目标站。

七、高级重点：PROXYIP 怎么选？

后台通常会有 PROXYIP 配置项，可以填一个或多个地址。

常见格式：

1.2.3.4

或者：

1.2.3.4:443

多个地址一般用英文逗号隔开：

1.2.3.4,5.6.7.8,9.10.11.12

具体格式以你使用的项目版本说明为准。

选择思路：

• 第一轮可以测美国西海岸：Los Angeles、San Jose、San Francisco、Seattle。
• 同时保留日本、新加坡、美国中部/东部作为对照。
• 不要只看延迟，重点看 OpenAI、Claude、GitHub、npm 是否稳定。
• 不要长期依赖来路不明的公共 PROXYIP。
• 不要在随机群聊、评论区批量复制公共 PROXYIP；优先用自己可信 VPS，公共节点只做临时测试。

如果你填了多个 PROXYIP，要记录每次测试到底使用的是哪一个，否则后面很难判断哪个节点真正好。

八、怎么测试才靠谱？

不建议只用测速网站。尤其是 Cloudflare 自家的测速站，它主要反映你到 Cloudflare/测速服务的体验，不能证明 PROXYIP -> OpenAI/GitHub/npm 的出口质量。

普通用户可以这样测：

• 浏览器打开 ChatGPT、Claude、GitHub。
• 下载一个几 MB 的文件，看是否中断。
• 晚高峰再测一次。
• 第二天再测一次。

可以按这个表记录：

测试项	成功标准	失败信号
ChatGPT/Claude 页面	能打开并完成几轮对话	页面转圈、频繁断线
API 地址	能稳定返回 HTTP 响应头	TLS 失败、连接重置
GitHub	首页和仓库都能打开	首页能开但 raw 文件慢
npm	能查包版本	安装包时大量超时
下载测试	10MB 级文件不中断	中途断、速度掉到不可用

开发者可以进一步测：

curl -I https://api.openai.com
curl -I https://api.anthropic.com
curl -I https://github.com
npm view react version
git ls-remote https://github.com/openai/codex.git HEAD

看到 401、403 不一定是网络失败。比如 API 地址没带 Key 时返回 401/403 很正常，关键是它能不能稳定返回 HTTP 响应头。

更专业一点，可以用 curl -w 看连接耗时：

curl -o /dev/null -sS -w 'connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://api.openai.com

如果你要跑 Codex、Claude Code、OpenClaw 这类长任务，至少做一次 10 到 30 分钟的连续使用测试。一次成功只能说明“能用”，连续多轮、跨时段成功，才说明“比较适合你的用途”。

更稳的做法是分两级：10 到 30 分钟用于初筛；真正要跑长任务时，再跑一次 2 到 4 小时的真实项目任务，看是否断线、卡安装、拉 GitHub 失败或 API 流式响应中断。

九、那 VPS 会不会更好？

如果 VPS 质量合格、线路稳定、IP 信誉干净，通常会比公共 PROXYIP 更可控。原因很简单：VPS 是你自己租的服务器，你知道它在哪里、谁在用、端口怎么开、服务怎么配置。

但 VPS 也不是自动变好。便宜 VPS 可能遇到：

• 机房超售。
• 晚高峰丢包。
• 路由绕路。
• IP 被滥用过，目标服务风控。
• 流量太少或带宽太小。

所以更准确的说法是：

好 VPS 通常比公共 PROXYIP 稳；差 VPS 不一定。

对比一下：

方案	成本	可控性	适合场景
Cloudflare + 公共 PROXYIP	免费或接近免费	低	学习、备用、短任务
Cloudflare + 自己 VPS 做上游	VPS 成本	中高	想保留 Cloudflare 入口，同时控制出口
客户端直连自己的 VPS	VPS 成本	高	长任务、开发工具、长期使用

长任务最怕的不是慢一点，而是中途断。Codex、Claude Code、OpenClaw 这类工具一旦长连接断开，可能会导致任务失败、上下文丢失、依赖安装卡住、GitHub 拉源码失败。

好的 VPS 不能保证零失败，但能降低失败概率。

同时也要注意：VPS 只是让网络出口更可控，不代表一定符合 OpenAI、Anthropic、GitHub、npm 的访问政策或风控要求。账号风控、IP 信誉和服务条款仍然要单独考虑。

十、5 美元 VPS 怎么选？

如果预算是每月 5 美元左右，不要只看价格，先看筛选标准：

• 机房：美国西海岸可以作为第一候选，但仍要实测。
• 流量：别买太小流量。
• IP 信誉：新买后先测 OpenAI、GitHub、npm。
• 晚高峰表现：晚上和周末都要测。
• 是否支持快照/重装：小白折腾时很重要。
• 退款政策：买之前看清楚。

商家名字会随库存、地区、价格、线路和 ToS 变化，不建议把任何一家当成永久答案。你可以比较常见 VPS 商家，但最终用一周左右的真实测试决定是否留下。

我的实用建议：

1. 先选一个便宜美国西海岸 VPS。
2. 跑一周，记录 OpenAI、Claude、GitHub、npm 的失败率。
3. 如果稳定，再长期用。
4. 如果不稳定，换机房或换商家，不要只盯配置参数。

十一、VPS 基础搭建思路

这里只给小白理解框架，不展开具体脚本。

1. 买 VPS

建议：

• 系统：Ubuntu 22.04 / Debian 12。
• 配置：学习用 1 核 1G 起步，长期跑服务建议 1 核 2G 以上。
• 地区：先测美国西海岸，同时保留其他区域对照。

2. 登录服务器

确认你连接的是自己购买的服务器：

ssh root@你的服务器IP

首次登录后建议：

• 改 root 密码或改用 SSH Key。
• 确认商家控制台能重装系统。
• 有条件先做快照。
• 更新系统前确认没有重要数据。

常见更新命令：

apt update && apt upgrade -y

3. 安装代理服务

常见选择方向：

• sing-box、xray 这类成熟内核。
• 带图形化后台的面板类工具。

本文不推荐具体一键脚本。小白如果使用面板类工具，要优先选择能开启认证、能更新、文档清楚的方案。

如果用面板，一定要注意：

• 不要使用默认后台路径。
• 设置强密码。
• 不要开放无认证代理。
• 用防火墙限制后台访问。
• 定期更新面板和内核。
• 不要把订阅链接发到公开群。

4. 导入客户端并测试

导入 Clash/Sing-box/Shadowrocket 后，先测：

curl -I https://api.openai.com
curl -I https://github.com
npm view react version

能返回 HTTP 响应头，说明网络基本可达；后续还要看跨时段稳定性和下载表现。

十二、Cloudflare + VPS 组合怎么玩？

如果你已经有 VPS，可以把 VPS 作为更可信的上游，而不是继续依赖公共 PROXYIP。

路径变成：

你的电脑
  -> Cloudflare Worker
  -> 你的 VPS 上的上游代理/反代服务
  -> OpenAI / Claude / GitHub / npm

注意：不是把一台空 VPS 的 IP 填进 PROXYIP 就一定能工作。VPS 上必须运行 edgetunnel 支持的上游服务或反代入口，并确认端口、协议、TLS/SNI、认证方式都匹配。千万不要开放无认证代理。

如果你用的是 SOCKS5/HTTP 上游，应使用项目对应的 SOCKS5/HTTP 配置，不要误填到 PROXYIP。

这种组合的优点：

• Cloudflare 入口仍然好用。
• 出口变成你自己控制的 VPS。
• 公共 PROXYIP 拥堵、失效、被滥用的问题会少很多。

缺点：

• 多一跳，速度不一定比直连 VPS 快。
• 配置更复杂。
• VPS 本身仍然决定长期稳定性。

实用排序：

• 平时重度使用：客户端直连质量合格的 VPS。
• 备用入口：Cloudflare + 自己的 VPS 上游。
• 免费临时：Cloudflare + 公共 PROXYIP。

十三、安全和合规提醒

这类方案最容易出问题的不是“技术搭不起来”，而是安全边界没守住。

请至少做到：

• 不对外转售或公开提供代理服务。
• 不违反公司、学校、服务商和所在地规则。
• 不共享订阅链接。
• 不用弱 ADMIN 密码。
• 不截图泄露 UUID、Token、订阅地址、后台域名。
• 不把公共 PROXYIP 当可信线路。
• 不让生产 API Key、客户数据、支付账号走公共节点。
• 不开放无认证 HTTP/SOCKS5 代理。
• 定期更新项目、面板、系统和客户端。

如果你只是学习和备用，风险可控；如果你要长期重度使用，建议用自己控制的 VPS，并把账号、日志、密钥和访问权限管理好。

十四、最后怎么选？

我会按这个顺序给小白建议：

1. 先搭 Cloudflare + edgetunnel，理解入口、Worker、PROXYIP、目标服务这几段链路。
2. 配好自定义域名、ADMIN、KV、客户端订阅。
3. 不要迷信默认 PROXYIP，自己测试美国西海岸、日本、新加坡等候选节点。
4. 测真实目标：OpenAI、Claude、Codex、GitHub、raw.githubusercontent.com、npm。
5. 如果只是备用，免费方案先用着。
6. 如果要跑长任务，再买质量合格的 VPS。
7. 如果 VPS 稳定，再考虑接回 Cloudflare 做备用入口。

这次测试最值得记住的一句话是：

决定 AI 开发工具体验的，不只是本地延迟，而是出口节点到 OpenAI、Claude、GitHub、npm 的稳定性。

PROXYIP 有用，是因为它影响这段出口链路。VPS 更可控，也是因为它让你掌握出口。免费方案先跑起来，知道问题在哪里；等它真的影响工作，再花钱升级。这样通常更稳妥，也更容易控制成本。