503エラーとは？原因・直し方・SEOへの影響を解説

Q: 503エラーと502・504エラーの違いは何ですか？

503はサービスが一時的にリクエストを処理できない状態です。502はゲートウェイやプロキシが上流から不正な応答を受けた状態、504は上流の応答を待ったものの時間切れになった状態を示します。

503 Service Unavailableは、サーバーが一時的にリクエストを処理できないことを示すHTTPステータスコードです。 閲覧者は連続更新や送信の再実行を避け、運営者は再起動の前に、発生時刻・影響範囲・直前の変更・ログ・リソース・依存サービスを同じ時間軸で確認します。

30秒で分かる結論

503は一時的な利用不可。まず発生元を特定し、可逆な復旧から行う

代表的な原因は、アクセス集中、CPU・メモリ・接続数などの枯渇、計画メンテナンス、アプリやデータベースの停止、デプロイ後のヘルスチェック失敗です。エラー番号だけで設定を変えず、CDN・プロキシ・アプリ・DBのどこが503を返しているかを先に確認します。

閲覧者待ってから一度だけ再試行。決済・予約・送信は重複実行しない

運営者変更を止め、ログ・監視・依存先を同じ発生時刻で突き合わせる

SEO短時間の正しい503は適切。長期化するとクロールと登録に影響する

意味	サービスが一時的にリクエストを処理できない状態
主な原因	過負荷、リソース枯渇、メンテナンス、上流・DB停止、設定不整合
閲覧者の対応	連続更新を避け、少し待って一度だけ再試行。送信結果を先に確認
運営者の対応	影響範囲と時刻を固定し、変更・ログ・監視・依存先を順番に確認
SEO	短時間なら一時停止を伝える適切な応答。長期化は避ける
確認日	2026年7月29日

503 Service Unavailableの意味

HTTPの仕様を定めるRFC 9110では、503は一時的な過負荷または計画メンテナンスにより、現在リクエストを処理できない状態と定義されています。復旧までのおおよその時間を示せる場合、サーバーは任意でRetry-Afterヘッダーを返せます。

大切なのは、503が「サーバー本体の故障」だけを意味しない点です。ブラウザとアプリの間には、CDN、WAF、ロードバランサー、リバースプロキシ、コンテナ、データベースなど複数の層があります。どの層が503を生成したかは、レスポンスヘッダー、ログ、監視画面を突き合わせて判断します。

503は「原因名」ではなく「現在処理できない」という結果

同じ503でも、PHP-FPMのワーカー不足、DB接続枯渇、ロードバランサーの正常バックエンド不在、CDNの一時ブロックでは対処が異なります。エラー番号だけで設定を変更せず、発生元を先に特定します。

500・502・503・504・429の違い

5xxはサーバー側のエラーですが、番号ごとに示す状況が異なります。実際の原因は構成とログで確定させる必要があるものの、最初の切り分けには次の表が役立ちます。

コード	意味	よくある状況	最初に見る場所
500	Internal Server Error	アプリ例外、設定ミス、権限エラーなど、処理中に予期しない失敗が発生	アプリログ、Webサーバーのerror log、直前の変更
502	Bad Gateway	プロキシが上流サーバーから無効・不完全な応答を受信	リバースプロキシ、上流アプリ、接続・証明書
503	Service Unavailable	一時的な過負荷、メンテナンス、正常なバックエンド不在	負荷、ワーカー、ヘルスチェック、依存サービス
504	Gateway Timeout	プロキシが上流サーバーの応答を待ったが期限内に返らない	上流処理時間、タイムアウト、DB・外部API遅延
429	Too Many Requests	特定クライアントやAPIキーがレート制限を超過	WAF、APIゲートウェイ、レート制限ルール

決済・予約・送信処理の連打に注意

503の直後にPOSTや購入ボタンを繰り返すと、画面はエラーでも上流側では処理が完了しており、二重注文や重複登録になることがあります。履歴や確認メールを確認してから再実行してください。

503エラーが発生する主な原因

原因を早く見つけるには、「サーバーが重い」という一括りの見方をやめ、受付、アプリ、データ、外部依存、配信経路の層に分けて確認します。

アクセス集中と同時実行数の上限

キャンペーン、SNS拡散、クローラー、攻撃的なアクセスで、ワーカー数や接続数の上限に達すると新しい処理を受け付けられません。

