Folk behandler socks5h som socks5 med en venligere stavemåde og forventer, at begge sender den samme anmodning til samme sted. Det ekstra bogstav flytter i stedet DNS-opslaget. På en maskine, hvis resolver og hvis proxy ligger i forskellige netværk, er det forskellen mellem en anmodning, der virker, og en, der fejler.

Et bogstav, to resolvere

Skemaet afgør, hvor destinationsnavnet bliver til en adresse. Lokal opløsning bruger den resolver, der er konfigureret på din maskine. Fjern opløsning lægger værtsnavnet ind i SOCKS-anmodningen, og proxyen slår det op med sin egen resolver og sit eget billede af netværket. Begge former forbinder stadig til den samme proxyadresse på den samme port, så forskellen ligger i anmodningens krop, ikke i vejen.

Intet ved skemaet ændrer kryptering eller godkendelse; kun DNS-vejen flyttes. Derfor er bogstavet let at ignorere og dyrt at tage fejl af.

Samme proxy, forskellig anmodning

De to kald adskiller sig med et enkelt tegn. Alt andet ved dem er identisk:

curl --proxy socks5://proxy.example:1080 https://service.example/
curl --proxy socks5h://proxy.example:1080 https://service.example/

The curl-proxyreferencen dokumenterer disse skemaer hver for sig, og det er den autoritative grund til ikke at behandle dem som aliaser. Kør begge mod et ufarligt endepunkt, du har tilladelse til at bruge, og læs forskellen. Et vellykket fjernopslag siger intet om andre programmer, fordi browsere, pakkehåndteringer og sprogmiljøer vælger hver for sig.

Proxyens eget navn opløses lokalt

I den kommando skal proxy.example blive en adresse, før noget andet sker, og det opslag er altid lokalt. At flytte service.example-opløsningen til proxyen gør intet for proxyens eget navn, som stadig kræver en resolver, din maskine kan nå. Det er her, en VPN ændrer billedet.

Hvis proxyens navn kun opløses inde i tunnelen, afhænger forbindelsen af, at tunnelen er oppe, før curl starter. Hvilket skema der så vinder, afhænger af, hvilken side der kan svare. Når din maskine ikke kan opløse destinationen, men proxyen kan, fejler socks5, og socks5h lykkes. Når din maskine opløser den gennem tunnelen, og proxyen ikke kan, virker socks5, og socks5h fejler.

Skemaet placerer ikke forbindelsen til proxyen inde eller ude af VPN; det gør rutetabellen, og skemaet ser den aldrig. Derfor kan en tunnel rette ét skema og ødelægge det andet på samme maskine. Bogstavet afgør kun, hvem der stiller spørgsmålet.

Hvad hver side kan opløse

En offentlig proxy kan ikke opløse et navn, der kun findes i virksomheden, så at sende værtsnavnet derhen fejler hos proxyen og viser sig som en proxyfejl i stedet for en lokal DNS-fejl. En proxy inde i samme private netværk kan normalt opløse de navne, og det er her, socks5h gør sin nytte. Vælg resolverens placering ud fra den politik, du faktisk har brug for, fordi fjern-DNS ikke automatisk er mere kapabelt, og det overlader navnet til en tredjepart. For en offentlig destination virker begge former, så foretræk den, dine andre værktøjer allerede bruger.

Skriv det valg ind i runbooken i stedet for i en kommentar, og hold legitimationsoplysninger ude af delt historik og diagnostisk output. Skift derefter én variabel ad gangen: samme destination, samme binære fil, samme resolver, et bogstav.

Hvilken binær fil svarede

To curl-binære filer på samme maskine kan variere i version og build-funktioner. I et Unix-lignende shell oplister type -a curl hver forekomst på stien, og curl --version viser funktionerne i den, der ville køre. Et wrapper-script eller et alias tidligere på stien er en hyppig grund til, at resultaterne ikke svarer til den binære fil, du tror, du tester.

Et ikke-understøttet skema, en proxy, der ikke kan opløse navnet, og en uopnåelig destination er tre forskellige fejl, så læs meddelelsen, før du ændrer bogstavet. Et build uden socks5h-syntaksen rapporterer proxy-strengen som ikke-understøttet, hvilket ikke er det samme som et navn, der ikke kunne opløses. Gør ikke én gammel rapport om en system-curl til en permanent regel for enhver platform.

Relaterede artikler