深夜排查一段时好时坏的代理IP链路，抓包发现有个现象很规律：某些报文发出去后就没了回音，丢包率稳定在百分之几。细看字段，这些报文的 TTL 都走到了零。
TTL 归零不是巧合，而是机制按预期工作的结果。那一刻设备做了什么，值得拆开看——一共三件事，顺序还固定。
第一件事：停止转发
报文到达时如果 TTL 已经是一，设备按规矩先减一，变成零。规则说得很清楚：值为零的报文不再具备继续旅行的资格，设备不会把它转给下一站，旅程到此为止。
停止转发是干脆利落的，设备不会尝试改路、不会等一会儿再试，直接把报文拦在自己这一关。这也是 TTL 能阻止环路报文的根本原因，规则执行从不讲情面。
对正常通信来说，TTL 归零意味着报文半路夭折，应用只能靠重试弥补。好在正常路径不会让 TTL 轻易耗尽，走代理IP时归零如果频繁出现，往往指向某一段路径异常，值得顺藤摸瓜查下去。
第二件事：丢弃报文
被拦下的报文会从设备的转发队列里清除，不再占用任何后续资源。对设备来说，这份报文的任务到此结束，它的存在被彻底终止。
从使用者的角度看，这份报文对应的请求就「消失」了——应用层迟迟等不到回应，超时后报错或重试。这就是 TTL 耗尽在用户体验上的样子：一次没有回音的请求，一段平白无故的等待，代理IP链路上尤其明显。
第三件事：回一个超时报文
丢弃之外，设备还会给报文的来源回一个通知，意思是「你的报文在我这里超时了」。这个通知走 ICMP 协议，专门用于网络层的状态沟通，类型名叫 Time Exceeded（超时）。
回报超时不是强制的，部分设备为节省资源会静默丢弃。所以抓包时看到归零不回包也别意外，这属于设备策略差异，不代表机制失效。真正要留意的是归零的频率：偶尔一次是正常的路径波动，密集出现才需要排查。
而正是这个回包，让网络工具可以借此一段段摸清整条路径——它从一次「事故通知」变成了探路的梯子，这是设计者当初没想到的用途。
归零时刻在代理IP链路上意味着什么
链路里任何一段出了问题都可能导致 TTL 耗尽，但最常见的其实是配置问题：报文要走的路径比预期长得多，比如出口配置指向了很远的转发层，或者链路上套了多层转发，跳数累积超过了初始值。
还有一种更隐蔽的情况：某些转发层对报文做了重新封装，每封装一次就相当于多走若干跳，TTL 消耗比肉眼看到的路径更快。这类问题不看抓包很难发现，因为表面路径看起来并不长。
排查这类问题还有个现实意义：代理IP出口看似连着目标站，中间可能隔着好几层机房转发，每一层都在扣减 TTL。数字偏小不一定是绕远路，也可能是转发层级的正常代价，先分清再动手。
归零丢包先查路径再换出口：走代理IP时遇到 TTL 归零造成的丢包，先别急着判定线路故障。核对出口配置的路径是否比预想长，往往比反复换出口更有效。
把 TTL 想成入场券：进场划一格，划完最后一次正好到门口，票就作废了。路由器做的三件事——停转、丢弃、回报——就是检票员处理废票的完整流程，每一步都有它存在的理由。