第15回｜トラブル対応と運用（続けられる力）｜やさしい UNIX & Linux

やさしい UNIX & Linux | 第１５回

サーバーが動かなくなったとき、何をするか

第 14 回では、Nginx をインストールして自分のページをブラウザで表示するところまでを確認しました。サーバーが外からのアクセスに応答する体験です。

サーバーを動かし続けると、いつかは「ページが表示されない」「SSH で入れない」といった状況に直面します。これはサーバーを使う誰もが通る道です。この回では、トラブルが起きたときの考え方と、状況を把握するための具体的な手順を整理します。

トラブル対応の基本姿勢｜「壊れた」ではなく「止まっただけ」

ページが表示されなくなると、最初は「何かを壊してしまった」と感じるかもしれません。しかし多くの場合、サーバーが完全に壊れているわけではありません。設定ミス・サービスの停止・ネットワークの問題など、原因は必ずどこかにあり、特定できれば対処できます。

焦って次々と設定を変えると、状況がわからなくなります。まず「今何が起きているか」を把握することが、解決への最短経路です。

最初に確認すること｜状況把握のチェックリスト

トラブルが起きたとき、次の順番で状況を確認します。

• サーバー自体が起動しているか：VPS のコントロールパネルでサーバーの電源状態を確認する
• SSH で接続できるか：接続できれば、サーバーは動いている。できなければネットワーク障害または SSH サービスの停止を疑う
• 問題のサービスが起動しているか：Nginx が止まっていれば Web ページは表示されない
• 直前に何かを変更したか：設定ファイルを編集した・ソフトウェアをインストールした・再起動した、など

Nginx の状態確認は、第 14 回でも使った次のコマンドです。

sudo systemctl status nginx

sudo systemctl status nginx

inactive と表示されていれば停止しています。再起動するには次のコマンドを使います。

sudo systemctl restart nginx

sudo systemctl restart nginx

ログを読む｜サーバーが残したヒントを拾う

サービスが起動に失敗したり、エラーが発生したりすると、その記録がログに残ります。ログはサーバーの「診断記録」です。英語でも、すべてを理解できなくても構いません。エラーが起きた時刻付近に何が書かれているかを確認するだけで、手がかりになります。

Nginx のエラーログを確認するコマンドは次のとおりです。

sudo cat /var/log/nginx/error.log

sudo cat /var/log/nginx/error.log

systemd 経由で起動・停止の記録を確認するには次のコマンドが便利です。

sudo journalctl -xe

sudo journalctl -xe

ログに Permission denied や No such file or directory といった文字が見えれば、権限の問題やファイルの不在が原因である可能性が高いです。エラーメッセージをそのままコピーして検索すると、解決方法が見つかることがほとんどです。

「直す」より「戻す」｜バックアップの考え方

設定ファイルを変更してサービスが止まった場合、元の設定に戻すことが最も確実な対処です。設定ファイルを編集する前に、コピーを取っておく習慣をつけると安心です。

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

.bak という拡張子を付けてバックアップを作成しておけば、変更後に問題が起きても元のファイルに戻せます。

sudo cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf

sudo cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf

「戻れる場所がある」という状態で作業すると、心理的な余裕が生まれ、落ち着いて問題を調べられます。無理に原因を探し続けるより、いったん動いていた状態に戻してから改めて変更を加える方が、結果的に早く解決することが多いです。

再起動という手段｜最初に試す対処のひとつ

原因がわからないまま何かおかしい、という状況では、サービスの再起動が有効な場合があります。一時的なメモリ不足・プロセスのハングアップ・ネットワーク接続の切断などは、再起動で解消されることがあります。

特定のサービスを再起動するのが安全です。サーバー全体を再起動する場合は SSH 接続が切れることを念頭に置きます。

# Nginx だけ再起動
sudo systemctl restart nginx

# サーバー全体を再起動
sudo reboot

# Nginx だけ再起動
sudo systemctl restart nginx

# サーバー全体を再起動
sudo reboot

reboot を実行するとすぐに接続が切れます。数十秒〜1 分ほど待ってから再度 SSH で接続します。

運用を続けるための考え方

サーバーをゼロ・トラブルで動かし続けることは現実的ではありません。企業の本番サーバーでも、障害は起きます。大切なのは、トラブルが起きたときに「状況を把握し・原因を特定し・対処できる」という経験を積み重ねることです。

一度経験したトラブルは、次に同じ状況が起きたとき対処できます。ログの見方・サービスの起動確認・バックアップと復元、これらを一通り体験しておくことが、運用の土台になります。

完璧な設定を最初から目指すより、「小さく動かし・少し壊し・直す」を繰り返す中で理解が深まっていきます。続けることが、もっとも確実な上達方法です。

まとめ｜トラブルは仕組みを知る入口

第 15 回で確認したポイントをまとめます。

• 基本姿勢：焦らず、まず状況を把握する。「壊れた」ではなく「止まっただけ」
• 最初の確認：サーバーの電源 → SSH 接続 → サービスの起動状態 → 直前の変更
• ログの確認：/var/log/nginx/error.log や journalctl -xe でヒントを探す
• バックアップ：設定ファイルを変更する前に .bak コピーを作る。「戻せる状態」を維持する
• 再起動：systemctl restart でサービス単体を、reboot でサーバー全体を再起動できる
• 続ける力：一度経験したトラブルは次に対処できる。繰り返しの中で理解が深まる

トラブルに向き合う経験は、サーバーの仕組みを理解する最短経路のひとつです。

次回予告

第 15 回では、トラブルが起きたときの確認手順と、運用を続けるための考え方を整理しました。

第 16 回では、トラブルを「減らす」ための話に進みます。VPS を安全に使い続けるための基本設定として、ファイアウォールの設定・SSH の鍵認証・不要なサービスの停止といった、最初に整えておくべき項目を確認していきます。