服务可用性 / HTTP 500
AI API 返回 500:服务端错误如何安全排查
直接答案
500 通常表示服务端未能完成请求。先保留请求 ID 和已脱敏的错误体,再用最小请求判断是上游故障,还是特定参数触发的问题。
症状与常见原因
- 服务商内部组件短时异常
- 特定输入、工具参数或响应格式触发服务端缺陷
- 依赖服务不可用或服务端资源紧张
如何确认问题
- 记录 HTTP 状态、错误类型与错误码、request ID、响应头、SDK 异常、模型、端点、项目和发生时间。
- 对比最小请求与失败请求,每次只改变一个变量,确认故障发生在客户端、网络、网关还是服务商层。
- 日志中不得保存完整 API Key、Authorization 请求头、用户敏感输入或私密文件内容。
排障步骤
- 记录时间、端点、模型标识、状态码和 request ID,并删除密钥与用户数据
- 查看服务商状态页,确认是否存在已知故障
- 移除工具调用、结构化输出等可选参数,以最小请求复现
- 仅对可安全重放的请求采用带抖动、有上限的退避重试
- 持续复现时提交最小样例和 request ID 给服务商支持
常见错误做法
- 对不可重放请求或明确的配置错误进行无上限重试。
- 同时更改密钥、模型、代理和请求参数,导致无法判断真正修复项。
- 关闭 TLS 校验、公开原始日志,或把临时缓解误判为已经恢复。
修复后的验证方法
- 用脱敏的最小请求确认状态码、响应结构和延迟恢复正常。
- 恢复少量真实流量,观察错误率、重试次数和业务结果,不立即放大并发。
- 确认没有重复副作用、告警恢复,并保留 request ID 与时间窗口供复盘。
常见问题
500 是否说明请求参数一定正确?
不一定。服务端应对无效参数返回更明确的 4xx,但实现缺陷也可能令特定参数触发 500,因此仍要用最小请求隔离变量。