ComfyUI 原生启动参数中没有提供 Basic Auth 密码验证功能，直接暴露服务存在未授权访问风险。最可靠的处理方案是在 ComfyUI 前端部署 Nginx 或 Caddy 反向代理，由代理层处理身份验证。
先说结论：ComfyUI 核心程序不包含身份验证模块，必须依赖外部反向代理或隧道服务实现访问控制。
- 先判断：确认 ComfyUI 版本及启动参数，原生不支持 `--auth` 类指令。
- 优先做：使用 Nginx 配置 htpasswd 或 Cloudflare Tunnel 设置访问策略。
- 再验证：通过浏览器隐私模式或 curl 命令测试未登录是否无法访问。
命令速用版
以下是 Nginx 配置 Basic Auth 的核心片段，将其放入 server 配置块即可生效。
location / {
proxy_pass http://127.0.0.1:8188;
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.htpasswd;
}生成密码文件命令：htpasswd -c /etc/nginx/.htpasswd username
为什么会这样
ComfyUI 设计初衷是本地桌面工具，网络暴露功能仅为调试便利，未内置安全认证模块。官方文档在介绍 `--listen` 参数时仅提示用于局域网访问，未提及内置密码保护机制。因此直接监听 0.0.0.0 会导致任何知道 IP 的人都能提交工作流。
分步处理
步骤 1：安装 Nginx 并生成密码文件
适用场景：Linux 服务器或本地部署环境。操作动作：安装 apache2-utils 工具包，执行 htpasswd 命令生成凭证。验证结果：确认文件生成且包含加密密码。风险边界：密码文件权限需设置为 640，防止被其他用户读取。
步骤 2：配置反向代理
适用场景：Nginx 已安装并运行。操作动作：编辑 nginx.conf 或 sites-available 配置，添加 auth_basic 指令。验证结果：执行 nginx -t 检查语法无错误。风险边界：确保 proxy_pass 地址与 ComfyUI 实际监听端口一致，默认为 8188。
步骤 3：重启服务
适用场景：配置修改完成后。操作动作：执行 nginx -s reload 或 systemctl restart nginx。验证结果：Nginx 进程状态为 active。风险边界：重启可能导致短暂连接中断，建议在业务低峰期操作。
怎么验证是否生效
使用 curl 命令不带凭证访问，应返回 401 Unauthorized 状态码。浏览器访问时应弹出密码输入框，输入错误密码无法加载界面。
curl -I http://your-server-ip:80检查返回头中是否包含 WWW-Authenticate: Basic 字段。
常见坑
1. ComfyUI 启动时使用了 `--listen` 0.0.0.0，若 Nginx 配置错误，后端仍可能直接暴露。
2. 密码文件路径权限错误，Nginx 无法读取会导致 500 错误而非密码验证。
3. 未配置 HTTPS，密码在网络中以明文传输，建议配合 SSL 证书使用。
常见问题
ComfyUI 有没有自带的账号密码登录插件？
社区虽有 custom nodes 尝试实现，但非官方标准，稳定性不如反向代理方案。
只用 `--listen` 参数安全吗？
不安全，该参数仅开启网络监听，不包含任何访问控制或加密措施。
Cloudflare Tunnel 能代替 Nginx 吗？
可以，Cloudflare Access 策略能提供类似的身份验证且无需暴露公网 IP。
参考来源
- ComfyUI GitHub Repository, README.md, `--listen` parameter description. URL: https://github.com/comfyanonymous/ComfyUI
- Nginx Official Documentation, Module ngx_http_auth_basic_module. URL: https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html