Reset after data flowed
The connection worked, data moved, and then one side cut it off rather than closing it politely. Which side sent the reset is usually the entire answer.
What it looks like
A complete handshake, some data in both directions, and then a RST instead of the FIN exchange that ends a healthy conversation. The report grades it Degraded, says “The conversation was cut off mid-sentence”, and names the side that sent the reset.
What causes it
- An application timeout. A server with a 30-second limit on a request that took longer will reset rather than wait.
- A stateful device that forgot. Firewalls and NAT gateways drop idle connections from their tables, typically after minutes of silence; the next packet then has no entry and gets a reset. Long-lived idle connections — database pools, SSH sessions — are the classic victims, and TCP keepalives are the classic fix.
- A proxy enforcing a limit. Body size, header count, or request duration.
- The application closed the socket with data still unread, which makes the kernel send a reset rather than a FIN.
What to do
Start at the end that sent it — the report says which. Look at the timing: a reset that arrives at a suspiciously round number of seconds after the last packet is a timeout, and the number usually names the device. If it arrives after a long idle period, it is a state table, and keepalives below that idle timeout will fix it. If it arrives immediately after a particular request, it is the application, and its log will say why.