ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

ComfyUI云端GPU部署实战:从硬件选型到高可用API服务

ComfyUI云端GPU部署实战:从硬件选型到高可用API服务 1. 项目概述为什么现在必须认真对待 ComfyUI 的云端 GPU 部署ComfyUI 不是又一个“点几下就能出图”的傻瓜式 AI 工具它是一套基于节点图Node Graph的、面向专业图像生成工作流的底层执行引擎。你看到的那些惊艳的 LoRA 微调效果、多模型协同控制、条件注入链路、像素级重绘逻辑背后全是节点之间用张量Tensor流动构建起来的精密管道。而这条管道要跑得稳、跑得快、跑得不崩GPU 就不是“可选项”而是整条流水线的发动机、冷却系统和供电单元三合一。我从 2023 年初开始在本地 RTX 4090 上调试第一个 Stable Diffusion XL 工作流到今天稳定运行在富文云端、Vultr GPU 实例和阿里云 ECS gn7i 上的 20 个生产级 ComfyUI 服务踩过的坑比走过的路还多——驱动版本错一位、CUDA Toolkit 和 PyTorch 版本不匹配、显存碎片化导致 OOM、节点缓存未清理引发 D3D 设备移除错误……这些都不是报错信息里写清楚的“请升级驱动”而是需要你亲手拆开日志、看懂 CUDA 初始化流程、理解 PyTorch 的 CUDA Context 管理机制才能定位的问题。所以这篇教程不叫“ComfyUI 安装指南”它叫“云端 GPU 文生图工作流搭建”。关键词顺序不能乱“ComfyUI”是载体“云端”是部署形态“GPU”是硬性约束“文生图”是核心任务“工作流”是交付成果。它解决的不是“能不能跑起来”而是“能不能每天稳定处理 500 张客户定制图、支持 3 个设计师并发编辑、在 8 小时内完成 10 套电商主图详情页短视频封面的批量生成”。这意味着你要面对的不是单次推理而是持续的显存调度、节点状态持久化、HTTP 请求队列管理、失败重试策略、日志追踪闭环。我见过太多人用秋叶一键整合包在本地跑通了一上云就卡在“无法加载 custom node”或“GPU 利用率始终为 0”根本原因不是配置不对而是没意识到本地环境是“玩具沙盒”云端环境是“工业产线”二者对稳定性、可观测性、可维护性的要求差着整整一个数量级。这篇文章适合三类人第一类是刚用熟秋叶整合包、想把个人工作流搬到线上接单的自由画师第二类是小型设计工作室的技术负责人需要为 5–10 人团队搭建共享式 AI 出图平台第三类是开发者正在为自有 SaaS 产品集成文生图能力需要可控、可审计、可计费的后端服务。如果你属于这三类中的任何一类接下来的内容就是你未来三个月反复打开的“操作手册”。它不讲原理推导只讲实操路径不堆砌参数列表只解释每个参数背后的代价与收益不承诺“一键成功”但保证你每一步操作都能在终端里看到明确反馈、每一步失败都能在日志里找到唯一根源。我们从最底层的硬件选型开始而不是从 git clone 开始。2. 硬件与云平台选型GPU 能力不是看显存大小而是看计算架构兼容性2.1 显卡型号选择别再被“RTX 4090”四个字绑架了很多人一上来就搜“租一台 RTX 4090 云服务器”结果发现月费 2000而实际推理一张图只用了 30% 显存。这不是浪费钱这是浪费算力认知。ComfyUI 的瓶颈从来不在“显存够不够”而在“CUDA Core 能不能喂饱”、“Tensor Core 支持 FP16/BF16 的效率如何”、“PCIe 带宽是否成为数据搬运瓶颈”。举个真实例子我在富文云端测试过 A1024GB 显存、L4048GB 显存和 V10032GB 显存三台实例跑同一个 SDXL 工作流含 ControlNet IP-Adapter Tiled VAE平均单图耗时分别是 8.2s、6.7s、11.4s。A10 比 V100 快近 30%原因很简单V100 是 Pascal 架构不支持 Tensor Core 的 BF16 加速而 A10 是 Ampere 架构原生支持且 PCIe 4.0 带宽翻倍。所以选卡第一条铁律优先看 Compute Capability计算能力再看显存最后看价格。当前主流云平台 GPU 型号的 Compute Capability 对照表如下截至 2024 年中云平台GPU 型号Compute Capability显存适用场景关键限制说明富文云端A108.624GB高性价比主力SDXL/FLUX 推理不支持 CUDA Graph大 batch 会略慢富文云端L408.948GB大模型微调高分辨率图生成驱动需 ≥525.85.12否则报d3d device removed阿里云 ECSgn7i (V100)7.032GB兼容老工作流成本低不支持 BF16SDXL 推理慢 40%阿里云 ECSgn8i (A100)8.040GB多模态大模型训练租用成本高小图生成不划算VultrA100-PCIE8.040GB需要极致显存带宽的场景PCIe 4.0 x16但单卡价格是 A10 的 2.3 倍提示Compute Capability是 NVIDIA 官方定义的 GPU 架构代号它直接决定该卡能运行哪些 CUDA 版本、支持哪些 PyTorch 运算。ComfyUI v0.35.0 及以上版本强制要求 Compute Capability ≥ 7.0即 Volta 及以后架构但实际生产推荐 ≥ 8.0Ampere 及以后。低于此值即使能启动也会在加载torch.compile或xformers时静默失败。2.2 云平台对比不是谁家便宜选谁而是谁家“故障恢复快”选谁云平台不是水电煤买完就完事。它是一个有 SLA服务等级协议、有运维响应、有镜像生态的协作系统。我过去一年在四家主流平台部署 ComfyUI真实故障统计如下富文云端平均每月 1 次计划内维护提前 2 小时通知非计划宕机 0 次GPU 实例冷启动时间 42s自定义镜像上传支持.tar.gz直传最大的优势是comfyui-manager插件可直接识别其预装的custom nodes库无需手动 symlink。阿里云 ECS每月平均 2.3 次网络抖动表现为Connection reset by peer需配合 SLB 做健康检查GPU 驱动需手动安装官方镜像默认无nvidia-smi但它的弹性伸缩组可以根据nvidia-smi --query-gpuutilization.gpu指标自动增减实例适合流量波动大的 SaaS 场景。Vultr实例创建最快18s但 GPU 驱动更新滞后曾出现pytorch 2.3.0cu121与nvidia-driver-535冲突导致cudaErrorInitializationError优点是支持on-demand按秒计费适合临时跑批任务。腾讯云 CVMGPU 实例需单独购买GPU 云服务器服务开通流程复杂但它的云监控可直接采集nvtop数据并绘图对排查显存泄漏极友好。注意所有平台都存在一个共性陷阱——它们提供的“AI 镜像”大多预装了stable-diffusion-webuiAUTOMATIC1111而非 ComfyUI。这些镜像默认关闭systemd-resolved导致 ComfyUI 启动时requests.get()超时卡死。这不是 ComfyUI 的 bug是云平台镜像配置缺陷。解决方案必须在初始化脚本中加入sudo systemctl enable systemd-resolved sudo systemctl start systemd-resolved。2.3 系统镜像选择Ubuntu 22.04 LTS 是当前唯一稳妥选择别碰 CentOS Stream、AlmaLinux 或 Debian 12。理由很现实ComfyUI 生态的绝大多数custom nodes比如ComfyUI-Manager、Impact Pack、LayerDiffuse的 CI/CD 流程全部基于 Ubuntu 22.04 构建它们的setup.sh脚本里写的apt install -y python3.10-venv在其他发行版上会报E: Unable to locate package。我试过在 Rocky Linux 9 上强行编译xformers最终因gcc 11.4与pybind11的 ABI 不兼容而放弃。Ubuntu 22.04 的核心优势在于三点Python 版本锁定系统自带 Python 3.10.12与 PyTorch 官方 wheel 包完全匹配避免pip install torch时下载cp311轮子却报ImportError: libcudnn.so.8: cannot open shared object fileCUDA Toolkit 兼容性NVIDIA 官方 CUDA 12.1 Toolkit 的.run安装包明确声明支持 Ubuntu 22.04而对 24.04 的支持尚在 beta 阶段长期维护保障Ubuntu 22.04 LTS 支持至 2032 年意味着你部署的这套环境未来 8 年内无需因系统升级而重构整个工作流。实操心得不要用云平台提供的“Ubuntu 22.04 with GPU Driver”镜像。它们往往预装了旧版驱动如 515.x而 ComfyUI v0.35.0 要求驱动 ≥ 525.60.13A10/L40或 ≥ 535.54.03A100。正确做法是选纯净版 Ubuntu 22.04然后手动安装最新驱动。命令如下以 A10 为例# 卸载旧驱动 sudo apt-get purge nvidia-* sudo reboot # 安装依赖 sudo apt-get update sudo apt-get install -y build-essential libgl1 libsm6 libxext6 libglib2.0-0 # 下载并安装驱动以 535.129.03 为例 wget https://us.download.nvidia.com/tesla/535.129.03/NVIDIA-Linux-x86_64-535.129.03.run sudo sh NVIDIA-Linux-x86_64-535.129.03.run --no-opengl-files --no-opengl-libs --silent # 验证 nvidia-smi # 应显示 Driver Version: 535.129.03, CUDA Version: 12.23. ComfyUI 核心环境搭建从源码编译到工作流热加载的完整链路3.1 源码部署 vs 秋叶整合包为什么生产环境必须自己编译秋叶 ComfyUI 整合包是 Windows 用户的福音但它在云端 Linux 环境下是“定时炸弹”。原因有三路径硬编码整合包的run_nvidia_gpu.bat里写死了C:\comfyui\python_embeded\python.exeLinux 下需手动改start_linux.sh且每次更新都会覆盖依赖隔离缺失它把torch、xformers、transformers全部塞进一个python_embeded环境导致你无法用pip list查看真实版本也无法用pip install --force-reinstall修复损坏包custom nodes 管理混乱所有插件都放在custom_nodes文件夹下但ComfyUI-Manager的update all功能会误删你手动添加的私有节点。所以生产环境必须走标准 Python 流程git clone → venv → pip install。步骤如下# 创建专用用户避免 root 权限风险 sudo adduser comfyui --gecos --disabled-password sudo usermod -aG sudo comfyui sudo su - comfyui # 安装基础依赖 sudo apt-get update sudo apt-get install -y git curl wget unzip htop nvtop # 克隆源码注意必须用 --recursive 获取所有 submodule git clone --recursive https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI # 创建虚拟环境关键指定 Python 3.10避免与系统 Python 冲突 python3.10 -m venv venv source venv/bin/activate # 升级 pip必须否则安装 torch 会失败 pip install --upgrade pip # 安装 PyTorch重点CUDA 版本必须与 nvidia-smi 显示的 CUDA Version 一致 # 查看 CUDA Versionnvidia-smi → 右上角 CUDA Version: 12.2 pip install torch2.3.0cu121 torchvision0.18.0cu121 torchaudio2.3.0cu121 --extra-index-url https://download.pytorch.org/whl/cu121 # 安装 xformers提升显存效率SDXL 必装 pip install xformers0.0.26.post1 --extra-index-url https://download.pytorch.org/whl/cu121 # 启动验证不加 --listen 参数先本地测试 python main.py --cpu 21 | grep Starting server # 应看到 Starting server on 127.0.0.1:8188注意--extra-index-url参数不能省略。PyTorch 官方 wheel 包托管在download.pytorch.org而国内镜像如清华源往往不同步 cu121 版本会导致pip install torch下载到 CPU 版本启动时报No module named torch.cuda。3.2 ComfyUI-Manager工作流可持续演进的基础设施ComfyUI 的核心价值在于“工作流可复用、可分享、可迭代”。而ComfyUI-Manager就是让这个价值落地的基础设施。它不是锦上添花的插件而是生产环境的必需品。它的三大不可替代功能是一键安装/更新 custom nodes比如你想接入ComfyUI-Impact-Pack做人脸检测传统方式是git clonegit pull 手动检查requirements.txt而 Manager 只需在 Web UI 点击“Install”按钮它会自动解析__init__.py中的NODE_CLASS_MAPPINGS下载依赖校验 SHA256工作流市场Workflow Market这里不是“下载别人的工作流”而是“订阅工作流更新”。例如Flux.1-dev的官方工作流每周更新节点逻辑Manager 可设置自动拉取最新版避免你手动 diff JSON 文件节点依赖图谱Dependency Graph当你导入一个复杂工作流如AnimateDiffControlNetIP-AdapterManager 会自动生成依赖关系图告诉你哪些节点需要torchvision0.17.0哪些需要opencv-python-headless哪些与当前 PyTorch 版本冲突。安装 Manager 的命令必须在 ComfyUI 根目录执行cd /home/comfyui/ComfyUI git clone https://github.com/ltdrdata/ComfyUI-Manager.git custom_nodes/ComfyUI-Manager # 重启 ComfyUI 后访问 http://your-ip:8188 → 右下角出现 Manager 按钮实操心得Manager 的Update All功能有隐藏风险。它会强制更新所有节点到main分支最新 commit而某些节点如ComfyUI-Custom-Nodes的main分支可能尚未适配 ComfyUI v0.35.0。我的做法是在custom_nodes/ComfyUI-Manager目录下将git pull替换为git checkout v2024.06.15指定稳定 Tag并在manager_config.json中设置auto_update: false改为手动触发更新。3.3 工作流Workflow的本质JSON 文件不是配置而是可执行程序很多人把.json工作流文件当成“配置文件”这是最大误区。ComfyUI 的工作流 JSON 是一个完整的、带状态的、可序列化的程序。它包含三部分节点定义nodes每个节点是一个 Python 类的实例化如class_type: KSampler对应comfy_extras.nodes.KSampler类连接关系links定义张量如何在节点间流动如[2, positive, 3, positive]表示节点 2 的positive输出连接到节点 3 的positive输入执行上下文extra_data存储运行时状态如prompt: {3: {inputs: {text: masterpiece, best quality}}}这部分在保存工作流时会被剥离但加载时会重新注入。因此工作流的“热加载”不是简单地cp workflow.json /input/而是要理解它的生命周期加载阶段ComfyUI 解析 JSON实例化所有节点对象但不执行任何计算队列阶段用户点击“Queue Prompt”ComfyUI 将工作流 ID 加入内存队列并为每个节点分配唯一 UUID执行阶段按拓扑序Topological Order逐个调用节点的execute()方法张量在内存中流转缓存阶段如果节点输出未改变如CLIPTextEncode的文本输入相同则复用上一次的output缓存跳过计算。提示工作流文件应放在/home/comfyui/ComfyUI/workflows/目录下需手动创建而非默认的/input/。因为/input/是 ComfyUI 的临时上传区文件可能被自动清理。我习惯按业务分类建子目录/workflows/ecommerce/电商图、/workflows/animation/图生视频、/workflows/portrait/人像精修。4. 云端服务化封装从本地 Web UI 到高可用 API 服务的工程实践4.1 为什么不能直接暴露 8188 端口Web UI 的设计哲学与生产反模式ComfyUI 的 Web UI 是一个开发调试工具不是生产级服务。它的设计哲学是“单用户、低并发、强交互”。当你在浏览器里拖拽节点、实时预览 latent 图、手动调整 CFG Scale这些操作都依赖 WebSocket 长连接维持前端状态。一旦你把它暴露到公网安全风险默认无认证任何知道 IP 的人都能上传任意 Python 脚本通过Load Image节点加载恶意.py文件资源失控一个用户连续点击 10 次 “Queue Prompt”会生成 10 个独立执行队列每个队列占用 2–3GB 显存最终 OOM无请求隔离所有用户的 prompt 都塞进同一个内存队列A 用户的长任务会阻塞 B 用户的短任务。所以必须做一层服务化封装把 ComfyUI 从“图形界面”变成“后台计算引擎”。核心思路是用 REST API 接收请求 → 转换为 ComfyUI 的 prompt JSON → 提交到 ComfyUI 的/prompt接口 → 轮询/history获取结果 → 返回 base64 图片。我采用的方案是Flask ComfyUI API组合代码仅 127 行已开源在 GitHub关键逻辑如下# app.py from flask import Flask, request, jsonify import requests import json import time import os app Flask(__name__) COMFYUI_URL http://127.0.0.1:8188 app.route(/generate, methods[POST]) def generate(): try: # 1. 接收用户 JSON必须包含 workflow_id 和 input_params data request.get_json() workflow_id data[workflow_id] # 如 ecommerce_product input_params data[input_params] # 如 {image_url: https://..., prompt: red dress} # 2. 加载预存工作流模板 with open(f/home/comfyui/ComfyUI/workflows/{workflow_id}.json, r) as f: workflow json.load(f) # 3. 注入动态参数关键替换 workflow 中的占位符 for node_id, node in workflow[nodes].items(): if inputs in node: for key, value in node[inputs].items(): if isinstance(value, str) and value.startswith({{) and value.endswith(}}): # 如 {{prompt}} → 替换为 input_params[prompt] placeholder value[2:-2] if placeholder in input_params: node[inputs][key] input_params[placeholder] # 4. 提交到 ComfyUI API prompt_id requests.post( f{COMFYUI_URL}/prompt, json{prompt: workflow} ).json()[prompt_id] # 5. 轮询结果最多 300 秒 for _ in range(300): time.sleep(1) history requests.get(f{COMFYUI_URL}/history/{prompt_id}).json() if prompt_id in history and status in history[prompt_id]: if history[prompt_id][status][completed]: # 6. 提取图片 base64 output history[prompt_id][outputs][save_image][images][0] image_url f{COMFYUI_URL}/view?filename{output[filename]}subfolder{output[subfolder]}typeoutput image_data requests.get(image_url).content return jsonify({image_base64: base64.b64encode(image_data).decode()}) return jsonify({error: timeout}), 408 except Exception as e: return jsonify({error: str(e)}), 500 if __name__ __main__: app.run(host0.0.0.0, port5000, debugFalse)注意这段代码必须运行在与 ComfyUI 同一主机且COMFYUI_URL指向127.0.0.1:8188而非公网 IP。因为 ComfyUI 的/prompt接口默认只监听 localhost这是安全设计不能修改。4.2 Nginx 反向代理给 API 加上企业级网关Flask 服务不能直接暴露给公网必须前置一层工业级网关。我选用 Nginx因为它轻量、稳定、且能无缝集成认证与限流。配置文件/etc/nginx/sites-available/comfyui-api如下upstream comfyui_backend { server 127.0.0.1:5000; } server { listen 443 ssl http2; server_name api.yourdomain.com; ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # 强制 HTTPS if ($scheme ! https) { return 301 https://$host$request_uri; } # API 认证使用 API Key location /generate { auth_request /auth; proxy_pass http://comfyui_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; } # 认证子请求 location /auth { internal; proxy_pass_request_body off; proxy_set_header Content-Length ; proxy_set_header X-Original-URI $request_uri; proxy_pass http://127.0.0.1:8000/auth; } # 健康检查 location /health { return 200 OK; add_header Content-Type text/plain; } }配套的认证服务/auth用一个极简的 Python 脚本实现它读取/etc/comfyui/api_keys.txt每行一个 key验证Authorization: Bearer key。这样你的前端调用就变成了curl -X POST https://api.yourdomain.com/generate \ -H Authorization: Bearer sk-xxx \ -H Content-Type: application/json \ -d {workflow_id:ecommerce_product,input_params:{prompt:white sneakers on black background}}实操心得Nginx 的proxy_buffering off;必须开启。因为 ComfyUI 的/prompt接口返回的是 JSON而 Flask 默认启用缓冲会导致首字节延迟。加上这行API 响应时间从平均 1.2s 降到 0.3s。4.3 自动化部署与监控用 systemd 管理进程用 Prometheus 抓取指标生产环境不能靠nohup python main.py 启动。必须用 systemd 做进程守护确保崩溃后自动重启、日志集中管理、启动依赖清晰。创建/etc/systemd/system/comfyui.service[Unit] DescriptionComfyUI Service Afternetwork.target [Service] Typesimple Usercomfyui WorkingDirectory/home/comfyui/ComfyUI ExecStart/home/comfyui/ComfyUI/venv/bin/python main.py --listen 127.0.0.1:8188 --disable-auto-launch Restartalways RestartSec10 StandardOutputjournal StandardErrorjournal SyslogIdentifiercomfyui [Install] WantedBymulti-user.target启用服务sudo systemctl daemon-reload sudo systemctl enable comfyui sudo systemctl start comfyui sudo journalctl -u comfyui -f # 实时查看日志监控方面我用 Prometheus 抓取两个核心指标nvidia_smi_utilization_gpu_percent来自node_exporter的nvidia_smicollector阈值设为 95%超时触发告警comfyui_queue_length自定义 exporter定期调用http://127.0.0.1:8188/prompt的/queue接口解析 JSON提取queue_running和queue_pending字段。提示ComfyUI 的/queue接口返回的是 HTML用于 Web UI 渲染不是 JSON。要获取队列长度必须解析div idqueue-size2/div这样的 DOM。我写了一个 20 行的 Python 脚本用requestsBeautifulSoup提取再暴露为/metrics端点供 Prometheus 抓取。5. 常见问题与排查技巧实录从 D3D 设备移除到工作流加载失败的全链路诊断5.1 GPU 崩溃类问题D3D device removed和CUDA error: initialization error的根因分析这两个错误看似不同实则同源GPU 上下文被操作系统强制重置。触发条件有三类错误类型触发场景日志特征解决方案D3D device removedWindows 子系统WSL2或远程桌面会话中 GPU 被挂起nvidia-smi显示GPU-xxxx: Not Supporteddmesg有NVRM: GPU at 0000:01:00.0 has fallen off the bus1. 禁用 WSL2 的 GPU 支持wsl --update --webgpu false2. 在云平台控制台关闭“GPU 节能模式”3. 更新驱动至535.129.03CUDA error: initialization error多进程竞争 GPU Contextnvidia-smi正常但python -c import torch; print(torch.cuda.is_available())返回False1. 检查是否多个 ComfyUI 实例绑定同一 GPUCUDA_VISIBLE_DEVICES02. 在main.py启动前加export CUDA_LAUNCH_BLOCKING1强制同步3. 重启nvidia-persistenced服务out of memory显存碎片化非真不足nvidia-smi显示Used: 12500MiB / 24576MiB但torch.cuda.memory_allocated()返回01. 在工作流开头插入FreeMemory节点来自Impact Pack2. 设置PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:1283. 重启 ComfyUI 进程实操心得nvidia-smi的Used值不可信。它显示的是驱动层分配的显存而 PyTorch 的memory_allocated()显示的是框架层实际使用的。两者差值就是“显存碎片”。我写了一个一键清理脚本#!/bin/bash # clear_gpu.sh echo Clearing GPU cache... sudo fuser -v /dev/nvidia* 2/dev/null | awk {print $2} | xargs -r kill -9 2/dev/null sudo nvidia-smi --gpu-reset -i 0 2/dev/null echo Done. Run nvidia-smi to verify.5.2 工作流加载失败KeyError: class_type和ModuleNotFoundError的精准定位当你导入一个.json工作流页面报错KeyError: class_type这不是文件损坏而是ComfyUI 版本与工作流导出版本不匹配。ComfyUI v0.35.0 修改了节点序列化格式将原来的class_type: KSampler改为type: KSampler而旧版工作流仍用class_type。解决方案只有两个降级 ComfyUIgit checkout v0.34.10然后git submodule update --init --recursive升级工作流用在线工具 ComfyUI Workflow Updater 上传 JSON自动转换字段名。ModuleNotFoundError更常见比如No module named cv2。这表示工作流中某个节点如Impact Pack的FaceDetailer依赖 OpenCV但你的环境没装。排查步骤查看报错日志末尾的Traceback定位到具体哪一行import cv2进入custom_nodes/ComfyUI-Impact-Pack目录查看其requirements.txt执行pip install -r requirements.txt注意必须在 ComfyUI 的 venv 中如果requirements.txt里写的是opencv-python而你需要opencv-python-headless无 GUI则手动pip install opencv-python-headless。注意ComfyUI-Manager的Install按钮有时会跳过requirements.txt因为它只认__init__.py中的NODE_CLASS_MAPPINGS。此时必须手动进入节点目录执行pip install。5.3 网络与权限类问题Connection refused和Permission denied的现场还原Connection refused通常发生在两种场景ComfyUI 未启动systemctl status comfyui显示inactive (dead)原因是main.py启动时--listen参数绑定失败。检查sudo journalctl -u comfyui | grep Failed to bind大概率是端口被占用如8188被另一个进程占了Nginx 配置错误proxy_pass指向了错误的地址如http://localhost:5000而不是http://127.0.0.1:5000Nginx 会因 DNS 解析失败返回502 Bad Gateway但浏览器显示为Connection refused。Permission denied多半是文件权限问题。典型案例如
返回列表