当社の立場：私たちはGeonodeというプロキシ販売会社であり、この記事の前半では、Postmanで当社のような製品を使用する方法について解説します。 率直に言えば、Postmanはプロキシを多用する作業には不向きなツールです — リクエストごとにではなく、グローバルにプロキシ設定が適用されるため、あるリクエストをプロキシ経由で送信し、別のリクエストを直接送信するような使い分けを簡単に行うことができません。 プロキシが機能するかどうかをテストしたり、プロキシ経由でAPIを調査したりするには最適ですが、リクエストごとに異なるルーティングが必要な作業には不向きなツールです。設定の確認にはPostmanを使用し、実際の作業はリクエストごとの制御が可能なクライアントに移行してください。
どの機能が必要ですか？
まずこれを決めておけば、あとは簡単です。
**Postmanにプロキシ経由でリクエストを送信させたい場合。**理由：社内ネットワークから外部へ接続する唯一の経路が企業プロキシである場合、または地理的位置情報やアクセス権限を確認するためにプロキシ経由でAPIをテストする場合などです。これはグローバルプロキシ設定であり、後ほど説明します。
別のアプリケーションからのリクエストをキャプチャしたい場合。 理由：モバイルアプリやブラウザが実際に送信している内容を確認したい場合や、サードパーティ製統合機能のデバッグを行う場合などです。これはPostmanの組み込みプロキシであり、後ほど説明します。Postmanが仲介役となり、他のソフトウェアがPostmanを参照する形になります。
これらは設定場所が異なり、解決する問題も別物です。
グローバルプロキシの設定
Postmanのドキュメントには、3つの方法が記載されています。
デフォルトのプロキシは、システムで設定されているプロキシを自動的に使用します。オペレーティングシステムにすでにプロキシが設定されている場合、Postmanがそれを自動的に認識するため、何も設定する必要はありません。
システムプロキシは、リクエストに対してシステムプロキシを明示的に有効にするものです。システムプロキシが設定されているにもかかわらず、Postmanがそれを無視しているように見える場合に確認すべき設定です。
カスタムプロキシでは、別のサーバーを指定できます。これは商用プロキシサービスを利用する際に使用するもので、「設定」の「プロキシ」タブで設定します。
サポートされているプロトコルは、多くの人が予想するよりも幅広いものです。ドキュメントには「HTTP、SOCKS5、SOCKS5H、SOCKS4、およびSOCKS4Aプロトコル」と記載されていますが、1つの制限が明記されています。「Postmanは、SOCKSプロキシ経由でのHTTPおよびHTTPSリクエストの送信のみをサポートしています。」
SOCKS5Hの記載は注目に値します。hのこのバリエーションは、ホスト名をローカルで解決するのではなく、プロキシに送信して解決させるため、トラフィックが外部へ流出している間も、DNSクエリが自身のリゾルバーに漏れるのを防ぎます。特に、自身の位置情報を偽装するためにSOCKSを使用する場合は、SOCKS5ではなくSOCKS5Hを選択してください。
認証は別の切り替えスイッチです。認証情報を必要とするプロキシの場合、ドキュメントには「Postmanデスクトップアプリに認証情報を追加する」よう記載されており、プロキシ設定タブでユーザー名とパスワードを入力します。これはデスクトップアプリでの操作である点に注意してください。ブラウザ版では、ローカルネットワーク上のプロキシに接続できません。
バイパスリストを使用すると、ホストを除外できます。「ホスト名をカンマ区切りでリスト入力してください。これらのホストに送信されるリクエストは、カスタムプロキシを使用しません。」ここに localhost、127.0.0.1、およびその他の内部ホスト名を指定してください。そうしないと、自身の開発サーバーへのリクエストがプロキシ経由でルーティングされ、混乱を招くようなエラーが発生してしまいます。
実際に機能しているかを確認する
多くの人が省略してしまうこの手順こそ、1時間の時間を節約してくれるものです。
表示されているアドレスを報告してくれるサービスにリクエストを送信します：
GET https://api.ipify.org?format=json
プロキシを無効にした状態で実行し、アドレスを確認してから、プロキシを有効にして再度実行します。 アドレスが変わらない場合、プロキシは使用されていません。 これを知らせるエラーメッセージは表示されません。リクエストは単に直接送信され、成功するだけです。
設定が反映されない3つの一般的な理由：
バイパスリストにターゲットが一致している。 意図せず対象をカバーしているエントリがないか確認してください。
Postmanのブラウザ版を使用している場合、ローカルマシン上のプロキシにアクセスできません。デスクトップアプリが必要です。
設定が間違ったタブにある場合。デフォルト、システム、カスタムは別々のオプションであり、システムプロキシオプションが選択されている状態でカスタムプロキシを設定しても効果はありません。
地域限定のプロキシの場合、アドレスを確認するだけでは不十分です。結果によって検証してください。つまり、地域によって実際に異なるリクエストを行い、レスポンスが変化することを確認してください。ルックアップサービスが正しい国を報告しているにもかかわらず、APIが自宅の地域のデータを返す場合は、ターゲティングが本来意図した場所に到達していないことを意味します。
リクエストを失敗させる設定
Postman の 2 つの設定がプロキシの使用と相互作用し、原因不明のエラーを引き起こします。
SSL 証明書の検証。 プロキシが TLS を傍受している場合（企業のプロキシではよくあることです）、Postman は、その証明書が信頼された認証局ではなくプロキシ自身の認証局によって発行されたものであるため、その証明書を拒否します。 その結果、すべての HTTPS リクエストで TLS エラーが発生します。
正しい対処法は、Postman の証明書設定に自組織の CA 証明書を追加することです。 SSL検証をグローバルに無効にしたくなるかもしれませんが、その代償を理解しておく価値があります。無効にすると、Postmanでのすべてのリクエストが、どのような証明書でも受け入れてしまうことになります。これは、何かがリクエストを傍受していないかを知りたいAPIの場合でも同様です。どうしても無効にする必要がある場合は、そのリスクを十分に理解した上で行い、その後必ず再有効化してください。
リクエストのタイムアウト。 Postmanのデフォルトのリクエストタイムアウトは余裕がありますが、プロキシ（特に一般家庭向けのもの）はリクエストごとに実質的な遅延をもたらします。プロキシ経由のリクエストがタイムアウトする一方で、直接リクエストすると正常に動作する場合は、プロキシが故障していると結論付ける前に、設定でタイムアウト時間を延長してください。
コレクションの実行に関する補足：従量課金制のプロキシを経由する場合、大容量のデータファイルを使用したコレクションの実行では、行ごとに1回のリクエストが発生し、そのすべてに対して課金されます。これは後から考えれば当然のことですが、請求書を見て初めて驚くことがあります。
Postmanの組み込みプロキシ：トラフィックのキャプチャ
もう1つの機能で、これは実に便利なものです。
ドキュメントには次のように明記されています。「Postmanデスクトップアプリには、HTTPおよびHTTPSトラフィックをキャプチャできる組み込みプロキシが搭載されています。」 これはクライアントアプリケーションからのリクエストを傍受して転送し、レスポンスをキャプチャするほか、Cookieの収集も可能です。
デフォルトのポートは5559です。
他のデバイスをこのプロキシに接続するには、ドキュメントに以下の3つの手順が記載されています： お使いのコンピュータのローカルIPアドレスを確認し、そのIPアドレスとプロキシポートを使用してHTTPプロキシを利用するようにデバイスのWi-Fi設定を構成します。また、iOSの場合は特に、「設定」→「Wi-Fi」→情報アイコン→「プロキシ設定」→「手動」の順に進み、サーバーのIPアドレスとポートを入力します。
これは、「このモバイルアプリは実際に何を送信しているのか」という、そうでなければ意外に扱いにくい質問に対する最も手っ取り早い解決策です。
HTTPSには証明書が必要です。 ドキュメントには、プロキシが「セキュアなHTTPSトラフィックをキャプチャするには、クライアントデバイスに『postman-proxy-ca.crt』証明書をインストールする必要がある」こと、またホストコンピュータでは「証明書をインストールすることで、Postmanプロキシがブラウザやその他のクライアントアプリから送信されるセキュアなHTTPSトラフィックをキャプチャできるようになる」ことが明記されています。
実行する前に、これが何を意味するのかを理解してください。あなたは、任意のドメインに対して証明書を発行できる認証局をインストールすることになり、PostmanはそのTLSトラフィックを復号化して表示します。これが仕組みのすべてであり、暗号化を解除せずに暗号化されたトラフィックを検査する方法はありません。
この点から、真剣に受け止めるべき2つの結果があります。作業が終了したら、必ず証明書を削除してください。特に、個人的な用途にも使用しているスマートフォンでは注意が必要です。また、証明書がインストールされている間は、重要な認証情報を含むトラフィックをキャプチャしないでください。それらの認証情報は復号化され、表示されてしまうからです。
環境機能を活用したプロキシ依存作業の管理
Postmanではリクエストごとにプロキシを変更できないため、実用的な回避策として、それ以外のすべての設定を変更することになります。この点において、Postmanの環境機能はまさにうってつけです。
ターゲットのベースURLはリクエスト内ではなく、環境変数に設定してください。すべてのリクエストで {{baseUrl}}
を使用するコレクションでも、環境を切り替えることで別のホストを指すようにできます。これにより、何も編集することなく、地域ごとの動作を比較することが可能です：
{{baseUrl}}/api/products?region={{region}}
シナリオごとに1つの環境を作成します。 「ダイレクト」環境と「プロキシ経由」環境をそれぞれ独自の変数とともに用意しておけば、1つのドロップダウンでコンテキストを切り替えることができます。プロキシ設定そのものは「設定」で切り替える必要がありますが、それ以外のすべては環境に合わせて自動的に変更されます。
アドレスチェックをコレクション内のリクエストとして保存する。 実際のリクエストと一緒に保存された GET https://api.ipify.org?format=json
があれば、プロキシの確認に新しいタブを開く必要がなく、ワンクリックで済みます。検出結果を記録するテストスクリプトを追加しましょう：
const ip = pm.response.json().ip;
pm.environment.set("observedIp", ip);
console.log("Exit address:", ip);
アドレスではなく、リージョンに依存するコンテンツについてアサーションを行う。 地域ターゲティングを行う場合、有用なチェックはレスポンスが実際に異なるかどうかを確認することです：
pm.test("Response is region-specific", function () {
pm.expect(pm.response.json().currency).to.eql(pm.environment.get("expectedCurrency"));
});
これは、プロキシ作業の他のあらゆる場面と同じ原則です。IP 検索では検索サービスがどう判断しているかがわかりますが、ターゲティングが機能したかどうかは、ターゲット自身のレスポンスによってのみ確認できます。
また、認証情報はコレクションに含めないでください。 プロキシの認証情報はPostmanの設定に、APIの認証情報は「secret」としてマークされた環境変数に格納すべきです。リクエスト内に含めるべきではなく、ましてやエクスポートや共有を目的としたコレクション内に含めることは絶対に避けてください。エクスポートされたコレクションには、変数が「secret」としてマークされていない限り、その変数値がそのまま含まれてしまいます。これにより、うっかりトークンを公開してしまうリスクが高まります。
用途に応じたツールの選び方
Postmanは特定の用途に特化した優れたツールですが、その限界を理解しておくことで時間を節約できます。
Postmanの活用シーン： APIのインタラクティブな探索、プロキシが正常に動作しているかどうかの確認、デバイスからのトラフィックのキャプチャ、およびリクエストコレクションの同僚との共有。
curl を使うべき場面： 再現したい処理、スクリプト化したい処理、またはチケットに貼り付けたい処理など。-x
によるリクエストごとのプロキシ制御、ネットワーク上で何が起こったかを正確に示す詳細な出力、そしてどのマシンでも同じように動作するコマンド（
curl -x http://user:pass@proxy.example.com:9000 https://api.ipify.org
）が利用できます。Postman では、任意のリクエストから curl コマンドを生成できるため、探索段階から再現可能な状態へ移行する最も速い方法となります。
コード内では、以下の用途に適切なHTTPクライアントを使用してください： 実際の処理量が多い場合、リクエストごとのルーティング、リトライロジック、またはセッション処理が必要な場合。Postmanのグローバルプロキシ設定はアプリケーション全体で単一の値であるため、リクエストごとに異なる出口を必要とするワークロードは、この設定ではまったく表現できません。
実用的なワークフロー： Postmanでプロキシが機能することを確認し、リクエストをcurl形式でエクスポートしてGUI外で検証した後、リクエストごとの制御を備えたコードとして実装します。各ステップは、不適切なツールで前のステップのデバッグを行うよりも効率的です。
トラブルシューティング
プロキシを使用しない場合はリクエストが成功するが、プロキシを使用すると失敗する。 まず認証情報を確認してください。ステータスコード 407 はプロキシによるアクセス拒否を意味し、これはターゲット側から返される 401 とは異なるエラーです。次に、プロバイダーが IP 許可リストを使用しており、現在のアドレスがリストに含まれていないかどうかを確認してください。
すべての処理が遅い。 個人向けプロキシはリクエストごとに実際の遅延を生じますが、これは不具合ではなく物理的な特性によるものです。何かが壊れていると結論付ける前に、タイムアウト時間を延長して測定を行ってください。
すべての HTTPS リクエストで TLS エラーが発生する。 プロキシが TLS を傍受しています。検証を無効にするのではなく、CA 証明書を追加してください。
プロキシ設定が無視されているようです。 バイパスリストを確認し、デスクトップアプリを使用していることを確認した上で、正しいオプションが有効になっているか確認してください。「カスタム」「システム」「デフォルト」はそれぞれ別物です。
キャプチャに何も表示されません。 デバイスが同じネットワーク上にあり、ポートが一致していること、およびお使いのマシン上のファイアウォールが 5559 番ポートへの着信接続をブロックしていないことを確認してください。
HTTPS キャプチャに接続は表示されるが、コンテンツが表示されない。 クライアントデバイスに CA 証明書がインストールされていないか、信頼されていません。一部のプラットフォームでは、証明書のインストールと信頼設定は別々の手順となります。
正しい認証情報を入力しても 407 エラーが解消されない場合。 パスワードにエンコードが必要な文字が含まれていないか確認し、プロバイダーが認証情報を要求しているかどうかを確認してください。多くのプロバイダーは代わりに IP 許可リストを提供しており、これにより設定から認証情報が完全に排除されます。IP アドレスが安定している場合は、この方法を利用することをお勧めします。
よくある質問
Postmanでプロキシを設定するにはどうすればよいですか？
デスクトップアプリで「設定」を開き、「プロキシ」タブに移動します。そこで「カスタムプロキシ」を選択し、ホスト名とポート番号を入力してください。Postmanでは、システムのプロキシを自動的に使用することも可能です。プロキシに認証情報が必要な場合は、同じタブで認証情報を追加してください。
PostmanはSOCKSプロキシに対応していますか？
はい。ドキュメントには、HTTP、SOCKS5、SOCKS5H、SOCKS4、SOCKS4Aが記載されています。 記載されている制限として、SOCKSプロキシ経由で送信できるのはHTTPおよびHTTPSリクエストのみです。SOCKS5よりもSOCKS5Hを優先してください。SOCKS5Hはプロキシ側でホスト名を解決するため、DNSクエリの漏洩を防ぐことができます。
Postmanがプロキシ設定を無視するのはなぜですか？
通常、以下の3つの原因のいずれかが考えられます：ターゲットホストがバイパスリストのエントリと一致している、デスクトップアプリではなくブラウザ版を使用している、または別のプロキシオプションが選択されている状態でカスタムプロキシを設定している。自分のアドレスを返すサービスにリクエストを送信して確認してください。
Postmanでリクエストをキャプチャするにはどうすればよいですか？
組み込みのプロキシを使用してください（デフォルトのポートは 5559 です）。お使いのコンピュータのローカル IP アドレスを確認し、クライアントデバイスを設定してそのポートで HTTP プロキシとして使用できるようにします。HTTPS リクエストをキャプチャする必要がある場合は、そのデバイスに postman-proxy-ca.crt の証明書をインストールしてください。
Postman でプロキシを使用すると、なぜ SSL エラーが発生するのですか？
これは、プロキシがTLS通信を傍受し、Postmanが信頼していない独自の証明書を提示しているためです。Postmanの証明書設定に、所属組織のCA証明書を追加してください。SSL検証を無効にすることも可能ですが、その設定は以降のすべてのリクエストに適用されるため、セキュリティ上のリスクが高まります。
Postmanでリクエストごとに異なるプロキシを設定できますか？
いいえ。プロキシ設定はアプリケーション全体に適用されるため、リクエストごとに異なる出口を必要とするワークロードにはPostmanは適していません。そのような場合はコードベースのクライアントを使用し、Postmanはコードを記述する前にプロキシが機能するかどうかを確認するために使用してください。
Postmanのプロキシ設定とキャプチャプロキシの違いは何ですか？
プロキシ設定は、Postman自身のリクエストを外部プロキシ経由でルーティングします。一方、キャプチャプロキシは、Postmanを他のアプリケーションがリクエストを送信するためのプロキシとして機能させ、それらのアプリケーションが送信する内容を確認できるようにするものです。方向性が異なり、設定も無関係です。
PostmanのCA証明書をインストールしても安全ですか？
これは意図的なトレードオフです。この証明書により、PostmanはHTTPSトラフィックを復号化できるようになりますが、これはトラフィックを検査する唯一の手段でもあります。一方で、この証明書を持つものは、どのドメインに対しても信頼された証明書を発行できることを意味します。キャプチャが必要な場合にのみインストールし、作業終了後は削除してください。また、インストール中は機密性の高い認証情報の取り扱いを避けてください。
まとめ
このトピックに関する混乱は、あくまで名称の問題に過ぎません。Postmanのプロキシ設定は、リクエストを他者のプロキシ経由で送信するものです。一方、Postmanのキャプチャプロキシは、Postman自体を他のアプリケーションの中継点として機能させるものです。どちらを使うかを決めるのにかかる時間は10秒程度で、間違ったドキュメントを読み込む手間を省くことができます。
前者の場合は、デスクトップアプリを使用し、「設定」でカスタムプロキシを設定し、バイパスリストに localhost を追加します。そして、最も重要なステップとして、自分のアドレスを返すサービスにリクエストを送信して確認してください。何もしないプロキシ設定では、エラーが一切発生しないからです。
2つ目の方法では、ポート5559とクライアントデバイス上のCA証明書が必要です。この証明書はPostmanがトラフィックを復号化するために存在することを理解し、作業が終わったら削除してください。
また、Postmanの限界も認識しておきましょう。Postmanはプロキシ設定をグローバルに適用するため、リクエストごとのルーティングをまったく表現できません。Postmanはプロキシが機能しているかを確認するために使用し、リクエストをcurl形式でエクスポートしてGUI外で検証した後、実際の処理はコードで構築してください。インタラクティブなツールにスクリプト化された作業をさせようとするよりも、その方が効率的です。