ChrisRodStar/stream

Stream TV 想给家庭一个私有的“片库 + 播放器”：catalog 同步元数据，iPhone 或网页客户端看片，真正的视频从第三方片源站解析后经 VPN 容器中继过来。适合已经在跑 Docker Compose 和 Tailscale、并愿意跟着上游站点维护解析代码的人；想要开箱即用的媒体服务器则不合适。

解决什么问题

一个家庭想有个统一的地方浏览片名、在手机上直接开播，而不是在满屏弹窗、跟踪脚本和失效链接的公开站点里翻找。过去这意味着同时维护元数据源、多个片源网站和播放器，链接一换就要重新折腾。Stream TV 把这些步骤收进一台家用服务器：catalog 同步片名信息，providers 服务解析真实流地址，relay 再转成干净的 HLS 播放流。用户拿到熟悉的片架和播放界面，但媒体内容仍来自上游片源站。

有什么不同

真正区别于常见方案的是网络设计，而不是界面。隐私章节描述 streaming 容器的抓取和取流流量只走 Mullvad 的 WireGuard 接口，隧道断开时防火墙规则丢弃出网流量；Rust relay 重写 .m3u8 播放列表，客户端只能看到本地中继路径。片源的安全挑战用纯 Go 原生代码解决，不需要无头浏览器，容器可以更精简；catalog 保留读取快照，TMDB 故障时仍能浏览；API 提前准备排序好的备用源，便于快速切换。

代价是架构偏重：六个独立维护的项目、三个容器，技术栈横跨 Go、Rust、Swift 和 React，播放还要令牌校验。每个片源的解密与探测逻辑都是逆向得来，上游一改就会失效，直到 provider 代码更新。fail-closed 路由是 README 里的设计目标，现有材料没有独立验证它是否真的不漏流量、能否长期稳定。

谁值得试

适合已经在用 Docker Compose 和 Tailscale 的家庭服务器用户：他们需要 iPhone 和网页两端都能看，也愿意在片源站变化时跟进维护 provider 代码。不适合想要开箱即用媒体服务器、或希望全家完全不碰技术的人；也不适合需要明确授权内容来源的用户——这个项目是去找第三方流，而不是提供媒体版权。iOS 客户端带后台播放器预热，对 Apple 设备家庭有吸引力；只用网页端则不必构建 Swift 应用。

使用条件与边界

你需要一台能跑三个容器的主机、一份 Mullvad WireGuard 配置，以及可选的 Tailscale Serve 私有入口；部署说明覆盖 Compose 配置。片源解析是持续变动的目标，上游更改加密方式或播放列表格式时就要维护，README 把每个服务描述为各自维护依赖和发布节奏。项目没有声明许可证，这会影响能否再分发或嵌入部分代码。密钥、VPN 私钥和本地 SQLite 数据不能提交进代码库，这是长期运维责任，不是一次性配置。现有 README 摘录没有细说 iOS 应用的构建要求。

HotRepo 点评

HotRepo 记录到这个仓库时它只有 1 天历史；2026-10-25 的观测显示总星数 35，在新项目榜（不是总榜）排第 17。这只是单次快照，不是增长序列，无法判断热度能否持续。投入前值得先确认哪些片源目前仍然可用，以及 provider 代码过去需要多频繁地修改。