CORS preflight失敗時の診断手順
preflight失敗は、実リクエスト前にブロックされるため、まずOPTIONS応答の成立可否を最優先で確認します。
典型的な症状
- コンソールに「preflight did not succeed」が出る
- 実リクエストがサーバーに到達しない
- curlでは成功するがブラウザだけ失敗する
診断ステップ
- 1) CORS Error Troubleshooting でエラー文から失敗種別を特定
- 2) CORS Diagnostic で request/response の整合を確認
- 3) CORS Response Inspect で ACAO / ACAM / ACAH / ACAC を確認
- 4) Origin Allowlist Check で許可条件を再確認
- 5) Host/Authority/Origin Inspect でヘッダー起点の不一致を確認
OPTIONSで最低限成立させる条件
- OPTIONS に対して 2xx を返す
- Access-Control-Allow-Origin を要求Originに一致させる
- Access-Control-Allow-Methods に要求メソッドを含める
- Access-Control-Allow-Headers に要求ヘッダーを含める
- 動的Origin反映なら Vary: Origin を付与する
よくある原因
- API gatewayでOPTIONSが認可されていない
- Allow-Headersが実リクエストと一致していない
- ACAO=* と credentials=true を併用している
- 開発環境Originが本番allowlistに未登録
修正後の再確認
- 同一シナリオでpreflightが2xxになるか
- 実リクエストが到達し、期待レスポンスを返すか
- 主要ブラウザで再現が消えるか
使うツール
- CORS Error Troubleshooting
- CORS Diagnostic
- CORS Response Inspect
- Origin Allowlist Check
- Host/Authority/Origin Inspect
- CORS Checklist
FAQ
- curl で通るのにブラウザで失敗するのはなぜですか？
- ブラウザでは preflight と CORS 制約が適用されるためです。OPTIONS 応答と Allow-* の整合を確認してください。
- Access-Control-Allow-Origin に * を使えば解決しますか？
- credentials=true を使う場合は不可です。認証付き通信では明示的な Origin を返してください。
参照仕様
次に見る（診断順）
site_map ルールに基づいて、次に確認すべきページを表示しています。
- CORS Error Troubleshooting — CORSエラー文とヘッダーを突き合わせて失敗ポイントを症状別に切り分け
- CORS Diagnostic — Origin と Allow-* を照合してCORS判定を診断
- CORS Response Inspect — Access-Control-Allow-* を解析してCORS応答を点検
- Origin Allowlist Check — Origin と許可リストの一致を判定
- CORS Checklist — CORS設定の確認項目を手順化
- Host/Authority/Origin Inspect — Host/:authority/Origin/Referer を照合して不整合を確認
- 症状別診断ガイド（入口） — キャッシュ/CORS/JWT/MIME系の実運用トラブルを、症状起点で最短導線に振り分ける総合ハブ
- 304が返らない時の診断手順 — ETag / Last-Modified と If-* の往復を確認して 304 不発を切り分ける
同テーマの導線
事例クラスタ一覧
実運用トラブル別に、最短の診断ルートへ入るためのシナリオ集
- 症状別診断ガイド（入口） — キャッシュ/CORS/JWT/MIME系の実運用トラブルを、症状起点で最短導線に振り分ける総合ハブ
- 304が返らない時の診断手順 — ETag / Last-Modified と If-* の往復を確認して 304 不発を切り分ける
- 更新したのに反映されない時の診断手順 — HTML/API/静的アセット別にキャッシュ方針を確認し、反映遅延を短時間で切り分ける
- JWT 401/403 切り分け手順 — Authorization / WWW-Authenticate / claims / 署名検証を連携して 401 と 403 を分離する
- 429/503で再試行が止まらない時の診断手順 — Retry-After の秒/日時解釈とクライアント実装差を切り分け、過剰再試行を抑える
- nosniffでJS/CSSがブロックされる時の診断手順 — Content-Type と nosniff の不一致、404/302混入、配信経路の上書きを切り分ける
- Set-Cookie が保存されない時の診断手順 — Domain/Path/Secure/SameSite を順に確認して Cookie 非保持の原因を切り分ける
- OAuth戻りでログインが維持されない時の診断手順 — IdP戻りで起きる Cookie 不達を SameSite・Secure・Path/Domain・競合で順に切り分ける
- 同名Cookie競合で不安定な時の診断手順 — 同名CookieのPath/Domain差分・上書き順・送信衝突を整理して不安定挙動を解消する
- Cookie障害の運用チェックリスト — 保存失敗・OAuth戻り失敗・同名競合を一本化し、トリアージから恒久対策まで運用手順を標準化する