Nginx Proxy Manager
💡 快速導航
Nginx Proxy Manager 是我 Home Lab 的反向代理入口。幾乎所有需要從瀏覽器或外部網路存取的服務，都先經過 NPM，再轉到後面的實際服務。
我把它當成整套 Home Lab 的「前台總機」：使用者記的是網域與 HTTPS 入口，而不是每個服務到底跑在哪台機器、哪個 port。
🎯 我為什麼用它
服務一多，不能再靠記 IP:Port
Home Lab 一開始服務少，直接輸入 IP:Port 還能接受。但服務變多後，這種方式很快會失控：
- 每個服務 port 不一致，難記也難分享給家人
- HTTPS 憑證分散管理，更新與除錯成本高
- 外部入口太多，防火牆與安全邊界變得混亂
- 服務搬家或換主機時，使用者端也要跟著改
NPM 把這些問題收斂成一個入口層。後端服務怎麼移動、port 怎麼改，只要更新 proxy host，使用者仍然透過同一個網域進入。
圖形化管理足夠直覺
我選 NPM 的原因不是它最強，而是它足夠直覺。Proxy Host、SSL 憑證、Access List 和自訂 Nginx 設定都能在 Web UI 裡管理，對日常維運很省時間。
🧱 在 Home Lab 裡的角色
flowchart TD U[使用者 / 瀏覽器 / App] --> DNS[DNS / 子網域] DNS --> NPM[Nginx Proxy Manager<br/>OMV / Docker] NPM --> HA[Home Assistant] NPM --> IMM[Immich] NPM --> QZ[Quartz Blog] NPM --> BW[Bitwarden] NPM --> OTHER[其他服務] NPM --> AUTH[Authelia<br/>Forward Auth]
NPM 位在 App Layer，主要跑在 OMV 的 Docker 環境。它不保存核心業務資料，但它是服務入口，所以一旦壞掉，很多服務即使本身正常，使用者也會覺得「網站掛了」。
目前狀態摘要
| 項目 | 目前做法 |
|---|---|
| 部署位置 | OMV / Docker |
| Image | jc21/nginx-proxy-manager:2.15.1 |
| 主要用途 | 反向代理、HTTPS 憑證、服務入口管理 |
| 對外入口 | HTTP / HTTPS，後端服務不直接裸露原始 port |
| 管理入口 | NPM Admin UI，只應限制在可信任網路或加強保護 |
| 持久化資料 | NPM app data、Let’s Encrypt 憑證、web root / challenge data |
Warning
NPM 是入口層，不應把它當成唯一安全防線。公開服務仍要檢查應用本身權限、登入保護、更新狀態和備份策略。
🐳 部署摘要
實際部署使用 Docker Compose，核心概念如下：
services:
nginx-proxy-manager:
image: jc21/nginx-proxy-manager:2.15.1
restart: unless-stopped
ports:
- "<http-port>:80"
- "<https-port>:443"
- "<admin-port>:81"
volumes:
- <npm-data>:/data
- <letsencrypt-data>:/etc/letsencrypt
- <web-root>:/var/www/html我在公開筆記中不記錄實際 domain、內網 IP、靜態 Docker IP 或管理端口。這些資訊屬於部署細節，應留在私有設定與備份裡。
目前 NPM 內的資料量
| 類型 | 數量 |
|---|---|
| Proxy Hosts | 32 |
| Certificates | 35 |
| Access Lists | 1 |
| Users | 1 |
| Redirection Hosts | 1 |
| Streams | 0 |
這代表 NPM 已經不是單一服務的小工具，而是整個 Home Lab 的共用入口元件。它的備份與還原優先級應該接近其他核心基礎設施。
🌐 Proxy Host 模型
我會把每個服務抽象成一個 Proxy Host：
service.example.com -> internal-service:port公開筆記中只保留模式，不保留真實 domain 或內網位址。
我的命名原則
- 每個服務固定一個主要子網域
- 管理後台和使用者入口盡量分開
- 不使用臨時名稱作為長期入口
- 服務搬移時優先改 NPM upstream，不讓使用者端跟著改
- 重要服務加上明確備註，避免日後忘記用途
為什麼不要直接公開服務 port
直接公開每個服務 port 會讓入口散落各處，也讓安全規則變難管理。NPM 的價值是把對外入口集中到少數固定端口，再由 proxy host 決定流量要去哪裡。
🔐 HTTPS 與憑證策略
NPM 負責集中管理 Let’s Encrypt 憑證。大部分 proxy host 都會啟用 SSL，並強制 HTTP 轉 HTTPS。
我會檢查的項目
| 項目 | 原則 |
|---|---|
| Force SSL | 對外服務預設開啟 |
| Certificate renew | 定期確認自動續期正常 |
| WebSocket support | 需要即時連線的服務才開啟 |
| HSTS | 依服務成熟度與回滾需求決定 |
| Admin UI | 不直接裸露到不可信任網路 |
憑證集中後，維運壓力小很多。以前每個服務自己處理 TLS，排查時要看很多地方；現在大部分 HTTPS 問題都可以先從 NPM 的 proxy host 和 certificate 狀態開始查。
🛡️ 與 Authelia 的分工
NPM 負責「入口與路由」，Authelia 負責「身份驗證與存取控制」。
sequenceDiagram participant User as User participant NPM as Nginx Proxy Manager participant Auth as Authelia participant App as Backend Service User->>NPM: Request protected service NPM->>Auth: Forward-auth check Auth-->>NPM: Allow / deny NPM->>App: Proxy request if allowed App-->>User: Response through NPM
目前有多個 proxy host 使用 Authelia forward-auth。這類服務不是只靠應用本身登入，而是在進入服務前先經過集中式身份驗證。
分工原則
- NPM：處理 domain、TLS、proxy、header、WebSocket、upstream
- Authelia：處理登入、2FA、access control policy
- 後端服務：保留自己的權限模型，不假設外層一定永遠有效
Important
反向代理和 forward-auth 是防線的一部分，不是免維護保證。後端服務仍要更新、設定強密碼、關閉不必要功能，並避免把管理介面暴露給不需要的人。
💾 備份與還原
NPM 的資料量不大，但重要性很高。需要保護的內容主要是：
- NPM app data：proxy host、users、access lists、設定資料庫
- Let’s Encrypt data：憑證與續期相關資料
- web root / challenge data：憑證驗證與靜態需求
- Docker Compose /
.env：服務啟動方式與掛載路徑
還原時的檢查順序
- 容器是否正常啟動
- Admin UI 是否可登入
- Proxy host 清單是否完整
- 憑證是否存在且未過期
- 重要服務是否能透過 HTTPS 入口連線
- Authelia 保護的服務是否仍正常完成 forward-auth
NPM 還原成功不代表所有服務都正常，但它能快速確認入口層是否恢復。
⚠️ 踩坑與維運原則
先規劃命名規則
我一開始沒有先把子網域命名規則想清楚，服務一多就會開始混亂。後來才發現，反向代理不是最後才補的東西，而是服務上線流程的一部分。
每個 Proxy Host 都要留下意圖
服務多了之後，最怕看到一堆 proxy host 但不知道誰還在用。現在新增服務時，我會順手記下：
- 這個入口給誰用
- 後端服務在哪一層
- 是否需要 WebSocket
- 是否需要 Authelia
- 是否能直接停用或刪除
入口層更新要保守
NPM 本身不難更新，但它影響面很大。升級前我會先確認備份，更新後優先測試最常用與最重要的服務入口。
結論
Nginx Proxy Manager 是這套 Home Lab 裡很重要的基礎設施。它讓服務入口統一、HTTPS 集中管理，也讓後端服務可以搬移或重建而不影響使用者入口。
它看起來只是 Web UI 版的 Nginx，但實際上是整套服務可用性的前門。只要服務需要被自己或家人穩定使用，NPM 就不只是附屬工具，而是必須備份、監控、謹慎升級的核心元件。