「プロキシクライアントソフトウェア」というカテゴリーは、その名称が示唆するよりもはるかに限定された用途を持つものであり、まず最初に検討すべき有用な問いは、そもそもそれが必要かどうかということです。
私たちは Geonode であり、プロキシを販売しています。率直な所見をまず述べると、プロキシクライアントソフトウェアを検索する人の圧倒的多数は、何もインストールする必要がありません。 コードを書いている場合、使用しているHTTPライブラリにはすでにプロキシ引数が用意されています。ブラウザを使用している場合、ブラウザやOSにプロキシ設定があります。curlを実行している場合、-xというオプションがあります。これらはいずれも、追加のソフトウェアやライセンスを必要とせず、障害の原因にもならない、サポートされ、ドキュメント化された方法です。
プロキシクライアントが存在するのは、ある特定の課題を解決するためであり、それを正確に述べておく価値があります：プロキシ設定を持たないアプリケーションに、それでもプロキシを経由して通信させること。 ネットワーク設定のないデスクトップソフトウェア、ゲームクライアント、レガシーツール、環境変数を無視するコマンドラインユーティリティなどです。それがプロキシクライアントの役割です。これらのツールが行うその他の機能はすべて、あくまで利便性を高めるためのものです。
選択する前に知っておくべき2つ目の点は、プロキシを適用できる層が4つあり、それぞれに異なるツールセットと異なる障害モードがあるということです。間違った層を選んでしまうことが、本来必要のないソフトウェアを導入してしまったり、トラフィックが知らぬ間にプロキシを経由せずに流れてしまったりする主な原因です。
そして、ほぼすべてのレイヤーに共通して存在する問題が1つあります。それは、トラフィック自体は正しくルーティングされているにもかかわらず、アクセスしたすべてのホスト名がローカルのリゾルバーに送信されてしまう「DNSリーク」です。この問題については別途セクションを設けています。なぜなら、正しく設定されたプロキシ環境であっても、所有者が期待する動作をしない最も一般的な原因がこれだからです。
以下の価格および技術的な動作に関する情報は、各プロジェクトの公式ドキュメントまたは購入ページに基づいています。
プロキシクライアントが実際に解決する問題
3つの真の問題と、通常は架空の問題が1つあります。
問題1：アプリケーションにプロキシ設定がない
これが真の問題です。多くのデスクトップソフトウェアはネットワーク接続を行いますが、プロキシを設定する手段を提供していません。 システム全体の設定を反映する場合もありますが、独自のネットワークスタックを使用しているため、反映されないことも頻繁にあります。
プロキシクライアントは、アプリケーションが判断を行うレベルよりも下位で、アプリケーションのネットワーク呼び出しをインターセプトすることでこの問題を解決します。アプリケーションはそれに気づくことはありません。これは非常に有用であり、これ以外に解決策はありません。
問題その2：アプリケーションごとに異なるプロキシが必要
あるアプリケーションは英国のアドレス経由、別のアプリケーションは直接接続、さらに別のアプリケーションはSOCKS5のエンドポイント経由、といった具合です。OSのプロキシ設定はグローバルなものであり、このような設定を表現することはできません。しかし、ルールを設定できるプロキシクライアントなら可能です。
地域ごとの挙動をテストする場合や、1台のマシン上で業務用トラフィックと研究用トラフィックを分離する場合など、この機能こそが購入の正当な理由となります。
問題その3：多数のプロキシの管理
ローテーション、プーリング、フェイルオーバー、リトライ、そして実際に何が起こったかの確認。 これらをすべてのスクリプトに組み込むのは手間がかかりますが、ローカルプロキシマネージャーを使えば一度設定するだけで、すべてが localhost を指すようになります。
架空の問題：プライバシー
人々は匿名性を期待してプロキシクライアントを利用します。プロキシクライアントは、相手側から見るとトラフィックの発信元がどこに見えるかを変えるだけです。 それ自体は何も暗号化せず、プロキシ運営者から何も隠さず、自分のマシン上のソフトウェアに対しても何の影響も与えません。
プライバシーが要件であるなら、答えは信頼できるVPNやTorブラウザであり、プロキシクライアントではありません。これらは異なる問題に対する異なるツールであり、この混同は頻繁に起こり、人々に実際の金銭的損失をもたらしています。
プロキシを適用できる4つのレイヤー
この枠組みは、どのツール比較よりも有益な情報を提供するため、表の前に掲載しています。
レイヤー1：コード内
お使いのHTTPライブラリには、プロキシパラメータがあります。requestsにはproxies、curlには-xがあり、ほとんどの言語に同等の機能があります。
利点： 完全な精度、リクエストごとの制御、追加のソフトウェアが不要、情報漏洩のリスクがなく、将来コードを読む人が確認できるよう、プロキシがコード内に明示されている。
制限： 自身が発行するリクエストのみを対象とする。
適用可能な場合は常にこれを使用してください。 リクエストを行うコードを記述している場合は、ここで読み進める必要はありません。この記事の残りの部分は、あなたには関係のない問題について書かれています。
第2層：アプリケーション内
ブラウザ、ダウンロードマネージャー、および多くの開発者ツールには、独自のプロキシ設定があります。 ブラウザ拡張機能は、サイトごとのルールによってこれを拡張します。
利点： 特権のあるソフトウェアが不要、変更が容易、1つのアプリケーションに限定される。
制限： そのアプリケーションのみ、かつ設定がある場合に限られます。
第3層：システム全体
Windows、macOS、およびほとんどのLinuxデスクトップには、システムプロキシ設定があります。適切に動作するアプリケーションは、この設定を参照します。
利点： 組み込み機能であり、無料で、ソフトウェアをインストールする必要がありません。
制限（これは重大です）： アプリケーションは、この設定に従う義務がありません。 多くのアプリケーションは独自のネットワーク処理を行い、システム設定を完全に無視します。これが、プロキシ経由となるべきトラフィックが実際にはそうならない理由であり、重要な用途においてこの方法が信頼性に欠ける理由でもあります。推測するのではなく、必ず確認してください。
第4層：インターセプト
ここがプロキシクライアントソフトウェアの活躍の場です。 このツールはアプリケーションの下層でネットワーク呼び出しを傍受するため、アプリケーションが何を意図していたかは関係ありません。接続はそれにかかわらずリダイレクトされます。
ProxifierはWindowsおよびmacOS上でドライバーを使用してこれを実現します。proxychainsはUnix系システム上でライブラリ呼び出しをフックすることでこれを実現します。両者とも異なる手法で同じ結果を達成しています。
利点： プロキシ機能を全くサポートしていないアプリケーションでも動作する；アプリケーションごとのルールをサポートする。
制限： 特権が必要なインストールまたは特定の起動方法が必要であり、後述する実際のエッジケースが存在し、それ自体が失敗する可能性のあるコンポーネントが追加される。
選択方法
リストを下にたどり、動作する最初のレイヤーで停止してください。 コード、次にアプリケーション、次にシステム、そしてインターセプションの順です。下へ進むごとに機能は増えますが、障害モードも増えます。ニーズの大部分は、最初の2つのレイヤーで満たされます。
ツールの比較
| ツール | レイヤー | 対応プラットフォーム | 価格 | 適した用途 |
|---|
| お使いのHTTPライブラリ | コード | すべて | 無料 | 自分で作成したあらゆるもの |
curl -x | コード | すべて | 無料 | スクリプトや単発のリクエスト |
| ブラウザの設定／拡張機能 | アプリケーション | すべて | 無料 | ブラウジング、サイトごとのルール |
| システムのプロキシ設定 | システム | すべて | 無料 | 正常に動作するアプリケーションのみ |
| Proxifier | インターセプション | Windows、macOS | $39.95 永久ライセンス | プロキシに対応していないアプリケーション |
| proxychains-ng | インターセプション | Linux、BSD、macOS、Haiku | 無料、GPL-2.0 | Unix上のコマンドラインツール |
| Bright Data Proxy Manager | ローカルマネージャー | Windows、Linux、macOS | 無料、オープンソース | ローテーション、プーリング、ロギング |
表の読み方
最初の4行は無料で、ほとんどの要件をカバーしています。 これは単なる修辞的な表現ではありません。残りの項目を検討する前に、まずはこれらをしっかりと確認してください。
Proxifierは、ここで紹介する中で唯一の主要な有料製品であり、洗練されたグラフィカルインターフェースを備えた唯一のツールです。サブスクリプション形式ではなく永久ライセンスで39.95ドルという価格は、誰にとっても1時間の労働時間と比較すれば安価であり、頑固なWindowsやmacOSアプリケーションのルーティングという特定の用途においては、実質的な競合製品は存在しません。
proxychains-ngはUnix版に相当するもので、GPL-2.0の下で無料で利用できますが、その仕組みは大きく異なり、不具合が発生するケースも大きく異なります。
Bright DataのProxy Managerは、当社の競合他社による真に有用な推奨ツールであり、特筆に値します。これはオープンソースで、3つのデスクトッププラットフォームすべてで動作し、Bright Data独自のネットワーク向けに設計されていますが、--ext_proxiesオプションを通じて外部のプロキシベンダーもサポートしています。 つまり、当社を含め、どのプロバイダーのプロキシでも動作します。Webインターフェースを通じて、接続プーリング、ロードバランシング、ローテーション、SSL解析、ロギングを処理し、Dockerにも対応しています。
競合他社のツールを紹介するのは、それが当社の顧客が抱える問題に対する最良の無料ソリューションだからです。お客様を当社のエコシステム内に留めるために、性能の劣る代替ツールを開発することは、関係者全員の時間の無駄になります。
Proxifier とデスクトップ環境
商用版であり、Windows や macOS のアプリケーションにプロキシ設定がそもそもない場合に利用すべき選択肢です。
機能
Proxifier は、ネットワーク層で接続を傍受し、ユーザーが定義したルールに従って接続をリダイレクトするドライバーをインストールします。 接続を行うアプリケーションには一切問い合わせを行わず、アプリケーション側の協力も必要ありません。
この「ルール」こそが、本製品を購入する最大の理由です。アプリケーション単位、ターゲットホスト単位、ポート単位、あるいはそれらの組み合わせでルーティングを設定できます。あるプログラムはプロキシ経由、別のプログラムは直接接続、さらに別のプログラムは完全にブロックするといった設定も可能です。これは、システム全体の設定では実現できない機能です。
価格
1ライセンスあたり39.95ドルで、Windows版Proxifier Standard Edition、Windows版Portable Edition、またはMac版Proxifierのいずれかを選択できます。これらは永久ライセンスであり、将来のマイナーバージョンアップデートがすべて含まれており、サブスクリプションではありません。また、ボリュームディスカウントは最大40%まで適用されます。 30日間の返金保証があります（現在の価格）。
サブスクリプションが主流のカテゴリーにおいて、1回限りの購入という点は、特筆すべき珍しいケースです。
ポータブル版
制約条件が変わるため、理解しておく価値があります。スタンダード版はドライバーをインストールするため、管理者権限が必要です。 ポータブル版は、ドライバーのインストールが不可能な場合や、インストールを望まない状況を想定しています。
管理者権限を持たないマシンで作業する場合は、購入前にどちらのエディションが適しているかを確認してください。ライセンスはそれぞれ別個に提供されています。
信頼する前に確認すべきこと
トラフィックが実際に通過しているか。 アプリケーションを開き、ネットワーク関連の操作を行わせて、Proxifier独自の接続ログにその接続が記録されていることを確認してください。通常とは異なる仕組みを使用しているアプリケーションでもすり抜けてしまう可能性がありますが、ログを見ればすぐにわかります。
DNSが希望通りに処理されているか。 これについては後述のセクションで詳しく説明しますが、この設定を見落としがちなのです。
ルールが正しい順序で並んでいるか。 ルールシステムは順序通りに評価されるため、上の方に広範囲なルールがあると、本来は後続のより具体的なルールで捕捉すべきトラフィックが、知らぬ間にそのルールに飲み込まれてしまいます。これは最もよくある設定ミスです。
proxychains と Linux の場合
Unix ならではの無料の解決策であり、何が機能しないかを正確に説明してくれるため、その仕組みを理解しておく価値があります。
仕組み
proxychains-ng は、SOCKS4a、SOCKS5、または HTTP プロキシを経由して接続をリダイレクトします。そのドキュメントによると、このツールは「プリロードされた DLL を通じて、動的リンクされたプログラム内のネットワーク関連の libc 関数をフックし、1 つまたは複数の SOCKS/HTTP プロキシを経由して接続をリダイレクトする」とのことです。
その仕組みは「LD_PRELOAD」です。ライブラリがプログラムの通常のライブラリよりも先に読み込まれ、システム側のソケット関数の代わりに、そのライブラリが提供する関数が使用されます。プログラムは標準関数だと思い込んで呼び出しを行いますが、実際にはproxychainsが応答します。
グローバルに設定するのではなく、コマンドを介して実行します：
proxychains4 curl https://example.com
proxychains4 nmap -sT target
GPL-2.0ライセンスで提供されており、Linux、BSD、macOS、Haikuで動作します。
公式ドキュメントに記載されている制限事項
これらはプロジェクト側で文書化されており、一見したよりも重大な影響を及ぼします。
静的リンクされたバイナリは動作しません。 この技術には動的リンクが必要です。 静的にリンクされたプログラムには、事前に読み込むべきライブラリが存在しないため、エラーも警告も出さずに、プロキシを素通りして直接接続してしまいます。
TCPのみ対応。 「TCPのみをサポートしています（UDP/ICMPなどは非対応）」。UDPを使用する通信はプロキシ経由になりません。 これには現代のネットワーク通信の多くが含まれており、その処理は黙って行われます。
PythonとPerlには特有の問題があります。 ドキュメントには、「glibcのダイナミックリンカーには、dlopen()で読み込まれたモジュールが同じdlsymフックの対象となるのを妨げるバグまたはセキュリティ機能がある」と記載されており、これはこれらの言語の拡張モジュールに影響を与えます。 Pythonスクリプトは自身のリクエストをプロキシできる一方で、そのスクリプトが読み込むコンパイル済み拡張モジュールはプロキシされません。
macOSのシステム整合性保護（SIP）は、 10.11以降のシステムアプリケーションに対してこれをブロックします。SIPはまさにこの種のインジェクションを防ぐために存在しており、その役割を果たしています。
バックグラウンドプロセスを生成するスクリプトやデーモンは失敗する可能性があります。
プロジェクト独自のREADMEでは、本格的に使用する前に徹底的にテストするよう勧告しています。これは異例なほど率直なアドバイスであり、文字通り受け止めるべきです。
これらの制限に見られるパターン
そのすべてが静かに、かつオープンに失敗します。 接続はブロックされず、直接接続されます。トラフィックは実際のアドレスから送信され、そのことを示す兆候は一切ありません。
したがって、推測するのではなく、明示的に確認してください。proxychains 経由でアドレス報告を行うエンドポイントに対してコマンドを実行し、使用を予定している各アプリケーションについて、返されるアドレスがプロキシのものであることを確認してください。一般的に、一度だけ確認するのではなく、各アプリケーションごとに確認する必要があります。
プロキシマネージャー：ローテーションとプーリング
これは、リクエストを傍受するツールとは異なる役割ですが、しばしばそれらと混同されます。
プロキシマネージャーはローカルで実行され、単一のプロキシエンドポイントとして機能します。アプリケーションは localhost を指定します。その背後で、プロキシマネージャーはリクエストをアップストリームプロキシのプールに分散させ、プロキシをローテーションさせ、失敗した場合は再試行を行い、発生した事象をログに記録します。
導入する価値がある理由
ローテーションのロジックが一箇所に集約されます。 各スクリプトが独自のプール処理を実装するのではなく、すべてが1つのローカルエンドポイントを指し、マネージャーが処理を決定します。
フェイルオーバーは、コードが認識することなく行われます。 ダウンしたアップストリームプロキシに対しては、別のプロキシで再試行が行われます。
可観測性が得られます。 どのリクエストが成功し、どれが失敗したか、所要時間はどれくらいか、どの場所にどれだけの帯域幅が消費されたかなどが把握できます。プロキシの請求額が予想外に高額になった際、これがなかったことを最も後悔する点です。
認証情報は1つの設定ファイルにまとめられます。十数個のスクリプトにコピーされるよりも、整理されやすく、安全性も高まります。
実用的な選択肢
Bright DataのProxy Managerはオープンソースで、Windows、Linux、macOS上で動作します。接続プール、ロードバランシング、自動ローテーション、SOCKS5のサポート、SSL解析、Web設定インターフェース、Dockerイメージなどの機能を提供しています。
Bright Dataのネットワーク向けに構築されていますが、「--ext_proxies」オプションを通じて外部プロキシベンダーにも対応しているため、どのプロバイダーのプロキシでも問題なく動作します。当社のプロキシを利用しており、ローテーションやロギング機能を備えた管理されたローカルエンドポイントが必要な場合は、これを利用すれば無料で目的を果たせます。
必要ない場合
1つのスクリプトから1日数百件のリクエストを送信する程度であれば、マネージャーは「まだ発生していない問題」に対するインフラに過ぎません。ローテーションが重要になるのは、アドレスごとのレート制限が制約となる場合です。可観測性が重要になるのは、請求額や障害率が調査すべき水準に達した場合です。これらの閾値を下回る場合、HTTPクライアントにプロキシ引数を指定するだけで十分です。
あらゆるレイヤーをすり抜けるDNSリーク
正しく設定されたプロキシ環境が、所有者が想定している通りの動作をしない最も一般的な原因。
問題点
お使いのマシンが example.com
に接続するには、まずその名前を IP アドレスに変換する必要があります。その解決が ローカル で行われる場合、トラフィック自体はプロキシを経由しているにもかかわらず、DNS リゾルバー（通常はインターネットプロバイダやネットワーク管理者）は、あなたがアクセスしたすべてのホスト名を把握してしまいます。
通信経路を設定し、宛先を通知してしまったことになります。
現れる場所
curl や SOCKS を使用するあらゆるツールで。 違いはスキームにあります。socks5://
の場合、curl はプロキシに接続する前にローカルでホスト名を解決します。socks5h://
の場合、ホスト名はプロキシに送信され、そこで解決されます。たった1文字の違いです。
curl -x socks5://proxy.example.com:1080 https://example.com # leaks the lookup
curl -x socks5h://proxy.example.com:1080 https://example.com # does not
プロキシクライアントソフトウェアにおいて。 Proxifierには、プロキシ経由でのDNS処理に関する明示的な設定があります。これは必ずしもデフォルト設定ではなく、見落としがちです。
proxychainsにおいて。 設定ファイルでDNSの処理方法を制御しており、正しい設定はバージョンやプロキシの種類によって異なります。
ブラウザの場合。 特定の設定を変更しない限り、SOCKSプロキシが設定されていても、ローカルで解決してしまうものがあります。
プライバシー以外の観点から重要な理由
これは単なる情報漏洩の問題だけではありません。 ローカルで解決されたホスト名は、まったく間違ったアドレスを返す可能性があります。 地域ごとに異なるインフラを提供するサイトは、場所によって解決結果が異なります。ドイツ経由でプロキシ接続しているにもかかわらず、英国からDNS解決が行われている場合、ドイツのアドレスから英国のエンドポイントに接続することになります。これは、本来の目的から外れているだけでなく、異常に目立つ組み合わせです。
これは、地理的なテストの結果が現実と一致しない原因として頻繁に発生し、実際に混乱を招くものです。
確認方法
どのレイヤーを使用している場合でも、そのレイヤーを介してDNSリークテストを実行し、報告されたリゾルバーが自身のネットワークではなく、プロキシのネットワークに属していることを確認してください。所要時間は30秒で、この記事全体を通じて最も価値のある検証手順です。
プロキシクライアントが必要ない場合
私たちの意図に反し、またこの記事のテーマからも外れますが、このケースは読者の大半に当てはまるでしょう。
あなたがコードを書いている場合。 プロキシをHTTPライブラリに渡してください。インストールも不要、情報漏洩の心配もなく、ライセンスも不要で、次にコードを読む人にもその設定が明確になります。
アプリケーションにプロキシ設定がある場合。 それを利用してください。その上にインターセプト層を追加すると、設定が間違っている可能性がある箇所が2つになってしまいます。
プライバシーを重視する場合。 信頼できるVPNやTorブラウザを使用してください。プロキシクライアントはトラフィックを暗号化せず、プロキシ運営者から何も隠すことはできません。
ブラウザでウェブサイトのブロックを解除したい場合。 ブラウザ拡張機能やブラウザ自体の設定で対応できます。そのためにシステムドライバをインストールするのは、見合いが合いません。
リクエストの数がごくわずかである場合。 レート制限や検知は、トラフィックの量やパターンに基づいて行われます。1日50件のリクエスト程度なら、特別なインフラは不要です。
アプリケーションがシステムのプロキシ設定を尊重している場合。 まず確認してください。1分もかからず、プロジェクトを中止できるかもしれません。
サーバー上で実行しており、環境を制御できる場合。 環境変数、コンテナレベルのネットワーク設定、または適切に構成されたルーティングは、インジェクション層よりもすっきりとした解決策であり、前述のような静かな失敗も起こりません。
本当に必要な場合
プロキシをサポートしておらず、システム設定も無視するアプリケーション。 このカテゴリーが存在する唯一の正当な理由です。
アプリケーションごとのルーティングルール。 1台のマシン上で、プログラムごとに異なる宛先を設定する場合。
多数の上流プロキシからなるプール全体でのローテーションと可観測性を、大規模に実現する場合。
プロキシオプションを持たないUnix上のコマンドラインツール — proxychains。ただし、そのドキュメントに記載された制限をしっかりと念頭に置く必要があります。
これら以外のケースでは、よりシンプルなレイヤーの方が良い解決策であり、しかも無料です。
よくある質問
プロキシクライアントソフトウェアとは何ですか？
他のアプリケーションのネットワークトラフィックをプロキシ経由でルーティングするソフトウェアです。通常、アプリケーションが接続方法を決定するレベルよりも下位で接続をインターセプトします。その目的は、独自のプロキシ設定を持たないアプリケーションをプロキシ経由で動作させることです。
プロキシクライアントは必要ですか？
通常は必要ありません。コードを記述する場合は、HTTPライブラリにプロキシを渡してください。アプリケーションにプロキシ設定がある場合は、それを使用してください。プロキシクライアントは、プロキシをサポートしておらず、システム全体の設定も無視してしまうアプリケーションという特定のケースのためのものです。
Windows向けの最適なプロキシクライアントはどれですか？
Proxifierは定評のある商用製品で、アプリケーションごとのルーティングルールを備えた永久ライセンスが39.95ドルです。接続の傍受ではなく、プロキシのプールやローテーションを行う場合は、Bright Dataのオープンソース製品であるProxy ManagerがWindowsで動作し、外部のプロキシプロバイダと連携できます。
Linux用の無料プロキシクライアントはありますか？
GPL-2.0ライセンスの「proxychains-ng」があります。これはLD_PRELOADを介してlibcのネットワーク機能にフックします。ドキュメントに記載されている制限事項に注意してください：TCPのみ対応、静的バイナリ非対応、PythonおよびPerlの拡張モジュールとの互換性の問題、そしてmacOSのシステム整合性保護（SIP）によりシステムアプリケーションでの使用がブロックされる点です。
なぜトラフィックがプロキシを経由しないのですか？
多くの場合、アプリケーションがシステムのプロキシ設定を無視し、独自のネットワーク接続を使用しているためです。特に proxychains の場合、静的にリンクされたバイナリや UDP トラフィックは、プロキシを完全に、かつ気付かれないままバイパスしてしまいます。推測するのではなく、アドレスを報告するエンドポイントで確認してください。
DNSリークとは何ですか？また、それを防ぐにはどうすればよいですか？
トラフィックはプロキシを経由しますが、ホスト名の解決はローカルで行われるため、自身のリゾルバーがアクセスしたすべてのサイトを把握してしまいます。 これを修正するには、プロキシにホスト名の解決を行わせます。curlでは socks5:// ではなく socks5h:// を使用し、Proxifierやproxychainsで同等のオプションを有効にして、DNSリークチェッカーでテストしてください。
プロキシクライアントはトラフィックを暗号化しますか？
いいえ。プロキシは接続を中継するだけで、暗号化を追加するわけではありません。HTTPSはユーザーと宛先間の通信内容を保護しますが、プロキシの運営者はユーザーがどのホストに接続しているかを確認できます。デバイスから外部への通信を暗号化する必要がある場合は、VPNを利用してください。
Proxifierとproxychains、どちらを選ぶべきか？
プラットフォームも仕組みも異なります。ProxifierはWindowsおよびmacOS向けで、ドライバーを使用し、グラフィカルなルールエディタを備え、価格は39.95ドルです。proxychainsはUnix向けで、ライブラリのプリロードを使用し、無料ですが、ドキュメントに記載されている不具合があり、エラーが黙って発生することがあります。どちらが優れているというわけではなく、それぞれ異なるシステムに適しています。
まとめ
プロキシクライアントソフトウェアは、その名称が示唆するよりも用途が限定的です。そのため、ソフトウェアを選ぶ前に最も重要なのは、問題の根本が実際にどのレイヤーにあるのかを特定することです。
各レイヤーを順に確認し、最初に機能するレイヤーで止めてください。 まずコードレベル、次にアプリケーションレベル、その次はシステム全体、そしてインターセプションです。各ステップで機能は増えますが、失敗する可能性も増えます。そして、要件の大部分は最初の2つのレイヤーで満たされます――しかも、何もインストールせずに、無料で実現できます。
真にインターセプト層に到達した場合、選択は主にプラットフォームによって決まります。WindowsおよびmacOS向けのProxifierは、永久ライセンスで39.95ドルで、組み込みの設定では表現できないアプリケーションごとのルールを設定できます。 Unix向けのproxychains-ngは、無料かつGPL-2.0ライセンスですが、覚えておくべき制限があります：TCPのみ対応、静的バイナリなし、PythonおよびPerl拡張機能との相性が悪いこと、そして最新のmacOSではシステム整合性保護（SIP）によってブロックされることです。
これらの制限事項の「パターン」は、そのリストそのものよりも重要です。 これらはすべて「失敗しても接続を許可し、何も通知しない」 — 接続は拒否されず、単にあなたの実際のアドレスから直接送信されるだけで、そのことを知らせるものは何もない。一度設定してそのまま信頼するのではなく、ルーティングする予定のすべてのアプリケーションについて、アドレス報告エンドポイントで検証を行うこと。
次に、DNSを確認する。 プロキシ経由でトラフィックが流れる一方で、ホスト名の解決がローカルのリゾルバーで行われるという設定は、この分野で最も一般的な「半ば機能している」設定ですが、これは情報漏洩の問題であると同時に正確性の問題でもあります。ローカルで解決されたホスト名が、地域的に誤ったアドレスを返す可能性があるからです。socks5:// ではなく socks5h:// を利用し、使用しているツールで DNS オプションを有効にし、30 秒間のリークテストを行ってください。
また、プロキシのプールを運用している場合は、Bright Dataのオープンソースツール「Proxy Manager」がローテーション、フェイルオーバー、ログ記録を処理し、3つのプラットフォームすべてで動作し、外部プロバイダーとも連携します。これは競合他社のツールですが、この問題に対する最良の無料ソリューションであり、そのことをはっきり述べておく価値があると思いました。
