企业官网建设流程全解析

1. 这个项目到底解决什么问题

开始聊之前我先说两句实话。很多人第一次接触网站搭建、NAS穿透、服务器部署的时候，最先遇到的技术门槛往往不是业务本身，而是"怎么把某个服务安全地暴露到公网"。

你自己机器上跑了一堆服务：一个博客系统、一个在线文档工具、一个下载容器、几个开发中的测试接口，它们各有各的端口。直接对外开放意味着把N个不设防的端口暴露给全网扫描器，而且每个服务还要各自处理HTTPS证书，想想都头大。这时候Nginx Proxy Manager（后面统称NPM）就是为这个场景量身定做的工具。

NPM本质上是一层可视化反向代理管理面板。它把Nginx那套难啃的server块配置、SSL证书申请、访问权限控制，做成了网页上几个表单下拉框，点几下鼠标就能完成一条反向代理规则的发布。好处很明显：不用手动碰Nginx配置文件也能管好入口流量。对刚入门的同学来说，它像一个带翻译器的仪表盘；对老手来说，它能把大量重复的配置工作压缩成几秒钟的操作。

我自己的习惯是：只要是单机或者少机器场景，入口流量尽可能都交给NPM走一道。所有服务统一从80/443进来，由NPM按域名分发给各个后端服务。有了它，访问服务不再需要记端口，域名对了、HTTPS对了、转发规则对了，就完事了。这篇文章就按"安装、配置、实战"的路线，把NPM完整跑起来，也把过程中容易踩的坑一次性说清楚。

1.1 NPM是什么：一套可视化的反向代理翻译层

通俗点说，NPM就是给Nginx包了一层皮。Nginx本身是极其强大的反向代理和Web服务器，强大到它的配置文件语法庞大、指令繁多，普通人看它如同看天书。NPM的做法很粗暴：你在网页后台填好"域名、目标地址、端口"，它自动帮你生成对应的Nginx配置块；你要HTTPS，它帮你对接Let's Encrypt自动申请和续期证书；你想限制某些IP访问，它通过Access List直接配置在对应的server块上。

从实现方式上看，NPM本身也是一个Docker容器，跑到宿主机之后接管宿主机的80、443端口。它并不替代你原有的服务容器，而是作为一个"流量中转站"存在。外部用户请求 www.example.com -> DNS解析到宿主机 -> NPM容器处理HTTPS并反代到内部某个服务的IP端口。用户不关心你内部到底是什么实现，只要域名能通、证书正确、数据能返回即可。

因为NPM的数据管理是靠SQLite数据库加本地证书目录，所以它其实非常轻量，一个最基础部署占用内存通常在300MB以内，适合放在小内存VPS、家用小主机、NAS上长期运行。

1.2 为什么我没有直接选裸Nginx或全功能面板

有人会问：既然底层是Nginx，我直接手写Nginx配置不香吗？面板那么多，为什么选NPM？

• 裸Nginx学习曲线陡峭，而且每个server配置块往往有一大段重复样板：监听443、证书路径、tls参数、location转发、日志路径、WebSocket头。写多了之后，维护成本很高，一旦某个域名下了、证书换了，忘记同步清理都很正常。
• 全功能服务器面板（比如各类建站面板）功能太杂，面面俱到反而目标不聚焦。为了管理反向代理去装一个整套网页管理环境，资源开销大、攻击面大，而且面板的更新和维护风格未必适合轻量部署。
• NPM的功能边界很清晰：代理、SSL、访问控制、简单流式转发。别指望它像全能面板那样管DNS、管数据库、管文件，但就做好"入口流量管理"这单一职责，已经能覆盖绝大多数个人和小团队的使用场景。

它的代价是引入了新的运维实体，但只要打包成Docker容器，升级和数据备份都很简单。我试用下来，NPM在整个方案里的性价比很高，适合作为一台服务器或NAS的统一入口。

1.3 一个典型的落地场景

