Claude Code 走 OpenAI 兼容模式而非 /v1/messages 的 6 大原因（NPM 版本完整排查指南）

作者注：NPM 安裝的 Claude Code 應該走原生 /v1/messages 接口，但實際請求卻是 /v1/chat/completions？本文從官方機制出發分析 6 大可能原因，並給出 5 步快速診斷方案和 API易接入的正確配置示例。

按官方文檔，從 NPM 安裝的 @anthropic-ai/claude-code 在命令行環境下應該始終向 /v1/messages 端點發送請求——這是 Anthropic 原生的 Messages API 協議，包含 anthropic-version 請求頭和原生的 messages 格式。

但你的客戶實際抓包看到的卻是 /v1/chat/completions（OpenAI Chat Completions 格式）——這說明在某個環節出現了協議轉換或包名混淆。這不是 Claude Code 本身的 Bug，而是 6 類常見配置/環境問題之一。

核心價值: 本文將完整分析這 6 類原因（包括誤裝第三方包、ANTHROPIC_BASE_URL 指向兼容網關、claude-code-router 攔截轉換等），提供 5 步快速診斷方案，並給出通過 API易 apiyi.com 接入時確保走原生 /v1/messages 的正確配置示例。

一、Claude Code 默認應該走 /v1/messages：核心機制解讀

在動手排查之前，先明確官方 Claude Code 的預期行爲，才能判斷哪裏出了問題。

1.1 官方 @anthropic-ai/claude-code 的協議設計

Anthropic 官方維護的 @anthropic-ai/claude-code NPM 包，在所有版本中都只使用 Anthropic 原生 Messages API 協議，具體表現：

維度	官方 Claude Code 行爲
請求端點	`POST {ANTHROPIC_BASE_URL}/v1/messages`
請求頭	`x-api-key`、`anthropic-version: 2023-06-01`、`anthropic-beta`
請求體格式	`{ "model": "..."， "messages": [...]， "system": "..."， "max_tokens": ... }`
響應格式	`{ "content": [...]， "stop_reason": "..."， "usage": {...} }`
流式響應	SSE 事件流，事件類型如 `message_start`、`content_block_delta`

如果你的客戶抓包看到 /v1/chat/completions、Authorization: Bearer ...、請求體含 choices 數組——這些都是 OpenAI 協議特徵，說明請求走的不是官方 Claude Code 應有的路徑。

1.2 關鍵環境變量的正確語義

官方 Claude Code 只識別以下幾個環境變量來調整 API 行爲：

# 必填：Anthropic API Key 或兼容服務的 Key
ANTHROPIC_AUTH_TOKEN=sk-your-key
# 或同義變量：
ANTHROPIC_API_KEY=sk-your-key

# 可選：自定義 API 網關地址（不要帶 /v1 後綴）
ANTHROPIC_BASE_URL=https://api.anthropic.com

# 可選：自定義模型 ID
ANTHROPIC_MODEL=claude-sonnet-4-5
ANTHROPIC_SMALL_FAST_MODEL=claude-haiku-4-5

注意：官方 Claude Code 沒有 OPENAI_BASE_URL、CLAUDE_CODE_USE_OPENAI 這類變量。如果你的環境裏出現這些變量名，說明用了第三方 wrapper。

💡 快速驗證建議：在終端執行 which claude 查看 Claude Code 安裝路徑，然後執行 cat $（which claude） | head -20，如果看到 @anthropic-ai/claude-code 字樣，說明裝的是官方版本。如果看到 openclaude、claudex、cli-agent-openai-adapter 等關鍵詞，就找到根因了。

二、Claude Code 走 OpenAI 兼容模式的 6 大可能原因

按出現概率從高到低排列，建議按順序排查。

2.1 原因一：誤裝了第三方 OpenAI Wrapper 包（約 35% 案例）

NPM 上存在多個名字相似但功能完全不同的"Claude Code"包，專門做 OpenAI 兼容轉換。客戶可能誤裝了其中之一：

