アプリケーションはプロキシを無視します：トラフィックをどのようにラップするか

```html

Windowsの設定にプロキシを記入し、プログラムを再起動したのに、依然として自宅のIPを使用している場合や、逆にブラウザがプロキシを通過しているのに、デスクトップクライアントが実際のアドレスを表示し続けている場合があります。これはプロキシのバグでもなく、クレデンシャルの問題でもありません。これは、オペレーティングシステムが「システムプロキシ」を扱う方法の根本的な特性です：それは強制するのではなく、単に提案するだけです。

以下は、特定のアプリケーションをSOCKS5を通じて動作させるための4つの実用的な方法であり、それぞれの制限や設定が崩れる原因について説明します。

システムプロキシが機能しない理由：短い技術的真実

Windowsには「システムプロキシ」が1つだけ存在するわけではありません。少なくとも2つの独立した設定セットがあります。最初はWinINETです：これは「設定 → ネットワークとインターネット → プロキシサーバー」で修正するものです。Internet Explorer/Edge、.NETの一部のアプリケーション、そして標準のユーザーHTTPスタックを使用するすべてのものがこれを読み取ります。2つ目はWinHTTPで、システムサービスやバックグラウンドプロセスが使用します。そして重要なのは、WinHTTPはWinINETの設定を明示的にインポートしない限り使用しないということです。これはnetsh winhttp import proxy source=ieというコマンドで行われ、Microsoftのドキュメントからの重要な詳細として、このコマンドは現在の設定のスナップショットを取得します。後で設定を変更した場合、スナップショットは自動的に更新されず、コマンドを再実行する必要があります。

しかし、インポートしても主要な問題カテゴリからは救われません。非常に多くのプログラムはシステムに問い合わせることなく、独自のネットワークスタックを使用し、TCPソケットを直接開きます。これは多くのソーシャルメディアやメッセンジャーのデスクトップクライアント、ゲームランチャー、トレント、一部のElectronアプリケーション、コンパイルされたGoおよびRustユーティリティに当てはまります。これらにとっては、OSの設定での「プロキシ」という行は単なる概念として存在しません。

したがって、ルールはこうです：アプリケーションにプロキシのためのフィールドがない場合、唯一の信頼できる方法は、アプリケーションの下のレベルでそのトラフィックをキャッチすることです。方法は4つのクラスに分かれ、価格、信頼性、必要な権限が根本的に異なります。

ステップ0：問題が本当にこれであることを確認してください

アプリケーションを起動し、表示されるIPを確認します（アカウントのプロフィール、サービスの管理ページ、任意の組み込みインジケーター）。
同時に、同じプロキシを通じてブラウザを開き、アドレスを照合します。異なるIP = アプリケーションがシステム設定を無視しています。
プログラムに独自のプロキシ設定があるか確認します。これらは「ネットワーク」、「接続」または設定ファイルに隠れていることがよくあります。ネイティブサポートは常に外部キャッチよりも優れています：層が少なく、故障が少なくなります。
DNSを別途確認します。アプリケーションがローカルで名前を解決し、トラフィックがプロキシを通過している場合、実際のプロバイダーはあなたがどこに行っているかを依然として見ることができます。

方法1. Proxifier — WindowsおよびmacOSの商業標準

Proxifierはアプリケーションの接続をキャッチし、指定されたプロキシにルールに従って転送します：「このexeはプロキシAを通じて、あれはプロキシBを通じて、残りは直接」と設定できます。ポートや宛先アドレスで分けたり、複数のプロキシのチェーンを構築したりできます。

執筆時点での最新バージョン：Windows用の4.14（2025年4月23日リリース）およびmacOS用の3.15（2025年9月18日）。ライセンスは$39.95で1ライセンス、単発購入、無期限で、無料のマイナーアップデートが含まれています；31日間のフル機能トライアル、2ライセンス以上のボリュームディスカウント、30日間の返金があります。

設定の実践：

Proxy Servers → Add: アドレス、ポート、SOCKS5プロトコル、クレデンシャルを指定します。Checkをクリック — テストはルールを作成する前に成功する必要があります。そうでないと、2つの問題を同時にデバッグすることになります。
Proxification Rules → Add: Applicationsで特定の実行ファイルを選択し、Actionでプロキシを選択します。
DefaultルールはDirectのままにしておきます。そうしないと、全てのマシンがトンネルに入ってしまいます。これは初心者が最もよく犯す間違いです：Default → ProxyはOSのアップデーターやアンチウイルス、そしてあなたがギガバイト単位で支払う余計なトラフィックをトンネルに入れてしまいます。
Connectionsタブをリアルタイムで監視します：どの接続がプロキシを通過し、どれが直接であるかがわかります。

強みは成熟度、安定したルール、明確な診断です。弱点は有料であり、攻撃的なアンチチートシステムではドライバキャッチが検出される可能性があることです。

方法2. ProxiFyre — UDPサポート付きのWindows向け無料代替

予算がゼロで、プラットフォームがWindowsの場合、オープンプロジェクトのProxiFyre（ライセンスAGPL-3.0）があります。これはNDISAPI/Windows Packet Filterに基づいており、つまりパケットフィルタリングドライバーレベルで動作し、しばしば不足している機能を持っています：TCPだけでなく、UDPも各アプリケーションごとに透過的にラップすることができます。これはUDPやQUIC上で動作するすべてのもの、音声チャネル、ゲームクライアント、現代のブラウザ接続の一部にとって重要です。

新しいバージョンの便利な点：IPv6のサポートはv2.3.0で追加され、SOCKS5-over-TLSはv2.4.0で追加され、アプリケーション用の例外ルールと他のすべてのためのcatch-allがあります。要件：インストールされたWindows Packet Filter、Visual Studioのランタイムライブラリ、および管理者権限。

設定は、アプリケーションのリストとそれに関連付けられたSOCKS5エンドポイントを含む設定ファイルを通じて行われます。Proxifierよりも参入障壁は高いですが、料金は発生せず、UDPを取得できます。

方法3. proxychains-ng — Linux向けの迅速なオプション、条件付き

Unixシステムのクラシック：proxychains4 curl https://example.com。メカニズムはLD_PRELOADです：ライブラリが動的にリンクされたプログラム内のソケット呼び出しを置き換え、SOCKSに導きます。

作業プロセスを構築する前に知っておくべき制限：

TCPのみ。 UDPおよびICMPは全くラップされません — proxychainsを通じてpingを実行しても、意味のあるものは確認できません。
動的にリンクされたバイナリのみ。 静的にビルドされたユーティリティ（Goの典型的な状況）はLD_PRELOADを静かに無視し、トラフィックは直接流れ、あなたはそれに気づかないでしょう。
macOSではSIPに制約されます。 システムバイナリにライブラリをロードすることがSystem Integrity Protectionによってブロックされます：proxychains4 ssh user@hostは機能しません。作業回避策は、バイナリを自分のディレクトリにコピーすることです（cp /usr/bin/ssh ~/.local/bin/）そしてコピーを実行します。便利さのためにSIPを無効にすることはお勧めしません：1つのユーティリティのためにシステム全体の保護を弱めることになります。

特定のタスク（curl、pythonスクリプト、コンソールユーティリティ）には、proxychainsが最も迅速な方法であり、1つのコマンドでインストールでき、rootを必要としません。

方法4. TUNモード：仮想インターフェースレベルでのキャッチ

最も汎用的なクラスのソリューションです。仮想ネットワークインターフェースが作成され、システムのルートがそれにラップされ、ユーザーのTCP/IPスタックがパケットを解析し、SOCKS5を通じて外部に出力します。これにはtun2socks（gVisorスタックを使用し、TCPとUDPをサポートし、すべてのプラットフォームに対応）やsing-boxがTUNモードで動作します。

LD_PRELOADに対する重要な利点は、静的バイナリや独自のスタックを持つアプリケーションを含むすべてをキャッチすることです。sing-boxにはプロセスごとのルーティングもあり、process_name、process_path、およびprocess_path_regexフィールドがあり、真のper-appルールを提供します；ドキュメントによると、これはLinux、Windows、macOSでサポートされています（モバイルプラットフォームでは、ルールはパッケージ名またはバンドルIDで設定されます）。

ほとんどの人がつまずく2つの罠：

ルーティングループ。 すべてのトラフィックがTUNに送信される場合、SOCKS5サーバーへの接続もTUNに送信しようとします — トンネルは自分自身をラップし始めます。これは、物理インターフェースを介してプロキシのIPへの明示的な例外ルートで修正できます。これはsing-boxの設定でよく見られる問題です。
権限。 TUNインターフェースの作成とルーティングテーブルの修正にはroot/管理者権限が必要です。企業のマシンでは、ポリシーによりこれが利用できない場合があります。

Linuxには、redsocks — iptablesのルールを介してローカルポートにリダイレクトするキャッチ（Linux専用、rootが必要）や、sshuttleがあり、通常のSSHアクセスの上にVPNのようなルーティングを構築し、「TCP上のTCP」という古典的な問題を回避します。

最も壊れやすいもの

DNSリーク。 正しく設定されたSOCKS5であっても、アプリケーションがローカルでドメインを解決することがあります。解決がプロキシ側に行っていることを確認し、プロバイダーに行っていないことを確認してください。
SOCKS4が選択された。 SOCKS4は基本的にUDPをサポートせず、一部の実装ではドメイン名を送信できません。任意のトラフィックをキャッチするには、SOCKS5のみを使用してください — なぜそうなのかは、SOCKS5の動作原理についての資料で詳しく説明されています。
HTTPプロキシがSOCKSの代わりに選択された。 HTTPプロキシはHTTPをプロキシし、CONNECTを介してTLS接続を行うことができます。ゲームクライアントやメッセンジャーの任意のTCPトラフィックはラップされません。
全トラフィックに対するDefaultルール。 マシン全体をラップすると、更新やテレメトリーのために居住者プールのトラフィックを消費してしまいます。
設定後の確認がない。 常にアプリケーションからの実際の出力IPを再確認してください。ブラウザではなく、アプリケーション自体から確認してください。

どのタイプのプロキシをキャッチに選ぶべきか

技術的には、キャッチは任意のSOCKS5エンドポイントで機能しますが、タイプの選択があなたのシナリオが結果に至るかどうかを決定します。

居住者 — アプリケーションがIPの評判を評価するサービスと連携している場合：ソーシャルネットワーク、マーケットプレイス、広告ダッシュボード、支払いフォーム。データセンターのアドレスはほぼ瞬時に認識されます。SOCKS5とstickyセッションをサポートする居住者プロキシが適しています — これは重要です。なぜなら、アクティブなセッションの途中でIPが変更されることは、最初から「他人」のIPを使用するよりもアンチフロードにとって悪化するからです。
データセンター — 厳しいアンチフロードがない技術的なタスクのため：APIへのアクセス、内部サービス、テストスタンド、速度と安定性が重要であり、「居住者」アドレスの見た目が重要でないすべてのもの。ここでは、データセンターのプロキシが最良のpingと予測可能性を提供します。
モバイル — アプリケーションが本質的にモバイルである場合（エミュレーター、ソーシャルネットワークのクライアント）で、プラットフォームの最大の信頼が必要です。

別途：アプリケーションレベルでのキャッチはVPNではなく、一方を他方に置き換えるべきではありません。全マシンのために1つの安全なチャネルが必要な場合、異なるプログラムのために異なるIPが必要な場合、アプローチの比較はWireGuard対プロキシの分析にあります。

1分で方法を選ぶには

アプリケーションが独自のプロキシ設定を持っている → それを使用し、何もキャッチしないでください。
Windows、今日結果が必要、予算がある → Proxifier。
Windows、UDPが必要で無料 → ProxiFyre。
Linux、コンソールユーティリティでの単発タスク → proxychains-ng。
静的バイナリ、ゲーム、またはすべてをper-appルールでキャッチする必要がある → TUNモード（sing-box、tun2socks）、プロキシへの例外ルートを忘れずに。

主な結論はシンプルです：「プロキシが機能しない」というのは、10回中9回は「プロキシがそのレベルで設定されていない」ことを意味します。システム設定はアプリケーションへの丁寧なリクエストであり、ドライバーレベル、LD_PRELOAD、またはTUNインターフェースでのキャッチは強制です。正しいレイヤーを選択し、アプリケーションからの実際の出力IPを確認し、DNSを忘れずに確認してください — そうすれば、問題は一度で解決し、プログラムの更新ごとに再発することはありません。