title: "400/404/413排查 | 请求格式与Prompt过长" category: 人工智能 tags:
- 大模型API中转站
- 4SAPI
- 400 Bad Request
- 404 Not Found
- 413 Request Entity Too Large
- API排错 description: "400、404、413 多数和客户端请求有关。本文讲如何排查 4SAPI 接入中的请求格式错误、Base URL 填错、endpoint 不存在、模型参数不兼容和 Prompt 过长。"
这篇写三个特别常见的客户端错误：
它们的共同点是：
所以遇到这三类错误，第一反应不应该是换 Key。
第一反应应该是：
1. 400：服务器看不懂你的请求
400 Bad Request 的意思是：
在大模型 API 接入里，常见原因有：
比如有些模型或接口不支持某些参数。
你把 OpenAI 风格的 system、tools、response_format 原样传给所有模型，可能就会触发 400。
这不是权限问题。
这是参数兼容问题。
2. 400 的最小化排查法
遇到 400，先不要把整段业务请求发给管理员。
先做最小请求：
如果最小请求正常，再逐步加回去：
哪一步开始报 400，问题大概率就在那一步。
这比盲目改 Key、换模型、换 Base URL 高效得多。
3. 400 常见修复清单
可以按这个清单看：
| 检查项 | 说明 |
|---|---|
| JSON 是否合法 | 少逗号、多逗号、引号错误都会炸 |
| messages 是否为空 | 有些接口不接受空 messages |
| role 是否支持 | 不同模型对 system/user/assistant 支持不同 |
| max_tokens 是否过大 | 超过模型限制可能失败 |
| temperature 类型 | 不要把数字传成字符串 |
| tools 是否兼容 | 有些模型不支持工具调用 |
| response_format 是否兼容 | 结构化输出不是所有模型都支持 |
如果你接的是企业级 API 网关，建议把模型能力做成配置：
这样业务系统不会把所有模型当成一个接口用。
4SAPI 也可以通过模型路由和日志，帮你发现哪个模型最常因为参数兼容报 400。
4. 404：你访问的资源不存在
404 Not Found 在 API 接入里通常不是“网页不存在”。
它更常见的意思是：
比如你本来应该配置：
结果写成：
或者 SDK 自动拼接路径时，你又手动多写了一段 /v1。
最后实际请求就变成了不存在的路径。
5. 404 的排查顺序
遇到 404，先看四件事：
很多客户端配置里，Base URL 只填域名即可。
有些客户端则要求包含 /v1。
还有些工具对最后一个斜杠很敏感。
所以最稳的做法是：
如果日志里能看到 path，就很好排。
比如：
这种一眼就知道是重复拼接。
6. 413：请求体太大
413 Request Entity Too Large 表示：
在大模型场景里，最常见原因是：
这类问题不能靠重试解决。
你重试 10 次，请求体还是那么大。
7. 413 的修复方式
先做一个简单验证：
如果短 Prompt 正常，说明 Key、Base URL、模型路由大概率没问题。
问题就在输入体量。
修复策略：
企业内部接入时，建议设置输入上限：
不要让一个用户的一次请求把整个服务拖慢。
8. 4SAPI 日志应该记录什么
这三类错误都适合记录请求摘要。
字段建议：
注意：
Prompt 里可能有客户数据、代码、合同、隐私内容。
更稳的是记录：
需要深度排查时，再由有权限的人查看原始请求。
9. 给 AI 的排错 Prompt
这个 Prompt 可以给低成本模型先跑。
如果涉及多客户端、多模型、多 SDK 的兼容性，再交给 Fable 5 做系统排查。
10. 总结
400、404、413 这三类错误，优先怀疑请求本身。
排查顺序是：
4SAPI 的价值是把状态码、模型、路径、输入长度和错误摘要记录下来。
一句话：
