fnOS上部署Nginx Proxy Manager：用域名和HTTPS统一管理NAS服务

先说一个我自己的场景：家里的fnOS（飞牛私有云）上跑着NAS、相册、下载机、几个容器化的小服务，一开始每个服务都是一个“IP+端口”，时间一长我自己都记不住，更别提偶尔想给朋友分享一个页面的时候，对方看到一串带端口号的地址，第一反应永远都是“这啥”。后来我在fnOS上部署了Nginx Proxy Manager（以下简称NPM），用域名加反向代理把这些零零散散的服务统一收口，端口号彻底消失在访问路径里，SSL证书也能自动申请和续期，体验完全上了一个台阶。这篇文章就是把我从零部署到日常维护踩过的坑、摸索出的习惯，完整写出来，给同样在用fnOS、想搞清反向代理这事的你一个可以直接照着操作的参考。

1. 先搞清楚：为什么NAS上需要一个“反向代理管理器”

很多人第一次听到“反向代理”这四个字就头大，觉得是运维才需要的东西。其实放到普通家用NAS的场景里，它的作用特别好理解：你的fnOS上跑了十几个服务，每个服务监听一个端口，别人访问你的时候需要记“IP+端口”，这既难记又不安全，而反向代理相当于一个前台接待员，他坐在唯一的大门（通常是80/443端口）那里，你只需要告诉他“我要找A服务”，他就把你带到A服务对应的那个房间里去。

1.1 反向代理要解决的真实痛点

具体落到日常使用中，痛点非常实际：

• 端口暴露面大：每开一个服务就暴露一个端口，管理麻烦，扫描风险也高。
• 访问地址难记：192.168.1.10:8123、192.168.1.10:8080、192.168.1.10:9000，时间久了你自己都分不清哪个是哪个。
• SSL证书分散：如果想让某个服务走HTTPS，每个服务都要单独配证书，重复劳动。
• 路径跳转混乱：有的服务在反向代理之后会出现登录后跳转回IP+端口的问题，就是因为没有统一入口导致的。

反向代理把上面这些问题集中起来解决：对外只有一个入口，内部随便怎么拆分，用户感知不到后端的变化。

1.2 为什么要选NPM而不是自己手写Nginx配置

当然，纯粹用Nginx也能实现反向代理，只是你得去编辑nginx.conf，还得懂server块、location块、upstream这些概念，改错一个分号都可能让整个服务挂掉。NPM做的事情，是在Nginx之上包了一层图形化管理界面，把“创建反向代理规则”“申请SSL证书”“配置重定向”“查看访问日志”这些高频操作变成了填表单。

我用NPM而不是直接改Nginx的另一个原因是：它是一个长期维护的开源项目，社区活跃，资料多，遇到问题搜一下就有答案。你不需要成为Nginx专家，也能完成80%的日常反向代理需求。剩下的20%特殊需求，NPM也保留了“高级自定义配置”入口，可以直接往生成的Nginx配置里插入自定义片段，不至于被工具的边界卡死。

1.3 NPM在fnOS上的适配情况

fnOS本身就是为家用私有云设计的Linux系统，底层是Debian，自带Docker环境，运行NPM这种容器化工具非常自然。实际部署下来，NPM在fnOS上没有任何特殊兼容问题，CPU占用极低，内存占用大概200MB上下，对于NAS这种7x24小时开机的设备来说完全可以接受。

2. 部署前的环境准备与端口规划

开始部署之前，有几个规划工作建议先做，不然后面改起来很折腾。我最初就是没规划直接装，结果80端口被系统里的其他服务占用，排查了半天。

2.1 确认fnOS的Docker环境可用

fnOS在应用中心里带了Docker管理界面，但我建议你直接使用SSH终端操作，因为部署NPM这种方式写配置文件更直观、更容易版本化备份。

先用SSH登录fnOS，确认Docker环境：

docker --version docker compose version

如果没安装Docker Compose插件，你需要先补上。fnOS是基于Debian的，常见做法是直接安装docker-compose-plugin这个包，或者用pip装docker-compose。实测下来，用系统包管理器安装最稳。

2.2 端口规划：这步决定了你后面会不会折腾

NPM官方镜像默认监听三个端口：

家用场景里，80和443很容易被占用。常见情况包括：fnOS自带的Web服务、其他容器已经占用了这些端口、甚至光猫管理页面占用了80。我的建议是：把映射到宿主机的端口改为非标准端口，比如：

ports: - "8080:80" - "8443:443" - "8081:81"

