在 CCSub 近 7 天的错误分布里，connect_error 出现了 46 次，远高于 upstream_client_error 的 8 次和 upstream_unavailable 的 5 次。这个比例说明一件事：绝大多数 Codex CLI 接入失败并不是模型、额度或计费问题，而是请求根本没能在网络层抵达 ccsub.xyz。
本文只讲一件事——连不上。如果你看到的是余额不足或输出被截断，那是另外两类问题，本文不涉及。下面按 DNS 解析 → 环境变量 → TLS 握手 → 本地缓存四层顺序排查，每层都给可直接复制的命令。
先确认：connect_error 到底卡在哪一环
Codex CLI 在发起请求时，会依次完成：域名解析 → TCP 连接 → TLS 握手 → HTTP 请求。任何一步失败都可能被归类为 connect_error，但错误信息里通常还藏着细节。先跑一遍最小复现：
codex "hello" --debug观察输出的最后几行，重点看是 getaddrinfo ENOTFOUND（DNS 层）、ECONNREFUSED / ETIMEDOUT（连接层）还是 unable to verify the first certificate（TLS 层）。这三个方向对应完全不同的修法。
第一步：确认域名本身能解析
CCSub 的 Codex 原生接入点是 https://ccsub.xyz/openai，OpenAI 兼容接入点是 https://ccsub.xyz/v1。两者域名相同，所以先验证域名解析：
nslookup ccsub.xyz
# 或
dig ccsub.xyz +short
# Windows 下
ipconfig /flushdns
nslookup ccsub.xyz 8.8.8.8如果本机 DNS 返回 ENOTFOUND 或解析到明显异常的地址，用公共 DNS 再查一次。两个结果不一致，说明是本地 DNS 缓存污染或运营商 DNS 劫持，不是 CCSub 侧的问题。此时清缓存并改用可信 DNS：
- macOS：
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Windows：
ipconfig /flushdns - Linux（systemd）：
sudo systemd-resolve --flush-caches
很多用户以为要装加速工具才能用，其实先确认域名能否稳定解析。解析都不通时，换任何代理都白搭。
第二步：直连测试，绕开 CLI 本身
把 Codex CLI 先放到一边，用 curl 直连验证可达性，这是最快的分界线：
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://ccsub.xyz/v1/models
# 查看 Codex 原生端点
curl -sS -o /dev/null -w "%{http_code}\n" https://ccsub.xyz/openai/responses带上密钥再试一次，确认鉴权链路也没问题：
curl https://ccsub.xyz/v1/models \
-H "Authorization: Bearer sk-你的CCSub密钥"GET /v1/models 是查询当前可用模型的官方方式，能正常返回说明 DNS、TCP、TLS 三段都通了，问题就落在 Codex 配置或代理环境变量上。如果 curl 也失败，先修网络，别改配置。
第三步：环境变量冲突是最高频的隐形杀手
当你同时开着代理软件、公司 VPN 或终端代理，HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY 很可能互相打架。先看当前终端实际生效了什么：
env | grep -i proxy
# Windows PowerShell
Get-ChildItem Env: | Where-Object Name -match "proxy"常见坑有两类：
- 代理变量指向已关闭的本地端口（比如
127.0.0.1:7890但代理软件没开），表现为ECONNREFUSED。 - NO_PROXY 没排除 ccsub.xyz，导致本该直连的请求被塞进一个不支持的代理通道，表现为握手超时。
排查时先清空代理变量做一次裸连，再逐条加回来定位：
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
curl -sS https://ccsub.xyz/v1/models \
-H "Authorization: Bearer sk-你的CCSub密钥"公司网络与代理软件的 TLS 拦截
如果裸连也失败，但浏览器能打开 ccsub.xyz，大概率是公司网关或代理软件做了 TLS 中间人拦截。特征是报错里出现 self signed certificate、unable to verify the first certificate 或 certificate has expired。
openssl s_client -connect ccsub.xyz:443 -servername ccsub.xyz < /dev/null 2>/dev/null \
| openssl x509 -noout -issuer -subject -dates查看签发者是否是意想不到的机构。正确做法是把公司根证书导入系统信任链，或让代理软件对 ccsub.xyz 走直连，而不是在客户端盲目关闭证书校验。
第四步：收敛后的正确配置写法
网络通之后，把配置固定下来，避免环境变量再次污染。Codex CLI 请在配置里指向原生端点，并声明使用 Responses 接口：
# Codex CLI 配置示例
base_url = "https://ccsub.xyz/openai"
wire_api = "responses"
model = "gpt-5.6-sol"
api_key = "sk-你的CCSub密钥"wire_api = responses 是必须的，因为 Codex CLI 会自动向 /responses 发起请求，而 CCSub 的 Codex 原生入口正是 https://ccsub.xyz/openai/responses。写成 Chat Completions 端点会直接失配。
其他客户端的对应关系
- OpenAI 兼容模式：
OPENAI_BASE_URL=https://ccsub.xyz/v1，请求打向/v1/chat/completions，适合 Cursor、VS Code、CherryStudio 等。 - Claude Code 原生：设
ANTHROPIC_BASE_URL=https://ccsub.xyz/api，客户端会自动请求/v1/messages。 - Codex 原生：
https://ccsub.xyz/openai，按上面的wire_api = responses配置。
模型清单请始终以 GET https://ccsub.xyz/v1/models 返回为准，例如 gpt-5.6-sol、gpt-5.6-luna、claude-sonnet-5、claude-opus-4-8 等。写死一个已下线的模型名，也可能表现为连接后立即失败。
用 Node 版本统一验证一遍
Codex CLI 依赖较新的 Node.js。Node 版本过低时，某些网络库在 TLS 协商阶段就会报错，容易被误读成 connect_error：
node -v # 建议使用较新的 LTS 版本
npm -v如果 Node 版本很旧，升级后重装 Codex CLI 再试一次，往往能一次性解决一类连接报错。
常见 connect_error 对照表
getaddrinfo ENOTFOUND ccsub.xyz→ DNS 解析失败，清缓存或换 DNS。ECONNREFUSED→ 代理端口没开或代理变量残留，检查*_PROXY。ETIMEDOUT→ 出口被拦或代理链路不通，测试直连。unable to verify the first certificate→ TLS 中间人拦截，导入根证书。- 连上后立刻报错 → 检查
wire_api与base_url是否匹配，模型名是否存在。
成本和充值提醒
网络层修好之前，不要反复重试触发大量请求。虽然 connect_error 通常不会产生模型计费，但一旦链路通了，真实消耗就会开始。你的 Codex 与 OpenAI 通道按 token 计费，输入与输出价格不同，缓存读写另有单价，建议先在小对话里验证连通，再放进长任务。
如果排查半天仍然连不上，先把以下信息整理好：curl -v https://ccsub.xyz/v1/models 的完整输出、env | grep -i proxy 的结果、node -v 版本号。带着这三样去看故障排查文档，或在账号后台提交工单，能明显缩短定位时间。
下一步行动
- 先用 curl 确认
https://ccsub.xyz/v1/models能带密钥返回。 - 清空代理变量做一次裸连，确认不是环境变量打架。
- 按客户端类型写对
base_url与接口类型：Codex 用https://ccsub.xyz/openai+wire_api = responses。 - 确认无误后，再回到安装配置文档完成收尾，或从新手入门重新走一遍流程。
把网络层这三步走顺，Codex CLI 的 connect_error 基本都能自己解决，剩下的才轮到额度与模型参数问题。