libproxy vælger en rute; din klient opretter forbindelsen

Hvis libproxy returnerer en proxy-URI, mens den næste socket forbinder direkte, skal du undersøge overdragelsen. libproxy registrerer politik; det opsnapper ikke hver socket, programmet åbner.

1. Spørg efter ressourcen. I det dokumenterede libproxy 0.5 C-API skal du oprette en proxyfabrik og bede om den faktiske destinations-URL.
2. Fortolk de ordnede kandidater. HTTP-, SOCKS- og direkte resultater kræver forskellig håndtering. Bevar deres præferencerækkefølge og den tilsigtede fejlpolitik.
3. Konfigurer forbrugeren. Giv den valgte proxytype, slutpunkt og godkendelsesordning til en transport, der understøtter dem. En rå TCP-socket opnår ikke CONNECT- eller SOCKS-forhandling fra en returneret URI.

Gem ikke ét svar som ruten for alle destinationer, og gør ikke direkte routing permanent, fordi den første proxy fejlede én gang.

Hvis HTTP-klienten allerede integrerer systemproxy eller PAC-registrering, skal du vælge én ejer af valget. To uafhængige vælgere plus en ekstra indpakning kan give en rute, som ingen af politikkerne tilsigtede.

I indbygget kode skal du følge det installerede API's livscyklus for fabrik og resultat-hukommelse. Genbrug af en fabrik kan bevare nyttig registreringstilstand, men den kræver stadig en forespørgsel for hver destination. Log valg adskilt fra forbindelsesresultatet: en returneret URI beviser ikke vellykket godkendelse, opløsning eller videre adgang.