HTTP 200 不等于 LLM 请求成功：多层网关下的静默失败

LLM 请求返回 HTTP 200 并不意味着成功，因为它可能在策略层被拒绝或在 sanitization 过程中被修改。 信号强调，一旦请求通过 policy、sanitization、routing 和 audit 层，单纯的 HTTP 监控就无法捕捉这些失败。

策略层拦截不会改变 HTTP 返回码

在现代 LLM 网关架构中，策略层（policy layer）承担了内容安全、合规检查和访问控制的核心职责。当用户提示中包含敏感关键词、越权指令或违反企业政策的内容时，这一层会直接拒绝请求。但关键在于，大多数实现为了保持协议兼容性，不会返回 4xx 或 5xx 状态码，而是继续让请求流转到下游模型，并最终返回 HTTP 200。

这种设计源于历史原因。早期 API 网关主要面向传统 REST 服务，客户端代码普遍只检查状态码是否为 200 就认为调用成功。如果策略层贸然返回 403，可能会导致大量现有集成代码崩溃。因此，策略拒绝被包装成正常响应，错误信息被塞进响应体中的某个字段，或者以看似正常的空回复返回。

实际场景中，企业级 LLM 服务常常要求对所有提示进行 PII 检测、毒性评分或知识产权合规检查。这些检查可能在几毫秒内完成，却直接决定了请求是否应该继续。如果开发者只盯着 Prometheus 的 http_status=200 指标，就会把大量被策略拦截的请求当成成功案例，进而误判模型可用性和业务健康度。

这种静默拒绝带来的后果是严重的。运维团队可能看到请求量和成功率都很高，但业务反馈却是“AI 回答越来越敷衍”。根源其实是 30% 的请求在策略层被无声拒绝，却从未被正确归类为失败。

Sanitization 层可能悄然破坏请求有效性

清理层（sanitization layer）负责对输入提示进行脱敏、过滤、规范化等操作，以防止提示注入、越狱攻击或数据泄露。这一层修改内容的动作往往是破坏性的，却几乎从不改变 HTTP 状态码。

举例来说，原始提示中包含了内部系统命令或特定格式的 JSON，sanitization 模块可能会移除这些部分，或者将其替换为占位符。模型收到的是一个被大幅阉割后的提示，却依然正常生成了回复。整个调用链路返回 200，客户端拿到的是看似合理的文本，但实际语义已完全偏离用户本意。

更隐蔽的情况是，清理层有时会直接丢弃部分多模态内容，比如把图像描述中的关键实体抹掉。开发者如果只检查状态码和响应长度，很容易忽略内容质量的下降。长期来看，这会导致模型效果评估数据失真，A/B 测试结果不可信。

信号明确指出，sanitization 之后的请求已经不是用户最初发送的那个请求了。HTTP 200 只是表明“网关把一个东西送给了模型并拿到了回复”，不能代表“用户想要的东西被正确处理了”。

Routing 决策把请求送入失败路径

路由层（routing layer）根据提示特征、负载均衡策略、模型能力标签或成本策略，将请求分发到不同的后端 LLM。路由决策出错时，请求可能被送到一个能力不足的模型、一个已过载的实例，或者一个根本不支持该功能的端点。

典型案例是：一个需要函数调用的复杂提示被路由到了只支持纯文本生成的旧版模型。模型返回了普通文本，网关包装成 200 状态码返回。客户端代码无法区分这是“模型正常回答”还是“路由选错了导致的降级回答”。

另一种常见情况是灰度路由或多租户场景下，路由策略把企业用户请求错误地送到了免费配额已耗尽的共享实例。模型返回拒绝信息，但 HTTP 层仍然是 200。监控系统如果只看状态码，就会把这类路由失败统计为正常流量。

路由层引入的失败是结构性的。它不是模型本身出问题，而是整个调用路径选错了。仅依赖 HTTP 状态码的监控系统完全看不到路由决策的细节，因此无法定位到具体是哪个路由规则导致了持续的低质量输出。

Audit 层引入额外拒绝与延迟

