症状
curl では通るのにブラウザでは失敗する
フロントエンド担当、フルスタック開発者、問い合わせ一次対応をする人向け
サーバーは動いているのにブラウザだけ通信できないとき、ネットワークタブとレスポンスヘッダをどう見るかを練習する入口です。
想定検索意図
CORS エラー 切り分け preflight ブラウザだけ失敗
向いている人
フロントエンド担当、フルスタック開発者、問い合わせ一次対応をする人向け
おすすめの進め方
症状を読む → 確認ポイントを押さえる → 関連シナリオで実際に手を動かす、の順で進めるのが最短です。
まずは自分の困り方がこのテーマに合っているかを確認します。
curl では通るのにブラウザでは失敗する
preflight request が弾かれている
Access-Control-Allow-Origin などのヘッダ不足が疑われる
上から順に見ていくと切り分けが進みます。 途中で原因が分かればそこで止めて構いません。
curl が通ってブラウザだけ失敗するなら、 サーバーは正常に応答していて ブラウザが結果を渡さずに遮断している。 これが CORS の切り分けの起点。 逆に curl も失敗するなら CORS ではなく、 サーバー側の問題を先に見る。
本命のリクエストの前に OPTIONS が飛んでいれば preflight が発生している。 単純リクエストの条件から外れると preflight が起きる — 独自ヘッダを付けた、 PUT や DELETE を使った、 Content-Type を application/json にした、 などが典型。 OPTIONS が無いのに失敗しているなら、 preflight ではなくレスポンス側のヘッダを疑う。
Access-Control-Allow-Origin にこちらのオリジンが入っているか、 Access-Control-Allow-Methods に使いたいメソッドが入っているか、 Access-Control-Allow-Headers に送ろうとしている独自ヘッダが入っているか。 どれか 1 つでも欠けると本命のリクエストは送られない。
資格情報つき (credentials を含める設定) の場合、 Access-Control-Allow-Origin にワイルドカードは使えず、 具体的なオリジンを返す必要がある。 加えて Access-Control-Allow-Credentials: true も要る。 ワイルドカードで動いていたものが Cookie を付けた途端に失敗するのはこれ。
遮断しているのはブラウザなので、 サーバー側のログには 200 が記録されていることが多い。 「サーバーは正常」 という報告と 「動かない」 という報告が両立するのはこのため。 判断材料はブラウザのネットワークタブにある。
読んで終わらせず、そのまま手を動かせるシナリオに絞っています。