TCP Zero Window Through a Proxy: Identify the Receiver

A packet trace says TCP ZeroWindow. Before changing a kernel setting, identify the endpoint advertising the zero.

That endpoint is describing its receiving capacity on that TCP connection. It is not announcing how much bandwidth the whole proxy has available. A zero-window probe lets the sender discover whether that advertised capacity has changed; probes alone do not establish packet loss or a broken proxy.

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

These are separate TCP conversations. Suppose the browser stops reading a large response and advertises zero on A. The proxy can eventually stop draining B as its own buffers fill. A later zero window on B may be a consequence of the slow client, rather than the original problem.

The reverse situation is possible during an upload. If the destination application stops consuming data, its window on B can close. Pressure can then travel back toward the client through the proxy's buffers.

Put the observations in order

1. Record the connection endpoints and the direction of the affected data transfer.
2. Identify which endpoint first advertised a shrinking or zero receive window.
3. Check whether its application was reading, paused on another operation, or constrained by resources.
4. Compare the timing on the proxy's other connection before assigning the original cause.

Wireshark's window analysis labels are helpful interpretations of the capture, not an instruction to increase every receive buffer. Window scaling also has to be interpreted with the connection's negotiation in view.

Trying another endpoint from a proxy list and seeing the transfer recover is useful evidence that the path changed. It does not, by itself, prove that one operating system's TCP implementation was defective. Keep the explanation tied to the receiving process and the connection where the wait began.