アプリケーションはプロキシBを指していますが、プロキシA向けに設定されたラッパー経由で起動されています。ウェブサイトにはどの出口が見えるのでしょうか。答えは、ラッパーがどの接続を傍受するかによって変わります。

単純な入れ子の構成では、アプリケーションはまずBへの接続を試みます。ラッパーがその接続を傍受し、A経由で運びます。次にアプリケーションは結果として得られたストリーム上でBのプロキシプロトコルを話し、Bが最終的なウェブサイトへの接続を行います。

application → wrapper proxy A → application proxy B → website

ウェブサイトにはBの最終的な外向き接続が見えます。BにはA経由で到着する接続が見えます。これは、ラッパーがアプリケーション自身のプロキシ設定を黙って上書きする場合とは異なります。

単純な図には条件がある

バイパス規則、サポートされていないソケット呼び出し、既存のプロセス、各製品の傍受モデルによって経路は変わり得ます。一部のラッパーは自身のプロキシや選択した宛先を除外できます。すべてのツールの組み合わせが同じように動作するとは考えないでください。

proxychains-ngの説明は、その傍受方式と制限を解説しています。ネイティブのプロキシサポートを使うプログラムも、そのプロキシへのネットワーク接続を行っており、これが傍受の候補の一つです。

認証されていない公開エンドポイントを意図的にチェーンする場合、無料プロキシリストは各ツールにプロトコルが合致しなければならない候補を提供します。予期しない出口については、3つのアドレスを別々に記録してください。アプリケーションが選んだエンドポイント、ラッパーが選んだエンドポイント、そしてウェブサイトが見る結果です。ブラウザの設定だけを見ると中間層を見落とします。

意図した動作を確立する間は一方の経路を使い、チェーンが必要な場合にだけもう一方を追加してください。余分なホップは障害点や異なる信頼関係を増やし得ます。識別用Cookieを自動的に消したり、アプリケーションのすべての接続を同じ経路にしたりするものではありません。

関連記事