500と502エラーの違い｜サイト運営者が最初に残す調査メモ

白い画面やサーバーエラーが出たとき、何を確認して担当者へ伝えるか。エラー番号だけで原因を決めず、URL・時刻・変更内容から絞り込みます。

最初は、エラー番号と発生範囲を記録する

500や502が出たときに、記事本文やDNSを思いつきで変更すると、元の原因を調べにくくなります。まず画面に出た文字列、完全なURL、時刻を保存します。トップだけか、特定の記事だけか、管理画面も開かないかを分けて確認してください。

MDNによると500は、サーバーが予期しない状況に遭遇して処理できなかったことを示す一般的なエラーです。502は、ゲートウェイやプロキシーが上流のサーバーから不正な応答を受け取ったことを示します。どちらも番号だけで、具体的な故障箇所までは確定できません。

例えば「公開直後から全ページが500」なら、直前の公開内容と実行環境の設定を照合する材料になります。「一覧は開くが記事だけ500」なら、そのページで使うデータや処理へ確認対象を絞れます。これらは調査の仮説であり、原因が確定したという意味ではありません。

同じ送信を何度も繰り返す前に、受付が保存されていないか確認します。フォームなどでは、画面の応答に失敗していても、処理の一部が完了している場合があります。注文や決済のあるサービスでは、特に担当者の案内に従ってください。

項目	記入例の形式
発生したURL	https://example.com/articles/guide
時刻	年月日・時分・タイムゾーン
エラー	500、502、表示された文章
範囲	全ページ／特定ページ／特定操作
直前の変更	公開した版・設定・更新内容
再現性	毎回／時々／現在は回復

ログを共有する場合は、認証キーやフォームに入力された個人情報を取り除きます。サポートへの説明に、すべてのログをそのまま公開する必要はありません。

直前の版へ戻すことが有効かは、変更内容によります。データベースの構造まで変更した場合、プログラムだけ戻して整合性が取れなくなることもあります。公開記録と変更範囲を確認し、担当者が戻し方を判断できるようにしてください。

トップページが開いたら終わりにせず、問題が出た記事やフォームを同じ手順で確認します。発生時刻、原因、復旧操作、再発防止策を短く残せば、次回の対応が速くなります。原因が分からないまま回復した場合は、その事実も記録してください。

SITE PORTを検討する際には、公開後にエラーが起きたときの窓口と、運営者が確認できる情報を聞いておきましょう。制作時の使いやすさに加えて、困ったときに何を伝えればよいかが分かることも、運用面の判断材料です。

SITE PORTの完成例を見る・編集のデモを見る。自分で更新する場面を想像しながら、利用できる機能とサポート範囲を申込前に確認してください。

[DNSエラーの確認](/articles/dns-nxdomain-first-check)・[フォームの受付確認](/articles/contact-form-delivery-test)