Nginx Proxy Manager 是一个可视化的 Nginx 代理配置的管理器，皇冠通过它可以避免手动编辑一个个 conf 文件的麻烦，还支持自动签发 SSL/TLS 证书。

本文将告诉你怎么部署和使用。这是一篇新手向教程。过程十分简单！

我不建议将这个工具用于企业的生产环境，因为它的设计不够好，并且健壮性也不行。这是我个人的评价，后文细节中我会给出原因。

当然，如果你是个人/测试用途，那么它还是很方便的。尤其是代理配置数量很多的情况。

我们使用 Docker 和 Docker Compose 部署它，创建 docker-compose.yml 文件：

services: server: image: "jc21/nginx-proxy-manager" restart: unless-stopped network_mode: host volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt

默认情况下，DG游戏它会监听 80/81 端口，如果本地有安装 Nginx 请禁用或卸载。确认无误后使用 docker-compose up -d 命令部署。

部署完成后，访问 81 端口进入此工具的管理页面。输入以下默认信息登录：

用户名 admin@example.com

密码 changeme

登录完成后，立即修改邮箱和密码。

我们创建第一个代理，以代理此管理页面为例子。进入 Proxy Hosts 页面，点击 Add Proxy Host，填写以下信息：

将 换成你自己的域名。由于这里代理的是此工具的管理页面本身，所以我建议使用例如 nginx-proxy-manager.example.com 这样的子域名。

接下来进入 Custom locations 这个 Tab 页面，欧博注册填写以下信息：

我们将 / 代理到本地的 81 端口（即管理页面的端口）。这样我们就可以通过 nginx-proxy-manager.example.com 访问此管理页面，而无需使用特别的端口。

现在重新访问绑定域名的管理页面，成功即表示第一个代理的创建正确无误。

如果你对防火墙要求很严格，你现在就可以禁止 81 端口的外部访问了。因为我们可以通过域名访问此管理页面。

本章节举例说明如何使用此工具申请 Let’s Encrypt 的免费证书。

进入 SSL Certificates 页面，点击 Add SSL Certificate 按钮，选择 Let's Encrypt。勾选 Use a DNS Challenge，然后选择你域名的 DNS Provider，例如 Cloudflare。最后填写相应的凭证内容。

步骤其实跟 Certbot 是一样的，欧博代理只是把参数放到 UI 上，过程自动化了。

假设你的域名是 example.com，请填写 example.com 和 *.example.com 这两个。这是普遍的通配符配置，前者用于域名自身（@ 解析），后者用于子域名（例如 www）。但要注意此处的通配符域名可以匹配 foo.example.com 或 bar.example.com 而不匹配 foo.bar.example.com。

即使你需要 foo.bar.example.com 这类三级域名，也不能添加 *.*.example.com 这种通配符域名。因为通配符 * 只能存在一个。这种情况下请手动添加具体的域名。

如果是 Cloudflare，请按照此步骤创建 Token。如果步骤对你太繁琐，也可以直接使用 Global API Key（注意风险）。对于其它 DNS 提供商，欧博官网只要 DNS Provider 列表中存在，就表示支持。需自行查阅相应的凭证内容获取方法。

如果你按照上述步骤进行成功创建了证书，你会看到类似下面的列表：

这里的 *.hentioe.dev 和 hentioe.dev 是一起申请的，即在创建对话框中同时填写了这两个域名（后者是通配符域名）。对于同一个域名，我建议创建到一起。

重新编辑代理，进入 SSL Tab 页面，选择你刚刚创建的证书：

此处编辑的是我博客的代理，即包含 blog.hentioe.dev,*.hentioe.dev 的证书。如果你分别独立申请了 example.com 和 *.example.com 两个证书，请选择包含通配符的域名证书。

如果你要删除证书，切记首先移除代理的 SSL 配置，然后再删除证书。如果你直接从 SSL Certificates 页面删除了证书，那么 Nginx 会启动失败，因为证书不存在但又被代理使用。这导致你不得不 SSH 到服务器手动编辑配置并重启容器，才能恢复访问。

这就是我认为这个工具不够健壮的原因之一。它缺乏证书删除前的必要检查，会产生错误的配置。

通过 UI 上的一些开关、输入框等你可以定制部分配置，但是很有限。例如添加一个 Location，必须填写转发相关信息。但实际上 Location 也可以用于其它目的，例如：

location ~ ^/styles.*\.css$ { add_header Cache-Control "public, max-age=31536000"; } location ~ ^/js/main.*\.js$ { add_header Cache-Control "public, max-age=31536000"; }

我这两个 Location，没有转发，而是添加了 Cache-Control 头信息。这对于网站而言很常见，将静态资源的缓存策略区别开。但是 Nginx Proxy Manager 的 UI 并不支持这样的配置。

如果要添加我上面的例子，需要进入代理的 Advanced Tag 页面，在 Custom Nginx Configuration 中输入其它类型的 location 配置。但是顺序你无法改变，它始终被添加到最前面。

进入 data/nginx/proxy_host/ 目录，会看到一些以数字递增命名的 conf 文件。这些就是一个个的代理配置。如果你查看它们的内容，会发现这些文件存在大量的空行，不合理的缩进。因为这个工具是基于模板插值来生成配置，这是一种不可靠的简单做法。

如果是我的话，我会为 Nginx 配置建立尽量完整的结构抽象，然后实现 render 来生成配置内容。这样可以提高生成内容的正确性（你可以做很多检查），并且是高度格式化的。不过我没有做这件事，这只是一个想法。所以我没有资格说这个工具不好，我只是认为它不够好。

对于其它的 Nginx 配置部分，例如一些全局的配置，你是无法通过此工具管理的。但这个工具也并不是毫无作为，它提供了一些路径，将该路径的文件插入到 Nginx 配置中。

一些例子：

创建 /data/nginx/custom/root.conf 文件，此文件的内容将被插入到 nginx.conf 的末尾。

创建 /data/nginx/custom/http_top.conf 文件，将被插入到主 http 块的顶部。

创建 /data/nginx/custom/server_proxy.conf 文件，将包含在每个代理服务器块的末尾。

所以它的局限性很大，不过还是能把一些基本的都配置上，只是不优雅。这是我认为它的设计不够好的原因，它远远没有达到对 Nginx 完整配置建立抽象的程度，只是大量的 Hooks。

完整请看。

这就是 Nginx Proxy Manager 的使用方法。它的功能很简单，对于新手来说是一个很好的工具。

但是此工具并非解决 Nginx 配置管理的最佳方案。我有提及它的缺陷，所以我再次强调不要用于生产用途。