如果你的调用日志里出现大量 connect_error，先不要急着怀疑 CCSub 的上游服务。我们把近 7 天的失败样本按错误类型拆开看：connect_error 共 66 次，upstream_unavailable 只有 4 次。这个比例说明，绝大部分失败发生在“连接建立”这一层，也就是请求从你的机器出发、到真正触及模型之间的那段链路，而不是模型侧返回了不可用。本文就按这个分布讲清楚每类错误该由谁负责修、怎么修，以及在 gpt-5.6-sol 这类高并发主力模型上，如何配置超时、重试与连接复用。
一、先判断错误归属：连接层还是服务层
排查稳定性问题的第一步不是改代码，而是归类。把失败分到两个桶里，你就知道该动本地配置还是该等待服务恢复。
1. connect_error：本地网络链路问题
connect_error 表示客户端在建立连接阶段就失败了，请求根本没有形成一次完整的服务端交互。常见原因包括：
- 本机网络抖动、DNS 解析失败或临时断网；
- 代理软件切换节点、连接池被重置；
- 客户端超时设置过短，在 TLS 握手阶段就主动放弃；
- 短时间内并发过高，本机端口或连接数被耗尽。
这类错误的特点是：重试往往能直接成功，且失败时间点集中、批量出现。
2. upstream_unavailable：上游服务抖动
这类错误通常伴随 HTTP 5xx 状态码返回，代表请求已经到达服务端，但服务端在向上游模型发起请求时遇到不可用。它的数量通常很少，且具有全局性——同一时间段内不同客户端都会遇到。
判断口诀：如果错误在你的日志里成片出现、且换网络就消失，大概率是 connect_error；如果错误同时出现在多个同事的机器上、且几分钟后自愈，才是 upstream_unavailable。
二、确认你的接入参数是对的
很多 connect_error 其实是配置写错导致的连接目标错误。开始改重试策略前，先核对端点。
OpenAI 兼容调用
基础地址必须指向：
OPENAI_BASE_URL=https://ccsub.xyz/v1对话请求落在 https://ccsub.xyz/v1/chat/completions。API Key 使用你在控制台创建的密钥，形如 sk-你的CCSub密钥。
Codex 原生调用
Codex 使用独立的基础地址 https://ccsub.xyz/openai，协议为 wire_api = "responses"。配置正确后，Codex 会自动请求 /responses 端点（即 https://ccsub.xyz/openai/responses），你不需要手动拼路径。
Claude Code 原生调用
Claude Code 的基础地址为 ANTHROPIC_BASE_URL=https://ccsub.xyz/api，客户端会自动请求 /v1/messages，对应 https://ccsub.xyz/api/v1/messages。
可用模型查询
不要凭记忆写模型名。发起 GET https://ccsub.xyz/v1/models 即可拿到当前可用的模型 ID 列表，例如 claude-sonnet-5、claude-opus-4-8、gpt-5.6-sol、gpt-5.5 等。模型名写错时返回的通常是 4xx，而不是 connect_error，但模型名与端点混用（比如把 Claude 模型发到 OpenAI 兼容端点）可能引发难以定位的连接异常。
三、客户端超时、重试与指数退避的推荐参数
下面的参数基于“连接失败占多数”的实测分布给出，目标是让偶发 connect_error 被自动消化，同时不放大对上游的压力。
超时设置
- 连接超时（connect timeout）：10 秒。低于 5 秒会误杀正常慢握手，高于 15 秒则会让故障请求长时间占用连接。
- 读取超时（read timeout）：120 秒。长上下文或流式输出需要更长等待，不要用连接超时的值去卡读取阶段。
- 流式请求建议开启 keep-alive 心跳，避免中间设备切断空闲连接后表现为 connect_error。
重试次数
- 最多重试 3 次（即总尝试 4 次）。实测中 connect_error 重试一两次即恢复的比例很高，3 次足以覆盖绝大部分抖动。
- 仅对连接类错误和 5xx 重试；对 4xx（参数错误、模型名错误、余额不足）不要重试，重试只会浪费配额。
- 流式响应已经开始输出后中断的，不要整段重试，应由业务层自行决定是否续写。
指数退避参数
推荐使用带抖动的指数退避：
delay = min(base * 2^(attempt-1), maxDelay) * jitter
base = 0.5s
maxDelay = 8s
jitter = 0.5 ~ 1.0 的随机系数对应实际等待：约 0.5s、1s、2s，封顶 8s。加入随机抖动是为了避免大量客户端在同一时刻集体重连，形成新的连接风暴。
如果你不确定该用哪一档，先把 base 设为 0.5 秒、总重试 3 次跑一天，再看日志里 connect_error 的剩余量。多数本地网络问题会在这里被吸收掉。
四、gpt-5.6-sol 高并发场景的连接复用
从近 30 天调用分布看，gpt-5.6-sol 是绝对主力——967 次调用中占 760 次。高并发下，稳定性问题的重心会从“网络抖不抖”转移到“连接有没有被复用”。
1. 复用 HTTP 连接，不要每次新建
确保客户端 SDK 使用持久化连接池，而不是每个请求新建连接。频繁建连既慢又容易在握手阶段失败，这正是 connect_error 的一大来源。多数官方 SDK 默认复用，但如果你自己用 fetch 或裸 HTTP 请求，需要显式维护连接池或复用底层会话。
2. 限制并发上限
并发数建议控制在客户端连接池大小以内。例如连接池上限 50，则业务侧并发不超过 50，超出的请求进入本地队列，而不是继续硬开新连接。超出连接池的请求强行建连，失败往往就表现为 connect_error。
3. 失败请求与正常请求分离重试节奏
高并发时一旦发生批量 connect_error，集中重试会立刻形成第二次冲击。务必保留上面的随机抖动，并考虑在重试前加一个全局熔断窗口：短时间内连续失败超过阈值时，暂停发起新请求 5 到 10 秒再恢复。
4. 区分模型选择合适的调用方式
Codex 系模型走 https://ccsub.xyz/openai 的 /responses 协议，Claude 系模型走 https://ccsub.xyz/api 的 /v1/messages。把不同协议的模型塞进同一个连接池并无问题，但要确保每种协议使用各自正确的客户端实例，避免配置串用导致的连接异常。
五、常见错误排查清单
- 先看错误类型占比。connect_error 为主 → 查本地网络、代理、连接池；upstream_unavailable 为主 → 关注服务恢复，适当延长退避。
- 核对三个基础地址。OpenAI 兼容用
/v1，Codex 用/openai，Claude Code 用/api，混用是最常见的低级错误。 - 用
GET /v1/models校验模型名。模型名错误的表现未必是 400，有时会被误判成连接问题。 - 临时切换网络验证。换手机热点后 connect_error 消失，基本可以确认是本地链路问题。
- 检查代理与 DNS。代理解析域名异常、DNS 缓存过期都会制造批量连接失败。
- 查看密钥与余额状态。余额不足通常返回明确错误码，但如果被客户端统一包装成连接失败，会误导排查方向。
六、成本与充值提醒
重试策略会直接影响成本：一次失败后重试 3 次，最坏情况下单次业务请求可能产生 4 次计费调用（成功前不会被重复计费，但已消耗的输入 token 会计算）。因此：
- 对 4xx 错误坚决不重试，避免为参数错误反复付费；
- 监控充值余额，余额耗尽时的错误容易被误判为连接异常；
- 高并发跑批前先估算 token 消耗，参考控制台的模型定价分组，例如
gpt-5.6-sol的输入与输出单价差异较大，输出占比高的任务成本上升更快。
七、接下来怎么做
按本文顺序推进：先用 /v1/models 确认模型清单，再核对三个基础地址，然后落地 10 秒连接超时 + 3 次重试 + 0.5 秒起底的指数退避。跑一天后回看日志中 connect_error 的剩余数量，如果仍然偏高，优先怀疑代理与连接池，而不是服务端。需要更细的症状对照，可查阅 故障排查文档；尚未完成配置的，从 安装配置 开始，注册与密钥创建见 注册与充值。