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

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

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

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

• 模型服务端整体不可用
• API 请求无法发出
• 认证失败
• 模型配置不合法
• 返回结果被系统判定为失败
• 多模型回退链全部失效

因此，看到这个报错时，不能只盯着单一模型，而要把 OpenClaw 的整个模型调用链一起检查。

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

排查 All models failed 的第一步永远是查看日志，因为最终错误只是一个汇总结果，真正的原因通常隐藏在每次模型调用失败的明细中。不同部署方式查看日志的方法不同。

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

cd logs
ls

常见日志文件包括：

• gateway.log
• system.log
• error.log
• worker.log

重点查看错误日志：

tail -f error.log

或查看系统日志：

tail -f system.log

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

docker logs openclaw-gateway

实时查看：

docker logs -f openclaw-gateway

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

• 401 Unauthorized
• 403 Forbidden
• 429 Too Many Requests
• Model is not allowed
• Connection timeout
• Invalid API key
• No route to host

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

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

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

重点检查以下内容：

• API Key 是否填写完整
• 环境变量是否加载成功
• 配置文件中是否有多余空格
• 是否误用了测试 Key 或旧 Key
• 是否把 Web 订阅账号误当成 API Key 使用

例如 OpenAI 配置通常类似：

OPENAI_API_KEY=sk-xxxx

Anthropic 配置通常类似：

ANTHROPIC_API_KEY=sk-ant-xxxx

OpenRouter 配置通常类似：

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

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

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

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

常见错误形式包括：

• 把 gpt-4o 写成 gpt4o
• 把 claude-3-sonnet 写成 claude-sonnet
• 把 openrouter 平台模型名写成平台外部格式
• 把已经下线的旧模型继续写在配置中

例如错误写法：

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

常见问题包括：

• 少写 /v1
• http 和 https 写反
• 写成了控制台地址而不是 API 地址
• 域名能打开网页，但接口路径不对

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

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

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

需要重点排查：

• 服务器是否能访问外网
• DNS 是否解析正常
• 是否被防火墙拦截
• 是否需要代理才能访问模型平台
• Docker 容器是否拥有外网权限

可用以下方式初步测试：

ping google.com

ping openrouter.ai

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

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

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

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

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

重点检查：

• API 账户是否还有可用余额
• 是否启用了付费权限
• 是否触发每分钟请求限制
• 是否达到每日额度上限
• 是否模型权限仅限部分套餐

典型现象包括：

• 首个请求成功，后续全部失败
• 高并发任务下频繁报错
• 同样配置昨天能用，今天突然全部失败

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

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

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

例如某些配置可能存在：

ALLOWED_MODELS=gpt-4o,claude-3-sonnet,deepseek-chat

如果你实际调用的是：

MODEL_NAME=claude-3-opus

那么策略层会直接拒绝。

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

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

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

需要重点检查：

• 输入内容是否过长
• 系统提示词是否异常膨胀
• 附件内容是否一次性塞入过多文本
• max_tokens 是否超过模型支持范围
• 是否在多轮对话中累计了过多历史记录

典型错误可能表现为：

• context length exceeded
• max tokens too large
• request too large

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

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

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，但容器里依然是空值，结果所有模型都失败。

应重点检查：

• docker-compose.yml 是否写入 environment
• .env 文件是否被正确加载
• 容器重启后是否读取了新配置
• 旧容器缓存是否仍在运行

例如：

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 时，需确认：

• Ollama 进程已经启动
• 接口端口可访问
• 目标模型已拉取完成
• OpenClaw 配置指向正确地址

本地接口示例：

http://127.0.0.1:11434/v1

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

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

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

建议检查：

• OpenClaw 是否为较旧版本
• 依赖库是否长期未更新
• 第三方模型平台是否已更改接口格式
• 本地镜像是否仍是旧版

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

git pull

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

docker compose pull
docker compose up -d

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

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

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

• 先看日志，找真实报错
• 检查 API Key 是否正确
• 确认模型名称是否准确
• 检查 API Base 地址
• 测试网络连通性
• 查看账户额度与限流状态
• 确认模型权限和白名单
• 检查输入参数是否超限
• 手动单测每个模型
• 检查 Docker 环境变量注入
• 确认本地模型服务是否在运行
• 更新 OpenClaw 和依赖版本

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

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

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

• 重新确认并替换 API Key
• 将模型名改成平台官方文档中的精确名称
• 检查 OPENAI_API_BASE 或第三方网关地址
• 重启 OpenClaw 服务或重建 Docker 容器
• 把请求内容缩短后再试一次
• 切换一个确定可用的基础模型做对照测试

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

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

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

• 不要把所有模型都绑定在同一个单点网关上
• 主模型和备用模型尽量分散到不同链路
• 定期检查 API Key 有效性和余额
• 日志级别保持可审计，方便回溯
• 模型升级前先在测试环境验证
• 避免长期使用已下线或临时模型名称

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

十八、最终判断思路

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