ControlNet 自动启动服务配置教程：稳定运行，附模型选择建议

ControlNet 自动启动适合哪些场景

ControlNet 常用于 Stable Diffusion 工作流中的姿态控制、边缘线稿、深度图、分割图等条件生成任务。对于个人创作者来说，手动启动 WebUI 后再加载插件已经可以满足日常使用；但在工作室、内网共享机器、远程渲染主机或固定生产环境中，频繁手动启动容易造成流程中断，也不利于多人协作。因此，将 ControlNet 所在的 Stable Diffusion WebUI 配置为自动启动服务，可以在设备重启后自动恢复运行，并在异常退出时尝试拉起进程。

需要注意的是，ControlNet 本身通常不是单独运行的后台程序，而是作为 WebUI 的扩展加载。因此所谓“ControlNet 自动启动”，核心是让承载它的 WebUI 稳定启动，同时确保扩展目录、模型目录、启动参数和运行用户都配置正确。只要 WebUI 启动成功，ControlNet 扩展和模型能够正常识别，自动服务就算完成了主要目标。

准备工作：先确认环境能手动运行

配置服务前，不建议直接改系统启动项。第一步应先确认手动运行完全正常，包括 Python 环境、依赖包、显卡驱动、WebUI 主程序、ControlNet 扩展、模型文件路径等。建议先进入 WebUI 目录，执行原本的启动脚本，打开浏览器访问本机地址，确认页面能加载，ControlNet 面板能展开，选择预处理器和模型后可以正常生成结果。

常见目录结构一般包括 WebUI 主目录、extensions 目录以及 models 目录。ControlNet 扩展通常位于 extensions 下，模型文件一般放在 models/ControlNet 或扩展指定的模型目录中。模型格式常见为 safetensors 或 pth，建议优先使用来源明确、下载页面说明完整的文件。若手动启动时已经出现缺包、端口被占用、模型无法读取等问题，自动启动只会把问题隐藏到日志里，排查更困难。

Windows：使用任务计划程序实现开机启动

Windows 用户最简单的做法是使用“任务计划程序”。先新建一个启动用的 bat 文件，例如 start-webui.bat，内容可以写为切换到 WebUI 目录后执行启动脚本。示例思路是：先进入对应盘符，再 cd 到 WebUI 文件夹，最后运行 webui-user.bat。不要把路径写错，也不要依赖桌面快捷方式，因为服务启动时工作目录可能并不是你平时双击的位置。

打开任务计划程序后，选择“创建任务”，在“常规”中填写名称，例如 Stable Diffusion WebUI Service，并选择“使用最高权限运行”时要谨慎。如果只是本机创作环境，一般不需要给过高权限，能正常访问模型目录和 Python 环境即可。在“触发器”中选择“登录时”或“启动时”；如果机器无人值守，更适合选择“启动时”，但要确保网络磁盘、外接硬盘等资源已就绪。

在“操作”中选择“启动程序”，程序填写 bat 文件路径，起始于填写 WebUI 主目录。很多启动失败都出在“起始于”为空，导致脚本找不到相对路径。条件选项中可取消“只有在使用交流电源时才启动”，适用于笔记本长期运行场景；设置选项中可勾选“如果任务失败，按间隔重新启动”，例如每 5 分钟重试一次，最多 3 次。保存后重启测试，确认任务是否自动执行，并查看 WebUI 控制台或日志文件。

Linux：使用 systemd 管理后台运行

Linux 服务器更推荐使用 systemd。先创建一个独立的普通用户运行 WebUI，不建议使用 root 直接执行。假设 WebUI 位于 /opt/sd-webui，可创建服务文件，例如 /etc/systemd/system/sd-webui.service。服务内容需要包含工作目录、启动命令、运行用户、重启策略和环境变量。启动命令可指向 webui.sh，也可以指向你自定义的启动脚本。

典型配置思路是：Unit 部分描述服务名称并设置网络就绪后启动；Service 部分设置 User、WorkingDirectory、ExecStart、Restart=on-failure、RestartSec=10；Install 部分设置 WantedBy=multi-user.target。保存后执行 systemctl daemon-reload，再执行 systemctl enable sd-webui 和 systemctl start sd-webui。查看状态可使用 systemctl status sd-webui，查看实时日志可使用 journalctl -u sd-webui -f。

