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

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

冒頭まとめ OpenAI API の 502 には、他のエラーと決定的に違う点があります。公式のエラー一覧に載っていないことです。400、401、403、429、500、503 は項目として説明がありますが、502 はありません。理由は応答を見れば分かります。502 のときに返るのは JSON ではなく、次のような HTML です。 <html> <head><title>502 Bad Gateway</title></head> <body> <center><h1>502 Bad Gateway</h1></center> <hr><center>cloudflare</center> </body> </html> 末尾に、前段で配信を担う事業者の名前が入っています。つまりこの応答を作ったのは API の層ではありません。要求は API に届く前に遮られています。この違いは対処に直結します。type も code も param も存在しないため、応答から原因を読み取る通常の手順が使えません。代わりに確認するのは、本文が JSON かどうか、そして何が起きたときに出るかです。さらに注意すべき点があります。502 は、その裏にある本当の失敗を覆い隠すことがあります。実際に、認証の失敗が 502 として現れた事例が報告されています。エラーの概要通常のエラーと並べると、構造の違いが際立ちます。 # 400 や 429 の場合（API の層が返す） {"error": {"message": "...", "type": "...", "param": null, "code": "..."}} # 502 の場合（前段が返す） <html><head><title>502 Bad Gateway</title></head> ... <center>cloudflare</center> ... プログラム側では、この違いが例外の形にも現れます。本文を JSON として解釈しようとして失敗する、あるいは中身の無いエラーとして扱われる、といった形です。公式のソフトウェア開発キットでは 500 番台としてまとめて扱われるため、500 と 502 が同じ区分に見えてしまう点にも注意が要ります。 ...

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

冒頭まとめ Azure で 502 Bad Gateway を受け取る場面は、Application Gateway を前段に置いた構成に集中します。表示される文言も定型で、要求を取り次いだ側が背後から正しい応答を得られなかった、という趣旨のものです。公式のトラブルシューティング文書は、このエラーの原因を明確に列挙しています。ネットワークの遮断規則・利用者定義の経路・独自の名前解決による遮断、既定の正常性確認が背後に届かないこと、独自の正常性確認の設定不備、背後の一覧が未設定または空であること、一覧の中に正常な相手が1つも無いこと、要求の時間切れや接続の問題、そして背後の証明書が一致しないことです。並べてみると、多くが1点に帰着します。背後が正常だと判定されていない、ということです。同じ文書には、一覧内のすべてが正常でないと判定された場合、要求は転送されず 502 が返る、と明記されています。したがって調査の起点は、設定ファイルではなく背後の正常性の状態です。もう1つ、時間に関する記述があります。要求を受け取った Application Gateway は、背後からの応答を一定時間待ちます。既定は20秒です。そして「v1 では、この時間内に応答が返らないと利用者は 502 を受け取る」と、版を明示したうえで書かれています。版を明示しているということは、別の版では同じ状況が同じ結果にならない可能性がある、ということです。自分の環境がどちらの版かを先に確認してください。エラーの概要利用者側には定型の文言が表示されます。応答が無効だった、という趣旨のものです。 Server Error: 502 - Web server received an invalid response while acting as a gateway or proxy server. 判断の材料は、この画面ではなく背後の正常性の状態です。公式文書には、一覧内のすべてが正常でないと判定された場合に 502 が返ることと、詳細を示す欄に表示される内容から調査を始めるべきことが書かれています。正常性の確認の既定の挙動も定義されています。確認の要求は <プロトコル>://127.0.0.1:<番号> の形で送られ、番号とプロトコルは設定から引き継がれます。そして、正常と見なされる応答は 200 から 399 までの状態コードだけです。この範囲外を返すパスを確認先にしていると、背後が正しく動いていても正常でないと判定されます。まず最初に：背後の正常性を見る第一に、背後の正常性の状態を確認します。すべてが正常でないと判定されていれば、原因はそこにあります。アプリケーションの中身を調べる前に、判定が通るようにしてください。第二に、詳細を示す欄の内容を読みます。公式文書には、接続を確立できない場合の文言として、確認に使う番号で背後が応答しているかを確かめること、そして遮断の設定が邪魔していないかを確かめることが挙げられています。第三に、正常と判定されているのに 502 が出る場合を分けて考えます。この場合、判定は通っているので、疑うのは実際の通信の側です。証明書の不一致や、名前の扱いの食い違いが候補になります。よくある原因と解決手順原因1：遮断の設定で、確認の通信が届いていない公式文書が最初に挙げている原因です。ネットワークの遮断規則、利用者定義の経路、独自の名前解決のいずれかが、Application Gateway から背後への到達を妨げていると、正常性の確認が失敗し、結果として 502 になります。同じ文書には、これらの設定が Application Gateway 側の区画にある場合と、背後の機器がある区画にある場合の両方がありうる、と書かれています。片方だけを見て安心しないでください。さらに、管理用の通信に必要な範囲も決まっています。公式の正常性に関する文書によれば、v1 では 65503 から 65534、v2 では 65200 から 65535 への受信を許可しておく必要があります。この範囲を塞ぐと、背後の設定が正しくても機能しません。 ...

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