包名	實際功能	默認協議
`@anthropic-ai/claude-code`	✅ 官方包	`/v1/messages`
`@gitlawb/openclaude`	OpenAI shim	`/v1/chat/completions`
`@aryanjsx/openclaude`	OpenAI shim	`/v1/chat/completions`
`cli-agent-openai-adapter`	協議轉換器	`/v1/chat/completions`
`claude-code-openai-wrapper`	雙協議 wrapper	兩者都支持
`claudex`	Go 寫的 OpenAI 代理	`/v1/chat/completions`

排查方法：

# 1. 查看實際安裝路徑
which claude
# 輸出示例：/usr/local/bin/claude

# 2. 查看包的 package.json 中的 name
cat $（npm root -g）/@anthropic-ai/claude-code/package.json 2>/dev/null | grep '"name"'

# 3. 查看全局已安裝的所有 claude 相關包
npm list -g --depth=0 | grep -i claude

如果 npm list 沒有 @anthropic-ai/claude-code，但有其他類似名字的包，就是誤裝。

2.2 原因二：配置了 claude-code-router 等路由工具（約 25% 案例）

claude-code-router（CCR）是社區流行的開源工具，專門攔截 Claude Code 請求並轉發到不同模型（如 OpenAI、DeepSeek、智譜）。其工作原理：

啓動一個本地代理服務器（默認 http://localhost:3456）
用戶把 ANTHROPIC_BASE_URL 指向這個本地代理
CCR 接收到 /v1/messages 請求後，翻譯成 /v1/chat/completions 轉發到目標模型
抓包看到的就是 OpenAI 協議

排查方法：

# 檢查環境變量
env | grep -i ANTHROPIC

# 如果看到類似 ANTHROPIC_BASE_URL=http://localhost:3456 或 http://127.0.0.1:xxx
# 大概率是 CCR / claude-code-router 等本地代理

2.3 原因三：ANTHROPIC_BASE_URL 指向 OpenAI 兼容網關（約 20% 案例）

某些 LLM 網關（如 LiteLLM Proxy、OneAPI、Bifrost）雖然支持配置 Anthropic 模型，但只暴露 /v1/chat/completions 接口。如果客戶把 ANTHROPIC_BASE_URL 指向這種網關：

Claude Code 仍然按 /v1/messages 發請求
網關返回 404 或自動 rewrite 路徑
網關內部轉換成 OpenAI 格式調用上游
抓包工具如果是在網關之後部署，看到的就是 OpenAI 協議

排查方法：檢查 ANTHROPIC_BASE_URL 是否是已知的 OpenAI 兼容網關地址，請求是否實際成功（200 還是 404）。

2.4 原因四：設置了第三方 Wrapper 的環境變量（約 10% 案例）

某些 wrapper 包通過環境變量切換協議模式，例如：

# openclaude 的切換變量
CLAUDE_CODE_USE_OPENAI=1
OPENAI_API_KEY=sk-xxx
OPENAI_MODEL=gpt-4o
OPENAI_BASE_URL=https://api.openai.com/v1

即使 npm 裝的是官方包，如果 PATH 中有 wrapper 腳本（如 /usr/local/bin/claude 實際是 wrapper），這些變量也會生效。

排查方法：

# 列出所有 PATH 中名爲 claude 的可執行文件
type -a claude

# 檢查是否有相關環境變量
env | grep -E 'CLAUDE_CODE|OPENAI_BASE_URL|OPENAI_MODEL'

2.5 原因五：Shell alias 或 wrapper 腳本攔截（約 7% 案例）

客戶可能在 ~/.bashrc / ~/.zshrc 中配置了 alias：

# 這種 alias 會讓原始 claude 命令被替換
alias claude='openclaude'
alias claude='claude-code-router run'

# 或定義了同名函數
claude（） {
  CCR_PROXY=http://localhost:3456 command claude "$@"
}

排查方法：

# 查看 alias
alias | grep claude

# 查看 function
type claude

# 查看 shell 啓動文件
grep -nE 'claude' ~/.bashrc ~/.zshrc ~/.profile 2>/dev/null

2.6 原因六：抓包視角誤判（約 3% 案例）

少數情況下，客戶的抓包工具部署位置不對，看到的請求並不是 Claude Code 實際發出的。例如：