审计层（audit layer）通常放在整个处理流程的最后，甚至是异步的。它负责记录请求内容、生成合规报告、检测事后风险等。当审计发现问题时，可能需要对已生成的回复进行二次拦截或标记，但此时 HTTP 响应已经发出，客户端收到的仍是 200。

更麻烦的是，同步审计逻辑有时会增加显著延迟。如果审计模块需要调用外部合规模型或数据库，整体响应时间会从几秒延长到十几秒，而状态码依然是 200。客户端超时重试机制如果只看状态码，就会错误地认为这是正常的慢响应，而不是审计导致的阻塞。

审计拒绝的场景也值得注意。有些企业要求所有输出必须经过事后审核，审核不通过的回复会被替换为标准拒绝语句，但 HTTP 头和状态码保持不变。这进一步模糊了成功和失败的界限。

错误检测必须检查响应体而非状态码

正确的错误检测方式必须深入到响应内容本身。开发者需要解析响应体中的特定字段，比如 error、status、policy_violation、sanitized 等标记。这些字段才是真实反映多层处理结果的信号。

一个可行的模式是定义统一的语义状态码。例如，网关可以在响应体中增加一个 llm_status 字段，取值包括 success、policy_denied、sanitized、routed_to_fallback、audit_rejected 等。客户端 SDK 应该优先读取这个字段，只有当 llm_status 为 success 时才认为调用真正成功。

同时，响应体中还应携带详细的元数据：经过了哪些策略检查、被修改了哪些内容、实际路由到了哪个模型、审计结果如何。这些信息对后续调试和优化至关重要。单纯的 HTTP 200 + 文本回复的时代已经过去了。

对于中文开发者来说，特别需要注意提示中常见的中文敏感词、格式化指令和企业内部术语。这些内容在 sanitization 层最容易被意外修改，必须在响应中明确标注修改痕迹。

重试逻辑需区分 HTTP 错误与语义失败

重试机制必须彻底重构。传统的“非 200 就重试”的逻辑在这里完全失效。策略拒绝的请求即使重试十次结果也一样，因为根本问题是提示内容违规。盲目重试只会浪费 token 和计算资源。

正确的做法是分层重试策略：

• HTTP 5xx 或连接超时：立即重试或切换节点；
• 策略拒绝（policy_denied）：不再重试，直接向用户返回合规提示或引导修改输入；
• Sanitization 修改：可以尝试轻微改写提示后重试，但需限制次数；
• 路由失败：切换到明确支持该能力的模型后再重试；
• Audit 拒绝：根据拒绝原因决定是否需要人工介入或使用备用回复。

这种区分对待的机制能显著降低无效重试率，同时提高整体成功率。信号中提到的多层处理特性，要求重试逻辑必须理解每一层的失败语义，而不是简单相信 HTTP 状态。

监控体系要覆盖所有处理层

对中文开发者而言，从过去依赖 Nginx 或 API 网关的 HTTP access log 转向内容级和网关级监控，是架构升级的必经之路。新的监控体系需要采集每个处理层的决策结果：policy 判断结果、sanitization 修改比例、路由分布、audit 通过率等。

具体实现上，可以在 LLM 网关中埋点，将每一次请求的完整处理轨迹以结构化日志或指标形式输出。重点监控指标包括：policy_deny_rate、sanitization_alter_rate、fallback_routing_ratio、audit_reject_rate、semantic_success_rate 等。

这些指标能帮助团队快速定位问题。例如，如果 policy_deny_rate 突然上升，很可能是新上线的功能触发了更多合规规则；如果 sanitization_alter_rate 居高不下，则需要审查清理规则是否过于激进。

最终，监控的目的是让开发者不再被虚假的 200 成功率所蒙蔽，而是真正看到 LLM 服务在企业环境下的健康状况。这也是为什么越来越多团队开始引入专为生成式 AI 设计的网关产品，它们天然提供了跨层的可观测性。

只有当监控覆盖了 policy、sanitization、routing 和 audit 所有环节，HTTP 200 才不再是误导性的信号，而是真正有意义的起点。

参考来源

• HTTP 200 doesn’t mean your LLM request succeeded