この2つのエラーメッセージは、どちらも「つながらない」という結果は同じですが、原因の場所がまったく異なります。エラーの意味を理解せずにむやみに設定を変更しても問題は解消しません。調査の方向性を誤れば、無関係な変更を重ねるばかりで時間を浪費します。
この記事では、RHEL 9系（Rocky Linux 9）およびUbuntu 24.04 LTSを想定環境として、Connection refusedとConnection timed outそれぞれの意味と、ss・systemctl・firewall-cmdを使った3段階の切り分け手順を解説します。
この記事のポイント
・Connection refusedはパケットが届いているがポート/サービス側に問題がある
・Connection timed outはパケット自体が届いていないネットワーク/ファイアウォール側の問題
・ssコマンドでListenポート確認→systemctlでサービス確認→firewall-cmdでルール確認の順で調査
・iptables -nvLのpktsカウンタが増えているルールが遮断箇所の手がかりになる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「Connection refused」と「Connection timed out」の根本的な違い
2つのエラーメッセージは、TCPの動作レベルで意味が異なります。Connection refused（接続拒否）は、送ったパケットが相手ホストに届いており、相手のOSがRST（リセット）パケットを返してきた状態です。パケットは相手に着いています。問題はパケットが届いた後の処理にあります。主な原因は次の3つです。
・指定したポートでサービスが起動していない（または指定ポートが間違っている）
・ファイアウォールがREJECTルールで拒否している（DROPと異なりRSTを返す）
・サービスが127.0.0.1などのloopbackアドレスにしかBindしておらず外部接続を受け付けていない
Connection timed out（接続タイムアウト）は、送ったパケットが相手に届かず、一定時間待っても何の応答も返ってこない状態です。パケットが経路のどこかで「消えている」か「止まっている」ことを意味します。主な原因は次の3つです。
・ファイアウォールがDROPルールでパケットを破棄している
・ネットワーク経路に問題がある（ルーティング誤設定・物理断・クラウドVPC設定ミスなど）
・クラウド環境のセキュリティグループやNACLがトラフィックを遮断している
この違いを念頭に置くと、調査の出発点が変わります。Connection refusedはサーバー側（ポート・サービス状態・REJECT設定）から調べ、Connection timed outはネットワーク経路（ping・firewalld）から調べます。
「Connection refused」が出た時の3段階調査
1. ssコマンドでポートがListenしているか確認する
最初に確認すべきは「そのポートでサービスが待ち受けているか」です。Linux ポート確認の全コマンドにまとめているとおり、現在のLinux環境ではssコマンドが標準です。# ListenしているTCPポートをプロセス名付きで一覧表示する ss -tlnp # 特定ポート（例: 80番）に絞って確認する ss -tlnp | grep ':80' # 出力例（環境により異なります） State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("httpd",pid=1234,fd=4))
LISTEN行が表示されれば、そのポートでプロセスが待ち受けています。出力が空であれば、サービスが起動していないか、想定外のポートでListenしている可能性があります。また、
Local Addressが127.0.0.1:80のようにloopbackアドレスになっている場合、外部からのアクセスは受け付けません。サービスの設定ファイルでListenアドレスを0.0.0.0または::（IPv6全体）に変更する必要があります。2. systemctl statusでサービスが起動しているか確認する
ssで対象ポートが見つからない場合、次はsystemctlでサービスの状態を確認します。# HTTPDサービスの状態を確認する（例） systemctl status httpd # 出力例（環境により異なります） * httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled) Active: inactive (dead)
Active: inactive (dead)と表示されていればサービスが停止しています。failedの場合は起動に失敗した状態です。起動するには以下を実行します。# サービスを起動する systemctl start httpd # OS再起動後も自動起動させる場合 systemctl enable httpd
# サービスのログを直近20行確認する journalctl -u httpd --no-pager | tail -20
3. ファイアウォールがREJECTで拒否していないか確認する
ssでポートがListenしており、サービスも起動しているのにConnection refusedが出る場合、ファイアウォールがREJECTルールで拒否している可能性があります。# firewalldのアクティブゾーンとルールを確認する firewall-cmd --list-all # 出力例（環境により異なります） public (active) target: default interfaces: eth0 services: ssh dhcpv6-client ports:
# ポートを一時的に開放して確認する（再起動で元に戻る） firewall-cmd --add-port=80/tcp # 疎通が確認できたら永続化する firewall-cmd --add-port=80/tcp --permanent firewall-cmd --reload
# iptablesのルールとパケットカウンタを確認する iptables -nvL # 出力例（環境により異なります） Chain INPUT (policy ACCEPT) pkts bytes target prot opt in out source destination 37 2220 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
pktsの値が増加していれば、そのルールにマッチしたパケットが存在します。「Connection timed out」が出た時の3段階調査
1. pingとtracerouteでネットワーク疎通を確認する
まずネットワーク経路が通っているかを確認します。# ホストへの到達確認（4パケット送信） ping -c 4 <接続先IPまたはホスト名> # ネットワーク経路を確認する traceroute <接続先IP> # または tracepath <接続先IP>
pingも通らない場合：ネットワーク経路そのものに問題があります。ルーティングの設定ミス（
ip route showで確認）や、クラウド環境のVPC設定・セキュリティグループを確認します。2. firewall-cmdのDROPルールとパケットカウンタを確認する
pingが通るがTCPポートへの接続がタイムアウトする場合、DROPルールが疑われます。# firewalldのルールを確認する firewall-cmd --list-all # iptablesのDROPルールとカウンタのみ抽出する iptables -nvL | grep DROP # 出力例（環境により異なります） 128 7680 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
pktsが増えているDROPルールがあれば、そこでパケットが破棄されています。iptablesでどのルールにマッチしているかを動的に確認するには、
watch -n 2 'iptables -nvL'でカウンタの変化をリアルタイムで監視しながら接続を試みると、どのルールがヒットしているかがわかります。3. それでも解消しない場合の追加確認事項
サービスが起動しており、ファイアウォールルールにも問題が見当たらないのにConnection timed outが続く場合は、次を確認します。SELinuxによる通信制限：SELinuxが有効な環境では、設定済みポート以外へのBindや通信をdeniedにすることがあります。
# SELinuxのアクセス拒否ログを確認する grep 'denied' /var/log/audit/audit.log | tail -20 # SELinuxの現在の状態を確認する sestatus
カーネルパラメータによる接続数制限：高トラフィック環境では
net.core.somaxconnやnet.ipv4.tcp_max_syn_backlogが不足して新規接続がタイムアウトすることがあります。# 現在の設定値を確認する（出力例） sysctl net.core.somaxconn # net.core.somaxconn = 128 sysctl net.ipv4.tcp_max_syn_backlog # net.ipv4.tcp_max_syn_backlog = 512
/etc/sysctl.confに設定を追記してsysctl -pで反映します。よくあるシナリオ別・原因と対処の早見表
| 状況 | エラー | 原因 | 最初に使うコマンド |
|---|---|---|---|
| SSHで接続できない | Connection refused | sshd停止またはポート変更 | ss -tlnp | grep ssh |
| HTTPSが開かない | Connection refused | httpd/nginx停止またはポート443でListen未 | ss -tlnp | grep ':443' |
| pingは通るが接続できない | Connection timed out | firewalldのDROPルール | firewall-cmd --list-all |
| クラウドVMに外部から接続できない | Connection timed out | セキュリティグループの遮断 | Linux側確認後にクラウドコンソールを確認 |
| ローカルからは接続できるが外部から接続できない | Connection refused | Listenアドレスが127.0.0.1のみ | ss -tlnpでLocal Addressを確認 |
本記事のまとめ
Connection refusedとConnection timed outの切り分けポイントをまとめます。| 観点 | Connection refused | Connection timed out |
|---|---|---|
| パケットの到達 | ○ 相手に届いている（RSTが返る） | × 届いていない（無応答） |
| 主な原因 | サービス停止・ポート違い・REJECT | DROPルール・ネットワーク経路断・クラウド遮断 |
| 最初に確認するコマンド | ss -tlnp / systemctl status |
ping / traceroute |
| ファイアウォール確認のポイント | REJECTルールのpktsカウンタ | DROPルールのpktsカウンタ |
こうした切り分けスキルをはじめ、Linuxサーバー管理に必要な技術を体系的に学びたい方は、Linux Master Pro Seminarをご覧ください。20年以上の指導実績をもとに、現場で通用するLinuxスキルを2日間のハンズオンで習得できます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
Linuxサーバー構築入門マニュアル（図解60P）を無料でプレゼントしています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：bpftraceコマンドの使い方｜LinuxのI/O遅延・システムコールをワンライナーで解析する実践手順
- この記事の属するカテゴリ：Linuxトラブルシューティングへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます