有个现象挺反直觉：你在浏览器里清清楚楚看到请求带着十几行头部发出去，等代理IP转发到目标站、对方把收到的内容打出来一看，少了几行。中间没人动过手脚，那几行就是凭空消失了。
消失不是故障，是协议里写明的规矩。请求头被分成了两类，一类要一路带到终点，另一类只在相邻两个环节之间有效。代理IP转发时遇到后一类，读完就自己消化掉，不往下传。
逐跳头：只在相邻两段之间有效
这类字段描述的是「这一段连接」的状态，而不是整趟通信的意图。比如连接要不要复用、要不要升级协议、内容怎么分块，这些事只在直接相连的两个环节之间才成立。换一段连接，原来的约定就作废了。
代理IP服务器拿到这类字段，会按字段含义在本环节做出响应，然后把字段摘掉再发往下一环。摘掉不是丢弃信息，而是这段信息已经完成了它的任务——就像快递面单上「本站分拣」的印章，到了下一站就没有意义了。
端到端头：一路带到终点
与逐跳头相对的是端到端头，它们描述的是整趟通信的意图，目标站必须看到。目标主机、内容类型、语言偏好、来源页面，这些都属于这一类。代理IP转发时原则上原样带过去，动它们只会让目标站做出错误判断。
区分两类的实用标准很简单：这个字段说的是「这一段连接怎么走」，还是「这次请求要什么」。代理IP转发时按这个标准判断，前者是逐跳的，走到下一段就失效；后者是端到端的，必须完整抵达终点。
Connection 名单：代理按它决定删哪些
实际转发时，代理怎么知道哪个字段该摘？靠一个叫 Connection 的字段列出的名单。它是逐跳字段，本身写着一串字段名，等于告诉中间环节：这几项只对当前这一段有效，转发时请摘掉。
代理读到这份名单，就把名单里点到的字段在本环节处理完，然后连同名单一并移除，再把剩下的头部发往下一环。代理IP服务器在每一跳都重复这个动作，所以多级链路上每经过一跳，头部就可能少一批。
顺带一提，很多代理IP服务商支持自定义这份名单的行为，这也是为什么同样的请求头，走不同的转发配置，到了对面的结果会不一样。
对照这三类，再回头看消失的那几行，基本都能归位。
- 连接复用类字段：描述这一段连接是否保持，换一段就失效，属于典型的逐跳字段
- 协议升级类字段：只在这一段协商，下一段要不要升级得重新谈
- 分块与长度类字段：每一段可能重新分块，旧的分块说明不能带过去
- 名单字段本身：它列完该摘的项，自己也一并被摘掉，不会传到下一环
需要注意的是，逐跳字段被摘掉，不等于它约定的事没发生。连接复用、协议升级这些事在每一段都被认真执行了，只是执行记录不会跟着请求一起走到终点，代理IP链路上的每一跳都是如此。
先看字段属于哪一类，再决定补不补：目标站没看到的字段，有不少本来就不该出现在那一端，盲目补字段反而会让代理IP链路上的信息更乱。
顺带说一句，被摘掉的字段在代理侧通常留有记录。需要核对时把两端的记录摆在一起比对，比在客户端反复试要快得多。
头部会少几行，不是信息丢了，而是有些话本来就说给这一段听。