503 Service Unavailableの意味と対処法：nginx・Varnish・HAProxy別

HTTPエラー503とは？

503 Service Unavailableは、サーバー、またはその手前にある何かが、今リクエストを処理できないことを意味します。過負荷、メンテナンス中、リクエスト数の制限（レート制限）中、または転送先の正常なバックエンドがない状態です。 RFC 9110は503を、しばらく待てば解消する可能性が高い一時的な状態と定義しています。

サーバーは、どれくらい待てばよいかを示すRetry-Afterヘッダーを付けることがあります。何かが壊れたことを意味する500と違い、503は「今は無理」という意味です。そのため、計画メンテナンスには503が使われます。

実際には、Webサーバー自体ではなく、その手前の層が応答していることがよくあります。HAProxyのようなロードバランサー、Varnishのようなキャッシュ、CloudflareのようなCDN、あるいはKubernetesのIngressです。正確な文言を見れば、どの層かがわかります（下の表を参照）。

503エラーの表示例

メッセージを見れば、どの層が応答したかがわかります。よく見かけるメッセージと、それを表示するソフトウェアは次のとおりです。

文言が何であれ、意味は同じです。このリクエストは今は処理できず、調べるべきなのは表の「送信元」にある層です。

HTTPエラー503の主な原因

サーバーやその手前の層が503を返す主な理由は次のとおりです。

• 過負荷 — トラフィックの急増、話題になった投稿、攻撃的なクローラーによって、CPU、メモリ、接続数の上限に達している状態です。
• 計画メンテナンス — 更新や移行のために、意図的にサイトを止めている状態です。正しく行うなら、Retry-Afterヘッダーを付けます。
• 正常なバックエンドがない — ロードバランサー、プロキシ、Ingressが、リクエストを送れる正常なサーバーを見つけられない状態です（アプリのクラッシュ、ヘルスチェックの失敗、準備完了のPodがない）。
• リクエスト数・接続数の制限 — nginxのlimit_reqとlimit_connはデフォルトで503を返すため、リクエストの多いクライアントやクローラーがきっかけになることがあります。
• アプリケーションのクラッシュや停止 — Webサーバーは動いているのに、その奥のPHP-FPM、Node.js、Pythonが止まっている状態です。IISでは、アプリケーション プールが停止している状態です。
• ホスティングのリソース制限 — 共有ホスティングでは、アカウントごとにCPU、メモリ、プロセス数が制限されています。
• プラグイン、テーマ、アップデート — WordPressなどのCMSでは、不具合のあるアップデートがアプリを止めたり、サイトがメンテナンスモードのまま戻らなくなったりすることがあります。
• 攻撃 — DDoSやボットの大量アクセスは、トラフィック急増と同じようにリソースを使い果たします。

訪問者向けの対処法

他人のサイトで503が出ている場合、問題は相手側にあります。訪問者にできることは次のとおりです。

• 待ってから再試行する — 503はもともと一時的なエラーです。1分ほど待ってから、1回だけ再読み込みしてください。ページにRetry-Afterの時間やメンテナンスの案内があれば、その時間だけ待ちましょう。
• 全員がアクセスできないのか確認する — DNS Robotのサーバーダウンチェックは、あなたのネットワークの外からサイトをテストします。
• サイトのステータスページやSNSを確認する — 計画メンテナンスや障害は、たいてい告知されています。
• 別のネットワークで試す — モバイルデータ通信なら開ける場合、普段のネットワークのVPNやプロキシが503を返しているか、サイトがあなたのIPアドレスのリクエスト数を制限しています。

対処法1：503を返した層を特定する

何かを再起動する前に、メッセージとレスポンスヘッダーを確認しましょう。どの層が応答したかがわかります。DNS RobotのHTTPヘッダーチェッカーやcurl -sIで外部から確認し、serverヘッダーと本文を見てください（上の表を参照）。

そのうえで、Webサーバーだけでなく、実際に問題が起きている層を再起動します。

# Restart Nginx
sudo systemctl restart nginx

# Restart Apache
sudo systemctl restart apache2      # Debian/Ubuntu
sudo systemctl restart httpd         # CentOS/RHEL

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm    # Adjust version as needed

# Restart Node.js (PM2)
pm2 restart all

# Restart entire server (last resort)
sudo reboot

再起動から数分以内に503が戻ってくるなら、原因はまだ残っています。リソースとログの確認に進みましょう。

対処法2：サーバーリソース（CPU、RAM、ディスク）を確認する

サーバーが過負荷状態の場合、再起動は一時的な対処にしかなりません。何がリソースを消費しているか確認しましょう。

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space
df -h

# Check memory in detail
free -m

# Check active connections
ss -s

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

CPUまたはRAMが90%以上の場合、アプリケーションの最適化、暴走プロセスの終了、またはサーバーのアップグレードが必要です。ディスク容量が満杯の場合は、ログファイル、古いバックアップ、一時ファイルを削除してください。

