nginx でフォワードプロキシを設定する方法（HTTP + HTTPS）

nginx のフォワードプロキシとは、クライアントからのリクエストを外部の宛先へ中継するように構成された nginx サーバーであり、オリジンサーバーの代わりではなく、クライアントに代わって動作します。このチュートリアルでは、HTTP と HTTPS の両方で動作するフォワードプロキシを構築し、curl でテストし、アクセス制御を追加し、1台のサーバー IP では足りない場合に 住宅用プロキシのプールへ接続する方法を順に解説します。

読み終える頃には、実用的な nginx フォワードプロキシの構成と、nginx 単体では適切な選択肢でなくなる条件が得られます。

DataImpulse は倫理的なプロキシプロバイダーで、195か国にわたって9,000万を超える住宅用、モバイル、データセンターの IP アドレスを提供しています。トラフィックが失効しない従量課金モデルを 1 GB あたり 1 ドルから採用し、Webスクレイピング、広告検証、価格モニタリング、市場調査、複数アカウント管理に利用されています。

nginx フォワードプロキシとリバースプロキシの違いは何ですか?

フォワードプロキシはクライアントの前に立ち、そのリクエストを任意の宛先へ外向きに転送します。一方リバースプロキシはサーバーの前に立ち、サーバーに代わって受信リクエストを受け付けます。違いは、トラフィックの流れる向きです。

nginx のチュートリアルの多くはリバースプロキシを扱っているため、この点を念頭に置いてください:

• フォワードプロキシ。 クライアントがそれを経由してトラフィックを送るよう構成され、ターゲットからはクライアントが隠されます。curl -x やブラウザのプロキシ欄で設定するものです。
• リバースプロキシ。 クライアントは公開ホスト名へ通常どおり接続し、nginx はその背後のバックエンドプールへリクエストをルーティングします。クライアントはプロキシの存在を知りません。

より詳しい比較は、reverse proxy vs forward proxy のガイドをご覧ください。この記事の残りではフォワードの場合のみを扱います。

始める前に何が必要ですか?

公開 IP を持つ Linux サーバーと nginx が必要です。HTTPS には CONNECT モジュールを組み込んだ nginx のビルドも必要です。暗号化されていない HTTP の転送は、標準の nginx でも動作します。

バイナリがすでに CONNECT に対応しているか確認します:

nginx -V 2>&1 | grep -o proxy_connect
# empty output means the module is not compiled in

標準の nginx には、HTTPS トンネリングに必要な HTTP CONNECT メソッド用のディレクティブがないため、ブラウザや curl は未改変のビルドでは TLS をトンネルできません。これを追加するには、オープンソースの ngx_http_proxy_connect_module でパッチを当てて nginx を再コンパイルします:

git clone https://github.com/chobits/ngx_http_proxy_connect_module
cd nginx-1.27.0
patch -p1 < ../ngx_http_proxy_connect_module/patch/proxy_connect_rewrite_102101.patch
./configure --add-module=../ngx_http_proxy_connect_module
make && make install

パッチファイルは nginx のバージョンに合わせてください。モジュールのリポジトリに、どのパッチがどのリリースに対応するか記載されています。

nginx フォワードプロキシを段階的に設定するには?

プロキシ用ポートで待ち受ける専用の server ブロックを定義し、DNS resolver を設定して、クライアントが指定したホストへリクエストを転送します。まず暗号化されていない HTTP から始め、その後 HTTPS 用の CONNECT ディレクティブを追加します。

これは HTTP トラフィック向けの、フォワードプロキシとしての最小限の nginx 構成です:

server {
    listen 8888;
    resolver 1.1.1.1 ipv6=off;

    location / {
        proxy_pass http://$http_host$request_uri;
        proxy_set_header Host $http_host;
        proxy_buffers 256 4k;
    }
}

resolver の行が重要なのは、nginx がリクエスト時に動的なターゲットホストを解決するためです。次に同じブロックを拡張し、CONNECT メソッドで HTTPS をトンネルします。次の nginx フォワードプロキシの HTTPS 用設定例では、CONNECT を有効にし、標準の TLS ポートだけを許可します:

server {
    listen 8888;
    resolver 1.1.1.1 ipv6=off;

    proxy_connect;
    proxy_connect_allow            443 563;
    proxy_connect_connect_timeout  10s;
    proxy_connect_read_timeout     10s;
    proxy_connect_send_timeout     10s;

    location / {
        proxy_pass http://$http_host$request_uri;
        proxy_set_header Host $http_host;
    }
}

オープンなフォワードプロキシはリスクとなるため、既知のクライアントだけにアクセスを制限します。IP アドレスによる許可リストが最もシンプルな方法です:

location / {
    allow 198.51.100.0/24;
    deny  all;
    proxy_pass http://$http_host$request_uri;
}

IP ルールの代わりに資格情報ベースのアクセスを使う場合は、nginx を認証レイヤーと組み合わせます。proxy authentication のガイドで、ユーザー名とパスワードの方式と、その背後にある HTTP 407 ハンドシェイクを解説しています。

nginx フォワードプロキシが動作するか確認し、よくあるエラーを直すには?

-x フラグで curl をプロキシに向け、IP エコーサービスにリクエストします。プロキシサーバーの公開 IP を示すレスポンスが返れば、トラフィックがそこを通っている証拠です。HTTP と HTTPS は個別にテストします。

curl -x http://203.0.113.10:8888 http://httpbin.org/ip
curl -x http://203.0.113.10:8888 https://httpbin.org/ip

