HTTPエラー503 Service Unavailableの原因と解決方法

HTTPエラー503とは？

HTTPエラー503（Service Unavailable）は、Webサーバーが一時的にリクエストを処理できないことを示すサーバー側のステータスコードです。404エラー（ページが見つからない）や500エラー（内部サーバーエラー）とは異なり、503は明確に一時的な状態を示します。サーバー自体は存在し到達可能ですが、今はコンテンツを配信できない状態です。

HTTP仕様（RFC 9110）によれば、サーバーはRetry-Afterヘッダーを含めて、クライアントが再試行するまでの待機時間を示すことができます。このヘッダーにより、ブラウザ、検索エンジンのクローラー、APIクライアントはサービスの復旧予定時刻を知ることができます。

重要なのは「一時的」というキーワードです。適切に設定された503レスポンスは、Googleなどのサーチエンジンにページをインデックスから削除するのではなく、後で再訪問するよう伝えます。そのため、計画的なメンテナンス時に503を使用することでSEOランキングを維持できます。

503エラーの表示例

文言は異なっていても、根本的な原因は常に同じです。サーバーがリクエストを受信したものの、現時点では処理できない状態にあります。

• 503 Service Unavailable

• 503 Service Temporarily Unavailable

• HTTP Error 503. The service is unavailable.

• Error 503 Backend Fetch Failed（Varnishキャッシュ）

• 503 Service Unavailable — No server is available to handle this request（Apache）

• 503 Service Temporarily Unavailable — nginx（Nginx）

• Error 503 (Service Unavailable)!! 1（Cloudflareオリジンエラー）

• サイトは一時的にご利用いただけません または 定期メンテナンスのため一時的にご利用いただけません（WordPress）

HTTPエラー503の主な原因

根本原因を理解することが、最も素早い修正への近道です。サーバーが503を返す主な理由を、発生頻度の高い順に紹介します。

• サーバーの過負荷 — CPU、RAM、接続数の上限に達した状態。トラフィックの急増、バイラルコンテンツ、ボットの大量クロールなどで発生します。

• 計画的なメンテナンス — サイト管理者がアップデート、移行、デプロイのために意図的にサーバーをオフラインにしている状態。適切に設定されたメンテナンスページはRetry-Afterヘッダー付きの503を返します。

• プラグインやテーマの不具合 — WordPress、Joomla、MagentoなどのCMSプラットフォームでは、バグのあるプラグイン、テーマ更新の競合、PHPバージョンの非互換性がアプリケーションをクラッシュさせ503を引き起こすことがあります。

• PHP-FPMまたはアプリケーションのクラッシュ — PHPプロセスマネージャー（php-fpm）のワーカープロセスが枯渇した、またはアプリケーションバックエンド（Node.js、Python、Ruby）がクラッシュした状態。Webサーバー（Nginx/Apache）は動作していますが、リクエストを転送するバックエンドがありません。

• データベースの過負荷 — データベース（MySQL、PostgreSQL）が接続数上限に達した、メモリ不足、長時間クエリによるロックが発生した状態。アプリケーションがデータを取得できず503を返します。

• DDoS攻撃 — 分散型サービス拒否攻撃がサーバーに大量のリクエストを送り込み、リソースを枯渇させ、正規のリクエストが503で失敗します。

• DNSまたはCDNの設定ミス — Cloudflare、AWS CloudFront、その他のCDNがDNS変更、SSL期限切れ、IPホワイトリストの問題などでオリジンサーバーに到達できない状態です。

• リソース制限への到達 — 共有ホスティングプランではCPU、RAM、同時接続数に厳しい制限があります。これらを超過すると、ホスティングプロバイダーがリクエストを制限または503でブロックします。

訪問者向けの対処法

他の人のウェブサイトで503エラーが表示された場合、問題はそのサーバー側にあります。あなたのデバイスの問題ではありません。ただし、いくつか試せることがあります。

• 待ってから再読み込み — 503は一時的なエラーなので、30〜60秒待ってからページを更新してください。サーバーが再起動中またはデプロイ完了中の可能性があります。

