curl socks5h kontra socks5: vem löser upp värdnamnet

Folk behandlar socks5h som socks5 med en vänligare stavning, och förväntar sig att båda skickar samma förfrågan till samma plats. Den extra bokstaven flyttar i stället DNS-frågan. På en maskin där resolvern och proxyn ligger i olika nät är det skillnaden mellan en förfrågan som fungerar och en som misslyckas.

En bokstav, två resolvrar

Schemat avgör var destinationsnamnet blir en adress. Lokal uppslagning använder resolvern som är konfigurerad på din maskin. Fjärruppslagning lägger värdnamnet i SOCKS-förfrågan, och proxyn slår upp det med sin egen resolver och sin egen bild av nätet. Båda formerna ansluter fortfarande till samma proxyadress på samma port, så skillnaden ligger i förfrågans kropp, inte i vägen.

Ingenting i schemat ändrar kryptering eller autentisering; bara DNS-vägen flyttas. Därför är bokstaven lätt att förbise och dyr att ha fel i.

Samma proxy, annan förfrågan

De två anropen skiljer sig åt med ett enda tecken. Allt annat är identiskt:

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

The curl-proxyreferensen dokumenterar dessa scheman separat, och det är det auktoritativa skälet att inte behandla dem som alias. Kör båda mot en ofarlig slutpunkt som du har tillåtelse att använda och läs skillnaden. En lyckad fjärrsökning säger ingenting om andra program, eftersom webbläsare, pakethanterare och språkens körtidsmiljöer väljer var för sig.

Proxyns eget namn löses lokalt

I det kommandot måste proxy.example bli en adress innan något annat händer, och den sökningen är alltid lokal. Att flytta uppslagningen av service.example till proxyn gör ingenting för proxyns eget namn, som fortfarande behöver en resolver som din maskin kan nå. Det är här en VPN ändrar bilden.

Om proxyns namn bara löses inuti tunneln beror anslutningen på att tunneln är uppe innan curl startar. Vilket schema som vinner beror då på vilken sida som kan svara. När din maskin inte kan lösa destinationen men proxyn kan, misslyckas socks5 och socks5h lyckas. När din maskin löser den genom tunneln och proxyn inte kan, fungerar socks5 och socks5h misslyckas.

Schemat placerar inte anslutningen till proxyn innanför eller utanför VPN; det gör routingtabellen, och schemat ser den aldrig. Därför kan en tunnel reparera det ena schemat och förstöra det andra på samma maskin. Bokstaven avgör bara vem som ställer frågan.

Vad varje sida kan lösa

En offentlig proxy kan inte lösa ett namn som bara finns inom företaget, så att skicka värdnamnet dit misslyckas hos proxyn och visas som ett proxyfel i stället för ett lokalt DNS-fel. En proxy inom samma privata nät kan oftast lösa sådana namn, och det är där socks5h gör nytta. Välj resolverens placering utifrån den policy du faktiskt behöver, eftersom fjärr-DNS inte automatiskt är mer kapabelt och det verkligen lämnar namnet till en tredje part. För ett offentligt mål fungerar båda formerna, så föredra den som dina andra verktyg redan använder.

Skriv in det valet i runbooken i stället för i en kommentar, och håll inloggningsuppgifter utanför delad historik och diagnostisk utdata. Byt sedan en variabel i taget: samma mål, samma binärfil, samma resolver, en bokstav.

Vilken binärfil som svarade

Två curl-binärfiler på samma maskin kan skilja sig i version och byggfunktioner. I ett Unix-likt skal listar type -a curl varje träff på sökvägen och curl --version visar funktionerna hos den som skulle köras. Ett omslagsskript eller ett alias tidigare på sökvägen är en vanlig orsak till att resultaten inte stämmer med binärfilen du tror att du testar.

Ett icke-stött schema, en proxy som inte kan lösa namnet och ett oåtkomligt mål är tre olika fel, så läs meddelandet innan du ändrar bokstaven. En byggnad utan socks5h-syntaxen rapporterar proxy-strängen som icke-stödd, vilket inte är samma sak som ett namn som inte kunde lösas. Gör inte en gammal rapport om en system-curl till en permanent regel för varje plattform.