docker-compose部署bitwardenrs最稳：轻量（80–120MB内存）、兼容官方客户端、需配config.json禁注册/设admin_token/指定HTTPS域名，并通过Nginx反代透传WebSocket及HSTS头。
用 docker-compose 部署 bitwardenrs 是最稳的选择
官方 Bitwarden 服务端（bitwarden/server）依赖 .NET 运行时，内存占用高、启动慢、在低配 VPS（如 1C1G）上容易 OOM；而社区维护的 Rust 实现 bitwardenrs（现名 bitwarden_rs，项目已迁至 bitwarden/server 的兼容分支，但镜像仍广泛使用 quay.io/bitwardenrs/server 或更轻量的 bitwardenrs/server）更轻、更快、配置简单，且完全兼容所有官方客户端。别被名字误导——它不是“阉割版”，而是生产可用的替代实现。
实操建议：
- 创建专属目录，比如
/opt/bitwarden，避免混入系统路径 - 用
docker-compose.yml管理容器，而不是裸跑docker run，方便后续升级和备份 - 必须挂载持久化卷：
./data存数据库和附件，./config.json控制行为（如禁用注册、开启管理员面板） - 默认监听
http://127.0.0.1:8080，不暴露到公网 —— 这是安全前提，反向代理必须接管 HTTPS 终止
宝塔面板里配反向代理，location / 必须透传 WebSocket 和 Header
很多人部署完能打开首页，但登录后卡在“正在同步”或通知图标不亮，本质是没正确转发 SignalR 的 WebSocket 连接。Bitwarden 客户端依赖 /notifications/hub 建立长连接推送密码变更、设备登出等事件，Nginx（或宝塔内置 Nginx）若未显式支持 upgrade，就会降级为轮询，极慢甚至失败。
在宝塔「网站」→「反向代理」→「配置文件」中，确保包含以下三段（不能只写一个 location /）：
location / {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
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;
}
location /notifications/hub {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /admin {
proxy_pass http://127.0.0.1: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-Proto $scheme 决定客户端看到的是 http 还是 https，漏掉会导致重定向循环或混合内容警告。
config.json 里这几个键值不设好，等于裸奔
bitwardenrs 启动时会读取同目录下的 config.json。不配它，服务就按默认策略运行 —— 比如允许任何人注册、不强制 HTTPS、日志明文落盘，这些在公网环境极其危险。
关键配置项（必须手动写入）：
-
"domain": "https://passwd.yourdomain.com"—— 必须带https://，否则浏览器插件拒绝同步 -
"admin_token": "your_random_string_here"—— 设置后才能访问/admin页面，生成方式：执行openssl rand -base64 48 -
"signups_allowed": false—— 关闭公开注册，防止被当肉鸡收垃圾账号 -
"disable_2fa": false—— 别关，双因子是底线防护 -
"log_level": "warn"—— 生产环境别用debug，日志体积爆炸且含敏感字段
改完 config.json 后，必须重启容器：docker-compose down && docker-compose up -d，热加载不生效。
SSL 证书必须由宝塔自动申请并「强制 HTTPS」，别手动生成或复用旧证书
Bitwarden 客户端（尤其是桌面端和移动端）对证书链校验严格。用自签证书、Let's Encrypt staging 环境证书、或过期证书，会导致客户端报错 ERR_CERT_AUTHORITY_INVALID 或直接拒绝连接。
在宝塔「网站」→「SSL」页中操作：
- 选择「Let's Encrypt」，勾选域名，点击「申请」—— 宝塔会自动完成 DNS/HTTP 验证并续期
- 申请成功后，立即启用「强制 HTTPS」开关（本质是加了 301 重定向规则）
- 确认「SSL」选项卡里「当前状态」显示「已启用」，且「证书到期时间」在 3 个月以后
- 别手动替换
/www/server/panel/vhost/cert/下的 PEM 文件 —— 宝塔管理逻辑会覆盖它
最后验证：用 curl -I https://passwd.yourdomain.com 看返回头是否含 HTTP/2 200 和 Strict-Transport-Security 字段。没有，说明 HTTPS 没真正生效，前端代理或证书链仍有问题。
最关键的细节常被忽略：Bitwarden 的 Web 登录页、浏览器插件、移动 App 全部依赖 HSTS 和有效证书链。哪怕只差一级中间证书，iOS 客户端就静默失败，连错误提示都不给 —— 这类问题排查起来最耗时间。
