最強のWebサーバーを「維持」する技術
こんにちは！「リナックス先生」です。
全3回のApache講座、お疲れ様でした。サーバーは構築して終わりではなく、そこから始まる「運用」こそが本番です。
- 第1回：セキュリティ編 – 攻撃者の偵察を遮断する「防衛の深層設定」
- 第2回：パフォーマンス編 – MPM Eventの限界チューニングとベンチマーク計測術
- 第3回：拡張編 – アプリを守る「リバースプロキシ」と「ヘッダー制御」
- 付録（今回）：トラブルシューティング＆運用テクニック総まとめ
先生！実はさっき、設定をいじってたらApacheが起動しなくなっちゃって…。
エラーログを見ても英語ばかりでよく分からないんです。
運用中にこういうことが起きたらと思うとゾッとします。
エンジニアなら「エラーは友達」と思いなさい。
Apacheは非常に親切なソフトで、「なぜ動かないのか」を必ずログに残してくれるわ。
今回は、現場で頻発するトラブルの解決法と、サーバーを長持ちさせるメンテナンス術を「虎の巻」としてまとめたわよ。
1. Apacheが起動しない！緊急レスキュー手順
設定変更後に再起動（restart）したらエラーが出た。焦る必要はありません。以下の手順で必ず原因特定できます。
Step 1: 構文チェックコマンド (configtest)
いきなりログを見る前に、まずは「文法ミス」がないかApache自身に聞きます。
apachectl configtest # または httpd -t
結果の見方：
Syntax OK：設定ファイルの書き方は合っています。原因は別にあります。Syntax error on line 32 of ...：32行目にスペルミスや閉じ忘れがあります。そこを直せば動きます。
Step 2: 詳細ステータスの確認
文法が合っているのに起動しない場合は、Systemdのログを見ます。
systemctl status httpd -l # または journalctl -xeu httpd
よくある原因：
Address already in use: make_sock: could not bind to address 0.0.0.0:80
→ 原因： すでに他のソフト（Nginxなど）が80番ポートを使っています。lsof -i :80で犯人を特定して停止させましょう。
2. ステータスコード別・トラブルシューティング
ブラウザに表示されるエラーコードから、原因を絞り込みます。
500 Internal Server Error（内部サーバーエラー）
「Apacheの設定ミス」か「プログラム（PHP）の暴走」です。
- .htaccessの記述ミス： 一番多い原因です。
.htaccessを一度リネームして無効化し、表示されるか試してください。 - 権限（Permission）ミス： PHPファイルやディレクトリの書き込み権限がおかしい場合に発生します。
- PHPの致命的エラー： メモリ不足など。
/var/log/php-fpm/error.logも確認しましょう。
403 Forbidden（閲覧禁止）
「見せられない」という拒否反応です。
- ファイル権限： ドキュメントルートの権限が
700などになっていませんか？（Apacheユーザーが読めない） - WAF (ModSecurity)： 攻撃とみなされてブロックされた可能性があります。ログに
ModSecurity: Access deniedと出ていないか確認してください。 - ディレクトリ一覧禁止： インデックスファイル（index.html/php）がないディレクトリにアクセスし、
Options -Indexesが設定されている場合に出ます（これは正常な挙動です）。
502 Bad Gateway / 503 Service Unavailable
リバースプロキシ構成でよく出ます。「裏側のアプリ」に原因があります。
- バックエンドダウン： Node.jsやPythonアプリが落ちていませんか？
- SELinux： Apacheが裏側のポートへ接続するのをOSが止めていませんか？
setsebool -P httpd_can_network_connect 1を試してください。
3. プロのログ解析術
ログファイルは巨大すぎて、ただ眺めていても分かりません。grep や tail を駆使して必要な情報を抜き出します。
リアルタイムでエラーを監視する
ブラウザでアクセスしながら、裏でログがどう動くかを見ます。
# エラーログの末尾をリアルタイム表示 tail -f /var/log/httpd/error_log
特定のIPアドレスの動きを追う
「攻撃かな？」と思ったら、そのIPアドレスの行動履歴を抽出します。
# アクセスログから特定IPを検索 grep "203.0.113.5" /var/log/httpd/access_log
攻撃の兆候（403/404エラー）が多い順に集計する
誰がエラーを大量に出しているかランキング化する、プロ御用達のワンライナーです。
awk '($9 ~ /403/ || $9 ~ /404/)' /var/log/httpd/access_log | awk '{print $1}' | sort | uniq -c | sort -nr | head -10
4. 運用自動化：ディスクをパンクさせない技術
サーバー障害の定番、「ログによるディスク容量圧迫」を防ぐ設定です。
Logrotate（ログローテーション）の確認
Linuxにはログを定期的に圧縮・削除する logrotate が標準装備されていますが、Apache用の設定が適切か確認しましょう。
設定ファイル： /etc/logrotate.d/httpd (またはapache2)
/var/log/httpd/*log {
daily # 毎日ローテーション
missingok # ログがなくてもエラーにしない
rotate 14 # 14日分（2週間）保存する
compress # 過去ログは圧縮する（容量節約）
delaycompress # 圧縮は1日遅らせる（書き込み競合防止）
notifempty # 空ならローテーションしない
sharedscripts
postrotate
# ローテーション後にApacheをリロードして新しいログファイルを使わせる
/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
endscript
}
アクセスが多いサイトなら、rotate 14 を rotate 7 に減らしたり、古いログをS3などの外部ストレージに逃がすスクリプトを組むことも検討します。
SSL証明書の更新フック
Certbot（Let’s Encrypt）は証明書を自動更新してくれますが、「更新した後にApacheを再読み込み」しないと、Apacheはずっと古い証明書を使い続けてしまいます。
/etc/letsencrypt/renewal-hooks/deploy/ ディレクトリに、以下のスクリプトを置いておくと確実です。
#!/bin/sh # 証明書更新後にApacheをリロードする systemctl reload httpd
※実行権限（chmod +x）を忘れずに付与してください。
付録まとめ：ログは口ほどに物を言う
トラブルシューティングの基本は、憶測ではなく「証拠（ログ）」に基づいて動くことです。
- 動かない時は：
configtestとstatusを見る。 - エラー画面が出たら： ステータスコード（500/403/503）から原因を推測し、
error_logで答え合わせをする。 - 将来のために：
logrotateでディスクを守り、SSL更新フックで証明書切れを防ぐ。
ログの見方が分かると、エラーも怖くなくなりますね！
「あ、これはPermissionエラーだな」とか分かるようになってきました。
ログローテーションの設定も見直して、長期運用に備えます！
素晴らしい心構えよ。
サーバーは24時間365日働き続けるもの。だからこそ、何かあった時にすぐ気づける仕組みと、復旧させる技術が必要なの。
この付録記事をブックマークして、いつでも見返せるようにしておいてね。あなたのサーバー運用が平穏であることを祈っているわ！
▼トラブル時も安心のサポート体制
どうしても解決できないトラブルに遭遇した時、充実したマニュアルやコミュニティ、あるいはスナップショット機能での復元が可能なVPSを選んでおくと安心です。
コメント