対処法3：エラーログを確認する

ログを見れば、503が起きた理由が正確にわかります。下のコマンドで最新の行を読み、次の文言を探してください。

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log      # Debian/Ubuntu
tail -50 /var/log/httpd/error_log         # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# WordPress debug log (if WP_DEBUG_LOG is enabled)
tail -50 /var/www/html/wp-content/debug.log

# System log
tail -50 /var/log/syslog

「limiting requests」または「limiting connections」（nginx）— limit_reqまたはlimit_connがリクエストを拒否しました。limit_req_statusやlimit_conn_statusを設定していなければ、503を返します。

「max_children」（PHP-FPM、例：「server reached pm.max_children setting」）— PHPワーカーがすべて使用中です。この場合、Apacheは503を返しますが、nginxは502または504を返します。

「AH01114」／「failed to make connection to backend」（Apacheのmod_proxy）— Apacheがバックエンドに接続できず、503を返しました。

「Too many connections」（MySQL）— データベースの接続数の上限に達しています。

nginxの「no live upstreams」と「upstream timed out」は503ではなく、502 Bad Gatewayと504 Gateway Timeoutに当たります。

対処法4：プラグインとテーマを無効化する（WordPress / CMS）

WordPressなどのCMSでは、重いプラグインがPHPワーカーやホスティングのリソース上限を使い果たし、503になることがあります（プラグインがクラッシュした場合は503ではなく500になります）。プラグインの更新やインストールの後に503が出始めたなら、まずそのプラグインを疑いましょう。

WordPress管理画面にアクセスできない場合は、ファイルシステムまたはデータベース経由でプラグインを無効化できます。

# Disable all plugins by renaming the plugins folder
cd /var/www/html/wp-content
mv plugins plugins_disabled

# If the site loads, rename it back and re-enable plugins one by one
mv plugins_disabled plugins

# To disable a single plugin
mv plugins/problem-plugin plugins/problem-plugin.disabled

不具合のあるプラグインを特定したら、更新、代替プラグインへの変更、またはプラグイン開発者への問い合わせを行ってください。また、PHPバージョンの互換性も確認しましょう。サーバーのPHPアップグレード時に一部のプラグインが動作しなくなることがあります。

「Briefly unavailable for scheduled maintenance」（日本語のサイトでは「現在メンテナンス中のため、しばらくの間ご利用いただけません。」）のまま戻らない場合：WordPressは更新中にサイトのルートに.maintenanceファイルを作成し、作成から10分を過ぎたファイルは無視します。早く戻したいなら、このファイルを削除してください。それでもメッセージが消えない場合は、wp-content/maintenance.phpファイルや、キャッシュされたページのコピーがないか確認しましょう。

対処法5：PHPとサーバーの制限値を引き上げる

PHPワーカーの不足やメモリ制限に達した場合は、設定ファイルで制限値を引き上げる必要があります。

; PHP-FPM pool (e.g. /etc/php/8.2/fpm/pool.d/www.conf); the default ships with pm.max_children = 5
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; php.ini (defaults: memory_limit = 128M, max_execution_time = 30)
memory_limit = 256M
max_execution_time = 300

変更後は、新しい上限を読み込ませるためにPHP-FPMを再起動してください（sudo systemctl restart php8.2-fpm、バージョンは環境に合わせて）。

対処法6：CDNやロードバランサーを確認する

Cloudflareや他のCDN、ロードバランサーを使っている場合、503はサーバーではなくそちらから返されている可能性があります。

Cloudflareによる見分け方（Cloudflareの503ガイド）は次のとおりです。

• ページに「cloudflare」または「cloudflare-nginx」とある場合 — Cloudflareが生成したページです。CPUやメモリの上限を超えたWorkerがないか確認し、/cdn-cgi/traceの出力を添えてCloudflareのサポートに問い合わせてください。
• Cloudflareの表示がない場合 — オリジンサーバーが503を返し、Cloudflareがそれをそのまま中継しています。オリジンのログを確認し、ホスティング会社がCloudflareのIPアドレスにレート制限をかけていないか問い合わせましょう。

HAProxy、クラウドのロードバランサー、KubernetesのIngressの場合は、バックエンドを確認してください。そこでの503は、たいていリクエストを受けられるバックエンドがないことを意味します（AWSのApplication Load Balancerなら、ターゲットグループに登録済みのターゲットがないということです）。DNS RobotのDNS確認で、ドメインが想定どおりの場所を指しているかも確認しましょう。

対処法7：DDoSやボット攻撃を確認する

ボットからの突然のトラフィック急増やDDoS攻撃は、サーバーを圧倒します。アクセスログで不審なパターンを確認しましょう。

# Count requests per IP in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Requests per minute (use -f1-4 for per second)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP (-I puts the rule first, before any ACCEPT rules)
sudo iptables -I INPUT -s 1.2.3.4 -j DROP