CPU・メモリ・ディスク・接続プールの枯渇

CPU使用率だけでなく、メモリ、ファイルディスクリプタ、PHPワーカー、DB接続、キュー長などの飽和も確認します。

データベース・キャッシュ・外部APIの停止

アプリ本体が動いていても、DB、Redis、決済API、認証基盤などへ接続できなければ、サービス全体が503を返す場合があります。

デプロイ・設定変更・ヘルスチェック不整合

環境変数、ポート、証明書、ルーティング、readiness条件の変更で、新しいインスタンスが正常扱いにならないことがあります。

計画メンテナンス

更新作業中に意図的に503を返す構成です。メンテナンスページが表示されても、HTTPステータスが200になっていないか確認します。

CDN・WAF・ロードバランサーの制御

レート制限、bot対策、オリジン到達不能、正常バックエンド不在など、アプリより手前の層が503を生成することがあります。

WordPress・PHPの処理滞留

重いプラグイン、wp-cron、バックアップ、外部通信、PHP-FPMワーカー不足、DBクエリ遅延が同時に重なると503につながります。

ホスティング事業者・リージョン側の障害

自分の変更がなく複数サイトや複数回線で発生する場合、事業者の障害情報、稼働状況、サポート窓口を確認します。

サイト閲覧者ができる対処法

503は多くの場合、閲覧者の端末ではなくサービス側の問題です。何度も設定を変えるより、重複処理を避けながら状況を確認するほうが安全です。

数分待ち、一度だけ再読み込みする

Retry-Afterが表示・送信されている場合は、その時間を尊重します。連続更新はサーバー負荷を増やすため避けてください。
公式の障害情報とメンテナンス告知を確認する

サービスのステータスページ、公式サイト、公式SNSを確認します。広域障害なら端末側の操作では解消しません。
決済・予約・フォーム送信の結果を先に確認する

購入履歴、予約一覧、確認メールを確認し、処理済みなら再送信しません。判断できない場合は運営窓口へ問い合わせます。
自分だけ発生する場合は別回線で切り分ける

Wi-Fiとモバイル回線、通常画面とシークレットウィンドウで結果が変わるなら、CDN・WAFの判定やネットワーク経路の差も考えられます。

キャッシュ削除は最優先ではありません

503は通常サーバー側の応答です。古いエラーページがキャッシュされている例はありますが、まずは待機と公式情報の確認を優先し、端末設定の初期化やアプリの再インストールまで行う必要はありません。

サイト運営者向けの安全な復旧手順

復旧を急ぐほど、複数の設定を同時に変更したくなります。しかし、原因の記録を失うと一時的に直っても再発します。次の順番で「観測 → 切り分け → 可逆な緩和 → 検証」を進めます。

影響範囲と最初の発生時刻を固定する

対象URL、HTTPメソッド、端末・回線、地域、ステータスコード、最初の検知時刻を記録します。トップだけか、管理画面やAPIも含むかを分けます。
変更を止め、直前のデプロイとメンテナンスを確認する

追加デプロイ、設定変更、負荷試験、バッチ投入を一旦止めます。503の開始時刻と、リリース・証明書・環境変数・DNS変更の時刻を照合します。
どの層が503を返したか確認する

レスポンスヘッダーのServer、Via、CDN固有ID、リクエストID、エラーページの文言を確認します。ブラウザ画面だけでオリジン障害と断定しません。
ログと監視値を同じ時間軸で見る

アクセスログ、Webサーバー、アプリ、ロードバランサー、DB、外部APIのログを相関させます。CPUだけでなくメモリ、接続数、キュー、ワーカー、エラー率、遅延を確認します。
影響を抑えた変更を一つずつ実施する

承認済みロールバック、トラフィック制限、重いバッチの停止、静的キャッシュ、正常インスタンスへの切替など、戻せて記録できる操作を一つずつ行います。
復旧後の安定を確認してから完了とする

主要URLの2xx、エラー率、p95・p99遅延、DB成功率、キュー長を一定時間監視します。単発の200だけで復旧完了とせず、再発条件が消えたことを確認します。

まずレスポンスヘッダーと応答時間を確認する

ブラウザの画面だけでは、ステータスコードや発生元が分かりません。GETリクエストでヘッダーを取得し、複数回線・複数URLで比較します。

