带宽是有限资源，用满只是时间问题：某个时刻流量超过出口能力，链路就进入满载状态。代理IP链路满载时会发生一连串连锁反应——排队、延迟上升、丢包、重传，体感就是网页转圈、视频卡顿。
理解满载机制，是读懂代理IP速度问题的一半：满载不是玄学，它有清晰的物理过程。知道带宽满了之后数据经历了什么，看到卡顿时就能判断是临时拥挤还是出口真的不够，进而知道该等还是该换。
这篇完整还原满载现场：数据在出口前如何排队、延迟为什么拉长、丢包和重传怎么发生，以及满载最伤害哪类业务。
满载第一步：数据开始排队
当单位时间到达出口的数据超过它的送出能力，多余的数据不会消失，而是先在出口设备的缓冲队列里排队。队列越来越长，每个数据包等待的时间越来越久，延迟随之上升——这是满载最早的信号。
队列长度是满载的温度计：队列短，说明出口还宽裕；队列持续变长，说明出口已经吃紧。代理IP链路里，本机网卡、路由、机房出口各有各的队列，任何一处排起长队，这一段的延迟就会异常。
排队到一定程度，设备会开始丢弃无法容纳的数据。丢包一旦发生，可靠传输协议就会重传，重传的数据再次挤进队列，进一步加剧拥堵——满载进入恶性循环，体感从「慢」恶化为「卡顿与超时」。
值得注意的是，满载时带宽可能看起来没降：测速看的是吞吐量，而排队与丢包伤害的是延迟与稳定性。带宽满着、延迟乱跳，正是满载区别于线路故障的特征——吞吐还在，体验已崩。
代理IP链路对满载更敏感，因为数据要过两道出口：本地出口满载影响第一段，机房出口满载影响第二段。任何一段满载，整体体验都会被拖累，排查时两端都要看。
满载最伤害哪类业务
对延迟敏感的小请求首当其冲：它们的数据量小，不在乎带宽，却在队列里和大流量数据一起排队，原本几毫秒的请求被拖到几百毫秒。视频大流量业务反而相对扛得住，因为它们对延迟不敏感，慢一点也能播放。
怎么避开满载时段
满载有规律可循：晚高峰、活动时段、整点任务集中触发时最容易发生。错峰执行大任务、把零散请求分散到不同时段，都能明显减少撞上满载的概率。观察自己业务的用时分布，错峰并不难。
出口带宽满载的连锁反应是排队、延迟上升、丢包重传，伤害最大的是延迟敏感的小请求。
满载讲的是「用满之后」，那「用满之前」呢？服务商采购带宽时，是按什么标准决定买多大的？这就牵出出口带宽的计价方式——带宽怎么卖，直接决定服务商敢买多少、怎么分，下一篇看供给侧的价格逻辑。
满载现象还能解释一个常见疑惑：为什么代理IP链路的延迟在高峰时段会「跳」而不是平稳上升？因为排队与丢包是交替发生的，重传一波接一波，延迟读数自然忽高忽低。看到这种跳动，先想到满载，再查具体原因。
最后落到习惯上：给出口带宽留两到三成的安全边际，是许多长期使用代理IP的团队共同的实践。边际不是浪费，而是给突发流量留的缓冲，也是让链路在满载边缘仍能维持可用体验的保险。
带宽是硬资源，满载是它的天然边界。理解了满载的机制与信号，就不会在卡顿时胡乱猜测，而是先看队列、再看时段、最后调整使用节奏——代理IP链路的许多速度谜题，解开钥匙就在这一篇里。