HTTP/2 GOAWAY and RST_STREAM PCAP Analysis: Debugging Reset Streams, Proxy Limits, and gRPC Failures

HTTP/2 failures can be hard to diagnose because one TCP connection can carry many streams. A single request may fail with RST_STREAM, the whole connection may receive GOAWAY, or a gRPC client may report UNAVAILABLE, INTERNAL, CANCELLED, or stream reset. Users search for "HTTP2 GOAWAY pcap", "RST_STREAM analysis", "gRPC stream reset packet capture", "HTTP/2 proxy reset", and "ALPN HTTP2 troubleshooting" when logs do not explain whether the client, proxy, load balancer, or server ended the stream.

PCAP Surgery is useful because HTTP/2 evidence must preserve TLS, ALPN, connection timing, stream resets, and TCP close behavior. If TLS is encrypted and keys are unavailable, packet captures still show timing, TCP resets, connection reuse, and sometimes decrypted HTTP/2 only in controlled environments.

HTTP/2 connection vs stream

HTTP/2 multiplexes multiple streams over one connection. A stream reset is not the same as a TCP connection reset.

• RST_STREAM: one stream is cancelled or failed.
• GOAWAY: endpoint is closing or draining the HTTP/2 connection.
• TCP FIN/RST: the underlying connection closes or aborts.

Applications often collapse these into one error. Packet evidence and logs should separate them.

ALPN negotiation

HTTP/2 over TLS usually depends on ALPN. The TLS handshake negotiates h2 or another protocol. If ALPN does not negotiate HTTP/2, the client and server may fall back or fail.

Preserve:

• ClientHello ALPN extension.
• Server-selected ALPN where visible.
• TLS alerts.
• TCP resets during handshake.

If HTTP/2 never negotiated, do not debug RST_STREAM yet.

GOAWAY

GOAWAY tells the peer that no new streams should be created on that connection. It can be normal during graceful draining, deploys, proxy connection aging, or load balancer behavior. It becomes a problem when clients reuse draining connections incorrectly or when GOAWAY appears during active requests.

Important questions:

• Who sent GOAWAY?
• What was the last stream ID?
• Did active streams fail?
• Did client retry on a new connection?
• Does GOAWAY happen at fixed connection age?

RST_STREAM

RST_STREAM terminates one HTTP/2 stream. Causes include:

• Client cancellation.
• Server rejecting a request.
• Proxy timeout.
• Flow-control issue.
• Max stream limit.
• gRPC deadline exceeded.
• Backend reset translated by proxy.

The stream ID and timing matter. Without them, the packet story is incomplete.

TCP layer still matters

HTTP/2 sits on TCP. If the underlying connection has retransmissions, zero window, reset, MTU problems, or idle timeout, HTTP/2 errors may be secondary.

Correlate:

• Stream reset time.
• TCP retransmissions before reset.
• FIN/RST sender.
• Idle interval.
• TLS close_notify if visible.

Checklist

Use this workflow:

1. Preserve DNS, TCP, and TLS handshake.
2. Confirm ALPN negotiated HTTP/2.
3. Identify whether failure is stream-level or connection-level.
4. Look for GOAWAY timing and sender.
5. Look for RST_STREAM timing and stream ID in decrypted traces or logs.
6. Correlate with proxy/load-balancer logs.
7. Check TCP retransmission, zero window, FIN, and RST.
8. Check whether client retries correctly.
9. Preserve packet timing when trimming.
10. Combine pcap evidence with HTTP/2 debug logs when encrypted.

Final diagnosis

HTTP/2 GOAWAY and RST_STREAM errors are not generic network failures. They are stream and connection control signals that must be correlated with ALPN, proxy behavior, gRPC deadlines, TCP health, and connection reuse.

PCAP Surgery helps preserve the timeline so HTTP/2 and gRPC failures can be reduced to the right layer: TLS negotiation, stream reset, connection drain, proxy timeout, or TCP transport failure.