terminal
# レスポンスヘッダーを表示し、本文は保存しない
curl -sS -D - -o /dev/null https://example.com/

# ステータス、合計時間、接続先IPを確認
curl -sS -o /dev/null \
  -w 'status=%{http_code} total=%{time_total}s remote=%{remote_ip}\n' \
  https://example.com/

curl -IはHEADリクエストを送るため、GETと挙動が異なるアプリでは結果が変わる場合があります。実際の閲覧に近い確認には、上記のようにGETのまま本文だけ破棄する方法が安全です。

Retry-Afterを返す場合の例

復旧予定を示せる計画メンテナンスでは、秒数またはHTTP-date形式で再試行時刻を伝えられます。実際の設定方法は利用中のWebサーバーやCDNの公式資料を確認してください。

http response
HTTP/1.1 503 Service Unavailable
Retry-After: 300
Cache-Control: no-store
Content-Type: text/html; charset=UTF-8

自動リトライはメソッドを区別する

GETなどの冪等な処理と、POST・PATCHなど状態を変更する処理を同じように再送しないでください。リバースプロキシの上流切替を設定する場合も、重複処理を避ける設計と回数・時間の上限が必要です。

環境別に確認したいポイント

同じ503でも、WordPress、リバースプロキシ、CDN、コンテナでは調査箇所が異なります。該当する構成から順に確認してください。

WordPress 共有サーバー・PHP

ホスティング会社の障害情報、CPU・メモリ・同時実行数などの制限
PHP-FPMワーカー、PHPエラーログ、Webサーバーのerror log
直前に更新したプラグイン・テーマ・PHPバージョン
バックアップ、画像変換、wp-cron、外部API通信などの重い処理
DB接続数、遅いクエリ、optionsテーブルの肥大化、キャッシュ状態
更新失敗後に残ったメンテナンス状態や一時ファイル

NGINX / Apache リバースプロキシ

upstreamの接続拒否、タイムアウト、無効な応答、正常サーバー数
proxy・FastCGIの接続先、ポート、UNIXソケット、権限
ワーカー接続数、ファイルディスクリプタ、キープアライブ
上流切替条件と試行回数。非冪等リクエストを無制限に再送しない
エラーページを表示しながら200を返していないか

CDN / WAF 配信・防御レイヤー

CDNのステータスページ、オリジン到達性、証明書、DNS
WAF・bot対策・レート制限が正規ユーザーやGooglebotを遮断していないか
エラーレスポンスがCDN生成かオリジン生成かを固有ヘッダーで判定
キャッシュ済み503の保持時間と、復旧後のパージ対象
ロードバランサーのヘルスチェックURL、期待コード、タイムアウト

Container / Serverless Cloud環境

正常インスタンス数、readiness・liveness、起動失敗
最大インスタンス、同時実行数、CPU・メモリ上限、オートスケール遅延
コンテナの待受ポート、環境変数、シークレット、IAM
新旧リビジョンへのトラフィック比率とロールバック可否
DBコネクションの増え方と、スケールアウト時の接続集中

503エラーがSEOに与える影響

短時間の計画メンテナンスで正しく503を返すこと自体は、検索エンジンに一時停止を伝える適切な方法です。エラーページを見せながら200を返したり、一時停止なのに404を返したりするより、状態を正確に表せます。

一方、Googleの公式資料では、5xxと429が返るとクローラーは一時的にクロールを遅くし、すでに登録されているURLは当初維持されるものの、エラーが継続すると最終的にインデックスから外れる可能性があると説明されています。2xxに戻ると、クロール頻度は徐々に回復します。

メンテナンス時のSEOチェック

一時停止中はHTTPステータス503を返す
復旧予定を示せる場合はRetry-Afterを付ける
エラーページを200で返さない
サイト全体を長期間503のままにしない
復旧後は主要URLが2xxに戻ったことを確認する
Search Consoleとサーバーログで5xxの減少を確認する

503発生時に確認するSEO項目

トップページだけでなく、robots.txt、XMLサイトマップ、CSS・JavaScriptも取得できるか
GooglebotだけをWAFやレート制限で誤って遮断していないか
CDNとオリジンの両方で、同じURLがどのステータスを返すか
エラーページにnoindexを付けることより、正しい503を返すことを優先しているか
復旧後、URL検査とページのインデックス登録レポートで状態を確認したか

