★ FEATURED ARTICLE 前阵子帮朋友调试一台放在家里的小主机装了各种服务有文件分享、有下载工具、有智能家居控制面板。每次远程过去他掏出的浏览器地址栏里永远是一串192.168.x.x:8080、192.168.x.x:9090问他哪个端口对应哪个服务他自己都要翻笔记。后来我帮他把 Nginx Proxy Manager简称NPM装上去把一堆服务统一挂到几个域名下面访问时只需要输入files.home.arpa、dashboard.home.arpa这种地址就行不用再记端口连他自己都感慨原来局域网网站还能这么玩。这篇文章就把整个落地过程写出来。包含为什么 NPM 能解决IP端口的痛点、Docker 部署的完整步骤、第一台反向代理的配置流程以及我实战中踩过的坑和排查思路。无论是家里有 NAS、小主机还是办公室内网跑了一堆内部系统这套东西都能让你的访问体验上一个台阶。1. 为什么还在敲IP端口这个习惯该改了1.1 一个真实场景从IP端口到域名访问的转变先说个最常见的画面。你有一台长期开机的服务器上面跑了三个服务Web管理后台监听8080文件服务监听9000监控面板监听3000要访问它们你的地址栏可能是http://192.168.1.10:8080、http://192.168.1.10:9000、http://192.168.1.10:3000。问题很快就暴露了端口号是数字不直观服务多了容易记混有些设备上的应用只允许配置一个服务地址没法每个都记端口。更麻烦的是某些服务默认监听端口是随机的或者你想让两个服务都用 80 端口比如想让web和files都走标准 HTTP 端口直接就会冲突。反向代理解决的就是这个矛盾。它的核心工作很简单你访问一个域名或固定地址代理服务器根据这个域名把请求转发到背后的某个具体 IP 加端口上。对外统一用 80/443 端口对内按域名分流。1.2 反向代理到底解决了什么问题你可以把反向代理想象成公司前台。访客不用知道某位同事在几楼几号工位IP端口只需要说我找销售部域名前台就会引导他去正确的工位。这个前台监听的是大门统一入口80/443 端口门槛统一、路径清晰内部怎么乱都不影响外面。在实际部署中反向代理带来几个直接好处统一入口所有服务都走 80/443不用再记:8080这种端口。域名分流一个入口可以带着 N 个域名不同域名转发到不同服务。SSL 证书统一管理证书签发、续期、套用都可以集中处理不用每个服务单独配。服务隔离与安全过滤可以在代理层做访问控制、拦截常见攻击。便于迁移后端服务换端口、换 IP用户侧完全无感只需要改代理配置。所以你看到的局域网网页访问本质上是两个问题的叠加一是地址不好记二是端口规划混乱。反向代理把这两个问题一起解决了。1.3 为什么局域网场景选 NPM 而不是手写配置有人会说Nginx 本身就能做反向代理手写 nginx.conf 不就行了确实可以但如果你经历过给 Nginx 配证书尤其是要申请、续期、配置 upstream、加各种 location 规则就知道那是一个坑接一个坑的过程。手写配置没问题但要做到超简单三个字NPM 更合适。NPM 是 Nginx Proxy Manager 的简称思路很直接把 Nginx 那个强大但不太友好的配置文件封装成网页上能点的表单然后在后台帮你生成 Nginx 配置。几个核心优势图形化管理添加域名、填后端地址、选几个选项保存就能生效。证书自动化在管理界面点几下就能申请证书、自动续期不用手动certbot。多用户权限家庭或团队场景下可以控制不同账号的访问权限。轻量易部署一个 Docker 容器就能跑起来对宿主机依赖小。说实话如果只是临时转发一个服务手写 Nginx 也不算难。但当你发现要维护的服务越来越多从第 5 个开始网页界面点选比写配置舒服太多了。这也是我推荐 NPM 的原因。2. 部署前的准备工作Docker 环境与网络模式选择2.1 确认基础环境哪些设备能跑怎么装 DockerNPM 本质上是容器化运行所以第一步是准备 Docker 环境。常见的运行载体有三类一台长期开机的 Linux 小主机/老电脑带 Docker 套件的 NAS 设备云服务器如果你想把内网服务对公网暴露NPM 同样适用。我这边以 Linux 系统为例安装 Docker 的大致命令如下不同发行版略有差异# 更新软件包索引 sudo apt update # 安装依赖 sudo apt install -y ca-certificates curl gnupg # 添加 Docker 官方软件源按系统架构选择合适的源 curl -fsSL https://get.docker.com | sh注意get.docker.com脚本适合快速安装生产环境建议按照你所用系统的官方仓库方式安装并锁定版本。装完之后用docker --version确认一下。如果你的载体是 NAS 设备通常在套件中心里找到 Docker 应用安装后直接通过图形界面配置容器即可下面涉及 docker-compose 的部分也能在容器管理界面里通过项目功能实现。2.2 网络模式bridge 还是 host先想明白再选这是很多人一上来就踩坑的地方。NPM 容器运行后对外提供 80、443代理入口和 81管理界面三个端口我们可以选择Bridge 模式容器映射端口默认推荐做法Host 模式直接共享宿主机网络我个人的建议是在 NAS 或小主机上用 Docker 默认的 bridge 模式加端口映射就足够稳定。原因有几个配置直观端口映射在界面上写清楚谁占用哪个端口一眼就能看到容器和宿主机隔离更清晰不容易误伤宿主机的现有服务故障排查相对简单因为流量路径是访问者 → 宿主机端口 → 容器内部 Nginx。Host 模式通常适合那些对真实客户端 IP有强依赖的场景或者你想让 NPM 直接复用宿主机网络环境。但 Host 模式最大的问题是NPM 直接监听宿主机 80/443/81如果这三端口被其他程序占用NPM 都起不来而且管理界面 81 也一并暴露在宿主机的所有网卡上。如果对端口占用没有把握建议先用 bridge 模式。2.3 端口规划80、443 和 81 这三个端口的角色开始部署前先明确 NPM 用到的三个端口端口角色备注80HTTP 反向代理入口提供 HTTP 访问也是证书验证的必经端口443HTTPS 反向代理入口提供 HTTPS 访问统一挂证书81NPM 管理界面网页配置后台不建议对外公网开放在你运行 NPM 之前先检查宿主机上这三个端口有没有被占用sudo ss -tlnp | grep -E :(80|81|443)\s如果 80 或 443 已经被别的 Web 服务占用你有两条路一是停掉旧服务把端口让出来二是把 NPM 的端口映射改成其他宿主机端口比如8080:80、8443:443但这样入口地址就不是标准端口了体验会打折扣。我一般优先选择把 80/443 专门留给 NPM毕竟它就是干这个的。如果你所在网络环境里路由器或主网关已经占用了 80/443而你又是把 NPM 装在那台设备上要特别小心 Host 模式。遇到这种情况bridge 模式加自定义宿主端口映射会是更安全的方案。3. 安装 Nginx Proxy Manager一份能直接照抄的 docker-compose3.1 完整 compose 配置与启动过程到这一步环境准备好了端口也确认过了。下面给一份我这边跑得比较稳的 docker-compose 配置version: 3 services: npm: image: jc21/nginx-proxy-manager:latest container_name: npm restart: unless-stopped ports: - 80:80 # HTTP 代理入口 - 443:443 # HTTPS 代理入口 - 81:81 # NPM 管理界面 volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt environment: - TZAsia/Shanghai把这份内容保存为docker-compose.yml然后在同级目录执行docker compose up -d稍等片刻镜像拉取完成容器启动。然后访问http://你的主机IP:81就能看到 NPM 管理后台。如果访问 81 端口无法打开页面优先检查防火墙。很多系统默认不开放 81 端口的入站规则需要手动放行。家庭路由器场景则要看是否启用了 AP 隔离等限制。3.2 首次登录与默认账号处理NPM 首次启动后默认登录信息是固定的官方默认账号第一次登录会强制要求修改邮箱和密码。这个默认账号不是什么秘密而且公网上经常有扫描器尝试用它登录所以把它改掉是必须的第一步。修改完登录信息之后先在右上角把界面语言相关偏好过一遍再把管理后台的访问方式确认一下。我的习惯是管理界面本身尽量不暴露到不信任的网络如果一定要远程管理可以用 NPM 自己做一个代理规则来保护它而不是直接把 81 端口映射出去。3.3 初始化时容易忽略的细节有几个细节不留意很容易出问题首次启动需要拉取镜像网络状况不好时可能超时可以重试docker compose up -d。NPM 内部会启动一个 SQLite 数据库数据存放在/data目录。所以./data这个卷的备份很重要里面不只是配置还包括你后续申请下来的证书关联信息。NPM 启动后会自动检查 Nginx 配置如果原有配置有语法错误容器可能反复重启日志里能看到具体报错。排查时用docker logs npm。4. 第一台反向代理配置从IP端口到域名访问的关键步骤4.1 添加 Proxy Host 的完整流程登录 NPM 管理后台后主界面有三个入口Proxy Hosts代理主机、Redirection Hosts重定向和 Streams端口转发。我们最常用的是 Proxy Hosts。点击 Add Proxy Host进入表单Domain Names 填你要访问的域名比如files.home.arpa。Forward Hostname / IP 填后端服务实际地址比如192.168.1.20。Forward Port 填后端服务实际端口比如9000。如果你希望访问时自动跳到 HTTPS勾选 Block Common Exploits 和 Websockets Support 按需选择。保存之后NPM 会立即生成对应的 Nginx 配置并 reload。此时如果你本机已经能解析files.home.arpa访问这个域名就会被代理到192.168.1.20:9000。一个后端服务可以对应多个域名也可以在同一个域名下通过路径区分不同服务比如home.arpa/files、home.arpa/dashboard。用路径分流时要注意后端服务自己是否处理了子路径否则会返回 404。这种情况我更推荐用独立子域名每个服务一个子域名逻辑最清晰。4.2 让局域网里所有设备都能认识这个域名配置好代理后最关键的环节来了你定义的域名设备得能解析到 NPM 所在主机上。局域网环境里常见是三种方案从简单到完善排列改客户端 hosts 文件适合只有一两台设备需要访问的场景。在电脑或手机的高级网络设置里把files.home.arpa指向 NPM 所在主机 IP 即可。缺点是要在每台设备上单独改离开这台设备就失效。路由器 DHCP 自定义 DNS / hosts很多家用路由器的高级设置里支持给内网设备下发自定义 DNS 地址或者直接下发自定义 hosts 记录。如果路由器支持这是性价比很高的方案全屋设备一次生效。但有些路由器界面没有这个选项或者品牌不同入口位置不同需要仔细找一下。局域网内自建 DNS 服务用一个小型 DNS 服务比如 dnsmasq 类容器给整个内网做解析然后在路由器 DHCP 设置里把 DNS 指到这台服务上。这样你可以在一个地方集中管理所有内网域名后续加服务只需要加一条解析记录。这套方案初期折腾一点但胜在可控性最强域名解析记录和 NPM 代理规则可以完全匹配。无论用哪种方案核心就一句话让访问者把home.arpa这类自定义域名解析到 NPM 所在主机的 IP后续所有代理规则都建立在这个基础之上。4.3 转发规则里几个容易忽略的选项NPM 的 Add Proxy Host 表单里有几个选项很多人不看就关掉后来出问题才想起来。我说下我平时的参考配置Block Common Exploits建议开启。它会启用一些常见攻击特征的过滤规则对家庭或内网场景来说多点防护总没坏处。Websockets Support如果你的后端服务用到了 WebSocket比如部分监控面板、在线编辑器必须开启。不开启的话页面能打开但实时刷新功能会一直转圈。Access List这里可以指定允许访问的来源 IP。内网场景如果只希望特定网段的设备访问可以建一个 Access List在白名单之外的全部拒绝。Custom Nginx Configuration某些特殊服务需要注入少量自定义 Nginx 配置时使用比如特殊 header 或额外 location 规则。大多数场景用不上但要知道有这个出口。有人问Forward Hostname/IP 填127.0.0.1行不行我在踩坑部分会说这个填写取决于你的网络架构但多数情况下填后端服务真实内网 IP 更稳。5. 进阶玩法SSL 证书、端口复用与多服务组织5.1 给内网域名配置 SSL 证书访问不再有警告HTTPS 在局域网里也很重要尤其是一些设备如浏览器、智能家居 App 对非 HTTPS 地址限制越来越多。用 NPM 给内网代理挂证书有两种典型路径你的域名是公网可解析的真实域名这种情况下可以直接在 NPM 的 SSL Certificates 里选 Add SSL Certificate → Lets Encrypt填域名并选择 DNS Challenge 或 HTTP Challenge。如果你把域名的解析记录指向了这台主机或这台主机的公网入口NPM 能自动完成验证、签发和续期。这种方式是无感自动续期的我比较推荐。你的域名只是内网自定义域名因为你没有公网解析控制权公共 CA 普遍没法完成验证NPM 的自动化签发在这里会失败。一个务实方案是创建本地自签名证书导入到各设备的信任列表里另一个方案是搭建内部 CA给每台设备统一信任。前者适合个人用后者适合团队或家庭统一管理。实际体验下来内网使用自签名证书时最重要的是让浏览器信任你自建的根证书。各设备信任一次之后后续访问 HTTPS 就不会再有红色警告。这个操作比想象中简单但需要你在每台设备上做一次导入。5.2 端口复用一个 443 入口转发 N 个服务配置好证书后端口复用的价值就体现出来了。NPM 统一监听 443所有服务都走 HTTPS不用为每个服务专门开一个公网端口。这样防火墙规则也简单入站只开放 80 和 443其他端口根本不用暴露。例如files.home.arpa→ 后端192.168.1.20:9000dashboard.home.arpa→ 后端192.168.1.20:3000cam.home.arpa→ 后端192.168.1.25:554全部通过 443 使用不同域名区分。管理这些规则在 NPM 的后台就是一行行的 Proxy Host 记录加服务、下线服务一目了然。5.3 用 Access Lists 做简单的访问控制NPM 的 Access Lists 功能可以让你在代理层做访问控制也很适合内网多服务场景。举个例子家里有孩子使用的设备和访客 Wi-Fi你想让某些服务只有你自己管理的网段能访问其他设备一律拒绝。这时可以在 Access Lists 里添加一条规则名称e.g.home-trusted规则Allow 来自192.168.1.0/24或指定 IP其余默认拒绝然后在对应 Proxy Host 的 Access List 里选这个名单即可。这样做的好处是后端服务本身不需要任何改动访问控制已经统一收口在反向代理层。管理多个服务时可以建一个全局限定规则也可以给敏感服务单独建更严格的名单。6. 实战踩坑我遇到的几个常见问题与排查思路6.1 网络模式选错导致 NPM 起不来我最初在一台自带许多服务的宿主机上部署 NPM 时图省事选了 Host 网络模式结果 NPM 一启动就报端口冲突。查看日志发现 NPM 的 Nginx 进程无法绑定 80/443因为宿主机上已经有一个 Web 管理界面占用了 80。后来我把网络模式改回 bridge并把映射改成8080:80、8443:443先把 NPM 跑起来后续再逐步清理旧服务的端口占用最终回归标准端口。这个经历给我的教训是如果宿主机上已有端口占用不要硬上 Host 模式。用 bridge 模式做映射至少能在不冲突的前提下先让服务可用精细化调整再慢慢来。6.2 配置代理后访问 502 Bad Gateway502 是 NPM 场景里最常见的问题原因多半是代理目标地址不可达。我碰到过一次后端服务监听的是127.0.0.1:9090NPM 容器配置里填了127.0.0.1:9090作为 Forward IP。但 NPM 容器内的127.0.0.1是容器自己不是宿主机所以怎么转发都通不了。正确做法是把后端服务的监听地址改到0.0.0.0或具体内网网卡然后在 NPM 里填宿主机内网 IP。比如后端服务和 NPM 在同一台机器上Forward IP 填这台机器的内网 IP如192.168.1.10而不是127.0.0.1。排查 502 的通用顺序直接在 NPM 所在机器上用curl http://后端IP:后端端口看后端是否可访问。检查后端服务的监听地址确认不是127.0.0.1而是0.0.0.0。检查防火墙。有些后端服务自带白名单只允许某些来源访问。6.3 管理界面打开了但代理域名一直不生效这种情况常见于域名解析没有正确生效。你配置了files.home.arpa但访问时浏览器提示找不到地址。这时候先确认在哪台设备上访问这台设备的 hosts 或 DNS 设置是否已经指向 NPM 主机路由器是否启用了 DNS 重绑定保护故意拦截了内网自定义域名有些路由器默认会拦截不常见的域名解析请求需要关掉相关过滤。我踩过最隐蔽的一个坑是DNS 已经解析到正确 IP但访问时浏览器自动走了代理配合浏览器的自动代理设置代理服务器并不认识内网域名。排查方案是暂时关闭系统代理或者把该域名加入不使用代理的名单里。6.4 持久化备份与日常维护心得用了 NPM 差不多一年我现在对它的维护主要集中在两点定期备份data目录升级前先看更新日志。data目录里保存了所有代理配置、证书状态和用户信息只要这个目录在换机迁移部署时把同一份数据挂载回去所有配置直接恢复。升级 NPM 时不要直接拉最新镜像就重启。先停容器备份data目录再拉新镜像启动。虽然大多数小版本升级无损但养成备份习惯能避免很多后悔。另外我习惯把 NPM 的地址固定成静态内网 IPDHCP 分配容易变动代理规则和后端转发目标也会跟着失效。如果你用的后端设备经常变 IP建议在 DHCP 里给这些设备设置固定地址或者直接手工配置静态 IP。这是减少后期维护成本最值当的一步。最后再分享一个体会NPM 解决的不只是记住端口的问题更是把一套服务管理的思路固化下来。你能很清楚地看到整张服务列表、每个服务的证书状态、访问来源限制这种感觉是手写 Nginx 配置时很难获得的。如果你的局域网服务也开始多起来花一晚上部署一个 NPM应该不会后悔。
阅读完成 · 觉得有帮助？
