開示事項：私たちはGeonodeであり、プロキシを販売しています。そのため、この記事では自社製品の使用に反対する立場を述べています。他社のプロキシの背後に当社のプロキシを連結したり、当社のプロキシを複数連続で連結したりすると、リクエストの速度が低下し、信頼性も低下するため、状況を実質的に改善することにはなりません。 その理由は、特定のプロバイダーの制限というよりは構造的なものであり、以下で説明します。プロキシを連鎖させることには、2つか3つの真に妥当な理由がありますが、それらは匿名性というよりは、ルーティングやアクセスに関するものです。もしあなたの目的が匿名性であるならば、率直に言って、その目的のために特別に設計されたシステムこそが適切に機能し、商用プロキシを積み重ねただけでは不十分です。
チェーン接続とは実際何なのか
通常の場合：ユーザーがプロキシに接続し、プロキシが宛先に接続します。接続は2つ、仲介者は1つです。
チェーン接続の場合：プロキシAに接続し、プロキシAがプロキシBに接続し、プロキシBが宛先に接続します。各ホップで前の接続が終了し、新しい接続が確立されるため、宛先からはプロキシBのアドレスしか見えず、プロキシBからはプロキシAしか見えません。
これによる利点として、単一の中継点が両端を把握することはなく、経路を追跡するにはチェーン内のすべての運営者の協力が必要になることが挙げられています。
これらの主張は狭い意味では正しいものの、実際には要約が示唆するほど強力ではありません。この記事の残りの部分では、その理由について解説します。
チェーンを構築する2つの方法
クライアントサイドのチェーンは一般的なケースです。つまり、自分のマシンがAを経由するように設定されており、AはBへ転送するように設定（または指示）されています。proxychainsのようなツールは、接続を傍受し、ユーザーが管理するリストに沿って接続を辿らせることでこれを実現します。
重要な点は、チェーンを選択するのはあなた自身であるということです。すべてのホップを把握しており、変更も可能で、事業者の協力も必要ありません。これが、実用的なチェイニングのほとんどがクライアントサイドで行われる理由です。
サーバーサイドのチェーンとは、プロバイダーが、あなたが制御できないインフラストラクチャを経由してトラフィックを転送する場合を指します。一部のサービスは内部でこれを行っています。接続を終了させ、多数のエンドポイントのいずれかから外部へ送り出すゲートウェイは、技術的にはチェーンですが、通常はそのように説明されることはありません。
ここで重要な特性は正反対です：あなたはチェーンを制御できず、検証することもできません。 プロバイダーが「複数の国を経由してルーティングする」と主張しても、あなたの側からは検証できません。それは信頼の表明であり、アーキテクチャではありません。
proxychains：その機能と限界
最もよく知られているツールであり、その説明文にはその仕組みが的確に記されています。proxychainsは、「プリロードされたDLLを介して、動的リンクされたプログラム内のネットワーク関連のlibc関数をフックし、SOCKS4a/5またはHTTPプロキシを経由して接続をリダイレクトするUNIXプログラム」です。
この一文には、その巧妙さと限界の両方が込められています。
その巧妙さ： プロキシ機能を独自に持たないプログラムでも動作します。libcレベルでインターセプトするため、通常のソケット呼び出しを行うアプリケーションは、そのことを全く知らされることなく透過的にルーティングされます。
制限点（率直に言えば）： これは「動的リンクされたプログラムでのみ動作する」ものであり、proxychainsとターゲットアプリケーションが「同じ動的リンカーを使用している」ことが必要となる。 静的リンクされたバイナリ（現代のGoソフトウェアの多くがこれに該当する）は、まったく影響を受けません。プログラムは実行され、直接接続され、何の警告も表示されません。
3つのチェーンモードがサポートされています：
正確な順序 — 設定どおりにプロキシが使用されます。動作は予測可能ですが、1つのプロキシが機能しなくなるとチェーンが切断されます。 動的順序 — 機能しなくなったプロキシは適切に除外されるため、指定した順序とは異なるチェーンになる代償を払うことで、チェーンは障害を乗り越えて維持されます。 ランダム順序 — 設定された長さのランダムなサブセットが使用されます。実行ごとにバリエーションを持たせたい場合に便利です。
サポートされるプロトコルは、SOCKS4、SOCKS4a、SOCKS5、HTTP(S)であり、SOCKSではユーザー名/パスワード認証、HTTPでは基本認証が利用可能です。
また、非常に知られていないため知っておく価値のある、文書化された障害モードが1つあります。「プロセスがフォークし、子プロセスでDNSルックアップを行い、その後親プロセスのIPアドレスを使用する場合、対応するIPマッピングが見つかりません。」このよう構成されたアプリケーションは、ネットワークの問題のように見えるが実際にはそうではない異常な動作を示します。
レイテンシが累積し、信頼性が低下する
この計算こそが、安易なチェーン化に反対する最も強力な論拠である。
レイテンシは累積する。 各ホップは、それ自体の往復時間と処理時間を加算します。50ミリ秒の直接リクエストも、プロキシを1つ経由すればおそらく200ミリ秒になり、2つ経由すれば400ミリ秒になります。対話型利用の場合、これは「実用可能」と「苛立たしい」の分かれ目となります。10万件のリクエストを行うスクレイピングジョブの場合、これは4時間と8時間の差となります。
信頼性は乗算されるが、1未満の数の乗算には一方向しかない。 各ホップが95％の確率で独立して利用可能だと仮定すると：
| ホップ数 | 成功率 |
|---|---|
| 1 | 95% |
| 2 | 90.3% |
| 3 | 85.7% |
| 4 | 81.5% |
個々に信頼性の高いプロキシが3ホップ連鎖しているシステムでは、7回に1回のリクエストが失敗します。 また、チェーン内の障害は単一のホップでの障害よりも深刻です。なぜなら、原因の特定が困難だからです。タイムアウトが発生しても、チェーンが途切れたことは分かりますが、どのリンクで問題が発生したかは分かりません。
帯域幅はホップごとに課金されます。 従量課金制のプロキシを2つ利用している場合、1バイトごとに2回課金されます。 0.79ドル/GBの住宅向けサービスを2つ連結すると、同じデータに対して1.58ドル/GBのコストがかかります。
スループットは最も遅いホップによって制限されます。ホップを追加すればするほど、速度が低下する可能性が高まります。
こうしたコストに見合うだけのメリットがなければなりません。通常、そのようなメリットはありません。
チェイニングによって匿名性は高まるのか？
正直なところ、宣伝されているほどではなく、その効果は完全に運営者次第だ。
チェイニングによって実現されること。 どのホップも、あなたのアドレスと宛先の両方を同時に把握することはありません。ホップAは、あなたが誰であるか、そしてBと通信したことを知っています。ホップBは、宛先と通信したことは知っていますが、発信元が誰であるかは知りません。これは紛れもない特性です。
なぜ、見た目ほど効果が得られないのか。
両方のホップを監視している者にとっては、ホップ間の相関関係を特定するのは容易です。 両端の状況（タイミング、トラフィック量、パターンなど）を把握している観察者は、何も復号することなくそれらを結びつけることができます。これがトラフィック分析であり、匿名性システムの核心的な問題です。2つの商用プロキシでは、この問題に対処できません。
同一の所有者によってチェーンは崩壊する。 両方のホップが同じプロバイダーに属している場合、あるいは同じ基盤ネットワークを再販している場合、その分離は名目上のものに過ぎない。プロキシ市場における再販関係は一般的であり、必ずしも開示されているわけではない。また、同じサプライヤーを共有する2つのブランドを経由するチェーンは、2つのオペレーターではなく、1つのオペレーターによって運営されていることになる。
アプリケーション層によって完全に無効化される。 クッキー、ログイン情報、ブラウザのフィンガープリント、そして入力したあらゆる情報は、ルーティングに関係なくあなたを特定する。ログイン状態のセッションを運ぶ5つのプロキシのチェーンは、身元を特定されるための非常に遅い方法に過ぎない。
支払い記録やアカウント記録が結びつく。 あなたはこれらのサービスを購入したのだ。 記録が残っています。
暗号化は階層化されていません。 単純なプロキシチェーンでは、各ホップでTLSによって保護されていないデータはすべて読み取られてしまいます。チェーン化によって暗号化が追加されるわけではなく、トラフィックを読み取る可能性のある仲介者が追加されるだけです。これは意図された方向とは正反対であり、次のセクションで具体的に取り上げる問題点です。
Torはチェーンを適切に構築している
商用プロキシのスタックには欠けている要素がここには示されているため、リファレンスデザインとして理解しておく価値がある。
Torプロジェクトはこの違いを次のように明確に説明しています。「単一の信頼点および障害点を作り出す通常のプロキシサーバーとは異なり、Torは多層的な暗号化を用いて、トラフィックを複数のリレーを経由してルーティングします。」
トラフィックは少なくとも3つのリレーを通過し、その情報は意図的に分割されています。 最初の中継サーバーは、あるアドレスがTorを使用していることは確認できても、宛先を特定することはできません。中間の中継サーバーは暗号化されたトラフィックを目にするものの、送信者も最終的な宛先も特定できません。出口中継サーバーは送信されるトラフィックを確認できますが、その送信元は確認できません。また、HTTPSの場合、コンテンツではなく宛先サイトのみを確認できます。
これを可能にする3つの設計上の特性がありますが、手動のプロキシチェーンにはそのいずれも備わっていません：
多層暗号化。 各ホップで1層ずつ暗号化が解除されます。ある中継サーバーは、次のホップが受け取る内容を読み取ることはできません。単純なプロキシチェーンでは、各ホップはクライアントから送信されたままのトラフィックをそのまま見ることになります。
回路は、クライアントが公開ディレクトリから選択するものであり、相関する中継サーバーを回避するように設計された経路制約が設けられています。手動のチェーンでは、購入したサービスの中から選択するだけであり、2つのプロバイダーがインフラを共有しているかどうかは判別できません。
中継サーバーは、ボランティアによって独立して運営されています。 商用プロキシプロバイダーは、記録、請求、法的義務を負う企業です。
これらの点から、Torが万能の解決策であるとは言えません。速度が遅く、多くのサイトがTorをブロックしており、大量のデータ収集には不向きです。重要なのは比較の観点です。匿名性が目的であれば、そのために設計されたシステムが役割を果たしますが、商用プロキシを積み重ねても、形は似ていても本質は欠けています。
チェーン全体を台無しにする情報漏洩
チェーンの強度は、その最も弱い経路によって決まります。また、いくつかの経路ではチェーンが完全に迂回されてしまいます。
DNS。 最も一般的なケースです。リゾルバーに直接クエリが送信されると、トラフィックが3ホップを経由する間に、ISPはすべてのホスト名を確認することになります。 SOCKS5を使用する場合は、socks5hという方式を採用し、ホスト名の解決をローカルではなくプロキシ側で行うようにしてください。curlにおけるsocks5://とsocks5h://の違いはまさにこれであり、これはプロキシ設定において最も見落とされがちな詳細です。
WebRTC。 ブラウザでは、プロキシ経路の外側にあるローカルアドレスやパブリックアドレスが露呈する可能性があります。
IPv6。 IPv6接続が利用可能なIPv4専用チェーンでは、一部のトラフィックが直接送信されます。これは目立たず、テストを行わない限り気づかれません。
proxychains下にある静的リンクされたバイナリ。 上記で説明した通り、インターセプトは適用されず、プログラムは警告なしに直接接続します。
インターセプト対象外のプロセス。 システムの更新プログラム、テレメトリ、バックグラウンドサービスなど。これらはそもそもチェーンに含まれていません。
一般的なルール：推測するのではなく、確認すること。 ウェブサイトが外部のIPアドレスを報告していることを確認しても、それは明らかに変化するはずだったことしか確認できません。プロキシのテストに関する当ガイドでは、DNS、WebRTC、IPv6を適切に確認する方法について解説しています。チェーンの場合、失敗する可能性のある箇所が多いため、その検証は重要度が低くなるどころか、むしろ高くなります。
チェーン接続を行う正当な理由
実際の事例であり、いずれも匿名性とは関係ありません。
直接接続できないネットワークにアクセスする場合。 企業のプロキシが唯一の外部への経路であり、特定の宛先にアクセスするために、その先にある別のプロキシが必要となる場合です。 これは「配管」としてのチェーン構成であり、断然最も一般的な正当な用途です。
プロトコルのブリッジング。 アプリケーションがSOCKSのみをサポートしているのに、利用可能なプロキシがHTTPである場合、あるいはその逆の場合です。ローカルプロキシが変換して転送します。これもまた「配管」の一種です。
ローカルホップでの機能追加。 キャッシュ、ロギング、リクエストの書き換え、またはTLS検査のためにローカルプロキシを実行し、そこからアップストリームプロキシへ転送します。これは、最初のホップが何かを隠すためではなく、特定の処理を行うために存在するチェーンであり、開発やテストにおける標準的な手法です。
直接購入できない地理的なルーティング。 時折、必要な出口ロケーションに到達するには、中間サーバーを経由する必要がある場合があります。これは稀なケースですが、チェーンを構築する前に、プロバイダーがそのロケーションを提供しているかどうかを確認する価値があります。
マルチホップの挙動をテストする場合。 複数のプロキシの背後で動作するシステムを構築している場合、その経路をテストすることは正当な行為です。
これらに共通する点に注目してください。チェーンが存在するのはルーティング上の制約によるものであり、ホップ数が多いほど良いと想定されたからではありません。この区別を、ご自身のケースにも当てはめて検討する価値があります。
よくある質問
プロキシをチェーン接続すると、匿名性は高まりますか？
わずかに高まりますが、期待ほどではありません。チェーン接続を行うと、単一のホップがあなたのアドレスと宛先の両方を同時に把握することはなくなります。しかし、トラフィックの相関分析、プロバイダー間の共通所有、あるいはクッキー、ログイン情報、フィンガープリントによるアプリケーション層での特定に対しては、防御にはなりません。 また、単純なプロキシの連鎖では暗号化も追加されません。各ホップでは、TLSで保護されていない情報はすべて見られてしまいます。
プロキシはいくつ連鎖させるべきですか？
正当なルーティング上の理由から、制約上必要な最小限の数――通常は2つ――に留めるべきです。 匿名性を高めるためには、商用プロキシをチェーンでつなぐのは、その数がいくらであっても間違ったアプローチであり、その目的のために設計されたシステムの方が効果的です。ホップが1つ増えるごとに遅延が増加し、障害発生確率が倍増し、帯域幅の料金も倍増します。
proxychainsとは何ですか？また、どのように機能しますか？
動的リンクされたプログラム内のネットワーク関連の libc 関数にフックし、SOCKS4a/5 または HTTP プロキシを経由して接続をリダイレクトする Unix ツールです。正確かつ動的、そしてランダムなチェーン順序を提供します。主な制限は、動的リンクされたプログラムでのみ動作する点です。静的リンクされたバイナリは、警告なしに直接接続されます。
プロキシのチェーン化は遅いですか？
はい、必然的に遅くなります。各ホップごとに往復時間と処理時間が追加されるため、2ホップのチェーンでは、1つのプロキシを使用する場合に比べてコストがおよそ2倍になります。スループットは最も遅いホップによって制限され、各ホップの信頼性が95％の場合、3ホップのチェーンの成功率は約86％となります。
VPNとプロキシをチェーン接続できますか？
技術的には可能ですし、一般的な手法でもあります。実際の効果としては、各当事者が認識する状況にわずかな変化があるものの、通常は遅延が増加します。VPNプロバイダーは依然として接続を認識し、プロキシ運営者もリクエストを認識します。また、どちらの構成もアプリケーション層での識別対策にはなりません。
チェーン化によって、ウェブサイトによる追跡を防ぐことはできますか？
いいえ。追跡は、クッキー、ブラウザのフィンガープリント、アカウントへのログイン、行動パターンなどを通じて行われますが、これらはいずれも、トラフィックが何ホップを経由するかには影響されません。ルーティングによってサイトが記録するアドレスは変わりますが、サイト側がアドレスのみに依存するのをやめたのは、はるか昔のことです。
Torはプロキシチェーンですか？
Torは、手動によるチェーンにはない3つの特性を備えたチェーンです。それは、各中継サーバーが次の中継サーバーが受信した内容を読み取れないようにする多層暗号化、相関する中継サーバーを回避するための制約が設けられた公開ディレクトリからクライアントが経路を選択できる仕組み、そして独立して運営されるボランティアによる中継サーバーです。 Torプロジェクトは、これを「単一の信頼点および障害点を作り出す」通常のプロキシと対比しています。
チェーン内では帯域幅の料金を2回支払うことになるのか？
両方のホップでデータ通信量が課金される場合、答えは「はい」です。すべてのバイトが両方のホップを通過し、双方から課金されるためです。0.79ドル/GBの家庭用サービスが2つある場合、同じデータ量でも1.58ドル/GBの費用がかかります。これは、チェーンを構築する前に、それが実際に問題を解決しているかどうかを確認すべき明確な理由となります。
まとめ
プロキシの連鎖は、プライバシー保護の手法として宣伝されているルーティング技術ですが、この2つは同じものではありません。
ルーティングとして見れば、場合によってはまさに適切な手法である。例えば、企業プロキシを経由してさらに別のプロキシを必要とする宛先へ接続する場合、SOCKSとHTTPの間をブリッジする場合、あるいはキャッシュやログ記録のためにローカルプロキシを前面に配置する場合などだ。こうしたケースでは、制約があるためにチェーンが存在し、追加の遅延はルートを選択する代償となる。
プライバシーの観点から見ると、これは強力なバージョンが存在する手法の弱いバージョンに過ぎません。手動でのチェーン化では暗号化が追加されないため、TLSで保護されていない情報はどのホップでも読み取られてしまいます。また、2つのプロバイダーがインフラを共有しているかどうかも判別できません。トラフィックの相関関係には全く対処できず、クッキー、ログイン情報、フィンガープリントについても何ら対策が講じられていません。これらは、実際に身元が特定される場面なのです。
一方、コストは確実です。レイテンシは累積し、信頼性は低下し、従量制の帯域幅料金は2倍になります。チェーンの導入を検討しているなら、それが具体的にどのルーティング上の制約を解決するのかを問うことが重要です。もし答えが「ホップ数が多いほど安全だ」というものであれば、その計算はあなたにとって不利になります。