503エラーを再発させないための対策

再発防止は「サーバーを強くする」だけでは不十分です。負荷の入口、処理の滞留、依存先障害、デプロイ失敗を早く検知し、影響を小さくする仕組みを組み合わせます。

飽和指標を監視する

CPUだけでなく、メモリ、接続数、ワーカー、キュー、DBプール、エラー率、p95・p99遅延にしきい値を設けます。

負荷を平準化する

CDN・キャッシュ、キュー、非同期処理、レート制御、重いバッチの時間分散で、瞬間的な集中を吸収します。

安全にスケールする

オートスケール上限、起動時間、DB接続上限をセットで設計します。アプリだけ増やしてDBを枯渇させないことが重要です。

デプロイを段階化する

カナリアリリース、ヘルスチェック、ロールバック、DBマイグレーションの互換性確認で全台同時障害を避けます。

復旧手順をRunbook化する

連絡先、確認ログ、判断基準、ロールバック、告知、復旧確認を文書化し、担当者が変わっても同じ順番で動けるようにします。

重複実行を防ぐ

決済・予約・登録APIでは冪等性キーや重複チェックを設け、503後の再送でも二重処理にならない設計にします。

復旧確認チェックリスト

作業を終える前に、次の項目を一つずつ確認します。単発の表示成功だけでなく、サービス全体が安定しているかを見ます。

対象URL、API、管理画面が継続して2xxを返している
5xx率とタイムアウト率が通常水準へ戻っている
p95・p99の応答時間が悪化したままになっていない
CPU、メモリ、接続数、キュー、ワーカーに余裕がある
DB、キャッシュ、外部APIの成功率が回復している
CDN・ロードバランサーの正常バックエンド数が戻っている
決済・予約・フォームに重複処理が発生していない
メンテナンスページとRetry-Afterが解除されている
Search Consoleと監視で新しい5xxが増えていない
原因、判断、変更、復旧時刻、再発防止策を記録した

503エラーに関するよくある質問

503エラーは放置しても直りますか？

一時的なアクセス集中や計画メンテナンスなら自然に解消する場合があります。ただし、繰り返し発生する503は、リソース不足、依存サービス停止、設定不整合などが残っている可能性があります。運営者はログと監視値を確認してください。

503エラーと502・504エラーの違いは何ですか？

503はサービスが一時的に処理できない状態です。502はゲートウェイやプロキシが上流から不正な応答を受けた状態、504は上流の応答を待ったものの時間切れになった状態を示します。

ブラウザのキャッシュを削除すれば直りますか？

503は通常サーバー側またはCDN・プロキシ側の問題なので、キャッシュ削除だけで直るケースは多くありません。公式の障害情報を確認し、少し待ってから一度だけ再試行してください。

503エラーはSEOに悪影響がありますか？

短時間の計画メンテナンスで正しく503を返すことは適切な運用です。一方、5xxが長期間続くとGoogleのクロール頻度が低下し、継続的にエラーを返すURLは最終的にインデックスから外れる可能性があります。

Retry-Afterヘッダーには何を設定しますか？

復旧予定時刻をHTTP-date形式で指定するか、再試行までの秒数を0以上の整数で指定します。復旧見込みが分かる計画メンテナンスなどで利用します。

サーバーを再起動すれば503エラーは直りますか？

一時的に復旧することはありますが、原因不明のまま再起動するとログや接続状態などの調査材料を失う場合があります。変更履歴、ログ、リソース、依存先を確認し、記録可能で可逆な復旧手順として実施してください。

公式資料・参考情報

HTTPの意味はRFCを基準にし、検索クローラーへの影響や実装固有の設定は、利用中のサービス・Webサーバーの公式資料で確認してください。

この記事は、2026年7月29日時点のHTTP仕様および各公式資料をもとに一般的な判断手順を整理したものです。実際の復旧操作は、契約中のホスティングサービス、クラウド、CDN、Webサーバーの仕様とバックアップ方針に従ってください。

執筆・検証：Hikaru OnoWebサイト・業務システムの設計と開発を担当。Go、HTML/CSS、Flutter、Firebaseなどを使い、公開後の運用まで見据えた構成を支援しています。