百度、115、夸克太分散？用 LitePan 把多网盘和影音入口收拢到一起

百度、115、夸克太分散？用 LitePan 把多网盘和影音入口收拢到一起

1、前言

网盘一多，真正麻烦的往往不是"文件放不下"，而是入口越来越散。

115 里一部分，百度里一部分，夸克里还有一部分。平时只是临时找文件还好，一旦准备把这些内容长期接进 Emby、Jellyfin 或其他影音库，路径、刷新、刮削和媒体输出就会开始变得复杂。

LitePan 解决的就是这类"多网盘 + 影音库"场景。它不是简单再做一个文件列表，而是把几个常见问题集中起来处理：

• 多个网盘账号先收口到一个入口；
• 普通挂载场景走 WebDAV；
• 影音库场景可以生成 STRM；
• 缓存、日志和插件继续放在本地维护。

这篇会先把 LitePan 本地部署起来，再把 WebDAV 和 STRM 的使用边界理清。只有当 5211 本地页面已经可用以后，才继续使用cpolar增加公网入口。

这里也需要先收紧一个结论：原文标题提到"比 AList、OpenList 更轻、更适合影音党"，但正文并没有做资源占用、性能或功能对照测试。因此这一版不会把它写成直接优于 AList / OpenList，而只保留原文能够支持的判断------LitePan 的产品定位更集中在多网盘聚合和影音库流程。

图 1：LitePan 负责收口网盘，cpolar 负责远程访问。

2、LitePan 主要解决哪几个问题？

LitePan 是一个轻量级多网盘聚合工具。按照原文引用的官方文档，它被描述为"轻量级多网盘挂载系统"，支持主流网盘接入、WebDAV 挂载和 STRM 生成。

真正值得注意的不是"又多了一个网盘工具"，而是它把几个影音场景里经常分散处理的环节收到了同一套系统里：账号、目录浏览、缓存、WebDAV、STRM 和插件。

原文归纳出的重点能力包括：

• 多网盘接入：115、百度、夸克、123、天翼、WebDAV 等都在支持列表里。
• WebDAV 挂载：适合播放器、本地文件管理器和其他支持 WebDAV 的软件。
• STRM 生成：更适合 Emby、Jellyfin 这类媒体库，减少直接扫网盘带来的压力。
• 缓存保持：让目录浏览更接近"本地磁盘"的手感。
• 本地化存储：数据、日志、STRM 和插件都放在本地目录，迁移和备份更直接。

从原文引用的官方 README 和文档看，LitePan 目前仍处于 Beta 阶段，定位也偏个人和家庭场景。

所以更合适的理解是：它在多个网盘和媒体库之间加了一层中枢。 前台负责浏览，后台负责账号和缓存，WebDAV 负责挂载，STRM 负责媒体播放路径。

3、先把 LitePan 本地部署跑通

原文按照官方文档使用 Docker Compose 部署 LitePan。

这一阶段先不考虑公网访问，只确认两件事：容器能不能正常启动，以及 5211 页面能不能从本地打开。

原文给出的 Compose 配置如下：

version: "3.8"

services:
  litepan:
    image: ponphil/litepan:latest
    container_name: litepan
    restart: unless-stopped
    network_mode: host
    environment:
      TZ: Asia/Shanghai
    volumes:
      - ./data:/app/data
      - ./log:/app/log
      - ./strm:/app/strm
      - ./plugins:/app/plugins

保存配置后启动容器：

docker compose up -d

容器启动后，通过下面地址验证 LitePan Web 页面：

http://服务器IP:5211

原文还说明，如果宿主机不方便使用 host 网络，也可以改成端口映射，只要保持 5211 对外可访问即可。

其中 data、log、strm、plugins 四个目录是后续迁移和备份时需要重点保留的内容。这个结构也说明 LitePan 的关键状态都被明确放在本地目录里。

4、别急着接媒体库，先把网盘账号和目录跑通

第一次登录后，先按页面提示修改管理员密码，再进入后台做账号接入。

