OpenClaw All models failed 错误排查步骤

在部署或使用 OpenClaw 的过程中，如果系统提示 All models failed，通常表示当前任务请求已经尝试调用一个或多个模型，但最终所有模型都返回失败结果，因此 OpenClaw 无法继续完成推理、对话、任务执行或自动化流程。这类报错并不一定意味着 OpenClaw 主程序本身损坏，更常见的原因是模型平台连接异常、API Key 配置错误、模型名称填写不正确、第三方接口不可用、网络访问失败、请求参数超限、账户额度不足，或者多模型回退策略全部失效。要解决 OpenClaw All models failed 问题，关键不在于简单重启，而在于按顺序检查模型接入链路、平台授权状态、日志内容、网络环境以及配置文件。

一、先理解 All models failed 的真实含义

OpenClaw 通常支持单模型调用和多模型回退机制。当首选模型不可用时，系统可能会自动切换到备用模型继续请求。如果主模型失败、备用模型失败、默认模型失败，最终所有候选模型都没有返回可用结果，就会出现 All models failed 提示。

这说明问题可能存在于以下层面：

二、第一步：查看 OpenClaw 详细错误日志

如果是本地部署，可以先查看项目日志目录：

cd logs
ls

常见日志文件包括：

重点查看错误日志：

tail -f error.log

或查看系统日志：

tail -f system.log

如果是 Docker 部署，可以直接看容器日志：

docker logs openclaw-gateway

实时查看：

docker logs -f openclaw-gateway

从日志中通常可以看到更具体的报错，例如：

这些具体错误，才是解决 All models failed 的真正入口。

三、第二步：确认 API Key 是否有效

OpenClaw 调用 OpenAI、Anthropic、OpenRouter、DeepSeek、Ollama 网关或其他第三方模型平台时，都依赖对应平台的 API Key。如果 API Key 错误、过期、被删除、额度被停用，所有模型请求都会失败，最终汇总为 All models failed。

重点检查以下内容：

例如 OpenAI 配置通常类似：

OPENAI_API_KEY=sk-xxxx

Anthropic 配置通常类似：

OPENAI_API_KEY=sk-or-xxxx
OPENAI_API_BASE=https://openrouter.ai/api/v1

如果环境变量修改后没有重启 OpenClaw，系统仍可能读取旧值，因此改完配置后应立即重启服务。

四、第三步：检查模型名称是否正确

OpenClaw 报 All models failed 的另一个高频原因，是模型名称填写错误。模型平台通常要求模型 ID 完全匹配，哪怕只错一个字符，也会直接返回失败。

常见错误形式包括：

例如错误写法：

MODEL_NAME=gpt4

更规范的写法可能是：

MODEL_NAME=gpt-4o

如果使用 OpenRouter，还要注意模型名通常带供应商前缀，例如：

MODEL_NAME=openai/gpt-4o
MODEL_NAME=anthropic/claude-3-sonnet
MODEL_NAME=deepseek/deepseek-chat

只要主模型和备用模型名称都写错，OpenClaw 就会连续失败，最后报 All models failed。

五、第四步：检查 API Base 地址是否配置正确

很多用户在接入 OpenRouter、代理网关、本地兼容接口或企业中转服务时，会单独配置 API Base。如果 API Base 地址错误、路径不完整、协议不匹配，模型请求根本发不到目标服务，自然会全部失败。

例如常见配置：

OPENAI_API_BASE=https://openrouter.ai/api/v1

本地兼容接口示例：

OPENAI_API_BASE=http://127.0.0.1:11434/v1

常见问题包括：

可以先用 curl 直接测试接口联通性，确认基础地址不是空壳地址。

六、第五步：检查网络连接是否正常

如果 OpenClaw 服务器无法访问模型平台，即使配置完全正确，最终也会报 All models failed。特别是在云服务器、企业内网、Docker 容器、代理环境中，网络问题非常常见。

需要重点排查：

可用以下方式初步测试：

ping google.com

ping openrouter.ai

也可以直接测试接口端口连通性：

curl https://openrouter.ai/api/v1/models

如果请求超时、解析失败或返回网络错误，就需要先修复网络问题，而不是继续修改模型配置。

七、第六步：检查账户额度、计费状态和请求频率

很多平台在额度不足、信用用尽、速率超限时，不会以“余额不足”这样直白的最终提示出现在 OpenClaw 前端，而是在后台多次失败后统一汇总成 All models failed。因此，排查时必须查看平台账户状态。

典型现象包括：

这类情况往往不是 OpenClaw 自身故障，而是上游模型平台的计费或限流规则导致。

八、第七步：检查模型权限与白名单配置

某些 OpenClaw 版本、企业网关或第三方中转接口，会限制允许调用的模型范围。如果配置的模型不在允许列表中，请求虽然发送成功，但会被策略层拒绝，多个模型都被拒绝后，也会出现 All models failed。

例如某些配置可能存在：

MODEL_NAME=claude-3-opus

