Hvorfor din PAC-fil vælger den forkerte netværksadapter

Den bærbare computer er på kontorets Wi-Fi, Ethernet-kablet er tilsluttet, og en VPN-adapter er stadig til stede. Din PAC-fil spørger myIpAddress(), hvilket netværk den er på. Det lyder rimeligt, indtil den får en adresse, der tilhører den forkerte adapter.

Den manglende detalje er, at funktionen returnerer én adresse. Den er ikke en fortegnelse over hver grænseflade, og den kontakter ikke et websted for at finde din offentlige IP. En privat adresse, eller endda et loopback-fallback, fortæller dig ikke, hvilken udgangsadresse en proxy-anmodning vil bruge.

Ét svar til en maskine med flere adresser

Valg af netværksgrænseflade hører til PAC-implementeringen. Gammelt råd om at omarrangere Windows-adaptere kan beskrive en bestemt browser- og operativsystemversion, men det er en dårlig universel løsning. Chromium dokumenterer sin egen valgalgoritme og begrænsninger ved flere netværk; en anden klient behøver ikke træffe det samme valg.

Begynd med at identificere den værdi, den berørte browser faktisk leverede, og sammenlign den derefter med undernetstjekkene i dit script. Gør dette separat på Wi-Fi, Ethernet og den godkendte VPN-forbindelse. En adresse, der ser overraskende ud, kan stadig opfylde implementeringens regler.

Lad beslutningen afhænge af mindre gætteri

Hvor det er praktisk, vælg en proxy ud fra destinationsværtens navn i stedet for en antaget klientgrænseflade. Hvis netværksregistrering er nødvendig, brug et bevidst, dokumenteret signal, som din organisation kontrollerer. DNS-baseret registrering har også fejltilstande, så definer, hvad der sker, når signalet ikke er tilgængeligt.

Nogle implementeringer tilbyder myIpAddressEx(). Kontroller understøttelsen og returformatet, før du tager det i brug; det er ikke en direkte erstatning for en enkelt IPv4-streng. Kontroller til sidst den resulterende anmodningsrute uafhængigt. Korrekt genkendelse af kontorets undernet og at nå den tilsigtede proxy er to separate resultater.