冒頭まとめ GCP で 502 Bad Gateway を受け取ったとき、最初に押さえるべき事実が1つあります。Google が公開しているエラー区分の定義ファイルには、502 が存在しません。各区分には対応する HTTP の状態コードが併記されており、200・400・401・403・404・409・429・499・500・501・503・504 が並びますが、502 はどこにも出てきません。これは、各サービスの窓口が自分のエラーとして 502 を返す仕組みになっていない、ということです。つまり GCP で 502 を見たら、応答を作ったのは窓口そのものではなく、その手前にいる仕組みです。多くの場合は Cloud Load Balancing、あるいは経路上のプロキシです。504 が窓口自身からも返りうるのとは、この点で性質が違います。ロードバランサが返す 502 については、原因を絞り込む手段が用意されています。ログの statusDetails という項目です。公式のトラブルシューティング文書には、この値が response_sent_by_backend であればロードバランサは背後の応答をそのまま渡しただけで、それ以外の値であればロードバランサ自身が作った応答だ、と明記されています。値ごとの意味も一覧になっています。もう1つ、種類による違いがあります。同じ文書によれば、グローバルおよびリージョンの外部アプリケーションロードバランサは 503 や 504 といった意味のある状態コードを生成しますが、従来型のアプリケーションロードバランサは常に 502 を使います。従来型の環境では、待ち時間の超過も接続の失敗も、まとめて 502 として現れます。数字だけでは区別できません。エラーの概要利用者側に届くのは簡素な応答で、そこに手がかりはほとんどありません。判断の材料はログ側にあります。 { "httpRequest": { "status": 502 }, "jsonPayload": { "@type": "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry", "statusDetails": "failed_to_connect_to_backend" }, "resource": { "type": "http_load_balancer" } } 公式文書に説明がある値のうち、502 に結び付きやすいものは次の3つです。 failed_to_connect_to_backend は、ロードバランサが背後との接続を確立できなかったことを示します。文書では、背後で動いている処理が、バックエンドサービスに定義された番号で待ち受けていない可能性がある、と説明されています。 failed_to_pick_backend は、送り先を選べなかったことを示します。すべての背後が正常でない状態が考えられ、正常性の確認に必要な通信が許可されているかを確かめるよう案内されています。なお同じ文書には、グローバルの構成を変更した直後に、設定が行き渡るまでの短い間だけこの値とともに 502 が出ることがある、とも書かれています。 backend_connection_closed_before_data_sent_to_client は、応答が利用者へ渡される前に、背後が予期せず接続を閉じたことを示します。文書では、間に別の装置が挟まっていて、そちらの待ち時間のほうが短い場合に起きうる、と説明されています。まず最初に：statusDetails を読む第一に、ログから 502 の件を取り出し、statusDetails の値を確認します。ここが response_sent_by_backend であれば、502 を作ったのは背後のアプリケーションです。調べる先はそちらになり、ロードバランサの設定を触っても変わりません。 ...

GitLab の 502 エラー：原因と解決策

