代理请求形态是什么
经过显式代理时，客户端发出的请求行里写的是绝对 URI，包含方案与主机名，而不是直连时的路径形式；部分旧式代理还会附加 Proxy-Connection 头。识别这一点可以快速判断链路里是否存在显式代理，也能避免把这种形态误认成请求被人篡改。反向代理与透明代理不改写请求行，形态与直连一致，只能从网络路径、设备日志或行为特征侧确认。判读时还要留意代理可能改写其他头，例如 Via 与转发类头部，这与请求行形态是两条独立的线索。
基本信息
| 协议依据 | RFC 9110 与 RFC 9112（代理与请求目标） |
|---|---|
| 抓包字段 | http.request.uri、http.proxy_connection |
| 显式代理特征 | 请求行含完整方案与主机名 |
| 反代与透明代理 | 不改写请求行，形态与直连相同 |
| 关联头 | Via、X-Forwarded-For 等转发类头部 |
典型使用场景
- 链路确认：判断客户端是否配置了显式代理以及代理的部署位置
- 故障定位：代理配置错误时常伴随大量 4xx/5xx 与请求行形态异常
- 与反向代理区分：反向代理场景下请求行仍是路径形式
- 请求改写核查：确认头字段是否被中间设备增删
- 安全分析：转发类头部会暴露内部地址与网络拓扑
过滤与判断
过滤与判断
http.request.uri contains "http://" # 绝对 URI 形态
http.proxy_connection # 旧式代理的专有头条目
http.request.uri contains "/api/" # 直连或反向代理的路径形态
# 结合 Via 头判断链路里经过了几层代理部署方式与报文形态
| 部署方式 | 请求行形态 | 识别难度 |
|---|---|---|
| 显式代理 | 绝对 URI，可能带 Proxy-Connection | 抓包直接可见 |
| 反向代理 | 路径形式，与直连一致 | 需从设备日志与路由确认 |
| 透明代理 | 路径形式，无任何改写 | 只能从网络路径确认 |
Proxy-Connection 并非标准头，部分现代代理已不再使用；看不到它并不能证明链路里没有代理，判断要结合请求行形态与网络路径一起看。
转发类头部会暴露内部地址与拓扑结构，抓包文件对外分享前要把这些字段一并处理干净，否则等同于泄露网络设计。