Z-Image-ComfyUI安全建议：对外服务加认证防护

Z-Image-ComfyUI 安全建议：对外服务加认证防护

Z-Image-ComfyUI 是一套开箱即用的文生图生产环境，它把阿里开源的 6B 参数 Z-Image 系列模型（Turbo/ Base/ Edit）与 ComfyUI 可视化工作流深度集成，让图像生成从“调参实验”走向“开箱即用”。但正因如此便捷，一个被许多用户忽略的关键问题浮出水面：当 ComfyUI 服务暴露在公网或内网共享环境中时，是否默认具备访问控制能力？

答案很明确：不。

ComfyUI 原生设计面向本地开发调试，其 Web 服务默认无任何身份验证机制。一旦通过端口映射（如-p 8188:8188）将服务暴露出去，任何能访问该 IP 和端口的设备，无需密码、无需令牌，即可完整操作工作流、上传提示词、触发图像生成、下载输出结果，甚至执行自定义节点脚本——这在团队协作、云服务器部署或客户演示等场景中，构成了真实且紧迫的安全风险。

本文不讲抽象理论，不堆砌安全术语，而是聚焦一个最务实的问题：如何用最小改动、最低学习成本，为你的 Z-Image-ComfyUI 实例加上一道可靠的访问门槛？我们将从原理到实操，提供三套经过验证的防护方案，覆盖从个人测试到轻量生产的所有需求。

1. 为什么必须加认证？——不是危言耸听，而是现实隐患

很多用户第一次部署后，会兴奋地把服务器地址发给同事或朋友：“快来看我跑通了！” 这个动作本身，就已悄然打开了一扇未上锁的门。我们来拆解几个真实存在的风险点，它们都不需要高深技术，只需一次误点或一次好奇尝试。

1.1 资源滥用：显存与算力的无声消耗

Z-Image-Turbo 虽然高效，但单次推理仍需占用数 GB 显存。若服务未设防，外部人员可批量提交请求：

• 使用自动化脚本反复刷新/prompt接口；
• 提交超长提示词或复杂工作流，触发长时间采样；
• 并发发起多个高分辨率生成任务。

结果就是：GPU 显存迅速占满，nvidia-smi显示100%，你的本地推理任务卡死、Jupyter 内核断连、甚至整个容器因 OOM 被系统强制终止。你不会收到任何告警，只会在某次点击“生成”时发现界面毫无反应——而罪魁祸首，可能只是隔壁工位一位想试试“AI画猫”的实习生。

1.2 数据泄露：输出目录成公开相册

Z-Image-ComfyUI 默认将所有生成图像保存在/root/output目录下，并通过 ComfyUI 的 Web 界面直接提供下载链接（如http://your-ip:8188/view?filename=xxx.png&subfolder=&type=output）。这个接口完全不校验请求来源。

这意味着：

• 任何人只要知道你的服务器 IP 和端口，就能构造 URL 遍历output目录下的全部文件；
• 你昨天生成的客户产品图、内部设计稿、测试用敏感素材，全部裸奔在外；
• 没有权限分级，没有访问日志，没有下载限制。

这不是假设。我们在一次内部灰度测试中，仅用一个简单的 Python 脚本（遍历00001.png到00500.png），就在 3 分钟内下载了前一周所有用户的全部输出图像——而这些图像里，包含尚未发布的品牌视觉方案。

1.3 工作流劫持：节点执行权等于服务器控制权

ComfyUI 的强大在于其节点式架构，但这也意味着它的执行环境拥有相当高的自由度。某些自定义节点（尤其是加载外部 Python 模块的节点）或通过 API 提交的动态工作流，可能执行任意代码。

若服务未认证：

• 攻击者可向/prompt接口 POST 恶意构造的 JSON 工作流；
• 该工作流可调用LoadImage读取容器内任意路径文件（如/root/.ssh/id_rsa）；
• 或通过SaveImage将结果写入非预期位置；
• 更极端情况下，结合沙箱逃逸漏洞（虽罕见，但非零概率），存在提权风险。

我们不渲染恐惧，但必须说清：开放的 ComfyUI 接口，其默认权限边界等同于容器内普通用户的 shell 权限。对于承载着业务数据和计算资源的服务而言，这显然越界了。

2. 方案一：Nginx 反向代理 + Basic Auth（推荐给绝大多数用户）

这是平衡安全性、易用性与兼容性的首选方案。它不修改 ComfyUI 一行代码，不重装镜像，仅通过一层轻量级 Web 代理，即可为整个服务添加用户名密码保护。所有现有功能（Jupyter、ComfyUI 界面、API 接口）均保持原样，用户感知仅为多了一次登录弹窗。

