libproxy は経路を選び、接続はクライアントが行う

libproxy がプロキシ URI を返したのに次のソケットが直接接続する場合は、受け渡しを確認してください。libproxy はポリシーを検出しますが、アプリケーションが開くすべてのソケットを横取りするわけではありません。

1. リソースを問い合わせる。 文書化された libproxy 0.5 の C API でプロキシファクトリを作成し、実際の宛先 URL を要求します。
2. 順序付き候補を解釈する。 HTTP、SOCKS、直接の結果は扱いが異なります。優先順位と意図した失敗ポリシーを維持してください。
3. 利用側を設定する。 選択したプロキシ種別、エンドポイント、認証の取り決めを、それらをサポートするトランスポートに渡します。生の TCP ソケットは、返された URI から CONNECT や SOCKS のネゴシエーションを得ることはありません。

1 つの回答をすべての宛先の経路として保存したり、最初のプロキシが一度失敗しただけで直接ルーティングを恒久化したりしないでください。

HTTP クライアントがすでにシステムプロキシや PAC 検出を統合している場合は、選択の所有者を 1 つにしてください。2 つの独立したセレクタとさらに別のラッパーが加わると、どちらのポリシーも意図しない経路が生じることがあります。

ネイティブコードでは、インストール済み API のファクトリと結果メモリのライフサイクルに従ってください。ファクトリを再利用すると有用な検出状態を保てますが、宛先ごとに問い合わせは依然として必要です。選択は接続結果とは別に記録してください。返された URI は、認証・名前解決・その先のアクセスの成功を証明しません。