这样宿主机的80/443端口就留出来了，不影响其他服务。NPM容器内部仍然监听80/443，它自己路由不受影响，只是外面访问入口变了。如果你有公网IP且想直接用域名访问不写端口，那最好确保80/443没有被占用。

2.3 数据目录规划

NPM有两个关键数据目录：

• data：存储SQLite数据库、配置信息。
• letsencrypt：存储Let's Encrypt颁发的SSL证书。

这两个目录必须持久化到宿主机上，否则容器一重建，你配置的所有代理规则和证书全部丢失。在fnOS里我习惯放在/vol1/0000/docker/npm/这种飞牛数据卷路径下，备份也方便。

3. 用Docker Compose部署NPM，一次跑通

我推荐用Docker Compose方式部署，理由很简单：配置文件写清楚之后，以后升级重建容器就是一条命令的事情，可复现性远好过在图形界面里点来点去。

3.1 编写docker-compose.yml

在fnOS的SSH终端里，先创建目录：

mkdir -p /vol1/0000/docker/npm cd /vol1/0000/docker/npm

然后创建docker-compose.yml：

services: npm: image: docker.io/jc21/nginx-proxy-manager:latest container_name: npm restart: unless-stopped ports: - "8080:80" - "8443:443" - "8081:81" environment: - PUID=1000 - PGID=1000 - TZ=Asia/Shanghai volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt

这里有几点说明：

• PUID/PGID：指定容器内进程运行的用户ID和组ID。你可以先用id命令查看你fnOS当前用户的UID，尽量保持一致，避免数据目录出现权限问题。
• TZ：时区设置为Asia/Shanghai，日志时间和证书续期时间会比较正常。
• container_name：给容器固定名字，方便后面用docker logs npm查看日志。
• restart: unless-stopped：NAS重启后容器自动拉起，不需要手动干预。

3.2 启动容器与初始登录

保存文件后执行：

docker compose up -d

第一次启动会拉取镜像，时间取决于网络情况。启动完成后，浏览器访问：

http://你的fnOS地址:8081

默认登录账号是admin@example.com，密码是changeme。登录后第一件事就是去修改密码和邮箱地址，这个默认账号任何人知道都能登录。

提示：NPM的默认密码是众所周知的，只要你的管理面板端口暴露在公网，极容易被扫描器登录并直接接管。部署完成后第一时间修改，不要拖。

3.3 飞牛应用中心方式的补充说明

如果你不想用SSH，fnOS应用中心也能搜到Nginx Proxy Manager，点安装即可。但我大概率不会推荐这种方式，原因有两条：

• 飞牛应用中心里的版本更新不一定及时，镜像源也未必是官方最新。
• 应用中心安装时端口映射是写死的，后续改起来不如Compose文件方便。

你要是完全没接触过命令行，用应用中心装也没问题，先把功能跑起来。等你熟悉了再改成Compose也不迟，反正在NPM里导出配置后迁移并不难。

4. 实战：添加第一个反向代理主机

NPM装好只是第一步，真正让它干活的是添加代理规则。下面我用一个具体例子走一遍完整流程：把fnOS上某个运行在http://localhost:8123的服务（比如家庭自动化系统Home Assistant），反向代理到https://ha.example.com。

4.1 先想清楚域名解析与网络可达

反向代理要能正常工作，有一个前提：访客访问的域名要能解析到这台fnOS所在的网络入口。

这里分两种情况：

• 仅内网使用：在路由器的DNS或者客户端的hosts文件里，把ha.example.com解析到fnOS的内网IP即可。
• 公网访问：需要域名商的DNS解析到你的公网IP，且路由器把对应的端口转发到fnOS上。

我自己是家庭宽带，没有固定公网IP，所以借助了DDNS动态域名解析把域名指向家里。如果你没有公网IPv4，只有IPv6，也可以只做IPv6的解析，然后确保NPM监听的是IPv6地址，或者让运营商光猫设置桥接后由路由器拨号获取到公网IPv4。

4.2 在NPM面板中创建Proxy Host

登录NPM管理面板（8081端口），进入Hosts（主机） -> Proxy Hosts（代理主机），点击“Add Proxy Host”（添加代理主机）：

• Domain Names：填写你要用的域名，例如ha.example.com。可以填多个，用空格分隔。
• Forward Hostname / IP：填写要转发到的目标地址，填192.168.1.10或者host.docker.internal（如果目标是宿主机上的服务）。
• Forward Port：填写目标端口，例如8123。
• Cache Assets：一般不建议勾选，静态资源Cache在动态页面上容易出奇怪问题。
• Block Common Exploits：建议勾选，能过滤一些常见的恶意扫描路径。
• Websockets Support：如果你的服务使用了WebSocket（比如Home Assistant、实时日志面板），必须勾选。