• サイトが全員に対してダウンしているか確認 — DNS RobotのHTTPヘッダーツールを使って、外部サーバーからのレスポンスコードを確認しましょう。全員に503が返されていれば、サイトは本当にダウンしています。

• ブラウザキャッシュをクリア — まれに、ブラウザが503レスポンスページをキャッシュしている場合があります。キャッシュをクリアして再度アクセスしてください。

• 別のブラウザやデバイスで試す — ブラウザ固有のキャッシュや拡張機能の問題を排除できます。

• サイトのSNSを確認 — サイトがX（Twitter）やステータスページで計画的メンテナンスや既知の障害について告知している場合があります。

対処法1：Webサーバーを再起動する

再起動後、すぐにサイトをテストしてください。数分以内に503が再発する場合は、根本原因がまだ存在しています。ログとリソースの確認に進みましょう。

# 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

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

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

# 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

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

503の原因となる代表的なログメッセージ：

"upstream timed out" または "no live upstreams"（Nginx） — PHP-FPMまたはバックエンドアプリが応答していません。php-fpmを再起動するかタイムアウト値を増やしてください。

"server reached pm.max_children"（PHP-FPM） — すべてのPHPワーカープロセスがビジー状態です。PHP-FPMプール設定でpm.max_childrenを増やしてください。

"Too many connections"（MySQL） — データベースの接続数上限に達しています。MySQL設定でmax_connectionsを増やすか、クエリを最適化してください。

"Cannot allocate memory" — サーバーのRAMが不足しています。不要なプロセスを終了するか、スワップ領域を追加してください。

# 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

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

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

# 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

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

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

# PHP-FPM pool config (e.g., /etc/php/8.2/fpm/pool.d/www.conf)
pm = dynamic
pm.max_children = 50          # Increase from default (5-10)
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

# PHP memory limit (php.ini)
memory_limit = 256M           # Increase from default 128M
max_execution_time = 300      # Increase from default 30

# Restart PHP-FPM after changes
sudo systemctl restart php8.2-fpm

対処法6：DNSとCDNの設定を確認する

診断するには、DNS RobotのDNSルックアップを使ってドメインが正しいIPアドレスを指しているか確認しましょう。DNS RobotのHTTPヘッダーツールでサーバーが返すステータスコードを確認することもできます。DNSがCloudflareを指しているのにオリジンIPが変更されている場合は、CloudflareダッシュボードでAレコードを更新してください。

• Cloudflareブランドの503：エラーページにCloudflareのロゴが表示される場合 — Cloudflareのデータセンター側の問題です（まれ）。

• Cloudflare経由のオリジン503：エラーページがプレーンまたはサイト独自のデザインの場合 — オリジンサーバーが503を返し、Cloudflareがそのまま通過させています。

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

単一のIPまたは少数のIP範囲から数千のリクエストが来ている場合は、ファイアウォールレベルでブロックしてください。大規模なDDoS攻撃の場合は、Cloudflareの「Under Attack Mode」を有効にするか、ホスティングプロバイダーのDDoS対策を利用しましょう。DNS RobotのIPブラックリストチェッカーを使えば、攻撃元のIPが既知のブラックリストに載っているか確認できます。

# 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

# Check requests per second
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP with iptables
sudo iptables -A INPUT -s 1.2.3.4 -j DROP

# Or block with Nginx
# Add to server block: deny 1.2.3.4;

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

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

# Check if MySQL/MariaDB is running
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は503を500とは異なる扱いをし、短時間の障害であればリトライしてランキングを維持します。

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で攻撃的なクローラーやスクレイパーがサーバーを過負荷にする前にレート制限を設定しましょう。

• データベースクエリの最適化 — 遅いクエリはデータベース関連の503の最大の原因です。インデックスの追加、JOINの最適化、クエリキャッシュの活用を行いましょう。

• 適切なメンテナンスページの使用 — デプロイ中はサーバーをクラッシュさせるのではなく、Retry-Afterヘッダー付きの503を返しましょう。SEOを守り、ユーザーに情報を伝えられます。

• ソフトウェアの最新化 — CMS、プラグイン、PHP、データベースを最新の安定版に更新して、既知のバグやセキュリティ上の問題を避けましょう。