这是一个 非常专业、也非常关键的问题。

很多人把「配置不当」和「容量不够」混为一谈，结果要么 白砸钱升机器，要么 一直以为官方炸了其实是自己把门堵死。

下面给你一套 可操作的 3 层判别法，按顺序做，基本能 5 分钟内定性。

0. 先给结论定义（你判断的标尺）

1）第一层： 先看是不是“你自己这台机器先撑不住了”

1.1 看 CPU / 内存 / Swap（最常见被忽略）

bashbashtop
free -h

你要盯住两件事：

• swap used > 0 且在涨（= 内存不够，系统开始用磁盘 → 一切变慢/超时）

• %wa很高（= IO 阻塞，多半是 sqlite 日志/数据目录在拖）

如果 CPU 很低、内存也充裕，但请求依然 502/满 → 基本可以排除“机器容量”，往“配置/网络/上游”走

1.2 看连接数 & TIME_WAIT 是否“假满”

bashbashss -s

重点关注：

• TIME_WAIT上万（常见在 3~5 万+）

  → 多半是 反代/Nginx/Caddy 没做 keepalive、或容器网络 NAT 表被你打穿

• 或者你看到 closed/ orphan异常高

这一步的意义是：

很多“满载”是 TCP 层满了，不是模型层满了。

2）第二层：看你的「中转服务」到底在卡什么（New-API / 同类）

2.1 先看容器/进程有没有饿死

bashbashdocker stats
docker logs --tail 100 new-api

你要找的关键信号（配置不当证据）：

• too many open files

• connection refused（但上游域名是通的 → 说明你本地出口/NAT 出问题）

• context deadline exceeded出现在 还没发到上游前

2.2 看“是不是被你自己重试喷死的”（最关键）

假性满载的典型形态：

• 一个请求慢 → 客户端/面板 立即重试

• 重试×N → 连接数暴增 → 反代/中转认为池不健康 → 全部 502

• 然后你一刷新：又来一波

自检方法（很有效）：

1. 把调用端改成 no-retry（或只重试 1 次 + 退避）

2. 把并发降到 1

3. 发一个“短 prompt + 小 max_tokens(64)” 的测试请求

如果这时：

• 立刻通 → 不是容量，是 并发/重试/池阈值 设太小

• 仍然 capacity / timeout → 继续往下看

3）第三层：做一次「直连 vs 中转」对照实验（最准的审判）

3.1 用同一 Key、同一模型、同一机房环境，做两条路

A. 走中转（你怀疑有问题的）

bashbashtime curl -s -o /dev/null -w "%{http_code}\n" \
  https://your-domain/v1/chat/completions \
  -H "Authorization: Bearer sk-你的令牌" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"hi"}],"max_tokens":16}'

B. 走官方直连（绕开中转）

bashbashtime curl -s -o /dev/null -w "%{http_code}\n" \
  https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer sk-真实官方Key" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"hi"}],"max_tokens":16}'

然后你只看三件事：

4）常见“配置不当伪装成容量问题”的 5 个罪魁（对照自查）

1. 反代没 keepalive / 最大连接太低

   • Nginx： proxy_max_conns太小 / upstream没 keepalive

   • Caddy：默认还好，但如果你手写过 max_conns要检查

2. New-API 渠道并发/QPM 设得太保守（看着像“满”，其实是你不让它接）

   → 试着把渠道的并发上限/冷却阈值 先放宽一点，看是不是立刻好转

3. SQLite 在高频请求下成锁点

   → 日志级别开太高 / 每次请求都写盘 → 表现就是“越用越满、越卡越多”

4. DNS 解析抖动

   → 容器里 /etc/resolv.conf指了不可靠 DNS

   → 表象：断断续续 “capacity/timeout”，但 ping 通

5. 你用了共享账号池中转，但上游出口被别人跑满

   → 这时对你来说“客观就是容量问题”，但责任不在官方、也不在你配置——而是 中转供给不足