1. 部署背景与目标
1.1 现状分析
在 NAS 或 Linux 服务器环境中，宿主机的 80 与 443 端口通常被系统自带的管理门户占用。这导致用户在部署其他 Docker 服务时，必须附加非标准端口号（如 :13133）进行访问，且无法直接获得有效的 SSL 加密保护。
1.2 部署目标
- 统一入口：通过域名直接访问服务，消除 IP:端口号 的访问形式。
- 加密通信：利用通配符证书实现所有二级域名的 HTTPS 安全访问。
- 本地解析：在局域网内完成流量转发，提升访问速度并保护隐私。
2. 环境要求与工具
- 系统环境：支持 Docker 与 Docker Compose 的 Linux 发行版或 NAS 系统。
- 解析资源：拥有一个可控域名（建议托管于 Cloudflare 等支持 API 的平台）。
- 核心工具：Nginx Proxy Manager (NPM)、Certbot（基于 DNS-01 校验模式）。
3. 实施步骤
3.1 宿主机端口冲突处理
Nginx Proxy Manager 需要监听标准 80 与 443 端口。实施前需释放宿主机的相应端口。
- 修改原服务端口：将系统自带门户的监听端口移至非标准段（如 HTTP 改为 5080，HTTPS 改为 5443）。
- 确认访问通道：确保可通过新端口（如 http://[IP]:5080）正常登录管理后台。
3.2 获取通配符证书（使用 Certbot）
为实现内网环境下的通配符域名支持，采用 Certbot 的 DNS-01 验证方式。推荐使用 Docker Compose 进行管理，便于维护路径映射。
- 获取 API 令牌：在域名服务商（如 Cloudflare）处创建具有 DNS 编辑权限的 API 令牌。
- 创建配置文件：在本地创建 cloudflare.ini，写入 dns_cloudflare_api_token = 你的令牌。
- 配置 Docker Compose：创建 docker-compose.yml 文件管理证书申请流程：
services:
certbot:
image: certbot/dns-cloudflare
container_name: certbot
volumes:
- ./conf:/etc/letsencrypt
- ./work:/var/lib/letsencrypt
- ./cloudflare.ini:/cloudflare.ini
command: >-
certonly
--dns-cloudflare
--dns-cloudflare-credentials /cloudflare.ini
--email 你的邮箱
--agree-tos
--no-eff-email
-d "example.com"
-d "*.example.com"
- 运行申**令：在目录下执行以下命令启动申请：
docker compose run \--rm certbot
- 获取结果：申请成功后，证书文件将存储在当前目录的 conf/live/ 文件夹下。
3.3 部署反向代理容器
使用 Docker Bridge 模式部署 Nginx Proxy Manager。
docker-compose.yml 配置示例：
services:
npm:image: jc21/nginx-proxy-manager:2.12.1
container_name: nginx-proxy-manager
restart: unless-stopped
ports:
- 80:80
- 443:443
- 81:81
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
3.4 DNS 解析配置
在域名服务商处配置指向内网 IP 的解析记录。
- 配置泛解析：设置 A 记录，名称为 *，内容为宿主机局域网 IP。
- 设置根域名：设置 A 记录，名称为 @，内容为宿主机局域网 IP。
- 状态说明：将“代理状态”设为“仅限 DNS”。私有 IP 不支持公网 CDN 代理。
3.5 证书导入与规则映射
3.5.1 导入 SSL 证书
在 NPM 管理后台（81 端口）的 SSL Certificates 页面导入 PEM 格式证书：
- Certificate: 对应 fullchain.pem。
- Certificate Key: 对应 privkey.pem。
3.5.2 创建代理主机 (Proxy Host)
- Domain Names: 输入子域名（如 service.example.com）。
- Forward IP: 输入宿主机的局域网 IP。
- Forward Port: 输入目标容器端口。
- 配置参数: 开启 Websockets Support 并关联已导入的 SSL 证书，启用 Force SSL。
4. 技术细节说明
4.1 方案对比：Certbot vs fnOS 原生申请
选择使用 Docker 部署 Certbot 进行证书管理，而非使用 fnOS 系统自带的证书申请功能，主要基于以下考量：
- 连接可靠性：fnOS 原生证书申请功能在部分网络环境下（如特定内网 DNS 环境或由于系统组件限制）存在无法正常连接校验服务器的问题，导致申请流程中断或失败。
- 校验方式优势：内网环境通常不具备开放公网 80 端口的条件。Certbot 通过 DNS-01 验证方式确认所有权，无需任何入站端口映射，且能够原生支持申请通配符证书（*.domain.com）。
- 独立性与迁移性：将证书管理容器化，可以确保配置不依赖于特定 NAS 系统的闭源组件。这使得整套反向代理架构在系统升级或更换硬件时具备更高的迁移灵活性。
- 总之，如果你像我一样，使用FNOS自带的证书申请工具时总是超时，可以换成 Certbot 的方案。
4.2 容器网络模式的选择
推荐使用 Bridge 模式。在某些开启了 Open vSwitch 的环境或特定防火墙策略下，MacVLAN 的虚拟 MAC 地址可能被拦截。Bridge 模式具备更高的网络通用性。
4.3 证书更新策略
NPM 将证书存储于 ./data/custom_ssl/。若使用 Certbot 自动续签，可通过脚本定期将新生成的 PEM 文件覆盖至该目录下的对应子目录，并重启 NPM 容器完成证书热加载。
4.4 转发协议说明
建议 NPM 与后端容器间使用 HTTP 协议。HTTPS 解密由前端 NPM 完成，以降低后端容器的计算负担。
5. 结论
本方案通过释放标准端口、建立统一网关与配置泛解析，实现了局域网服务的规范化访问。这不仅提升了内网服务的安全性，也简化了多服务的管理复杂度。
FNOS 论坛的markdown编辑器太烂了
