Claude Code 配 ANTHROPIC_BASE_URL 后 404检查 /v1/messages 是否重复Claude Code 已经能启动settings.json里也写了ANTHROPIC_BASE_URL第一条消息却返回 404最容易先改的是模型名或 API Key。这个顺序不一定对404 可能发生在请求还没有进入模型路由之前真正的问题是客户端和 Base URL 各自拼了一次/v1。本文只解决一个问题Claude Code CLI 接自定义 Anthropic Messages 端点时怎样确认 Base URL 的边界以及怎样从实际请求路径判断是不是/v1/v1/messages。实测环境是Claude Code 2.1.219 (Claude Code)服务端是只监听127.0.0.1的合成夹具没有请求线上 Anthropic 或第三方 provider。先按最小路径跑一次适用环境适用于已经安装 Claude Code CLI、目标服务声称兼容 Anthropic Messages并且你能查看网关访问日志的 macOS/Linux 环境。Windows 可以把用户设置路径替换成%USERPROFILE%\\.claude\\settings.json项目级文件仍放在项目目录的.claude/下。1. 先确认你改的是哪一层Claude Code 当前 CLI 帮助列出了user、project、local三类 settings source。不要同时改三份文件后再猜优先级先只读确认路径ls-l~/.claude/settings.jsonls-l.claude/settings.json2/dev/null||truels-l.claude/settings.local.json2/dev/null||true如果需要完全隔离一次验证可以把环境变量放进一个临时 JSON再用--settings明确加载。下面的 URL 是占位符不要把真实 Key 写进仓库、截图或 shell history{env:{ANTHROPIC_BASE_URL:https://your-anthropic-compatible-endpoint.example,ANTHROPIC_AUTH_TOKEN:REDACTED,ANTHROPIC_MODEL:provider-model-id}}这里最重要的是ANTHROPIC_BASE_URL的末尾。本文的 Claude Code 版本会自己补/v1/messages因此先填服务文档规定的 API 根地址不要因为网上某个 OpenAI 示例写了/v1就原样复制到 Anthropic Messages 配置。2. 用一次最小命令观察成功信号claude--bare\--settings/tmp/claude-path-check.json\--tools\--printhello成功信号不是“CLI 启动了”而是网关访问日志出现一条POST /v1/messages并且命令能读到一个正常的 Anthropic Message 响应。失败信号是访问日志出现POST /v1/v1/messages或者网关直接返回 404。只看网页首页能否打开不能证明消息路径正确。Base URL 到底应该写到哪里把“服务根地址”和“资源路径”分开看ANTHROPIC_BASE_URL https://gateway.example Claude Code /v1/messages 实际请求 https://gateway.example/v1/messages如果把同一个端点写成https://gateway.example/v1当前版本会继续追加资源路径ANTHROPIC_BASE_URL https://gateway.example/v1 Claude Code /v1/messages 实际请求 https://gateway.example/v1/v1/messages这两条 URL 不是同一个资源。很多网关对未知路径直接返回 404所以你会误以为模型不存在。只有当目标服务文档明确要求“Base URL 已经包含/v1且客户端不会再追加”时才按它的约定填写不要把 OpenAI Chat Completions 的经验套给 Anthropic Messages 客户端。本机回环实测200 和 404 的分界内容包中的夹具只绑定127.0.0.1执行python3 06-evidence/probe_claude_base_url.py本次脱敏输出如下CLAUDE_VERSION2.1.219 (Claude Code) ROOT_SETTINGS_EXIT0 ROOT_SETTINGS_SIGNALfixture path success DUPLICATE_V1_EXIT1 DUPLICATE_V1_SIGNAL404_expected SHELL_OVERRIDE_EXIT1 SHELL_OVERRIDE_SIGNALsettings_value_won REQUESTS[ {path:/v1/messages?betatrue,status:200}, {path:/v1/v1/messages?betatrue,status:404} ] SUMMARYpass root_200 duplicate_v1_404 settings_env_precedence_observed ONLINE_PROVIDER_REQUESTNO这里的 200 只说明当前 Claude Code 把根地址拼成了/v1/messages不是某个线上 provider 已经兼容。404 分支则证明了路径重复时错误发生在路由层。夹具只记录路径、合成模型名、认证类别和状态码不记录任何凭据。三个容易误判的失败路径1. Base URL 末尾多了/v1这是本文的主问题。把配置从https://gateway.example/v1改为https://gateway.example后重新启动一次 Claude Code再看访问日志是否恢复为/v1/messages。不要只改模型名也不要用无限重试掩盖 404相同路径重复失败时重试不会改变路由。2. shell 环境变量没有覆盖 settings.json我在同一次实测中让 settings 文件写入错误的.../v1同时在启动进程里导出正确的根地址。结果仍然请求/v1/v1/messages命令退出码为 1说明在这次--settings运行里settingsenv的值胜过同名 shell 变量。这不是让你背一条永久优先级而是提醒你不要同时维护两套值。先选一个来源再用访问日志确认最终地址env|grep^ANTHROPIC_BASE_URL||truepython3-mjson.tool /tmp/claude-path-check.json如果两处值不同先清掉临时 shell 变量或改正 settings 文件再重启会话。不要把完整 Key 打到env输出或诊断截图里。3. 把 Anthropic Messages 和 OpenAI Chat Completions 混在一起Anthropic Messages 的资源路径是/v1/messages请求体和响应结构也不同于/v1/chat/completions。如果目标服务只实现 OpenAI 兼容接口把 URL 改成/v1并不会让 Claude Code 自动获得协议兼容此时可能得到 404、405、协议解析失败或网关统一错误。先查服务文档再用最小消息请求确认协议不要把“域名可访问”写成“API 已兼容”。排查顺序记录 CLI 版本claude --version。确认实际生效的 settings source不要同时编辑 user、project、local 三份配置。让ANTHROPIC_BASE_URL只保留服务根地址除非目标文档明确要求带版本路径。用--bare --settings做最小请求关闭工具、插件和额外上下文干扰。查看脱敏访问日志确认实际路径是/v1/messages再判断 401、403、404 或响应结构问题。只有路径正确且协议响应可读后才进入认证、模型 ID 或流式事件排查。安全边界示例中的REDACTED、provider-model-id和本地 fixture 值都不是可用凭据。真实 API Key 不应出现在仓库、截图、Issue 或 shell history项目级 settings 也不要提交明文密钥。本文没有请求线上 Anthropic 或任何第三方 provider回环结果不能替代你对目标服务当前文档和脱敏日志的核验。总结Claude Code 配自定义 Anthropic 端点遇到 404 时先确认请求路径再换模型或 Key。对当前2.1.219根 Base URL 会生成/v1/messagesBase URL 末尾再加/v1会生成/v1/v1/messages夹具返回 404。把配置收敛到一个 settings source用--bare --settings做最小复现并以访问日志中的真实路径作为成功信号才能把路由错误和模型、认证问题分开。