TCP SYN Flag
What it is (Definition)
The SYN flag is a TCP header control bit used to start a TCP connection. In the classic three-way handshake, the client sends a segment with SYN set to request a new connection, and the server responds with SYN+ACK to accept and synchronize sequence numbers. Because TCP is connection-oriented, SYN is one of the most important fields for interpreting “can’t connect” problems in packet captures.
Operationally, SYN also represents a resource decision. Servers and middleboxes may allocate state when they see SYN, which is why SYN floods can be a DoS vector and why many defenses focus on SYN handling.
Where it appears in the stack
SYN is a TCP (Layer 4) field. You will see it on any TCP connection establishment, including HTTPS, SSH, SMTP, database connections, and internal service calls. Even if application payloads are encrypted (TLS), the SYN handshake is still visible because it happens before encryption.
Handshake behavior at a glance
- Client → Server: SYN (initial request to open a connection).
- Server → Client: SYN,ACK (server accepts and acknowledges client’s sequence).
- Client → Server: ACK (connection established; data can flow).
If this sequence breaks, the symptom is usually “connection timeout” or “connection refused/reset,” and SYN packets are the fastest way to see where the failure occurs: before the server, at the server, or on the return path.
Common values and patterns (Value table)
| Flags pattern | Meaning | Where you see it | Notes |
|---|---|---|---|
| SYN | Connection request | Client initiating a new TCP connection | Often includes options (MSS, SACK, Window Scale) |
| SYN, ACK | Connection accepted | Server response | If absent, suspect filtering/routing/service not reachable |
| SYN repeated | Retries due to no response | Client side during failure | Indicates timeout or dropped return traffic |
| RST after SYN | Immediate refusal/reset | Server or middlebox | Can mean “port closed” or policy-based reset |
| SYN, ACK retransmitted | Server replied but client didn’t ACK | Server side during asymmetric loss | Return path/client filtering/NAT issues are common |
How it looks in Wireshark
Display filter example:
tcp.flags.syn == 1 && tcp.flags.ack == 0What you typically see:
- Initial SYN packets with TCP options that strongly influence performance (MSS, SACK, Window Scale).
- Whether SYN-ACK returns at all (basic reachability/policy signal).
- Handshake timing gaps that reveal drops, delays, or rate limiting.
Quick read tip: When a connection fails, first answer one question: “Do I see SYN-ACK coming back?” That single observation narrows the problem space dramatically.
Common troubleshooting patterns
SYN leaves, but SYN-ACK never returns
This usually indicates a drop on the forward path (client→server), a drop on the return path (server→client), or that the server is not reachable/listening. In captures, repeated SYNs without SYN-ACK is the signature. Confirm by capturing closer to the server or at the gateway to localize where packets disappear.
SYN-ACK returns, but the connection still fails
If the server sends SYN-ACK but the final ACK never arrives, the problem is often client-side filtering, NAT state, or asymmetric routing. Look for SYN-ACK retransmissions from the server and consider stateful devices between endpoints.
Related pages (internal links)
- Back to Fields Index
- Dictionary: TCP overview
- Topics Index (TCP three-way handshake — Soon)
- Dictionary Index