Diagnose TCP resets by reading the conversation, not just the RST

To diagnose a TCP reset, find the RST, isolate its connection, and read what happened before and after it. Then check whether the receiving endpoint could accept it and whether another capture or system log confirms its origin.

The RST identifies a transport event, not a root cause. An application can request a reset, but TCP can also generate one when a packet arrives for a connection that no longer exists. An accepted reset aborts an established connection; a FIN normally closes one direction of it in an orderly way. These distinctions come from the TCP specification, RFC 9293.

Work only with traffic and systems you own or are authorized to inspect. Keep captures private; redact payloads, tokens, addresses and identifiers before sharing diagnostic extracts.

1. Find the resets, then restore the conversation

In Wireshark, use this display filter:

tcp.flags.reset == 1

Select a reset and expand Transmission Control Protocol in the packet details. Record its frame number, timestamp, endpoint addresses and ports, flags, sequence number, acknowledgment number and stream index. Keep endpoint identities in your private notes; use redacted labels in shared extracts.

If its stream index is 7, replace the reset-only filter with:

tcp.stream == 7

Use the stream index from your own file. The Wireshark TCP field reference documents these fields, including tcp.flags.reset, tcp.stream, tcp.seq and tcp.ack.

Keep the whole stream visible while diagnosing. A reset-only view hides the handshake, retransmissions, idle periods and earlier close that may explain the reset. Check:

• Was there a SYN → SYN/ACK → ACK handshake?
• Did either direction carry data?
• Which direction sent the first RST?
• What was the last packet before it, and how long was the gap?
• Were there earlier FINs or RSTs?
• Does traffic continue afterward on the same connection, or does a new SYN begin another connection?

A reused address-and-port pair is not necessarily the same connection. Wireshark can flag a new SYN with different initial sequence numbers as TCP Port numbers reused; its TCP analysis guide explains that classification.

2. Check whether the capture can support the diagnosis

Before interpreting an absent packet as network loss, check how the capture was made:

• Location: client host, server host, switch mirror, tunnel interface or another point?
• Coverage: both directions, including the handshake and enough time after the reset?
• Completeness: restrictive capture filters, truncated packets, reported capture drops or gaps?
• Offloading: was this an endpoint capture made before the NIC completed transmission processing?

Wireshark’s Previous segment not captured and ACKed unseen segment annotations describe gaps in what it observed. Its retransmission and out-of-order labels are analysis results, and their interpretation can vary with capture location and available context. Treat them as leads, not independent proof of packet loss. See the TCP analysis documentation.

Likewise, a bad TCP checksum on a locally generated packet can be an offloading artifact: Wireshark may see it before hardware supplies the final checksum. Do not conclude that a reset was malformed on the wire from that annotation alone. The Wireshark checksum guide explains this capture effect.

3. Classify the pattern before choosing a cause

Pattern in the stream	Working interpretation	Next check
SYN followed by RST/ACK, without SYN/ACK	Connection attempt rejected; a closed port is one explanation	Verify the intended destination, listener and rejection policy
Completed handshake, then RST near the first data	Attempt to abort an established connection	Check reset acceptance, then correlate application, TLS and proxy logs
Long idle gap, then data followed by RST	One participant may have expired or discarded connection state	Compare idle-timeout settings and connection-pool reuse
Repeated unacknowledged data, then RST	The reset may be the final abort after an earlier stall	Compare captures in both directions and check timeout logs
Earlier close, then a late packet followed by RST	A response to stale traffic may explain this reset	Find the earlier close before blaming the last RST for the failure

These are hypotheses, not signatures that uniquely identify a cause. RFC 9293 specifies that a TCP endpoint in CLOSED responds to incoming non-RST segments with a reset; it also permits application-requested resets and describes reset behavior when a close leaves received data unread. Consequently, RST/ACK does not prove an application rejected a request. The ACK flag makes the acknowledgment field meaningful; it is not an application-level success indicator. See RFC 9293’s reset and close rules.

