Apache の mod_status を有効にすると、/server-status というページで「今いくつのリクエストを処理中か」「空いている処理枠はいくつか」「どの URL に時間がかかっているか」をリアルタイムに確認できます。サイトが重くなったときに、原因が Apache の処理枠不足なのか、PHP やデータベースの遅さなのかを切り分ける最初の手がかりになります。この記事では、有効化の手順、公開してはいけない理由とアクセス制限、WordPress の .htaccess と衝突したときの対処、スコアボードの読み方を説明します。
mod_status で分かること
server-status ページには、主に次の情報が表示されます。
- サーバーの稼働時間、累計アクセス数、1秒あたりのリクエスト数や転送量
- 処理中のリクエスト数と、待機中（空き）のワーカー数
- スコアボード：各処理枠（スロット）が今どの状態にあるかを1文字で並べた一覧
- 個々の処理中リクエストの詳細：接続元 IP、VirtualHost、リクエストされた URL、経過時間など
最後の詳細表示は ExtendedStatus が On のときに出ます。Apache 2.4 では mod_status を読み込むと既定で On になりますが、明示的に書いておくと設定の意図が分かりやすくなります。なお ExtendedStatus は graceful（reload）では切り替わらないため、変更したときは restart が必要です。
有効化する
Debian/Ubuntu 系
多くの環境で、mod_status は最初から有効になっています。設定は /etc/apache2/mods-enabled/status.conf にあり、標準ではサーバー自身（localhost）からのアクセスだけが許可されています。
sudo a2enmod status
cat /etc/apache2/mods-enabled/status.confRHEL/AlmaLinux 系
モジュール自体は標準で読み込まれていることが多い一方、/server-status の URL は標準では用意されていないことが一般的です。/etc/httpd/conf.d/status.conf を作って次のように書きます。
ExtendedStatus On
<Location "/server-status">
SetHandler server-status
Require local
# 管理用の固定IPから見る場合（例）
# Require ip 203.0.113.10
</Location>Require local はサーバー自身からの接続だけを許可します。社内の固定 IP から見たい場合は Require ip を加えます。変更後は構文を確認して反映します。
sudo apachectl configtest
sudo systemctl restart httpd # Debian/Ubuntu系は apache2アクセス制限を緩めてはいけない理由
server-status には、処理中のリクエストの URL、接続元 IP アドレス、VirtualHost 名が表示されます。URL のクエリ文字列に含まれる値や、公開していない管理画面のパス、サーバー上で動いている別サイトの存在も読み取れてしまいます。インターネット全体に公開するのは避け、許可する接続元を絞ります。
特に注意したいのが、同じサーバー上の Nginx などをリバースプロキシとして Apache の前に置いている構成です。この場合、Apache から見るとすべてのリクエストが 127.0.0.1 から来るため、Require local だけでは外部の訪問者にも server-status が見えてしまいます。前段のプロキシ側で /server-status への外部からのアクセスを拒否する、または Apache 側で管理専用のポートや VirtualHost に分けるといった対策を取ります。設定後は、外部の回線からアクセスして 403 や 404 になることを確かめておきます。
WordPress のサイトで 404 になる場合
WordPress をドキュメントルートに置いていると、/server-status を開いたのに WordPress の 404 ページが表示されることがあります。WordPress の .htaccess は「実在しないファイルやディレクトリへのリクエストを index.php に渡す」書き方になっており、server-status も実在するファイルではないため、WordPress 側に渡されてしまうのが原因です。
.htaccess の # BEGIN WordPress より前に、次の行を加えると server-status を書き換えの対象から外せます。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^server-status$ - [L]
</IfModule># BEGIN WordPress から # END WordPress の間は、パーマリンク設定を保存したときに WordPress が書き換えるため、その外に書きます。.htaccess を編集する前にはバックアップを取っておきます。
サーバー内から確認する
ブラウザで見る以外に、サーバーに SSH でログインして curl で取得できます。?auto を付けると、監視ツールで扱いやすい「項目名: 値」の形式で出力されます。
curl -s http://127.0.0.1/server-status?autoブラウザで見る場合は ?refresh=5 を付けると5秒ごとに自動更新されるため、負荷がかかっている間の変化を追いやすくなります。
Zabbix や Prometheus（apache_exporter）、Netdata などの監視ツールにも、mod_status の ?auto 出力を読み取って Apache の状態をグラフ化する仕組みがあります。テンプレートや設定の名称はツールのバージョンで変わるため、各ツールのドキュメントで確認してください（2026年10月現在）。
スコアボードの読み方
スコアボードは、処理枠1つにつき1文字で状態を表します。よく見る文字は次のとおりです。
_：接続待ち（空いている処理枠）W：応答を送信中。PHP の処理を待っている間もこの状態になるR：リクエストを読み込み中K：KeepAlive で次のリクエストを待機中C：接続を閉じている途中G：graceful の再起動後、処理中のリクエストを終えるのを待っている.：プロセスがまだ起動していない枠
空き（_）がほとんど無い
処理枠が足りていない状態です。エラーログに MaxRequestWorkers の上限に達したという内容のメッセージが出ていないかを確認します。
sudo grep -i "MaxRequestWorkers" /var/log/apache2/error.log # RHEL系は /var/log/httpd/error_log上限に達しているなら、メモリに余裕がある範囲で MaxRequestWorkers を見直します。ただし、処理枠を増やす前に、1件あたりの処理が遅くなっていないかを先に見ます。
W が多く、同じ URL に長い時間がかかっている
ExtendedStatus の詳細表示で、経過時間が長いリクエストの URL を確認します。WordPress なら、特定のページや管理画面の操作、xmlrpc.php や wp-login.php への大量のアクセスが原因になっていることがあります。PHP-FPM を使っている場合、Apache の W には FPM の処理待ちも含まれるため、PHP-FPM のステータスページやスローログもあわせて確認すると原因を絞り込めます。
K が大半を占めている（prefork の場合）
prefork MPM では、KeepAlive で待機している間も処理枠を1つ占有します。KeepAliveTimeout が長すぎると、実際には処理していない接続で枠が埋まります。KeepAliveTimeout を短くするか、event MPM への切り替えを検討します。
event MPM の場合
event MPM では、スコアボードに加えて接続の状態をまとめた表が表示されます。KeepAlive 中の接続は処理用のスレッドを占有しないため、prefork と同じ基準で K の数を判断しないよう注意します。
まとめ
- mod_status を有効にすると
/server-statusで処理中のリクエスト数、空きワーカー数、スコアボードを確認できる - URL や接続元 IP が表示されるため、
Require localやRequire ipでアクセス元を絞る。前段にリバースプロキシがある構成ではRequire localだけでは不十分 - WordPress の 404 になる場合は、.htaccess の WordPress ブロックより前で server-status を書き換えの対象から外す
?autoで監視ツール向けの出力、?refresh=秒数で自動更新ができる- 空きが無ければ処理枠不足、
Wが長ければ PHP やデータベース、prefork でKが多ければ KeepAliveTimeout を疑う