【Web エラー】503 Service Temporarily Unavailable とは？原因と対策・502 との違い

はじめに

Web サイトを閲覧している際や、システムの運用管理を行っている際に、「503 Service Temporarily Unavailable」というエラー画面に遭遇することがあります。

このエラーは、アクセス先のサーバーが一時的に過負荷状態にあるか、メンテナンス中であるため、リクエストを正常に処理できないことを示す HTTP ステータスコードです。単なるアクセスの集中からバックエンドサービスの停止まで、発生する理由は多岐にわたります。

本記事では、503 エラーの概要や混同されやすい「502 Bad Gateway」との違いをはじめ、発生する主な原因と一般的な対策について解説します。また、システム管理者の方向けの実例として、vCSA（VMware vCenter Server Appliance）や Apache リバースプロキシ環境において 503 エラーが発生した場合のトラブルシューティング手順も併せて紹介します。

503 Service Temporarily Unavailable とは？

「503 Service Temporarily Unavailable」は、Web サイトや Web アプリケーションにアクセスした際、サーバーが一時的にリクエストを処理できない状態であることを示す HTTP ステータスコードです。

このエラーが返される場合、サーバーのネットワーク機能自体は稼働して通信に応答できていますが、過負荷状態やメンテナンスなどの理由により、要求された処理を実行する余裕がないことを意味しています。「Temporarily（一時的に）」とあるように、サーバーの物理的な故障などの恒久的な障害ではなく、原因が解消されれば復旧する性質を持っています。

似ているエラー「502 Bad Gateway」との違い

503 エラーと混同されやすいものに、「502 Bad Gateway」があります。どちらも「Web サイトが表示されない」という結果は同じですが、システム内部で問題が発生している箇所が異なります。

503 Service Temporarily Unavailable

アクセス先となるサーバー自身が、「現在、リクエストを処理する余裕がない（またはメンテナンス中）」と応答している状態です。サーバーのリソース不足が主な原因です。

502 Bad Gateway

アクセス先のサーバー（プロキシやロードバランサーなど）が、その背後にある別のサーバー（アプリケーションサーバーなど）から「不正な応答を受け取った」または「通信できなかった」状態です。サーバー間の連携エラーが主な原因です。

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

503 エラーは「サーバーが一時的に処理を拒否している」状態ですが、その背景には主に以下のような原因があります。

アクセスの集中によるリソース（CPU・メモリ）の枯渇

最も一般的な原因は、Web サイトへの突発的なアクセス集中です。SNS での拡散やテレビ番組での紹介などにより、想定を大きく超えるトラフィック（アクセス数）が発生すると、サーバーの CPU やメモリ、あるいは同時接続数の上限に達してしまい、新たなリクエストを処理しきれずに 503 エラーを返します。

計画的なメンテナンスやサービスの再起動中

システム管理者が意図的に Web サーバーをメンテナンスモードに設定している場合や、サーバーの再起動処理を行っている最中にも 503 エラーが表示されます。この場合は、システム側が「現在サービスを提供できない」ことを正しく応答している正常な動作と言えます。

バックエンドサービス（データベースなど）の停止・異常

Web サーバー自体は正常に稼働していても、その裏側で連携しているアプリケーションプロセスやデータベースのサービスがダウンしている場合、要求された処理を完了できず 503 エラーとなることがあります。後述する vCSA 環境でのエラーも、この「バックエンドサービスの停止」に該当します。

503 エラーの一般的な対策

503 エラーに直面した場合の対策は、自身が「Web サイトの閲覧者（ユーザー）」であるか、「システムの管理者」であるかによって異なります。

ユーザー側の対策（基本は時間を置いて再アクセス）

Web サイトを閲覧していて 503 エラーが出た場合、ユーザー側で根本的に解決できる手段はありません。エラー画面に「Service Temporarily Unavailable（一時的に利用不可）」とある通り、基本的にはしばらく時間を置いてから再度アクセス（リロード）を試みます。

注意点として、エラー画面のまま何度も連続してページ更新（F5 連打）を行うと、サーバーにさらなる負荷をかけ、復旧を遅らせる原因となるため控えてください。

サーバー管理者側の対策（リソース拡張、負荷分散、ログの確認）

自身の管理する Web サイトやシステムで 503 エラーが発生している場合、以下の視点で調査と対策を行います。

【管理者向け実例】システム別の 503 エラー対処法