Network devices can also generate resets. For a concrete example, AWS documents that its Network Load Balancer returns a RST when data arrives on a flow whose idle timeout has expired. That is evidence about that service, not a universal timeout rule for every firewall or load balancer. Check the documentation and configuration for the device actually in your path. See AWS’s Network Load Balancer troubleshooting guide.

4. Check sequence numbers and receiver behavior

A captured RST is not automatically an accepted RST.

For an ordinary SYN without payload, a reset response acknowledging the SYN should acknowledge its sequence number plus one, wrapping to zero at the end of the 32-bit sequence space. SYN occupies one position in TCP sequence space. During SYN-SENT, the reset’s acknowledgment must acknowledge the SYN to be acceptable. These rules are specified in RFC 9293.

For an established connection, compare the reset’s sequence number with what its receiver next expected from that direction. The receiver’s preceding ACK is a useful starting point, provided no intervening data or FIN advanced its receive state.

This constructed example uses relative sequence numbers and endpoint labels, not a production capture. Assume no intervening packets:

Direction	Flags	Seq	Ack	TCP payload length
Client → Server	ACK	201	901	0
Server → Client	RST	901	—	0

The client advertised that it next expected server byte 901. The server-direction RST uses sequence 901, making it an exact-match reset candidate. The acknowledgment field is not interpreted here because the RST has no ACK flag.

Under RFC 5961’s reset-validation rules, an exact match resets the connection; an in-window but non-exact sequence number triggers a challenge ACK and the RST is discarded; an out-of-window RST is silently discarded. Apply this interpretation to endpoints implementing those rules, and inspect subsequent packets rather than assuming acceptance.

For an in-window check, use the receiver’s advertised window, accounting for negotiated window scaling. Wireshark exposes the calculated value as tcp.window_size; if the handshake is missing, the scale factor may be unknown. See the TCP field reference and window-scaling explanation.

A RST → ACK → RST exchange can therefore be legitimate reset validation, not simply a retransmitted reset. Missing packets or data in flight can also make the receiver’s exact state uncertain.

Wireshark and TShark normally display relative sequence numbers. When comparing different capture files, use tcp.seq_raw and tcp.ack_raw, or disable relative numbering: files that start at different points can have different relative baselines.

5. Confirm where the reset appeared

The source address tells you which endpoint the packet represents, but a single observation point may not establish which host or network device generated it. Capture simultaneously at both endpoints when possible, or on both sides of a suspected device.

Compare the same exchange using direction, ports, flags, raw sequence/acknowledgment numbers, payload lengths and timing. Stream indexes are local to each file; do not use matching tcp.stream values as a cross-file identity test.

• RST visible outbound at the server and inbound at the client: supports server-side generation. Check server process, socket and application logs for the reason.
• RST visible at the client but absent from a complete server-side capture: investigate intervening devices—but first rule out capture gaps, the wrong interface and alternate paths.
• RST seen at its sender but not its receiver: investigate delivery; the receiver may instead remain open until another event or timeout.

Allow for clock offsets when comparing timestamps. If a proxy terminates TCP, diagnose its client-side and upstream connections separately rather than expecting identical sequence numbers across them.

For a compact local timeline, TShark can extract transport fields without printing payloads or addresses. In a POSIX shell:

tshark -r incident.pcapng -Y 'tcp.stream == 7' \
-T fields -E header=y \
-e frame.number -e frame.time_relative \
-e tcp.srcport -e tcp.dstport \
-e tcp.flags -e tcp.seq_raw -e tcp.ack_raw \
  -e tcp.len -e tcp.time_delta

Replace the filename and stream index with yours. This uses TShark’s documented file-reading, display-filter and field-output options. The extract still contains timing and connection metadata; review it before sharing.

Finish the diagnosis with observation, interpretation and confirmation, not just “server reset.” For example: “The server-direction RST followed the first post-idle data packet. Expired connection state is a hypothesis; confirm it against device timeout settings and a server-side capture.” For encrypted traffic, transport behavior remains useful even when the application reason is hidden—see what HTTPS leaves visible in a packet capture.