安全代理拒绝请求时，为什么应该告诉客户端原因：3个设计原则与9种拦截类型

当你的AI代理被安全系统拦截，它看到的只有一个冷冰冰的4xx状态码。是目标地址有问题？请求体违规？还是某个请求头触发了规则？代理超时了吗？还是代理本身崩溃了？没有上下文，每次拦截看起来都一样，代理只能在黑暗中消耗重试次数，试图用同一个请求榨取更多信息。

某安全厂商的解决方案是一个名为X-Block-Reason的响应头。词汇表精简，格式开放规范，但对运维人员的调试效率提升巨大。这篇技术文档讲的是设计思路、数据格式，以及为什么让安全代理"开口解释"反而能提升整体安全态势。

这个响应头要解决什么问题

想象一个编码代理运行工具获取URL，解析响应，再把输出喂给模型。请求经过安全网关，系统判定响应包含提示注入攻击模式，返回403，没有响应体。

代理完全不知道发生了什么。从代理视角看，可能性太多了：目标主机不可达、网关配置错误、网关宕机、目标服务器本身返回403、请求扫描失败、响应扫描失败……每种情况对应的正确策略都不同。"主机不可达"可能意味着换台主机重试；"网关配置错误"应该通知运维人员；"扫描拦截了请求"则意味着不要用完全相同的请求体重试。

没有信号，代理只能一视同仁：重试，撞墙，再重试，最终放弃。

运维人员的视角同样糟糕。审计日志确实记录了拦截事件，但要把代理混乱的重试序列和网关的决策树对应起来，意味着要按时间戳和请求ID交叉比对两条日志流。安静时段的单个拦截还好处理，面对每小时数千请求的集群，这就是折磨。

响应中的结构化拦截原因同时解决两边的问题。代理知道发生了什么，运维人员也不必grep两条日志来推断代理看到了什么。

这是面向运维人员的强制执行另一半。《Politeness vs Enforcement》讲如何让内核拒绝绕过；拦截原因响应头讲的是拒绝之后代理应该做什么。

响应头格式

完整规范在该厂商仓库的docs/specs/block-reason-header.md。一句话概括格式：

X-Block-Reason:

配合版本、严重程度、重试策略、触发层级的伴随响应头：

X-Block-Reason: dlp_match

X-Block-Reason-Version: 1

X-Block-Reason-Severity: critical

X-Block-Reason-Retry: none

X-Block-Reason-Layer: dlp

X-Block-Reason-Receipt在v2.4中预留：规范和WithReceipt验证器随该版本发布，但生产环境的拦截路径暂不填充该值，等待收据指针机制落地。填充后，该值将是一个26字符的Crockford-base32 ULID。

原因值（reason）采用受限词汇表，有意保持精简。当前定义包括：

1. request_body_scan_failed — 请求体扫描失败

2. response_body_scan_failed — 响应体扫描失败

3. header_scan_failed — 请求头扫描失败

4. dlp_match — 数据防泄漏规则匹配

5. prompt_injection_detected — 检测到提示注入

6. rate_limit_exceeded — 超出速率限制

7. upstream_timeout — 上游超时

8. upstream_unreachable — 上游不可达

9. proxy_internal_error — 代理内部错误

每个原因都有明确的语义边界。比如upstream_timeout表示网关成功连接目标但读取响应超时，而upstream_unreachable表示TCP连接建立失败。这种区分让代理能做出更智能的决策：前者可能值得重试，后者可能需要切换目标。

为什么开放规范比加密令牌更好

有人建议用加密令牌替代明文原因值，声称这样更安全。这个论点经不起推敲。

加密令牌需要密钥分发。网关和代理必须共享密钥，或者代理必须向验证服务发起额外请求。这两种方案都增加了故障面：密钥轮换出错会导致误报，验证服务宕机会让代理无法解析拦截原因。

更深层的问题是威胁模型错位。攻击者如果能读取响应头，已经处于中间人位置或控制了代理主机。此时隐藏原因值提供的安全增益微乎其微——攻击者可以直接观察请求是否成功，通过行为推断拦截规则。

明文原因值的价值在于降低运维成本。工程师看到prompt_injection_detected就知道该检查响应内容，看到rate_limit_exceeded就知道该调整请求频率。这种即时可解释性减少了工单流转时间，也减少了因误解拦截原因而产生的误操作。

重试策略字段的设计考量

X-Block-Reason-Retry字段取值为none、backoff、immediate或alternate_target，直接指导代理的下一步动作。

none用于不可逆的违规场景，如DLP规则匹配。重试相同请求只会再次触发相同规则，浪费资源且可能触发速率限制。

backoff用于临时性故障，如上游超时。代理应按指数退避策略延迟后重试。

immediate用于网关内部瞬态错误，如某扫描节点过载。快速重试到健康节点可能成功。

alternate_target用于上游不可达场景，提示代理尝试备用地址或CDN节点。

这个字段的存在让代理的决策逻辑从猜测变为响应。代理不再需要维护复杂的启发式规则来推断403的含义，而是直接遵循网关的明确指示。

与现有HTTP语义的兼容性

设计选择使用自定义响应头而非扩展Retry-After或WWW-Authenticate，是因为现有头部无法承载所需的语义密度。

Retry-After只表达时间维度，不区分原因。WWW-Authenticate专为认证场景设计，其挑战-响应模式与拦截场景不匹配。

自定义头部保持了与HTTP/1.1和HTTP/2的完全兼容。旧版代理会忽略不认识的头，行为退化为当前状态——这本身就是安全的默认行为。

生产部署建议

渐进式 rollout 策略：先在非关键路径启用原因头，验证代理解析逻辑的正确性；再扩展到关键路径，同时监控代理的决策质量指标。

日志关联：在网关侧记录原因头内容与请求ID的映射，在代理侧记录接收到的原因值与后续动作。两套日志的交叉验证能快速发现解析错误。

词汇表扩展流程：新增原因值需要经过RFC式审查，确保与现有值的语义边界清晰。厂商维护的规范仓库接受社区提案，但保留最终决策权以避免词汇膨胀。

这个设计把安全代理从黑盒变成了可协作的系统组件。代理不再盲目重试，运维不再盲目排查，双方基于相同的结构化信息做出决策——这才是安全基础设施应有的样子。