你有一台 VPS,上面跑着五六个 Docker 服务:Nextcloud、Uptime Kuma、一个 Ghost 博客,也许还有一个 Vaultwarden。只有一个公网 IP。而你希望每个服务都拥有自己的子域名并启用 HTTPS,同时不必每加一个容器就手动编辑一次 Nginx 配置文件。这正是 Nginx Proxy Manager 要解决的问题。
本文将评测与完整的 Nginx Proxy Manager VPS 部署合二为一。Nginx Proxy Manager(NPM)是一款将 Nginx 封装进 Web 界面的 Docker 应用:你把子域名指向后端容器,并通过管理面板申请 Let's Encrypt 证书,而不必手动编写指令。本指南面向已经在使用 Docker、现在需要一个无需手动改动配置的反向代理的自托管用户和系统管理员, nginx.conf.
读完之后,你将知道 NPM 是否适合你的场景,会在 VPS 上把它连同 HTTPS 一起跑起来,并了解当 NPM 不再是合适工具时改用 Caddy 或 Traefik 的判断标准。
简短版本
- NPM 是什么: 一款在 Nginx 之上加了 Web 界面的 Docker 应用,用于管理代理主机和自动 Let's Encrypt HTTPS。它适合想要图形界面、且运行着规模较小、变动不大的一组服务的用户。
- 取舍: 配置保存在一个 SQLite 数据库里,因此不像配置文件那样可纳入版本控制或做差异比对。截至 2026 年 7 月 12 日,最新的标签发行版受 CVE-2026-40519 影响,因此新部署应等待包含该修复的标签版本。其位于 81 端口的管理面板是你必须重点锁定的地方。
- 规格选型: NPM 本身空闲时约占用 50 MB 内存。1 GB 的 VPS 是实际可用的底线;一旦加上它后面的各项服务,2 GB 会更从容。
- 何时改用其他方案: 如果你的服务栈规模小、基本不变,且看重图形界面,就继续用 NPM。如果你想要配置即代码、更小的占用,就用 Caddy。如果容器频繁变动,使得 Docker 自动发现比手动注册主机更有价值,就用 Traefik。
本指南不涉及的内容
这是一份 VPS 部署指南,而非参考手册。为保持聚焦,以下内容不在讨论范围内:
- 深度的 Nginx 指令定制(超出 NPM 界面所暴露范围的自定义 location 块)。
- 大规模的负载均衡架构。
- Kubernetes ingress 的对比。
- 在 Windows 上运行 NPM。
- 面向没有静态 IP 场景的 Cloudflare Tunnel 方案。
Nginx Proxy Manager 能做什么(以及它会在哪里坑你)
Nginx Proxy Manager 是一款 Docker 应用,底层运行 Nginx,并在其上加了一个 Web 管理面板。你通过表单而非配置文件来创建代理主机(子域名到后端容器和端口)并申请 Let's Encrypt 证书。它适合在一台 VPS 上运行的、规模较小且变动不大的一组自托管应用。
除了基础功能,管理面板还能处理访问列表和原始 TCP/UDP 流转发。对于一台 VPS 上的一组应用来说,这确实很方便:你加一个容器,打开管理面板,把一个子域名指向它,点一下签发证书,就完成了。
主要的取舍在于,NPM 作为唯一真实来源的配置默认保存在一个 SQLite 数据库中。NPM 确实会在以下位置生成可读的 Nginx 文件: /data/nginx/proxy_host/,但这些文件是生成出来的产物,而非你直接编辑并纳入版本控制的声明式配置。你可以查看它们,但它们并不能干净利落地替代 Caddyfile 或 Traefik 标签,而复现该部署的可靠办法是恢复 NPM 的数据卷和证书卷。对于规模小、变动少的服务栈,这或许可以接受。而对于以 Git 驱动的基础设施工作流来说,这是一个实实在在的限制。
截至 2026 年 7 月 12 日, 最新的标签发行版 为 v2.15.1,发布于 2026 年 6 月 3 日。该项目仍在活跃维护,并采用 MIT 授权,但其当前的安全状况有一个重要提醒:NVD 将 2.9.14 至 2.15.1 版本列为受以下漏洞影响: CVE-2026-40519,这是一个已认证命令注入漏洞,已在某次提交中修复: a5db5ed 但尚未包含在更新的标签发行版中。部署之前,请查看发行页面,并使用第一个包含该修复的标签版本。NPM 仍在维护中,但目前不应把 v2.15.1 描述为已完全修复。
在占用方面,根据 byte-guard 的反向代理对比,NPM 空闲时约占用 50 MB 内存。这已经足够轻量,NPM 几乎从来不是给你 VPS 造成压力的那一个,真正吃资源的是它后面的各项服务。
我的看法: 如果你想要图形界面且运行的是一个小型 Docker 服务栈,NPM 在 2026 年是一个合理的选择。如果你的日常离不开版本控制、想把代理配置放进 Git,那就看看 Caddy。决定因素是基于 SQLite 的配置方式,而不是代理本身有什么问题。
NPM 用配置可移植性换取了图形界面。对于规模小、变动少的服务栈来说,这笔交换没问题;而对于以 Git 驱动的工作流来说,则令人恼火。
NPM、Caddy 与 Traefik 对比:哪个反向代理适合你的 VPS
这三款工具在四个决定选择的维度上各不相同:如何配置、如何处理 HTTPS、如何随服务数量扩展,以及空闲时占用多少内存。以下是对比。
| 属性 | Nginx 代理管理器 | Caddy | Traefik |
|---|---|---|---|
| 配置模型 | Web 图形界面,存储于 SQLite | Caddyfile(文本,可纳入版本控制) | Docker 标签 / YAML |
| 自动 HTTPS | 支持,在界面中按主机逐个申请 | 支持,默认开启,零配置 | 支持,需要配置 ACME 解析器 |
| Docker 自动发现 | No | No | 支持,通过容器标签 |
| 空闲内存 | ~50 MB | 约 30 MB | 约 80 MB |
| 最适合的场景 | 图形界面用户,小型/静态服务栈 | 配置即代码,占用最低 | 容器频繁变动的动态 Docker 服务栈 |
空闲内存数据是来自 某项 2026 年对比的近似观测值,而非固定要求。实际占用会因镜像版本、启用的功能、流量和日志而异。
选择标准可直接从上表推导出来。如果你想要一个管理面板,且运行的是少数几个不常变动的服务,NPM 就是合适的工具。如果你偏好配置即代码、想要最小的占用,或欣赏 Caddy 的 无需任何 ACME 配置即可自动签发和续期 HTTPS,那就用 Caddy。在单站点部署中我自己就会选 Caddy,因为 SSL 处理是自动的,Caddyfile 也很简短。如果你频繁地添加、移除或重新部署容器,Traefik 基于标签的自动发现意味着你不必再手动注册每一个新主机。
还有搭配 Certbot 的裸 Nginx,一些管理员出于精确控制或非 Docker 部署的考虑更偏好它。Certbot 可以自动完成证书续期,但虚拟主机路由和 Nginx 配置仍需你自己管理。如果你考虑 NPM 的主要原因是想避免手动配置代理,那么裸 Nginx 不太可能是更合适的选择。
关于选择还有一点说明:byte-guard 的对比得出 Caddy 是该对比中最轻量的选项,对于 2026 年全新的单主机配置来说,这是一个合理的选择。Caddy 胜在比 NPM 更轻量,但如果你明确想要图形界面,它就不是你的最佳选择。
如需对底层引擎做更深入的并排对比,请参见 在 VPS 上 Caddy 与 Nginx 的对比.
先决条件:你会需要什么
部署之前,请先准备好以下这些。清单不长,但只要漏掉任何一项,后面的证书步骤就会失败。
- 一台已安装 Docker 和 Docker Compose 的 VPS (Ubuntu 22.04 LTS 或 Debian 12 均可)。
- 一个域名,并配有 DNS A 记录 (如果你使用 IPv6,还需 AAAA 记录)指向你的 VPS 公网 IP。
- 对该 VPS 的 SSH 访问权限。
- 在你的防火墙上向互联网开放 80 和 443 端口。
- 81 端口仅你自己可访问,不对公众开放(安全章节会讲到)。
使用 Docker Compose 在你的 VPS 上部署 Nginx Proxy Manager
本节使用 Docker Compose 部署 NPM。一旦你的 DNS 记录解析到该 VPS,容器本身的搭建就很快,不过 DNS 传播和证书签发可能需要更长时间。
该配置使用一个 Docker Compose 文件,以及一条一次性命令来创建共享的 Docker 网络。创建一个目录,创建该网络,添加下面的 docker-compose.yml 文件,然后启动容器。
首先,创建共享的 Docker 网络:
docker network create proxy
然后创建以下 docker-compose.yml 文件:
# docker-compose.yml
services:
npm:
image: 'jc21/nginx-proxy-manager:<PATCHED_VERSION>'
restart: unless-stopped
ports:
- '80:80' # public HTTP
- '443:443' # public HTTPS
- '127.0.0.1:81:81' # admin UI, reachable only from the VPS itself
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
networks:
- proxy
networks:
proxy:
external: true
将 NPM 必须通过服务名访问的每一个后端容器,都接入同一个外部 proxy 网络。这样 NPM 就能通过服务名解析到容器,而无需在 VPS 上发布后端应用的端口。
在升级前,请同时备份 ./data 和 ./letsencrypt 两者。数据目录包含 NPM 的数据库和生成的配置,而 Let's Encrypt 目录包含其证书材料。
关于这个文件有几点说明。该镜像默认使用一个 SQLite 数据库,保存在 ./data 卷中。这是默认的后端存储,对大多数单 VPS 部署来说是正确的。如果你需要外部数据库,NPM 支持 MariaDB/MySQL 和 PostgreSQL,这意味着要额外添加一个数据库服务和相应的环境变量。对于单台 VPS,除非你有明确理由把数据库移出数据卷,否则 SQLite 仍是最简单的默认选择。 restart: unless-stopped 策略意味着 VPS 重启后 NPM 会自动恢复运行,对于一个位于所有服务最前端的服务来说,这正是你想要的。
启动它并确认其正在运行:
docker compose up -d
docker compose ps
预期输出: npm 容器处于状态 Up,80 和 443 端口映射到公网,而 81 端口仅绑定到 127.0.0.1。首次启动会花上几分钟,其间 NPM 会生成 JWT 密钥、初始化数据库并创建默认管理员用户。 官方安装文档 描述了这一首次运行的流程。
在打开管理界面之前,先从你的本地电脑创建一条 SSH 隧道:
ssh -L 8181:127.0.0.1:81 user@your-vps
然后打开 http://127.0.0.1:8181 在浏览器中访问。全新安装时,使用以下凭据登录: [email protected] 和 changeme,然后立即替换默认的邮箱和密码。在默认凭据仍然有效时,切勿让管理面板可被公网访问。
修改管理员凭据后,添加你的第一个代理主机:
- 在管理面板中,前往 Hosts,然后 Proxy Hosts,然后 Add Proxy Host.
- 设置 Domain Name 设为你的子域名(例如
cloud.example.com). - 设置 Forward Hostname / IP 设为后端容器名或 IP,并将 Forward Port 设为它所监听的端口。
- 保存。该代理主机会出现在列表中,此后发往该子域名的流量便会到达你的容器。
如果你同时还运行着一个 Docker 管理界面,同样的方式也适用:用相同办法把一个子域名指向该容器管理工具,对于你想放在代理之后的 Prometheus 和 Grafana 监控栈 也照此办理。
为子域名配置自动 HTTPS
本节将为你的子域名申请一张有效且能自动续期的 Let's Encrypt 证书。有一个前提最容易被人忽略:该子域名的 DNS A 记录必须已经指向你的 VPS,而且 80 端口必须能从互联网访问,因为 Let's Encrypt 会通过回连该域名来验证它。
在代理主机创建好之后,申请证书:
- 编辑该代理主机,打开 SSL 标签页
- 在...下面 SSL证书选择 申请一张新的 SSL 证书.
- 启用 强制 SSL(Force SSL) 和 HTTP/2 支持。只有在确认 HTTPS 正常工作之后才开启 HSTS,因为浏览器会缓存该策略,从而使证书或代理配置出错后的恢复变得更加困难。
- 同意 Let's Encrypt 条款并保存。
默认情况下,NPM 对非通配符名称使用 HTTP-01 挑战,通过 80 端口验证每个请求的主机名。一张证书可以包含多个非通配符名称,但 HTTP-01 无法签发通配符证书。诸如 *.example.com 这样的通配符名称需要配合受支持的 DNS 服务商使用 DNS-01 挑战。对于常见的每个服务一个子域名的配置,HTTP-01 就够了,而且续期是自动的。
如果证书申请失败,请先检查 80 端口。 常见原因包括 80 端口不可达、云防火墙或安全组规则不正确,以及 DNS 尚未完成传播。Let's Encrypt 无法验证一个它无法访问的域名。
在 VPS 上保护 NPM 管理面板
位于 81 端口的管理界面是 NPM 部署中主要的暴露面,本节将把它锁定。这属于运维层面的加固,而非安全审计:三件事,各做一次,风险状况就会大幅下降。
第一,也是最重要的,让 81 端口保持绑定到 127.0.0.1 如 Docker Compose 文件中所示。通过前面描述的 SSH 隧道访问管理面板。如果你需要持久的远程访问,请让管理界面仅能通过私有 VPN 访问。不要在 VPS 的公网 IP 上发布 81 端口。
第二,为你的管理员账户启用 TOTP 两步验证。NPM 在 2.13.6 版本中加入了基于 TOTP 的 2FA,因此任何当前安装的版本都具备该功能。把它打开。
第三,让 NPM 保持已打补丁的状态,并核对确切的发行版本,而不要想当然地认为 latest 标签就是安全的。CVE-2026-40519 影响 2.9.14 至 2.15.1 版本,可能通过恶意的 DNS 服务商凭据实现已认证的远程代码执行。 CVE-2026-50892 影响 v2.14.0,可能让已认证的攻击者获取 Let's Encrypt 私钥材料。更早的一个问题 CVE-2025-50579 影响 v2.12.3,是一个可能暴露 JWT 令牌的 CORS 缺陷。实际的规则很简单:让 81 端口保持私有、启用两步验证、固定使用已知已打补丁的版本,并在升级前核对安全公告。
让 81 端口保持私有,让 NPM 保持已打补丁。做好这两件事,对于常见的单 VPS 配置来说,主要的已知风险就会容易管理得多。
为 Nginx Proxy Manager 选择 VPS 规格
NPM 本身很轻量;规格问题其实关乎的是 NPM 加上它后面各项服务的总和。代理的空闲占用很少成为瓶颈。一个 Nextcloud 实例或 Ghost 博客所用的资源,都会超过代理本身。
以下是各档规格在实际中的表现:
- 实际可用的最低底线:1 GB RAM、1 vCPU 和 10 GB 存储。 一 第三方规格选型指南 采用了相同的底线,但请把它当作规划参考,而非 NPM 的官方要求。它足以运行 NPM、操作系统和少数几个轻量服务,但留出的余量有限。
- 较为从容:2 GB RAM、1 vCPU、20 GB 存储。 NPM 加上三到五个服务,还有喘息空间。对大多数自托管用户来说,这是最合适的甜蜜点。
- 进阶:4 GB RAM、2 vCPU。 适用于八到十二个服务,或有一定流量、你希望为 TLS 终结留出 CPU 余量的配置。
你要据以选型的数字,是被代理各应用的总和,而非 NPM。把你打算运行的各服务的内存占用加起来,再加上代理那一点小小的空闲开销,然后在此基础上留有余量地挑选上面某一档。
给机器选规格是简单的部分。真正让 NPM 跑起来,仍然意味着开通 VPS、安装 Docker、拉取镜像,并走一遍首次运行的配置流程。如果你更愿意跳过这些开通步骤,Cloudzy 的应用市场提供一键 Nginx Proxy Manager 部署 ,运行在 NVMe VPS 上。它会在一台全新服务器上把容器搭建好,你便可直接进入管理面板并创建第一个代理主机。无论采用哪种方式,上面的规格档次都是你选型的依据。
常见问题
Nginx 和 Nginx Proxy Manager 有什么区别?
Nginx 是 Web 服务器和反向代理引擎本身,你通过编辑文本文件来配置它。Nginx Proxy Manager 是一款 Docker 应用,底层运行 Nginx,并在其上加了一个 Web 界面,因此你可以通过管理面板来管理代理主机和 Let's Encrypt 证书,而不必编写配置文件。NPM 是图形界面层;Nginx 才是干活的引擎。
2026 年 Nginx Proxy Manager 还值得用吗?
值得,对于偏好图形界面、运行小型 Docker 服务栈的用户是这样,但前提是你已确认所部署的镜像包含最新的安全修复。截至 2026 年 7 月 12 日,v2.15.1 是最新的标签发行版,NVD 将其列为受 CVE-2026-40519 影响。如果你偏好配置即代码,Caddy 仍是更合适的选择;NPM 基于 SQLite 的配置方式是其主要的运维局限。
Nginx Proxy Manager 的最低内存要求是多少?
NPM 本身空闲时约占用 50 MB 内存。1 GB 的 VPS 是一个实际可用的底线,足以运行 NPM 加上少数几个轻量服务。一旦你加入更多被代理的应用,2 GB 会更从容。真正的内存需求由 NPM 后面的各项服务决定,而非 NPM 本身。
我应该把 81 端口暴露到互联网吗?
不应该。让 81 端口绑定到 localhost,并通过 SSH 隧道访问它,或让它仅能通过私有 VPN 访问。不要在 VPS 的公网 IP 上发布管理界面。
我能不用 Docker 运行 Nginx Proxy Manager 吗?
不能。NPM 是以 Docker 容器的形式分发和设计的,没有受支持的非 Docker 安装方式。如果你不能或不愿运行 Docker,请改用搭配 Certbot 的裸 Nginx,或作为单个可执行文件的 Caddy。
Nginx Proxy Manager 支持通配符证书吗?
支持,需配置受支持的 DNS 服务商并使用 DNS-01 挑战。标准的单主机名证书通过 80 端口使用 HTTP-01 挑战;而通配符证书(*.example.com)需要 DNS-01,因为证书颁发机构是通过写入一条 DNS 记录来验证控制权,而非访问单个主机。