给你一个具体画面：我维护的一台机器上有三个服务在跑，一个是基于某种框架的Web应用容器，监听8080端口；一个是内容管理类的服务，监听9000端口；还有一个内部工具，监听5601端口。这套东西以前访问方式类似：浏览器敲IP加端口，哪个端口开放给公网，哪个服务就没有加密，很不安全。

把NPM放进来之后，我做了三件事。给每个服务分配一个二级域名，比如 app1.example.com、app2.example.com；在NPM后台给每个域名创建代理主机，目标指向各服务的容器名加内部端口；给每个代理启用SSL并开启强制HTTPS。完成之后，用户只需要输入规范的域名，整个过程不需要告诉任何人端口号。NPM真正面向的，是所有希望"一个域名对应一个服务"的人，不用关心服务器内部怎么调度。

2. 安装部署：Docker Compose几分钟搞定

NPM的官方推荐方式是Docker部署，这也是普遍推荐的做法。无论用的是云服务器、本地虚拟机还是NAS设备，只要装好Docker环境，后面基本是复制粘贴的事。

2.1 部署前的三个必备条件

第一个条件：一台能稳定运行的Linux机器（或支持Docker的NAS、小主机）。NPM本身对系统要求很低，512MB内存的机器也能跑，但是后端服务都在同一台机器上时，要根据业务体量合理安排资源。

第二个条件：域名。如果你只想在内网通过IP访问NPM后台，那么最小化部署只要NPM本身可用即可。但如果想要HTTPS证书自动签发，必须有一个域名，并且域名的DNS解析记录要准确指向宿主机的公网IP。证书签发机构在验证域名归属时，走的是标准域名验证流程，没有域名是不可能签发证书的。

第三个条件：宿主机的80、443端口必须为空闲状态。NPM接管这些端口之后，容器内的Nginx才能正常监听。如果你机器上已经装了别的Nginx或网页服务占用了80端口，需要先把服务停掉或换端口，否则容器起不起来，或者起来后端口冲突导致反代失败。

注意：别把NPM的Docker端口映射改到8888、8443之类的非常规端口去避开冲突。虽然容器能起来，但后续证书签发、HTTP访问都会变得别扭，标准方案就是让NPM容器直接用宿主机80、443。

2.2 写一份可以直接抄的compose配置

我部署NPM习惯用Docker Compose管理，配置清晰、升级方便。一个最小可用的docker-compose.yml如下：

version: "3.8" services: npm: image: jc21/nginx-proxy-manager:latest container_name: npm restart: unless-stopped ports: - "80:80" - "443:443" - "81:81" environment: - TZ=Asia/Shanghai volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt - ./logs:/var/log/nginx networks: - npm_net networks: npm_net: name: npm_net driver: bridge

解释一下几个关键点：

• 80:80和443:443是NPM对外服务的入口，分别承载HTTP流量和HTTPS流量。
• 81:81是NPM管理后台的访问端口，只在需要打开管理界面时使用。我建议这个端口只对可信网络开放，或者干脆用NPM本身的反代规则给后台绑定一个域名，配上访问列表保护起来。
• 数据卷./data里面存放了NPM的SQLite数据库、用户信息、代理配置；./letsencrypt存放签发的证书；./logs方便查看Nginx日志。
• 定义一个自定义网络npm_net非常关键，后面要让后端服务容器也加入这个网络，这样在NPM后台填目标地址时可以直接写容器名，而不是容易变化的IP。

写完配置后，在配置文件所在目录执行：

docker compose up -d

等镜像拉取完成，容器启动后，访问http://服务器IP:81就能进入初始化页面。默认管理员的邮箱和密码是admin@example.com/changeme，第一次登录后系统会强制要求修改密码。

2.3 初始化与登录细节

第一次打开后台，界面很清爽。左侧是Dashboard、Hosts、Access Lists、Settings、Audit Log等菜单。在设置里建议第一时间处理几件事：

• 修改管理员邮箱和密码，不要留着默认值。
• 设置后台的语言为中文界面（取决于版本，部分版本支持多语言），操作更顺手。
• 到Settings里面查看是否允许来自公网的访问，如果不需要，建议在云服务商的安全组限制81端口来源IP。

