LinuxでSYN-RECVが溜まり続ける原因と対処法

Linuxサーバーの通信トラブル調査中、以下のような状態に遭遇したことはないでしょうか。

• ss や netstat で SYN-RECV が大量に表示される
• 時間が経っても減らない
• クライアントからの接続が遅い・失敗する

この状態は、

「接続要求は来ているが、接続が完了していない」

ことを意味します。

本記事では、

• SYN-RECV が示す正しい意味
• 溜まり続ける典型的な原因
• 実務での切り分けと対処法
• どこまで直れば解決と判断できるか

を、Linux運用者向けに整理して解説します。

SYN-RECVとは何が起きている状態か

TCP通信は以下の流れで接続されます。

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

SYN-RECV とは、

サーバーが SYN/ACK を返し、ACK 待ちの状態

です。

つまり、

• 通信要求は届いている
• サーバーも応答している
• 最後の ACK が返ってきていない

という、途中で止まっている状態です。

確認方法：SYN-RECVの見方

ss -ant | grep SYN-RECV

この状態が、

• 一時的に出る → 正常
• 増え続ける → 異常

と判断します。

解決の判断基準：
SYN-RECV が短時間で消え、ESTABLISHED に移行する

原因1：クライアント側がACKを返していない

最も多い原因です。

• クライアントが高負荷
• 通信途中でFWに落とされている
• ロードバランサ配下の死活異常

確認方法

tcpdump -nn port ポート番号

SYN/ACK に対する ACK が返ってこない場合、 クライアント側の問題です。

原因2：サーバー側のバックログ枯渇

接続要求は、

listen キュー（バックログ）

に一度溜められます。

このキューが溢れると、

• SYN-RECV が溜まる
• 新規接続が完了しない

状態になります。

確認ポイント

ss -lnt

Recv-Q / Send-Q が上限に近い場合、 バックログ不足を疑います。

対処：
アプリの backlog 設定や net.core.somaxconn を見直します。

原因3：ファイアウォール・セキュリティ機器での遮断

途中経路で、

• SYN は通る
• ACK が落とされる

ケースは非常に多いです。

特に、

• WAF
• IPS/IDS
• クラウドFW

では頻発します。

切り分け

サーバー側で SYN/ACK が出ているかを tcpdump で確認します。

原因4：SYN flood などの攻撃

大量の SYN を送り、 ACK を返さない攻撃です。

この場合、

• SYN-RECV が大量に残る
• 正規ユーザーも接続できない

状態になります。

確認

ss -ant | grep SYN-RECV | wc -l

異常に多い場合、 SYN flood を疑います。

対処：
SYN cookie を有効化する

原因5：アプリケーションのaccept遅延

アプリが、

• 高負荷
• スレッド枯渇

状態だと、 accept() が遅れ SYN-RECV が増えます。

確認

ESTABLISHED に移行せず、 SYN-RECV が残り続ける場合は アプリ側を疑います。

実務的な切り分けフロー

1. ss で SYN-RECV 数を確認
2. tcpdump で ACK が返っているか確認
3. バックログ・キューの状態を見る
4. FW / LB / 攻撃を疑う
5. 最後にアプリの負荷を見る

まとめ

• SYN-RECV は「接続途中で止まっている状態」
• 溜まり続けるのは異常
• 原因はクライアント・経路・サーバーの3方向

SYN-RECV が減らず困った時は、

「ACKがどこで消えているか」

を追うことで、原因に辿り着けます。