冒頭まとめ GitLab の 502 には、他のソフトウェアにはない手がかりがあります。専用の画面が用意されていて、応答に時間がかかりすぎている、という趣旨の文言が表示されます。この文言が出ているかどうかが、切り分けの起点になります。専用の画面が表示されているなら、応答を作ったのは GitLab に同梱されている前段のソフトウェアです。つまり、前段は動いています。動いていない相手は、その後ろにいる応用処理の側です。逆に、素っ気ない画面や別の形式の画面が出ているなら、応答を作ったのは GitLab の外側にいる中継役です。この場合、GitLab の設定をいくら見直しても変わりません。 GitLab の構成は多段です。前段が受け取り、補助の役が中継し、応用処理が実際の処理を行い、その先に格納の役が控えています。502 が起きるのは、このどこかで応答が返らなくなったときです。段が多いぶん、どこで止まったかを特定する作業が要ります。公式の窓口記事には、具体的な設定に起因する例が挙げられています。応用処理を単独で動かす設定にしていると、頻繁な再起動が起き、その際に 502 が表示される、というものです。この設定は資源の限られた環境向けのもので、外すと複数の処理単位で動くようになり、順に入れ替える方式が使えるため、停止する時間が短くなる、と説明されています。エラーの概要利用者側に表示されるのは、GitLab が用意した専用の画面です。時間がかかりすぎている、という趣旨の文言が入ります。前段の記録には、その先へ繋げなかったことが残ります。 upstream prematurely closed connection while reading response header from upstream connect() failed (111: Connection refused) while connecting to upstream, upstream: "http://unix:/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket:/" 転送先として、ファイルを経由した接続先が記録されているのが特徴です。この経路で繋がらないということは、応用処理が待ち受けていないか、応答を返す前に落ちているということです。各段の稼働状況は、まとめて確認できます。 run: gitaly: (pid 1580) 83s; run: log: (pid 1575) 83s run: nginx: (pid 1588) 83s; run: log: (pid 1584) 83s run: puma: (pid 12394) 0s; run: log: (pid 1574) 83s run: sidekiq: (pid 12015) 2s; run: log: (pid 1578) 83s ここで見るべきは、右側の経過時間です。他の段が同じくらいの値なのに、応用処理の段だけが数秒しか経っていない場合、その段が繰り返し起動し直していることを示します。この形は、後述する再起動の問題に直結します。 ...

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

冒頭まとめ Kubernetes で 502 Bad Gateway を見る場面は、利用者向けの通信を取り次ぐ Ingress の制御役に集中します。kubectl の操作で 502 が出ることは、通常ありません。API サーバーが時間切れで打ち切る場合は 504 になり、応答できる相手が居ない場合は 503 になるためです。したがって 502 を見たら、まずコンテナへの通信経路の話だと考えて構いません。 502 の意味は、取り次いだ側が転送先から正しい応答を得られなかった、ということです。ここで重要なのは、転送先そのものは選べているという点です。選べていなければ、そもそも転送する相手が居ないので別のエラーになります。多くの制御役は、対象の転送先が1つも無い場合に 503 を返します。したがって切り分けの第一歩は、502 と 503 のどちらが出ているかを見ることです。503 なら、転送先の一覧が空です。準備完了の判定が通っていないか、選択の条件が合っていないかのどちらかです。502 なら、一覧には相手が居るのに、その相手との通信が成立していません。 502 の原因は、制御役の土台になっているソフトウェアの作りから、3系統に整理できます。接続そのものを拒否された場合、応答の見出し部分が大きすぎて扱えなかった場合、そして応答を渡し終える前に切られた場合です。ログの文言でこの3つは区別できます。エラーの概要制御役のログには、要求ごとの記録と、失敗の理由が残ります。接続を拒否された場合の記録は次の形です。 connect() failed (111: Connection refused) while connecting to upstream, client: 10.1.0.5, server: example.com, request: "GET /api HTTP/1.1", upstream: "http://10.2.3.4:8080/api" 応答の見出し部分が大きすぎる場合は、別の文言になります。 upstream sent too big header while reading response header from upstream, client: 10.1.0.5, server: example.com, request: "GET /api HTTP/1.1" このとき記録に残る転送先の番号を確認してください。ここに出ている番号が、自分が意図したコンテナの番号と違っていれば、原因は設定の食い違いです。 ...

Terraform の 502 エラー：原因と解決策

