curlのステータスコードとは？確認方法も！（取得方法：オプション：意味：レスポンスヘッダーなど）

curlのステータスコードとは？確認方法も！（取得方法：オプション：意味：レスポンスヘッダーなど）

curlはWebサイトやAPIへリクエストを送り、通信結果をコマンドライン上で確認できる代表的なツールです。

HTTPステータスコードを正しく読めるようになると、ページが表示されない原因、リダイレクトの有無、API連携の失敗箇所などを短時間で切り分けやすくなります。

本記事ではcurlでステータスコードを取得する基本操作から、主要なオプション、レスポンスヘッダーの見方、トラブル時の確認手順までを解説します。

curlのステータスコードの意味

それではまずcurlのステータスコードの意味について解説していきます。

HTTP通信における結果番号

ステータスコードとは、Webサーバーがリクエストを受け取ったあと、どのような結果を返したかを3桁の数字で表す情報です。

たとえば正常にページを返せた場合は200、別のURLへ移動させる場合は301や302、対象が存在しない場合は404が返されます。

curlはURLへアクセスしてサーバーの応答を確認するため、ブラウザを開かなくても通信状態を調べられます。

ステータスコードは画面の見た目ではなく、サーバーが返した通信結果を示す番号です。

ブラウザでは正常に見えるページでも、内部で複数回のリダイレクトやエラーが発生している場合があります。

SEO、Web制作、サーバー保守、API開発では、実際のHTTPレスポンスを確認する習慣が重要になります。

ステータスコードの大まかな分類

HTTPステータスコードは先頭の数字によって、通信結果の種類をおおまかに判別できます。

分類	主な意味	代表的なコード	確認時の考え方
100番台	処理の継続情報	100	通常のWeb確認では目にする機会は少なめです
200番台	成功	200、201、204	リクエストは原則として正常に完了しています
300番台	転送やキャッシュ	301、302、304、307、308	移転先や転送方法を確認します
400番台	利用者側の条件エラー	400、401、403、404、429	URL、認証、権限、送信内容を見直します
500番台	サーバー側の処理エラー	500、502、503、504	アプリケーションや上流サーバーを調査します

200番台であっても、期待した内容が返っているとは限りません。

APIでは200の代わりに204が返り本文が空であるケースもあり、作業目的に応じてヘッダーやレスポンス本文も確認する必要があります。

curlで確認する価値

curlを使う利点は、ブラウザのキャッシュ、拡張機能、JavaScriptによる表示差の影響を受けにくい点にあります。

単純なHTTPリクエストを送って結果を取得できるため、URLが正しいか、サーバーが応答しているか、リダイレクト先が意図どおりかを整理できます。

特にSEOのリダイレクト確認では、旧URLから新URLまでの応答の流れが重要です。

リンク先のURL変更、常時SSL化、wwwの有無の統一、ドメイン移転などでは、curlによる確認が役立ちます。

curlによるステータスコードの確認方法

続いてはcurlによるステータスコードの確認方法を確認していきます。

ヘッダーだけを取得する基本コマンド

最も手軽な方法は、curlに-Iオプションを付けてHTTPレスポンスヘッダーだけを表示する方法です。

実行結果の先頭にはHTTP/2 200のような行が表示されます。

この最後の3桁がステータスコードであり、URLへのアクセス結果をすぐに確認できます。

本文をダウンロードしないため、ページ内容まで不要な場合に向いています。

ただしサーバーによってはHEADリクエストへの対応が通常のGETリクエストと異なることもあります。

重要なページでは-Iの結果だけで終わらせず、GETリクエストでも同様に確認すると安心です。

ステータスコードのみを表示する方法

監視やスクリプト処理では、余計なヘッダーやHTMLを出力せず、ステータスコードだけを受け取りたい場面があります。

その場合は-wオプションと-oオプションを組み合わせます。

Windows環境ではNUL、macOSやLinuxでは/dev/nullを出力先に指定します。

-sは進行状況の表示を抑えるオプションであり、定期確認やバッチ処理の出力を見やすくしたいときに便利です。

結果が200なら成功、404ならURLまたは公開状態に問題がある可能性を考えます。

PowerShellではcurlが別名として扱われる環境もあるため、意図したcurlコマンドを実行したい場合はcurl.exeと明示する方法もあります。

GETリクエストでヘッダーを確認する方法

-Iオプションではなく、通常のGETリクエストを送りながらヘッダーを表示したい場合は-iオプションを使います。

この方法では、レスポンスヘッダーのあとにHTMLやJSONなどのレスポンス本文も続けて表示されます。

