TCPコネクションが確立しない時の原因と確認手順（SYN/ACK解析）

「pingは通るのにアプリケーション通信ができない」
「特定のポートだけ接続できない」

このようなトラブルの多くは、TCPコネクション確立（3ウェイハンドシェイク）の どこかで失敗しています。

本記事では、SYN / SYN-ACK / ACK の動きを軸に、 TCPコネクションが確立しない原因と、実務での確認手順を体系的に解説します。

TCPコネクション確立の基本（3ウェイハンドシェイク）

TCP通信は、以下の手順で接続が確立します。

1. クライアント → サーバ：SYN
2. サーバ → クライアント：SYN-ACK
3. クライアント → サーバ：ACK

このどこかが欠けると通信は開始されません。

まず行うべき初動切り分け

確認ポイント

• IP疎通（ping）は可能か
• 対象ポート番号は正しいか
• TCPかUDPかを誤っていないか

pingが通っても、TCPは別物です。

ケース① SYNが送信されていない

症状

• 接続要求が一切発生しない
• tcpdumpでSYNが見えない

確認コマンド例（クライアント側）

tcpdump -i eth0 tcp port 443

主な原因

• アプリケーション設定ミス
• 宛先IP・ポートの誤り
• ローカルFWで送信前に遮断

対処例

アプリ設定・e、OSの送信フィルタ（iptables / Windows FW）を確認します。

ケース② SYNは送信されるが SYN-ACK が返らない

症状

• SYN再送を繰り返す
• 接続タイムアウト

パケット例

SYN → SYN → SYN（再送）

主な原因

• サーバ側FWで遮断
• FW・ACL・NAT設定ミス
• サーバが起動していない／ポート未Listen

確認コマンド例（サーバ側）

ss -lnt

結果の見方

対象ポートが LISTEN 状態でなければ、SYN-ACK は返りません。

ケース③ SYN-ACK は返るが ACK が返らない

症状

• サーバ側で接続が確立しない
• FWログに一方向通信の記録

パケットの流れ

SYN → SYN-ACK → （ACKなし）

主な原因

• 戻り通信がFWで遮断
• 非対称ルーティング
• NAT設定不整合

実務ポイント

TCPは往復経路が一致していることが前提です。

ケース④ RSTが返される

症状

• 即座に接続失敗

パケット例

SYN → RST

主な原因

• ポート未開放
• アプリ未起動
• FWによる拒否応答

判断ポイント

RSTは「拒否された」ことを意味し、経路自体は生きている可能性が高いです。

FW・NAT環境での注意点

• ステートフルFWでセッションが確立しているか
• NAT変換後のIP・ポートを確認
• タイムアウト設定が短すぎないか

SYN/ACK解析は、FWログと必ずセットで行います。

トラブル対応の実践手順まとめ

1. pingでIP疎通確認
2. tcpdump / WiresharkでSYN確認
3. SYN-ACKの有無を確認
4. ACKが返っているか確認
5. FW・NAT・ルーティングを見直す

まとめ

• TCP通信トラブルはSYN/ACKを見ると一気に整理できる
• ping成功＝TCP成功ではない
• 一方向通信・戻り経路が最大の落とし穴

TCPコネクション解析を理解すると、 「つながらない理由」を論理的に説明できるエンジニアになります。