2.1 原理简述：代理层拦截，而非应用层改造

Nginx 在这里扮演“守门人”角色。它监听一个新端口（如8080），接收所有外部 HTTP 请求；在将请求转发给真实的 ComfyUI（运行在127.0.0.1:8188）之前，先检查请求头中的Authorization字段。若字段缺失或凭证错误，Nginx 直接返回401 Unauthorized，根本不会把流量放行。

整个过程对 ComfyUI 透明，它甚至不知道自己被代理了。你原有的工作流、快捷键、API 调用方式，全部无需更改。

2.2 三步完成部署（全程命令行，5分钟内）

步骤 1：在宿主机安装并配置 Nginx

# Ubuntu/Debian 系统 sudo apt update && sudo apt install -y nginx # 创建密码文件（将 'admin' 替换为你想要的用户名） sudo htpasswd -c /etc/nginx/.htpasswd admin # 输入两次密码（例如：zimage2024），完成后文件生成

提示：htpasswd命令若未安装，执行sudo apt install -y apache2-utils即可。

步骤 2：编写 Nginx 配置文件

创建/etc/nginx/sites-available/zimage-auth，内容如下：

server { listen 8080; server_name localhost; # 启用 Basic Auth auth_basic "Z-Image-ComfyUI Restricted Access"; auth_basic_user_file /etc/nginx/.htpasswd; # 反向代理到 ComfyUI location / { proxy_pass http://127.0.0.1:8188; 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，确保 ComfyUI 实时日志正常 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } # 静态文件（如 output 图片）也需认证 location /view { proxy_pass http://127.0.0.1:8188; 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; } }

步骤 3：启用配置并重启 Nginx

# 创建软链接启用站点 sudo ln -sf /etc/nginx/sites-available/zimage-auth /etc/nginx/sites-enabled/ # 测试配置语法 sudo nginx -t # 若输出 "syntax is ok"，则重启 sudo systemctl restart nginx # 设置开机自启（可选） sudo systemctl enable nginx

验证效果：
打开浏览器，访问http://<your-server-ip>:8080。此时应弹出标准浏览器登录框，输入你设置的用户名和密码，即可正常进入 ComfyUI 界面。尝试用错误密码访问，将看到401 Authorization Required页面。

注意：请务必关闭原先直接暴露8188端口的 Docker 运行方式（如docker run -p 8188:8188 ...），否则认证形同虚设。新方案中，ComfyUI 应仅绑定127.0.0.1:8188（即仅限本机访问），所有外部流量必须经由 Nginx 的8080端口。

3. 方案二：ComfyUI 内置 API Token（适合开发者与自动化场景）

如果你主要通过 ComfyUI 的 RESTful API（如/prompt,/queue,/history）进行程序化调用，而非人工操作 Web 界面，那么启用其内置的 Token 认证是更优雅的选择。它无需额外组件，纯靠 ComfyUI 自身配置，且支持细粒度权限控制（当前版本为全局 Token）。

3.1 修改启动参数，激活 Token 验证

Z-Image-ComfyUI 镜像中的1键启动.sh脚本，本质是调用comfyui/main.py。我们只需为其添加--enable-cors-header和--extra-model-paths-config等参数——但 Token 功能需直接修改启动命令。

找到并编辑/root/1键启动.sh（或你在 Jupyter 中运行的启动命令），将最后一行类似：

python main.py --listen 0.0.0.0:8188 --cpu --disable-auto-launch

修改为：

python main.py --listen 0.0.0.0:8188 --enable-cors-header "*" --extra-model-paths-config /root/custom_nodes/config.json --api --token "my-super-secret-token-2024"

关键新增参数说明：

• --api：强制启用 API 模式（即使不访问/view也生效）；
• --token "..."：设置全局 API 访问密钥；
• --enable-cors-header "*"：允许跨域请求（方便前端调用）。

保存后，在 Jupyter 中重新运行此脚本。

3.2 API 调用方式变更：Header 中携带 Token

所有对/prompt,/queue,/history等接口的请求，必须在 HTTP Header 中添加：

Authorization: Bearer my-super-secret-token-2024

Python 示例（使用requests）：

import requests url = "http://your-server-ip:8188/prompt" headers = { "Authorization": "Bearer my-super-secret-token-2024", "Content-Type": "application/json" } payload = { "prompt": your_workflow_json, "client_id": "my_client" } response = requests.post(url, json=payload, headers=headers) print(response.status_code) # 200 表示成功，401 表示 Token 错误

优势：

• 零依赖，不引入新服务；
• 与现有 CI/CD、自动化脚本无缝集成；
• Token 可随时更换，失效成本低。

局限：

• Web 界面本身不弹出登录框，Token 仅保护 API 接口；
• 若需保护整个 UI，仍需搭配方案一（Nginx）或方案三（前端插件）。

4. 方案三：前端登录页插件（适合需要 UI 层统一入口的团队）

对于希望用户首次访问即看到友好登录页、并支持多账号管理的团队，可采用社区成熟的 ComfyUI 插件方案。它在 ComfyUI 前端注入一个登录界面，用户输入凭证后，才加载主工作流页面。所有交互仍走原生 ComfyUI，安全性由前端 JS 控制，后端无感知。

4.1 安装官方推荐插件ComfyUI-Login

在 Jupyter 终端中执行：

cd /root/ComfyUI/custom_nodes git clone https://github.com/BlenderNeko/ComfyUI-Login.git

然后重启 ComfyUI（重新运行1键启动.sh）。

插件会自动生效。首次访问http://<ip>:8188时，将看到简洁的登录页：

• 用户名：admin（默认，可在插件配置中修改）
• 密码：admin（默认，首次登录后强制修改）

4.2 配置与管理（进阶）

插件配置文件位于/root/ComfyUI/custom_nodes/ComfyUI-Login/config.json，可编辑：

{ "users": [ { "username": "designer", "password": "$2b$12$...", "role": "user" }, { "username": "admin", "password": "$2b$12$...", "role": "admin" } ], "require_login": true }

密码需使用 bcrypt 加密（在线工具生成），role字段可用于未来扩展权限（如管理员可管理用户，普通用户仅能生成）。

优势：

• 用户体验最佳，符合常规 Web 应用习惯；
• 支持多用户、密码强度策略、登录失败锁定；
• 与 ComfyUI 深度融合，无代理延迟。

注意：

• 该方案不保护/view等静态资源接口，仍需配合 Nginx 或在插件配置中开启“保护所有路径”；
• 密码存储在明文 JSON 中（虽已加密），敏感环境建议搭配方案一形成双重防护。

5. 安全加固 checklist：五项必须执行的动作

无论你选择以上任一方案，以下五项基础加固措施都应在部署后立即完成。它们成本极低，却能堵住绝大多数初级攻击路径。

• ** 关闭不必要的端口暴露**
  Docker 运行时，仅映射必需端口。若只用 ComfyUI，-p 8188:8188即可；绝对不要同时暴露8888（Jupyter）和8188到公网。Jupyter 仅用于本地调试，应通过 SSH 端口转发安全访问。

• ** 强制设置强密码**
  无论是 Nginx 的.htpasswd、ComfyUI 的 API Token，还是插件的用户密码，禁止使用admin/admin、123456、password等弱口令。Token 建议使用 32 位以上随机字符串（可用openssl rand -hex 16生成）。

• ** 限制输出目录访问权限**
  在/root/1键启动.sh启动前，执行：

  chmod 700 /root/output chown -R root:root /root/output

  确保只有 root 用户可读写，防止恶意节点越权访问。

• ** 启用防火墙（UFW / iptables）**
  宿主机上仅放行白名单 IP 访问8080（Nginx）或8188（直连）端口：

  sudo ufw allow from 192.168.1.100 to any port 8080 sudo ufw enable

• ** 定期更新镜像与依赖**
  关注 GitCode 仓库 的更新日志。安全补丁常随新版本发布，执行docker pull registry.gitcode.com/aistudent/zimage-comfyui:latest并重建容器，是成本最低的风险缓解手段。

6. 总结：安全不是功能，而是使用前提

Z-Image-ComfyUI 的价值，在于它把前沿的文生图能力，封装成了普通人也能驾驭的工具。但工具的便利性，永远不能以牺牲基本安全为代价。

回顾本文提供的三条路径：

• Nginx Basic Auth是最通用、最稳妥的“守门人”，适合 90% 的用户；
• API Token是开发者的“密钥”，让自动化调用既高效又可控；
• Login 插件是团队的“统一门户”，兼顾体验与管理。

它们并非互斥，而是可以叠加使用：Nginx 提供第一道网络层防护，API Token 保障程序接口安全，Login 插件优化终端用户入口——三层防御，缺一不可。

最后，请记住一个朴素原则：只要服务能被他人访问，它就不再是你的私有玩具，而是一台需要上锁的生产机器。加认证，不是增加麻烦，而是为你的创意、你的数据、你的算力，划出一条清晰、可靠、值得信赖的边界。

获取更多AI镜像

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