503 | ErrorLog - エラーコード解決ガイド

OpenAI API の 503 エラー：原因と解決策

冒頭まとめ OpenAI API の 503 は、公式のエラー一覧で混雑として定義されています。文言は現在処理系が過負荷なので後で試すよう促す趣旨で、原因はサーバー側が大量の通信を受けていること、対処は短い待機のうえでの再試行、と明記されています。つまり、送った内容にも、自分の設定にも問題はありません。全利用者に対して起きている状態です。ただし、ここに落とし穴があります。同じ「過負荷」の文言は 429 でも返ります。公式の説明資料には、この文言が 429 の項目としても掲載されています。文言だけを読んで「混雑だから待とう」と判断すると、実際には自分の上限に達していた、という取り違えが起こります。この2つは対処が違います。503 は待てば通ります。429 は、レート制限なら待って通り、クォータ不足なら待っても永久に通りません。したがって、文言ではなく状態コードを見るのが出発点になります。エラーの概要応答は次の形です。 { "error": { "message": "The engine is currently overloaded, please try again later", "type": "server_error", "param": null, "code": null } } param も code も null です。500 と同じ構造で、指し示せる場所が無いことを示しています。公式のソフトウェア開発キットでは、状態コードが 500 以上のものがまとめて1つの区分になります。したがって、開発キットの例外の型だけでは 500 と 503 を区別できません。状態コードを取り出して確認する必要があります。再試行については、開発キットが接続の問題、408、409、429、そして 500 番台を既定で2回自動的に再試行します。503 もこの対象です。手元の記録に1回しか出ていなくても、実際は3回試したうえで諦めた状態です。まず最初に：状態コードで 429 と分ける第一に、状態コードを確認します。文言が「過負荷」でも、503 と 429 では意味が違います。第二に、429 だった場合は type を読みます。rate_limit_exceeded なら待てば通り、insufficient_quota なら待っても通りません（OpenAI API の 429 の記事）。 ...

Azure の 503 エラー：原因と解決策

エラーの概要 Azure 503 エラーは「Service Unavailable」を意味し、Azureサービスが一時的に利用できない状態を示します。リクエストがサーバーに到達しても、システムの過負荷、メンテナンス、インフラ障害などによってレスポンスを返すことができません。このエラーは一時的な場合が多いため、リトライ戦略を実装することが重要です。実際のエラーメッセージ例 Azure Portal の HTTP レスポンス： HTTP/1.1 503 Service Unavailable Content-Type: application/json Retry-After: 60 { "error": { "code": "ServiceUnavailable", "message": "The service is currently unavailable. Please try again later.", "target": "App Service" } } Azure CLI からのエラー出力： ERROR: (BadRequest) Service Unavailable: The service is temporarily unavailable. Please retry the request after some time. RequestId: abc123def456 よくある原因と解決手順原因1：Azureリージョンで障害が発生している Azure のデータセンター障害やメンテナンス作業により、特定のリージョン全体がサービス停止している場合があります。この場合、アプリケーション側での修正では解決できず、Azure のサービス復旧を待つか、別リージョンへの切り替えが必要です。 Before（エラーが起きるコード）： # 単一のリージョンにのみデプロイされている from azure.storage.blob import BlobServiceClient account_url = "https://mystorageaccount.blob.core.windows.net" blob_service_client = BlobServiceClient(account_url=account_url) try: container_client = blob_service_client.get_container_client("mycontainer") blobs = container_client.list_blobs() except Exception as e: print(f"Error: {e}") # リージョン障害時は対応策がない After（修正後）： ...

Docker Compose の 503 エラー：原因と解決策

