issue: after WEBUI_SECRET_KEY changes with multi-factor sign-in on, Open WebUI won’t start and the error doesn’t say why

快速结论：该 issue: after WEBUI_SECRET_KEY changes with multi-factor sign-in on, Open WebUI won’t start and the error doesn’t say why 通常发生在已开启多因素认证且已有用户完成验证器绑定的 Open WebUI 实例上，改动 WEBUI_SECRET_KEY（或在 Docker 中未固定该变量、重建容器后自动生成了新密钥）后启动即失败。优先排查 WEBUI_SECRET_KEY 是否与当初加密 MFA 密钥时一致，以及 MFA_ENCRYPTION_KEY 的取值来源。

适用环境：Open WebUI，安装方式为 Git Clone；Open WebUI 版本为 latest dev（e86c82406）；操作系统 Linux；Ollama v0.40.2；数据库为 SQLite（复现实例使用全新实例、无其他配置）。

最快修复方案：暂无确认的一步修复方案。Issue 期望的修复是让启动报错明确指出 WEBUI_SECRET_KEY 和 MFA_ENCRYPTION_KEY 需要恢复，而非当前写给学生用户看的 503 提示；截至 Issue 关闭时，评论中没有给出可直接执行的修复命令。

注意事项：拒绝启动本身是预期行为——没有原始密钥就无法解密已存储的验证器密钥，不应通过绕过检查来强行启动。Issue 指出在 Docker 中不显式设置 WEBUI_SECRET_KEY 时，生成的密钥写在 backend 旁边、位于数据卷之外，重建容器即产生新密钥，这是最容易踩坑的场景；恢复时请确认找对旧密钥，而非重新生成。

问题场景

用户在 Linux 上以 Git Clone 方式运行 Open WebUI（latest dev，e86c82406），使用 SQLite 数据库并连接 Ollama v0.40.2。第一次启动时设置了某个 WEBUI_SECRET_KEY，未设置 MFA_ENCRYPTION_KEY；注册首个用户后，在管理面板 Settings > Authentication 的 Multi-factor authentication 中开启“Require an authenticator for all users”，并在重新登录时完成验证器应用绑定。之后停止 Open WebUI，改用另一个 WEBUI_SECRET_KEY 启动，服务在启动阶段直接退出。Issue 反馈中另有用户表示容器因此无法再次启动。

报错原文

fastapi.exceptions.HTTPException: 503: Authenticator configuration is unavailable. Contact the operator.

Application startup failed. Exiting.

原因分析

启动时 Open WebUI 会校验所有已存储的验证器密钥能否被解密，而这项校验复用了登录流程中的辅助函数，其提示语是写给最终用户看的，因此启动日志里出现的是一条面向登录用户的 503 文案，没有指明是哪个配置项出了问题。实际上密钥不匹配才是根因：已存储的 MFA 密钥是用原 WEBUI_SECRET_KEY（以及 MFA_ENCRYPTION_KEY）加密的，换成新密钥后无法解密。同一个函数中的其他检查已能给出清晰的启动错误，例如 “A persistent WEBUI_SECRET_KEY is required for MFA.”，说明这里是错误信息复用导致的表述问题。在 Docker 场景下，若未显式设置 WEBUI_SECRET_KEY，自动生成的密钥不在数据卷内，容器重建即触发同一类密钥不匹配。

环境排查

确认 Open WebUI 版本，Issue 在 latest dev（e86c82406）复现，可对照当前版本是否已包含错误信息改进。
确认部署方式：Git Clone 还是 Docker；Docker 下检查是否显式传入 WEBUI_SECRET_KEY，以及密钥文件是否位于持久化卷中。
确认当前生效的 WEBUI_SECRET_KEY 与开启 MFA、绑定验证器时使用的那一个是否一致。
确认 MFA_ENCRYPTION_KEY 是否设置过；Issue 复现时该变量未设置。
确认数据库类型（Issue 中为 SQLite）以及是否经历过容器重建、镜像更新或数据库恢复。
确认多因素认证是否已开启且至少有一个用户完成验证器绑定。

解决步骤

先阅读启动日志末尾的完整堆栈，确认退出原因是 503: Authenticator configuration is unavailable. Contact the operator.，而不是其他启动失败。
回溯改动：确认本次启动与上次成功启动之间，WEBUI_SECRET_KEY 是否被修改、清空，或在 Docker 中因容器重建而重新生成（可优先尝试检查密钥是否被写在数据卷之外）。
可优先尝试：把 WEBUI_SECRET_KEY 恢复为开启 MFA 时使用的原始值，并保持已有的 MFA_ENCRYPTION_KEY 不变，然后重新启动服务。由于 Issue 未提供一步到位的验证结论，此步骤需自行验证结果。
若原始密钥已丢失，不要简单换一个新密钥继续启动；Issue 表明此时无法解密存储的验证器密钥，服务会继续拒绝启动。需要由熟悉部署的运维人员评估数据与 MFA 配置的处理方式，Issue 中未给出该场景的操作步骤。
在 Docker 部署中，可用性改善措施是显式设置固定的 WEBUI_SECRET_KEY，并确保其持久化，避免容器重建后密钥变化再次触发该问题。

验证方法

使用原始 WEBUI_SECRET_KEY 重新启动后，日志中不再出现 503: Authenticator configuration is unavailable. Contact the operator. 与 Application startup failed. Exiting.，服务正常进入运行状态，已绑定验证器的用户可以用验证器应用正常完成多因素登录。Issue 建议的最终修复形态是：启动仍会停止，但错误信息会点名 WEBUI_SECRET_KEY 和 MFA_ENCRYPTION_KEY；若升级后仍只看到笼统的 503 文案，说明尚未包含该改进。