ssでESTABLISHEDなのに通信できない時の原因と確認ポイント

Linuxサーバーで以下のような状況に直面したことはないでしょうか。

• ss では ESTABLISHED と表示されている
• 接続自体は確立している
• しかし通信が返ってこない／処理が進まない

この状態は、

「ネットワークは繋がっているが、通信が成立していない」

という、非常に切り分けが難しいトラブルです。

本記事では、

• ESTABLISHED の正しい意味
• 通信できない代表的な原因
• どこを確認すれば解決と判断できるのか

を、実務トラブルシューティングの視点で解説します。

前提：ESTABLISHEDは「通信できている」ではない

まず誤解されやすいポイントです。

ESTABLISHED とは、

TCPの3ウェイハンドシェイクが完了した状態

を示しているだけです。

つまり、

• データが送れている
• レスポンスが返っている

ことは一切保証されません。

原因1：アプリケーションが詰まっている

最も多い原因です。

以下のような状態では、

• TCP接続は確立
• アプリが処理できず無応答

となります。

• スレッド枯渇
• 外部API待ち
• DBロック待ち

確認方法

ss -antp | grep ESTAB

接続数が増え続けている場合、 アプリ側で詰まりが起きています。

解決の判断基準：
接続数が減少し、レスポンスが返るようになる

原因2：送信・受信バッファが詰まっている

送受信バッファが詰まると、

• ESTABLISHED のまま
• 通信が進まない

状態になります。

確認ポイント

ss -ti

Send-Q / Recv-Q が増え続けている場合、 データが滞留しています。

解決の判断基準：
Send-Q / Recv-Q が減少し、滞留が解消される

原因3：相手側が応答していない

ESTABLISHED は

一方向だけ成立している

可能性もあります。

相手側で、

• アプリ停止
• 高負荷
• FW遮断

が起きていると、 接続は維持されても応答はありません。

確認方法

tcpdump -nn host 相手IP

ACK が返ってこない場合、 相手側に問題があります。

原因4：MTU不一致・フラグメント問題

MTU不一致があると、

• 小さい通信は通る
• 大きい通信で止まる

という現象が起きます。

その結果、 ESTABLISHED のまま通信が進みません。

確認

ping -M do -s 1472 相手IP

解決の判断基準：
フラグメントなしで疎通できる

原因5：SELinuxによる通信制限

SELinuxは、

• 接続は許可
• 処理は拒否

という挙動を取ることがあります。

確認

getenforce

Enforcing の場合は、 audit.log を確認します。

原因6：カーネルリソース枯渇

以下の枯渇でも、 通信は止まります。

• ファイルディスクリプタ不足
• ephemeral port 枯渇

確認

ss -s

接続数が異常に多い場合、 リソース不足を疑います。

切り分けの実務フロー

1. ss で ESTABLISHED 数とキューを見る
2. tcpdump で双方向通信を確認
3. アプリ側ログ・処理状況を確認
4. MTU / SELinux / リソース枯渇を疑う

まとめ

• ESTABLISHED＝通信成功ではない
• 多くはアプリ or 待ち状態が原因
• キューと応答の有無を見ることが重要

ESTABLISHED なのに通信できない場合、

「ネットワークは問題ない」と切り捨てないことが解決への近道です。