Claude Code → 本地透明代理（如 mitmproxy）→ 遠程 OpenAI 網關
抓包工具部署在網關之後，看到的是網關重寫後的請求
實際上 Claude Code 發的就是 /v1/messages

排查方法：在客戶機器本地用 mitmproxy 直接代理 Claude Code 進程，確認它發出的第一跳請求是什麼協議。

三、5 步快速診斷 Claude Code 協議異常

按以下順序逐項檢查，絕大多數協議異常都能在前 3 步內定位。

3.1 第一步：確認安裝的是官方 NPM 包

# 卸載所有可能的 wrapper
npm uninstall -g @gitlawb/openclaude @aryanjsx/openclaude cli-agent-openai-adapter claudex claude-code-router 2>/dev/null

# 卸載並重裝官方包
npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code

# 驗證版本來源
claude --version
npm list -g @anthropic-ai/claude-code

通過條件：npm list -g 輸出包含 @anthropic-ai/[email protected]。

3.2 第二步：清理 PATH 和 Shell alias

# 找出所有 PATH 中名爲 claude 的可執行文件
type -a claude
which -a claude

# 取消同名 alias / function
unalias claude 2>/dev/null
unset -f claude 2>/dev/null

# 檢查並清理 shell 啓動腳本中的 claude 相關配置
grep -n 'claude' ~/.bashrc ~/.zshrc ~/.profile 2>/dev/null

通過條件：type -a claude 只輸出一個路徑，且指向 npm 全局目錄下的官方包。

3.3 第三步：清理衝突的環境變量

# 查看所有 claude / openai 相關變量
env | grep -iE 'claude|openai|anthropic'

# 清理可能衝突的變量
unset CLAUDE_CODE_USE_OPENAI
unset OPENAI_BASE_URL
unset OPENAI_MODEL
unset CCR_PROXY

# 只保留官方需要的變量
export ANTHROPIC_BASE_URL="https://vip.apiyi.com"
export ANTHROPIC_AUTH_TOKEN="sk-your-apiyi-key"

🎯 關鍵提醒：ANTHROPIC_BASE_URL 應填到域名根（不帶 /v1 後綴），Claude Code 會自動拼接 /v1/messages。如果填了 https://vip.apiyi.com/v1，會拼成 https://vip.apiyi.com/v1/v1/messages，導致 404。

3.4 第四步：測試 base_url 是否原生支持 /v1/messages

直接用 curl 模擬 Claude Code 的請求，驗證網關是否真的支持 Anthropic 原生協議：

curl -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5"，
    "max_tokens": 100，
    "messages": [{"role": "user"， "content": "Hello"}]
  }'

通過條件：返回 200，響應體包含 "type": "message" 和 "content": [...]。

如果返回 404 或響應體是 OpenAI 格式（含 choices），說明 ANTHROPIC_BASE_URL 指向的網關不支持原生 Anthropic 協議。這時切換到 API易 apiyi.com 即可立即解決——它原生支持 /v1/messages，也兼容 /v1/chat/completions，雙協議都能用。

3.5 第五步：本地抓包驗證最終請求

如果前 4 步都通過但仍有問題，用 mitmproxy 本地抓包驗證：

# 啓動 mitmproxy（默認端口 8080）
mitmproxy --listen-port 8080

# 讓 Claude Code 走本地代理
export HTTPS_PROXY=http://localhost:8080
export HTTP_PROXY=http://localhost:8080

# 啓動 Claude Code
claude

通過條件：mitmproxy 抓到的第一個請求是 POST /v1/messages，請求頭含 anthropic-version。

四、通過 API易接入 Claude Code 走原生 /v1/messages 的完整配置

API易 apiyi.com 是少數幾個原生支持 Anthropic Messages API 協議的中轉服務，可以確保 Claude Code 走 /v1/messages 而非 /v1/chat/completions。

4.1 環境變量配置（最簡方式）

# macOS / Linux
export ANTHROPIC_BASE_URL="https://vip.apiyi.com"
export ANTHROPIC_AUTH_TOKEN="sk-your-apiyi-key"
# 可選：指定默認模型
export ANTHROPIC_MODEL="claude-sonnet-4-5"
export ANTHROPIC_SMALL_FAST_MODEL="claude-haiku-4-5"

