Nginx Proxy Manager 評測：圖形化介面輕鬆搞定反向代理與 SSL 證書
NPM 是開源專案，採用 MIT 授權，原始碼公開在 GitHub 上。它本質上是一個「包裝層」，把幾個成熟元件整合在一起：
Nginx：真正負責處理流量與 TLS 終結的網頁伺服器。
Vue.js 前端：提供你看到的圖形化操作介面。
部署方式以 Docker 為主，官方映像檔是 jc21/nginx-proxy-manager。專案也提供社群維護的其他安裝方式，但社群共識是：除非你有特殊理由，否則一律用 Docker。原因很簡單，NPM 牽涉到 Nginx、Node、憑證工具等多個元件的版本搭配，手動安裝很容易在某個環節卡住，而 Docker 把這些相依性全部封裝好了。
2.2 主要功能一覽
下表整理了 NPM 的主要功能與實際用途，方便你快速判斷是否符合需求：
功能
說明
實用程度
Proxy Host
最基本的反向代理，把網域導向內部 IP 與連接埠
★★★★★
SSL 憑證管理
一鍵申請 Let's Encrypt 憑證、自動續期、強制 HTTPS 跳轉
★★★★★
Redirection Host
將整個網域 301／302 轉到另一個網址
★★★★☆
Stream（TCP／UDP）
轉發非 HTTP 協定，例如資料庫、遊戲伺服器、SMTP
★★★★☆
Access Lists
以帳密做 HTTP Basic Auth，或限制來源 IP
★★★★☆
404 Host
自訂找不到主機時回傳的頁面
★★☆☆☆
自訂 Nginx 設定片段
在自動生成的設定中插入手寫指令
★★★★☆
使用者與權限管理
可建立多個管理帳號
★★★☆☆
稽核日誌
記錄誰在什麼時候改了哪筆設定
★★★☆☆
2.3 它不適合處理什麼？
為了避免期待落差，這裡也要誠實說明 NPM 的邊界。它不是一個完整的 Nginx 管理面板，你不能透過它調整 worker_processes、設定複雜的 rewrite 規則鏈、操作 upstream 負載平衡的健康檢查，或是做精細的快取策略。它的定位是「反向代理與憑證的前台」，複雜邏輯仍然要靠自訂設定片段硬寫。
另外，NPM 也不是 WAF（Web 應用防火牆），它不會幫你擋 SQL Injection 或 XSS。若你需要這些，得另外串接 ModSecurity、Cloudflare 或專門的防護服務。
三、安裝與部署實測
3.1 用 Docker Compose 部署，五分鐘搞定
實測環境為一台 2 vCPU／2GB RAM 的雲端主機，系統為 Ubuntu 22.04，已預先安裝 Docker 與 Docker Compose。以下是官方推薦的部署方式：
version: "3.8"
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
ports:
- '80:80' # HTTP
- '443:443' # HTTPS
- '81:81' # 管理介面
environment:
DB_SQLITE_FILE: "/data/database.sqlite"
DISABLE_IPV6: 'true'
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
存成 docker-compose.yml 後執行 docker compose up -d，等個十幾秒，開啟瀏覽器連到 http://主機IP:81 就能看到登入畫面。整個過程不需要編譯、不需要設定資料庫、不需要碰任何設定檔。
有幾個部署細節值得注意。第一，80 與 443 埠必須是空的。如果你的主機上已經跑著 Apache、Caddy 或另一個 Nginx，請先停掉它，否則容器會啟動失敗。第二，data 與 letsencrypt 這兩個目錄一定要掛載出來，否則容器重建時設定與憑證都會消失。第三，若你使用 MySQL，記得把 DB_MYSQL_HOST、DB_MYSQL_USER 等環境變數補上，並將資料庫容器放在同一個 Docker 網路中。
3.2 首次登入與安全初始化
預設帳號是 [email protected]，密碼是 changeme。登入後系統會立刻要求你修改姓名、Email 與密碼，這個流程設計得不錯，避免了「忘了改預設密碼」的低級錯誤。
不過這裡有一個非常重要的資安提醒：預設狀態下，管理介面 81 埠是對外開放的。請務必在雲端防火牆或主機防火牆上限制 81 埠的來源 IP，或者更進一步，把 81 埠只綁定到內網位址，再透過 VPN 或 SSH 通道存取。我實測時就刻意掃了一下，還沒改防火牆設定的 NPM 實例幾乎都會在短時間內收到登入嘗試。這是很多教學文章忽略的一點。
3.3 非 Docker 安裝值得嘗試嗎？
專案本身有提供從原始碼建置的方式，需要手動安裝 Node.js、Nginx、Python 環境、Certbot 等相依項目。實測結論是：不推薦。原因有三：版本相依容易出錯；日後升級需要重新跑一次建置流程；一旦遇到問題，社群幾乎都以 Docker 環境為前提在回答。除非你的環境完全不允許 Docker，否則沒有必要走這條路。
四、圖形化介面操作流程實測
4.1 Proxy Host：新增第一個反向代理
點進「Hosts → Proxy Hosts → Add Proxy Host」，會看到一個分頁式的表單。實際填寫的欄位如下：
app.example.com。可以一次填多個，用逗號分隔。Cache Assets：是否啟用靜態資源快取。
儲存後，NPM 會即時生成設定、測試並 reload。整個過程大約一到兩秒，重新整理頁面就能看到新增的項目。我實測新增十筆規則，從頭到尾沒碰過終端機，這正是 NPM 的最大賣點。
值得一提的是，NPM 對 Docker 環境特別友善。如果 NPM 與後端容器在同一個 Docker 網路裡，Forward Hostname 直接填容器名稱就好，不需要知道實際 IP，容器重啟換 IP 也不影響。建議在 compose 檔案中建立一個共用網路，把所有服務接上去。
4.2 SSL 憑證：從申請到自動續期
在同一筆 Proxy Host 的「SSL」分頁中，選擇「Request a new SSL Certificate」，勾選「Force SSL」與「HTTP/2 Support」，同意服務條款後按下儲存。NPM 會在背景呼叫 ACME 流程，向 Let's Encrypt 驗證網域所有權，通常十秒內完成。
驗證成功後，憑證會存放在掛載出來的 letsencrypt 目錄中，並由容器內的排程自動續期。實測追蹤了三個月的續期紀錄，沒有出現任何需要人工介入的情況，這點比起手動維護 Certbot 確實省心不少。
但這裡有幾個常見的失敗原因，值得先知道：
4.3 Access Lists：替服務加上第二道門
有些服務（例如管理後台、內部監控、個人筆記工具）你不希望被任何人找到就能打開。NPM 的 Access Lists 提供了兩種控制方式：
第一種是 HTTP Basic Auth，建立使用者名稱與密碼（密碼以 bcrypt 雜湊儲存），然後在 Proxy Host 設定中指定這份清單。這樣一來，任何人連進來都會先看到瀏覽器原生的帳密輸入框。這對機器人與隨機掃描相當有效，但要注意它只是基本防護，密碼強度仍然重要。
第二種是 IP 白名單／黑名單，可用 CIDR 格式指定允許或拒絕的來源網段。實務上很適合「只允許公司固定 IP 存取」或「只允許自家 ISP 網段進來」的情境。兩者可以同時套用，形成雙重檢查。
實測下來，Access Lists 的設定直覺、生效迅速，是 NPM 被低估的功能之一。很多人只把它當反向代理用，其實這道防線的成本效益很高。
4.4 Stream 與 Redirection Host
Stream 分頁處理的是非 HTTP 流量。例如你的 MySQL 跑在內網的 3306，想從外部連線；或是自架的 Minecraft 伺服器需要 25565 埠。只要新增一筆 Stream 規則，指定流入埠與目標位址，NPM 就會用 Nginx 的 stream 模組轉發。
要注意的是，Stream 不支援 SSL 憑證申請（因為它不屬於 HTTP 協定），也無法套用 Access Lists。若需要加密，得在客戶端與後端自行處理 TLS。
Redirection Host 則是把整個網域轉向另一個網址，例如把 old.example.com 永久轉到 new.example.com。雖然用 DNS 的 CNAME 也能做到類似效果，但 301 轉址對於 SEO 的權重轉移更明確，且可以精細控制路徑。
五、進階應用與實用技巧
5.1 自訂 Nginx 設定片段
圖形化介面方便，但總會遇到介面沒提供的需求。NPM 在 Proxy Host 的「Advanced」分頁中提供了自訂設定欄位，你可以在這裡插入任意的 Nginx 指令。常見用途包括：
放寬上傳大小限制。Nginx 預設的 client_max_body_size 是 1MB，對於 Nextcloud、Immich 這類服務來說太小，會導致大檔案上傳失敗。這時插入 client_max_body_size 0; 即可取消限制。
調整逾時設定。某些處理時間較長的應用（例如大型報表匯出、AI 推論服務）會遇到 504 Gateway Timeout，可以加入 proxy_read_timeout 600s; 之類的指令延長等待。
加入自訂標頭。例如要整合 Google OAuth 或某些需要特定驗證標頭的服務時，可用 add_header 或 proxy_set_header 補上。
要注意的是，這裡的內容會被插入到自動生成的設定中，若你寫了衝突的指令，可能導致 Nginx 語法錯誤而 reload 失敗。NPM 在儲存前會做語法測試，不會讓整個服務掛掉，但你會看到錯誤提示。建議每次只改一小段，確認生效後再繼續。
5.2 用 DNS 驗證申請泛域名憑證
若你有一堆子網域（app.example.com、git.example.com、nas.example.com……），一張泛域名憑證 *.example.com 就能全部涵蓋，管理上清爽許多。泛域名憑證只能透過 DNS 驗證申請，而 NPM 支援多家 DNS 供應商的 API，包括 Cloudflare、Route 53、DigitalOcean、GoDaddy 等。
以 Cloudflare 為例，步驟是：到 Cloudflare 建立一組具備 Zone:DNS:Edit 權限的 API Token，回到 NPM 的「SSL Certificates → Add SSL Certificate → Let's Encrypt」，在 Domain Names 填入 *.example.com 與 example.com，勾選「Use a DNS Challenge」，選擇 Cloudflare，貼上 Token，儲存即可。NPM 會自動建立 TXT 記錄、完成驗證、再清除記錄，整個流程不需要你手動介入。
實測這個流程相當順暢，特別適合手上管理多個子網域的人。唯一的注意點是 API Token 的權限要最小化，不要直接使用 Global API Key。
5.3 搭配 Cloudflare 與真實 IP 還原
很多人會在 NPM 前面再掛一層 Cloudflare，好處是隱藏真實 IP、提供 CDN 加速與基本 DDoS 防護。但這會帶來一個副作用：NPM 的日誌裡看到的來源 IP 全是 Cloudflare 的節點 IP，導致 Access Lists 的 IP 規則失效，也無法從日誌判斷真實訪客。
解法是在自訂設定中加入 Cloudflare 的真實 IP 還原設定。由於 Cloudflare 的 IP 段會變動，比較穩妥的做法是定期更新清單，或使用社群維護的設定片段。設定完成後，日誌與 IP 規則就能正確識別原始來源。這個議題稍嫌繁瑣，但只要設定一次就能長期受益。
5.4 備份與遷移
NPM 的所有設定都存在資料庫裡，因此備份的核心就是備份資料庫檔案與憑證目錄。若使用 SQLite，只要定期複製 data/database.sqlite 與整個 letsencrypt 目錄即可。NPM 介面也提供了設定匯出功能，可以產生一份 JSON 備份，方便在另一台主機上快速還原。
實際遷移測試中，我在新主機部署好容器後，把備份的資料庫與憑證目錄覆蓋進去，重啟容器，所有 Proxy Host、憑證、使用者設定都完好如初，總共花不到十分鐘。這種「整包搬走」的特性，對於經常更換 VPS 或做災難復原的人來說非常實用。
六、效能、穩定性與安全性評測
6.1 效能表現
由於底層就是 Nginx，NPM 的效能基本上等於原生 Nginx，圖形化介面與資料庫只影響「設定變更」的流程，不影響實際的流量處理路徑。實測在一台 2 vCPU 的主機上，透過 NPM 代理的靜態網站可以輕鬆跑滿 1Gbps 網卡，並行處理數千個連線也沒有明顯延遲。
唯一會感覺到的差異是設定變更時的處理時間。每次新增或修改規則，後端都要寫入資料庫、重新產生設定檔、測試語法、reload Nginx。在 SQLite 環境下，這個流程大約一到兩秒，完全可接受。但如果你有數百筆規則且頻繁變更，改用 MySQL 會讓介面反應更順暢一些。
6.2 安全性考量
NPM 本身沒有重大災難級漏洞，但它的設計有幾個需要使用者自行注意的資安要點：
另外要提醒的是，NPM 的設計讓它成為網路的「單點入口」，一旦它掛掉，所有對外服務都會中斷。因此若你的服務有高可用需求，需要考慮多節點部署或改用其他架構。
6.3 穩定性與維護狀態
在長達數個月的實測期間，NPM 沒有出現過崩潰或需要重啟的情況。容器重啟後設定自動載入，憑證自動續期，整體來說相當穩定。
不過社群長期關注的一個議題是開發活躍度。這個專案在過去曾出現較長時間沒有新版本發布的情況，引起不少討論。就開源專案而言，維護節奏放緩確實是需要納入考量的風險，尤其當底層的 Nginx、Node.js 出現安全性更新時。實務建議是：把它當作一個「成熟但更新較慢」的工具使用，定期關注專案動態，並保留手動切換到原生 Nginx 或 Caddy 的能力。
七、與同類工具比較
反向代理的解決方案不只 NPM 一個，以下是幾個常見選項的橫向比較：
工具
操作方式
自動 SSL
學習曲線
彈性
適合對象
Nginx Proxy Manager
圖形化介面
支援（含泛域名）
自架新手、Home Lab
原生 Nginx + Certbot
設定檔
需自行設定
極高
有經驗的維運人員
Caddy
設定檔（極簡）
內建自動
喜歡簡潔設定的人
Traefik
標籤／設定檔
內建自動
極高
Kubernetes、大型容器環境
SWAG
設定檔＋範本
內建自動
中高
願意碰設定檔的自架玩家
簡單來說，如果你追求的是「最快讓服務上線」且不想學設定檔語法，NPM 是首選。Caddy 的設定語法已經非常精簡，但終究要編輯檔案；Traefik 功能強大但設定抽象，對新手不友善；原生 Nginx 彈性最高，但也是門檻最高的選項。
值得注意的是，NPM 的彈性其實不差——透過自訂設定片段，你能做到的事情比想像中多。真正受限的是「無法改變整體架構」這件事，例如複雜的負載平衡策略、動態 upstream 更新等。
八、優點與缺點總結
8.1 主要優點
狀態一目瞭然：所有代理規則、憑證效期、存取清單都在同一個介面中。
備份與遷移簡單：複製資料庫與憑證目錄即可整包搬移。
8.2 主要缺點
開發活躍度不如預期：版本更新節奏偏慢，長期維護性需要觀察。
管理介面本身是攻擊面：若未妥善保護 81 埠，風險相當高。
單點故障：作為唯一入口，服務中斷時影響面很大。
Stream 功能相對陽春：不支援憑證與存取控制。
非 Docker 安裝體驗不佳，幾乎等於被綁定在容器環境。
8.3 誰適合用 Nginx Proxy Manager？
非常適合：自架 Home Lab 的玩家、把多個服務放在單台 VPS 的個人開發者、小型團隊需要快速讓內部工具上線、對 Nginx 設定檔不熟的初學者。
不太適合：需要複雜流量調度的大型生產環境、必須嚴格遵循更新時程的合規場景、需要精細快取與 WAF 功能的高流量網站。這些情境下，原生 Nginx、Traefik 或搭配專業 CDN 會更合適。
九、常見問題 FAQ
Q1：NPM 可以跟其他網頁伺服器共存嗎？
可以，但需要調整連接埠或改用其他模式。由於 NPM 需要獨佔 80 與 443，若主機上已有 Apache 或 IIS，必須先讓它們改用其他埠，或把 NPM 部署到另一台主機。
Q2：憑證續期失敗怎麼辦？
先檢查網域的 DNS 是否仍指向正確 IP、80 埠是否暢通、Cloudflare 代理是否造成干擾。若狀況持續，可以到 SSL Certificates 頁面手動觸發續期，並查看日誌中的 ACME 錯誤訊息。
Q3：可以代理 WebSocket 服務嗎？
可以，只要在 Proxy Host 設定中勾選「Websockets Support」即可。多數需要即時通訊的服務（如 Nextcloud Talk、各種聊天工具）都必須開啟這個選項。
Q4：如何處理 502 Bad Gateway？
這通常代表 NPM 連不到後端。請確認 Forward Hostname 與 Port 是否正確、後端服務是否正在執行、兩者是否在同一個 Docker 網路中。若後端是 HTTPS 但 Scheme 選了 http，也會出現這個錯誤。
Q5：SQLite 與 MySQL 該選哪個？
一般自用環境選 SQLite 就好，零維護、效能足夠。只有在規則數量龐大、多人同時操作，或需要與其他系統共用資料庫時，才建議改用 MySQL。
Q6：更新 NPM 會不會遺失設定？
只要 data 與 letsencrypt 目錄有正確掛載，拉新映像檔重建容器後設定都會保留。更新前仍建議先備份一次資料庫。
十、結論與評分
Nginx Proxy Manager 解決的是一個非常具體、也非常普遍的問題：讓不懂 Nginx 的人也能安全地把服務推出家門。它把反向代理與 SSL 憑證這兩個最容易勸退新手的環節，壓縮成幾個表單欄位與幾次點擊。以我實測的體驗來說，從部署到第一個 HTTPS 網域上線，全程不到十分鐘，而且完全沒有打開終端機。
它的缺點也很清楚：開發節奏偏慢、管理介面需要自行加固、彈性有天花板。但這些缺點並不會讓它變得不值得用，而是提醒你——它是「簡化層」，不是「全能層」。你可以在它之上疊加 Cloudflare、在自訂片段裡補足特殊需求，也可以在未來規模變大時平順地遷移到原生 Nginx，因為底層的設定邏輯是共通的。
綜合評分如下（滿分 5 分）：
易用性：★★★★★
功能性：★★★★☆
效能：★★★★★
彈性：★★★☆☆
安全性（預設狀態）：★★☆☆☆（妥善設定後可達 ★★★★☆）
維護活躍度：★★★☆☆
整體推薦度：★★★★☆
如果你手上有一堆自架服務，卻一直卡在「怎麼讓它們安全上線」這一步，Nginx Proxy Manager 幾乎是目前門檻最低、回報最高的選擇。花一個晚上把它架起來，你會發現原本繁瑣的反向代理與憑證管理工作，真的可以變得輕鬆愉快。只要記得一件事：把 81 埠關好，它就是你最好的幫手；忘記關，它就可能變成你的惡夢。