この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
Linuxサーバーの障害対応で、こういう状況に直面したことがあるでしょうか。
ネットワーク自体は生きている、でもサービスには接続できない。原因がまったく分からず、焦るだけで時間が過ぎていく——私がSE時代にこの状況を初めて経験したのは、客先の本番Apacheサーバーが突然応答しなくなったときのことです。
この記事では、20年以上Linuxサーバーを運用してきた経験と、3,100名以上のエンジニアを指導してきた立場から、「pingは通るのにサービスに繋がらない」という状況の原因と切り分け手順を、私自身の体験談を交えながら解説します。ネットワーク層とアプリケーション層の違いを正しく理解することが、Linux現場での問題解決速度を大きく変える出発点になります。
この記事のポイント
・「pingが通る」と「サービスが動いている」は全く別レイヤーの問題
・切り分けはIPレイヤー→ポート→プロセス→ログの順で進める
・ssコマンドとjournalctlを組み合わせれば原因の9割は特定できる
・受講生が詰まるのは「どのレイヤーの問題か」という視点が抜けているから
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
SE時代のあの日、pingは通るのにApacheが一切応答しなかった
2003年のことです。私が担当していた客先のWebサーバーが、朝から突然応答しなくなりました。社内のネットワーク担当者は「ネットワーク側は問題ない」と言います。実際、サーバーにSSHでログインすることはでき、pingを打てば問題なく応答が返ってきました。でも、ブラウザからWebサイトにアクセスすると「接続できません」のまま動きません。
当時の私は「pingが通るんだから、ネットワークは問題ないはず。じゃあなんで？」と完全に混乱していました。サーバーにログインできている以上、サーバー自体は生きている。それなのにWebが見えない。ネットワーク担当者と「こちらは問題ない」「でもつながらない」を繰り返すだけで、原因究明が進みません。
結局、原因はApacheが起動していなかっただけでした。前日の夜間パッチ適用後にサーバーを再起動したとき、Apacheの自動起動が設定されていなかったため、そのまま止まっていたのです。でも当時の私にはその「確認の順序」がわかっていなかった。pingが通るということにばかり注目して、サービスのプロセス状態を確認するという発想がなかったのです。
あの混乱の1時間が、私に「ネットワーク疎通とサービス稼働は全く別の話」という感覚を叩き込んでくれました。この経験がなければ、今の私の障害対応の考え方は違っていたかもしれません。
なぜpingが通ってもサービスに繋がらないのか
pingはICMPというプロトコルを使って、「相手のIPアドレスに届くか」だけを確認するコマンドです。TCP/IPの層でいうと「ネットワーク層（IP層）」の疎通確認にすぎません。Webサービスの場合、HTTPは「アプリケーション層」の話です。pingが通るということは「サーバーのIPアドレスにパケットが届く」ことは確認できますが、その上で動くサービス（Apache・Nginx・MySQLなど）が正常に稼働しているかどうかは、また別の話になります。
簡単に整理すると、次のようになります。
・pingが通る = IPレイヤーで通信できる（サーバーが起動していてネットワークがある）
・Webに繋がる = TCPポート80（または443）でApacheなどのプロセスがLISTENしている
この2つは完全に独立しています。pingが通っても、Apacheが止まっていればWebに繋がりません。逆にpingが通らなくても、SSH接続が別経路で可能なこともあります（ファイアウォールがICMPをブロックしている場合など）。
「pingが通っているから大丈夫」というのは、残念ながら判断として不十分です。では、「サービスがTCPポートでLISTENしているか」を確認するにはどうすればよいか。現場ではssコマンドを使います。
# ss -tlnp | grep :80 LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("httpd",pid=12345,fd=6))
障害を切り分けるための具体的な手順
「pingが通るのにサービスに繋がらない」という状況で、私が現場で実際に実行する手順を順番に解説します。1. pingで疎通確認（IPレイヤーの確認）
まずpingを打って、相手のIPアドレスにパケットが届くかを確認します。これでIPレイヤーの問題かどうかが分かります。pingが通らなければ、ネットワーク設定・ルーティング・ファイアウォールのICMPブロックを疑います。pingが通るなら、問題はサービスレイヤーにあります。2. ssコマンドでポートのLISTEN状態を確認する
サービスが期待するポートでLISTENしているかを確認します。サーバーにSSHでログインした後、次のコマンドを実行します。# ss -tlnp State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=987)) LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("httpd",pid=1234)) LISTEN 0 70 127.0.0.1:33060 0.0.0.0:* users:(("mysqld",pid=2345))
3. systemctlでサービスの状態を確認する
サービスの稼働状態と直近のエラーを確認します。# systemctl status httpd * httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Mon 2026-09-01 03:22:15 JST; 1h 12min ago Process: 1234 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE) Main PID: 1234 (code=exited, status=1/FAILURE) Sep 01 03:22:15 server01 httpd[1234]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 Sep 01 03:22:15 server01 httpd[1234]: no listening sockets available, shutting down Sep 01 03:22:15 server01 systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE Sep 01 03:22:15 server01 systemd[1]: Failed to start The Apache HTTP Server.
4. journalctlでエラーの原因を詳しく調べる
systemctlのstatusに詳細が出ない場合は、journalctlで直近のサービスログを確認します。# journalctl -u httpd -n 50 --no-pager Sep 01 03:22:15 server01 httpd[1234]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name Sep 01 03:22:15 server01 httpd[1234]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 Sep 01 03:22:15 server01 systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE Sep 01 03:22:15 server01 systemd[1]: Failed to start The Apache HTTP Server.
よくあるエラーと動かない時の原因・対処法
現場でよく遭遇する「pingは通るのにサービスに繋がらない」パターンを紹介します。実際にセミナーで受講生から「詰まりました」と相談を受けてきたケースが多く含まれています。パターン1：サービスが起動していない
最も多いケースです。再起動後に自動起動設定が抜けていたり、手動で誤って停止していたりする場合です。Apacheの場合は
systemctl enable httpd で自動起動を設定し、systemctl start httpd でサービスを起動します。パターン2：ポートが別のプロセスに使われている（Address already in use）
起動に失敗しているのに旧プロセスが残っているケースや、想定外のサービスが同じポートを使っているケースです。
ss -tlnp | grep :80 で何が使っているかを確認し、不要なプロセスを停止してから再起動します。パターン3：ファイアウォールがポートをブロックしている
サービスは起動しているのに外部からアクセスできない場合、ファイアウォール設定が原因の可能性があります。サーバー内からのアクセスは通るのに、外部からは繋がらないというケースがこれにあたります。
firewall-cmd --list-all でポートの開放状況を確認します。パターン4：設定ファイルに構文エラーがある
Apacheの設定ファイル（httpd.conf）を変更した後に再起動すると、構文エラーで起動に失敗することがあります。
httpd -t または apachectl configtest で設定ファイルの構文チェックを行ってから再起動します。「Syntax OK」と表示されれば設定ファイルに問題はありません。パターン5：SELinuxが接続をブロックしている
RHEL/AlmaLinux/Rocky Linuxで非標準のポートを使う場合や、特定のディレクトリへのアクセスをSELinuxのポリシーがブロックすることがあります。
ausearch -m avc -ts recent で最近のSELinuxの拒否ログを確認し、必要に応じてポリシーを修正します。上記5パターンの対処を順に試すことで、「pingは通るのにサービスが繋がらない」問題のほとんどは解決できます。重要なのは、「pingが通る = 問題なし」と判断せず、サービスレイヤーまで確認を進める習慣をつけることです。
この経験から受講生に必ず伝えていること
3,100名以上を指導してきた中で、「pingは通るのにサービスに繋がらない」という状況で詰まる受講生は少なくありません。その多くが、「なぜ繋がらないのか」の視点を「ネットワークレイヤー」で止めてしまっています。私がセミナーで必ず伝えるのは「障害は層（レイヤー）で考える」という視点です。TCP/IPの7層（OSI参照モデル）を厳密に覚える必要はありませんが、「これはネットワーク疎通の問題なのか」「ポートで待ち受けているプロセスの問題なのか」「アプリケーションの設定の問題なのか」という層の区別だけは、現場では必須の感覚です。
・pingが通る ⇒ IP層は問題なし
・ポートにLISTENがある ⇒ プロセスは起動している
・アプリケーションが正常応答する ⇒ サービスとして機能している
この3段階の確認を習慣化するだけで、同じような障害で詰まる時間を大幅に減らせます。
私がSE時代に1時間かかった切り分けが、今では数分で終わります。その差は技術力というより、「どの順序で何を確認するか」という思考の型の違いです。Linuxの現場経験を積む中で、この型を早めに身につけることが、エンジニアとしての成長速度を左右します。20年以上現場を経験してきた中で、切り分けが速いエンジニアは必ずといっていいほど「レイヤーで考える習慣」を持っています。それはどこかで突然身につくものではなく、1回1回の障害を丁寧に「どのレイヤーの問題だったか」と振り返ることで積み上がっていくものです。
まとめ
「pingは通るのにサービスに繋がらない」という状況を経験した方は多いでしょう。この記事で解説した切り分けの手順を、改めて整理します。| 確認レイヤー | 確認コマンド | 何が分かるか |
|---|---|---|
| IPレイヤー（疎通） | ping サーバーIP |
IPアドレスに到達できるか |
| ポートレイヤー（待受） | ss -tlnp | grep :ポート番号 |
サービスがLISTENしているか |
| プロセスレイヤー（状態） | systemctl status サービス名 |
サービスが正常稼働しているか |
| ログレイヤー（原因） | journalctl -u サービス名 -n 50 |
エラーの詳細と原因 |
| ファイアウォール（通信制御） | firewall-cmd --list-all |
ポートが開放されているか |
| SELinux（アクセス制御） | ausearch -m avc -ts recent |
SELinuxによるブロックがないか |
この「層で考える」思考法は、Linuxの障害対応だけでなく、サーバー構築・セキュリティ設定・パフォーマンスチューニングにも応用できます。早いうちに身につけておくことが、現場での信頼につながります。
関連記事も合わせて参考にしてください。
・ssコマンドでソケット情報・LISTENポートを確認する方法
・systemctlコマンドの使い方｜サービスの起動・停止・自動起動設定
障害切り分けの「型」を最短で身につけたい方へ
「pingが通る」「サービスが動いている」「ログに何も出ない」——それぞれのレイヤーを順に確認する習慣は、コマンドの丸暗記では身につきません。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxのstderrを知らずにエラーが消えていた日の話｜2>&1の意味を理解するまで3年かかった経験
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます