net.ipv4.tcp_max_syn_backlog を触る前の判断基準

Linux のネットワークチューニングで、

• SYN-RECV が溜まっている
• 接続が遅い・不安定

といった状況を見ると、

tcp_max_syn_backlog を増やせば解決するのでは？

と考えがちです。

しかし、このパラメータは

条件を間違えると逆効果になる代表例

でもあります。

本記事では、

• tcp_max_syn_backlog の役割
• 変更を検討すべき「具体条件」
• 触ってはいけない典型ケース

を実務判断できるレベルで整理します。

tcp_max_syn_backlog とは何か

tcp_max_syn_backlog は、

SYN を受信してから accept されるまでの待ち行列の最大数

を制御します。

対象となるのは、

• 状態：SYN-RECV
• まだアプリに渡っていない接続

です。

まず理解すべき重要な前提

SYN-RECV が増える原因は、

• クライアントが多い
• サーバが遅い
• ネットワークが不安定

など 複数あります。

tcp_max_syn_backlog は、

「受け皿を広げる」だけで原因を解決しません。

変更を検討してよい具体条件

条件①：SYN-RECV が一時的に溜まる

確認コマンド

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

以下のような特徴がある場合です。

• ピーク時のみ増える
• 時間が経てば減る

これは

瞬間的に接続要求が集中しているだけ

の可能性があります。

条件②：再送（retransmission）がほぼない

netstat -s | grep -i retrans

再送が少ない場合、

• ネットワークは健全
• 接続要求自体は正しく届いている

と判断できます。

条件③：アプリの accept が追いついている

以下を確認します。

• Recv-Q が溜まっていない
• CPU idle に余裕がある

この状態で SYN-RECV だけが溜まる場合、

backlog 拡張は有効な選択肢

になります。

触ってはいけない典型ケース

ケース①：SYN-RECV が減らない

常に大量の SYN-RECV が存在する場合、

• SYN flood
• 通信経路問題

の可能性があります。

この状態で backlog を増やすと、

メモリ消費と被害を拡大するだけ

です。

ケース②：再送が多い

再送が多い場合、

• SYN-ACK が届いていない

という状態です。

これは backlog ではなく、

• ネットワーク品質
• FW / LB / MTU

を疑うべきです。

ケース③：アプリ側が遅い

以下が見られる場合です。

• Recv-Q が溜まる
• アプリログに処理遅延

この場合、

accept backlog を増やしても意味はありません。

変更例（検証前提）

sysctl -w net.ipv4.tcp_max_syn_backlog=4096

必ず一時変更で効果確認を行います。

改善が確認できた場合のみ永続化します。

変更後に必ず確認する指標

• SYN-RECV の推移
• 接続エラーの減少
• 再送数の増減

改善が見られない場合、

元に戻す判断も正解

です。

よくある誤解

• backlog を増やせば安定する → ×
• SYN-RECV＝必ず backlog 不足 → ×
• DoS 対策になる → ×

まとめ

• tcp_max_syn_backlog は「条件付き対処」
• SYN-RECV の性質を見極めることが最重要
• 原因不明のまま触らない

tcp_max_syn_backlog を触る前に、

「なぜ SYN-RECV が溜まっているのか説明できるか」

これができなければ、変更すべきではありません。