IC咖啡胡运旺先交代一下背景：我在本地跑 ReActor 换脸流程的时候，遇到过几次挺让人恼火的报错，样子非常直接——
text复制HTTP Error 502: Bad Gateway
unexpected status 502 bad gateway: unknown error, url: http://127.0.0.1:1572
看到这条提示，第一反应是“怎么本地服务还给我整出个 502”。如果你也卡在这一步，别急着怀疑人生，这基本不是逻辑代码写错了，而是 ReActor 背后的辅助服务、模型进程或者依赖环境出了问题。这篇文章就把我从报错出现到排查、修复、再到稳定使用的完整过程拆开讲，重点说明这个 502 在换脸插件场景里到底意味着什么，以及每一步怎么处理。
1. 先搞清楚 502 是从哪一层冒出来的：ReActor 的调用链
1.1 一个看似本地却走 HTTP 的换脸插件
ReActor 是目前社区里比较常用的换脸（face swap）插件，很多人在 ComfyUI、SD WebUI 这类图形界面里直接调用它。很多人误以为 ReActor 就是一个纯本地函数库，靠 Python 代码直接跑——它确实最终是在本机做推理，但实际架构里通常有一层独立服务在待命。当你在界面上发起一次换脸请求时，主程序会先向本地某个端口发起 HTTP 请求，等服务把模型加载、推理结果算完，再返回给主程序。
http://127.0.0.1:1572 这个地址就是那个本地服务入口。502 是网关类错误，本质是“我（客户端）请求了某个代理/网关，但网关背后的真正服务没有给出合法响应”。在 ReActor 这里，相当于：
- 主 UI 进程（客户端）去请求本地 ReActor 服务；
- 本地服务可能没起来、正在加载模型、或者已经崩了；
- 于是返回了一个 502，而不是正常的图片数据。
1.2 502 在 ReActor 场景下的真实含义
我最初以为 502 是网络代理问题，毕竟这类报错在浏览器里太常见了。但在 ReActor 的调用上下文里，不完全是这么回事。它更多表示：服务进程存在，但没有成功处理这次请求。常见情况有几种：
- 服务进程启动过程中被中断，端口没有真正监听；
- 服务进程还活着，但模型加载没有完成，请求直接超时；
- 请求进入之后，推理过程中显存爆掉，进程被杀，连接被重置；
- 多个实例抢同一个端口，实际响应你的不是 ReActor，而是另一个不认识的进程。
这就是为什么单看报错解决不了问题——你得先判断 502 是在哪个阶段出现的。这里我建议排查时先按“端口能否连通 → 服务日志有没有报错 → 模型是否加载完整 → 配置有没有冲突”的顺序走，下面每一节都对应一个具体检查点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 最常见的元凶：内存、显存与模型加载的前后顺序
2.1 模型没有完整加载就请求，服务端直接拒了
ReActor 换脸依赖的模型文件一般体积不小，比如用于人脸检测、特征提取的多个模型加起来动辄几百 MB 到几个 GB。首次启动时需要把模型读入内存或显存，这个阶段如果立刻发送请求，服务端往往直接返回连接异常或 502。
我实际遇到的情况是：ReActor 服务在后台静默启动，但是模型加载需要二十多秒，而 UI 层已经认为服务“可用了”，于是马上发请求。这时候本地服务还卡在模型加载，根本来不及处理，最终表现为 502。
复现路径大概是：
- 启动 ComfyUI 或 WebUI；
- 加载 ReActor 插件，后台服务开始预热；
- 立刻在界面上传一张图，点击生成；
- 控制台抛出
HTTP Error 502: Bad Gateway。
这类问题最容易出现在“服务热启动 + 用户手速快”的组合下。解决方式很朴素：启动完成后等几秒再发第一次请求。如果你用脚本调用，可以在请求前轮询端口连通性，确认服务真正就绪。
提示：端口能连通不等于服务就绪。连通只能说明有 socket 在监听，不代表模型已经加载到显存里。要等日志出现类似“model loaded”的标记后再进入任务队列。
2.2 显存和内存双双顶满，进程假死或被杀
另一个高频原因是推理过程中显存或