流量暴涨把 Cloudflare Worker 打满后：我用 Rust 在 OCI 上重建了视频流代理这篇文章记录一

流量暴涨把 Cloudflare Worker 打满后：我用 Rust 在 OCI 上重建了视频流代理

这篇文章记录一次“事故驱动”的工程改造：用户流量突然暴涨，Cloudflare free 版本的 Worker 很快被打满。我第一时间充钱，想顶住峰值，紧接着就收到了限制/封禁通知。

那一刻我意识到：当你的核心链路依赖一个平台的边缘函数额度与策略时，可用性并不完全掌握在自己手里。
于是我马上启动 Rust 改造，把播放器最关键的“视频流代理”迁移到自建服务上，最终落地到 Oracle Cloud（OCI）服务器，保证可控、可部署、可长期稳定运行。

视频流代理的难点在于它不是普通 HTTP 反代：

HLS（m3u8）是“清单 + 分片 + Key”的链路
只代理 m3u8 没意义：播放器会继续请求清单里的 ts/m4s/key URL，如果不重写，它们会绕过代理。
MP4 等大文件需要 Range（206 Partial Content）
不透传 Range，拖拽、断点续传会非常不稳定。
流量大、连接长、响应体大
平台边缘函数对这类流式转发更敏感：额度/时长/策略/风控都可能触发。

所以我做的不是“一个反代”，而是一条“播放器真实链路可用”的代理链路。

我把需求收敛成两条：

最终服务暴露的接口非常简单：

当上游返回 m3u8（或 URL 包含 .m3u8），服务会读取清单文本并重写：

这一步是 HLS “能播”的关键，否则 m3u8 只是个入口，真正的数据流还是直连源站。

Range 请求头会被透传给上游，源站支持 Range 时就能返回 206，播放器拖拽更稳定。

代理不把视频读进内存，也不落盘：上游响应体以流式方式直接转发给客户端，减少延迟和内存压力。

部署形态：

Nginx 关键点是必须传：

否则 m3u8 重写出来的 URL 可能协议/域名错误（例如变成 http）。

我把“写完能跑”升级到“可交付”：

真实踩坑：在较老 Ubuntu 上，glibc 版本可能不够，导致：

GLIBC_2.34 not found

所以发布改成 x86_64-unknown-linux-musl 静态链接，兼容性更好：下载解压就能跑。

（CI/CD 说明见仓库文档：cicd.md）

适用范围：

风险提示：

这次改造最大的收获不是“Rust 很快”，而是：
把不可控的风险（平台策略/额度/风控）换成可控的成本（服务器与运维）。

如果你也在做播放器、媒体聚合、跨域代理，欢迎提 Issue 或 PR，我们一起把它做得更稳、更工程化。