本文中的域名、IP 地址、路径、Token 等信息均已脱敏处理。
最近给新设备安装 Vaultwarden 浏览器扩展和客户端时，发现了一个奇怪的问题。
网页版能够正常访问登录，但浏览器扩展和客户端始终无法登录。后来又发现密码库中的附件无法下载，提示：
Failed to fetch浏览器控制台里还能看到类似错误：
net::ERR_EMPTY_RESPONSE相比扩展登录失败，我更担心附件下载的问题。
账号密码至少还能记住一部分，但附件里存放的各种密钥文件、备份文件和配置文件显然不可能靠脑子记住。如果附件真的出了问题，那麻烦就大了。
于是开始排查。
现象确认
最开始我以为只是输错密码。
因为问题最早出现在新设备安装扩展之后。
扩展输入：
自托管服务器地址邮箱（账号）主密码之后提示登录失败。
但网页版却能正常访问登录下载附件。
刚开始没太在意，以为是扩展的问题。
直到后来需要通过拓展下载一个附件时发现：
Failed to fetch而且所有附件都无法下载。（什么？你说网页版不是可以用吗？可那还是太麻烦了了嘛，哪有拓展来得快）
这时候基本可以确定：
问题不是密码输错那么简单。
先检查 Vaultwarden 本身
由于官方论坛里有人遇到过类似问题，并通过升级版本解决。
所以第一反应是：
是不是版本问题。
先查看当前容器情况：
docker inspect vaultwarden从输出里可以看到当时运行的是：
Version 1.35.8于是决定升级试试。
先停止并删除旧容器：
docker stop vaultwardendocker rm vaultwarden拉取最新镜像：
docker pull vaultwarden/server:latest然后重新创建容器：
docker run --name=vaultwarden \ -v /path/to/vaultwarden-data:/data \ -p 8080:80 \ -e SIGNUPS_ALLOWED=false \ --restart unless-stopped \ -d vaultwarden/server:latest确认版本已经变成：
Version 1.36.0然而问题依旧。
扩展仍然无法登录。
附件仍然无法下载。
说明升级不是根本原因。
直接测试附件接口
接下来决定绕过浏览器。
既然浏览器提示下载失败，那就直接请求附件下载接口看看。
首先从浏览器开发者工具中复制真实下载地址。
地址大致类似：
https://vaultwarden.example.com/attachments/<attachment-id>?token=<token>第一次在 Windows CMD 中测试：
curl -v "https://vaultwarden.example.com/attachments/<attachment-id>?token=<token>"结果直接报错：
URL rejectedPort number was not a decimal number between 0 and 65535后来发现是 Windows 下命令行对 URL 中特殊字符处理的问题。
于是改用 PowerShell：
curl.exe -v "https://vaultwarden.example.com/attachments/<attachment-id>?token=<token>" ` --output downloaded_attachment.bin这次返回：
HTTP/1.1 200 OKContent-Length: 5793文件成功下载。
而且大小完全正确。
这一步其实非常关键。
因为它证明了一件事：
Vaultwarden 容器本身没有问题，附件文件也没有损坏。
既然服务端能够正常返回文件，那么问题大概率出在：
- 反向代理
- Vaultwarden 外部 URL 配置
- 浏览器扩展与服务端之间的交互
- 客户端自身的问题
而不是数据本身。
检查 DOMAIN 配置
Vaultwarden 官方文档里提到过一个环境变量：
DOMAIN于是进入容器查看：
docker exec vaultwarden env | grep DOMAIN结果什么都没有输出：
说明根本没配置。
这时候开始怀疑：
是不是 Vaultwarden 在生成下载链接或者身份验证 Token 时用了错误的地址。
于是重新创建容器。
增加：
-e DOMAIN="https://vaultwarden.example.com"完整命令类似：
docker run --name=vaultwarden \ -v /path/to/vaultwarden-data:/data \ -p 8080:80 \ -e SIGNUPS_ALLOWED=false \ -e DOMAIN="https://vaultwarden.example.com" \ --restart unless-stopped \ -d vaultwarden/server:latest容器启动正常。
但问题依然没有完全解决。
于是继续往反向代理方向排查。
检查 Nginx 反向代理
我的架构大致如下：
公网 ↓路由器端口转发 ↓宝塔 Nginx ↓Vaultwarden 容器查看 Nginx 配置后发现：
proxy_pass http://192.168.x.x:8080;
proxy_set_header Host vaultwarden.example.com;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;这里缺少几个比较关键的头。
尤其是：
X-Forwarded-Proto如果这个头没有传递。
后端就无法知道：
用户访问的是 HTTPS。
还是 HTTP。
于是修改为：
proxy_pass http://192.168.x.x:8080;
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;proxy_set_header X-Forwarded-Host $host;proxy_set_header X-Forwarded-Port $server_port;保存后测试配置：
nginx -t确认无误：
nginx -s reload重新加载。
为什么 X-Forwarded-Proto 会影响登录和附件下载？（点击展开）
实际访问链路是：
浏览器 ↓ HTTPSNginx ↓ HTTPVaultwarden对于 Vaultwarden 来说，它看到的请求来自 Nginx。
而 Nginx 与 Vaultwarden 之间使用的是 HTTP 通信。
因此如果没有：
proxy_set_header X-Forwarded-Proto $scheme;Vaultwarden 就会认为用户是通过 HTTP 访问网站的。
这会导致它在生成某些绝对地址、下载链接或身份验证信息时使用错误的协议。
例如本应生成：
https://vaultwarden.example.com/...结果变成：
http://vaultwarden.example.com/...网页端大量使用相对路径，因此问题可能并不明显。
而浏览器扩展在登录验证和附件下载时会严格校验这些信息。
当协议不一致时，就可能出现：
- 浏览器扩展或客户端无法登录
- 附件下载 Failed to fetch
- 控制台出现 ERR_EMPTY_RESPONSE
等现象。
问题解决
修改完成之后。
重新安装浏览器扩展。
再次登录。
成功。
然后测试附件下载。
成功。
之前一直报错的：
Failed to fetch也消失了。
新设备同样能够正常登录。
问题彻底解决。
根本原因分析
后来回头看，其实问题来自两个配置缺失。
1. Vaultwarden 未配置 DOMAIN
当 DOMAIN 没有设置时。
Vaultwarden 在某些场景下可能生成错误的外部 URL。
尤其是在：
- 身份验证
- 下载链接
- 邮件链接
等功能中。
2. Nginx 未传递 HTTPS 协议信息
反向代理后：
客户端 → HTTPS → NginxNginx → HTTP → Vaultwarden如果没有：
proxy_set_header X-Forwarded-Proto $scheme;那么 Vaultwarden 看到的请求永远是：
HTTP而不是真实的：
HTTPS这会导致生成错误的链接和 Token 信息。
网页版由于大量使用相对路径，所以问题不明显。
浏览器扩展则更加严格，因此最先暴露问题。
总结
最终修复实际上只有两步：
Vaultwarden
增加：
-e DOMAIN="https://vaultwarden.example.com"Nginx
增加：
proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header X-Forwarded-Host $host;proxy_set_header X-Forwarded-Port $server_port;同时将：
proxy_set_header Host vaultwarden.example.com;改为：
proxy_set_header Host $host;之后：
- 浏览器扩展恢复正常登录
- 附件恢复正常下载
- 新设备登录正常
- 现有数据无需迁移
如果你也遇到：
Vaultwarden 网页正常扩展无法登录附件 Failed to fetch那么建议优先检查：
DOMAIN是否配置X-Forwarded-Proto是否传递- 反向代理头是否完整
这两个地方比升级版本更值得优先排查。
我觉得我是时候该给它弄个备份了？（
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时
