ComfyUI使用中有哪些禁忌

ComfyUI使用禁忌与规避清单

安全与部署禁忌

• 禁止将 ComfyUI 控制台对公网无鉴权暴露；该项目的官方立场是“未授权访问属于错误配置”，应仅在内网或沙箱中运行，必要时使用反向代理与访问控制。历史上还披露过包括任意文件读取、远程代码执行、存储型XSS在内的多类漏洞（如：CVE-2024-10099、CVE-2024-21574～21577），公网暴露风险极高。
• 禁止通过不受信任来源加载模型，尤其是 .pth 等可能触发 pickle 反序列化的文件；攻击者曾利用 ComfyUI-Manager 的远程下载功能从 Hugging Face 及其镜像站拉取恶意 .pth，在加载时执行恶意代码，进一步下载 C2 木马。
• 禁止在生产环境使用来历不明的插件/自定义节点；曾出现插件 ComfyUI_LLMVISION 内置恶意程序窃取浏览器数据，后被平台封禁；建议优先用 ComfyUI-Manager 安装并关注其安全提示。
• 禁止忽视依赖供应链风险；如 ultralytics 8.3.41 版本曾被植入挖矿脚本，运行相关节点会导致 CPU/GPU 异常占用；发现应立刻卸载并升级到安全版本。
• 禁止以 root/管理员身份长期运行 ComfyUI 或在工作流中随意执行系统命令/下载脚本节点，降低被恶意工作流“提权”的可能。

合规与授权禁忌

• 忽视 GPL-3.0 传染性是商业部署的高风险做法：对 ComfyUI 本体或核心进行修改后再分发（如打包成 Docker 镜像交付客户），通常需要公开相应源码；若仅作为独立服务运行 SaaS 模式，通常不视为“分发”，但仍需结合具体集成形态与法律意见评估。
• 将 ComfyUI 与自有代码深度耦合（共享内存、函数调用）可能被认定为单一程序从而触发 copyleft；更稳妥的做法是通过 REST API/消息队列进行进程间通信，保持清晰的模块化边界。
• 分发包含 ComfyUI 修改版的闭源商业产品而不提供源码，存在合规风险；建议对核心保持“原版+配置”，把业务逻辑放在独立服务中实现。

资源与运维禁忌

• 禁止在 CPU-only 或显存不足环境下强行运行大模型/复杂工作流，易导致系统卡死或OOM；建议至少配备8GB 显存的 NVIDIA 显卡，低显存机型需谨慎设置参数与分辨率。
• 禁止长期不更新 ComfyUI、插件与依赖；版本不匹配是常见报错与漏洞暴露源，应建立定期更新与回滚机制。
• 禁止在生产环境使用来源不明的整合包/一键安装器；若必须使用，务必核验哈希与签名、隔离运行并保留变更记录。
• 禁止忽视日志与审计：应开启访问日志、任务日志与模型/工作流版本留存，便于溯源与合规。

快速自检清单

• 访问管理界面是否需要强认证（强密码/Token/网络访问控制），仅在内网或受控网段开放。
• 近期是否安装/更新过插件或依赖；如用到 ultralytics，立即执行：pip show ultralytics，若版本为8.3.41，立刻卸载并升级。
• 是否从 Hugging Face/镜像站或匿名短链（如 0x0.st）下载过 .pth/.ckpt 等模型文件；发现异常立即隔离、查杀并更换为可信来源。
• 是否以 root/管理员运行；工作流中是否包含执行命令/下载脚本等高风险节点，必要时移除或改为离线、受控执行。
• 商业部署是否涉及分发（镜像、安装包、交付客户环境）；如是，评估 GPL-3.0 义务或咨询专业法务。