目次
はじめに
TCP通信において RST(Reset)パケットが多発する 状態は、
「通信が強制的に切断されている」ことを意味します。
RSTは 正常系ではほぼ出ない ため、
- アプリ障害
- 設定ミス
- リソース枯渇
- FW / LB の挙動
など、何らかの異常が裏に隠れているサインです。
この記事では、
- RSTが送信される仕組み
- 実務で多い原因パターン
- 現場での切り分け手順
- 原因別の具体的対策
を体系的に解説します。
RSTとは何か(超重要ポイント)
RSTは以下のような状況で送信されます。
- 受信したTCPセグメントが 想定外
- 対応するソケットが 存在しない
- アプリが 即時切断を要求
- OS / FW が 異常通信と判断
つまり、
RST = 「その通信は受け付けられない」
という強い拒否メッセージです。
RSTが多発する代表的な原因
① アプリが listen していないポートに接続している
典型例
- サービス停止中
- bind 失敗
- 起動直後に接続が来ている
確認方法
ss -lntp
netstat -lntp
ポートが LISTEN していなければ、
接続元には 即RST が返ります。
対策
- systemd 起動順序を見直す
- LB 側のヘルスチェック開始タイミングを遅らせる
- アプリ起動完了前に通信を流さない
② アプリが accept しきれず強制切断している
発生条件
- backlog が小さい
- 同時接続数が急増
- accept() が詰まっている
確認ポイント
ss -s
ss -ant | grep SYN-RECV | wc -l
SYN-RECV が大量に溜まり、その後RSTが返る場合、
アプリの処理能力不足です。
対策
- アプリ側のスレッド数・ワーカー数増加
- backlog 設定見直し
- 短命接続の削減(KeepAlive有効化)
③ ファイルディスクリプタ枯渇
FDが枯渇すると、新しいソケットを作れず RSTで切断されます。
確認方法
ulimit -n
cat /proc/sys/fs/file-nr
lsof -n | wc -l
よくある症状
- 接続直後にRST
- 時間帯によってのみ発生
- 再起動で一時的に直る
対策
- ulimit の引き上げ
- systemd LimitNOFILE 設定
- 不要なコネクションのリーク修正
④ FW / iptables / firewalld が RST を返している
FWは DROPではなくREJECT(RST) を返す設定が可能です。
確認方法
iptables -L -n -v
iptables -S
firewall-cmd --list-all
典型ミス
- REJECT –reject-with tcp-reset
- 想定外ポートへの通信
対策
- DROPに変更する
- 通信設計を明確化
- FWとアプリ設計の責務分離
⑤ ロードバランサ(LB)がRSTを返している
ALB / NLB / L4LB などは以下でRSTを返します。
- ターゲットが Unhealthy
- idle timeout 超過
- backend 接続失敗
切り分け
tcpdump -nn host 接続先IP
RSTが LB側IPから来ているか を確認。
対策
- idle timeout 延長
- アプリ KeepAlive 設定
- ヘルスチェック条件の見直し
⑥ TIME_WAIT / ポート枯渇の副作用
クライアント側でポートが枯渇すると、
接続開始時点でRST になることがあります。
確認方法
ss -ant | grep TIME-WAIT | wc -l
cat /proc/sys/net/ipv4/ip_local_port_range
対策
- エフェメラルポート拡張
- 短命TCP接続の削減
- コネクションプール導入
実務的な切り分け手順
Step 1:どこからRSTが来ているか
tcpdump -nn tcp and tcp[tcpflags] & tcp-rst != 0
- クライアント?
- サーバ?
- LB?
Step 2:アプリは生きているか
ss -lntp
ps aux | grep アプリ名
Step 3:リソース枯渇チェック
ulimit -n
ss -s
free -m
Step 4:FW / SELinux の影響排除
getenforce
iptables -L -n
まとめ
RST多発は 「TCPレベルの異常通知」 であり、
- アプリ
- OS
- ネットワーク
- LB
の どこかで設計 or 設定が破綻している サインです。
重要なのは、
❌ RSTを止める
✅ RSTを出している原因を潰す
この視点です。
あわせて読みたい


TIME_WAITが大量発生する原因と対策
Linuxサーバーでネットワーク遅延や接続エラーが増えた際、 ss や netstat を確認すると TIME_WAIT が大量に残っているケースがあります。 TIME_WAIT自体は異常ではあり…
あわせて読みたい


エフェメラルポート枯渇の見抜き方と対処法【TIME_WAITとの関係を理解する】
Linuxサーバーで「突然外部通信ができなくなった」「再起動すると一時的に直る」 といった障害の原因として、見落とされがちなのが エフェメラルポート枯渇です。 本記…
あわせて読みたい


LinuxでTCP接続数が増え続ける原因と対策【調査から設計改善まで】
Linuxサーバーを運用していると、 「TCP接続数が時間とともに増え続け、減らない」 という現象に遭遇することがあります。 この状態を放置すると、 通信遅延 エフェメラ…
