4K 视频总卡在公网带宽？用 N1 + OpenList 把网盘播放链路重新理顺

4K 视频总卡在公网带宽？用 N1 + OpenList 把网盘播放链路重新理顺

前言

N1 盒子刷上 iStoreOS 以后，我一直觉得它最适合干的不是"堆很多服务"，而是把一些本来就轻量、但需要长期在线的事情接起来。OpenList 就很符合这个思路：它自己不需要承担整套影音存储，而是把阿里云盘、夸克网盘、百度网盘这类入口聚合到一个 Web 页面里。真正容易踩坑的地方反而在公网播放------页面能打开，不代表大文件播放就一定顺畅；如果视频流量一直绕回家里的上行链路，N1 再省电也解决不了带宽问题。尤其这种小盒子，真正应该省的是重复中转，而不是硬扛本来就不该由它承担的大流量。

这次我按现有环境在 iStoreOS 里安装 OpenList，再给 cpolar 配置公网访问和固定二级子域名 xylist，随后挂载夸克网盘，最后测试文章里的 302 思路。原流程先出现了"视频能播，但带宽不够"的状态，之后开启【使用转码地址】，再次播放时页面显示下行约 12.93MB/s。我更关心的是整条数据路径到底怎么走：OpenList 负责聚合和返回播放地址，cpolar 负责 Web 公网入口，真正的大文件流量是否还经过 N1 和隧道，则要看当前存储驱动和播放方式。对我来说，这比一句"4K 随便播"更值得说明白。

1. 先把这套方案拆成三层

这篇真正要解决的，不只是"给 N1 再装一个程序"。

第一层是 OpenList 聚合网盘 。

不同网盘的内容放进同一个 Web 页面，查找和管理会更集中。

第二层是 cpolar 提供公网入口 。

离开家以后，外部设备先能够打开 OpenList 页面。

第三层才是 视频实际怎么传输 。

公网页面能打开，不等于 4K 视频就一定顺畅。如果大文件仍然持续经过家庭上行和中转链路，带宽还是会成为瓶颈。

所以我会一直把这三层分开看：

OpenList 负责聚合 → cpolar 负责入口 → 302 / 播放地址决定后续大文件请求怎么走。

2. 在 iStoreOS 安装 OpenList

进入 iStoreOS 应用商店，搜索：

openlist

然后安装。

安装完成以后，关闭按钮会变成绿色。

刷新页面，再进入服务列表，可以看到 OpenList 菜单。

打开以后进入登录界面。

当前步骤使用默认用户名：

admin

默认密码：

password

如果后面准备长期从公网访问，我不会一直保留默认密码；不过这里按当前材料原样保留。

3. OpenList 为什么适合放在 N1 上？

OpenList 本身更像一个目录聚合和访问入口。

当前介绍里提到它可以挂载：

• 阿里云盘；
• 夸克网盘；
• 百度网盘；
• WebDAV；
• 其他存储服务。

这篇真正继续实操的是 夸克网盘。

所以新版不会把"支持很多存储"直接写成"这些网盘都已经逐个验证"，而是围绕当前真正跑过的夸克链路继续。

至于原文里 OpenList 与 AList 的项目生态比较，包括收购、数据收集、协议变化等判断，这次不额外联网核实，也不把这些评价扩展成新的结论。当前教程实际使用的是 OpenList，这一点保持不变。

4. 本地能打开以后，再给 OpenList 增加公网入口

现在 OpenList 已经在 iStoreOS 里跑起来。

如果只在家里使用，到这里就够了。

问题是人在外面以后，192.168.x.x 这类局域网地址无法直接访问。

这里再加入 cpolar。

cpolar 在这套方案里的职责比较单一：

把 OpenList 的 Web 页面提供到公网。

它不参与网盘挂载，也不决定后面 4K 视频到底从哪里下载。

5. 在 iStoreOS 安装 cpolar

先点击 iStoreOS 首页的终端按钮。

进入终端页面并登录系统。

先下载公钥：

wget -O cpolar-public.key http://openwrt.cpolar.com/releases/public.key

下载完成后添加公钥，并加入 cpolar 的 opkg 仓库源：

opkg-key add cpolar-public.key

echo "src/gz cpolar_packages http://openwrt.cpolar.com/releases/packages/$(. /etc/openwrt_release ; echo $DISTRIB_ARCH)" >> /etc/opkg/customfeeds.conf

更新仓库：

opkg update

然后安装 cpolar 主程序、LuCI 管理插件和中文语言包：

#安装 cpolar 主程序，这是核心二进制文件，可以运行隧道服务。
opkg install cpolar
#安装 LuCI 的前端管理界面插件，也就是在 iStoreOS 的 Web 界面（LuCI）里能看到图形化的 Cpolar 配置。
opkg install luci-app-cpolar
#安装 LuCI 的中文语言包，让 Web 界面显示中文。
opkg install luci-i18n-cpolar-zh-cn

安装完成以后刷新 iStoreOS 首页。

进入【服务】，可以看到 cpolar 菜单。

6. 给 OpenList 建立 HTTP 公网入口

点击：

【打开Web-UI管理界面】

进入 cpolar 后台。

注册并登录以后，进入：

【隧道管理 → 隧道列表】

当前页面里可以看到已有隧道。

选择：

website

隧道进行编辑，也可以创建新的隧道。

