先に結論
最初に『どこからでも止まっているか』を確認し、DNS→TLS→HTTP→アプリケーションの順で一層ずつ切り分けます。
最初の5分で確認すること
- エラー画面、URL、発生時刻を保存する。
- Wi-Fiとモバイル回線、または外部監視から同じURLを確認する。
- 直前30分のDNS変更、証明書更新、デプロイ、設定変更を列挙する。
- ステータスページ、CDN、ホスティング事業者の障害情報を確認する。
- DNS解決、TLS接続、HTTP応答のどこで止まるかを一つずつ確認する。
結論：「サイトが開かない」は原因ではありません。名前が引けない、暗号化接続できない、HTTPが返らない、アプリが失敗する、のどこかを確定します。
症状と確認する層
| 見えている症状 | 優先する層 | 次の確認 |
|---|---|---|
| DNS_PROBE_FINISHED / NXDOMAIN | DNS | 権威DNSと委任を確認 |
| 証明書警告・接続はプライベートではない | TLS | 期限・ホスト名・チェーンを確認 |
| 接続タイムアウト | 経路・FW・サーバー | 複数地点、CDN、負荷、ポートを確認 |
| 502 / 504 | プロキシ・上流 | ロードバランサーとオリジンのログを突合 |
| 503 | 容量・保守・依存先 | CPU/メモリ/接続数、保守設定を確認 |
| 200だが真っ白 | フロント・アプリ | ブラウザコンソールと直前デプロイを確認 |
避ける操作
- ログを保存せず、全サーバーを同時に再起動する。
- DNS、証明書、CDN、アプリ設定を同時に変更する。
- 障害中にバックアップ確認なしでデータベース移行や巻き戻しを行う。
- 証明書警告を無視して管理画面や決済画面へログインする。
停止：認証情報流出、改ざん、未知の管理者、外部への不審通信がある場合は通常障害ではなくセキュリティ事故として扱い、証拠を保全します。
相談前にそろえる情報
- 対象URLと影響範囲、最初に確認した時刻
- エラー全文、HTTPステータス、DNS/TLS確認結果
- 直前の変更、デプロイ識別子、担当者
- CDN・LB・オリジン・アプリログの同時刻部分
- 復旧優先度と、許容できる切り戻し範囲
公式情報
よくある質問
再起動を最初にしてよいですか？
原因の記録が消えるため、監視・アクセスログ・直前の変更を保存してからにします。冗長構成なら正常系を残し、障害系だけを切り離します。
自分の端末だけ開けない場合もサーバー障害ですか？
別回線や外部監視で正常なら、端末のDNSキャッシュ、VPN、プロキシ、セキュリティ製品を優先して確認します。
502と503は同じですか？
どちらも利用者側で直すエラーではありません。502は上流から有効な応答を受け取れない、503は一時的に処理できない状態を示すのが一般的で、ログと構成の確認が必要です。