身為一名軟體工程師，我對「資料掌控權」與「環境可移植性」有近乎偏執的要求。
最近剛好有兩個需求同時浮現：一是替家裡的兩隻狗狗——二季與四季——整理一套長期可維護的專屬資料庫；二是為三月的日本名古屋與九州旅行，準備一個不依賴雲端訂閱制、又能跨裝置使用的密碼管理方案。在評估過各種 SaaS 方案後，我最終選擇回到老路：在自己的 NAS 上，搭一個真正屬於自己的 Vaultwarden。
這篇文章記錄的不是「怎麼三分鐘裝好服務」，而是一段從 DNS、反向代理到加密參數設定的實戰筆記，給正在考慮自建服務、或對數位自主權有執念的你。
整體設計思路：三層結構，優先降低維運摩擦
我的目標很明確：
在 Windows、Mac Air M4 與 iPhone 17 Pro 之間，建立一條穩定、低維護成本的加密通道，同時避免對外暴露服務。
最終架構拆成三層：傳輸、應用、安全。
一、傳輸層：用 Tailscale 解決 80% 的網路麻煩
我沒有選擇自己處理防火牆、Port Forward 或 DDNS，而是直接交給 Tailscale。
實際使用後，最大的優點有兩個。
MagicDNS：設備不再跟 IP 綁死
透過 MagicDNS，每一台設備都能用 .ts.net 網域互相存取。
即使內網 IP 改變、換網路環境，也不需要任何調整。
DNS 統一管理
我在 Tailscale 控制台整合了 AdGuard DNS，一次解決兩件事：
- 廣告與追蹤過濾
- 私有網域仍可正常解析
這讓整個網路行為在安全與便利之間取得平衡。
二、應用層：在 Synology 上部署 Vaultwarden
Vaultwarden 是 Bitwarden 的輕量化實作，非常適合 NAS 環境。
我使用 Synology 的 Container Manager 部署，重點放在兩件事。
資料持久化
所有加密資料固定掛載到：
/docker/vaultwarden/data
容器升級、重建都不會影響資料，這是自建服務最基本也最容易被忽略的一步。
實際效能體感
在 Mac Air M4（32G RAM）與本地 NAS 的組合下，
不論是 Web UI 還是 App 同步，延遲幾乎感覺不到。
三、安全層：反向代理是 Debug 重災區
這一層，是我花最多時間處理、也最容易翻車的地方。
WebSocket 設定不可省
在 Synology 的 HTTPS 反向代理中，必須手動加入 WebSocket 標頭：
UpgradeConnection
如果漏掉，Chrome 會出現登入後無限轉圈的狀況，
表面看起來像服務壞掉，實際上是代理層卡死。
加密演算法升級：Argon2id
我在 App 登入時遇到 KDF config is required 的錯誤，
最後的解法是將 Vaultwarden 的 KDF 改為 Argon2id。
這同時也符合目前對抗 GPU 暴力破解的主流建議。
完工後一定要做的防禦性設定
服務能用，並不代表安全。
關閉註冊功能
建立主帳號後，務必在 Container Manager 設定環境變數：
SIGNUPS_ALLOWED = false
這能避免服務網址被掃描後，遭到未授權的帳號註冊。
憑證指派要再次確認
在 NAS 的安全性設定中，確認 Tailscale 產生的 HTTPS 憑證
已正確指派給 Vaultwarden 使用的網域。
憑證錯誤時，網路再通，瀏覽器也會直接攔截連線。
結語：自建不是省錢，是選擇權
這套系統的成本，遠高於直接刷卡訂閱一個密碼管理服務。
但換來的是三件事：
- 資料在哪，我很清楚
- 架構怎麼跑，我能 Debug
- 什麼時候要搬走，不受人限制
如果你也對「把核心資料交給別人保管」感到不安，
或只是單純想替自己的數位生活留一條退路， 那麼自建 Vaultwarden，值得你花一次時間好好走完。
