LLM Wiki

Appearance

Built 26/04/16 06:15commit dacb639

OpenClaw Provider Endpoint DNS Failures ​

中文 | English

摘要 ​

报错 LLM request failed: DNS lookup for the provider endpoint failed. 指向的是 provider endpoint 解析失败，而不是一个泛泛的模型问题。在实际观察到的 OpenClaw 环境里，真正有效的修复路径是去检查 ~/.openclaw/openclaw.json 里的当前 provider 配置，确认默认模型到底被指向了哪个 endpoint。

现象 ​

OpenClaw 报出：

text
LLM request failed: DNS lookup for the provider endpoint failed.

这个症状很容易被理解成“GPT 出问题了”，但真正可操作的层面其实是 provider endpoint 配置。

根因模式 ​

当模型别名和 provider 配置之间发生漂移，或者当前配置的 endpoint 本身写错、不可达、或者在运行环境里无法解析时，请求会在模型执行前就卡死在 DNS 解析阶段。

在这次检查到的配置里，GPT 侧模型路径是通过 ~/.openclaw/openclaw.json 中的自定义 provider block 控制的：

json
"models": {
  "mode": "replace",
  "providers": {
    "openai-codex": {
      "api": "openai-codex-responses",
      "baseUrl": "https://chatgpt.com/backend-api"
    }
  }
}

同时默认模型被指到：

json
"agents": {
  "defaults": {
    "model": {
      "primary": "openai-codex/gpt-5.4"
    }
  }
}

如何确认 ​

  • 不要只靠 UI 猜，直接读 ~/.openclaw/openclaw.json。
  • 看当前默认模型到底归属于哪个 provider block。
  • 检查 provider 的 baseUrl，确认这个 endpoint 才是运行时真正会打到的地址。
  • 对照 .bak 快照，看 provider override 是否正是修复过程中引入的改动。

修复思路 ​

不要把它当成笼统的“GPT 挂了”，而要沿着配置链往下查：

  1. 先确认当前默认模型别名。
  2. 再确认这个别名归哪个 provider 管。
  3. 检查 openclaw.json 里的 provider endpoint。
  4. 把 provider 配置修到默认模型最终指向一个可解析的 endpoint。

在这次实际环境里，修复后的活跃状态是：使用自定义 openai-codex provider，把 baseUrl 设为 https://chatgpt.com/backend-api，并把默认模型切到 openai-codex/gpt-5.4。

实践意义 ​

遇到 provider 层故障时，关键问题不是“我们本来想用哪个 GPT 模型”，而是“当前活跃 provider 配置让运行时实际去请求哪个 endpoint”。

相关页面 ​