APIが返すエラーメッセージ、JSONの内容、文字コード指定なども同時に確認したいときに有効です。

ヘッダーだけなら-I、本文も含めて調査するなら-iという使い分けが基本になります。

取得量が大きいURLでは、本文の表示が多くなりすぎるため、必要に応じて出力をファイルに保存して確認するとよいでしょう。

curlオプションによる取得条件の指定

続いてはcurlオプションによる取得条件の指定を確認していきます。

リダイレクトを追跡する-Lオプション

301や302が返るURLでは、最初の応答だけを見ても最終的な到達先はわかりません。

-Lオプションを付けると、Locationヘッダーで指定された移転先をcurlが追跡します。

複数の応答行が表示された場合、途中に301や302があり、最後に表示されるステータスコードが最終URLの応答です。

旧ページが新ページへ移転しているかを確認する際には、途中の転送回数も見逃せません。

リダイレクトが何度も連続すると、表示速度、クロール効率、利用者の操作性に影響することがあります。

不要な転送を減らし、可能なら一度の301リダイレクトで正規URLへ到達させる構成が望まれます。

リクエストメソッドの指定

curlはGETだけでなく、POST、PUT、DELETEなどのHTTPメソッドを指定できます。

APIの動作確認では、同じURLでもメソッドによって返るステータスコードが変わります。

新しいデータの作成に成功した場合は201、入力内容に問題がある場合は400や422、認証情報が不足している場合は401が返ることがあります。

-Xオプションはメソッドを明示できる便利な指定ですが、通常のGET確認でむやみに付ける必要はありません。

サーバー側の仕様書やAPIドキュメントを確認し、必要なヘッダー、認証トークン、送信データを合わせて指定します。

ユーザーエージェントとタイムアウトの設定

WebサーバーやCDNの設定によっては、User-Agentの内容により異なる応答が返る場合があります。

検索エンジン向けの挙動を調べる際や、特定のクライアントを想定して検証する際は-Aオプションを利用します。

また、応答が遅いサイトでは–max-timeで通信全体の制限時間を設定できます。

接続できない状態でコマンドが長く待機し続けることを避けられるため、監視用途では特に有用です。

タイムアウトの発生は単なる失敗ではなく、サーバー負荷、DNS、ネットワーク、上流サービスの問題を示す手掛かりになります。

代表的なHTTPステータスコードの確認ポイント

続いては代表的なHTTPステータスコードの確認ポイントを確認していきます。

200番台の成功応答

200 OKは、リクエストが成功し、通常は要求したリソースが返されたことを示します。

Webページの公開確認ではもっともよく見るコードですが、意図したページが返っているかは本文やcanonical設定も含めて判断します。

201 Createdはデータ作成成功、204 No Contentは成功したものの返却本文がない状態を表します。

コード	意味	主な利用場面	確認ポイント
200	正常処理	通常のページ表示やAPI取得	正しい本文が返っているか確認します
201	作成成功	APIでの登録処理	作成されたリソースのURLも確認します
202	受付完了	非同期処理の開始	完了ではない場合があります
204	本文なしの成功	削除や更新処理	空の本文でも異常とは限りません

200という数字だけで安心せず、URL、本文、Content-Type、キャッシュ制御を目的に応じて確認しましょう。

300番台のリダイレクト応答

301 Moved Permanentlyは恒久的な移転、302 Foundは一時的な転送として扱われることが多いコードです。

307と308はHTTPメソッドを維持する性質があり、APIやフォーム送信を扱う場面で意味を理解しておく必要があります。

304 Not Modifiedは、ブラウザやキャッシュサーバーが保存済みのコンテンツを再利用できることを示す応答です。

HTTPSへの統一、末尾スラッシュの統一、URLの大文字小文字の統一などでは、転送ルールの重複によるループにも注意が必要です。

curl -I -Lで出力が繰り返される場合は、リダイレクト設定を見直す必要があります。

400番台と500番台のエラー応答

404 Not FoundはURLに対応するページが存在しない状態です。

削除済みページなら404が適切なこともありますが、移転済みの重要ページであれば301へ設定する判断が必要になるでしょう。

401 Unauthorizedは認証情報の不足、403 Forbiddenはアクセス権限の不足やアクセス制限を示します。

429 Too Many Requestsは短時間にリクエストを送りすぎた場合に返ることがあり、自動取得やAPI連携では待機処理を検討します。

500 Internal Server Error、502 Bad Gateway、503 Service Unavailable、504 Gateway Timeoutは、アプリケーションやサーバー間通信に関する問題の可能性があります。

