ASP.NET Core を IIS の裏で動かしていると、502.3 や 503 が突然出ることがある。アプリ例外というより「ゲートウェイ／プロセス側」の失敗であることが多い。
先に結論
- 502 … IIS（ANCM）が Kestrel と話せない／応答待ちで切れた
- 503 … アプリプール停止・起動失敗・過負荷で受け付けられない
- まず Event Viewer・stdout ログ・アプリプール状態を見る
- コードの NullReference だけ見ていても終わらないことが多い
502 のよくある型
- 起動失敗（依存欠落・設定ミス・ポート衝突）で Kestrel が上がらない
- 起動はするが最初の要求で落ちる（DI 未登録など）
- ANCM の requestTimeout 超過（遅い処理・デッドロック待ち）
- web.config の processPath / arguments ミス
503 のよくある型
- アプリプールが Stopped / 連続失敗で無効化
- 同時接続・キュー溢れ
- デプロイ中のリサイクルと要求がぶつかる
切り分け手順
- IIS マネージャでサイト／プールの状態を確認
- stdoutLogEnabled で起動ログを取る（失敗理由がそのまま出ることが多い）
- Windows イベントログ（Application）の .NET Runtime / IIS AspNetCore Module を見る
- 同じマシンで
dotnet アプリ.dll を直接起動して単体確認
- 遅いならタイムアウト設定と DB／外部依存の詰まりを疑う
対策の型
- 起動時検証（設定・DI）を有効にして「落ちるなら起動で落とす」
- ヘルスチェック／ウォームアップでリサイクル直後の 502 を減らす
- 長い処理は非同期化・タイムアウト見直し（闇雲な延長は最後）
- デプロイはアトミック（ロック付きコピーやスロット入れ替え）
関連: EF Core DbUpdateException（DB 起因で応答が返らずゲートウェイが切れるケース）
ざっくりまとめ
- 502＝前段とアプリの会話失敗、503＝受け付けられない状態
- stdout とイベントログが最短ルート
- アプリ例外ログだけでは足りないことが多い
関連記事