同一份数据，直连能跑满带宽，一换代理IP 就掉了将近一半，抓包看又没丢包重传。多数人第一反应是出口带宽不够，可换了好几个出口依然如此。这时候该往 TCP 滑动窗口这一层查——代理IP 链路上有两段连接，各管各的窗口，任何一段窗口被压小，整条链路的表现都会被拖住。
滑动窗口是 TCP 的”水管调节阀”
TCP 靠窗口机制控制一次能发多少数据。发送方维护一个发送窗口，决定在收到确认之前最多能往外发多少；接收方则在确认报文里带上自己的接收窗口值，告诉对方”我这会儿还能收多少”。两个窗口合在一起，就决定了这条连接当前的实际吞吐上限。
窗口不是固定不变的，它随数据收发不断”滑动”。已发送且已确认的数据从窗口里划出去，新数据补进来，发送方就这样持续地往外推数据。只要接收方处理得过来，窗口就保持宽大，传输效率就高。
问题在于窗口大小不是凭空定的，它取决于链路质量、两端处理能力和中间设备的转发行为。链路一抖动，窗口就会被调小；调小之后恢复又很慢，表现出来就是吞吐骤降。直连时链路短、环节少，窗口不容易被干扰；代理IP 多了一段中转，被干扰的概率明显上升。
走代理IP 时，一条完整连接被拆成两段：本地到代理一段，代理到目标站一段。这两段各自维护独立的窗口状态，互不共享。本地的发送窗口可能很宽，但代理那一段的窗口被压小了，数据在代理处堆积，本地再宽也发挥不出来。
为什么代理IP 链路上窗口更容易变小
窗口变小常见三个原因。一是链路往返时间变长，TCP 计算窗口时更保守，宁可少发也不冒险；二是代理自身的转发缓存有限，缓存一满就把接收窗口压小，向上游”喊停”；三是中间设备对空闲连接有超时清理，重建后窗口要从头爬升。
这三个原因叠加，使代理IP 链路比直连更容易出现窗口缩水。更要紧的是窗口缩小是静默的：数据照常流动，只是流量变慢，没有丢包、没有报错，很容易被误判成”出口质量差”而反复换出口，白费功夫。
窗口更新报文丢失的隐蔽影响
还有一个容易被忽略的细节：窗口更新报文丢失。接收方处理完一批数据后，会发报文告诉发送方”窗口变大了”，这个报文若在中途丢失，发送方会一直按旧的小窗口慢慢发，直到超时后重新探测才恢复，期间的吞吐白白浪费。
代理IP 链路上窗口更新被吞的概率比直连高。链路多了一段，中间任何一环丢一个报文，都可能让吞吐长时间停在低位。这类问题抓包时几乎看不到异常，只能靠对比”直连 vs 代理IP”的吞吐差异来定位。
短连接场景：连接很快建好又很快关掉，窗口还没爬升到高位就结束了，滑动窗口影响有限，问题更多体现在单次请求的延迟上。
长连接场景：窗口机制的影响被放大。连接保持得越久，窗口状态越重要，任何一次缩小或更新丢失，都会让吞吐持续受损，直到连接重建才恢复。
链路选择：想减少窗口层的问题，优先选延迟低、波动小的出口，并把连接保持时间纳入考量。窗口机制对稳定性的敏感度，比想象中高得多。
排查时可以按这个顺序走：先看有无丢包，无丢包再看窗口值变化，最后对比不同出口的吞吐差异。多数”直连满速、代理IP 掉半”的情况，都能在这一层找到答案，而不是一味地换出口。
窗口机制是 TCP 的基础能力，代理IP 只是把连接拆成两段，让原本隐藏的窗口问题显形。理解了窗口在哪一段被压小，就知道该往哪个方向调——这也是代理IP 链路优化里最容易被低估的一环。