ブラウザーは Squid 経由で HTTP ページを読み込みます。同じ宛先が proxychains では失敗します。これは必ずしも、どちらかのプログラムが誤ったプロキシ IP を選んだという意味ではありません。

通常の HTTP を理解するクライアントは、Web 要求を HTTP プロキシ形式でフォワードプロキシへ送れます。一方、汎用のソケットラッパーは、アプリケーションが開こうとした接続のためにバイトトンネルを必要とします。チェーン内の HTTP プロキシに対して、proxychains は CONNECT を使います。

つまり、ポート 80 上の平文の Web サイトがポート 80 への CONNECT 要求を発生させることがあります。CONNECT を承認済みの TLS ポート一覧だけに許可する Squid のポリシーは、ポート 80 への通常の HTTP 要求が許可されていても、そのトンネルを拒否できます。

ホスト名だけでなく要求を比較する

proxychains-ng のドキュメントは HTTP CONNECT のサポートを説明しています。Squid のアクセス規則はメソッドと宛先ポートを区別できます。同じ Web サイトへの異なる要求経路です。

変更する前に、拒否と意図されたポリシーを読んでください。CONNECT アクセスをすべてのポートに広げるのは大きな変更です。ラッパーの不一致に対する既定の対応にすべきではありません。

アプリケーションにネイティブの HTTP プロキシ サポートがあれば、それを使うことで平文 HTTP に不要な汎用トンネルを避けられます。本当に生の TCP トンネルが必要なら、それを提供する承認済みのプロキシプロトコルとポートポリシーを選んでください。

ブラウザー要求の成功は、プロキシの到達性と 1 つのサポートされた要求モードについての有用な証拠です。しかし、すべてのトンネル方式、宛先ポート、アプリケーション プロトコルがそのプロキシ経由で許可されていることを証明するものではありません。

関連記事