必须升级为Nginx反向代理+多实例负载均衡架构，否则API重启或Worker卡死将直接导致前端白屏、日志中断、上传失败；需确保所有实例共享同一PostgreSQL集群（同步复制）和Redis（Sentinel/Cluster模式），DATABASE_URL与REDIS_URL环境变量完全一致，各实例健康检查返回200后，再通过least_conn算法配置upstream实现动态分发，并启用WebSocket头转发与大文件上传支持。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要在Dify生产环境中实现高并发访问支撑与故障自动规避，必须将单实例裸跑模式升级为Nginx反向代理+多实例负载均衡架构，否则任何一次API服务重启或Worker卡死都会直接导致前端白屏、日志流中断、文件上传失败。
确认Dify多实例已就绪且状态一致
先确保所有Dify实例共享同一套后端依赖：PostgreSQL集群必须启用同步复制，Redis需配置为Sentinel或Cluster模式，【所有实例的DATABASE_URL和REDIS_URL环境变量必须完全相同】。若使用docker-compose部署，各实例不能各自启动独立数据库容器，否则RAG索引不同步、会话丢失、任务队列错乱将无法避免。
执行健康检查命令验证每个实例可响应：
curl -I http://192.168.1.10:5001/health → 返回HTTP/1.1 200 OK；
curl -I http://192.168.1.11:5001/health → 同样返回200；
任一实例返回503或超时，说明该节点未完成初始化或数据库连接失败，不可加入上游组。
配置Nginx upstream实现动态负载分发
在/etc/nginx/conf.d/dify.conf中定义上游服务组，采用least_conn算法适配Dify长请求特性：
upstream dify_backend {
least_conn;
server 192.168.1.10:5001 max_fails=3 fail_timeout=30s;
server 192.168.1.11:5001 max_fails=3 fail_timeout=30s;
keepalive 32;
}
max_fails=3不是随便写的——Dify在冷启动时可能前2次/health探测失败（因向量库加载延迟），设为3可避免误剔除；fail_timeout=30s则覆盖文档解析类任务的典型耗时。
注意：不要在server块里写proxy_pass http://192.168.1.10:5001; 这种硬编码会让Nginx失去故障转移能力。
编写反向代理规则并启用WebSocket支持
步骤一：匹配API路径与静态资源路径，分离处理逻辑
location ~ ^/(api|v1|console/api|files) {
proxy_pass http://dify_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
步骤二：显式开启WebSocket头转发，否则Agent实时输出、调试日志流会卡在CONNECTING状态
location /ws/ {
proxy_pass http://dify_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
步骤三：强制提升大文件上传限制，Dify知识库上传PDF常超10MB
client_max_body_size 100M;
启用主动健康检查并验证剔除逻辑
方法一：使用Nginx Plus（商业版）内置health_check指令，但多数团队用开源版；
方法二：用nginx-module-vts + 自定义脚本轮询/health端点，每5秒检测一次；
方法三（推荐）：在upstream块外添加stub_status模块暴露指标，配合Prometheus抓取failed_requests数值变化；
这一步操作起来很简单，直接在server块内加location /nginx_status { stub_status on; }即可，但必须配合allow/deny限制IP访问，【否则任何人都能获取后端节点实时状态】。
验证剔除效果：手动停掉192.168.1.10上的dify-api容器，等待30秒后执行curl -s http://localhost/nginx_status | grep failed → 应看到该IP对应的failed计数持续增长，且后续请求全部落到192.168.1.11。