冒頭まとめ 502 Bad Gateway は、要求を取り次いだ中継役が、その先から正常な応答を得られなかったことを示します。同じ 5xx でも、待ちきれずに諦めた場合は 504 です。応答が得られなかったのか、待ち時間が尽きたのかという違いで、疑うべき場所も変わります。 Terraform では、502 の扱いに1つ特徴があります。本体のソースを読むと、レジストリへの問い合わせの再試行回数を設定する処理の説明に、「502 のような再試行可能なエラーに対して行う再試行の回数」と書かれています。つまり Terraform は、502 を再試行で吸収すべきものとして名指しで想定しています。ところが、その既定値は1回です。合計2回で諦める設計になっており、失敗時の文言に「2回試した」と出るのはこのためです。想定しているにもかかわらず、既定では吸収できる幅が非常に狭い、という状態になっています。この回数は環境変数で増やせます。もう1つ、読み方の注意点があります。エラー文に現れる URL は、要求の宛先であって、502 を作った相手ではありません。社内のプロキシがその先へ繋げずに 502 を返している場合でも、文言にはレジストリの URL が並びます。「レジストリが落ちている」と判断する前に、応答を作ったのが誰かを確かめてください。エラーの概要 terraform init の段階では、再試行の回数を含む形になります。 Error: Failed to query available provider packages Could not retrieve the list of available versions for provider example/example: the request failed after 2 attempts, please try again later: 502 Bad Gateway returned from https://registry.terraform.io/v1/providers/... 「2回試した」という数字は、既定の再試行回数が1回であることに対応します。この数字が2以外になっていれば、環境変数で回数が変更されているということです。プロバイダのファイルを取得する段階でも起きます。この場合、宛先はレジストリではなく配布元です。 Error: Failed to install provider Error while installing example/example v1.2.3: unsuccessful request to https://releases.example.com/terraform-provider-example_1.2.3_linux_amd64.zip: 502 Bad Gateway terraform plan や terraform apply の途中で出る場合は、プロバイダがクラウドの窓口を叩いた結果です。この場合、どの資源の処理で起きたかが示されます。応答の本文が各社のエラー形式ではなく、簡素な HTML であれば、作ったのは窓口ではなく手前の中継役です。 ...

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

冒頭まとめ Nginx の 502 Bad Gateway は、リバースプロキシとしての Nginx が上流（proxy_pass や fastcgi_pass の接続先）への接続に失敗したか、接続はできたものの応答として解釈できないデータを受け取ったことを示します。原因はほぼ確実にエラーログの文言で特定できます。connect() failed (111: Connection refused) なら上流が起動していないか接続先の指定違い、unix ソケットへの (2: No such file or directory) や (13: Permission denied) ならソケットのパスか権限、no live upstreams なら全上流サーバーの一時除外、upstream prematurely closed connection なら上流の応答途中の切断、upstream sent too big header なら応答ヘッダーのバッファ超過、SSL_do_handshake() failed なら上流との TLS ハンドシェイク失敗です。 502と誤解されやすい隣のコードも押さえておくと迷いません。上流の応答待ちの時間切れは502ではなく504です（エラーログに upstream timed out と残ります）。limit_req などの制限超過は503、応答前にクライアント側が切断した場合はアクセスログに499が残ります。「遅いから502」という説明を見かけますが、Nginx のソースコード上、時間切れは504に明示的に割り当てられており、502になるのはそれ以外の接続失敗と不正応答です。エラーの概要 Nginx は上流への中継に失敗したとき、失敗の種類ごとに返すステータスコードを割り当てます。この割り当てはソースコード（ngx_http_upstream.c の ngx_http_upstream_next）で確認でき、時間切れ（NGX_HTTP_UPSTREAM_FT_TIMEOUT）は504、接続失敗・不正な応答ヘッダー・全サーバー除外などそれ以外の失敗は既定の分岐として502になります。つまり502は「時間内に、しかし正常には、上流とやり取りできなかった」ことの総称です。ブラウザに表示されるデフォルトのエラーページ： 502 Bad Gateway nginx アクセスログの出力例： 192.0.2.10 - - [15/Jul/2026:10:23:45 +0900] "GET /api/users HTTP/1.1" 502 157 "-" "Mozilla/5.0" エラーログ（/var/log/nginx/error.log）の出力例。この upstream: に続く接続先と、括弧内の失敗理由が切り分けの起点です： ...

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

エラーの概要 502 Bad Gateway は、API Gateway や Application Load Balancer（ALB）がバックエンド（EC2、Lambda、ECS など）から不正な応答を受け取った、あるいは応答を得られなかったことを示すエラーです。AWS 環境では、バックエンドサービスの一時的な障害やタイムアウト、リソース不足など複数の原因で発生しやすいステータスコードです。実際のエラーメッセージ例 API Gateway から返されるレスポンス例： { "message": "502 Bad Gateway" } CloudWatch Logs に記録されるロードバランサーのログ例： [ALB] 2024-01-15T10:23:45Z app/my-app/1234567890abcdef 192.0.2.1:54321 10.0.1.100:8080 0.050 0.100 0 502 - - arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-targets/1234567890abcdef "GET http://example.com/ HTTP/1.1" "Mozilla/5.0" - arn:aws:acm:ap-northeast-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 - ecs default - - よくある原因と解決手順原因1：バックエンドのタイムアウトまたはクラッシュ Lambda 関数や EC2 インスタンス上のアプリケーションが処理中にタイムアウトするか、予期せず停止している場合、ALB や API Gateway は 502 を返します。 Before（タイムアウト設定が不適切）： # Lambda 関数がタイムアウト時間内に完了できない import time def lambda_handler(event, context): time.sleep(35) # デフォルトのタイムアウト 30秒を超える return {"statusCode": 200} After（タイムアウトを延長し、処理を最適化）： ...

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

エラーの概要 502 Bad Gateway は、Docker コンテナ内で実行されるアプリケーションやリバースプロキシが、上流のサーバーから不正な応答を受け取ったときに発生します。Docker Compose や Kubernetes でマルチコンテナを運用する環境では、コンテナ間通信の失敗、プロキシ設定のミス、ネットワーク分断などが典型的な原因です。特に、Nginx や Apache をリバースプロキシとして使用している場合に頻出します。実際のエラーメッセージ例 Bad Gateway The proxy server received an invalid response from an upstream server. { "error": "bad_gateway", "message": "502 Server Error: Bad Gateway for url: http://upstream-service:8080/api", "timestamp": "2024-01-15T10:30:45Z" } $ curl -v http://localhost:80/api < HTTP/1.1 502 Bad Gateway < Server: nginx/1.21.0 < Content-Type: text/html よくある原因と解決手順原因1：上流コンテナが起動していない、またはヘルスチェックに失敗している上流アプリケーション（Node.js、Python、Java など）が起動に失敗していたり、クラッシュしていたりする場合、プロキシは接続できずに 502 を返します。 Before（エラーが起きている設定） version: '3.8' services: nginx: image: nginx:latest ports: - "80:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf depends_on: - app app: image: myapp:latest # ヘルスチェックがない、起動スクリプトが不安定 After（修正後） ...

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

冒頭まとめ GitHub API の 502 Bad Gateway は、リクエストの綴りや認証の問題ではなく、GitHub 側が時間内に応答を作れなかったことを示すコードです。原因は2系統に整理できます。第一に、GitHub 側の一時的な障害やインシデントです。この場合、手元でできることは稼働状況の確認と、時間をおいた再試行しかありません。第二に、リクエストの処理が重すぎて時間切れになるケースで、特に GraphQL API で複雑なクエリや大量のデータを一度に要求したときに頻発します。こちらは、取得件数を減らす・クエリを分割するという自衛策が有効です。逆に、トークンの不備は 401、レート制限の超過は 403 または 429、リソースの不存在や権限不足は 404 として返るのが GitHub の仕様であり、これらが502の原因になることはありません。502の調査は、稼働状況と「操作の重さ」の2点から始めます。エラーの概要 502 Bad Gateway は、GitHub の内部で応答の生成に失敗した、または間に合わなかったことを示します。GraphQL API の場合、実際の報告例に共通する特徴的な応答本文があります。 { "data": "null", "errors": [ { "message": "Something went wrong while executing your query. This may be the result of a timeout, or it could be a GitHub bug. Please include `XXXX:XXXX:XXXXXXX:XXXXXXX:XXXXXXXX` when reporting this issue." } ] } message 内のバッククォートで囲まれた文字列は、そのリクエストを特定するための参照 ID です。GitHub サポートやコミュニティへ報告する際に必要になるため、502が続く場合は控えておきます。文言にあるとおり、この応答は時間切れ（timeout）の可能性を GitHub 自身が示しています。なお、ブラウザの GitHub 上で同種の問題が起きた場合は「We couldn’t respond to your request in time.」という表示になり、これも「時間内に応答できなかった」という同じ状態を指します。 ...