# Windows PowerShell
$env:ANTHROPIC_BASE_URL = "https://vip.apiyi.com"
$env:ANTHROPIC_AUTH_TOKEN = "sk-your-apiyi-key"

# 啓動 Claude Code
claude

4.2 持久化配置到 Shell 啓動文件

# 追加到 ~/.zshrc 或 ~/.bashrc
cat >> ~/.zshrc <<'EOF'

# Claude Code → API易 apiyi.com 中轉配置
export ANTHROPIC_BASE_URL="https://vip.apiyi.com"
export ANTHROPIC_AUTH_TOKEN="sk-your-apiyi-key"
export ANTHROPIC_MODEL="claude-sonnet-4-5"
EOF

# 重新加載
source ~/.zshrc

4.3 通過 Claude Code 內置配置命令（推薦）

Claude Code 自身提供了配置 CLI，避免環境變量泄漏：

# 方式一：交互式
claude /login
# 選擇 "Custom Endpoint"，填入 https://vip.apiyi.com 和 API Key

# 方式二：直接修改配置文件
cat > ~/.claude/settings.json <<'EOF'
{
  "env": {
    "ANTHROPIC_BASE_URL": "https://vip.apiyi.com"，
    "ANTHROPIC_AUTH_TOKEN": "sk-your-apiyi-key"
  }
}
EOF

4.4 驗證配置後的實際請求路徑

啓動 Claude Code 後，新開一個終端用以下命令驗證：

# 方式一：通過 mitmproxy 抓包（最準確）
mitmproxy --listen-port 8080
# 另一個終端啓動 Claude Code 時設置 HTTPS_PROXY=http://localhost:8080

# 方式二：開啓 Claude Code 的 debug 日誌
ANTHROPIC_LOG=debug claude
# 日誌中會顯示完整的請求 URL 和方法

預期結果：所有請求 URL 都是 https://vip.apiyi.com/v1/messages，方法 POST，請求頭含 anthropic-version: 2023-06-01。

4.5 API易接入的核心優勢

優勢	說明
原生 /v1/messages 支持	Claude Code 默認協議，零轉換損耗
同時支持 /v1/chat/completions	一個 Key 兩種協議，靈活適配
完整保留 anthropic-beta 頭	支持 prompt caching、tool use 等高級特性
不限併發	Claude Code 長會話場景不被限流
充值 100 美金送 10%	相當於官網 85 折
國內人民幣充值	微信/支付寶直接支付

五、原生 /v1/messages vs OpenAI /v1/chat/completions 協議對比

理解兩種協議的核心差異，才能判斷爲什麼 Claude Code 必須走原生協議才能發揮完整能力。

維度	Anthropic /v1/messages	OpenAI /v1/chat/completions
認證頭	`x-api-key: sk-...`	`Authorization: Bearer sk-...`
版本頭	`anthropic-version: 2023-06-01`	無（用 URL 版本號）
特性頭	`anthropic-beta: prompt-caching-...`	無統一標準
system 字段	頂層獨立字段	作爲 `messages[0]` 的 system role
響應格式	`{ "content": [...]， "stop_reason": "..." }`	`{ "choices": [{ "message": {...} }] }`
流式事件	`message_start`、`content_block_delta` 等結構化事件	`data: {...}` 通用 SSE
工具調用	在 content blocks 中嵌入 `tool_use`	`choices[0].message.tool_calls`
token 計數	`usage.input_tokens` / `usage.output_tokens`	`usage.prompt_tokens` / `usage.completion_tokens`

關鍵結論：Claude Code 大量使用 Anthropic 獨有特性（prompt caching、tool_use 流式增量、reasoning content 等），如果被強制轉換成 OpenAI 協議，會丟失這些能力或行爲不一致。這就是爲什麼必須確保它走原生 /v1/messages。

六、各使用場景排查清單

6.1 場景一：個人開發者本地使用

最常見原因：Shell alias 或 PATH 中有同名 wrapper

排查清單：

