基于容器平台和Cloudflare Tunnels的FRP方案

传统FRP方案进行本地无公网IP服务器的内网穿透及网站发布需要一个有公网IP的云服务器作为中转，难以在安全、稳定、成本之间实现合适的平衡，而使用Cloudflare Tunnels虽然能实现上述功能，但是由于服务器在家用网络使用Cloudflare服务容易出现间断性的不可用状态，在急需使用时的无法访问无疑令人头大。

注意到：

  1. Cloudflare Tunnels除了能映射HTTP服务，还可以将TCP端口映射至域名如frp.example.com
  2. 本地服务器只要能够访问frp.example.com就能将TCP端口映射到本地，而FRP恰好是通过TCP端口建立服务连接
  3. 家用网络下的Cloudflare Tunnels官方服务稳定性不高，但是对基于Cloudflare服务的自用域名如frp.example.com可用性和稳定性较高

因此新方案的思路是：

  1. 在云容器平台上部署一个运行Cloudflare Tunnels和frps（FRP服务端）的容器服务，此步骤成本约为零（或许没有一直免费的，但一直会有免费的，包括但不限于Claw、Koyeb、Render等平台）
  2. 在Cloudflare面板上将frps使用的TCP端口映射至域名frp.example.com，在本地电脑测试并将域名映射至本地TCP端口，此步骤多半可以连接（如果不行可以试试SaaS回源等优化方案）
  3. 在本地服务器上安装配置frpc（FRP客户端），在Cloudflare面板上添加域名或通过容器平台添加域名（如果容器平台支持）

具体的代码和使用说明见GitHub仓库，额外添加了保活功能用于应对容器平台的休眠策略，定期访问即可。文档是手打的，但是代码都是Claude写的，想添加需求建议直接问Claude。

以下是使用本方案发现的几个经验性的现象：

  1. 如果是在Cloudflare面板上添加使用的域名，比如alist.example.com对应本地的Alist网盘，下载时的流量不会被容器平台计入，测试时在Koyeb的容器监控中观察到CPU占用拉满但是上下行流量并没有变化，并且在Claw平台测试时下载了30G的内容也未被限流（该平台声明的是10G/月），具体原因未知
  2. 本方案对于内存需求不大，下载测试时容器监控中显示的用量也只有130MB，因此256MB的内存足矣，建议CPU配置拉高点
  3. 使用Uptime Kuma的一周测试中同样是Alist服务，相较于直接使用Cloudflare Tunnels，本方案的平均响应相差无几，在线时间提高了1%左右（98%->99%），在若干前者无法访问的时间段本方案成功访问，在动态IP轮换的时间点两者出现过短暂同时不可用，在响应时间波形图上本方案的波动性更大存在更多波峰