保存后，NPM会自动生成对应的Nginx配置文件，你的域名就指向目标服务了。如果这时候你的域名DNS已经解析到这台机器，直接访问http://ha.example.com应该就能看到后端服务的页面。

4.3 HTTPS证书申请与自动续期

HTTP访问没问题之后，接下来做HTTPS。方法是在NPM里给这个代理主机添加SSL证书，推荐使用Let's Encrypt：

1. 进入刚才创建的Proxy Host编辑页。
2. 切换到SSL（SSL）标签页。
3. 选择“Request a new SSL Certificate”（申请新证书）。
4. 勾选“Force SSL”（强制跳转HTTPS）。
5. 勾选“HTTP-01 Challenge”（HTTP验证）。这个方式要求NPM的80端口能从外网访问到，因为它要通过访问你的域名下的/.well-known/acme-challenge/路径来确认域名的控制权。
6. 填写邮箱，用于证书到期提醒。
7. 保存，几秒钟到一分钟内证书会签发完成。

证书申请成功后，NPM会自动配置续期任务，不需要你手动干预。DNS验证方式（DNS-01）也可以在NPM里配置，适用于没有80端口的情况，但需要配合Cloudflare等DNS服务商的API使用，家用场景里HTTP-01基本够用。

4.4 验证结果与证书状态

完成之后，你再去访问https://ha.example.com，浏览器地址栏解锁小锁标志，HTTP访问会301跳转到HTTPS。打开NPM面板里的“Access Lists”和“Audit Log”，你能看到访问记录，方便确认是否有异常IP在嗅探。

5. 日常使用中踩过的坑与排查思路

NPM虽然好用，但我在fnOS上实际使用中仍然踩了不少坑。下面这些是出现频率最高的问题，以及我总结的排查链路。直接给结论容易，但我觉得更有价值的是带你走一遍排查思路，因为换一个环境、换一个版本，表象可能又变了，但排查套路是通用的。

5.1 宿主机80/443端口被占用

症状：NPM容器启动失败，日志提示address already in use。

排查步骤：

# 查看监听80端口的进程 sudo ss -tlnp | grep :80 sudo ss -tlnp | grep :443

如果能看到其他进程占用了80，解决方式有两条路径：

• 停掉占用端口的服务（不推荐，可能影响系统功能）。
• 修改NPM的宿主机端口映射，比如8080:80、8443:443，然后把外部访问入口改成对应的非标准端口。

这里多说一句：如果只是想在局域网里使用，端口是不是80并不重要，管理面板用的8081、代理入口用8080/8443完全可行。但如果你要用Let's Encrypt的HTTP-01验证，证书签发的校验请求是打到你域名的80端口上的，如果80端口被占用，就改用DNS-01验证，或者在防火墙上做端口转发把外部80转到宿主机的8080。

5.2 证书申请失败，反复提示“Challenge failed”

这个坑我印象太深了。第一次在fnOS上配NPM时，证书申请怎么都失败，检查了IP、域名、端口都没问题，最后才发现是我在光猫上做的端口转发只转了443，没有转80。Let's Encrypt的HTTP-01验证依赖80端口能通，一转发立刻成功。

排查链路建议如下：

1. 确认域名解析正确：ping yourdomain.com看解析到的IP是不是你的公网IP。
2. 确认80端口可通：用手机流量（不要用局域网Wi-Fi绕过了NAT）访问http://yourdomain.com/.well-known/acme-challenge/test，能返回内容说明端口通了。
3. 确认端口转发规则：路由器/光猫上是否同时转发了TCP 80和TCP 443到fnOS。
4. 确认防火墙放行：fnOS系统防火墙或路由器ACL是否有额外限制。

5.3 反代之后登录页面跳转不对

症状：能打开登录页，但输入账号密码后跳转到http://192.168.1.10:8123/而不是https://ha.example.com/，或者反复回到登录页。

原因通常是后端服务配置的“外部访问URL”还是IP+端口形式，没有改成域名。以Home Assistant为例，需要去配置里把external_url设置为https://ha.example.com。另外，有些服务还需要设置“受信任的代理IP”，因为反向代理之后，服务看到的客户端IP变成了NPM容器的IP，不认这个IP可能导致安全策略异常。解决办法是把NPM容器的IP网段加入服务的信任代理列表。

