WebDAV 还是 AList 原生 API

更新于 2026 年 8 月 31 日 · 适用于 AList 与 OpenList

两条路的样子

AList 同时对外提供两套东西：一套自己的 HTTP API，一套 WebDAV 网关。同一个文件，两套接口取到的播放地址完全不同：

原生 API（多数网盘）
  网盘 CDN  ================================>  你的手机
  （AList 只在最开始被问了一句「这文件的直链是啥」）

原生 API（夸克视频 / 本地存储）与 WebDAV
  网盘  ======>  AList 机器  ======>  你的手机
  （每一个字节都在中间那台机器上过一遍手）

原生 API 的工作方式是：客户端问 AList 要某个文件的 raw_url，AList 去问网盘、把签好名的直链回给客户端，然后就退场了。此后播放器和网盘 CDN 直接对话——这条流的速度取决于网盘的下发能力和你的宽带，跟你那台跑 AList 的机器完全无关。

WebDAV 没有这个环节。WebDAV 是个文件协议，它只会「把文件内容吐给你」，所以 AList 必须自己去网盘把数据拉下来、再转发给客户端。你那台中转机同时承担了下载端和上传端两个角色，而且是全程，不是只有开头。

顺带说明：原生 API 也不是永远直发。夸克视频和本地存储在服务端就是硬编码走 /p 代理的，这两档下原生 API 的流量路径和 WebDAV 是一样的，绕不开。混挂多个网盘时，同一个 AList 里不同网盘的片子走的路可能完全不同，这一点在OpenList 挂载后怎么看电影里有对照表。

逐项对比

为什么很多播放器走 WebDAV 会卡

第三方播放器图省事只接 WebDAV，是有原因的：WebDAV 是标准协议，写一次到处能用；接原生 API 得为 AList 单独写一套，还得处理它那些脾气（失败也返回 HTTP 200、path 字段是物理路径、代理地址可能拼成 127.0.0.1）。省下的这些工作量，代价就落在播放体验上：

• 上行带宽是最硬的墙。1080p 蓝光原盘约 20–40 Mbps，4K UHD Remux 常见 80 Mbps 以上。中转机若挂在家用宽带的上行侧，或者跑在软路由、低配 J 系列小主机上，这个数字很容易就是过不去的坎——而症状只是「转圈」，不会有任何报错告诉你瓶颈在哪。
• 转发是持续负载。直发模式下 AList 只在开头忙一下；WebDAV 下它要从头忙到尾，两个人同时看就是双份。
• 拖进度条更贵。每一次跳转都要中转机重新向网盘发起请求、重新定位、重新转发，延迟被叠了两跳。
• 网盘那边多了一层中间人。网盘对同一账号的并发和速率是有限制的，这些限制原本由播放器一个客户端承担，现在由中转机集中承担，更容易触发限速。

所以「AList 播 4K 卡」这个问题，很多时候换个走原生 API 的客户端就解决了，跟换宽带、换 NAS 都没关系。判断方法很简单：如果你的中转机是软路由或低配小主机，而阿里、115 这类支持直发的网盘上的片子也卡，那基本可以确定是被 WebDAV 这条路卡住的。

什么情况下 WebDAV 仍然是对的选择

这不是一篇「WebDAV 该被淘汰」的文章。有三种情况它是更好的，甚至是唯一的：

• 服务只提供 WebDAV。坚果云这类纯 WebDAV 网盘、NAS 上的 WebDAV 套件、各种自建服务，压根没有 AList 那套 API，那就填 WebDAV 地址，直接连即可，不需要为它专门架一个 AList。
• 你的存储本来就在中转机上。如果 AList 挂的是本机硬盘或同一台 NAS 上的目录，那么「直发」这个概念不存在——数据本来就在那台机器上，原生 API 此时也会走 /p。这一档下两者的速度差别很小，用哪个都行。（不过这种场景更该直接走 SMB 或 NFS，见群晖手机看电影用什么 App。）
• 你要的是通用性而不是速度。一个 WebDAV 地址可以喂给几乎所有客户端和备份工具，换设备、换软件都不用重配。如果你的片源以 1080p 为主、中转机上行也够，为了省心用 WebDAV 完全说得过去。

在 Vela Player 里两种都怎么加

两种都支持（接入步骤见AList 用什么播放器），但分在两个不同的类别下，这一点最容易找错地方：

「网盘」那一类里找不到 WebDAV，「局域网与 NAS」那一类里也找不到 AList——分类依据是「这是什么形态的服务」，不是「数据存在哪儿」。填好点测试并保存，它会先真的连一次再存。加完源都不会自动扫描，要点进去浏览到影视目录，点顶栏的纳入媒体库，之后海报墙、季集分组、续播进度这些都一样，跟你走的是哪条路无关。

常见问题

同一个 AList，我能不能两种都加？

可以，但没必要，而且同一批文件会被扫进媒体库两次。真要对比速度的话，加两个源、只把其中一个纳入媒体库，另一个留在文件页里直接点开播，对比起来更干净。

WebDAV 能刮削出海报吗？

能，两条路在媒体库这一侧地位完全相同：都是扫描后从文件名与目录结构解析片名、年份、季集，再去 TMDB / OMDb 匹配。刮削发生在手机上，跟走哪个协议无关。

外网访问时哪个更好？

更倾向原生 API，而且差距会被放大。走 WebDAV 时你家宽带的上行要扛住整条流；走直发时手机是直接连网盘的 CDN，家里的上行完全不参与——这时候你甚至不需要内网穿透带宽跟得上，只要能问到那句直链就行。

为什么我走原生 API 也一样慢？

看这条流是不是回到了 /p 代理上：夸克视频、本地存储是服务端硬编码走代理的。另外也可能是站点 URL 没配对导致地址拼错，见直链播放失败排查。

WebDAV 会不会更稳定，毕竟没有直链过期的问题？

「直链过期」不是稳定性问题，是客户端实现问题——直链每次播放前现取就没有这回事，扫描时把地址存进数据库才会第二天集体 403。反过来，WebDAV 引入了一个新的单点：中转机重启、负载高、网络抖动，整条播放链就断了；直发模式下这台机器挂了，正在播的那一条流反而还能放完。