【実例1】vCSA 環境での 503 エラー（vpxd 停止・DB 肥大化）

システム管理の現場における具体的な事例として、VMware vCenter Server Appliance（vCSA 6.7 等）の Web 管理画面（vSphere Client）へアクセスした際、以下のような 503 エラーが表示されて接続できなくなるケースがあります。

503 Service Unavailable (Failed to connect to endpoint:
 [N7Vmacore4Http20NamedPipeServiceSpecE:0x0000562eebf99a50] _serverNamespace = / action = Allow _pipeName =/var/run/vmware/vpxd-webserver-pipe)

この事象は、前述した「バックエンドサービスの停止」の典型例であり、vCSA のコアサービスである「vpxd」が停止していることに起因します。

vpxd サービスの停止確認と起動

まずは vCSA へ SSH でログインし、service-control コマンドを使用してサービスの状態を確認します。

# サービスのステータス確認
service-control --status

実行結果の Stopped: の項目に vpxd が含まれている場合、サービスを起動します。

# vpxd サービスの起動とステータス確認
service-control --start vpxd
service-control --status vpxd

ステータスが Running: vpxd となれば復旧完了です。

データベース（/storage/seat）の肥大化確認と解消

上記のコマンドを実行しても Running にならない、あるいは起動直後に再び Stopped へ遷移してしまう場合は、vCSA 内部の PostgreSQL データベース領域（/storage/seat）が容量の上限（95%以上）に達している可能性があります。

ディスク使用率の確認

df -h /dev/mapper/seat_vg-seat

Use% が95%以上となっている場合は、不要なデータを削除して容量を空ける必要があります。

データベースへの接続と肥大化テーブルの特定

PostgreSQL へ接続し、容量を圧迫している上位5つのテーブルを特定します。

cd /opt/vmware/vpostgres/current/bin 
./psql -d VCDB -U postgres

SELECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size" FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_total_relation_size(C.oid) DESC LIMIT 5;

テーブルの削除（Truncate）

出力結果から肥大化しているテーブル（例: タスク履歴を保存する vc.vpx_task など）を確認し、内部のデータを削除します。

truncate table vc.vpx_task cascade;

ディスク使用率（Use%）が 90% 以下になるまで不要な履歴テーブルの削除を繰り返し、最後に vCSA 本体を再起動することで 503 エラーが解消されます。なお、再発を防ぐため、vCenter のデータベース設定から「タスクとイベントの保持期限（日数）」を短く調整しておくことを推奨します。

【実例2】Apache リバースプロキシ環境での 503 エラー（SELinux 起因）

Web サーバーのフロントに Apache を用いたリバースプロキシ（CentOS 等）を配置している環境において、クライアントからのアクセス時に 503 エラーが発生するケースがあります。

この場合、Apache のエラーログ（/var/log/httpd/error_log）を確認し、以下のような出力があれば、SELinux の設定が原因である可能性が高いです。

[error] (13)Permission denied: proxy: HTTP: attempt to connect to 10.1.x.x:8080 (10.1.x.x) failed

原因と対策

このエラーは、SELinuxのセキュリティ機能によって、httpd（Apache）プロセスがバックエンドの Web サーバーへネットワーク接続（プロキシ）することがブロックされているために発生します。

対策として、以下のコマンドを実行し、SELinux のブール値設定でhttpdのネットワーク接続を許可（有効化）します。

# httpdプロセスのネットワーク接続を許可する
/usr/sbin/setsebool -P httpd_can_network_connect 1

検証目的などで一時的に SELinux 自体を無効化する場合は、/etc/sysconfig/selinux ファイルの SELINUX=enforcing を disabled に変更して O を再起動します（セキュリティ上、本番環境での恒久的な無効化は非推奨です）。

まとめ

本記事では、Web アクセス時に発生する「503 Service Temporarily Unavailable」の概要と、管理者向けの実例について解説しました。

• 503 エラーは、サーバーの過負荷やメンテナンスによって一時的に処理ができない状態を示す。
• 似ている 502 エラーは、サーバー間の通信連携に問題がある点で発生箇所が異なる。
• ユーザー側は時間を置いて再アクセスし、管理者はリソース拡張やサービスの稼働状況を確認する。
• 実務の事例として、vCSA のサービス停止や、Apache の通信ブロック（SELinux）などが挙げられる。

以上、最後までお読みいただきありがとうございました。