エラーの概要 503エラーは「Service Unavailable」を意味し、Docker Composeでは依存するサービスが正常に起動できていない、または起動完了前にアクセスされている状況を示します。マイクロサービスアーキテクチャではよく発生するエラーで、特に複数コンテナーの起動順序やヘルスチェック設定に起因することが多いです。実際のエラーメッセージ例 Docker Composeで503エラーが発生した際のログ例を以下に示します。 { "status": 503, "message": "Service Unavailable", "error": "connect ECONNREFUSED 172.20.0.3:5432" } docker compose logs app-service 2024-01-15T10:23:45.123Z ERROR Failed to connect to database: ECONNREFUSED 2024-01-15T10:23:46.456Z WARN Service startup failed, retrying... 2024-01-15T10:23:50.789Z ERROR Max retries exceeded よくある原因と解決手順原因1：depends_onで依存関係を定義しているが、ヘルスチェック待機を設定していないマイクロサービス構成では、アプリケーションコンテナーがデータベースコンテナーの完全な起動完了を待つ必要があります。docker compose up実行時、デフォルトでは依存するコンテナーが「起動した」ことだけを確認して先に進むため、データベースが受け入れ準備完了する前にアクセスされます。 Before（エラーが起きるコード）： version: '3.8' services: postgres: image: postgres:15 environment: POSTGRES_PASSWORD: password ports: - "5432:5432" app: image: myapp:latest depends_on: - postgres ports: - "8080:8080" After（修正後）： version: '3.8' services: postgres: image: postgres:15 environment: POSTGRES_PASSWORD: password ports: - "5432:5432" healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 app: image: myapp:latest depends_on: postgres: condition: service_healthy ports: - "8080:8080" 上記の修正では、service_healthy条件によってPostgresのヘルスチェック成功を待ってからアプリケーション起動が開始されます。 ...

Kubernetes の 503 エラー：原因と解決策

エラーの概要 Kubernetes環境で503エラーが発生するのは、クライアントからのリクエストに対応できるPodが存在しない、または全てのPodが利用不可状態にあることを示しています。Service経由でアクセスした際、バックエンドのPodがすべてダウンしていたり、起動途中だったり、リソース不足で応答できない状態で表示されるHTTPステータスコードです。本エラーは一時的な問題である場合が多く、Podの自動復旧により解決することもありますが、根本原因の特定と対処が必要です。実際のエラーメッセージ例 HTTP/1.1 503 Service Unavailable Content-Type: text/html; charset=utf-8 Connection: close <html> <body><h1>503 Service Unavailable</h1> No servers are available to handle this request. </body></html> { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "no endpoints available for service", "code": 503 } よくある原因と解決手順原因1: Podがすべてダウン状態である DeploymentやStatefulSetで定義したPodが何らかの理由でクラッシュしており、バックエンドサーバーが完全に停止している状態です。CrashLoopBackOff状態やExit Code 1などの異常終了が続いている場合に発生します（Kubernetes の CrashLoopBackOff の記事）。 Before（エラーが起きるコード）： apiVersion: apps/v1 kind: Deployment metadata: name: web-app spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: app image: myapp:latest env: - name: DATABASE_URL value: "invalid-connection-string" After（修正後）： ...

Nginx の 503 エラー：原因と解決策

冒頭まとめ Nginx の 503 Service Unavailable の原因は、ほぼ次の3系統のいずれかです。第一に、limit_req（リクエスト頻度の制限）や limit_conn（同時接続数の制限）の超過で、Nginx 自身が既定で 503 を返します。第二に、メンテナンス用に設定した return 503 が設定内に残っているケースです。第三に、proxy_pass 先の上流アプリケーション自身が 503 を返し、Nginx がそれをそのまま中継しているケースです。注意すべき点として、「バックエンドに接続できない」ときに Nginx が返すのは 503 ではなく 502 Bad Gateway、応答待ちで時間切れになったときは 504 Gateway Timeout です。503 の調査だと思っていたものが実は 502 や 504 の問題だった、ということが起こりやすいので、まずアクセスログで実際のステータスコードを確かめ、次にエラーログの文言で原因を絞り込みます。エラーの概要 503 Service Unavailable は、サーバーが一時的にリクエストを処理できない状態を示します。Nginx をリバースプロキシとして使っている場合、似た状況で返るコードが3つあり、区別が重要です。上流への接続自体に失敗した場合（プロセス停止、ポート違い、接続拒否など）は 502、接続はできたが応答が時間内に返らなかった場合は 504、そして上流が「処理できない」と自ら 503 を応答した場合はその 503 がそのまま中継されます。加えて、上流と無関係に Nginx 自身が制限機能によって 503 を返す場合があります。 Nginx が自身の既定ページで 503 を返す場合、ブラウザには「503 Service Temporarily Unavailable」という見出しだけが表示されます。「The server is temporarily unable to service your request due to maintenance downtime or capacity problems.」のような説明文が表示されているなら、それは Nginx の既定ページの文言ではなく、上流の別のサーバーが生成した 503 を中継している可能性が高いです（原因3）。 ...

AWS の 503 エラー：原因と解決策

