请求走私是什么
当链路中同时存在前端代理与后端服务，而两者对请求边界的解析规则不同（主要是 Content-Length 与 Transfer-Encoding 的处理差异），一个请求的尾部可能被后端当作下一个请求的开头，形成请求走私（HTTP Request Smuggling）。它的危害不是单点越权，而是影响同一条连接上的其他用户请求，因此验证必须极其克制。
基本信息
| 前提条件 | 前端代理与后端对 CL/TE 头解析不一致 |
|---|---|
| 常见形态 | CL.TE、TE.CL、TE.TE（重复头与混淆头） |
| 参考标准 | RFC 9112（HTTP/1.1 消息语义） |
| 观察信号 | 请求超时、响应错配、队列变慢、后续请求被串包 |
典型使用场景
- 使用自研或老旧反向代理的架构中核查解析一致性
- 出现不明原因超时与响应错配时的根因排查
- 评估统一网关升级后是否已修复历史问题
- RFC 9112 发布后的合规性复核
- 与客户约定的专项窗口内做受控验证
验证原则
验证原则
1. 与客户确认专测窗口、影响范围与回滚联系人，说明可能影响其他用户请求
2. 优先使用工具内置的检测用例做无害样本（如 Burp 的相关检测功能）
3. 出现超时、错配或队列变慢立即停止，等待连接恢复正常再判断
4. 全程记录时间线与影响面（是否影响到非测试账号的请求）
5. 结论优先给出架构与配置层面的分析，动态验证结果仅作辅证风险与防护对照
| 风险形态 | 说明 | 加固方向 |
|---|---|---|
| CL/TE 解析差异 | 前后端取不同长度字段 | 统一使用 RFC 9112 严格解析 |
| 重复头混淆 | 同时出现两个 TE 头 | 拒绝含歧义头的请求 |
| 连接复用污染 | 走私内容影响后续请求 | 按请求隔离或关闭有问题的连接复用 |
| 代理版本缺陷 | 老旧代理实现不严谨 | 升级代理并回归验证 |
请求走私验证可能波及同一连接上的其他用户请求：生产环境测试必须限时、限量、有人值守，出现异常立即停止并通知客户。
前端代理与后端服务升级后要复测历史结论：解析行为随版本变化，旧结论不能用来说明当前状态。