HTTP 通信是一次问答：你发请求，服务器回响应。问答双方各带一套头——你带的是请求头，服务器带的是响应头，两套头长着同样的「名字: 值」格式，装的内容却各管一头。代理IP链路中看报文，分清这两套头是基本功。
请求头与响应头像一次对话里的两张便签：你去信时在便签上写自己的要求，对方回信时在另一张便签上写处理结果。两张便签格式相同，语义却对应着问答的两端，混着看会把信息张冠李戴。
这篇讲请求头与响应头的分工：各自装着什么、哪些信息成对出现、以及怎么看懂一次问答里的两套头。
各自装着什么
请求头装的是「这次访问的期望」：要什么内容、接受什么格式、带什么凭证。响应头装的是「这次处理的实况」：内容是什么类型、有多长、是否缓存、有没有过期。一个说需求，一个报情况，方向正好相对。
有些信息只在请求头出现，比如期望的语言与格式偏好；有些只在响应头出现，比如内容的实际类型与长度；还有些两头都有但含义不同——比如内容类型头，请求头里它说明要发的内容类型，响应头里它说明返回的内容类型。
成对出现的问答
不少头是成对工作的：你发 Accept 说想要什么格式，服务器回 Content-Type 说给了什么格式；代理IP请求里的这些成对问答同样一板一眼，你发 Cookie 带上状态，服务器回 Set-Cookie 更新状态。理解这种成对关系，看报文时就能把一问一答对起来，而不是只看孤立的某一行。
代理IP场景里还有一种成对：你发给代理的认证头与代理返回的认证要求。链路里的每一段都可能有一问一答，报文看多了会发现，整个 HTTP 世界就是无数个这样的问答串起来的。
请求头说需求、响应头报情况，两者按「名字: 值」同格式成对出现——分清两套头，一次问答就完整了。
请求头家族成员众多，逐个记会乱。好在它们可以按功能分门别类——下一篇给请求头画一张家族地图，分几个家族把它们各归其位。
从报文里认出两套头
抓包或开发者工具里，一次请求与它的响应会成对显示：上面是请求头（Request Headers），下面是响应头（Response Headers），中间用状态行隔开。养成先分清上下再读内容的习惯，看报文就不会把「我要什么」和「我给了什么」混为一谈——代理IP链路调试里这个习惯尤其重要。
代理IP链路中两套头都随报文经过转发层：请求头告诉转发层目标在哪，响应头带着转发层的痕迹回传。链路排障时两侧都看，往往能在请求头与响应头的差异里找到问题线索——这是报文阅读的基本功。
两套头的关系可以浓缩成一句话：你发的每一行请求头，都会在响应头里得到呼应或交代。养成报文成对读的习惯之后，代理IP链路中那些「请求发了没回音」的疑难，往往从响应头缺失或异常里就能找到突破口。