503 Service Unavailable:過負荷かメンテナンスか?
· 読了目安 2 分
エラーの意味
503 は、ウェブサーバーが「ここにいますが、今はお応えできません」と言っている状態です。502 と違い、背後で何かが壊れているとは限りません。サーバーが意図的に 503 を返すのは、3 つの場合です。メンテナンスモードになっている、守るよう指示された上限(接続数、ワーカー、帯域幅、レート制限)に達した、または過負荷で、動き続けるためにリクエストを切り捨てている。503 には、クライアントがいつ戻るべきかを伝える Retry-After ヘッダーが付くことがあります。検索エンジンは、短い 503 を一時的なものとして扱い、ページを外しません。
よくある原因
- メンテナンスモードが残ったままです。 WordPress は、更新中に
.maintenanceファイルを書き込み、更新が終わるまで 503 を返します。更新が中断されると、ファイルが残り、エラーも残ります。Laravel、Magento、Drupal など、ほとんどのフレームワークに同等のスイッチがあります。 - 過負荷です。 設定されたワーカーが処理できる数を超えるリクエスト。Apache の
MaxRequestWorkersに到達した、PHP-FPM のpm.max_childrenを使い切った、またはデータベースが遅すぎてすべてのワーカーが待っている。 - ホスティングの制限です。 共有ホスティングは、アカウントごとに CPU 秒、同時プロセス数、「エントリープロセス」の上限を設けています。上限に達すると、ホスティング会社のゲートウェイが、お客様のサイトに対してのみ 503 を返します。
- バックエンドがローテーションから外されました。 ロードバランサーや CDN の背後では、503 は、すべてのバックエンドがヘルスチェックに失敗したことを意味します。Cloudflare は、オリジンが過負荷またはレート制限されている場合に、独自の 503 ページを表示します。
- ボットやスクレイパーです。 数千ページを取得するクローラーや、
wp-login.phpやxmlrpc.phpへのブルートフォース攻撃が、ワーカーを使い切り、正規の訪問者に 503 が返ります。 - ディスクの満杯またはメモリ不足です。 サービスは動いていても、セッション、キャッシュファイル、ログを書き込めず、その状態で 503 を返すアプリケーションもあります。
訪問者の場合
1 分待ってから再読み込みしてください。503 は通常、短時間で終わります。サイトが何時間も 503 のままの場合は、運営者側でメンテナンスモードが固まっているか、容量の問題があり、運営者にしか修復できません。
ご自身のサイトの場合:まず確認
ウェブサイトダウンチェッカーを実行して、外部から 503 を確認し、CDN とご自身のサーバーのどちらが返したかを確認してください。そのうえで判断します。数分前に、ご自身または CMS が更新を開始しましたか? はいなら、メンテナンスモードです。いいえなら、容量の問題です。
ご自身のサーバーでは:
# ウェブサーバーはそもそも動いているか?
systemctl status nginx
systemctl status apache2
# 負荷、メモリ、ディスク:ほとんどの 503 の裏にある 3 つの数値
uptime
free -m
df -h
# 今、サイトに大量にアクセスしているのは誰か?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
CPU コア数をはるかに上回るロードアベレージ、100 MB を下回る空きメモリ、直近の数分間に数千リクエストを送った単一の IP は、いずれも 503 の説明になります。
ご自身のサーバーでの対処法
1. 固まったメンテナンスモードを終了する
WordPress:サイトのルートにある .maintenance ファイルを削除してから、サイトを開きます。ファイルを作成した更新が中断された場合、プラグインや本体が中途半端にインストールされている可能性があります。ダッシュボードまたは WP-CLI で、更新をやり直してください。
rm /var/www/example.com/.maintenance
wp core verify-checksums
wp plugin update --all
Laravel:php artisan up。Magento:bin/magento maintenance:disable。Drupal:$settings['maintenance_mode'] を false にするか、drush state:set system.maintenance_mode 0 を使います。
2. 大量アクセスを止める
問題の IP またはネットワークをブロックし、次回は同じことができないよう、レート制限を追加します。
# 1 つのアドレスをブロック(ufw を使う Debian/Ubuntu)
sudo ufw deny from 203.0.113.45
# または nftables で
sudo nft add rule inet filter input ip saddr 203.0.113.45 drop
ログインページ向けの nginx のレート制限(http ブロック、次に server ブロックで):
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /wp-login.php {
limit_req zone=login burst=5 nodelay;
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
Apache:mod_evasive や mod_qos が同じ役割を果たします。fail2ban の apache-badbots と wordpress のジェイルは、繰り返し違反する相手を自動的にブロックします。
3. サーバーに容量を持たせる
負荷が悪用ではなく、実際のトラフィックの場合は、メモリが許す範囲でワーカーの上限を引き上げます。Apache(mpm_event):MaxRequestWorkers。PHP-FPM:pm.max_children。まず、ワーカーあたりのメモリを確認します:ps -ylC php-fpm8.3 --sort:rss。そのうえで、テストして再読み込みします。
sudo apachectl configtest && sudo systemctl reload apache2
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm
ページキャッシュを有効にして(WordPress:キャッシュプラグイン、または nginx の FastCGI キャッシュ)、急増時に、リクエストのたびに PHP が実行されないようにします。キャッシュされたページのコストは 1 ミリ秒の何分の一かですが、キャッシュのない WordPress のページは何百倍もかかります。
4. ディスクを空ける
sudo du -xh --max-depth=1 /var | sort -h | tail
sudo journalctl --vacuum-size=200M
sudo apt clean
古いログファイル、同じディスクに置かれたバックアップ、暴走したデバッグログが、よくある原因です。
5. ロードバランサーの背後の場合
すべてのバックエンドが同時にヘルスチェックに失敗する場合は、たいてい、個々のバックエンドではなく、チェック用の URL 自体が壊れています(ヘルスページの削除、チェッカーがたどらない HTTPS へのリダイレクト)。ロードバランサーから、ヘルスチェックの URL を手動で取得してみてください。
ホスティング会社の問題の場合
共有ホスティングでは、上限を引き上げられません。どの上限に達したのか、ご自身のトラフィックなのか、同じサーバー上の別のアカウントなのかを、ホスティング会社に確認してください。
お世話になっております。ウェブサイト example.com が、09:10 UTC 頃から「503 Service Unavailable」を返しています。更新は開始しておらず、サイトもメンテナンスモードではありません。私のアカウントがリソースの上限(CPU、プロセス、メモリ)に達したのか、サーバーが過負荷なのか、またその数値を教えていただけますでしょうか。私のアカウントの場合は、どの上限に、いつからでしょうか。
「アカウントが上限に達しています」という回答が繰り返される場合は、サイトを適切にキャッシュするか、より容量の大きいプランやサーバーに移行してください。
次回に備えて
503 は予兆があります。負荷がじわじわと上がり、メモリが足りなくなり、1 つの IP が大量アクセスを始めます。ウェブサイトのチェックは、1 分以内に 503 を検知します。サーバーエージェントは、そこに至る前に、負荷、メモリ、ディスクを表示します。ご自身のサーバーでは、Quick Fix が定額でディスク容量を確保し、固まったサービスを再起動します。Deep Fix は、レート制限とキャッシュを設定して、次回はサーバーが落ちないようにします。
次のステップ
ダウンしても、すぐ対応します。
ご自身のサーバー、または SSH アクセスのあるウェブスペースが対象です。一般的な原因には定額の Quick Fix、それ以外には 15 分単位で請求する Deep Fix を、24 時間体制でご用意しています。ご依頼の前に料金が表示されます。
修復を依頼する