#️⃣NPM 本质是什么
🟢它不是独立的 Web 界面：NPM 实际上是 Nginx + 可视化面板 的合体
🟢自带 Nginx：装了 NPM 就不需要再在宿主机
apt install nginx 了，否则会因为争抢 80/443 端口导致服务无法启动#️⃣为什么反代填
127.0.0.1 会失败🟢隔离陷阱：NPM 跑在容器里，它的
127.0.0.1 指的是容器自己，找不到宿主机上的其他服务🟢黄金 IP
172.17.0.1：这是 Docker 的默认网桥网关。在 NPM 界面填这个 IP，就能通过宿主机的 “中转” 访问到其他所有映射了端口的容器#️⃣最实用、防踩坑通用反代公式
如果习惯于分开部署容器（每一个容器都有独立网段，这也是较常见的做法），请遵循这个公式：
🟢部署应用时：拿 Portainer 举例，使用最常用的端口映射写法
-p 9000:9000 / -p 0.0.0.0:9000:9000，⚠️ 避雷点：不要写成 -p 127.0.0.1:9000:9000，否则 NPM 会连接拒绝（正如前文所说：目标容器和 NPM 都有独立网段，不同网段的容器无法互相通信）🟢NPM 配置时：拿 Portainer 举例，转发主机名 / IP：填
172.17.0.1、转发端口：填映射出来的宿主机端口 9000⚠️ 为什么不推荐使用 127.0.0.1、内网 IP 或公网 IP？
在配置 NPM 反代时，会发现有多种 转发主机名 / IP 填法，但它们都有各自的 “坑”
❌ 127.0.0.1：最易碎的写法
🟢局限性：这种写法仅适用于 NPM 容器与目标容器被强行塞进同一个 network（网段）的情况
🟢弊端：如果你像我一样习惯分开部署容器（每个应用有独立的 Compose 文件），NPM 访问 127.0.0.1 只能看到它自己，根本跨不出容器大门
❌ 内网 IP (192.168.1.x)：最不通用的写法
🟢局限性：它强依赖于你当前的物理网络环境
🟢弊端：在家里是 192.168.1.x，换到 VPS 可能是 10.0.0.x。如果以后需要迁移服务器，或者想把这套配置分享给别人，所有的反代 IP 都要手动改一遍，极其痛苦
❌ 公网 IP：最离谱的写法
🟢局限性：让流量在公网上 “裸奔” 一圈再绕回来
🟢弊端：失去意义，反代的初衷是内网转发，写公网 IP 等于绕远路，增加延迟；变动风险，家庭宽带的公网 IP 经常变动，VPS 换了机器 IP 也会变，一旦变动，你所有的反代连接全部失效
注：
本篇讨论的核心： 如何反代 “同一台宿主机” 上的 Docker 容器或本地服务
如果你的目标是反代外网服务（如其他 VPS 上的网站或 API），请直接填写目标的域名或公网 IP 即可。在这种情况下，研究 127.0.0.1、内网 IP 或 Docker 网关的通用性已失去意义
🎲 Nginx Proxy Manager 相关
NPM 教程 | NPM 部署 | NPM 避雷 | Emby 反代
#Docker #Nginx #NPM #NginxProxyManager #反代 #反向代理 #Tips