302 反代让 Emby 播放不占服务器带宽：原理与配置

如果你搜过「Emby 网盘 302」，一定看过这句话：

开启 302 后视频不经过服务器，不占带宽。

这话只说对了一半，而且这半个真相坑了不少人。先把链路画清楚，再讲怎么配。

302 是什么

HTTP 状态码 302 表示「你要的东西临时在别处」，附带一个新地址，客户端应该去那里取。

在网盘播放场景里，OpenList 从网盘拿到真实文件地址后，把地址以 302 形式返回，而不是自己把文件读出来转发。

关键误解：302 的接收方是谁

只有 OpenList 返回 302

客户端 → Emby → OpenList
                    ↓ 返回 302 + 网盘真实地址
         Emby ←──────┘
           ↓ Emby 按 302 去网盘拉流
        网盘 ──→ Emby ──→ 客户端

看清楚：Emby 是那个跟着 302 走的客户端。视频数据从网盘流向 Emby 服务器，Emby 再转发给你的播放器。

结果就是：服务器上行带宽照样被占满。4K 原盘该卡还是卡。这跟"不占带宽"差了十万八千里。

加了反向代理之后

客户端 → 反代 → Emby（只取 API 元数据）
           ↓ 播放请求被改写
        客户端 ← 302 + 网盘直链
           ↓
        客户端 ──→ 网盘 CDN（直连）

这时客户端拿到的是网盘直链，视频流直接从网盘 CDN 到你的设备，服务器只负责 API 和目录。这才是真正不占带宽的形态。

怎么判断自己属于哪种情况

不用猜，做个测试：

1. 用 Emby 播放一个视频
2. 同时看服务器/ NAS 的网络监控
3. 如果上行流量接近视频码率（比如 4K 原盘 60Mbps），说明在走中转
4. 如果上行只有几百 KB/s，说明已经直链

这个测试比看任何配置项都可靠。

方案选择

实现「客户端直连网盘」的工具有几类：

工具	形态	适合
go-emby2openlist	独立反代容器	OpenList 用户，配置直观
MediaWarp	独立反代	需要同时处理多种媒体服务器
oneSTRM	一体化（STRM + 302）	不想拼多个组件
TgtoDrive	转存 + 整理 + STRM + 302 一体	115/123/光鸭用户
LitePan	挂载 + STRM + 302	NAS 影音场景

它们的共同原理一样：拦在 Emby 前面，把播放地址换成网盘直链。

配置的通用步骤

不同工具细节不同，但逻辑是同一套：

第一步：确认网盘支持 302

不是所有网盘都支持。OpenList 里对应存储的「Web 代理」要关闭，才会走 302（开着代理意味着由 OpenList 转发，那就又变成中转了）。

部分平台（如夸克）需要额外开转码设置才能走 302，具体看 OpenList 文档对应驱动的说明。

第二步：验证 OpenList 的 302 真的返回了

curl -I "http://你的OpenList地址/d/aliyun/电影/示例.mkv"

看返回：

• HTTP/1.1 302 + Location: https://...（网盘域名）→ 302 生效
• HTTP/1.1 200 + Content-Type: video/... → 走的是代理转发，没生效

这一步不通过，加反代也没用。

第三步：部署反代

以 go-emby2openlist 类工具为例，容器通常需要三个配置：

• Emby 服务地址（http://emby:8096）
• OpenList 地址（http://openlist:5244）
• 对外监听端口

然后把客户端访问的地址改成反代的端口，而不是原来的 Emby 端口。这一步最容易忘，配置完了但客户端还连着旧地址，当然没效果。

第四步：关闭转码

Emby 后台 → 用户 → 播放：

• 关闭「如有必要，在媒体播放期间允许视频转码」
• 关闭「允许音频转码」
• 关闭「允许更改容器格式」

转码意味着服务器要解码再编码，必然占 CPU 和带宽。直链播放的前提是原样把流交给客户端。

第五步：再次验证

重复开头的流量测试。服务器上行接近零、客户端能拖进度条，就成功了。

代价与风险

1. 起播略慢。 多了一次 302 跳转和网盘鉴权，通常比本地中转慢几百毫秒到一两秒。

2. 网盘风控。 直链播放会产生大量来自你账号的下载请求。多 IP、多线程、高并发都可能触发风控，严重时账号受限。个人自用通常没问题，但别把账号分享给一堆人同时用。

3. 客户端兼容性。 不是所有播放器都好好处理 302 跳转。部分电视端 App 可能起播失败，需要换播放器或改回中转模式。

4. 配置复杂度。 比单纯挂载复杂一档，出问题时排查链条更长（客户端 → 反代 → Emby → OpenList → 网盘）。

什么时候不值得折腾

如果满足以下任一条件，用挂载 + 中转就够了：

• 你的服务器上行带宽足够（比如 100Mbps 以上）
• 主要看 1080p，不追 4K 原盘
• 只在局域网内看
• 不想承担账号风控风险

302 真正解决的是「上行带宽不够 + 高码率」这个组合。其他情况下收益有限。

只剩一句要记

记这一句就够：

只有 OpenList 的 302，接收方是 Emby 服务器；要让客户端直连，必须在前面加反代。

理解了这句话，剩下的都是配置细节。至于哪个网盘的直链生态更成熟，可对照适合做影视媒体库的网盘。

相关阅读：302 重定向是什么、STRM 接入 Emby、网盘挂载工具。