那么策略层会直接拒绝。

此外，一些第三方平台并不是所有模型都默认开放，有的模型需要单独开通权限或更高套餐。只要主模型、备用模型都没有权限，系统就会整体失败。

九、第八步：检查请求参数是否超限

OpenClaw 在执行任务时，可能会把历史上下文、系统提示词、工具调用信息、附件内容一起发送给模型。如果请求体过大、token 超限、max_tokens 设置不合理，平台通常会直接返回失败。

需要重点检查：

典型错误可能表现为：

此时可以尝试缩短上下文、删除部分历史记录、降低输出长度限制，再重新测试。

十、第九步：检查多模型回退配置是否全部失效

OpenClaw 为了提高稳定性，很多场景会配置主模型、默认模型、快速模型、备用模型。如果这些模型共享同一个错误来源，比如同一个错误 API Key、同一个不可访问网关、同一个错误 API Base，那么系统虽然看起来在“切换模型”，实际上只是在重复失败，最终报 All models failed。

MODEL_DEFAULT=gpt-4o
MODEL_FAST=gpt-4o-mini
MODEL_FALLBACK=claude-3-sonnet

如果这三个模型都通过同一个错误的代理地址发送请求，那么三次都会失败。

十一、第十步：手动单独测试每一个模型

排查 All models failed 时，非常有效的方法是把 OpenClaw 的复杂流程拆开，逐个手动测试模型。不要一上来就只看最终报错，而要分别验证每一个模型是否独立可用。

可以采用如下思路：

如果只有某一个模型失败，问题通常在模型本身或权限配置；如果所有模型都失败，问题更可能是统一配置、网络、认证或网关层。

这种拆分测试方法，能够快速缩小问题范围，避免在复杂配置中盲目排查。

十二、第十一步：检查 Docker、容器环境和环境变量注入

如果 OpenClaw 通过 Docker 或 Docker Compose 运行，主机上的环境变量并不一定自动进入容器。很多用户在宿主机上已经配置好了 API Key，但容器里依然是空值，结果所有模型都失败。

应重点检查：

environment:
 – OPENAI_API_KEY=sk-xxxx
 – OPENAI_API_BASE=https://openrouter.ai/api/v1
 – MODEL_NAME=openai/gpt-4o

修改完成后应执行：

docker compose restart

必要时重新创建容器：

docker compose down
docker compose up -d

否则 OpenClaw 可能仍在使用旧配置，导致持续报错。

十三、第十二步：检查本地模型服务是否真的在运行

如果 OpenClaw 接的是 Ollama、LocalAI、vLLM 等本地模型服务，All models failed 还可能说明本地推理服务没有启动、端口没监听，或者模型尚未下载完成。

例如接入 Ollama 时，需确认：

本地接口示例：

http://127.0.0.1:11434/v1

如果服务没启动，即使 OpenClaw 配置完全正确，也会因为连不上本地模型而失败。

十四、第十三步：更新 OpenClaw 与依赖组件版本

某些 All models failed 并不是配置错误，而是版本兼容问题。例如旧版 OpenClaw 不识别新模型名称，旧版 SDK 不兼容新的 API 字段，或者网关组件在升级后接口格式发生变化。此时即便模型平台可用，系统也可能因为请求结构过旧而全部失败。

如果使用 Git 部署，可以尝试更新代码：

git pull

如果使用 Docker，可以更新镜像：

docker compose pull
docker compose up -d

更新后再重新测试模型链路，很多兼容性问题会直接消失。

十五、第十四步：按优先顺序执行完整排查流程

为了提高排查效率，建议按照以下顺序逐项处理，而不是同时改很多配置：

按照这种从外到内、从基础到高级的顺序排查，通常比反复重装系统更高效，也更容易准确定位故障点。

十六、适合直接套用的修复思路

如果当前没有太多时间逐项分析，可以先采用一套高概率有效的修复动作：

比如先不要同时测多个高级模型，而是先让一个已知稳定的模型通起来。只要单模型恢复正常，再逐步恢复备用模型和复杂路由配置，能显著减少误判。

十七、避免再次出现 All models failed 的运维建议

为了减少后续再次出现 All models failed，建议在 OpenClaw 日常使用中建立更稳妥的模型管理方式。

如果是团队协作环境，还应统一管理配置文件和环境变量，防止同一套 OpenClaw 被多人改动后产生不一致配置。

十八、最终判断思路

OpenClaw 提示 All models failed，本质上不是一个单一错误，而是多个模型调用都失败后的总括性结果。真正要解决问题，必须往下拆分：是认证失败、模型不存在、接口错误、网络不可达、额度耗尽、参数超限，还是回退链配置无效。只要找到第一次失败的具体原因，后面的“全部失败”通常也就自然消失。对大多数场景来说，日志、API Key、模型名称、API Base 和网络联通性，是最值得优先检查的五个核心点。

© 2026 一万网络 | 作者: 一万网络 | 来源: 一万网络