用户要的不是理论，而是一套能立刻操作的诊断流程。深层需求其实是：“我的服务到底靠不靠谱？会不会突然崩？我该修哪里？”需要把技术排查拆解成清晰的动作，让他能一步步排除疑点，最终定位到是真流量超载还是配置缺陷。
从历史看，用户对术语（如token、SSL、CLI）有基础认知但可能不深，所以解释要避免纯理论，多给命令和观察指标。关键点在于：真容量问题会体现在资源硬性瓶颈（CPU/内存/网络/文件描述符）和上游真实限流（429/503）；而配置不当通常有特征性线索——比如无限重试循环、连接池泄漏、日志阻塞、或反代超时设太短。
需要给用户一个“三步走”框架：先看自己机器资源（是不是自己先倒了），再看中转服务内部状态（队列/并发/上游健康），最后用外部直连对比验证是否上游真满载。要强调“别只看错误提示文字，要看底层指标和错误形态”。最后提醒他，如果走的是共享账号池中转，那“容量问题”可能根本不在他控制范围内。
这是一个非常专业、也非常关键的问题。
很多人把「配置不当」和「容量不够」混为一谈，结果要么白砸钱升机器，要么一直以为官方炸了其实是自己把门堵死。
下面给你一套可操作的 3 层判别法，按顺序做，基本能 5 分钟内定性。
0. 先给结论定义（你判断的标尺）
真·容量问题 | 配置/架构不当（假性满载） |
|---|---|
机器资源/连接数确实到顶 | 资源还很闲，但请求就是进不去/卡死 |
上游（官方）返回 429/503/“at capacity”且持续时间匹配高峰 | 你把自己的并发/重试/反代参数搞成了“自攻自受” |
队列在走，只是慢 | 要么直接 502/504/reset，要么只有“第一秒”通 |
1）第一层：先看是不是“你自己这台机器先撑不住了”
1.1 看 CPU / 内存 / Swap（最常见被忽略）
bash
bash
top free -h你要盯住两件事：
swap used > 0 且在涨（= 内存不够，系统开始用磁盘 → 一切变慢/超时）
%wa很高（= IO 阻塞，多半是 sqlite 日志/数据目录在拖）
如果 CPU 很低、内存也充裕，但请求依然 502/满 →基本可以排除“机器容量”，往“配置/网络/上游”走
1.2 看连接数 & TIME_WAIT 是否“假满”
bash
bash
ss -s重点关注：
TIME_WAIT上万（常见在 3~5 万+）→ 多半是反代/Nginx/Caddy 没做 keepalive、或容器网络 NAT 表被你打穿
或者你看到
closed/orphan异常高
这一步的意义是：
很多“满载”是 TCP 层满了，不是模型层满了。
2）第二层：看你的「中转服务」到底在卡什么（New-API / 同类）
2.1 先看容器/进程有没有饿死
bash
bash
docker stats docker logs --tail 100 new-api你要找的关键信号（配置不当证据）：
too many open filesconnection refused（但上游域名是通的 → 说明你本地出口/NAT 出问题）context deadline exceeded出现在还没发到上游前
2.2 看“是不是被你自己重试喷死的”（最关键）
假性满载的典型形态：
一个请求慢 → 客户端/面板立即重试
重试×N → 连接数暴增 → 反代/中转认为池不健康 → 全部 502
然后你一刷新：又来一波
自检方法（很有效）：
把调用端改成no-retry（或只重试 1 次 + 退避）
把并发降到1
发一个“短 prompt + 小 max_tokens(64)” 的测试请求
如果这时：
立刻通 → 不是容量，是并发/重试/池阈值 设太小
仍然 capacity / timeout → 继续往下看
3）第三层：做一次「直连 vs 中转」对照实验（最准的审判）
3.1 用同一 Key、同一模型、同一机房环境，做两条路
A. 走中转（你怀疑有问题的）
bash
bash
time 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. 走官方直连（绕开中转）
bash
bash
time 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}'然后你只看三件事：
结果 | 含义 |
|---|---|
直连也报 at capacity / 503 | 更像官方侧真调度满（尤其高峰） |
直连秒通，中转一直卡/502 | 90% 是你的：反代/Nginx/Caddy / 连接池 / 账号池 / 健康检查 |
两者都秒通，但一并发就炸 | 你的“容量”只在并发口子上：调 |
4）常见“配置不当伪装成容量问题”的 5 个罪魁（对照自查）
反代没 keepalive / 最大连接太低
Nginx：
proxy_max_conns太小 /upstream没 keepaliveCaddy：默认还好，但如果你手写过
max_conns要检查
New-API 渠道并发/QPM 设得太保守（看着像“满”，其实是你不让它接）
→ 试着把渠道的并发上限/冷却阈值先放宽一点，看是不是立刻好转
SQLite 在高频请求下成锁点
→ 日志级别开太高 / 每次请求都写盘 → 表现就是“越用越满、越卡越多”
DNS 解析抖动
→ 容器里
/etc/resolv.conf指了不可靠 DNS→ 表象：断断续续 “capacity/timeout”，但 ping 通
你用了共享账号池中转，但上游出口被别人跑满
→ 这时对你来说“客观就是容量问题”，但责任不在官方、也不在你配置——而是中转供给不足
