HTTPie（コマンド名は http と https）は、HTTP の要求と応答を読みやすく表示してくれるコマンドラインツールで、サイトの接続確認や WordPress の REST API の動作確認に向いています。この記事では、インストールから、応答ヘッダーの確認、リダイレクトの追跡、TLS 証明書まわりの確認、認証付きの REST API 呼び出し、スクリプトで使うための終了コードまで、接続確認でよく使うコマンドを目的別にまとめます。
オプションの有無や既定値はバージョンによって異なることがあります。以下は HTTPie 3 系を前提にしています（2026年10月現在）。手元の環境では http --help と http --version で確認してください。
インストールと基本の形
代表的なインストール方法は次のとおりです。
# Python の pip（ユーザー環境に入れる例）
python3 -m pip install --user --upgrade httpie
# macOS（Homebrew）
brew install httpie
# Debian / Ubuntu
sudo apt install httpieディストリビューションのパッケージは版が古いことがあります。新しいオプションが使えないときは、バージョンを確認してください。
基本の形は http [メソッド] URL [要素...] です。メソッドを省略すると、データがなければ GET、データがあれば POST になります。要素は書き方で意味が変わります。
Header:value… リクエストヘッダーname==value… クエリ文字列name=value… JSON の文字列フィールド（既定は JSON 送信）name:=123… JSON の生の値（数値・真偽値・配列など）
https example.com のように https コマンドを使うと、スキームを省略できます。
応答ヘッダーだけを確認する
接続確認でいちばん使うのは、ステータスとヘッダーの確認です。
http --headers https://example.com/--headers（短縮形 -h）は応答ヘッダーだけを表示します。キャッシュの状態（cache-control、CDN が付けるキャッシュ状態のヘッダー）、server、content-type、セキュリティ関連ヘッダー（strict-transport-security など）をここで確認できます。
送ったリクエストも含めて見たい場合は --verbose（-v）を使います。
http -v https://example.com/表示内容を細かく選ぶなら --print（-p）です。H がリクエストヘッダー、B がリクエスト本文、h が応答ヘッダー、b が応答本文を表します。
# リクエストヘッダーと応答ヘッダーだけ
http --print=Hh https://example.com/実際に送らずに、組み立てたリクエストだけを確認したいときは --offline が便利です。認証ヘッダーや JSON の形を送信前に確かめられます。
リダイレクトを追いかける
HTTP から HTTPS への転送、www の有無の統一、末尾スラッシュの付与など、リダイレクトの確認には --follow と --all を組み合わせます。
http --follow --all --headers http://example.com/--follow（-F）でリダイレクトを追い、--all で途中の応答もすべて表示します。location ヘッダーの流れを見れば、転送が何段あるか、ループしていないかが分かります。段数が多すぎる場合は --max-redirects=5 のように上限を指定すると、ループで止まらなくなるのを防げます。
WordPress では、「設定」→「一般」の WordPress アドレスとサイトアドレス、サーバー側の転送設定、CDN の設定の三か所でリダイレクトが起きることがあります。二重に転送されている場合は、どの段の location がどこを向いているかで発生元を推測できます。
応答時間とタイムアウト
応答が遅い・返ってこない場合は、タイムアウトを指定して待ち時間の上限を決めます。
http --timeout=10 https://example.com/経過時間を表示したい場合、比較的新しい版では応答のメタデータ（--meta、または --print=m）で確認できます。古い版にはないオプションなので、使えない場合は time http ... のようにシェルの機能で計測するか、詳細な内訳が必要なら curl の -w オプションを使ってください。
TLS と証明書まわりの確認
HTTPS の接続確認で使うオプションです。
# 指定した CA 証明書で検証する（社内 CA などの確認）
http --verify=/path/to/ca-bundle.pem https://internal.example.com/
# TLS のバージョンを指定して接続できるか試す
http --ssl=tls1.2 https://example.com/
# クライアント証明書が必要なサーバー（mTLS）
http --cert=client.crt --cert-key=client.key https://api.example.com/--verify=no で証明書の検証を止めることもできますが、これは「検証を止めたら通るか」を切り分けるための一時的な使い方にとどめてください。検証なしで通るなら、原因は証明書チェーンや名前の不一致など証明書側にあります。
HTTPie は証明書の有効期限やチェーンの詳細を表示する機能を持っていません。証明書そのものを調べるときは openssl s_client を使います。また、DNS を変えずに特定の IP アドレスのサーバーへ HTTPS で接続したい場合（移転前の新サーバー確認など）、HTTPie には curl の --resolve に相当するオプションがないため、hosts ファイルを一時的に書き換えるか、curl を使うのが現実的です。
WordPress の REST API を確認する
REST API が動いているかは、ルートにアクセスすると分かります。
http https://example.com/wp-json/
http https://example.com/wp-json/wp/v2/posts per_page==1JSON が整形されて返ってくれば、REST API は応答しています。HTML のエラーページやログイン画面が返ってくる場合は、セキュリティプラグインや WAF、パーマリンク設定が原因のことが多いです。
認証が必要なエンドポイントは、WordPress のアプリケーションパスワード（WordPress 5.6 以降のコア機能、HTTPS が前提）で確認できます。ユーザー名だけを渡すと、パスワードは対話的に入力を求められるので、シェルの履歴に残りません。
http -a your-username https://example.com/wp-json/wp/v2/users/meコマンドラインに -a user:password の形でパスワードを直接書くと、シェルの履歴やプロセス一覧に残ることがあります。スクリプトで使う場合も、パスワードはファイルに直書きせず、権限を絞った設定ファイルや環境の秘密情報管理の仕組みから読み込んでください。確認が終わったら、不要になったアプリケーションパスワードはユーザープロフィール画面から失効させます。
同じ認証情報やヘッダーを何度も使う場合は --session で保存できますが、セッションファイルには認証情報が保存される点に注意してください。
スクリプトで使う：終了コード
監視スクリプトや CI で使う場合は、--check-status を付けると、HTTP のステータスに応じた終了コードで終わります。
http --check-status --quiet --timeout=10 https://example.com/ || echo "NG: $?"終了コードの対応（--check-status 使用時）は、公式ドキュメントでは次のように説明されています。
- 0 … 成功
- 1 … 一般的なエラー
- 2 … タイムアウト
- 3 … 想定外の 3xx（
--followを付けていない場合） - 4 … 4xx
- 5 … 5xx
- 6 … リダイレクト上限の超過
--quiet（-q）で表示を抑えると、終了コードだけで判定できます。
まとめ
- HTTPie は
http/httpsコマンドで、ヘッダー・本文を読みやすく表示します。要素の書き方（:、==、=、:=）で意味が変わります - ステータスとヘッダーの確認は
--headers、リクエストも見るなら-v、送信前の確認は--offlineが便利です - リダイレクトは
--follow --all --headersで全段のlocationを確認します - TLS は
--verify・--ssl・--certで確認できますが、証明書の中身や特定 IP への接続は openssl や curl を併用します - REST API の認証はアプリケーションパスワードを使い、パスワードはコマンドラインに直書きせず対話入力にします
- スクリプトでは
--check-statusの終了コードで判定します