实操心得：我习惯把NPM自己的后台也通过NPM反代成一个子域名，并开启HTTPS。这样统一入口，也不需要在防火墙上单独开放81端口。但这一步要等你已经能熟练创建代理后，再回来加上。

初始化完成后，整个准备工作就绪。接下来就可以往里面添加第一个真实可用的反向代理了。

3. 核心配置实战：从代理主机到HTTPS一键签发

进入正题。这一章的内容是整个NPM使用过程中最高频的操作，也是你在网上搜教程时最常看到的"按步骤来"部分。

3.1 反向代理头两条配置长什么样

在后台左侧菜单点击Hosts -> Proxy Hosts，然后点Add Proxy Host按钮。界面上有四个标签页：Details、SSL、Advanced、Custom Locations，日常80%的时间都在Details和SSL两个标签页里打转。

在Details标签页中：

• Domain Names填你的域名，比如app1.example.com。如果你想让多个域名指向同一个服务，可以填多个，逗号分隔。
• Forward Scheme选择http还是https，取决于目标后端服务本身是否启用了HTTPS。绝大多数内部服务用http就够了。
• Forward Hostname和Forward Port填写后端服务实际的主机地址和端口。如果后端服务是另一个Docker容器，并且和NPM在同一个自定义网络里，这里可以直接填容器名，例如webapp、minio、portainer。
• 不要忘记勾选Block Common Exploits和Websockets Support。前者会拦截常见扫描攻击路径，后者让WebSocket服务能正常建立连接。

完成这些之后点Save，一条基本的反向代理就生效了。此时通过http://app1.example.com已经可以访问到后端服务，当然没有HTTPS，浏览器会警告。

这里最容易被忽略的就是"目标地址到底填什么"。很多人习惯填localhost或者127.0.0.1，这只有在后端服务恰好在宿主机网络命名空间中监听时才有效。如果后端是容器，NPM访问不到容器内部的回环地址。正确做法：先确认后端容器的网络模式，如果是默认bridge，用容器名即可；如果是host网络，则填宿主机IP或127.0.0.1。这个判断标准，比背教程更可靠。

3.2 Let's Encrypt证书签发背后的三个要素

SSL标签页是NPM的招牌功能。点开SSL标签页，选择Request a new SSL Certificate，勾选Force SSL、HTTP/2，然后填入你的邮箱用于接收过期提醒，点Save就能自动从Let's Encrypt申请证书。看起来很简单，但签发起不来的时候，往往都出在三个基础要素上。

• 域名必须能被公网正常解析。签发机构需要一个HTTP挑战：它临时生成一个验证文件放到你的域名根路径下，通过80端口请求验证。如果DNS解析没指向这台服务器，或者还没生效，验证必然失败。
• 宿主机80端口必须真实开放且没有被别的服务占用。NPM要接收来自外网的验证请求，如果80端口被墙、被防火墙间隔、被其他进程抢占，都会导致"域名验证失败(timeout)"。
• 如果域名通过某个CDN或代理服务做了加速，务必先关闭代理状态。很多CDN服务自带的云朵开关会让挑战请求返回代理节点的内容，而不是源服务器上NPM生成的验证文件，结果就是证书签发失败。签成功后再开启加速不影响。

在NPM里，证书申请成功后，再次点进SSL标签页，会看到证书的到期时间。NPM后台本身会在到期前自动续期，一般不需要手动干预。

提示：如果你不想让NPM自动管理证书，也可以选择Upload a custom certificate，粘贴已有证书的密钥和证书链，这在企业内部证书或某些特殊通用证书场景下非常有用。NPM支持这种手动模式，灵活度足够。

3.3 把访问权限管起来：两个小技巧

访问控制是NPM里容易被忽略但很实用的功能。在左侧Access Lists里，可以创建一组规则，比如"只允许特定网段"或"拒绝某些网段"。创建好之后，在代理主机的Details标签页里把Access List选上即可。

实现的效果是：访问请求进入NPM时，先根据用户来源IP进行匹配。匹配通过才继续反代，匹配不通过直接返回403或自定义错误页。

