curl socks5h kontra socks5: kven løyser opp vertsnamnet

Folk handsamar socks5h som socks5 med ei venlegare staving, og ventar at begge sender den same førespurnaden til same stad. Den ekstra bokstaven flyttar i staden DNS-spørjinga. På ei maskin der resolvaren og proxyen ligg i ulike nettverk, er det skilnaden mellom ein førespurnad som verkar og ein som feilar.

Éin bokstav, to resolverar

Skjemaet avgjer kvar destinasjonsnamnet blir ei adresse. Lokal oppslag brukar resolvaren som er sett opp på maskina di. Ekstern oppslag legg vertsnamnet inn i SOCKS-førespurnaden, og proxyen slår det opp med sin eigen resolver og sitt eige syn på nettverket. Begge formene koplar framleis til same proxyadresse på same port, så skilnaden ligg i kroppen på førespurnaden, ikkje i ruta.

Ingenting ved skjemaet endrar kryptering eller autentisering; berre DNS-ruta flyttar seg. Difor er bokstaven lett å sjå bort frå og dyr å ta feil av.

Same proxy, annan førespurnad

Dei to kalla skil seg med eitt einskilt teikn. Alt anna er identisk:

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

The curl-proxyreferansen dokumenterer desse skjemaane kvar for seg, og det er den autoritative grunnen til ikkje å handsame dei som alias. Køyr begge mot eit ufarleg endepunkt du har lov til å bruke, og les skilnaden. Eit vellukka eksternt oppslag seier ingenting om andre program, fordi nettlesarar, pakkehandsamarar og språk-køyretider vel kvar for seg.

Det eigne namnet til proxyen blir løyst lokalt

I den kommandoen må proxy.example bli ei adresse før noko anna skjer, og det oppslaget er alltid lokalt. Å flytte oppslaget av service.example til proxyen gjer ingenting for det eigne namnet til proxyen, som framleis treng ein resolver maskina di kan nå. Det er her ein VPN endrar biletet.

Viss namnet til proxyen berre blir løyst inne i tunnelen, avheng koplinga av at tunnelen er oppe før curl startar. Kva skjema som vinn, avheng då av kva side som kan svare. Når maskina di ikkje kan løyse destinasjonen men proxyen kan, feilar socks5 og socks5h lukkast. Når maskina di løyser han gjennom tunnelen og proxyen ikkje kan, verkar socks5 og socks5h feilar.

Skjemaet plasserer ikkje koplinga til proxyen innanfor eller utanfor VPN; det gjer rutetabellen, og skjemaet ser han aldri. Difor kan ein tunnel reparere eitt skjema og øydelegge det andre på same maskin. Bokstaven avgjer berre kven som stiller spørsmålet.

Kva kvar side kan løyse

Ein offentleg proxy kan ikkje løyse eit namn som berre finst i bedrifta, så å sende vertsnamnet dit feilar hos proxyen og viser seg som ein proxyfeil i staden for ein lokal DNS-feil. Ein proxy inne i same private nettverk kan vanlegvis løyse slike namn, og det er der socks5h gjer nytte for seg. Vel plasseringa av resolvaren ut frå policyen du faktisk treng, fordi ekstern DNS ikkje automatisk er meir kapabel, og det overlèt namnet til ein tredjepart. For ein offentleg destinasjon verkar begge former, så føretrekk den verktøya dine allereie brukar.

Skriv det valet inn i runbooken i staden for i ein kommentar, og hald legitimasjonsdata utanfor delt historikk og diagnostisk utdata. Bytt deretter éin variabel om gongen: same destinasjon, same binære fil, same resolver, éin bokstav.

Kva binærfil svara

To curl-binærfiler på same maskin kan variere i versjon og byggjefunksjonar. I eit Unix-liknande skal listar type -a curl opp kvart treff i stigen, og curl --version viser funksjonane til den som ville køyrt. Eit innpakningsskript eller eit alias tidlegare i stigen er ein vanleg grunn til at resultata ikkje stemmer med binærfilen du trur du testar.

Eit ikkje-støtta skjema, ein proxy som ikkje kan løyse namnet, og ein uoppnåeleg destinasjon er tre ulike feil, så les meldinga før du endrar bokstaven. Eit bygg utan socks5h-syntaksen rapporterer proxy-strengen som ikkje støtta, noko som ikkje er det same som eit namn som ikkje let seg løyse. Ikkje gjer éin gammal rapport om ein system-curl til ein permanent regel for kvar plattform.