冒頭まとめ AWS で 503 Service Unavailable を受け取ったとき、最初に確定すべきなのは「どのコンポーネントが503を返したのか」です。代表的な発生源は3つあります。第一に、Application Load Balancer（ALB）です。公式ドキュメントのとおり、ALB が503を返すのはターゲットグループに登録済みターゲットが存在しない場合です。第二に、Classic Load Balancer で、こちらはロードバランサー自体の一時的な容量不足か、登録インスタンスが存在しない場合です。第三に、S3 などの AWS サービス自体が過負荷の保護として返す503で、S3 では 503 Slow Down という形をとります。注意すべき誤解が1つあります。「ヘルスチェックに失敗してターゲットが全部 unhealthy になると503になる」という説明を見かけますが、ELB の公式仕様では逆です。登録済みターゲットがすべて unhealthy の場合、ロードバランサーは状態にかかわらず全ターゲットへリクエストを振り分けます（fail open と呼ばれる動作）。つまり全滅時の症状は503ではなく、ターゲット自身が返すエラー（502や504など）として現れます。ALB の503は「unhealthy だから」ではなく「そもそも登録がないから」です。エラーの概要 503 は「一時的にサービスを提供できない」ことを示すコードですが、AWS の構成ではロードバランサー・マネージドサービス・自分のアプリケーションのどれもが503を返しうるため、コードの数字だけでは原因の場所が分かりません。ALB が自身で生成する503は、ブラウザでは「503 Service Temporarily Unavailable」と表示され、CloudWatch では HTTPCode_ELB_5XX_Count（内訳として HTTPCode_ELB_503_Count）に計上され、ALB のアクセスログでは elb_status_code が 503 になります。逆に、ターゲット（アプリケーション）が返した503は HTTPCode_Target_5XX_Count とアクセスログの target_status_code 側に記録されます。この記録の場所の違いが、発生源を確定する決め手です。まず最初に：どこが503を返したかを確定する 3つの確認で発生源を特定します。第一に、CloudWatch メトリクスです。HTTPCode_ELB_503_Count が増えていればロードバランサー自身が生成した503（原因1・2）、HTTPCode_Target_5XX_Count 側ならターゲットのアプリケーションが返した503です（この場合の調査対象はアプリケーション側です）。第二に、ALB のアクセスログです。elb_status_code = 503 で target_status_code が空（-）なら、リクエストはターゲットに届く前に ALB で503になっています。第三に、S3 など API 呼び出しでの503なら、エラーメッセージ自体に発生源が書かれています。S3 の場合は Status Code: 503 とともに Slow Down という文言が含まれます（原因3）。 ...

Docker の 503 エラー：原因と解決策

エラーの概要 DockerのHTTP 503エラーは、「Service Unavailable」を意味し、リクエスト対象のサーバーが一時的に利用不可能な状態にあることを示します。Docker環境では、Docker HubなどのレジストリサーバーやローカルのDockerデーモンが応答しない場合に頻発します。コンテナイメージの取得やプッシュ時に最も多く遭遇するエラーであり、その原因は多岐にわたります。実際のエラーメッセージ例 $ docker pull ubuntu:latest Error response from daemon: Get "https://registry-1.docker.io/v2/library/ubuntu/manifests/latest": net/http: request canceled $ docker push myregistry.azurecr.io/myapp:latest The push refers to repository [myregistry.azurecr.io/myapp] error: unexpected status code 503 Service Unavailable { "status": "Service Unavailable", "errors": [ { "code": "UNAVAILABLE", "message": "Service is temporarily unavailable. Please try again later." } ] } よくある原因と解決手順原因1: Docker Hubまたはレジストリサーバーの障害 Docker Hubやプライベートレジストリが障害状態にあるか、メンテナンス中の場合にエラーが発生します。この場合、クライアント側の設定に問題がなくても、サーバー側の復旧を待つ必要があります。まずは、対象レジストリの状態確認コマンドを実行してください。 Before（エラーが起きるコード）： # エラーが出たらすぐに再度pull/pushを試みている $ docker pull myimage:latest Error response from daemon: Get "https://registry-1.docker.io/...": 503 Service Unavailable $ docker pull myimage:latest # 再試行（失敗） After（修正後）： ...

GCP の 503 エラー：原因と解決策

