はじめに
目的
本記事は、ブラウザやアプリで「Web server is down（Webサーバーが落ちている）」という表示を見たときに、何が起きているのかを分かりやすく解説することを目的としています。原因の見当をつけ、まず自分でできる確認と対処、管理者に伝えるべき情報を整理できます。
対象読者
- サイトにアクセスしてエラーが出た一般ユーザー
- 自分のサイトが表示されないサイト運営者
- 管理者に状況を分かりやすく伝えたい人
専門知識が少なくても理解できるようにかみ砕いて説明します。
記事の構成と読み方
以下の章で順に説明します。
– 第2章: 「is down」とは何が起きているか
– 第3章: 応答しない主な原因
– 第4章: ユーザー側でできる基本チェック
– 第5章: 管理者向けトラブルシューティング
まず第4章の基本チェックを行い、改善しなければ第5章の手順に進むと効率的です。
注意事項
本記事は一般的な対処法を示します。重要な業務サイトや複雑な構成は専門家に相談してください。ログや画面のキャプチャを用意すると対応が早くなります。
Webサーバー「is down」とは何が起きているのか
概要
「Web server is down」「サーバーが応答しない」と表示されたとき、ブラウザはWebサーバーから期待した応答を受け取れていません。必ずしも物理的に電源が落ちているわけではなく、さまざまな層で問題が起きている可能性があります。
主な状態と具体例
-
サーバー自体が停止している
サーバーの電源が落ちていたり、ホスティング側で停止している状態です。接続自体が拒否されるか、まったく応答が返りません。 -
サーバープロセスやアプリが停止・クラッシュしている
Webサーバー（例：Apache、Nginx）やアプリケーションが落ちていると、エラーページやタイムアウトが発生します。例：500 Internal Server Error。 -
過負荷による応答不能
同時アクセスが急増して処理が追いつかないと、503 Service Unavailableやタイムアウトになります。リソース不足（CPU・メモリ）やコネクション枯渇が原因です。 -
設定ミスやソフトウェアの不具合
設定ファイルの誤りや最近の更新で動作が止まることがあります。ログを見て設定エラーや例外を確認します。 -
ネットワークやDNSの問題
サーバーは動作していても、ネットワーク経路やDNSが壊れると到達できません。ブラウザに「DNS_PROBE_FINISHED_NXDOMAIN」や接続タイムアウトが表示されます。 -
クライアント側の問題
ユーザーの回線やブラウザ、ファイアウォール設定が原因で接続できないこともあります。別端末や別回線で確認すると切り分けできます。
要点
これらは重なる場合があります。まずは表示されるエラーメッセージとログを手がかりに、どの層で障害が起きているかを切り分けることが重要です。
サーバーが応答しない主な原因
ネットワークの不具合
ルーターの故障、LANケーブルの断線、Wi‑Fiの電波不良、DNS設定の誤りなどが含まれます。例えばルーター再起動で復旧することがあります。症状の目安はpingや traceroute が通らない、特定のサイトだけ見えないことです。
サーバーの過負荷・リソース不足
同時接続が急増したりCPUやメモリが枯渇すると応答が遅くなります。アクセス集中（バースト）やメモリリークが原因です。動作ログで高負荷や swap 使用を確認します。
Webサーバーの設定ミス・ソフトウェア不具合
設定ファイルの誤記やバージョン更新後の互換性問題でサービスが止まります。設定変更直後に不具合が出ることが多いです。エラーログを確認します。
ハードウェア故障
電源障害やディスク故障、NIC（ネットワークカード）の故障が該当します。サーバー自体が落ちる、起動に失敗する場合に疑います。ハードウェア監視やスマート（SMART）ログで判断します。
データベース障害
DBが停止したりクエリが極端に遅くなるとWebは応答しません。データベース接続エラーや遅延タイムアウトが出ます。DBの稼働状況とスロークエリを調べます。
複合的な要因
一つの問題が連鎖して複数の要素を悪化させることがあります。例えばネットワーク障害でリトライが増え、結果的にサーバーが過負荷になることがあります。原因切り分けを順に行うことが重要です。
まずユーザー側でできる基本チェック
別サイト・別端末で確認
まずは症状の切り分けです。別のサイト（ニュースサイトや検索ページ）を開いてみてください。別のサイトも見られない場合は自分の回線や端末側の問題の可能性が高いです。スマホや別のPCで同じサイトにアクセスして、見えればサーバー側の問題と判断できます。
ルーター・モデムの再起動
家庭のルーターやモデムを電源から外して10〜30秒待ち、再度入れてください。接続が長時間続くと機器の不具合で通信が途切れることがあります。再起動で直れば回線側の一時的な問題です。
LANケーブルとWi‑Fiの状態確認
有線ならケーブルの抜けや断線、差し直しを試してください。無線ならWi‑FiのSSIDとパスワードが正しいか、ほかの機器が接続できるかを確認します。近くに電子レンジなど干渉源があると弱まることがあります。
PCのネットワーク設定見直し
ネットワークの接続設定（自動取得か固定IPか）、プロキシ設定、VPN接続の有無を確認してください。誤った設定やVPN接続でサイトに届かないことがあります。
OS・ブラウザ・セキュリティソフトの確認
ブラウザを別のものに変える、ブラウザのキャッシュを削除する、拡張機能を一時無効化してみてください。セキュリティソフトやファイアウォールが通信を遮断していないかも確認します。必要なら一時的に無効化して試します。
結果の見方（切り分けの目安）
- 別端末でも同じ症状：サーバー側の可能性が高い
- 別端末で正常：自分の端末や回線の問題
- 再起動で直った：回線／機器の一時的な不具合
これらの手順でまず原因を絞れます。技術的に不明な点が残る場合は、次の章で管理者向けの対処を参照してください。
管理者向け「Webサーバー is down」トラブルシューティング
まず全体の切り分け
- 影響範囲を把握します（単一サーバーかクラスタ全体か）。ステータスページや監視アラートで確認します。
ネットワーク到達性の確認
- pingで疎通確認: ping -c 4
- 経路確認: traceroute で途中で止まる箇所を探します
- サーバー側のNIC状態: ip link show / ethtool eth0
サービスとプロセスの確認
- Webプロセス確認: systemctl status nginx（または apache）
- ポート確認: ss -ltnp（ポートがLISTENしているか）
- サービス再起動: sudo systemctl restart nginx
ログとリソースの確認
- エラーログ: tail -n 200 /var/log/nginx/error.log
- ジャーナル: sudo journalctl -u nginx -n 200
- リソース: top, free -m, df -h（メモリ・ディスク不足を確認）
設定と証明書の確認
- 設定検証: nginx -t や apachectl configtest
- SSL: 証明書の有効期限とパスを確認
周辺要素の確認
- ファイアウォール（iptables/ufw）、セキュリティグループを確認
- DNS: dig +short example.com が正しいIPを返すか
- ロードバランサーやCDNのヘルスチェックを確認
ハードウェアとOSレベル
- SMARTでディスク確認: smartctl -a /dev/sda
- dmesgでカーネルエラーを確認
復旧と予防措置
- 直近の変更をロールバックする手順を準備
- 影響を受けるサービスの一時的な代替（別ノードへの切替）を検討
- 対応履歴を残し、再発防止のため監視ルールや運用手順を更新します
必要なら各コマンドの実行例や優先順位を詳しく説明します。ご希望があれば教えてください。
