同一条代理IP链路，有人抓包看到 TTL 一路递减，有人看到数值突然跳回高位——两种说法都对，差别在于代理是「转发」还是「代发」报文。这个分野，是读懂代理IP链路报文的关键分水岭。
两种行为对 TTL 的处理完全不同，弄清楚之后再读抓包结果，思路会清楚很多。
转发：报文原样过路，TTL 照常递减
转发类的代理（典型是 SOCKS 类型的中继）把报文当作过路的包裹，除了必要的地址改写，内容基本原样往下传。TTL 也跟着正常规则走：进转发层减一，出转发层再减一，一路递减到目标站。
转发模式下的代理IP链路，相当于在原有路径上多加了几跳中转。报文从本机出发，经过转发层时照常递减，到达目标站时反映的是完整路径——本机到转发层、转发层到目标站全都算在内，一眼看不出转发层具体在哪一跳。
想确认转发层的位置，可以配合目标站回包的延迟数据一起看：延迟出现明显台阶的位置，往往就是链路换段的地方，也就是代理IP链路里转发层所在的大致区间。
代发：另起炉灶，TTL 重新填值
代发类的代理（典型是 HTTP 代理重新发起请求）不转你那份报文，而是自己作为客户端重新生成一份请求发往目标站。新报文由转发层那台机器的系统填初始值，从 64 或 128 重新开始数。
这种模式下，目标站看到的 TTL 完全反映转发层到目标站的路径，跟你本机到转发层走了多少跳没有关系。两段旅程在 TTL 上被彻底隔开，各算各的账。
代发模式在代理IP链路里同样常见：很多 HTTP 代理在收到请求后重新建立连接，你的本机只和转发层打交道，目标站也只和转发层打交道，两侧互不相见。TTL 的读数也因此分成两段。
理解代发模式还有个用途：它能解释为什么某些抓包里的 TTL 数值永远不按预期递减——不是链路坏了，而是报文根本不是同一份，代理IP转发层替它开了新的头，旧的旅程在那一跳就结束了。
怎么分辨两种模式
判断走的是哪种模式，有个直观的办法：抓包看目标站回包的 TTL，数值规整、像从高位开始递减的，多半是代发；数值和本机直连时递减趋势连贯的，多半是转发。
这个区别在实际使用中影响不小：依赖 TTL 做路径判断时，先搞清楚自己的代理类型，否则会把转发层的路程错算成自己的，把代发的新报文误判成原报文的延续。
对普通使用者来说，这个分野还意味着：别拿「目标站回包 TTL」去反推自己本机的路径，那两段早已不是同一份报文在跑。要测就分段测、要读就分头读，结论才不会串线。
先搞清楚代理类型再读 TTL：依赖 TTL 做路径判断时，先确认自己的代理是转发还是代发，方向错了，后面算得再细也是白费。
代理IP链路在 TTL 上拆成两段是一种行为，连成一段是另一种行为：转发让旧报文续命过路，代发让新报文从零上路。看懂这个分野，链路报文的很多疑问都能解开，排障时也不会再被数值断层带偏方向。