Linuxのトラブル対応でよく聞くつまずきです。エラーは出ている。でも、どの順番で何を確認すればいいのかが分からない。
この記事では、20年以上Linuxサーバーの運用に携わってきた経験をもとに、サービスが動かなくなったとき最初に確認すべき4つのポイントを解説します。想定環境はAlmaLinux 9系（RHEL 9系）ですが、Ubuntu 24.04 LTSでも基本のコマンドはほぼ共通して使えます。
この記事のポイント
・トラブルの初動は「ログ→プロセス→ネットワーク→権限」の4層で確認する
・journalctlとsystemctl statusで8割のトラブルは原因が特定できる
・「何から確認するか」の順番を持つと、原因特定の時間が大幅に短縮される
・「とりあえず再起動」は原因を消してしまうため、初動では実行しない
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「何から確認するか」が定まっていない状態のつまずきパターン
Linuxのトラブル対応で初学者がつまずく場面は、コマンドを知らないときではなく、「何から調べればいいか」の順序が定まっていないときです。典型的なケースとして、次のような流れがあります。
サービスに繋がらなくなった。とりあえず
pingを実行する。疎通はある。次にcurlで叩いてみる。接続を拒否される。なぜ？と思いながらログを探すが、/var/log/messagesをtailしても何も分からない。最終的に「とりあえず再起動しよう」という結論になる。再起動で一時的に直ったとしても、原因が分からないままなので同じトラブルは再発します。しかも再起動によってプロセスの状態やログの直前の記録が一部失われてしまい、後から原因を追えなくなることがあります。
現場での典型的な痛い経験として、多くのエンジニアが「再起動後に原因が分からなくなった」という話をします。これを防ぐには、確認する「順番」を事前に決めておくことが必要です。
なぜ確認に「順番」が必要なのか
Linuxのサーバーは、複数の層が積み重なって動いています。アプリケーション・ミドルウェア・ネットワーク・ファイルシステム・権限・カーネルなど、それぞれが独立して機能しながら連携しています。トラブルが起きたとき、どの層に問題があるのかが最初には分かりません。だからこそ、上位（ログ）から下位（カーネル・権限）へと順番に確認していく「層別アプローチ」が有効なのです。
確認する順番を持っている人は、「ログを確認する→サービスの状態を確認する→ネットワーク接続を確認する→権限を調べる」という流れを実行しています。この流れに従うだけで、見当違いな確認で時間を消費することが大幅に減ります。
3,100名以上を指導してきた経験から言えるのは、「答えを知っている人」よりも「何から確認するかを知っている人」のほうが、現場で頼りにされるということです。コマンドを何百個覚えていても、「今この状況で何を実行するか」の判断ができなければ意味がありません。
Linuxの学習における順序の重要性については、Linuxを学ぶ順番を間違えると遠回りになる理由でも詳しく解説しています。
4つのポイントで初動を組み立てる
1. ログで「何が起きたか」の記録を確認する
ログの確認から始めるのが鉄則です。トラブルが起きたとき、Linuxは必ず何らかの記録を残しています。systemd（システム管理デーモン）ベースのシステムでは
journalctlが主要なログの入り口になります。サービス単位でフィルタリングしながら、エラーの前後を追います。# journalctl -u httpd --since "1 hour ago" --no-pager 出力例（環境により異なります）: Nov 13 07:00:01 server1 httpd[1234]: (13)Permission denied: AH00035: access to /var/www/html/index.html denied # journalctl -p err --since today --no-pager 出力例（環境により異なります）: Nov 13 06:58:01 server1 systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE
・エラーが発生した時刻：何かの操作（パッケージ更新・設定変更・デプロイ）が行われた直後かどうかを確認します
・エラーのキーワード：「Permission denied」「Connection refused」「No such file or directory」など
・サービス名：どのプロセスが問題を起こしているかを特定します
特に「Permission denied」が含まれている場合は、ファイルのパーミッションかSELinux（Security-Enhanced Linux）のポリシーが原因である可能性が高くなります。
ログの読み方についてより詳しく知りたい方は、Linuxのログが読めるだけで現場の信頼が変わる理由もあわせて読んでみてください。
2. プロセスとサービスの状態を確認する
ログで「何が起きたか」が分かったら、次はサービスが今どういう状態にあるかを確認します。systemctl statusは、サービスの稼働状態に加えて最近のジャーナルメッセージも表示されるため、ログ確認とプロセス確認を同時に行える便利なコマンドです。# systemctl status httpd 出力例（環境により異なります）: * httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: failed (Result: exit-code) since Thu 2026-11-13 06:58:01 JST Main PID: 1234 (code=exited, status=1/FAILURE) Nov 13 06:58:01 server1 systemd[1]: httpd.service: Main process exited # ps aux | grep httpd | grep -v grep 出力例（環境により異なります）: apache 1234 0.0 0.1 12345 5678 ? S 07:00 0:00 /usr/sbin/httpd
「Active: active (running)」でも実際にリクエストが通らない場合は、ネットワークか権限の問題が考えられます。その場合は次のステップへ進みます。
3. ネットワークとポートの状態を確認する
サービスが起動していても、ポートが開いていなければ外部から繋がりません。ssコマンドでリスニング状態のポートを確認します。・サービスが正しいポートでLISTENしているか：
ss -tlnpを実行します・ファイアウォール（firewalld）のルール：
firewall-cmd --list-allで許可されているポートを確認しますApacheはデフォルトでポート80（HTTP）および443（HTTPS）をLISTENします。
ss -tlnpの出力にそのポートが含まれていなければ、サービスが正常に起動していないか、設定が変更されているかのどちらかです。「サービスが起動している」と「外部から繋がる」は別の問題です。ネットワーク設定の確認は、この2つを切り分けるために重要な手順になります。
4. 権限とSELinuxで「拒否されていないか」を調べる
ログに「Permission denied」がある場合やSELinuxの関連メッセージがある場合は、権限の確認が必要です。まずファイルの通常のパーミッションを確認し、次にSELinuxのコンテキストを確認します。
・
ls -laでファイルのパーミッションとオーナーを確認します・
ls -ZでSELinuxのセキュリティコンテキスト（ファイルのラベル情報）を確認します・
journalctl | grep -i selinuxやausearch -m avc --start todayでAVC denied（アクセス拒否の記録）を確認しますSELinuxのAVC deniedが出ている場合、
restorecon -v ファイルパスでコンテキストをデフォルトに戻すと解消するケースがよくあります。要注意なのは、SELinuxを「邪魔者」として
setenforce 0で無効化してしまうケースです。これは問題を先送りするだけで、本番環境でとるべき対処ではありません。SELinuxを有効にしたまま原因を追う習慣が大切です。よくある「エラーが解決できない」パターンと対処の流れ
ログを確認した、プロセスを確認した、ネットワークも権限も確認した。それでも解決できない場合があります。現場でよく出てくるパターンと次の対処を整理します。・ログに何も出ていない：アプリケーションが独自のログファイルを持っている場合があります。設定ファイル（例：
/etc/httpd/conf/httpd.confのErrorLog行）でログの出力先を確認してください。Webアプリケーションのエラーログは/var/log/httpd/error_logに出力されることが多いです・サービスが起動しているのに応答がない：設定ファイルのシンタックスエラーが原因のことがあります。Apacheなら
apachectl configtest、Nginxならnginx -tで構文チェックを実行してください・直前の変更が分からない：作業記録がなければ
rpm -qa --lastで直近に更新されたパッケージを確認します。journalctl --since "2 hours ago"で2時間前からのログを確認するのも有効です・どうしても原因が特定できない：「分からない」まま停滞するより、今の状態を記録して次の確認に移ります。
journalctl --no-pagerの出力、ps auxの出力、ss -tlnpの出力を記録しておくと、後から原因を追いやすくなります動いているものと動いていないものを切り分けることが原因特定の近道です。「サービスは起動している→ポートはLISTENしている→ファイアウォールは通っている→でも接続できない」と段階を踏んで確認することで、問題の場所が必ず絞り込めます。
まとめ
Linuxのトラブル対応は「何から確認するか」が定まっていると、原因特定のスピードが大きく変わります。ログ・プロセス・ネットワーク・権限の4つを順番に確認していく習慣が、現場での信頼に直結します。| 確認ポイント | 主なコマンド | 見るべきこと |
|---|---|---|
| ログ | journalctl -u サービス名 |
エラーの時刻・キーワード・発生箇所 |
| プロセス・サービス | systemctl status サービス名 |
active / failed・起動エラーの内容 |
| ネットワーク・ポート | ss -tlnp |
正しいポートでLISTENしているか |
| 権限・SELinux | ausearch -m avc --start today |
Permission denied・AVC denied |
「動かない」を自力で解決できる力をつけませんか？
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「早く実務で使えるスキルを身につけたい」という方には、2日間のハンズオン形式で学べる【初心者向けLinuxセミナー（2日間ハンズオン）】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：Linuxコマンドを「実行して終わり」にしない記録術｜手順書を作る習慣がスキルを底上げする理由
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます