Incident Guide

TLSエラー・502 Bad Gatewayの切り分け手順

HTTPSが開かない、証明書を更新しても502が残るとき、入口と奥のサービスを分けて確認したい人

HTTPSの入口にはTLS検証、その奥にはHTTP応答とバックエンドの処理があります。証明書を直した後に502が見えても、修正を取り消す前にエラーが出ている層を見直しましょう。表示された症状から確認の順番を選び、配信中の証明書・プロキシ・内部ヘルスの証拠を揃えるガイドです。

実行前の注意と、教材との違い

この画面は症状に合う確認候補を表示するだけです。サーバーへ接続せず、原因の自動診断や設定変更もしません。例はLinux系シェル向けの表示用で、URL・証明書パスは仮のものです。実行する場合は管理権限と許可のある対象・安全な読取用ヘルスURLに置き換えてください。ログや設定にある秘密・Cookie・トークンを公開しないでください。模擬教材では固定時計・教材JSON・固定経路を使い、実機のPEM、暗号検証、DNS、DB、任意のnginx設定とは異なります。

いま見えている症状を選ぶ

観測した症状から、次の確認候補を表示します。原因の自動診断・サーバーへの接続・設定変更は行いません。

まだ症状は選ばれていません。実際に見えたエラーやHTTP応答に近いものを選んでください。

想定検索意図

TLSエラー 切り分け / 502 Bad Gateway 原因 / 証明書 更新後 502

向いている人

HTTPSが開かない、証明書を更新しても502が残るとき、入口と奥のサービスを分けて確認したい人

おすすめの進め方

症状を読む → 確認ポイントを押さえる → 関連シナリオで実際に手を動かす、の順で進めるのが最短です。

よくある症状

まずは自分の困り方がこのテーマに合っているかを確認します。

症状

certificate has expiredでHTTPSを開けない

症状

証明書のホスト名や信頼の検証で止まる

症状

TLSエラーが消えた後にHTTP 502が見える

症状

内部ヘルスは200なのに入口や利用者の操作は失敗する

最初に確認するポイント

•検証を省略しないHTTPSで、TLS失敗なのかHTTP応答なのかを分ける
•配置した証明書と実際に配信中の証明書を区別する
•入口と内部ヘルスの両方を、同じ変更後の時点で確認する

確認手順

最初の原因が見つかっても、他の障害が残っていないか確認します。設定の反映と復旧証拠までを一組にしてください。

  1. 1

    TLSエラー・502の切り分けは、最初の失敗が出る層から始める

    対象URL、発生時刻、表示されたエラー、直前の変更を記録します。TLS検証で失敗している間は、その接続のアプリ応答まで確認できたとは言えません。証明書の問題とHTTP 502を一つの原因へまとめず、入口と奥を分けて見ます。複数の利用者・接続先・経路がある場合は、同じ対象を比較しているかも確認します。

  2. 2

    期限・ホスト名・信頼を別々に確認する

    期限切れなら配信証明書の有効期間と確認端末の時刻、ホスト名不一致ならアクセス先と証明書の対象名、信頼エラーなら配信チェーンとクライアントの信頼ストアを調べます。どれも同じ証明書エラーですが、対処は同じとは限りません。手元の証明書ファイルを見ただけでは、ロードバランサーやCDNも含めた実配信先の状態は証明できません。

  3. 3

    保存・反映・新しい接続での確認を分ける

    更新済みファイルの配置や設定保存は、稼働中のサービスへの反映と別です。実運用では構成に合う設定検査、承認された変更手順、反映後のログを確認します。nginxは設定の再読み込みに失敗すると以前の設定で動作を続けるため、コマンドを送ったことだけで成功としません。コンテナ、マネージド環境、systemdでは操作方法が異なり、教材のreloadをそのまま実機へ適用しないでください。

  4. 4

    502が見えたら、プロキシのログと実際の上流経路を見る

    502はゲートウェイやプロキシが上流から有効な応答を得られなかったことを表しますが、バックエンド停止だけが原因ではありません。同じ時刻のエラーログ、設定された宛先、接続拒否、名前解決、上流のTLSや応答形式を調べます。確認はそのプロキシと同じネットワークから、設定上の宛先・ポート・経路に対して行います。内部ポートをインターネットへ公開して確認する必要はありません。

  5. 5

    復旧はTLS検証・HTTP応答・利用者の操作で確認する

    許可された内部ヘルスと入口HTTPSを、修正を反映した後に確認し直します。curlは通常、HTTP 502でも通信が成立すれば終了コード0になり得るため、終了コードとHTTPステータスを混同しません。200でもログイン画面や別の経路を見ている可能性があり、期待する本文と安全な利用者操作まで照合します。修正対象と無関係な正常応答を復旧証拠にしないことが大切です。

よくある質問

TLSエラー・502の切り分けで最初に何を見ますか?

TLS検証で接続が止まるのか、HTTP 502を受け取っているのかを分けます。時刻・対象URL・直前の変更を記録し、配信証明書と同じ時刻のプロキシログを照合してください。この画面の症状選択は確認候補の案内であり、原因の自動診断ではありません。

証明書を更新して502になったら、更新を戻すべきですか?

それだけでは判断できません。TLSエラーの奥にあったHTTP障害が見え始めた可能性もあります。期限・名前・信頼を検証した上で、上流経路とログを確認します。設定を戻す判断は影響範囲と承認手順を確認して行ってください。

curl -kで200なら復旧ですか?

いいえ。-kや--insecureは証明書検証を省略するため、正しいHTTPSを確認したことにはなりません。正規の信頼設定・ホスト名で検証を省略せず確認します。通常のcurlの終了コード0とHTTP 200も別です。

教材のコマンドを本番でそのまま実行できますか?

そのまま使わないでください。教材は固定時計・JSON証明書・固定経路の状態モデルです。実機のOpenSSL/nginx、サービス管理、ネットワーク、権限は構成ごとに異なります。画面の例は自動実行されず、実運用では許可された対象と確認手順が必要です。

根拠となる公式資料

確認日:2026年10月13日。実機のバージョン・構成による違いは、利用環境の公式資料で確認してください。

このテーマで身につけたいこと

TLS検証とHTTP応答を混同しない
一部修正で隠れた障害が見えることがある
設定保存だけで反映済みとしない
502だけから原因を断定しない

このテーマに合うシナリオ

読んで終わらせず、そのまま手を動かせるシナリオに絞っています。