500番台を確認したときは、URLだけでなく発生時刻、リクエスト内容、サーバーログ、CDNやロードバランサーの状態を合わせて調べることが大切です。

レスポンスヘッダーの見方

続いてはレスポンスヘッダーの見方を確認していきます。

LocationとContent-Typeの役割

Locationヘッダーは、301、302、307、308などのリダイレクト時に移転先URLを伝える項目です。

意図しないドメインやパラメーター付きURLへ転送されていないか、httpsへ正しく移動しているかを確認します。

Content-Typeは返却されるデータの種類を示し、HTMLならtext/html、JSONならapplication/jsonとして返されることが一般的です。

APIを呼び出したのにHTMLのエラー画面が返る場合、Content-Typeを見ると異常に気付きやすくなります。

ステータスコードとContent-Typeを組み合わせると、成功に見える誤応答を発見しやすくなります。

Cache-Controlとキャッシュの挙動

Cache-Controlは、ブラウザやCDNがコンテンツをどの程度保持するかを制御するヘッダーです。

max-ageの値、no-cache、no-store、public、privateなどの指定により、更新内容の反映速度や配信効率が変わります。

更新したページがすぐに変わらない場合、HTMLの問題ではなくキャッシュ設定が原因になっていることがあります。

一方で動的な会員情報や個人情報を含むページでは、不適切なキャッシュ設定が情報管理上の問題につながる可能性もあります。

Serverとセキュリティ関連ヘッダー

Serverヘッダーでは、応答を返したWebサーバーやプロキシの情報が表示されることがあります。

ただし詳細なバージョン情報の公開は不要な手掛かりになる場合もあるため、運用方針により情報を抑える構成も見られます。

Strict-Transport-SecurityはHTTPS接続を強制するためのヘッダーであり、常時SSL化の確認に役立ちます。

X-Content-Type-Options、Content-Security-Policy、X-Frame-Optionsなども、Webサイトのセキュリティ設定を確認する際の重要項目です。

curlでヘッダーを確認する作業は、表示確認だけでなくセキュリティ設定の初期診断にも活用できます。

curl確認時のトラブル対策

続いてはcurl確認時のトラブル対策を確認していきます。

SSL証明書エラーへの対応

HTTPSサイトへ接続したとき、証明書の期限切れ、ドメイン名の不一致、中間証明書の設定不足などによりエラーが出ることがあります。

-kオプションを使うと証明書検証を省略できますが、通常運用で安易に使う方法はおすすめできません。

まずは証明書の発行先、期限、対象ドメイン、サーバー設定を確認し、根本原因を解消することが優先です。

検証目的で-kを使った場合も、通信できたことと証明書が正常であることは別の結果として扱います。

接続エラーと名前解決エラー

curlで応答が得られない場合、HTTPステータスコードの問題ではなく、DNSやネットワークの段階で失敗している可能性があります。

Could not resolve hostのような表示ではドメインの名前解決、Connection refusedでは待受ポートやWebサーバーの起動状態、Timeoutでは経路や負荷を確認します。

–connect-timeoutを指定すると、接続開始までの待機時間を制限できます。

HTTPステータスコードが表示されない場合は、Webサーバー以前の接続段階で問題が起きている可能性があります。

認証が必要なURLの確認

管理画面や非公開APIでは、401や403が返ることがあります。

Basic認証なら-uオプション、Bearerトークンを使うAPIなら-HオプションでAuthorizationヘッダーを付与して確認します。

認証情報をコマンド履歴に残すと、端末の共有環境では情報漏えいにつながるおそれがあります。

環境変数、認証情報ファイル、秘密情報管理サービスなどを利用し、トークンやパスワードを直接記述しない運用が望まれます。

また、認証情報を付けたリクエスト結果を共有する際は、出力にCookieやトークンが含まれていないかを必ず確認しましょう。

curlのステータスコード確認のまとめ

curlのステータスコードは、WebページやAPIがサーバーからどのように応答されたかを把握するための基本情報です。

200番台は成功、300番台は転送、400番台はリクエストや権限に関する問題、500番台はサーバー側の問題として、まずは大きく分類すると理解しやすくなります。

-Iでヘッダーのみを確認し、-iで本文を含めて調査し、-Lでリダイレクト先まで追跡する流れを覚えておくと便利です。

特に重要なのは、コードを単独で見るのではなく、URL、Location、Content-Type、Cache-Control、本文を目的に応じて組み合わせて確認することです。

ページ公開後の点検、リダイレクト設定、API障害の切り分け、SSL設定の確認など、curlは幅広い場面で役立ちます。

日常的な確認コマンドとして活用し、通信の異常を早い段階で発見できるようにしておきましょう。