排查的时候，一个技巧是在浏览器开发者工具里看网络请求，如果请求跳转的目标是IP，那基本就是服务自身的配置问题，跟NPM无关。

5.4 反代后页面样式错乱或者提示WebSocket连接失败

症状：页面能打开，但没有CSS样式，或者实时数据不动，WebSocket建立失败。

排查思路：

• 样式错乱大概率是NPM里没勾“Websockets Support”，或者是后端服务的websocket路径没有被正确代理。NPM在转发的时候，如果勾选了WebSockets Support，会自动加上Upgrade和Connection头。
• 检查浏览器Console报错，如果是401或403，可能又是服务自身的CSRF或安全策略问题，需要在服务配置里把反向代理的域名加进白名单。

NPM比较贴心的一点是，它生成的Nginx配置可以在线查看。进入Proxy Hosts -> 选中某个主机 -> Edit -> Advanced（高级）标签页，你能直接看到最终的Nginx配置片段，也可以在这里追加自定义location规则。排查问题时我经常先看这里，确认NPM生成的转发规则符合预期。

5.5 容器更新后配置丢失

这个问题多发生在“用别人模板一键部署”的场景。NPM版本升级有时候会改变数据库结构，或者有人在容器外直接改了数据文件导致初始化异常。

我的习惯是：每次更新前先备份整个npm目录。

tar czf npm-backup-$(date +%Y%m%d).tar.gz /vol1/0000/docker/npm

然后拉新镜像、重建容器：

docker compose pull docker compose up -d

如果升级后面板打不开，多半是数据库版本不兼容，这时候备份就派上用场了。恢复时把备份解压回去，再启动容器即可。

6. 进阶：从单服务到全家桶的统一入口

NPM的价值在服务数量多了之后才会完全体现出来。我现在fnOS上的服务都是通过NPM统一入口管理的，随便举几个例子：

• ha.example.com：Home Assistant
• media.example.com：媒体中心
• cloud.example.com：云笔记服务
• mini.example.com：内存监控面板

每个服务一个子域名，统一走443端口，证书全部由NPM自动管理。外网访问时路由器只需要转发443一个端口进来，其他端口全部关掉，暴露面小了很多。

6.1 规划子域名还是路径前缀

有两种组织方式：子域名方式（A服务.example.com、B服务.example.com）和路径前缀方式（example.com/a、example.com/b）。

我的建议是优先用子域名，原因有两条：

• 很多后端服务自身会生成基于当前域名的回调地址，直接用子域名代理过去，服务端收到的Host头就是原始域名，不容易出现跳转问题。
• WebSocket、Cookie、CDN配置在子域名下更干净，路径前缀方式容易出现Cookie冲突。

如果你确实只有少数几个服务且不想申请多个证书，NPM也支持一个证书覆盖多个域名（填多个域名申请一张多域名证书），或者用通配符证书。配置方法就是在申请的证书里把域名都填上，NPM会统一管理。

6.2 配合Lucky等其他工具的使用经验

在NAS社区里，很多人还会把NPM和Lucky配合使用。Lucky更擅长动态域名解析、内网穿透、端口转发这些事情，NPM则专注在Web反向代理和证书管理上。它们不是竞争关系，而是互补关系。

我自己的使用模式是：用Lucky负责从外部打进内网（Derp/映射/中继这类事情），进入内网后再由NPM统一做Web层的路由和SSL终结。这样外部入口只管一条通道，内部的服务编排全部走NPM，管理成本低很多。

6.3 把NPM的迁移备份当成一项定期任务

既然NPM成了家里所有服务的入口，它的数据重要性就等同于所有服务的配置总和。我给自己定了一个习惯：

• 每周自动备份一次npm目录到本地其他磁盘。
• 每次变更代理规则或者证书之后，手动触发一次备份。
• 大版本升级前，手动备份，升级后确认运行正常再清理旧备份。

换NAS或者重装系统的时候，只要把备份目录原样放回对应路径，启动容器，所有代理规则和证书立即恢复。这个体验比重新配置几十条规则舒服太多。

最后再分享一个实际的小技巧：如果你在NPM里配置了很复杂的转发规则，调试的时候可以在目标服务那边看访问日志，确认请求确实是从NPM转发过来的。如果目标服务能看到NPM容器IP的访问，但页面还是异常，问题大概率出在服务自身的回调地址配置上。这类问题是反向代理场景里占比最高的疑难杂症，先检查后端的“外部URL”设置，往往一改就好。