Stable-Diffusion-v1-5-archiveWebUI高可用：双实例+负载均衡+健康检查部署

Ne0inhk

21 Mar 2026 — 10 min read

Stable-Diffusion-v1-5-archive WebUI 高可用：双实例+负载均衡+健康检查部署

你是不是也遇到过这种情况：正在用 Stable Diffusion 生成一张重要的设计图，突然页面卡住，刷新一下直接 502 错误，所有工作进度都丢了。或者团队里几个人同时用，服务器就慢得像蜗牛，一张图要等好几分钟。

对于需要稳定、高效生成图片的团队或个人来说，单点部署的 WebUI 服务就像走钢丝——一旦服务挂了，所有工作都得停摆。今天，我就来分享一个实战方案：为 Stable-Diffusion-v1-5-archive WebUI 搭建一套高可用架构。

这套方案的核心很简单：部署两个 WebUI 实例，前面加一个负载均衡器，再配上自动健康检查。这样一来，任何一个实例出问题，流量会自动切到另一个健康的实例上，服务几乎不会中断。同时，负载均衡还能把用户请求分摊开，提升整体的处理能力。

下面，我就手把手带你从零搭建这套系统。

1. 方案设计与核心思路

在开始敲命令之前，我们先搞清楚要做什么，以及为什么这么做。

1.1 我们要解决什么问题？

单实例部署的 Stable Diffusion WebUI 有几个明显的痛点：

单点故障：服务进程崩溃、服务器重启、代码更新，都会导致服务不可用。
资源瓶颈：GPU 算力有限，多个用户或复杂任务同时进行时，排队严重，体验差。
维护困难：更新或调试服务时，必须停止服务，影响所有用户。

1.2 高可用方案的核心组件

我们的解决方案包含三个核心部分：

双实例：在两台服务器（或一台服务器的不同端口）上，分别部署完全相同的 Stable-Diffusion-v1-5-archive WebUI 服务。这是我们的“后备军”。
负载均衡器 (Nginx)：作为统一的入口，接收所有用户请求。它的职责是“调度”，根据策略（比如轮询）将请求分发给后端的两个 WebUI 实例。
健康检查：负载均衡器会定期（比如每5秒）去“探访”后端的每个 WebUI 实例，检查它是否还“活着”（能正常响应）。如果发现某个实例挂了，就立刻不再把新请求发给它，直到它恢复健康。

整个流程就像一家餐厅开了两个相同的厨房（实例），一个前台经理（Nginx）负责接待顾客（请求）并把点菜单分给两个厨房。经理会不断检查厨房是否着火（健康检查），如果A厨房着火了，就把所有新订单都交给B厨房，保证餐厅继续营业。

2. 环境准备与双实例部署

假设我们有两台服务器：server-A (192.168.1.10) 和 server-B (192.168.1.11)。我们将在这两台服务器上部署 WebUI。

2.1 基础环境与镜像部署

在两台服务器上，执行相同的部署操作。这里假设你已经通过类似 ZEEKLOG 星图镜像广场的平台，获取了 stable-diffusion-v1-5-archive 的部署镜像。

# 1. 登录服务器（以 server-A 为例） ssh [email protected] # 2. 假设镜像已提供一键部署脚本，运行它。如果没有，核心是启动WebUI服务。 # 通常启动命令类似这样（具体参数根据你的镜像调整）： cd /path/to/sd-webui python launch.py --listen --port 7860 --medvram # 3. 使用Supervisor守护进程（确保服务崩溃后能自动重启） # 安装supervisor (如果未安装) apt-get update && apt-get install -y supervisor # 创建Supervisor配置文件 cat > /etc/supervisor/conf.d/sd15-webui.conf << EOF [program:sd15-webui] command=python /path/to/sd-webui/launch.py --listen --port 7860 --medvram directory=/path/to/sd-webui autostart=true autorestart=true startretries=3 user=root redirect_stderr=true stdout_logfile=/var/log/sd15-webui.log stdout_logfile_maxbytes=10MB EOF # 更新Supervisor配置并启动服务 supervisorctl reread supervisorctl update supervisorctl start sd15-webui # 4. 验证服务是否启动 curl http://localhost:7860 # 或者查看进程 supervisorctl status sd15-webui

在 server-B (192.168.1.11) 上重复完全相同的步骤。确保两台服务器的 WebUI 都能通过各自的 IP 和端口 7860 独立访问。

关键点：确保两台服务器上的模型文件、依赖库版本完全一致，以避免生成效果出现差异。

3. 配置 Nginx 负载均衡与健康检查

现在，我们需要第三台服务器作为负载均衡器 (lb-server, 192.168.1.12)，或者你也可以选择在 server-A 或 server-B 其中一台上安装 Nginx。

3.1 安装与配置 Nginx

在负载均衡器服务器上操作：

