自托管密码库全过程：从部署、关注册、异地备份，到前门换线路的判断

摘要
浏览器自带的密码同步用起来方便，但账号、密码和安全笔记全放在别人的同步链路上，换设备、换浏览器都要重新适应。我的做法是在自己的一台云服务器上部署 Vaultwarden，把密码库的存储、同步入口和备份全部收归自己管理：容器只监听回环地址，对外只走反向代理；注册只为自己开一次，随即关闭；每天凌晨把数据异地备份两份；当前门线路在晚高峰拖慢同步时，依据实测把前门从 Cloudflare 切到 EdgeOne。这篇文章记录这套做法的完整链路，以及每一步取舍背后的判断。
一、为什么要自建密码库，而不是继续用浏览器同步
自建密码库的动机不是“更酷”，而是三个很实际的理由。
第一，入口统一。手机、电脑、浏览器扩展都连同一个密码库地址，新增或修改一条密码后，所有设备下次同步就能拿到，不用再逐台设备核对“这条到底改没改”。
第二，数据归属清楚。密码库文件就在自己的服务器上，备份策略、保留天数、存放位置都由自己定，不用猜服务商的保留规则，也不用担心某天免费档调整后导出受限。
第三，风险面可控。浏览器同步一旦主账号出问题，影响的是整条同步链；自建库出问题，影响范围就是这一个服务，排查和恢复的路径也短得多。
但自建也有代价，而且要先说清楚：服务器挂了、备份没做、证书过期了，责任全在自己身上。如果接受不了“自己就是运维”这一点，继续用成熟的托管服务反而是更稳妥的选择。我选择自建，是因为手头已经有一套跑着的备份和告警链路，密码库可以直接挂上去，而不是从零再搭一套。
二、部署：容器只监听回环，对外只留反向代理
部署本身不复杂，关键在“容器不直接见公网”这一条。我用 Docker 跑官方镜像，端口只绑在本机回环地址上，公网流量全部由 Nginx 反向代理进来：
services:
vaultwarden:
image: vaultwarden/server
container_name: vaultwarden
restart: always
environment:
- SIGNUPS_ALLOWED=false
volumes:
- vaultwarden-data:/data
ports:
- “127.0.0.1:8080:80”
对应的 Nginx 配置只做两件事：把域名指向回环端口，并补齐反向代理必需的转发头，让服务端能看到真实的客户端信息：
server {
listen 443 ssl;
server_name xx.xxx.xxxx;

location / {
    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;
}

}
证书用 Let’s Encrypt 的自动续期，域名解析和反代配好之后，浏览器里就是正常的 HTTPS 访问，没有自签证书的警告，也不用在每台设备上额外信任什么。
这样分层的好处在出问题时最明显：同步慢了，先看是反代层、证书层还是容器本身；容器异常了，重启或回滚只影响这一个服务，不用动整台服务器的网络配置。反过来，如果一开始就把容器端口直接暴露在公网上，之后每加一层防护都要改入口，不如一开始就把“只走反代”定为规矩。
三、注册只开一次：先建自己的账号，再把门关上
Vaultwarden 默认是允许注册的，这一步最容易被忽略，也最危险：部署完如果忘了关注册，任何人打开域名都能注册一个账号，虽然看不到别人的密码库，但白白多了一个入口和一堆垃圾账号。
我的顺序是固定的：先放开注册，只注册自己的主账号，确认登录和同步正常后，立刻把 SIGNUPS_ALLOWED 改回 false 并重建容器。改完之后要实测验证，而不是只看配置文件：退出登录，重新打开注册页面，确认新账号已经无法注册，才算这一步真正完成。
管理后台同样要单独设口令，并且只在需要时开启，平时不挂在常用入口上。密码库这类服务的安全策略就一句话：默认全部关闭，只把确实需要的那一个口子打开，而且打开之后要亲手验证它真的关上了。
版本升级也遵循同样的克制：只在自己确认过的版本上升级，升级后先验证登录和同步，再去看别的服务。我的实例目前跑在 1.37.5，升级后本地和公网访问都返回正常，才算一次升级完成。
四、备份：每天凌晨异地双写，无变化跳过，失败才告警
密码库是少数几个“丢了就无法靠记忆补回来”的服务，所以备份的优先级比部署本身还高。我的备份每天凌晨跑一次，规则只有四条，但每条都是被实际故障教育出来的：
第一，双写异地。备份同时写到对象存储 R2 和另一家云的对象存储，两份互为兜底，不把恢复的希望押在单一厂商或单一桶上。
第二，哈希比对、无变化跳过。每次打包前先算哈希，和上一份比对，没有变化就不重复上传。这样既省流量，也让备份记录本身变得可读：哪天没有变化，日志里就是干净的“跳过”，而不是一堆内容相同的重复包。
第三，14 天保留。保留期太短，误删后发现得晚就追不回来了；保留期太长，存储和清理成本又会悄悄上涨。14 天是我在“能覆盖一次出差加一次疏忽”和“不无限囤积”之间取的平衡点，到期自动清理，不靠人工记。
第四，成功静默、失败告警。备份成功不需要每天报平安，失败才同时通过聊天和自建推送通道告警。告警信息里要写清楚是哪一路备份失败、失败在哪一步，否则半夜收到一条“备份失败”也只能干瞪眼。
还有一条是习惯层面的：备份从来不等于“能恢复”。解包、导入、登录验证这套流程，要在不着急的时候单独演练一次，别等到真丢数据那天，才第一次验证备份包到底能不能用。
五、前门换线路：同步变慢时，先定位，再换门
这套密码库曾经遇到过一次很典型的“服务没问题，但用起来很慢”。表现是晚高峰时同步一次要拖好几分钟，第一反应很容易怀疑是服务器负载或容器出了问题。但本地检查下来容器和服务都是健康的，慢只出现在特定时段、特定入口上，问题指向的就不是后端，而是前门线路。
当时我的前门走的是 Cloudflare，晚高峰的表现不稳定。判断的办法不是换一家立刻下结论，而是先在原线路上复现问题，再切到 EdgeOne 之后用同一个办法验证：第一次同步仍然偏慢，第二次同步立刻完成。这个“一慢一快”的对照结果很关键，它说明慢不在数据本身，也不在服务器处理上，而在首次建连和线路环节；切过去之后第二次同步恢复正常，说明新线路在该时段确实更稳，于是前门就留在了 EdgeOne。
这次换门留下的经验有两条。第一，换线路之前要有可复现的判断依据，不能凭感觉换，换完也要用同一组操作验证，否则换完还是不知道到底修没修好。第二，回滚路径要事先想好：前门切换本质上是改一条解析记录，切过去之前就要知道怎么切回来，万一新线路表现更差，能在几分钟内恢复原状，而不是现查现改。
总结
自建密码库的完整链路其实可以浓缩成五句话：容器只监听回环，对外只走反向代理；注册只为自己开一次，验证关上了再收手；备份每天异地双写，哈希跳过、14 天保留、失败才告警；前门线路出问题时先定位再切换，切换前后用同一组操作验证；升级只升自己确认过的版本，升完先验证登录和同步。
这套做法没有哪一步是高深的，胜在每一步都有验证：注册关没关要实测，备份能不能恢复要演练，线路换没换好要对照。密码库值得这种啰嗦，因为它保管的是所有其他服务的钥匙。把验证做在平时，真出问题那天，才不用在慌乱里现补功课。