如何判断报错是否由 9Coding 返回

1 · 查看请求地址与 request id#

9Coding 对外有两个 API，报错格式不同。只有发往这两个地址的请求，才可能得到 9Coding 返回的报错。

推理网关 · api.9coding.com：承载全部模型调用，包括 OpenAI 兼容的 /v1/chat/completions 等端点，以及 Claude Code 使用的 /v1/messages。Key 缺失或无效时返回：

{
  "error": {
    "code": "",
    "message": "Invalid token (request id: 2026…)",
    "type": "new_api_error"
  }
}

判定依据：请求地址是 api.9coding.com，message 末尾带有 (request id: …)；Key 缺失或无效时，type 为 new_api_error。request id 以 UTC 时间开头（形如 2026…，比北京时间早 8 小时），网关响应头 x-oneapi-request-id 中也有同一个 id，用 curl -i 可以查看。部分报错（例如经 9Coding 转发的上游报错）的 message 可能不带 request id。其他中转服务若使用同一套开源网关，也会返回同样格式的报错，因此必须结合请求地址判断。

控制台 API · 9coding.com/api：承载网站与控制台的操作，包括登录、Key 管理、充值与用量查询。模型调用不经过这一 API。未登录或登录状态失效时返回：

{
  "message": "missing bearer token",
  "success": false
}

判定依据：message 与 success 两个字段并列，success 为 false。这类报错出现在网站与控制台的请求中（例如浏览器开发者工具的网络面板），与模型调用无关；登录状态失效时，重新登录控制台即可恢复。

2 · 对照第三方报错的特征#

以下只列出格式明确、可据此判断来源的几种。

• Browserbase：Missing x-bb-api-key header
  特征：statusCode、error、message 三个字段并列；x-bb-api-key 是云端浏览器服务 Browserbase 的认证请求头。
  处理：为 Browserbase 配置其自身的 Key，见下文。
• OpenAI 官方 API：Incorrect API key provided
  特征：报错指向 platform.openai.com，code 为 invalid_api_key。
  处理：请求直接发往了 OpenAI 官方；将 base URL 设为 https://api.9coding.com/v1。
• Anthropic 官方 API："request_id":"req_…"
  特征：顶层带有 request_id 字段，取值以 req_ 开头；message 末尾没有 (request id: …)。
  处理：请求直接发往了 Anthropic 官方，未经过 9Coding；检查 ANTHROPIC_BASE_URL 是否生效。
• Google 官方 API：API key not valid
  特征：Google 官方 API（如 Gemini API）的报错，带有 "status":"INVALID_ARGUMENT"，details 中的 reason 为 API_KEY_INVALID。
  处理：请求直接发往了 Google 官方，需找出发出这一请求的工具。Gemini CLI 按 Gemini 接入指南设置 GOOGLE_GEMINI_BASE_URL；其他直接调用 Google 的工具（例如 Browserbase 的 MCP 服务，见下文）需要 Google 的 Key。
• 客户端本身：Could not resolve authentication method
  特征：客户端在发出请求之前报错，没有 HTTP 响应。
  处理：设置 ANTHROPIC_AUTH_TOKEN，见 401 Unauthorized。
• 本机或网络：ECONNREFUSED · ENOTFOUND · ETIMEDOUT
  特征：没有状态码，也没有响应体。
  处理：见连接错误。

Key 已发送给第三方时：OpenAI、Anthropic、Google 这三种情况下，若请求携带的是 9Coding 的 Key（例如 OpenAI 报错中回显的 Key 以 sk-9c- 开头），这把 Key 已经发送给了对方。修正地址后，建议在 9Coding 控制台删除这把 Key 并重新创建。

3 · 用一条 curl 请求确认 9Coding 一侧#

范例沿用 Claude Code 的变量。这里使用的必须是出错工具实际配置的那把 Key；其他客户端把变量替换为该工具中填写的 Key。

curl -s https://api.9coding.com/v1/models \
  -H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN"

curl.exe -s https://api.9coding.com/v1/models `
  -H "Authorization: Bearer $env:ANTHROPIC_AUTH_TOKEN"

• 返回模型列表 → 这把 Key 与地址有效。原报错若带 (request id: …)，或属于模型不存在、限流、余额不足、上下文超限等情况，仍由 9Coding 一侧返回，按报错速查中的对应页面排查；原报错若是认证类报错且不带 9Coding 的特征，则来自工具链中的其他服务，按第 2 步确认返回方。
• 返回带 (request id: …) 的报错 → 由 9Coding 返回。Invalid token 表示这把 Key 无效，或请求中没有 Key（变量为空时同样返回这一条），见 401 Unauthorized；其他内容按报错速查中的对应页面排查。
• 没有任何输出 → curl 未取得响应，属于网络问题，见连接错误。