更新以后，进入：

【状态 → 在线隧道列表】

可以看到 HTTP 和 HTTPS 公网地址。

这里以 HTTPS 地址测试。

页面能够正常打开。

这一层真正验证的是：

OpenList Web 页面 → cpolar HTTP 隧道 → 外部浏览器。

到这里还不能说明视频带宽问题已经解决。

7. 随机地址跑通以后，再换固定二级子域名

随机公网地址适合先验证。

如果 OpenList 要长期从外部访问，固定地址更方便。

进入 cpolar 的预留页面。

当前记录为：

• 地区：China VIP
• 二级域名：xylist

关于二级域名，原文保留了这条说明：

注：二级域名是唯一的，每个账号都不相同，请以自己设置的二级域名保留的为主

接着回到：

【隧道管理 → 隧道列表】

当前可以看到：

xylist-5244

隧道。

点击编辑，把域名类型改成：

二级子域名

再填写前面保留成功的名称。

更新以后，到在线隧道列表查看。

继续通过 HTTPS 地址访问。

页面能够正常打开。

固定二级子域名解决的是：

长期访问入口不再频繁变化。

它本身不会直接提高视频播放带宽。

8. 开始挂载夸克网盘

接下来进入真正和视频资源有关的部分。

先进入 OpenList 管理页面。

当前默认账号密码在原文中再次写成：

#默认的账号和密码为： 
admin 
password

进入管理后台以后，打开：

【存储 → 添加】

驱动选择：

夸克

然后按页面填写对应信息。

这里需要先获取夸克网盘的 Cookie。

登录夸克网页版，再按照当前步骤提取 Cookie。

复制后先保存。

接着获取需要挂载目录的根文件夹 ID。

回到 OpenList 的存储配置页面，继续填写。

填写完成以后点击添加。

回到主页，可以看到夸克网盘已经挂载成功。

到这里跑通的是：

夸克网盘 → OpenList 存储驱动 → Web 页面统一浏览。

9. 先看优化前的播放状态

挂载完成以后，随机打开一个视频资源。

当前现象是：

视频可以播放，但下载带宽不足以流畅播放 4K。

这个结果很关键。

因为它说明"公网能打开 OpenList"和"高码率视频能顺畅播放"是两件事。

如果把这两层混在一起，就很容易把后面的优化原因写错。

10. 302 在这里解决的是数据路径问题

HTTP 302 表示临时重定向。

简单理解就是：

服务器告诉浏览器，真正的资源暂时在另一个地址，请去新的地址继续访问。

如果后续播放请求最终跳到网盘直链或 CDN，那么大文件就有机会不再持续经过原来的中转路径。

这正是这篇方案最值得看的地方。

但我不会把它直接写成"只要 302 就一定不受带宽限制"。

更准确的理解是：

最终视频流量怎么走，仍然取决于 OpenList 当前存储驱动返回的地址和播放方式。

11. 开启夸克配置里的"使用转码地址"

进入 OpenList 管理页面的【存储】。

找到已经挂载的夸克网盘，点击编辑。

当前步骤开启：

【使用转码地址】

这里按现有流程原样保留。

原文把这一操作作为后续 302 播放链路的一部分，因此新版也不自行替换成其他参数。

12. 再次播放，观察实际结果

保存设置以后，回到主页，重新选择视频播放。

当前页面显示下行带宽：

12.93MB/s

按照这次实际结果，这个速度已经足够播放当前测试的 4K 视频资源。

这里我只保留已经出现的结果：

在当前 N1 + iStoreOS + OpenList + 夸克网盘环境里，调整后页面显示约 12.93MB/s，当前测试视频可以顺畅播放。

不会进一步扩大成：

• 所有 4K 视频都一定不卡；
• 所有网盘都能达到相同速度；
• 开启相关设置以后就完全不受任何带宽限制；
• N1 或 cpolar 本身直接提供了 12.93MB/s 的视频带宽。

总结

这套方案让我觉得 N1 用得比较"对路"的地方，不是把它硬说成一台全能影音服务器，而是让它承担自己擅长的部分：

运行 OpenList、维护聚合入口、处理 Web 访问和控制逻辑。

这次实际跑通的主线是：

N1 → iStoreOS → OpenList → cpolar 公网访问 → 固定二级子域名 xylist → 夸克网盘挂载 → 视频播放 → 开启【使用转码地址】→ 再次测试 → 下行约 12.93MB/s。

几个边界需要一直分清：

• cpolar 负责 OpenList 的公网 Web 入口；
• OpenList 负责聚合网盘和返回文件访问路径；
• 当前实际挂载并测试的是夸克网盘，不代表其他网盘完全相同；
• 原文把 302 和【使用转码地址】放在同一条优化链里，这个技术关系按现有材料保留，没有额外替换或补充；
• 12.93MB/s 是当前页面展示的实际测试值，不代表所有网络环境都能复现；
• 固定二级子域名 xylist 解决的是访问入口，不会自动提升视频带宽；
• 默认 admin / password 属于当前安装步骤里的初始凭据。

对我来说，这类旧设备最有价值的玩法，不是让它什么都做，而是把服务入口和大流量数据路径分开。N1 只要能稳定把 OpenList 跑起来，真正影响 4K 播放体验的，就应该继续去看后面的请求到底去了哪里。