Linuxでポートは開いているのに接続できない理由

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

• ss や netstat では LISTEN している
• firewalld / iptables も許可済み
• それでも接続できない・タイムアウトする

この状態は、

「ポートが開いている＝通信できる」ではない

ことが原因です。

本記事では、

• なぜ LISTEN でも接続できないのか
• どこで通信が止まっているのか
• 実務での切り分け手順

を、Linux運用目線で体系的に解説します。

前提：LISTEN は「入口がある」だけ

以下の出力を見て安心してしまいがちです。

ss -lntp

LISTEN とは、

接続要求を受け取れる状態

であって、

• 処理できる
• 応答を返せる

ことを保証するものではありません。

原因1：アプリケーションが受け取れていない

よくあるのが、

• accept() 前で詰まっている
• ワーカースレッド枯渇

この場合、

• ポートは LISTEN
• 接続はタイムアウト

という現象が起きます。

確認方法

ss -antp | grep ポート番号

SYN-RECV が大量に溜まっている場合、 アプリ側が処理できていません。

原因2：バックログ（listen queue）が溢れている

Linuxでは、 接続要求は一度キューに積まれます。

このキューが溢れると、

• LISTENしている
• でも接続できない

状態になります。

確認ポイント

ss -lnt

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

原因3：ファイアウォールはOKだが途中で落とされている

firewalld や iptables を通っても、

• クラウドFW
• ロードバランサ
• セキュリティグループ

で遮断されているケースは非常に多いです。

確認方法

tcpdump -nn port ポート番号

SYN が来ていなければ、 Linux以前で落とされています。

原因4：バインドアドレスの問題

以下のようなケースです。

• 127.0.0.1 のみで LISTEN
• IPv6 のみで待ち受け

確認

ss -lntp

0.0.0.0 / :: で待ち受けているかを確認します。

原因5：SELinux による通信拒否

SELinux は、

• ポートは開いている
• でも接続は拒否

という挙動をします。

確認

getenforce

Enforcing の場合、 audit.log を必ず確認してください。

原因6：アプリが内部で固まっている

以下のような状態です。

• I/O待ち
• 外部API待ち
• DBロック待ち

この場合、

• ポートは開く
• レスポンスは返らない

という症状になります。

切り分けの基本フロー

1. ss で LISTEN と接続状態を見る
2. tcpdump で SYN が来ているか確認
3. アプリの処理詰まりを疑う
4. SELinux / クラウドFW を確認

まとめ

• LISTEN は「入口がある」だけ
• 接続不可はほぼ待ち・詰まり
• ネットワークだけでなくアプリ側も見る

「ポートは開いているのに繋がらない」時、

問題はポートの外ではなく中にあります。