npm list -g 是否包含 @anthropic-ai/claude-code
type -a claude 是否只指向官方包
~/.zshrc / ~/.bashrc 是否有 alias claude=...
env | grep -i claude 是否有非標準變量
ANTHROPIC_BASE_URL 是否填寫了 /v1 後綴（應不帶）

6.2 場景二：團隊/公司環境部署

最常見原因：內部 LLM 網關只支持 OpenAI 協議

排查清單：

公司網關是否原生支持 /v1/messages 端點
網關是否轉發 anthropic-version、anthropic-beta 請求頭
網關是否保留 SSE 事件原始格式
是否有團隊統一的 wrapper 腳本

如果公司網關確實只支持 OpenAI 協議，建議把客戶端的 ANTHROPIC_BASE_URL 改爲指向 API易 apiyi.com，原生協議直通，避免轉換損耗。

6.3 場景三：CI/CD 環境調用 Claude Code

最常見原因：CI 腳本中固化了第三方 wrapper

排查清單：

CI 配置文件是否 npm install -g 了非官方包
CI 環境變量是否有 CLAUDE_CODE_USE_OPENAI=1 等
CI runner 鏡像是否預裝了 wrapper

6.4 場景四：Docker 容器內運行

最常見原因：基礎鏡像預裝了 wrapper

排查清單：

Dockerfile 中 RUN npm install -g 的包名是否官方
容器內 which claude 指向哪裏
容器的 ENV 是否設置了協議切換變量

七、Claude Code 協議異常常見問題 FAQ

Q1: 我裝的就是官方 @anthropic-ai/claude-code，爲什麼還會走 OpenAI 協議？

最可能的原因是 ANTHROPIC_BASE_URL 指向了 OpenAI 兼容網關。某些網關接收到 /v1/messages 請求後會內部轉換成 /v1/chat/completions 調用上游，如果你抓包工具部署在網關之後，看到的就是轉換後的協議。

解決方案是把 ANTHROPIC_BASE_URL 改爲指向 API易 apiyi.com，原生支持 /v1/messages，無任何轉換損耗。

Q2: 如何徹底卸載所有可能的 Claude wrapper？

# 列出所有 claude 相關全局包
npm list -g --depth=0 | grep -i claude

# 一次性卸載已知 wrapper
npm uninstall -g \
  @gitlawb/openclaude \
  @aryanjsx/openclaude \
  cli-agent-openai-adapter \
  claudex \
  claude-code-router \
  ccr \
  2>/dev/null

# 重裝官方包
npm install -g @anthropic-ai/claude-code

# 驗證
which claude
claude --version

Q3: ANTHROPIC_BASE_URL 應該填到什麼級別的路徑？

填到域名根，不要帶 /v1 後綴。Claude Code 內部會自動拼接 /v1/messages。

# ✅ 正確
export ANTHROPIC_BASE_URL="https://vip.apiyi.com"

# ❌ 錯誤（會拼成 /v1/v1/messages）
export ANTHROPIC_BASE_URL="https://vip.apiyi.com/v1"

# ❌ 錯誤（自帶端點路徑）
export ANTHROPIC_BASE_URL="https://vip.apiyi.com/v1/messages"

Q4: 爲什麼有些教程讓我裝 claude-code-router？

claude-code-router 是社區工具，主要用途是讓 Claude Code 調用非 Anthropic 模型（如 DeepSeek、智譜、本地 Ollama 等）。它通過協議轉換實現。

如果你只是想用 Anthropic 原版 Claude 模型（如 Claude Sonnet 4.5、Opus 4.7），完全不需要 CCR，直接接入 API易 apiyi.com 走原生 /v1/messages 即可，體驗更好、無轉換損耗。

Q5: API易 apiyi.com 同時支持 /v1/messages 和 /v1/chat/completions 嗎？

是的，API易完全兼容兩種協議：

https://vip.apiyi.com/v1/messages —— Anthropic 原生格式（Claude Code 默認）
https://vip.apiyi.com/v1/chat/completions —— OpenAI 兼容格式

一個 API Key 可以同時使用兩種協議，根據客戶端工具自動適配。

Q6: 抓包看到的請求 URL 是 https://vip.apiyi.com/v1/messages 就一定是原生模式嗎？

