最近很多人在折腾 Clawdbot 对接 MiniMax,无非是想着用 MiniMax 的模型跑 Claude Code 那一套工作流,省点 API 费用,或者换个模型试试手。结果理想很丰满,现实很骨感,配置完一发请求就给你甩来一行红字:
code复制401 token is unusable (1004)
我第一次看到这个报错也愣了半天。“token is unusable”到底是在说哪个 token?后面括号里的 1004 又是什么暗号?更诡异的是,有时候报错还会变成 {"code":1004,"error":"domain forbidden"},或者干脆是 401 invalid token。同一个问题,不同工具显示的措辞还不一样,这就很容易把人带偏。
这篇文章我想把我踩坑、定位、修复的完整过程写下来。主要是 Clawdbot 对接 MiniMax 的 401 问题,但 Codex、OpenClaw 这类同样走 Anthropic 兼容接口的 CLI 工具,遇到的基本是同一套问题,排查思路可以直接照搬。适合所有打算把终端 AI 编程助手接到 MiniMax 账号上,却卡在认证这一关的人。
1. 报错现场还原:同一条 401,三种不同的脸
1.1 Clawdbot 里最常看到的报错形态
先说我在 Clawdbot 里第一次触发这个报错的具体场景。我按照网上教程配好了环境变量,指向 MiniMax 的兼容接口,模型名也填了,兴冲冲敲下第一条指令,结果终端里直接打出:
code复制Error: 401 token is unusable (1004)
没有任何请求详情,没有响应体,就这一句话。我去翻日志也没找到比这更多的信息。一开始我以为是 Clawdbot 自己的 token 失效了,于是重新登录、重新生成,折腾了半天,问题依旧。
后来我用调试模式跑了一遍,才看到完整链路:Clawdbot 把请求发到了 MiniMax 的 Anthropic 兼容端点,MiniMax 网关返回的是 {"code":1004,"error":"domain forbidden"},然后 Clawdbot 把 401 状态码翻译成了一句简短的 token is unusable,括号里把上游错误码 1004 保留了下来。
这里要提醒一句:报错文案里的 “token is unusable” 并不一定是 MiniMax 的原始返回,而是 Clawdbot 对 401 的统一翻译。也就是说,你看到的报错其实是一个“二手信息”,真正的一手信息藏在响应体里。这也是为什么很多人对着 “token is unusable” 猜了半天原因,方向全错的根源。
1.2 换到 Codex / OpenClaw 之后,报错换了个马甲
当时为了验证是不是 Clawdbot 的个例,我顺手把同样的 key 和端点搬到了 Codex CLI 和 OpenClaw 里。结果很有意思:
- Codex 返回的是
unexpected status 401 unauthorized: invalid token - OpenClaw 返回的是
http 401: invalid api key - 还有一个走 OpenAI 兼容格式的配置,返回
{"code":"api_key_required","message":"api key required"}
表面看四个报错长得完全不一样,但把响应体拉出来对一下,上游 MiniMax 返回的其实都是同一个 1004,只是不同工具对 401 的措辞处理不同,有的直接透传 body,有的自己包装了一下。这个规律说明:问题不在 Clawdbot 本身,而是在 Clawdbot 发出的请求和 MiniMax 期望的请求之间有差异。
1.3 为什么同一个 401 在不同工具里长得不一样
说白了,这些 CLI 工具对接 MiniMax 时,走的是 Anthropic 兼容接口,也就是用 Anthropic Messages API 的请求格式去调 MiniMax 的网关。网关收到请求后先做鉴权,鉴权不过就返回 401,但各工具对 401 的处理逻辑不同。
有的工具会把 body 原样打出来,你就能看到 1004 domain forbidden;有的工具对 401 做了固定文案映射,只显示 invalid token 或 token is unusable;还有的工具会把错误码拼在文案后面,就成了 token is unusable (1004)。
所以你在网上搜这个问题,会看到五花八门的标题:codex 报错 401、openclaw 报 http 401、minimax 返回 1004……其实都是同一件事的不同观察角度。搞懂这个,后面排查就知道往哪使劲了。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先搞清楚 401 和 1004 分别在说什么
2.1 HTTP 401 的意思是“你还没证明你是谁”
HTTP 状态码 401 的官方语义是 Unauthorized,但它更准确的理解是“未认证”或“认证失败”,而不是“没权限”。服务器在说:你这次请求没有带上能被识别的身份凭证,或者带上的凭证我没法接受。
拿门禁打比方:401 就像是你在刷门禁卡,但门禁读卡器根本没认出这张卡,它给你的反馈不是“你没权限进这栋楼”,而是“我不认识你是谁”。至于你是卡拿错了、卡过期了、还是门禁系统里压根没有你这个人,它不区分。
在 Clawdbot 对接 MiniMax 的场景里,401 可能出现在两个地方:一是 MiniMax 网关在检查 API Key 时直接拒绝;二是中间某个网关(比如你自建的 API 转发服务)在转发前就把请求拦了。后面你会看到,这两个位置都能产生一模一样的 401,所以要学会区分。
2.2 MiniMax 错误码 1004 的常见含义
从我自己抓到的响应体来看,MiniMax 这边如果返回 {"code":1004,"error":"domain forbidden"},大多数情况下和“域名/端点区域不匹配”有关。
我这里说的“域名”,不是指网页域名,而是指 API 服务的区域域。MiniMax 开放平台按账号归属区域分了不同的接入点:国内账号走国内端点,国际账号走国际端点。两边的 API Key 体系是不通用的。如果你拿国内账号的 Key 去请求国际端点,或者反过来,网关会认为这个 Key 不属于这个域,直接返回 1004 domain forbidden。
还有一种可能:有些团队的 API Key 在控制台里开了“访问控制”,只允许从特定域名或 IP 发起请求。如果 Clawdbot 跑在一台不在白名单里的机器上,同样可能触发 1004。这种情况在企业账号里会碰到,个人账号比较少。
2.3 组合起来看:认证链路在“解析 token”阶段就断了
现在把 401 和 1004 拼起来看:MiniMax 网关在读取 Authorization 头或 x-api-key 头时,发现这个 token 无法绑定到当前请求的 domain,于是判定 token unusable,返回 401,error 是 domain forbidden,code 是 1004。
这解释了一个很反直觉的现象:为什么我在别的平台上同一把 Key 能通,在 Clawdbot 里就 401?因为别的平台帮你把 endpoint 和区域处理对了,而 Clawdbot 需要你自己把 base_url、模型名、请求头全部配对。任何一个环节出错,最后都会汇聚成同一个 401。
3. 根因排查:定位到底断在哪个环节
3.1 先把链路拆出来
要排查,先知道一条请求到底经过了哪几个环节。Clawdbot 发一条消息的完整链路如下:
- Clawdbot 读取环境变量或配置文件,拿到 base_url、API token、model 名。
- Clawdbot 拼接请求地址:一般是
{base_url}/v1/messages(Anthropic 风格)或{base_url}/chat/completions(OpenAI 风格)。 - Clawdbot 把认证信息放进请求头:可能是
Authorization: Bearer xxx,也可能是x-api-key: xxx,取决于你配的是哪种。 - 请求到达 MiniMax 网关(或你自建的中转网关)。
- 网关做鉴权 → 路由到模型 → 返回结果。
任何一个环节出问题,都可能表现为 401。但根据我踩坑的经验,大部分时候问题出在 1、3、5 这三个环节:配置值错了、请求头格式不对、或者 Key 在网关看来不属于这个端点。
3.2 最常见的 4 个原因
我把自己在网上搜到的、以及朋友群里反馈的案例汇总了一下,触发 401 token is unusable (1004) 的原因集中在四个方面:
- 端点区域配错:国内账号配了国际端点,或反之。这是 1004 出现的头号原因。
- API Key 有格式噪声:多复制了空格、换行、引号,或者把旧版的 JWT Token 当新 Key 用。
- 环境变量冲突:
ANTHROPIC_API_KEY和ANTHROPIC_AUTH_TOKEN同时存在,Clawdbot 用了其中一个,但那个是旧的或错的。 - 模型名不匹配:请求里带的 model 名 MiniMax 网关不认,网关在路由阶段就把请求否了,表现也是 1004。
3.3 用 curl 直连,一锤定音
在动 Clawdbot 配置之前,我强烈建议先用 curl 直连 MiniMax 端点,把“Key 到底有没有问题”这件事确认清楚。这样能把“Key 坏了”和“工具配置坏了”彻底分开。
以 Anthropic 兼容端点为例,直连命令大致长这样:
bash复制curl -sS https://api.minimaxi.com/anthropic/v1/messages \
-H "x-api-key: YOUR_Minimax_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "your-model-name",
"max_tokens": 1024,
"messages": [{"role": "user", "content": "ping"}]
}'
把 YOUR_Minimax_API_KEY 换成你的 Key,your-model-name 换成 MiniMax 控制台里实际存在的模型名。如果这条命令返回正常内容,说明 Key 和端点都没问题,锅在 Clawdbot 配置。如果返回 1004,说明 Key 或端点这一层就有问题,先别去动 Clawdbot。
4. 终极解决方案:四步把它修好
4.1 第一步:确定区域,选对 endpoint
很多人一上来就卡在这里。我建议你先想清楚你的 MiniMax 账号是在哪个平台注册的:
- 如果你登录的是中文控制台,注册手机号是 +86,那你的账号属于国内资源池,端点应该用国内版。
- 如果你登录的是英文国际站,用的是海外方式注册,那属于国际资源池,端点应该用国际版。
端点不要自己猜,去控制台找“接入文档”或“API 文档”,搜索 anthropic 或 base_url,把页面里给出的 Anthropic 兼容端点原样复制下来。常见的形态有两种:
text复制# 国内账号(示例,以官方文档为准)
https://api.minimax.chat/anthropic
# 国际账号(示例,以官方文档为准)
https://api.minimaxi.com/anthropic
注意:不要在这个地址后面再手动加 /v1。Clawdbot 默认会自己拼 /v1/messages,如果你在 base_url 里已经写了 /v1,最终请求会变成 /anthropic/v1/v1/messages,网关直接懵掉。这类问题虽然不是 1004 的直接原因,但会导致后续的 404/401 混着出。
如果你之前用的是 OpenAI 兼容端点(比如常见的 /v1/text/chatcompletion_v2 这种),也要换成 Anthropic 兼容端点,因为 Clawdbot 默认按 Claude 的接口格式发消息,两者不通用。
4.2 第二步:重新复制 API Key,消除格式噪声
拿到正确的端点之后,再去控制台 API Key 列表页看一眼你的 Key。很多人喜欢手选复制,结果把 Key 末尾的换行或者前后空格都带进去了,从肉眼根本看不出来,但请求头发出去就是坏的。
我自己的做法是:在控制台点“复制”按钮,然后粘贴到一个临时文本文件里,让编辑器开启“显示空白字符”(比如 VS Code 的 Render Whitespace),检查有没有多余的空格和换行。也可以在终端里直接验证长度:
bash复制echo -n "你的key" | wc -c
如果这个长度和 MiniMax 控制台展示的 Key 长度对不上,那就说明复制环节出了问题。
另外要确认一件事:你复制的是 API Key,不是旧版的登录 Token。MiniMax 早期的接口走的是签名 Token 方式,需要自己拼接;新版开放平台直接给了 API Key,作为 Bearer Token 用就行。如果你把旧 Token 拿过来填到 Clawdbot 里,是一定会被 401 拒掉的。判断方法也很简单:看控制台里这一项的标题是 API Key 还是 Token,标题是 API Key 的才是给外部工具用的。
4.3 第三步:清干净环境变量,重设 Clawdbot
很多 401 问题其实是环境变量打架出来的。我的习惯是,在配置之前先开一个干净的终端,把所有历史变量清掉:
bash复制unset ANTHROPIC_API_KEY
unset ANTHROPIC_AUTH_TOKEN
unset ANTHROPIC_BASE_URL
unset ANTHROPIC_MODEL
unset HTTPS_PROXY HTTP_PROXY ALL_PROXY NO_PROXY
然后重新设置:
bash复制export ANTHROPIC_BASE_URL="https://api.minimaxi.com/anthropic
