API 测试成功，Claude Code / Codex 仍连接失败？按四步核对接入

先把“请求成功”和“工具接入完成”分开验证

你用 AIGoCode 发出一次 API 请求，已经拿到回复；换到 Claude Code 或 Codex，却仍然连接失败。此时先核对成功请求与失败工具各自用了什么配置，再决定改哪一项。

一次请求成功，只能确认那一次调用的地址、认证信息和请求内容能够配合工作。它不能替你确认另一个工具当前选中的供应商、密钥分组、服务地址和模型都已配置正确。

下面按“记录成功样例 → 核对目标工具 → 对照地址与认证 → 按错误继续排查”的顺序处理。涉及安装和手动配置的具体字段，仍以链接中的当前工具文档为准。

第一步：记下成功请求究竟验证了什么

先留一份不含密钥的对照记录。不要只写“API 已经通了”，而是说明在哪个客户端、通过哪个接口、用什么模型、得到了什么结果。

无法确认的项先标注“未知”，不要根据一个成功响应推断所有项都一致。记录中只保留密钥名称或本地代号，不粘贴 API Key、认证头或带密钥的查询参数。

如果成功的是一个脚本，失败的是另一个工具，后续验证应回到失败的工具中完成。反复运行成功脚本，不能代替这一步。

第二步：按目标工具核对密钥分组和启用状态

当前 AIGoCode 的Claude Code 文档和Codex CLI 文档给出的分组与操作如下：

两份文档都建议创建密钥后，优先使用该密钥右侧的 CC Switch 入口完成一键导入，再到对应工具页面启用供应商。“导入完成”和“已启用”是需要分别核对的两步。

先确认你打开的是目标工具对应的页面，再看 AIGoCode 供应商是否已启用。不要把另一个工具页面上的启用状态当作本工具配置完成的依据，也不要据此推断不同分组的密钥可以任意互换。

如果选择手动接入，Claude Code 文档提供环境变量配置入口，Codex 文档提供配置文件入口。按当前文档核对，不猜测环境变量、配置文件与供应商切换工具之间的覆盖顺序；不清楚哪份配置生效时，先保留这一差异，避免一次改动多个位置。

第三步：分开核对服务域名、协议路径和接口路径

AIGoCode 的Base URL 文档当前列出的统一服务根地址是 https://api.aigocode.dev，协议地址为：

这张表用于区分根地址和协议地址，不是让你把同一个值填入所有工具。文档说明，很多 CLI 或桌面客户端会自行拼接协议路径或具体 endpoint，填写方式应以对应工具教程为准。

检查时把三个部分分开记录：服务域名、/v1 或 /v1beta 这样的协议路径、最终调用的接口路径。成功脚本里使用的完整请求 URL，不一定就是工具 Base URL 字段需要的值。

如果工具里保留了旧教程复制来的地址，先与当前文档对照，记录差异，再按目标工具要求修改。这里只核对当前推荐值，不据此断言某个旧域名已停用，也不把 API 服务域名与公开网站域名混用。

遇到 404 Not Found 时，Base URL 文档把 /v1 或 /v1beta 多填、少填列为常见原因。先检查路径，而不是在根地址后反复尝试拼接不同接口。

认证信息也应按该工具要求填写。核对是否选错密钥、复制不完整或填入了不对应的字段；不要把成功脚本的整套配置未经核对地搬到另一个工具。若提示模型不可用，两份工具文档建议先核对其链接的模型名称列表，再检查 API Key 和 Base URL。

每确认一项差异后，在同一工具里验证一次，记录只调整了什么、状态码或错误是否变化。

第四步：按这次实际返回的错误选择下一步

AIGoCode 的错误码说明建议先看 HTTP 状态码，再看响应体中的错误信息。“连接失败”只是界面提示时，应先找到这些细节。

这些是排查方向，单个状态码不足以证明唯一原因。错误从 401 变成 429 时，应按新的错误继续检查，不能把两次都笼统记作“没有连上”。

如果单独使用正常，一开多个任务就连续出现 429，可以继续阅读本站的多任务并行 429 排查指南，重点检查并发和重试，避免反复重配已经验证过的基础接入。

最后，在原来失败的工具里完成验证

两份工具文档都要求进入代码项目目录后启动对应工具：Claude Code 使用 claude，Codex 使用 codex；以能够正常读取项目并回复，作为接入完成的判断依据。

完成后保留一张简短记录：目标工具、密钥分组、Base URL 的填写方式、所选模型、最后一次错误，以及这次修正了哪一项。这样下一次迁移配置或更换环境时，可以按相同口径核对，而不必凭印象重试整套设置。