curl socks5h kontra socks5: hvem løser opp vertsnavnet

Folk behandler socks5h som socks5 med en vennligere stavemåte, og forventer at begge sender den samme forespørselen til samme sted. Den ekstra bokstaven flytter i stedet DNS-spørringen. På en maskin der resolversen og proxyen ligger i ulike nettverk, er det forskjellen mellom en forespørsel som virker og en som feiler.

Én bokstav, to resolvere

Skjemaet avgjør hvor destinasjonsnavnet blir en adresse. Lokal oppslag bruker resolversen som er konfigurert på maskinen din. Eksternt oppslag legger vertsnavnet inn i SOCKS-forespørselen, og proxyen slår det opp med sin egen resolver og sitt eget syn på nettverket. Begge formene kobler fortsatt til samme proxyadresse på samme port, så forskjellen ligger i forespørselens kropp, ikke i ruten.

Ingenting ved skjemaet endrer kryptering eller autentisering; bare DNS-ruten flyttes. Derfor er bokstaven lett å overse og dyr å ta feil av.

Samme proxy, annen forespørsel

De to kallene skiller seg med ett enkelt tegn. Alt annet er identisk:

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

The curl-proxyreferansen dokumenterer disse skjemaene hver for seg, og det er den autoritative grunnen til ikke å behandle dem som aliaser. Kjør begge mot et ufarlig endepunkt du har lov til å bruke, og les forskjellen. Et vellykket eksternt oppslag sier ingenting om andre applikasjoner, fordi nettlesere, pakkebehandlere og språk-kjøretider velger hver for seg.

Proxyens eget navn løses lokalt

I den kommandoen må proxy.example bli en adresse før noe annet skjer, og det oppslaget er alltid lokalt. Å flytte oppslaget av service.example til proxyen gjør ingenting for proxyens eget navn, som fortsatt trenger en resolver maskinen din kan nå. Det er her en VPN endrer bildet.

Hvis proxyens navn bare løses inne i tunnelen, avhenger forbindelsen av at tunnelen er oppe før curl starter. Hvilket skjema som vinner, avhenger da av hvilken side som kan svare. Når maskinen din ikke kan løse destinasjonen men proxyen kan, feiler socks5 og socks5h lykkes. Når maskinen din løser den gjennom tunnelen og proxyen ikke kan, virker socks5 og socks5h feiler.

Skjemaet plasserer ikke forbindelsen til proxyen innenfor eller utenfor VPN; det gjør rutetabellen, og skjemaet ser den aldri. Derfor kan én tunnel reparere ett skjema og ødelegge det andre på samme maskin. Bokstaven avgjør bare hvem som stiller spørsmålet.

Hva hver side kan løse

En offentlig proxy kan ikke løse et navn som bare finnes i bedriften, så å sende vertsnavnet dit feiler hos proxyen og vises som en proxyfeil i stedet for en lokal DNS-feil. En proxy inne i samme private nettverk kan vanligvis løse slike navn, og det er der socks5h gjør nytten. Velg plasseringen av resolversen ut fra policyen du faktisk trenger, fordi ekstern DNS ikke automatisk er mer kapabel, og det overlater navnet til en tredjepart. For en offentlig destinasjon virker begge former, så foretrekk den verktøyene dine allerede bruker.

Skriv det valget inn i runbooken i stedet for i en kommentar, og hold legitimasjonsdata utenfor delt historikk og diagnostisk utdata. Bytt deretter én variabel om gangen: samme destinasjon, samme binære fil, samme resolver, én bokstav.

Hvilken binærfil svarte

To curl-binærfil samme maskin kan variere i versjon og byggefunksjoner. I et Unix-lignende skall lister type -a curl opp hver treff i stien, og curl --version viser funksjonene til den som ville kjørt. Et innpakningsskript eller et alias tidligere i stien er en vanlig grunn til at resultatene ikke stemmer med binærfilen du tror du tester.

Et ikke-støttet skjema, en proxy som ikke kan løse navnet, og en uoppnåelig destinasjon er tre forskjellige feil, så les meldingen før du endrer bokstaven. Et bygg uten socks5h-syntaksen rapporterer proxy-strengen som ikke støttet, noe som ikke er det samme som et navn som ikke lot seg løse. Ikke gjør én gammel rapport om en system-curl til en permanent regel for hver plattform.