用 Codex CLI 接 CCSub 时，最常见的两类报错是 connect_error 和 upstream_unavailable。它们看起来都像“连不上”，但归属完全不同：前者大多出在本地配置或网络出站，后者通常意味着请求已经打到中转服务、但上游模型侧暂时没能返回。把两者混在一起改配置，往往越改越乱。这篇按分层顺序走一遍，每一步都给出可复制的命令。
如果你还没装好客户端，建议先看 安装配置 和 新手入门，本文假设你已经能在终端里运行 Codex CLI。
先分清：两类报错分别意味着什么
- connect_error：客户端压根没建立到服务端的连接。典型原因是 base_url 写错、代理拦截、DNS 解析失败、端口或协议不对。请求很可能没有离开你的机器。
- upstream_unavailable：请求已经到达 CCSub 并被受理，但对应模型上游短时间不可用或返回异常。它属于服务侧波动，你的本地配置通常是对的。
一个简单判据：如果换一条普通 HTTP 请求也一样失败，就是 connect_error；如果 HTTP 请求能通、只有模型调用报错，那大概率是 upstream_unavailable。
第一步：确认 Codex 原生接入地址与 wire_api
Codex CLI 走的是 OpenAI 的 Responses 协议，不是 Chat Completions。接 CCSub 时，Codex 的专属 base_url 是 https://ccsub.xyz/openai，客户端会在这个地址下自动请求 /responses，也就是最终打到 https://ccsub.xyz/openai/responses。
配置里要把 wire_api 写成 responses，否则客户端可能用错协议体，表现为连接层面的失败。一个常见的 Codex 配置长这样：
# ~/.codex/config.toml
model = "gpt-5.6-sol"
model_provider = "ccsub"
[model_providers.ccsub]
name = "CCSub"
base_url = "https://ccsub.xyz/openai"
wire_api = "responses"
env_key = "CCSUB_API_KEY"密钥放在环境变量里，值是 sk-你的CCSub密钥：
export CCSUB_API_KEY="sk-你的CCSub密钥"写错 base_url 是最典型的 connect_error 来源。注意区分三组地址，它们服务不同客户端，不要混用：
- Codex 原生：
https://ccsub.xyz/openai（自动请求/responses） - OpenAI 兼容：
https://ccsub.xyz/v1（Chat 走/v1/chat/completions） - Claude Code 原生：
ANTHROPIC_BASE_URL=https://ccsub.xyz/api（客户端自动请求/v1/messages）
第二步：核对 API Key 与可用模型名
Key 无效或过期，有的客户端会先报连接类错误，容易和网络问题混淆。先确认 Key 真的能用：
curl -s https://ccsub.xyz/v1/models \
-H "Authorization: Bearer sk-你的CCSub密钥"能返回模型列表，说明域名可达、Key 有效、账户状态正常，connect_error 基本可以排除。可用模型以这次返回为准，不要凭记忆写。
模型名写错同样会引发失败。当前常见调用中，gpt-5.6-sol 用量最大，gpt-5.5 和 gpt-5.3-codex 也有稳定使用。名称必须逐字符匹配，例如：
gpt-5.6-sol
gpt-5.5
gpt-5.3-codex顺手看一眼账户余额和计费口径，避免把额度问题误判成连接问题，参考 注册与充值。
第三步：用 curl 把本地网络和上游波动分开
这一步是整篇的关键。直接在命令行打一次 Responses 接口，看返回的是连接失败还是服务端错误：
curl -i https://ccsub.xyz/openai/responses \
-H "Authorization: Bearer sk-你的CCSub密钥" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.6-sol",
"input": "ping"
}'- 卡住、超时、报 DNS 或 TLS 错误：本地网络或代理问题，属于
connect_error一侧。 - 服务端返回 5xx 或明确的不可用信息：请求已经到达，属于
upstream_unavailable一侧。
想再确认 OpenAI 兼容路径是否正常，可以补一条 Chat Completions：
curl -s https://ccsub.xyz/v1/chat/completions \
-H "Authorization: Bearer sk-你的CCSub密钥" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.6-sol",
"messages": [{"role": "user", "content": "ping"}]
}'两条路径一条通一条不通，说明问题在协议或路径配置，而不是网络整体不可用。
第四步：connect_error 的常见成因
- base_url 末尾拼错或多写了路径，导致请求打不到正确端点。
- 本地代理只放行了部分域名，Codex 的请求被拦下。
- 环境变量没生效，客户端读到的仍是空 Key 或旧 Key。
- 配置里
wire_api不是responses，协议不匹配。 - DNS 或 TLS 证书链异常，换网络环境可复现验证。
排查建议从最小改动开始：先把 base_url 和 Key 对齐到上面示例，再逐项加回代理等自定义设置。
第五步：upstream_unavailable 的重试与降级
如果 curl 已经能打通、只是偶尔报 upstream_unavailable，那多数是上游短时波动。处理原则是先重试、再降级，不要反复改本地配置。
重试时给请求留出间隔，避免短时间连续打同一个模型：
sleep 5 && curl -s https://ccsub.xyz/openai/responses \
-H "Authorization: Bearer sk-你的CCSub密钥" \
-H "Content-Type: application/json" \
-d '{"model": "gpt-5.6-sol", "input": "ping"}'如果同一模型持续不可用，先把 Codex 的 model 临时降到同系列的 gpt-5.6-luna，保证工作流不断：
# ~/.codex/config.toml 临时改为
model = "gpt-5.6-luna"先确认它可用，再切回主用模型：
curl -s https://ccsub.xyz/openai/responses \
-H "Authorization: Bearer sk-你的CCSub密钥" \
-H "Content-Type: application/json" \
-d '{"model": "gpt-5.6-luna", "input": "ping"}'降级只是过渡手段。等主用模型恢复后切回，避免长期跑在非预期模型上影响输出质量。
第六步：把排查顺序固化成习惯
- 先跑
GET /v1/models，确认域名、Key、账户都正常。 - 再跑一次
/openai/responses的 curl，判断是本地还是上游。 - 报连接类错误，改 base_url、wire_api、代理与 Key。
- 报上游不可用，重试、降级、等待恢复，不动本地配置。
- 仍无法定位，带上报错原文和时间点再查 故障排查。
顺手确认其他客户端的地址
如果你同时用多个工具，把地址一次对齐能省很多来回：
- Claude Code：
ANTHROPIC_BASE_URL=https://ccsub.xyz/api，自动请求/v1/messages。 - OpenAI 兼容工具（Cursor、VS Code、Windsurf、CherryStudio 等）：
OPENAI_BASE_URL=https://ccsub.xyz/v1。 - Codex、OpenCode、OpenClaw 走原生接入：
https://ccsub.xyz/openai，wire_api = responses。
参数支持范围可参考 API 参数与推理能力，计费与充值细节见 注册与充值。
小结
connect_error 和 upstream_unavailable 不是同一件事。前者优先查 base_url、wire_api、Key 与代理，后者优先重试和切换模型。先用 curl 分流，再决定改哪里，能省掉大部分无效调试。准备好后可以前往 ccsub.xyz 创建密钥并按本文配置，遇到疑问可对照 故障排查 逐项核对。