Windows se ProxyServer-waarde kan 'n kaart wees
Herken protokolspesifieke Windows-proksiestrengs eerder as om die hele waarde aan 'n enkel-URI-konstruktor te gee.
'n Skrip lees ProxyServer uit Windows Internet Settings en ken dit aan WebProxy.Address toe. Dit werk op een masjien en misluk dan op 'n ander wie se waarde so lyk:
http=proxy-a.example:8080;https=proxy-b.example:8080
Dit is 'n protokolspesifieke konfigurasiestreng, nie een proksi-URI nie. Om die hele waarde aan 'n konstruktor te gee wat 'n enkele adres verwag, verander die betekenis van die invoer.
| Inskrywing | Kies die proksi vir |
|---|---|
| http=... | HTTP-bestemmingsversoeke |
| https=... | HTTPS-bestemmingsversoeke |
Die https-sleutel beteken nie op sigself dat die verbinding na daardie proksi TLS gebruik nie. 'n Gewone HTTP-proksi kan die HTTPS-bestemming deur CONNECT dra.
Verkies die ondersteunde stelselproksi-koppelvlak vir die werklike bestemming waar die kliënt een verskaf. Handmatige proksiestrengs, omseilreëls, outomatiese konfigurasie-URL's en outo-ontdekking is verskillende dele van die konfigurasie. Om een registerwaarde te lees, kan nie almal weergee nie. As jy die gestoorde kaart inspekteer, lees ProxyEnable en AutoConfigURL langs ProxyServer.
As 'n integrasie 'n handmatige kartering moet ontleed, volg die gedokumenteerde formaat, behou die protokolassosiasie en gebruik 'n egte URI- of eindpunt-ontleder vir elke gekose waarde. Om elke dubbelpunt te splits, breek IPv6; om die eerste inskrywing te kies, verloor die onderskeid hierbo.
Hou dit binne die toepaslike rekeningkonteks. Die interaktiewe gebruiker se instellings is nie outomaties die instellings van 'n diens wat onder 'n ander identiteit loop nie.