另一个实用技巧是给后台或敏感服务加Basic Auth。NPM的访问列表支持简单的用户名密码认证。启用后，浏览器会弹出一个原生弹窗，要求输入用户名密码。这个功能适合给一些内部使用的服务加上双保险，虽然不是最安全的方式，但是确实能拦住大量开放扫描流量。

我在实际部署中经常组合使用：管理类的服务只允许家里或办公网段的IP访问，再配一套独立于NPM账号的密码认证。这样即使某个服务的漏洞被扫描到，攻击者也无法直接发起请求。

4. 进阶玩法：容器联动、流式转发与自定义Nginx

基础代理配置已经能解决日常大部分需求，但NPM还有几个进阶功能，能让整个入口管理变得更加顺手。

4.1 让后端容器用固定名字接入同一网络

前面提到docker-compose里自定义了一个npm_net网络。如果后端服务也加入这个网络，NPM就能直接用容器名互相通信。这个方案比用IP靠谱得多，因为容器重启后IP经常会变动，而容器名在同一网络内是固定的。

假设你有一个名为notebook的笔记服务，docker-compose配置如下：

services: notebook: image: some/notes-app container_name: notebook networks: - npm_net

那么NPM代理配置里的Forward Hostname直接填notebook就行。只要服务和NPM在同一网络，NPM就能解析到这个容器名背后的动态IP。这个"固定名字替代动态IP"的思路，是所有容器化内网通信的通用技巧，不限于NPM。

做这个操作时要注意，后端容器不必映射端口到宿主机，只要在容器内部暴露端口即可。这样通过NPM访问服务，请求链路是外部 -> NPM容器 -> 后端容器，全程不经过宿主机端口映射层，内部网络开销更小也更安全。

4.2 非HTTP协议怎么办：流式代理配置

NPM不仅能做HTTP反向代理，还支持TCP和UDP流式转发。在左侧菜单里有一个Stream模块，点进去添加Stream，可以指定Source Port和Forward Host/Port。它会将特定端口的TCP/UDP流量原样转发给后端。

这个功能适合一些不走HTTP协议的场景：比如数据库远程管理、某些私有协议的服务、SSH转发、远程桌面等。配置很简单，在后台添加条目、指定监听端口和目标地址即可。但要注意，任何要对外暴露的TCP端口都会先被云端安全组和系统防火墙检查一遍，确保NPM容器映射了对应端口，规则才会生效。

我自己的使用场景是把某些非HTTP服务通过域名+端口方式收敛到NPM入口。虽然不能像HTTP一样按域名区分，但至少集中到一个地方管理端口转发规则，排错时不用满台机器找规则。

4.3 自定义Nginx片段的正确姿势

NPM虽然把Nginx封装起来了，但终究要留一个"高级玩家入口"。在代理主机的Advanced标签页，可以粘贴自定义的Nginx配置片段。这些内容会被嵌入到对应server块的特定位置。

比如你需要给某个路由增加缓存头、限制并发、修改转发头，都可以在这里写。一个常见的例子是调整文件上传大小限制：

client_max_body_size 100m;

另一个常见的例子是给某个location换一个根目录，或添加额外的请求头。这些片段写法与标准Nginx配置一样。

注意：Advanced标签页里的配置是插入到server块内部的，不能写events{}或http{}级别的指令，否则Nginx重载时语法检查会报错。判断原则：凡是在一个server{}内直接能用的指令，都可以在这里写。

自定义配置改完后，NPM会自动触发Nginx reload，如果语法错误，界面会提示"检测到无效配置"并拒绝应用。所以建议每次改动时保留一份已知正确的配置备份，避免改错导致整个入口不可用。

5. 常见问题与排查思路实录

工具再好用，也不可能不出问题。把我在实际使用中遇到并解决过的典型问题列出来，按频率从高到低排列。

5.1 502 Bad Gateway排错清单

502出现时，不要急着怀疑NPM坏了。90%的情况是"NPM把流量转发过去，但后端服务连不上"。