不一定。需要同時驗證：

請求頭含 anthropic-version: 2023-06-01
請求體頂層有 messages 數組和獨立的 system 字段（不是 messages 內含 system role）
響應體含 "type": "message" 和 content: [...]（不是 choices: [...]）

如果 URL 是 /v1/messages 但請求體是 OpenAI 格式（含 system role 在 messages 內），說明客戶端有自己的轉換層。

Q7: Claude Code 啓用 debug 日誌的環境變量是什麼？

# 輸出詳細的 HTTP 請求/響應日誌
ANTHROPIC_LOG=debug claude

# 或用 verbose 模式
claude --verbose

# 查看 Claude Code 自身的診斷信息
claude /doctor

debug 日誌會顯示完整的 URL、請求頭、請求體（敏感字段會脫敏），是定位協議問題最直接的方法。

Q8: 我的 Claude Code 之前一直正常，最近突然變成 OpenAI 協議了，可能是什麼原因？

最常見的幾個突變原因：

升級了 Claude Code 但 npm install -g 誤裝了同名第三方包
團隊最近部署了 LLM 網關並下發了新的 ANTHROPIC_BASE_URL
macOS 升級後某些 alias 重新生效
公司啓用了透明代理做協議轉換審計

排查時優先查看最近一次環境變化（npm 安裝記錄、shell 配置改動、網關變更通知）。

八、Key Takeaways 核心要點

✅ 官方 @anthropic-ai/claude-code 永遠使用 /v1/messages，沒有官方的 OpenAI 兼容模式
✅ 6 大可能原因（按概率）：誤裝第三方包 / claude-code-router 攔截 / base_url 指向 OpenAI 網關 / 第三方環境變量 / Shell alias / 抓包視角誤判
✅ 5 步快速診斷：確認包名 → 清理 PATH/alias → 清理環境變量 → curl 測試 base_url → 本地抓包驗證
✅ ANTHROPIC_BASE_URL 不要帶 /v1 後綴，Claude Code 會自動拼接
✅ API易 apiyi.com 原生支持 /v1/messages，同時兼容 /v1/chat/completions，一個 Key 雙協議
✅ 走原生協議的好處：完整支持 prompt caching、tool_use、reasoning content 等 Anthropic 獨有特性
✅ 快速驗證方法：ANTHROPIC_LOG=debug claude 查看實際請求 URL 和方法

九、總結

NPM 安裝的 Claude Code 在命令行環境下應該始終走原生 /v1/messages 協議——這是官方 @anthropic-ai/claude-code 包的硬編碼行爲，沒有任何官方開關可以切換到 OpenAI 兼容模式。如果客戶實際抓包看到的是 /v1/chat/completions，問題一定出在客戶端環境的某個環節：要麼誤裝了第三方 wrapper，要麼 ANTHROPIC_BASE_URL 指向了只支持 OpenAI 協議的網關，要麼 Shell alias / 環境變量做了攔截轉換。

按本文第三章的 5 步診斷流程順序排查，絕大多數問題都能在 10 分鐘內定位。最常見的解決方案就是：卸載所有非官方包 → 重裝 @anthropic-ai/claude-code → 把 ANTHROPIC_BASE_URL 指向原生支持 /v1/messages 的中轉服務。

API易 apiyi.com 是爲這種場景設計的——原生支持 Anthropic Messages API（含 anthropic-version、anthropic-beta 頭完整透傳），同時兼容 OpenAI Chat Completions（一個 Key 雙協議），不限併發（Claude Code 長會話不被限流），充值 100 美金送 10%（相當於官網 85 折），人民幣充值（微信/支付寶直接支付）。配置只需把 ANTHROPIC_BASE_URL 設爲 https://vip.apiyi.com 即可，無需任何代碼改動。

🎯 下一步行動建議：讓客戶按本文 3.1 → 3.2 → 3.3 順序排查，並把 ANTHROPIC_BASE_URL 改爲 https://vip.apiyi.com，重新啓動 Claude Code 後用 ANTHROPIC_LOG=debug claude 驗證請求 URL 是否回到 /v1/messages。

