3way handshakeで止まる時の完全診断ガイド【SYN/SYN-ACK/ACKのどこで詰まるかを見抜く】

TCP通信ができないとき、

ほとんどの原因は3way handshakeのどこかで止まっています。

しかし現場では、

• 「FWは開いているはず」
• 「pingは通る」
• 「ポートはLISTENしている」

という状態で原因特定に時間がかかります。

本記事では、

• 3way handshakeの各段階の意味
• 止まる位置別の原因一覧
• tcpdumpによる正しい確認方法
• 確定診断のポイント
• 解決したと言える基準

を、実務レベルで解説します。

まず整理：3way handshakeとは

1. Client → Server : SYN
2. Server → Client : SYN-ACK
3. Client → Server : ACK

この3段階が完了して初めてTCP接続は確立します。

止まる位置が分かれば、原因はほぼ特定できます。

診断の基本：tcpdumpで必ず両方向を見る

tcpdump -nn host 相手IP and port ポート番号

見るべきは：

• SYNが来ているか
• SYN-ACKが出ているか
• ACKが戻っているか

パターン①：SYNが届かない

症状

• サーバ側でSYNが見えない
• クライアントは再送を繰り返す

原因

• 中間FWでTCPのみ遮断
• ACL誤設定
• ルーティング誤り
• 宛先ポートのNAT不備

確認方法

• FWログ確認
• 経路上の中間機器でtcpdump

解決条件

サーバ側でSYNが確認できること。

パターン②：SYNは来るがSYN-ACKが出ない

症状

• tcpdumpでSYNのみ確認
• SYN-ACKが返らない

原因

• ポート未LISTEN
• iptables/firewalld拒否
• tcp_wrappers制御
• backlog枯渇（acceptキュー溢れ）

確認コマンド

ss -lnt
iptables -L -n
ss -s

解決条件

SYN-ACKが確実に出力されること。

パターン③：SYN-ACKは出るがACKが戻らない

症状

• サーバでSYN-ACK確認
• ACKが来ない
• SYN-RECVが溜まる

原因

• 戻り経路不一致（非対称ルーティング）
• NATセッション未作成
• クライアント側FW拒否
• rp_filterで破棄

確認方法

netstat -nat | grep SYN_RECV
sysctl net.ipv4.conf.all.rp_filter

解決条件

ACKがサーバ側で確認できること。

パターン④：接続確立後すぐ切れる

症状

• ESTABLISHEDになる
• 直後にRST/FIN

原因

• MTU不一致
• MSS未調整
• アプリ側エラー
• WAF/IPSによる遮断

確認

ping -M do -s 1472 相手IP

解決条件

データが継続的に送受信できること。

3way handshake停止の即断フローチャート

1. SYNが見える？ → NO → FW/経路問題
2. SYN-ACK出ている？ → NO → サーバ設定問題
3. ACK戻る？ → NO → 戻り経路/NAT問題
4. ESTABLISHED維持？ → NO → MTU/アプリ問題

この順で必ず原因に到達します。

再送（retransmission）が多い場合

tcpdumpで以下が見えた場合：

[TCP Retransmission]

これは、

• 相手が応答していない
• 途中で破棄されている

ことを意味します。

再送は「ネットワークが悪い」のではなく、

どこかで止まっている証拠

です。

解決したと言える状態

• 3way handshakeが毎回成功する
• SYN-RECVが溜まらない
• 再送が発生しない
• ESTABLISHEDが安定する

まとめ

3way handshakeで止まる原因は、

止まる位置で決まります。

• SYN届かない → 経路/FW
• SYN-ACK出ない → サーバ設定
• ACK戻らない → 非対称/NAT
• 確立後切断 → MTU/アプリ

tcpdumpで段階を可視化すれば、必ず解決できます。