冒頭まとめ GCP の 503 Service Unavailable は、まず「どの URL が返したか」で2系統に分けると迷いません。第一に、Google Cloud の各 API（googleapis.com への呼び出し）が返す503です。これは Google 公式のエラーコード定義（google/rpc/code.proto）で UNAVAILABLE に割り当てられたもので、定義の原文に「多くの場合は一時的な状態であり、バックオフつきの再試行で回復しうる。ただし非冪等な操作の再試行が常に安全とは限らない」と、性質と対処と注意点まで書かれています。第二に、自分がデプロイしたサービス（Cloud Run など）の URL が返す503です。こちらは Google 側の障害ではなく、コンテナの待ち受け設定やメモリなど、自分のワークロード側の調査になります。境界も公式定義で引けます。クォータや利用枠の超過は RESOURCE_EXHAUSTED で429、処理の時間切れは DEADLINE_EXCEEDED で504、Google 内部の深刻なエラーは INTERNAL で500に割り当てられており、これらが503として返ることはありません。「クォータ超過で503」という説明は Google のエラーモデルに合いません。エラーの概要 Google Cloud の API のエラーは、公式のエラーモデルに沿った JSON で返ります。503の場合、切り分けの決め手になるのは status フィールドです。 { "error": { "code": 503, "message": "The service is currently unavailable.", "status": "UNAVAILABLE" } } status が UNAVAILABLE なら、この記事の原因1（API 側の一時的な利用不能）です。message の文言はサービスにより異なりますが、status の値はエラーモデルで定義された名前がそのまま入ります。一方、Cloud Run にデプロイした自分のサービスの URL への503は、Google の公式トラブルシューティング文書で「HTTP 応答が不正だったか、インスタンスへの接続でエラーが起きた」場合と説明されており、応答本文は自分のアプリや基盤の状態次第です（原因2）。まず最初に：どの URL の503かで2つに分岐する失敗したリクエストの宛先を確認します。googleapis.com 系の API 呼び出し（Cloud Storage、BigQuery、各サービスの管理 API など）で、応答の status が UNAVAILABLE なら原因1です。自分のサービスの URL（run.app のドメインや独自ドメイン）への503なら原因2です。あわせて、応答に error.status がある場合は値を必ず読みます。RESOURCE_EXHAUSTED（429）や DEADLINE_EXCEEDED（504）が本来のコードとともに返っているなら、調査は503ではなくそれぞれの系統に切り替えます。 ...

GitHub API の 503 エラー：原因と解決策

エラーの概要 GitHub APIにおける503エラーは、GitHubのサービスが一時的に利用不可の状態にあることを示します。このエラーはGitHub側のメンテナンス、インフラストラクチャの過負荷、またはAPI呼び出しの集中に達した場合に発生します。503エラーが返される際には、通常Retry-Afterヘッダーが含まれており、どのくらい待つべきかの秒数目安が提示されます。実際のエラーメッセージ例 GitHub APIから返される実際の503レスポンスの例を以下に示します。 { "message": "Service Unavailable", "documentation_url": "https://docs.github.com/rest/overview/resources-in-the-rest-api" } cURLやPythonのrequestsライブラリを使用した場合のコンソール出力例： curl -H "Authorization: token <your-github-token>" \ https://api.github.com/user/repos # レスポンス HTTP/1.1 503 Service Unavailable Retry-After: 60 Content-Type: application/json {"message":"Service Unavailable"} よくある原因と解決手順原因1：GitHub側のメンテナンスまたはシステム障害 GitHubが定期メンテナンスやシステム障害の最中にAPI呼び出しを行うと503エラーが発生します。この場合、ユーザー側では対応できず、GitHub側の復旧を待つ必要があります。 Before（エラーが起きるコード）： import requests response = requests.get( 'https://api.github.com/user/repos', headers={'Authorization': f'token <your-github-token>'} ) print(response.json()) # 503エラーで処理が停止 After（修正後）： import requests import time def fetch_with_retry(url, token, max_retries=3): headers = {'Authorization': f'token {token}'} retry_count = 0 while retry_count < max_retries: response = requests.get(url, headers=headers) if response.status_code == 503: retry_after = int(response.headers.get('Retry-After', 60)) print(f"503エラー。{retry_after}秒後に再試行します") time.sleep(retry_after) retry_count += 1 elif response.status_code == 200: return response.json() else: raise Exception(f"エラー: {response.status_code}") raise Exception("最大再試行回数に達しました") result = fetch_with_retry('https://api.github.com/user/repos', '<your-github-token>') print(result) 原因2：APIレート制限への抵触 GitHub APIには時間ごとの呼び出し回数制限があります。認証ユーザーは1時間あたり5,000リクエスト、未認証ユーザーは60リクエストに制限されています。この制限に達すると429エラーが返されますが、その直後の集中アクセスによって503エラーが発生する可能性があります。 ...