參考資料

Claude Code 官方文檔：LLM Gateway 配置說明
- 鏈接: code.claude.com/docs/en/llm-gateway
- 說明: 官方文檔明確說明 Claude Code 使用 Anthropic Messages API 格式
@anthropic-ai/claude-code NPM 包：官方 NPM 包頁面
- 鏈接: npmjs.com/package/@anthropic-ai/claude-code
- 說明: 驗證你安裝的是官方包
Anthropic Messages API 官方文檔：原生協議規範
- 鏈接: docs.anthropic.com/en/api/messages
- 說明: /v1/messages 端點的完整字段、請求頭、響應格式
API易官網：原生 Anthropic 協議中轉服務
- 鏈接: apiyi.com
- 說明: 原生 /v1/messages + 兼容 /v1/chat/completions、不限併發、充值 100 美金送 10%

作者: 技術團隊
最後更新: 2026-05-02
關於 API易: API易 apiyi.com 是專業的 Claude API 中轉服務商，原生支持 Anthropic Messages API（/v1/messages，含 anthropic-version、anthropic-beta 完整透傳），同時兼容 OpenAI Chat Completions（/v1/chat/completions）。提供 Claude Sonnet 4.5、Claude Opus 4.7、Claude Haiku 4.5 全系列穩定接入，充值 100 美金贈送 10%（相當於官網 85 折），不限併發，技術支持響應快。

一、Claude Code 默認應該走 /v1/messages：核心機制解讀

1.1 官方 @anthropic-ai/claude-code 的協議設計

1.2 關鍵環境變量的正確語義

二、Claude Code 走 OpenAI 兼容模式的 6 大可能原因

2.1 原因一：誤裝了第三方 OpenAI Wrapper 包（約 35% 案例）

2.2 原因二：配置了 claude-code-router 等路由工具（約 25% 案例）

2.3 原因三：ANTHROPIC_BASE_URL 指向 OpenAI 兼容網關（約 20% 案例）

2.4 原因四：設置了第三方 Wrapper 的環境變量（約 10% 案例）

2.5 原因五：Shell alias 或 wrapper 腳本攔截（約 7% 案例）

2.6 原因六：抓包視角誤判（約 3% 案例）

三、5 步快速診斷 Claude Code 協議異常

3.1 第一步：確認安裝的是官方 NPM 包

3.2 第二步：清理 PATH 和 Shell alias

3.3 第三步：清理衝突的環境變量

3.4 第四步：測試 base_url 是否原生支持 /v1/messages

3.5 第五步：本地抓包驗證最終請求

四、通過 API易接入 Claude Code 走原生 /v1/messages 的完整配置

4.1 環境變量配置（最簡方式）

4.2 持久化配置到 Shell 啓動文件

4.3 通過 Claude Code 內置配置命令（推薦）

4.4 驗證配置後的實際請求路徑

4.5 API易接入的核心優勢

五、原生 /v1/messages vs OpenAI /v1/chat/completions 協議對比

六、各使用場景排查清單

6.1 場景一：個人開發者本地使用

6.2 場景二：團隊/公司環境部署

6.3 場景三：CI/CD 環境調用 Claude Code

6.4 場景四：Docker 容器內運行

七、Claude Code 協議異常常見問題 FAQ

Q1: 我裝的就是官方 @anthropic-ai/claude-code，爲什麼還會走 OpenAI 協議？

Q2: 如何徹底卸載所有可能的 Claude wrapper？

Q3: ANTHROPIC_BASE_URL 應該填到什麼級別的路徑？

Q4: 爲什麼有些教程讓我裝 claude-code-router？

Q5: API易 apiyi.com 同時支持 /v1/messages 和 /v1/chat/completions 嗎？

Q6: 抓包看到的請求 URL 是 https://vip.apiyi.com/v1/messages 就一定是原生模式嗎？

Q7: Claude Code 啓用 debug 日誌的環境變量是什麼？

Q8: 我的 Claude Code 之前一直正常，最近突然變成 OpenAI 協議了，可能是什麼原因？

八、Key Takeaways 核心要點

九、總結

參考資料

Similar Posts