# 1. 安装 Nginx apt-get update && apt-get install -y nginx # 2. 创建负载均衡配置文件 # 我们将其放在 /etc/nginx/conf.d/ 下 cat > /etc/nginx/conf.d/sd15-loadbalancer.conf << EOF upstream sd15_backend { # 定义后端服务器组，并配置健康检查 server 192.168.1.10:7860 max_fails=3 fail_timeout=30s; server 192.168.1.11:7860 max_fails=3 fail_timeout=30s; # 负载均衡策略：轮询 (round-robin) # 其他策略：least_conn (最少连接), ip_hash (会话保持) } server { listen 80; # 如果你有域名，可以在这里配置 # server_name sd.yourdomain.com; location / { # 将请求代理到后端服务器组 proxy_pass http://sd15_backend; # 以下是一些重要的代理设置，确保WebUI正常工作 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 支持 (如果WebUI有相关功能) proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # 超时设置 proxy_connect_timeout 300s; proxy_send_timeout 300s; proxy_read_timeout 300s; } # 可选：添加一个状态检查页面（需要nginx status模块） location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; # 只允许本机访问，安全考虑 deny all; } } EOF # 3. 测试Nginx配置语法是否正确 nginx -t # 4. 重新加载Nginx配置，使其生效 systemctl reload nginx

3.2 核心配置解析

upstream sd15_backend: 定义了一个名为 sd15_backend 的后端服务器池。
max_fails=3 fail_timeout=30s: 这是被动健康检查。如果 Nginx 连续 3 次向后端服务器发送请求失败，就会认为该服务器“不健康”，并在接下来的 30 秒内不再向其分发请求。30秒后会再次尝试。
proxy_pass http://sd15_backend: 将所有到达 location / 的请求转发到后端服务器池。
超时设置：Stable Diffusion 生成图片可能耗时较长，因此将 proxy_read_timeout 等参数调大，避免任务被意外中断。

3.3 验证负载均衡

配置完成后，你的用户将不再直接访问 192.168.1.10:7860 或 192.168.1.11:7860，而是访问负载均衡器的 IP 或域名（例如 http://192.168.1.12）。

打开浏览器，访问 http://负载均衡器IP。
你应该能看到熟悉的 Stable Diffusion WebUI 界面。
为了验证负载均衡是否生效，你可以快速、连续地提交几次生成请求，然后分别去两个后端服务器的应用日志 (/var/log/sd15-webui.log) 查看。你会看到请求被交替分配到了 server-A 和 server-B。

4. 模拟故障与高可用验证

架构好不好，得经过故障测试。我们来模拟一下后端实例崩溃的情况。

观察效果：此时，你继续通过负载均衡器 (http://192.168.1.12) 使用 WebUI 生成图片。
- 第一次请求：Nginx 可能还会把请求发给已挂掉的 server-A，导致页面错误或长时间等待。
- 后续请求：Nginx 检测到 server-A 连续失败（达到 max_fails=3），会将其标记为“不可用”。之后的所有新请求都会自动发给健康的 server-B。服务整体没有中断！

恢复服务：在 server-A 上重启服务。

supervisorctl start sd15-webui

等待片刻（fail_timeout=30s 之后），Nginx 会再次尝试将请求发给 server-A，如果成功，则自动将其加回健康池，恢复负载均衡。

制造故障：在 server-A 上，手动停止 WebUI 服务。

# 在 server-A 上执行 supervisorctl stop sd15-webui

5. 进阶优化与生产建议

上面的方案已经能提供基础的高可用。要用于生产环境，还可以考虑以下几点：

5.1 使用域名与 HTTPS

为负载均衡器配置域名并申请 SSL 证书，启用 HTTPS，保证通信安全。

# 在Nginx配置中，将监听80端口的server块改为监听443，并配置SSL证书路径 server { listen 443 ssl http2; server_name sd.yourdomain.com; ssl_certificate /path/to/your/cert.pem; ssl_certificate_key /path/to/your/key.pem; ... # 其他配置不变 }

5.2 更精细的健康检查

Nginx 商业版或开源版搭配 nginx_upstream_check_module 模块，可以配置主动健康检查，定期请求一个特定的健康检查接口（比如 /health），更早地发现后端故障。

5.3 会话保持 (Session Persistence)

如果 WebUI 有用户登录状态等会话信息，默认的轮询策略会导致用户下次请求被发到不同后端，会话丢失。可以使用 ip_hash 策略，让同一客户端的请求总是发往同一后端。

upstream sd15_backend { ip_hash; # 添加此行 server 192.168.1.10:7860; server 192.168.1.11:7860; }

5.4 监控与告警

为 Nginx 和后端服务器设置监控（如 Prometheus + Grafana），监控关键指标：

Nginx：请求率、响应时间、后端健康状态。
服务器：CPU、GPU、内存使用率。
WebUI：生成队列长度、平均生成时间。配置告警规则，当服务异常时及时通知运维人员。

6. 总结

通过 双实例部署 + Nginx 负载均衡 + 健康检查 这套组合拳，我们成功为 Stable-Diffusion-v1-5-archive WebUI 构建了一个简单而有效的高可用架构。

这个方案带来的核心价值是：

可靠性提升：单点故障不再导致服务完全中断，保障了业务连续性。
性能扩展：通过水平扩展实例，提高了系统整体的并发处理能力。
维护便利：可以在不影响用户的情况下，对单个后端实例进行滚动更新或维护。

部署过程其实并不复杂，核心在于理解各个组件的作用和协作方式。你可以根据实际资源情况，将这个模式扩展到更多实例，或者结合 Docker 容器化技术，让部署和管理变得更加灵活高效。希望这篇实战指南能帮助你搭建出更稳定的 AI 图像生成服务。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 ZEEKLOG星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

Stable-Diffusion-v1-5-archiveWebUI高可用：双实例+负载均衡+健康检查部署

Ne0inhk