建议贴：建议飞牛影音增加 .strm 代理中转功能，解决 strm 异地播放风控隐患

时差症患者。

1. 痛点背景

我目前使用 OpenList 挂载网盘资源并生成 .strm 文件供飞牛影音播放。OpenList 的核心优势在于解析速度快，但在异地播放（如 5G 网络、酒店 WiFi 或公司网络）时，会触发严重的网盘安全风控。

2. 问题深度解析（为什么 OpenList 容易被风控？）

目前的播放逻辑是典型的 “解析与下载分离”：

• 控制流（NAS 端）： 飞牛调用 OpenList 在 NAS 本地完成 Token 鉴权并获取直链。网盘后台记录的是 NAS 的公网 IP。
• 数据流（客户端）： 飞牛将直链通过 302 重定向发给播放器。播放器直接用 客户端当前的 IP 去拉取数据。
• 风控触发点： 网盘侧在极短时间内收到了来自两个不同地理位置（IP 段）的访问请求。这种“异地双 IP”行为极易被判定为账号共享或盗链，导致网盘拉黑、限速甚至封号。

---

3. 建议功能：增加“强制代理（Proxy）”模式

建议在飞牛播放器的 .strm 播放逻辑中，增加一个 直连/中专 的切换。

流程对比图逻辑

【现状：302 直连模式】—— 异地播放产生双 IP

1. [客户端 (IP: B)] -> 请求播放 -> [NAS (IP: A)]
2. [NAS (IP: A)] -> OpenList 解析 -> [网盘 (识别到 IP: A)]
3. [NAS (IP: A)] -> 返回 302 重定向直链 -> [客户端 (IP: B)]
4. [客户端 (IP: B)] -> 直接拉取数据 -> [网盘 (识别到 IP: B)]
   • 结果： 网盘看到 A 和 B 同时操作，风控报警。

【建议：中转代理模式】—— 全程单 IP 访问

1. [客户端 (IP: B)] -> 请求播放 -> [NAS (IP: A)]
2. [NAS (IP: A)] -> OpenList 解析 -> [网盘 (识别到 IP: A)]
3. [NAS (IP: A)] -> 作为中转代理，由 NAS 拉取网盘数据流
4. [NAS (IP: A)] -> 将数据流转发给 -> [客户端 (IP: B)]
   • 结果： 网盘全程只看到 NAS (IP: A) 在访问，规避风控。

---

4. 给开发组的专业化描述

• 需求功能： 针对 http(s) 协议的 .strm 文件，增加类似反向代理的 Http Proxy 转发机制。
• 核心逻辑： 飞牛服务端（Server）获取流媒体数据后，不直接 302 给客户端，而是通过服务端建立 Socket 连接 ，将数据回传给 App/TV 端。
• 适用场景：
  • 异地播放防止网盘封号。
  • 客户端由于网络原因无法直接访问网盘（如某些内网环境），需通过 NAS 代理。

5. 总结

虽然中转会消耗 NAS 的上行带宽，但对于使用 OpenList 追求极致私密和稳定的用户来说，这是保护网盘账号不被封禁的刚需功能。目前 Emby、Jellyfin 均有成熟的中转方案，希望飞牛作为最懂中国用户的 NAS 系统，能尽快补齐这一块。

飞牛产品同学

感谢反馈，这个需求先记录下来，我们会根据评估结果推进

atangy

我一直以为用strm不会被风控呢
如果用爆米花在异地播放，我现在是爆米花挂载飞牛里的strm，按照你说的，那就有风控的风险，反而爆米花直接挂载115更安全？