如果需要指定端口、监听地址、显存优化参数，应写入启动脚本或 ExecStart 中。例如仅本机访问可绑定 127.0.0.1；内网共享才考虑绑定局域网地址。不要为了省事把管理页面暴露到不可信网络。若多人使用，建议在前端再增加访问控制、反向袋里白名单或账号校验，并定期更新组件。

启动参数与稳定性建议

自动启动并不等于参数越多越好。常见参数包括指定端口、启用 xformers、低显存模式、禁止自动打开浏览器等。对于显存较小的显卡，可考虑 medvram 或 lowvram，但生成速度会下降；对于较新的显卡和驱动，xformers 或其他优化库可能提升速度，但也可能带来兼容性问题。建议先用最小参数稳定运行，再逐项加入优化。

日志非常重要。Windows 可在 bat 中将输出重定向到 log 文件，便于查看启动失败原因；Linux 可依赖 journalctl，也可在启动脚本中写入自定义日志。自动重启策略不要设置得过于激进，如果模型文件损坏或依赖错误，服务会反复失败，造成资源占用。更稳妥的做法是设置合理重试次数，并保留错误日志。

ControlNet 模型选择建议

ControlNet 模型并不是越多越好，应根据实际任务选择。若需要根据人物姿态控制画面构图，可选择 openpose 类型模型；若希望根据线稿、草图或边缘信息生成图像，可选择 canny、scribble、lineart 等方向；若需要保持空间层次和场景结构，可选择 depth 类型；若是室内、建筑或复杂物体分区，可考虑 segmentation 类型；如果要保留画面轮廓和细节，可选择 tile、softedge 等模型。

模型版本要与底模体系匹配。SD 1.5 系列、SDXL 系列通常需要对应版本的 ControlNet 模型，混用可能导致效果变差、报错或显存压力异常。显存 6GB 左右的设备建议优先选择 SD 1.5 相关模型，单次只启用一个 ControlNet 单元，并降低分辨率；8GB 到 12GB 可尝试两个单元组合，例如 openpose 加 depth；更高显存才适合高分辨率、多单元、SDXL 工作流。生产环境中应固定模型版本，避免每次更新后输出风格和结构发生明显变化。

常见问题排查

问题一：开机后服务显示运行，但页面打不开。优先检查端口是否被其他程序占用、启动地址是否正确、脚本工作目录是否设置。Windows 尤其要检查任务计划中的“起始于”；Linux 则查看 journalctl 日志，确认是否卡在依赖安装或模型扫描阶段。

问题二：WebUI 能打开，但 ControlNet 面板消失。通常是扩展未正确加载、扩展目录损坏、版本不兼容或启动时跳过了扩展。可先停用服务，手动启动观察控制台报错，再更新扩展或回退到稳定版本。不要在生产机器上频繁尝试未经验证的分支。

问题三：模型列表为空。检查模型文件是否放在正确目录，文件后缀是否完整，权限是否允许运行用户读取。Linux 下如果使用独立用户运行服务，常见问题是模型由另一个用户下载，权限不足。修正权限后重启 WebUI，一般即可重新扫描。

问题四：运行一段时间后自动退出。可能是显存不足、内存不足、驱动异常或某个扩展冲突。可降低批量数量和分辨率，减少同时启用的 ControlNet 单元，关闭不必要扩展，并观察日志中的最后一段报错。如果系统资源长期接近上限，应考虑调整任务队列，而不是只依赖自动重启。

安全边界与维护习惯

AI 工具安装教程中最容易被忽视的是安全边界。ControlNet 模型和扩展应尽量从可信项目页、社区镜像或团队内部仓库获取，不要运行来历不明的脚本。自动启动服务不应使用过高权限，也不应开放到不受控的公网环境。若必须给团队访问，应设置访问入口、日志留存和资源限制，避免他人误操作导致机器长时间满载。

更新前建议备份配置文件、扩展目录版本号和正在使用的模型清单。稳定生产环境不必追求最新，尤其是 WebUI、ControlNet 扩展和推理库同时更新时，兼容性风险会增加。更推荐建立“测试目录”和“正式目录”：先在测试目录验证新版本，再迁移到正式服务。这样即使升级失败，也能快速回到原来的可用状态。

完成自动启动配置后，最好做三次测试：手动停止并启动服务、重启系统后访问页面、执行一次完整的 ControlNet 生成任务。只有启动、加载、推理和日志都正常，才算真正完成部署。对于长期运行的机器，还应定期清理临时文件、检查磁盘空间、整理模型目录，保持环境简单清晰，才能让 ControlNet 在日常创作和团队流程中稳定发挥作用。