利用 Cloudflare Workers 进行代理的项目很多,但是可以运行 Trojan 协议的 Epeius 还是不多见的。作为一个备用线路,用于应急方案应该是很优秀的项目,毕竟免费的 Cloudflare Workers 使用额度,极其简单的部署过程,以及 Surge、QuantumultX、Shadowrocket 等工具都支持 Trojan 协议,无论如何都是值得花费5分钟时间。
前置条件
- Cloudflare、GitHub 账号。
- Cloudflare API Token,用于使用 GitHub Action 部署 Cloudflare Workers。
- Trojan 密码以及 SHA224 Hash 值,可以直接利用 SHA224 Hash Generator 去生成,我使用的“some” 作为了密码并得到了“29394e353dca0ac4e0dd978cc2b58c7a0cd1f0dcb24a5b1d19603d61”哈希值。
部署过程
- 从作者仓库 Epeius Fork 到自己的仓库中。
- 回到自己的仓库中,添加 GitHub Action 要使用到的 Repository secrets。
CF_API_TOKEN 设置为之前获取到的 Cloudflare API Token。
SHA224PASS 设置为之前生成的哈希值“29394e353dca0ac4e0dd978cc2b58c7a0cd1f0dcb24a5b1d19603d61”。
PROXYIP 设置为“8.218.146.204”(例),可以通过访问 https://ipdb.api.030101.xyz/?type=bestproxy
获取一个优选的反代IP。
- 编写 GitHub Action 文件,当仓库
main
有变化或者手动触发将代码部署到 Cloudflare Workers 之上。
注意保存的目录地址:epeius/.github/workflows/deploy-CloudflareWorkers.yml
,其中文件内容如下。
name: Deploy to Cloudflare Workers
on:
push:
branches:
- main
repository_dispatch:
workflow_dispatch:
jobs:
deploy:
runs-on: ubuntu-latest
timeout-minutes: 60
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Deploy to Cloudflare Workers
uses: cloudflare/wrangler-action@v3
with:
apiToken: ${{ secrets.CF_API_TOKEN }}
secrets: |
SHA224PASS
PROXYIP
env:
SHA224PASS: ${{ secrets.SHA224PASS }}
PROXYIP: ${{ secrets.PROXYIP }}
提交到 GitHub 后应该会自动触发 GitHub Action 动作,如果一切顺利自动将代码部署到 Cloudflare Worker之上,如果没有触发可以在 Actions 中手动操作。
测试结果
- 进入 Cloudflare Workers 中可以看到已经自动创建了 Epeius 项目,在项目中可以自定义域名,也可以使用默认的域(只要能正常访问)。
- 访问
https://[YOUR_DOMAIN]/link
可以获取到 Trojan 的链接,类似trojan://ca110us@example.com:443/?type=ws&host=example.com&security=tls
,实际链接应该为trojan://some@example.com:443/?type=ws&host=example.com&security=tls
。 - 在 Surge 中添加相应的配置,并启用代理。
CFW_Trojan = trojan, example.com, 443, password=some, ws=true, ws-path=/, tfo=true, test-url=http://edge.microsoft.com/captiveportal/generate_204
- 4G网络下测试具体使用。
YouTube、Google、Twitter都是能正常使用的,但是 Cloudflare 却不能访问。
如果未设置 PROXYIP
,直接使用 Surge 进行测速会发现失败 http://cp.cloudflare.com/generate_204
,而使用 Cloudflare CDN 的服务都可能存在访问问题,在 Cloudflare Workers 的日志中发现了相关错误。
{
”message“: [
”retry tcpSocket closed error“,
”Error: proxy request failed, cannot connect to the specified address. It looks like you might be trying to connect to a HTTP-based service — consider using fetch instead“
],
”level“: ”log“,
”timestamp“: 17
}
后续
GitHub Action 的方式进行部署相对于手动部署的优势在于降低了后期更新操作的复杂性,之后作者更新代码后,直接进行 “Sync fork” 就能保证代码的更新同时并自动部署。
“可以不用,但是不能没有”应该就是对这个备选方案的定位,永远不知道未来的网络环境会变成怎样,对于这种可能解决突发状况的低成本方案,还是要备上一条。