Vaultwarden（Docker）怎么查看版本并升级？一套可复制的更新流程

• 域名、主机名、真实目录、容器 ID、时间戳、Token/密钥等信息均已替换为示例值。
• 命令输出为示例输出，仅用于帮助你识别成功/失败状态。

Vaultwarden（非官方 Bitwarden 服务端实现）用 Docker/Compose 部署后，升级维护的核心目标只有三个：

1. 版本可核对（升级前后都能确认版本变化）
2. 数据不丢（卷挂载目录可备份、可恢复）
3. 变更可回滚（至少能退回到上一个镜像/配置）

下面按一套“可复制”的流程来做。

0）前提：确认你有 Docker 权限

先试：

1
docker ps

• 能输出容器列表：权限 OK
• 若报 permission denied：用 sudo 或切 root

常用（切 root）：

1
sudo -i

1）进入 compose 目录

找到放着 docker-compose.yml 的目录（示例：/opt/vaultwarden）：

1
cd /opt/vaultwarden
2
ls

一般会看到：

• docker-compose.yml
• vw-data/（Vaultwarden 数据目录，示例名）

你的实际数据目录以 compose 里 volumes: 挂载为准。

2）查看 Vaultwarden 与 Web-Vault 版本（最准确）

直接在容器里查：

1
docker exec -it vaultwarden /vaultwarden --version

示例输出：

1
Vaultwarden 1.35.3
2
Web-Vault 2026.1.1

• Vaultwarden：后端服务版本
• Web-Vault：网页端静态资源版本

3）（强烈建议）升级前备份数据目录

如果你是这样挂载的（示意）：

1
volumes:
2
  - ./vw-data:/data

那么在 compose 目录下打包备份即可：

1
tar -czf vw-data-backup-$(date +%F).tgz vw-data

升级通常很稳，但备份是“低成本保险”。

4）拉取最新镜像

如果你的 compose 使用 latest：

1
services:
2
  vaultwarden:
3
    image: vaultwarden/server:latest

那么更新时拉取最新镜像：

1
docker compose pull

常见提示：version is obsolete

你可能会看到：

1
the attribute `version` is obsolete, it will be ignored

这表示 Docker Compose v2 不再需要顶层 version: "3"，会忽略它。

• 不影响运行
• 想消除提示：把 docker-compose.yml 顶层的 version: "3" 删除即可

5）用新镜像重建并后台启动

1
docker compose up -d

如果输出里出现 Recreated / Started，通常表示已成功用新镜像重建。

6）验收：看日志 + 再查一次版本

看启动日志（示例取最后 50 行）：

1
docker logs -n 50 vaultwarden

很多版本会在启动 banner 里显示，例如：

1
Starting Vaultwarden
2
Version 1.35.4

再查一次版本确认：

1
docker exec -it vaultwarden /vaultwarden --version

示例：

1
Vaultwarden 1.35.4
2
Web-Vault 2026.1.1

7）（可选）清理旧镜像，释放磁盘

1
docker image prune -f

这会清理“未被引用”的镜像层，不影响正在运行的容器。

8）安全加固：把 ADMIN_TOKEN 从明文改为 Argon2 哈希（推荐）

如果日志出现类似提示：

1
You are using a plain text ADMIN_TOKEN which is insecure.

说明你在 compose 里配置了明文管理员 Token。建议改为 Argon2 PHC 哈希，降低配置泄露风险。

8.1 生成 Argon2 哈希

在服务器上执行（会提示你输入原始 token；不要把 token/哈希粘贴到公开场合）：

1
docker exec -it vaultwarden /vaultwarden hash

会输出形如：

1
$argon2id$v=19$m=65540,t=3,p=4$...$...

8.2 替换 compose 里的 ADMIN_TOKEN

把（示意）：

1
environment:
2
  ADMIN_TOKEN: "你的明文token"

替换为：

1
environment:
2
  ADMIN_TOKEN: "$argon2id$..."

然后应用变更：

1
docker compose up -d

9）最小化“升级 SOP”（你可以贴到运维手册里）

1
cd /opt/vaultwarden
2

3
docker exec -it vaultwarden /vaultwarden --version
4

5
tar -czf vw-data-backup-$(date +%F).tgz vw-data
6

7
docker compose pull
8
docker compose up -d
9

10
docker logs -n 50 vaultwarden
11
docker exec -it vaultwarden /vaultwarden --version

10）常见故障：升级后突然打不开（ERR_TIMED_OUT / 只看到 SYN 没有 SYN-ACK）

这一类问题非常像应用挂了，但实际上经常是「云厂商的安全 sysctl 配置 + Docker 端口转发」组合导致的网络层问题。

典型症状：

• 浏览器访问 https://pass.example.com 直接 ERR_TIMED_OUT
• 服务器本机 curl -I https://127.0.0.1 -H 'Host: pass.example.com' 能返回 200（说明 nginx/Vaultwarden 正常）
• 抓包只看到外网 SYN 进来，但服务器没有回 SYN-ACK

10.1 快速定位思路（建议按顺序走）

1. 确认容器与端口监听

1
docker ps
2
ss -lntp | egrep ':80|:443'

2. 确认本机（内网 IP）443 正常（以云主机网卡 IP 为例）

1
curl -kIv https://10.0.0.2 --connect-timeout 3

3. 确认 DNAT 是否在工作（外网访问一次后看计数器是否增长）

1
nft list chain ip nat DOCKER

如果 tcp dport 443 ... dnat to 172.xx.xx.xx:443 的 counter packets 会增长，说明外网请求已到达并进入 DNAT。

4. 抓包判断是否回 SYN-ACK

1
tcpdump -ni <nic> 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'

只有 SYN 没有 SYN-ACK，基本就是系统层转发/过滤问题。

10.2 云主机常见根因：ip_forward=0

不少云镜像会通过安全策略把 IPv4 转发关掉（例如存在类似 60-*-network-security.conf 的 sysctl 文件），而 Docker 的端口转发/桥接依赖它。

检查：

1
sysctl net.ipv4.ip_forward

如果输出是 net.ipv4.ip_forward = 0，就会出现「DNAT 计数器涨，但流量进不了容器网桥」的情况，外网访问自然超时。

临时修复（立刻生效，无需重启）：

1
sysctl -w net.ipv4.ip_forward=1

如果系统没有 /proc/sys/net/bridge/* 相关项，说明 br_netfilter 未加载；可按需加载并启用：

1
modprobe br_netfilter
2
sysctl -w net.bridge.bridge-nf-call-iptables=1

永久化（推荐）

1
cat >/etc/sysctl.d/99-docker-forwarding.conf <<'EOF'
2
net.ipv4.ip_forward=1
3
net.bridge.bridge-nf-call-iptables=1
4
EOF
5

6
sysctl --system

以及让模块开机自动加载：

1
cat >/etc/modules-load.d/br_netfilter.conf <<'EOF'
2
br_netfilter
3
EOF

注意：以上为公开教程示例。实际环境请结合你的安全策略评估是否需要同时启用 bridge-nf-call-ip6tables 等选项。

结语

Vaultwarden 的 Docker 升级并不复杂，关键在于：

• 升级前后都要 核对版本
• 数据卷要 可备份
• 对外发布文档要 打码（域名/主机名/目录/Token 全部不要出现）

如果你希望更可控的升级策略（避免 latest 带来不可预期变更），建议把镜像 tag 固定为明确版本号，并在测试环境验证后再滚动到生产。