该文章已加密，点击 阅读全文 并输入密码后方可查看。

一、管理台有没有“完全不改代码”的同域名多后端降级功能？

以现在用的 Nginx Proxy Manager 2.11.3 为例，Web 管理界面只提供：

• 每个 Proxy Host 配置 一个 “Forward Hostname / IP + Port”
• 一个 “Custom Nginx Configuration” 文本框（本质是 Nginx 片段）
• Streams/Redirection/404 等基础能力

没有界面化的：

• 多个 upstream 服务器组配置
• 主/备后端、健康检查、权重等负载均衡选项
• 同一 Proxy Host 下点击就能加“第二个后端”的 UI

所以，要在 同一个域名 上做“主服务 + 降级服务容灾”，只能用两类办法：

1. 像我们现在这样
   • 用容器里 /data/nginx/custom/http_top.conf 定义 upstream（一次性手工）
   • 在 Proxy Host 的 Advanced 里用 proxy_pass http://my_backend_servers; 引用
2. 或者把 Failover 做在 NPM 之外
   • 上游用云厂商负载均衡 / DNS 失败切换
   • NPM 只接一个已经做好的虚拟 IP 或域名

换句话说：目前没有“纯点点点、不写配置片段”的图形化降级方案，你现在这套就是标准的高级用法。

二、实现办法

主题：基于 Nginx Proxy Manager 的 Docker 容器做同域名多服务降级容灾
目标：同一个域名指向两个后端服务，主服务不可用时自动切换到降级服务（Failover），无需人工干预。

1. 场景与目标

• 域名：example.com
• 主服务（正常业务）：主服务 A，例如 124.xxx.xxx.120:13210
• 降级服务（简化版/静态服务）：降级服务 B，例如 43.xxx.xxx.126:8001
• 入口：Nginx Proxy Manager（Docker 容器）
• 要求：
  • 日常所有流量走主服务 A
  • A 宕机、超时或连续失败时，自动切到 B
  • 对客户端保持域名不变

从零到上线：用 frp + Nginx Proxy Manager 将家中 Windows 笔记本的 Docker 服务安全暴露到公网（v0.65.0，TOML 版）

面向场景：你在家里的 Windows 笔记本（Surface Laptop 2）上运行若干 Docker 服务（例如端口 3210、5432、8181），家中宽带在 大内网/NAT 后，没有公网 IP；你已有一台有公网 IP 的 云服务器，并已部署 Nginx Proxy Manager（NPM）。目标是通过 frp 建立安全隧道，让手机在 5G 外网也能访问这些服务。

NAT：网络地址转换，将大量私网地址通过少量公网地址上网，导致内网设备无法被公网主动访问。

一、架构与原理

• 家里笔记本安装并以“服务”方式运行 frpc（客户端），主动连接云服务器的 frps（服务端），形成一条加密的 隧道。
• 外部请求访问云服务器（IP 或域名），由 Nginx Proxy Manager 反代到 frps 暴露的端口，再回源到家中笔记本对应的本地端口。
• 该方案绕过运营商 NAT 限制，稳定且安全。

text
手机/外网 → 域名(Nginx Proxy Manager, 云) → 127.0.0.1:远程端口(frps)
                                          ↓  frp 隧道
                                     家中 Windows: 本地端口 (Docker 服务)

隧道：指通过中间节点转发建立的端到端连接通道，常用于穿透 内网 或 防火墙。

二、版本与目录约定（重要）

• frp 版本：v0.65.0（从该版本开始官方主推配置文件为 TOML，不再使用 INI）。
• 云服务器（Linux）frp 安装目录：/root/frp/frp_0.65.0_linux_amd64。
• 本地 Windows 目录示例：D:\frp_0.65.0_windows_amd64。
• Windows 端以“系统服务”方式运行 frpc，避免关闭窗口导致进程退出。

TOML：一种人类友好的配置文件格式，键值以 key = "value" 表示，层级清晰、类型明确。

Dify模型代理配置：通过SSRF代理链链接

很久没用Dify，新版本代理配置比0.x.x版本变得复杂了些。论坛里搜索了下，没有一次通关的讲解，自己动手搭好测试后，丢篇手册给有需要的佬友们操作。

解决的问题：传统代理配置方式后，知识库出现不能连接的问题，或者沙盒、函数执行某些流程出现内部链接报错的问题，这些其实都是没有按照dify自身的网络链路上去处理，相对粗暴的为了海外模型的plugin进行了代理导致的。

从1.x.x版本后，某个版本dify网络安全的优化后，选择将 Dify 内置的 ssrf_proxy 服务作为了一个网络的处理中心，所以我们就基于它，做链接到一个上游代理（如 Clash），再让指定域名下的所有外部流量（特别是 plugin_daemon 服务）通过此代理链，解决OpenAI或者Gemini的api网络访问问题，同时保持配置的灵活性和安全性，避免内部网络链路出现问题。

一、配置目标与架构

1. 核心目标

• 统一出口：为 ssrf_proxy 服务配置一个上游 HTTP 代理，使国外的模型的api域名，经由它的流量都通过这个指定的上游出口。（当然上游这个出口需要你自行代理，且可访问Google，这是前提条件）
• 域名通配匹配覆盖：让 plugin_daemon 服务的外网网络请求，强制通过 ssrf_proxy，从而实现对插件外部访问的全面代理。
• 简化配置：在 .env 文件中提供清晰的配置选项，方便用户在不同操作系统（macOS、Windows、Linux）上快速设置。

2. 流量架构

代理链条，其流量走向如下：

plugin_daemon → ssrf_proxy (端口 3128) → 上游HTTP代理 (例如: host.docker.internal:7890) → 互联网