Postmanは、世界中の開発者、QAエンジニア、バックエンドスペシャリストによって使用される最も人気のあるAPIテストツールの1つです。しかし、特定の地域からのみアクセス可能なAPIをテストする必要がある場合、IPによるブロックを回避する必要がある場合、または異なる場所からのリクエストを検証する必要がある場合はどうすればよいでしょうか?解決策は、Postmanでプロキシサーバーを設定することです。
このガイドでは、Postmanでのプロキシ設定の正しい方法を、トラフィックの単純なルーティングから地理制限されたエンドポイントの操作、企業のプロキシサーバーを介したリクエストのデバッグまで、さまざまなシナリオにわたって説明します。グローバル設定と個別設定の両方、HTTPおよびSOCKS5プロトコルの操作、認証、一般的な問題の解決についても説明します。
APIテストにおけるプロキシの必要性
APIテストにおけるプロキシサーバーは、Postmanの標準機能では実行できないいくつかの重要なタスクを解決します。これらのシナリオを理解することで、適切なプロキシの種類を選択し、特定のニーズに合わせて設定することができます。
地理制限されたAPIのテスト。多くの現代のAPIは、クライアントの地理的位置に応じて異なるデータを返します。たとえば、気象サービス、ストリーミングプラットフォーム、金融アプリケーション、マーケットプレイスのAPIなどです。ドイツ、アメリカ、または日本のユーザー向けにアプリケーションがどのように機能するかをテストするには、該当する国のIPアドレスを持つプロキシサーバーが必要です。プロキシなしでは、他の地域のユーザーに対するAPIの動作を物理的に再現することはできません。
レート制限およびIPブロックの回避。APIを集中的にテストする際、1つのIPアドレスからのリクエスト数に制限がある場合があります。多くのサービスは、IPレベルでレート制 limitingを使用しています。たとえば、1つのアドレスからのリクエストは1分間に100件までです。プロキシをローテーションすることで、複数のIPアドレス間でリクエストを分散させ、遅延なしでテストを続けることができます。これは、負荷テストや自動化されたチェックに特に重要です。
企業プロキシを介した操作。厳格なネットワークポリシーを持つ企業で働いている場合、すべてのアウトバウンドトラフィックは企業プロキシサーバーを経由する可能性があります。この場合、Postmanでのプロキシ設定はオプションではなく、必要です。正しい構成がないと、リクエストは外部APIに到達しません。
トラフィックのデバッグと監視。プロキシサーバーは、HTTP/HTTPSトラフィックをキャプチャして分析するために使用できます。Charles Proxy、Fiddler、mitmproxyなどのツールを使用すると、リクエストとレスポンスの詳細、ヘッダー、リクエストのボディ、実行時間を確認できます。このようなプロキシを介してPostmanを設定すると、複雑なAPIインタラクションをデバッグするための強力なツールを得ることができます。
重要:地理的制限のあるAPIをテストするには、レジデンシャルプロキシを使用することをお勧めします。これらは実際の家庭ユーザーのIPアドレスを使用し、サービスによってプロキシサーバーとして識別されません。これはテストの正確性にとって重要です。
Postmanでのプロキシのグローバル設定
Postmanでは、プロキシを設定するための2つの主要な方法を提供しています:グローバル(すべてのリクエストに適用)と個別(特定のコレクションやリクエスト用)。まず、アプリケーションの設定メニューにあるグローバル設定から始めましょう。
プロキシ設定にアクセスする手順:
- Postmanを開き、アプリケーションの右上隅にあるギアアイコン(設定)をクリックするか、ショートカットキー
Ctrl+,(Windows/Linux)またはCmd+,(macOS)を使用します。 - 開いた設定ウィンドウで、Proxyタブに移動します。
- ここでは、以下で詳しく説明するいくつかのプロキシサーバーの構成オプションが表示されます。
プロキシ設定セクションには、プロキシを操作するための3つの主要なモードがあります:
- システムプロキシを使用 — オペレーティングシステムのシステムプロキシ設定を使用する
- カスタムプロキシ構成を追加 — 手動で独自のプロキシサーバーを設定する
- グローバルプロキシ構成 — HTTPおよびHTTPS用に異なるプロキシを指定できるグローバル構成
これらの各モードにはそれぞれの利点があり、異なる使用シナリオに適しています。それぞれを詳しく見ていきましょう。
システムプロキシ設定の使用
Postmanでプロキシを設定する最も簡単な方法は、システムプロキシ設定を使用することです。このモードは、オペレーティングシステムレベルでプロキシがすでに設定されている企業環境で作業している場合や、システムプロキシを自動的に構成するVPNクライアントを使用している場合に特に便利です。
システムプロキシの使用を有効にする方法:
- PostmanでSettings → Proxyを開きます。
- システムプロキシを使用のチェックボックスをオンにします。
- Postmanは自動的にOSの構成からプロキシ設定を検出します。
- 変更を保存するために更新ボタンをクリックします。
このオプションを有効にすると、Postmanはブラウザや他のアプリケーションと同じプロキシ設定を使用します。つまり、Windows(設定 → ネットワークとインターネット → プロキシ)、macOS(システム環境設定 → ネットワーク → 詳細 → プロキシ)、またはLinux(環境変数を介して)でプロキシを設定した場合、Postmanはこれらの設定を自動的に取得します。
制限:システム設定では、異なるリクエストに対してプロキシを柔軟に管理することはできません。異なる地域からAPIをテストしたり、プロキシサーバーを切り替えたりする必要がある場合は、カスタム構成を使用する方が良いでしょう。
カスタムプロキシサーバーの設定
カスタムプロキシ設定を使用すると、トラフィックのルーティングを完全に制御できます。特定のプロキシサーバー、ポート、プロトコルの種類を指定し、HTTPおよびHTTPSリクエスト用に異なるプロキシを設定することもできます。この方法は、商業プロキシサービスや独自のプロキシインフラストラクチャを使用したテストに最適です。
カスタムプロキシの設定手順:
- PostmanでSettings → Proxyを開きます。
- システムプロキシを使用のオプションがオフになっていることを確認します。
- カスタムプロキシ構成を追加のオプションをオンにします。
- プロキシタイプのフィールドで、プロトコルを選択します:HTTP、HTTPS、またはSOCKS5。
- プロキシサーバーのフィールドにプロキシサーバーのアドレスを入力します(例:
proxy.example.comまたはIPアドレス192.168.1.100)。 - プロキシポートのフィールドにポートを指定します(通常、HTTP用は8080、SOCKS5用は1080ですが、プロバイダーによって異なります)。
- プロキシが認証を必要とする場合は、プロキシ認証のオプションをオンにし、ユーザー名とパスワードを入力します。
- 設定を適用するために更新をクリックします。
設定を保存した後、Postmanからのすべてのアウトバウンドリクエストは指定されたプロキシサーバーを経由します。プロキシ設定の正確性を確認するには、IP確認サービスにテストリクエストを送信します。例えば:
GET https://api.ipify.org?format=json
レスポンスには、実際のIPではなく、プロキシサーバーのIPアドレスが表示されるはずです。IPが変更されていない場合は、入力したデータの正確性を確認し、プロキシサーバーが機能していることを確認してください。
HTTPおよびHTTPS用の異なるプロキシの設定
Postmanでは、HTTPおよびHTTPSトラフィック用に個別のプロキシサーバーを設定できます。これは、保護された接続に別のプロキシを使用する企業インフラストラクチャで作業している場合に便利です。
別々に設定するには:
- プロキシ設定セクションでグローバルプロキシ構成をオンにします。
- HTTPプロキシとHTTPSプロキシの2つの別々のブロックが表示されます。
- 各ブロックに対して、独自のサーバー、ポート、および認証情報を指定します。
- 変更を保存します。
これで、HTTPリクエストは1つのプロキシを経由し、HTTPSリクエストは別のプロキシを経由します。これは、ハイブリッドインフラストラクチャでのテストに特に重要です。
認証が必要なプロキシの操作
ほとんどの商業プロキシサービスおよび企業プロキシは、アクセスのために認証を要求します。Postmanは、プロキシサーバー用の基本的なHTTP認証(Basic Auth)をサポートしており、安全に資格情報を送信できます。
プロキシ認証の設定:
- プロキシ設定(Settings → Proxy)でプロキシ認証のオプションをオンにします。
- ユーザー名のフィールドに、プロキシプロバイダーから提供されたユーザー名を入力します。
- パスワードのフィールドにパスワードを入力します。
- 保存するために更新をクリックします。
Postmanは、プロキシを経由するすべてのリクエストにProxy-Authorizationヘッダーを自動的に追加します。資格情報はエンコードされた形式(Base64)で送信されますが、最大のセキュリティを確保するために、HTTPSプロキシまたは暗号化されたSOCKS5を使用することをお勧めします。
ヒント:商業プロバイダーのプロキシを使用している場合、資格情報は通常username:password@host:portの形式で指定されます。Postmanでは、これらのデータを別々に入力する必要があります:サーバーとポートをそれぞれのフィールドに、ユーザー名とパスワードをプロキシ認証セクションに入力します。
レジデンシャルプロキシを使用した設定の例
例えば、あなたが<а href="https://proxycove.com/ja/residential-proxies/" style="color:#2563eb;">レジデンシャルプロキシを使用して、アメリカとヨーロッパのユーザーに異なるコンテンツを返すAPIをテストしているとします。プロキシプロバイダーから以下のデータが提供されました:
- サーバー:
us.residential.proxy.com - ポート:
8080 - ユーザー名:
user_12345 - パスワード:
SecurePass789
Postmanでの設定は次のようになります:
- プロキシタイプ:HTTP
- プロキシサーバー:
us.residential.proxy.com - プロキシポート:
8080 - プロキシ認証:有効
- ユーザー名:
user_12345 - パスワード:
SecurePass789
設定を適用すると、すべてのリクエストはアメリカのIPアドレスから送信され、地理的に特定のAPIの動作をテストできます。
PostmanでのSOCKS5プロキシの設定
SOCKS5は、HTTP/HTTPSと比較してより汎用的なプロキシプロトコルです。ネットワークスタックのより低いレベルで動作し、HTTPだけでなく任意のタイプのトラフィックをプロキシできます。SOCKS5は、非標準プロトコルを使用するAPIのテストや、最大の匿名性が必要な場合に特に便利です。
APIテストにおけるSOCKS5の利点:
- 任意のプロトコルのサポート(HTTP、HTTPS、WebSocket、FTPなど)
- リクエストヘッダーを変更しない(HTTPプロキシとは異なる)
- UDPトラフィックのサポート(リアルタイムAPIに関連)
- プロトコルレベルでの認証の組み込みサポート
- HTTPS接続のパフォーマンスが向上(ダブルSSLハンドシェイクなし)
PostmanでのSOCKS5の設定:
- Settings → Proxyを開きます。
- カスタムプロキシ構成を追加を有効にします。
- プロキシタイプのフィールドでSOCKS5を選択します。
- SOCKS5サーバーのアドレスとポートを入力します(通常は1080ですが、プロバイダーによって異なります)。
- 認証が必要な場合は、プロキシ認証を有効にし、資格情報を入力します。
- 設定を保存します。
すべてのプロキシプロバイダーがSOCKS5をサポートしているわけではないことに注意してください。テストにこのプロトコルが必要な場合は、プロバイダーにSOCKS5エンドポイントの可用性を確認してください。たとえば、モバイルプロキシは、最大の柔軟性のためにHTTP/HTTPSに加えてSOCKS5を提供することがよくあります。
プロキシのバイパスルールの設定
時には、一部のリクエストをプロキシ経由で、一部を直接送信する必要があります。たとえば、外部APIをプロキシ経由でテストしているが、ローカル開発サーバー(localhost)に直接アクセスする必要がある場合です。このようなシナリオでは、Postmanはプロキシバイパスルールの設定を提供しています。
バイパスルールを設定する方法:
- Settings → Proxyでこれらのホストとドメインのプロキシをバイパスセクションを見つけます。
- プロキシをバイパスする必要があるドメインまたはIPアドレスのリストをカンマで区切って入力します。
- マスクがサポートされています:たとえば、
*.internal.company.comはすべてのサブドメインを除外します。 - 変更を保存します。
バイパスルールの例:
localhost— ローカルホストのバイパス127.0.0.1— ループバックアドレスのバイパス192.168.*.*— ローカルネットワーク全体のバイパス*.dev.company.com— 内部devサーバーのバイパスapi.internal.service— 特定の内部APIのバイパス
バイパスルールは、外部API(地理ターゲティングや制限の回避のためにプロキシを使用)と内部サービス(速度とデバッグの簡素化のために直接)を同時にテストするハイブリッド環境で特に便利です。
実用的な例:あなたは、外部のジオロケーションAPI(異なる国からのプロキシが必要)と内部の認証API(auth.mycompany.local)で動作するモバイルアプリを開発しています。*.mycompany.localをバイパスルールに追加すると、内部リクエストは直接行われ、外部リクエストはプロキシを介して行われます。
プロキシの実用的な使用シナリオ
理論は良いですが、APIテストにおけるプロキシの実際の使用シナリオを見てみましょう。これらの例は、特定のタスクを解決するためにプロキシ設定をどのように適用するかを理解するのに役立ちます。
シナリオ1:音楽ストリーミングサービスの地理制限APIのテスト
タスク:あなたの会社は、音楽ストリーミング用のモバイルアプリを開発しています。APIは、ライセンス制限により、ユーザーの国に応じて異なるトラックのカタログを返します。アメリカ、ドイツ、日本のユーザーが正しいコンテンツを表示することをテストする必要があります。
解決策:
- アメリカ、ドイツ、日本の3か国からレジデンシャルプロキシを取得します。
- Postmanで3つの環境(Environments)を作成します:「USA Testing」、「Germany Testing」、「Japan Testing」。
- 各環境でプロキシ設定の変数を作成します(Postmanはプロキシ設定での変数を直接サポートしていませんが、環境の説明に記録できます)。
- 各地域のテスト前にSettings → Proxyでプロキシを手動で切り替えます。
- APIにリクエストを送信します:
GET https://api.musicservice.com/v1/catalog - 結果を比較します:レスポンスには各国の異なるトラックが含まれているはずです。
このプロセスを自動化するには、Newman(PostmanのCLIバージョン)を使用してプロキシパラメータを指定し、CI/CDパイプラインから自動的にプロキシを切り替えながらテストを実行できます。
シナリオ2:負荷テスト中のレート制限の回避
タスク:1つのIPからのリクエスト数が1分間に100件に制限されている公開APIのパフォーマンステストを行っています。完全な負荷テストを行うには、1分間に1000件のリクエストを送信する必要があります。
解決策:
- 10以上のプロキシサーバーのプールを使用してローテーションします。
- テストリクエストを使用してPostman Collection Runnerを設定します。
- Pre-request Scriptにプロキシのローテーションロジックを追加します(注意:Postmanはスクリプト内でのプログラムによるプロキシの切り替えをサポートしていないため、このシナリオはNewmanと外部スクリプトを使用して実装する方が良いでしょう)。
- 代替案:自動的にIPをローテーションするプロキシプロバイダーを使用します(短いTTLのスティッキーセッション)。
このシナリオには、データセンタープロキシが理想的です。これらは高速で、複数のIPアドレス間で負荷を分散できます。
シナリオ3:SSLインスペクションを使用したHTTPS APIのデバッグ
タスク:外部APIと統合しており、500エラーが返されますが、エラーの詳細は表示されません。すべてのヘッダーとボディを含むHTTPSリクエストとレスポンスの完全な内容を確認する必要があります。
解決策:
- HTTPSトラフィックをキャプチャするツールをインストールします:Charles Proxy、Fiddler、またはmitmproxy。
- ツールをポート(通常はCharles用に8888、Fiddler用に8888)でリッスンするように設定します。
- ツールのSSL証明書をシステムにインストールします(手順は通常アプリケーション内にあります)。
- PostmanのSettings → Proxyでプロキシを
localhost:8888に設定します。 - テスト目的でPostmanのSSL検証をオフにします(Settings → General → SSL certificate verification → OFF)。
- Postmanから問題のあるリクエストを送信します。
- Charles/Fiddlerで、リクエストとレスポンスの完全なダンプを確認できます。HTTPSトラフィックが復号化されます。
この方法は、APIの複雑な問題をデバッグするために不可欠です。特に、ドキュメントが不完全であるか、エラーがサーバー側で発生する場合に役立ちます。
シナリオ4:ホワイトリスト付きの企業プロキシを介したAPIのテスト
タスク:あなたは、大企業で働いており、すべてのアウトバウンドトラフィックが企業プロキシを経由しています。プロキシはホワイトリストドメインへのアクセスのみを許可します。ホワイトリストにまだ追加されていない新しい外部APIをテストする必要があります。
解決策:
- APIドメインをホワイトリストに追加するためにIT部門にリクエストを送信します(数日または数週間かかる場合があります)。
- 即時テストのために:個人のモバイルインターネットを使用するか、VPNを設定します。
- PostmanでプロキシバイパスルールにAPIドメインを追加します(これらのホストのプロキシをバイパス)。
- 代替ネットワークに接続します(モバイルホットスポット、VPN経由の自宅のWi-Fi)。
- テストを実施します。
- ドメインが企業のホワイトリストに追加された後、バイパスルールを削除し、標準プロキシを介して作業します。
このシナリオは、企業環境におけるプロキシとバイパスルールの柔軟な設定の重要性を示しています。
プロキシ使用時の一般的な問題の解決
プロキシが正しく設定されていても、問題が発生することがあります。最も一般的なエラーとその解決方法を見てみましょう。
問題1:「応答を取得できませんでした」または「エラー:接続ETIMEDOUT」
原因:
- プロキシサーバーが利用できないか、アドレス/ポートが間違っている
- プロキシが認証を要求しているが、資格情報が指定されていない
- ファイアウォールがプロキシへの接続をブロックしている
- プロキシサーバーが過負荷または一時的に利用できない
解決策:
- ターミナルを介してプロキシの可用性を確認します:
curl -x http://proxy:port https://api.ipify.org - アドレスとポートが正しく指定されていることを確認します(余分なスペースがないか、正しいプロトコルを使用しているか)
- 認証が有効になっているか、ユーザー名/パスワードが正しく入力されているかを確認します
- プール内の別のプロキシサーバーを試してみます
- Postmanでプロキシを一時的に無効にし、リクエストが直接機能するかどうかを確認します
問題2:「407プロキシ認証が必要」
原因:プロキシが認証を要求しているが、資格情報が提供されていないか、無効です。
解決策:
- Postmanの設定でプロキシ認証を有効にします
- ユーザー名とパスワードの正確性を確認します(大文字小文字、特殊文字に注意)
- あなたのIPアドレスがプロキシプロバイダーのホワイトリストに許可されていることを確認します(該当する場合)
- 資格情報の有効期限を確認します(いくつかのプロバイダーは一時的なパスワードを生成します)
問題3:HTTPSプロキシ使用時のSSL/TLSエラー
一般的なエラー:「SSL証明書の問題」、「最初の証明書を確認できません」、「証明書チェーン内の自己署名証明書」。
原因:
- プロキシがSSLインスペクションを実行し、自身の証明書を挿入しています
- プロキシの証明書がシステムの信頼された証明書にインストールされていません
- API側の証明書チェーンに問題があります
解決策:
- テスト目的で:PostmanでSSL検証をオフにします(Settings → General → SSL certificate verification → OFF)。 注意:本番環境では使用しないでください!
- 本番環境では:プロキシのルート証明書をシステムとPostmanにインストールします(Settings → Certificates → CA Certificates)
- SSLインスペクションなしのプロキシを使用します(SOCKS5またはSSLパススルーのHTTPプロキシ)
- 正しい証明書を取得するためにプロキシ管理者に連絡します
問題4:プロキシ経由でのリクエスト速度が遅い
原因:
- プロキシサーバーが地理的にあなたやターゲットAPIから遠い
- プロキシが過負荷(特に無料または安価なプロキシに関連)
- プロキシプロバイダーの通信回線が遅い
- ダブルSSL暗号化(クライアント → プロキシ → API)
解決策:
- ターゲットAPIに近いプロキシサーバーを選択します(APIがアメリカにある場合は、アメリカのプロキシを使用します)
- より高速なプロキシタイプに切り替えます(たとえば、地理的制約がないタスクの場合、レジデンシャルからデータセンターに切り替えます)
- HTTPSリクエストにはSOCKS5を使用します(オーバーヘッドが少ない)
- 保証された帯域幅を持つプレミアムプロキシを検討します
- 重要でないリクエストの場合は、一時的にプロキシを無効にします
問題5:プロキシが設定されているのにIPアドレスが変更されない
原因:
- プロキシが設定されているが、アクティブになっていない(更新を忘れた)
- APIドメインがプロキシバイパスルールに追加されている
- システムプロキシがPostmanの設定を上書きしている
- DNSリクエストが直接行われている(DNS漏れ)
解決策:
- プロキシが実際にアクティブであることを確認します:
https://api.ipify.orgにリクエストを送信し、レスポンスでIPを確認します - カスタムプロキシを使用している場合は、Use System Proxyがオフになっていることを確認します
- バイパスドメインのリストを確認し、ターゲットドメインが含まれている場合は削除します
- プロキシ設定を変更した後、Postmanを再起動します
デバッグのヒント:IP確認サービスへのテストリクエストを作成します(例:https://api.ipify.org、https://ifconfig.me、またはhttps://api.myip.com)を作成し、これを「Proxy Tests」という別のコレクションに保存します。プロキシ設定を変更するたびにこのリクエストを送信して、迅速に確認します。
結論
Postmanでのプロキシ設定は、APIテストの可能性を広げる強力なツールです。システムプロキシとカスタムプロキシサーバーの設定、HTTPおよびSOCKS5プロトコルの操作、認証とバイパスルールの設定を学びました。これらのスキルを活用することで、地理制限のあるAPIを効果的にテストし、レート制限を回避し、企業プロキシを介して作業し、トラフィックキャプチャツールを使用して複雑な問題をデバッグできます。
この記事からの主なポイントは、...