比较稳妥的顺序是：

1. 在存储管理里添加网盘账号。
2. 按页面向导完成授权或 token 配置。
3. 先确认文件浏览正常，再决定走 WebDAV 还是 STRM。
4. 如果后面还要接媒体库，再去调缓存和 STRM 任务。

几个使用边界最好一开始就分清：

• 只做普通文件浏览或局域网挂载，优先考虑 WebDAV。
• 想接 Emby、Jellyfin 或飞牛这类媒体平台，优先考虑 STRM。
• 日常维护 STRM 时，原文建议优先使用"更新"；只有目录结构发生较大变化时，再考虑"全量"重建。
• 授权、刷新或目录异常时，优先检查缓存管理和系统日志。

这样可以避开一个常见坑：还没确认网盘目录本身稳定，就直接开始做媒体库。

先把账号接入和文件浏览跑通，再决定 WebDAV 还是 STRM，后面排查问题会简单很多。

5、本地已经可用，再考虑 cpolar

如果 LitePan 只在家里的局域网使用，前面的 5211 页面已经够了。

只有当人在外面，还希望继续打开 LitePan Web 页面时，才需要增加公网入口。

下面使用 cpolar 处理这一层。它不参与多网盘挂载、WebDAV、STRM 或缓存，只负责把本地 LitePan 服务从外部网络访问。

Linux 环境按照原文命令安装：

curl -L https://www.cpolar.com/static/downloads/install-release-cpolar.sh | sudo bash
cpolar version
cpolar authtoken xxxxxxxx
sudo systemctl enable cpolar
sudo systemctl start cpolar

安装并启动后，可以通过下面地址进入 cpolar Web UI：

http://127.0.0.1:9200

或者：

http://localhost:9200

登录 cpolar Web UI 后即可创建隧道。原文说明，cpolar 管理界面默认使用 9200 端口；如果发生端口占用，再另行修改。

6、把 5211 暴露到公网

要从外部网络访问 LitePan，原文的做法是在 cpolar 里创建 HTTP 隧道，并指向 LitePan 本地端口 5211。

原文建议这样配置：

• 隧道名称：litepan
• 协议：http
• 本地地址：5211
• 域名类型：测试阶段可先用随机域名
• 地区：按实际使用区域选择

创建完成后，先复制随机公网地址进行外网访问测试。能够正常打开 LitePan，才说明 5211 的远程访问链已经打通。

随机地址更适合先做连通性验证。如果准备长期保存这个入口，再去 cpolar 后台"预留"二级子域名，并把它绑定回 litepan 隧道。原文说明，这类固定二级子域名通常需要基础套餐或以上。

远程访问时还有两个容易忽略的点：

• LitePan 后台密码要足够强。
• 只开放真正需要的服务端口，不要为了省事把整台 NAS 直接暴露出去。

到这里，LitePan 本地聚合和外网访问才形成完整闭环。

7、结尾

LitePan 这篇真正解决的是一个很典型的家庭影音问题：网盘越来越多以后，先把账号、目录、挂载和媒体输出集中到一个入口里。

整套结构可以拆成两层：

• LitePan：负责多网盘接入、目录浏览、WebDAV、STRM、缓存和插件。
• cpolar ：只负责把本地 5211 Web 页面提供到公网。

原文标题里把 LitePan 和 AList、OpenList 放在一起比较，但正文没有实际跑资源占用、响应速度、媒体刮削或长期稳定性对照。因此这一版没有下"更轻""更强"的直接结论，只保留一个更稳妥的判断：从功能设计上看，LitePan 对 WebDAV、STRM 和媒体库链路的聚焦更明显。

另外，原文已经明确说明 LitePan 仍处于 Beta 阶段，所以如果准备长期用于家庭影音库，更适合先从小规模账号和目录开始验证，再逐步迁移。

本文仍以原文引用的 LitePan 官方文档和 cpolar 官方教程为基础，不额外扩展未在原文中验证的功能。