cc接入any时Unable to connect to API 的排查

最近any的国内站点好像因为没有续费无法请求了，于是就只能用主站链接，可是发现系统已经开启了全局代理，浏览器能访问网站，PowerShell 也能请求接口。但 Claude Code 发出消息后通常会等待很久最终报出：

text

API Error: Unable to connect to API (UNKNOWN_CERTIFICATE_VERIFICATION_ERROR)

中间尝试在配置文件里修改代理出口等等，甚至连clash也升级了一下，发现都不奏效。

鉴于any本身响应很慢，所以借助AI排查时需要区分两类请求：

/v1/models：用于验证域名、代理和鉴权，通常应在几十秒内返回。
/v1/messages 或 Claude Code 实际对话：用于验证模型调用，应至少预留 120 秒超时。

如果模型请求长时间无响应，但最终返回了 503、429 或正常内容，说明请求已经到达 AnyRouter；如果最终是 UNKNOWN_CERTIFICATE_VERIFICATION_ERROR，则应优先检查本机的 TLS 信任链。

第一层验证：AnyRouter 配置和鉴权

Claude Code 的用户配置位于：

text

C:\Users\<用户名>\.claude\settings.json

核心配置如下：

json

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://anyrouter.top",
    "ANTHROPIC_AUTH_TOKEN": "xxx",
    "ANTHROPIC_BETAS": "context-1m-2025-08-07"
  }
}

使用 PowerShell 验证 AnyRouter 的 Anthropic 兼容接口：

powershell

$headers = @{
  Authorization = "Bearer <AnyRouter API Key>"
  "anthropic-version" = "2023-06-01"
}

Invoke-RestMethod `
  -Uri "https://anyrouter.top/v1/models" `
  -Headers $headers `
  -Method Get

模型列表可以正常返回，说明：

https://anyrouter.top 可以访问。
API Key 可用。
AnyRouter 使用 Bearer 鉴权。
Anthropic 兼容接口本身正常。

模型映射应使用接口返回的实际模型 ID，例如：

json

{
  "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-5",
  "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-5-20250929",
  "ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-haiku-4-5-20251001",
  "ANTHROPIC_DEFAULT_FABLE_MODEL": "claude-fable-5",
  "CLAUDE_CODE_SUBAGENT_MODEL": "claude-opus-5"
}

不直接使用控制台页面里看见的展示名称作为模型 ID。

第二层验证：Windows 代理本身没有问题

我的 FlClash 代理运行在：

text

http://127.0.0.1:7890

可以用以下命令确认 Windows 的代理设置：

powershell

Get-ItemProperty `
  -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
  Select-Object ProxyEnable, ProxyServer

接着让 curl 显式通过代理访问 AnyRouter：

powershell

curl.exe `
  --proxy http://127.0.0.1:7890 `
  -sS -o NUL `
  -w "http=%{http_code} verify=%{ssl_verify_result}`n" `
  https://anyrouter.top/v1/models

得到的结果类似：

text

http=401 verify=0

这里的 401 是预期结果，因为 curl 请求没有提供 API Key；真正重要的是：

text

verify=0

它表示 TLS 证书校验成功。也就是说，在 curl 的运行环境中，FlClash、代理端口和到 AnyRouter 的 HTTPS 链路都没有问题。

但这一步并不能证明 Claude Code 也一定能成功。curl、PowerShell 和 Claude Code 插件不是同一个进程，也不使用完全相同的网络配置来源。

水落石出

我继续做了两个对照。首先，使用 PowerShell 携带 AnyRouter 的 Bearer Token 请求 /v1/models，可以正常获取模型列表。这排除了 API 地址错误、密钥失效，以及所有应用都无法通过代理访问 AnyRouter的可能。

但 Claude Code 插件仍然在等待较长时间后报UNKNOWN_CERTIFICATE_VERIFICATION_ERROR

到这里，问题范围被收窄为两种运行环境之间的差异：

PowerShell / curl可走系统代理，可验证证书，可访问 AnyRouter
Claude Code 插件请求失败，UNKNOWN_CERTIFICATE_VERIFICATION_ERROR

接下来确认 Claude Code 并不是复用 PowerShell 或 curl，而是使用 VS Code 插件自带的 claude.exe。这意味着它有独立的运行时和环境变量继承路径。即使 Windows 已经设置全局代理，也不能假设该进程一定会读取同一份代理配置或使用同一套系统 CA。因此没有直接关闭 TLS 校验，而是把 Claude Code 所需的两个前提显式写入配置：

json

{
  "HTTP_PROXY": "http://127.0.0.1:7890",
  "HTTPS_PROXY": "http://127.0.0.1:7890",
  "NODE_OPTIONS": "--use-system-ca"
}

前两项让 Claude Code 明确走 FlClash；--use-system-ca 则要求其内置 Node 运行时使用 Windows 系统证书库。

最后的验证也没有再使用 curl，而是直接调用插件目录中的 claude.exe 发起模型请求：

powershell

& $claudeExe `
  --model opus `
  --output-format text `
  --print "Reply with OK only."

最终终于返回OK。这一步说明：在显式指定代理并启用系统 CA 后，Claude Code 已能完成 HTTPS 连接、证书校验和模型调用。

综上所述，严格来说同时处理了代理没有继承和系统 CA 未使用两个变量，因此不能仅凭一次结果断言唯一根因就是 CA。更准确的结论是Claude Code 的独立运行时没有正确继承当前 Windows 的网络信任环境，显式提供代理配置和系统 CA 后，问题得到解决。