按下面顺序排查，通常能快速定位：

1. 检查后端服务是否真的在运行。在服务器上直接curl 容器名:端口测试，如果容器名解析不通，优先看网络是否在同一网络。
2. 确认Forward Hostname填写的是容器网络可解析的地址而不是外部域名。如果填的是公网域名，相当于NPM先访问公网再回到自己，容易因为防火墙或递归解析问题失败。
3. 检查后端服务绑定的监听地址。很多应用容器默认只监听127.0.0.1，从外部容器访问不到，要改成0.0.0.0。
4. 看NPM容器的日志，路径在之前compose定义的./logs下，或者直接docker logs npm。看到connect refused就说明后端没有起来，看到connection reset大概率是后端服务主动断开。

实操心得：遇到502先不要改NPM配置，先去验证后端容器的可访问性。用docker exec npm curl http://后端容器名:端口，一条命令就能把"入口问题"和"后端问题"区分开。

5.2 证书签发失败

我在群里看到最多的求助就是"证书签发失败"。失败的提示字面意思是DNS验证失败或连接超时，但背后的原因通常是：

• 域名解析确实还没生效，等几分钟再试。
• 宿主机安全组没有放行80端口，或者服务商处只放行了HTTPS端口。
• 域名所在域名服务商的DNS服务器响应慢，Let's Encrypt请求验证时超时。
• 多次失败触发了签发频率限制，短时间内无法再次申请。这时候只能等待，或换用DNS验证方式接入其他证书签发机构。

如果你用的域名服务商支持API操作，NPM也支持通过DNS Challenge方式向某些DNS服务商申请证书，也就是在DNS记录中临时添加一条TXT记录来完成验证。这种方式不需要打开80端口，适合80端口受限的环境。但需要提前在NPM设置里配置对应的DNS服务商凭据。

5.3 WebSocket连接不稳定与上传大小限制

之前创建代理时专门提到的Websockets Support开关，如果忘记打开，很多实时功能会异常：页面能打开，但实时推送、消息通知、终端交互全都卡住。原因在于WebSocket协议的Upgrade请求头没有被正确透传。

解决办法有两个：一是编辑代理主机，确认Details标签页里勾选了Websockets Support；二是如果场景特殊，可以在Advanced里手动补充：

proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

上传文件时提示413 Request Entity Too Large，这是Nginx默认限制了请求体大小。在Advanced标签页添加client_max_body_size并设置一个合理的上限即可。这个值根据业务来定，不是越大越好，得兼顾带宽消耗和服务器内存压力。

5.4 问题速查表

排查问题的总思路是分层处理：网络链路、DNS解析、NPM配置、后端服务状态，逐个排除。有了这套框架，大多数问题都能在几分钟内定位。

最后我再多说几句

NPM算是我在个人项目和团队小规模部署中使用频率非常高的基础组件之一。每次搭新环境，只要涉及对外提供Web服务，我都会先把NPM这台"入口守门员"立起来，再往后面挂业务容器。数据目录的备份一定要纳入习惯，因为data和letsencrypt两个目录里包含了所有代理配置、用户信息、证书，坏了重建很麻烦。我自己的做法是定期把这两个目录打包上传到对象存储或另一台机器，恢复时只需要解压回来再启动容器，几乎无缝。

还有一个小技巧是：给每个后端服务命名时尽量用可读性强的容器名，比如wordpress、uptime-kuma、portainer，这样在NPM后台填转发地址时一眼就知道指向哪里。命名规范这种东西，在规模小的时候觉得无所谓，服务越来越多之后极其值钱。

如果你只是想在几台机器上管理几十个域名和服务入口，NPM这套方案足够干净利落。如果你的需求已经上升到比较复杂的流量治理、A/B测试、灰度发布、细粒度限流，那确实需要回归裸Nginx或者更重的服务网格体系。工具选择从来不是越复杂越好，而是匹配场景才有意义。NPM适合的是那些不想把时间花在重复配置上、又能接受一定抽象层的人，我在实际项目中是越用越顺手，希望你跑起来之后也有同感。