通过代理观察 TCP 零窗口：定位接收方
在把卡住的下载归因于窗口缩放或缓冲区大小之前，先确认代理哪一侧的客户端或服务端在实施 TCP 流控。
抓包结果里出现了 TCP ZeroWindow。在改动内核参数之前，先确认是哪个端点通告了零窗口。
该端点描述的是它在这条 TCP 连接上的接收能力，并不是在宣告整个代理有多少可用带宽。零窗口探测让发送方得以了解对方通告的接收能力是否发生变化；探测本身并不能证明存在丢包或代理故障。
browser <-- TCP A --> proxy <-- TCP B --> website这是两段彼此独立的 TCP 会话。假设浏览器停止读取一个大响应，并在 A 上通告零窗口。随着代理自身缓冲区被填满，它最终可能不再从 B 读取数据。之后 B 上出现的零窗口，可能是慢客户端造成的结果，而不是最初的问题。
上传时也可能出现相反的情况。如果目标应用停止消费数据，它在 B 上的窗口就会关闭。压力随后可能经由代理的缓冲区回传到客户端一侧。
把观察结果按顺序整理
- 记录连接两端以及受影响数据传输的方向。
- 确认哪个端点最先通告了收缩或归零的接收窗口。
- 检查它的应用是在读取、卡在别的操作上，还是受资源限制。
- 在判定最初原因之前，对比代理另一条连接上的时间点。
Wireshark 的窗口分析标签只是对抓包的有用解读，并不是要求你把每个接收缓冲区都调大。窗口缩放同样需要结合这条连接的协商结果来理解。
从代理列表换一个端点、看到传输恢复，是有用的证据，说明路径变了；但仅凭这一点，并不能证明某个操作系统的 TCP 实现有缺陷。请把解释落在接收进程和等待开始的那条连接上。