WebDAV 连不上？从协议前缀到反向代理，一套排查流程全搞定

前言

WebDAV 是个好东西 —— 可以在 Finder 里像本地文件夹一样挂载远程目录、可以用 RaiDrive 映射成 Windows 盘符、可以给 Joplin / Obsidian 做同步后端。

但配置 WebDAV 的过程经常让人抓狂。URL 少了个 http://、反代少传了个 Header、AList 路径多打了个字母 —— 任何一个环节出问题都是连接失败，报错信息还经常不友好。

本文整理了最常见的五类故障和排查路径。下次 WebDAV 连不上，按这个顺序查。

一：协议前缀缺失

错误信息：

unsupported protocol scheme ""

原因：URL 里忘了写 http:// 或 https://。Go 的 HTTP 客户端看到以 / 开头的字符串不会自动补协议。

修复：

# 错误
webdav.myserver.com/dav


# 正确
https://webdav.myserver.com/dav

排查命令：curl -v https://webdav.myserver.com/dav，能返回内容说明 URL 没问题。

二：401 Unauthorized

WebDAV 最经典的错误。服务端收到了请求，但不接受你的凭据。

可能原因：

  1. 用户名 / 密码真的错了—— 最常见的答案也最容易忽略。确认一下，别猜。
  2. Basic Auth 的 base64 编码问题—— 有些客户端对特殊字符（@、:、#）的编码不一致
  3. AList 的 WebDAV 密码不是登录密码——AList 在后台单独生成 WebDAV 密码，跟账号密码是两套

排查：用 curl 手动测试

Terminal window
curl -u username:password https://webdav.myserver.com/dav

返回 401 → 凭据问题。返回 200 → 客户端配置问题。

三：AList 404 — API 路径 vs WebDAV 路径

AList 把 API 和 WebDAV 分成了不同路径：

https://alist.myserver.com/api   → REST API
https://alist.myserver.com/dav   → WebDAV

很多人把客户端连到了 /api 或者根路径，结果 404。

四：Nginx 反代配置缺 Header

WebDAV 走 HTTP 协议，但很多操作（PROPFIND、MKCOL、MOVE）不是标准的 GET / POST。Nginx 反代需要显式转发：

location /dav {
    proxy_pass http://127.0.0.1:5244/dav;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;


    # WebDAV 专用：转发所有 HTTP 方法
    proxy_set_header Destination $http_destination;


    # 大文件上传
    client_max_body_size 0;
    proxy_request_buffering off;
}

两个关键点：

  • client_max_body_size 0 — 不限上传大小，否则大文件被 Nginx 截断
  • proxy_set_header Destination $http_destination — WebDAV 的 MOVE / COPY 操作依赖这个头

五：500 Internal Server Error

服务端报 500，通常是存储层面出了问题：

  1. 存储路径不存在或权限不对：ls -la 看目录存在不，chown 改权限
  2. 对象存储（S3 / R2）配置错误：Access Key、Secret Key、Endpoint、Bucket 名，四个缺一不可
  3. 磁盘满了：df -h 看一眼

排查：直接看服务端日志

Terminal window
docker logs alist --tail 50

500 错误的服务端日志通常比客户端报错信息有用得多。

完整排查流程图

WebDAV 连不上
    │
    ├─ curl 通不通？
    │   ├─ 不通 → 检查 URL 前缀 + 网络连通性
    │   └─ 通 → 下一步
    │
    ├─ 返回什么状态码？
    │   ├─ 401 → 检查凭据（密码/AList WebDAV 密码/base64 编码）
    │   ├─ 404 → 检查路径（/dav vs /api vs 根路径）
    │   ├─ 500 → 看服务端日志（存储/权限/磁盘）
    │   └─ 502/504 → 反代没连上后端（proxy_pass 地址错了？端口不对？）
    │
    └─ 服务器直接连可以，反代后不行？
        └─ 检查 Nginx 配置（Host 头、Destination 头、body size）

总结

WebDAV 配置出问题不可怕，可怕的是不知道从哪里查。上面的流程从网络层到应用层逐层排查，大多数 WebDAV 问题都能定位。

核心原则：先用 curl 绕过客户端直接测试，排除网络和认证问题后，再看客户端配置和反代。