今回やること
この記事では、ブラウザのDevToolsと curl を使い、HTTP通信を確認します。
ブラウザで見えるエラーとcurlで見える結果を比べると、ブラウザ側の問題か、サーバー側の問題かを切り分けやすくなります。
前提条件
- ChromeまたはEdgeのDevToolsを開ける
- ターミナルで
curlを実行できる - 学習用のURLとして
https://example.comを使う
Step 1: DevToolsのNetworkを開く
ブラウザで対象ページを開き、DevToolsを表示します。
Cmd/Ctrl + Shift + I
Networkパネルを開いてから、ページを再読み込みします。
確認すること:
- ステータスコード
- リクエストURL
- Request Headers
- Response Headers
- Preview / Response
- Timing
Step 2: ステータスコードを見る
Networkパネルで、HTMLやAPIリクエストのステータスコードを確認します。
| コード | 見方 |
|---|---|
200 | 成功 |
301 / 302 | リダイレクト |
401 | 認証が必要 |
403 | 権限がない |
404 | 対象が見つからない |
500 | サーバー側エラー |
ステータスコードは原因の入口です。本文やヘッダーも合わせて見ます。
Step 3: curlで同じURLを確認する
ターミナルでHTTPヘッダーだけ確認します。
curl -I https://example.com
詳細ログを見る場合は次を使います。
curl -v https://example.com
ブラウザでは失敗するがcurlでは成功する場合、Cookie、CORS、拡張機能、ブラウザキャッシュなどが関係している可能性があります。
Step 4: リダイレクトを追う
curl -I ではリダイレクト先まで自動で追わない場合があります。追跡するには -L を使います。
curl -I -L https://example.com
どこへ移動したかを見るには、Location ヘッダーを確認します。
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/
Step 5: APIのJSON応答を見る
APIの確認では Accept ヘッダーを付けることがあります。
curl -sS https://api.example.com/users \
-H "Accept: application/json"
認証が必要なAPIでは、トークンを直接コマンドに書くと履歴に残るため注意します。
Step 6: ブラウザ特有の問題を見る
ブラウザでだけ失敗する代表例はCORSです。
| 症状 | 見る場所 |
|---|---|
| CORSエラー | Console |
| Cookieが送られない | Network > Request Headers |
| キャッシュが効く | Network > Size / Status |
| プリフライトが失敗 | OPTIONSリクエスト |
CORSはブラウザの制限なので、curlで成功してもブラウザで失敗することがあります。
よくあるエラー
| エラー | よくある原因 | 確認すること |
|---|---|---|
404 | URLやパスが違う | Request URL |
401 | 認証情報がない | Cookie、Authorization |
403 | 権限や許可設定 | ロール、CORS、IP制限 |
| CORSエラー | オリジン未許可 | Console、レスポンスヘッダー |
| 証明書エラー | TLS証明書の問題 | ドメイン名、期限 |
学習用と本番用の違い
学習では curl -v で詳細に見ると理解しやすいです。本番では、認証情報やCookie、個人情報をログや画面共有に載せないように注意します。
まとめ
DevToolsのNetworkパネルではブラウザ目線のHTTP通信を確認できます。curlではブラウザ外から同じURLの応答を確認できます。両方を比べることで、サーバー側の問題か、ブラウザ特有の問題かを切り分けやすくなります。