# Or in nginx's server block:
# deny 1.2.3.4;

1つのアドレスや狭い範囲から数千件のリクエストが来ているなら、ファイアウォールでブロックしましょう。CloudflareなどのCDNを経由している場合は、まずログに実際の訪問者のIPが記録されるようにします（nginxのset_real_ip_fromとreal_ip_header CF-Connecting-IP）。そうしないと、攻撃者ではなくCDNをブロックしてしまいます。大規模な攻撃には、Cloudflareの「I'm Under Attack」モードやホスティング会社のDDoS対策が、サーバーに届く前にトラフィックをふるい落としてくれます。

対処法8：データベース接続の問題を修正する

データベースの接続数が尽きたり、データベースが停止したりすると、その手前のアプリケーションが失敗することがあります。このとき503を返すアプリもありますが、WordPressは代わりに「Error establishing a database connection」（日本語のサイトでは「データベース接続確立エラー」）を表示します。データベースを直接確認しましょう。

# Check if MySQL/MariaDB is running (the unit is mysqld on RHEL, mariadb for MariaDB)
sudo systemctl status mysql

# Restart MySQL
sudo systemctl restart mysql

# Check current connections vs limit
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# Increase max connections (temporary)
mysql -e "SET GLOBAL max_connections = 200;"

# Check for long-running queries
mysql -e "SHOW PROCESSLIST;" | head -20

スリープ状態の接続が多数ある場合、アプリケーションがデータベース接続を適切に閉じていません。長時間実行中のクエリが他のクエリをブロックしている場合は、そのクエリを最適化するか強制終了してデータベースのブロックを解除しましょう。

対処法9：ホスティングプロバイダーに問い合わせる

共有ホスティング、マネージドWordPressホスティング、またはSquarespace、Wix、Shopifyなどのプラットフォームを利用している場合、サーバーログへのアクセスやサービスの再起動ができないことがあります。このような場合、503はホスティングプロバイダーのインフラが原因の可能性があります。

ホスティングプロバイダーのサポートに以下の情報を伝えてください。

• 503が返されるURL — 正確なURLを伝える
• エラーが始まった時刻 — 日時を記録しておく
• 変更点 — プラグインのインストール、テーマの更新、DNS設定の変更などを行ったか
• 断続的か恒常的か — 断続的な503はリソース制限を、恒常的な503はクラッシュや設定ミスを示唆します

503と他のHTTPエラーの違い

503エラーは他のサーバーエラーと混同されがちです。それぞれの違いを以下にまとめます。

重要な違いは、503はもともと一時的なエラーであることです。Retry-Afterヘッダーで期間を示すこともできます。クロールについては、Googleは5xxエラーと429エラーを同じように扱います。クローラーはクロールの頻度を落とし、インデックス済みのURLはしばらく保持しますが、エラーが続けば最終的にインデックスから削除します（Google検索セントラル）。

プロキシ側のエラーについては502 Bad Gatewayと504 Gateway Timeoutを、レート制限については429 Too Many Requestsを参照してください。

503エラーを予防する方法

予防は事後対応よりも効果的です。503エラーを未然に防ぐためのベストプラクティスを紹介します。

• サーバーリソースの監視 — CPU 80%超、RAM 85%超、ディスク 90%超でアラートを設定しましょう。UptimeRobot、Pingdom、Grafanaなどのツールで即座に通知を受け取れます。
• CDNの利用 — Cloudflare、Fastly、AWS CloudFrontは静的アセットをキャッシュし、トラフィックの急増を吸収してオリジンサーバーの負荷を軽減します。
• キャッシュの有効化 — Redis、Memcached、Varnishを使ってデータベースクエリやレンダリング済みページをキャッシュしましょう。WordPressユーザーはWP Super CacheやW3 Total Cacheなどのキャッシュプラグインを導入してください。
• オートスケーリング — クラウドホスティング（AWS、GCP、Azure、DigitalOcean）を利用している場合、トラフィック急増時に自動でサーバーを追加するオートスケーリングを設定しましょう。
• ボットのレート制限 — 攻撃的なクローラーやスクレイパーがサーバーを過負荷にする前に、nginxまたはCloudflareでレート制限を設定しましょう。
• データベースクエリの最適化 — 遅いクエリは接続やワーカーを長時間ふさぎます。インデックスの追加やJOINの最適化を行い、結果をRedisやMemcachedにキャッシュしましょう。
• 適切なメンテナンスページの使用 — デプロイ中はサーバーをクラッシュさせるのではなく、Retry-Afterヘッダー付きの503を返しましょう。SEOを守り、ユーザーに状況を伝えられます。
• ソフトウェアの最新化 — CMS、プラグイン、PHP、データベースを最新の安定版に更新して、既知のバグやセキュリティ上の問題を避けましょう。