デバッグ時に転送された各リクエストとその接続先 upstream を確認できるよう、ログフォーマットを追加します:

log_format proxy '$remote_addr [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 'upstream=$upstream_addr';
access_log /var/log/nginx/forward_proxy.log proxy;

テストが失敗したら、よくある原因を順に確認します:

• HTTPS が 400 を返すかハングする。 CONNECT モジュールがコンパイルされていないか、proxy_connect が欠けています。nginx -V を再確認してください。
• 502 または名前解決エラー。 resolver ディレクティブが無いか、到達できない DNS サーバーを指しています。
• 許可済みクライアントに対する 403。 リクエスト元の IP が allow の範囲外です。
• 407 Proxy Authentication Required。 upstream が資格情報を要求しています。HTTP エラー 407 を参照してください。

nginx を 住宅用プロキシのプールへ接続するには?

Proxy-Authorization ヘッダーを付けて住宅用 gateway へトラフィックを転送することで、nginx を上流プロキシへ接続します。これにより、1つの静的なサーバー IP から実在 IP のローテーションプールを利用できるようになります。

この設計は 3層のプロキシトポロジーとして捉えてください。各層に名前を付けることで、信頼とローテーションの境界が明確に保たれます:

• 第1層、クライアント。 -x で nginx を使うよう構成された、あなたのスクリプトやブラウザです。
• 第2層、nginx フォワードプロキシ。 あなたが所有する1つの IP 上での集中的な制御、ロギング、アクセスルールです。
• 第3層、住宅用プロキシのプール。 多数の実在 IP にわたるローテーションと地域指定 で、nginx が単体では提供できないものです。

住宅用プロキシ gateway への最小限の受け渡しは次のようになります。Basic トークンはあなたの login:password を base64 でエンコードしたものです:

server {
    listen 8890;

    location / {
        proxy_pass http://gw.dataimpulse.com:823;
        proxy_set_header Proxy-Authorization "Basic bG9naW46cGFzc3dvcmQ=";
        proxy_set_header Host $http_host;
    }
}

トレードオフには率直でいましょう。単にローテーションが必要なだけなら、クライアントを直接 gw.dataimpulse.com:823 に向ける方が、nginx のホップを追加するよりシンプルです。チェーン構成が意味を持つのは、集中ロギング、キャッシュ、またはチーム全体での共有アクセス制御のために nginx を中間に置きたい場合だけです。

あなたの用途にはどのプロキシ構成が合いますか?

クライアントを自分で制御でき、1つの出口 IP で十分なら、nginx フォワードプロキシ単体を使います。ローテーション、地域の選択肢、ブロックへの耐性が必要なら、住宅用プロキシのプールを追加します。決め手は、用途がいくつの異なる IP を必要とするかです。

判断の目安は次のとおりです:

• nginx フォワードプロキシ単体を使うのは、送信トラフィックを一元化する、リクエストをフィルタリングまたはロギングする、社内チームで1つの出口 IP を共有する場合です。
• nginx 単体を避けるのは、ターゲットが IP アドレスごとにレート制限やブロックを行う場合、またはリクエストを多くの国から発信させる必要がある場合です。nginx は1台のサーバー IP から転送し、ローテーションできません。

以下の比較で両者を並べて示します。

より本格的な自動化については、Webスクレイピングのベストプラクティスのガイドではローテーションとレート制御を扱っています。一方、住宅用プロキシの信頼性よりも、コストや通信事業者の IP が重要な用途には、データセンタープロキシ や モバイルプロキシ が適しています。

nginx フォワードプロキシの制限とリスクは何ですか?

nginx フォワードプロキシには現実的な制限があります。1つの IP から転送すること、HTTPS 対応が組み込みでないこと、そしてオープンなインスタンスがセキュリティリスクであることです。これらを知っておくと期待値が正直に保たれます。

• 単一 IP、ローテーションなし。 すべてのリクエストが同じサーバーアドレスから出るため、IP アドレスで制限するサイトでは、すぐにスロットリングやブロックの対象になり得ます。
• HTTPS にはカスタムビルドが必要。 CONNECT トンネリングはサードパーティモジュールとバージョンに合ったパッチに依存するため、アップグレードが複雑になります。
• オープンプロキシの危険。 allow ルールや認証がなければ、ポートを見つけた誰もがあなたのサーバー経由でトラフィックをルーティングでき、悪用や法的なリスクにつながります。
• 地理的カバレッジなし。 出口の場所はサーバーが動く地点に固定されるため、地域別のテストには複数のサーバーが必要になり、パッチ適用、監視、稼働時間のすべてを自分で担うことになります。

nginx は DataImpulse の製品ではなく、DataImpulse はマネージドのスクレイピング API や無料の Webプロキシ を販売していません。nginx が適する場面では自分で運用してください。スケールが必要な場面では、DataImpulse はオプトインして報酬を受け取るユーザーから ethical proxies として IP を調達しています。

よくある質問

関連ガイド

• NGINX リバースプロキシ
• Scrapy での ローテーションプロキシ
• プロキシの費用はいくらか

nginx では得られないローテーションが必要ですか?

1台のサーバー IP では足りないとき、DataImpulse は195か国にわたって9,000万以上のローテーション対応の住宅用、モバイル、データセンター IP を追加します。トラフィックは失効せず、従量課金で 1 GB あたり 1 ドルからです。アカウントを作成して gateway の資格情報を取得し、nginx またはクライアントから直接そのプールへ接続できます。