curl socks5h fronte a socks5: quen resolve o nome de host

A xente trata socks5h como socks5 cunha ortografía máis amable, e espera que ambas envíen a mesma petición ao mesmo lugar. A letra extra move a consulta DNS no seu lugar. Nunha máquina cuxo resolutor e cuxo proxy están en redes distintas, esa é a diferenza entre unha petición que funciona e outra que falla.

Unha letra, dous resolutores

O esquema decide onde o nome de destino se converte en enderezo. A resolución local usa o resolutor configurado na súa máquina. A resolución remota pon o nome de host dentro da petición SOCKS, e o proxy búscao co seu propio resolutor e a súa propia visión da rede. Ambas as formas seguen conectando ao mesmo enderezo de proxy no mesmo porto, así que a diferenza está no corpo da petición, non na ruta.

Nada do esquema cambia o cifrado nin a autenticación; só se move a ruta DNS. Por iso a letra é fácil de ignorar e cara de equivocar.

Mesmo proxy, petición distinta

As dúas invocacións difiren nun só carácter. Todo o demais é idéntico:

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

A referencia do proxy de curl documenta estes esquemas por separado, e esa é a razón autorizada para non tratalos como alias. Execute ambas contra un extremo inofensivo que teña permiso de usar e lea a diferenza. Unha busca remota exitosa non di nada sobre outras aplicacións, porque os navegadores, os xestores de paquetes e as contornas de execución das linguaxes elixen cada un pola súa conta.

O nome propio do proxy resólvese localmente

Nese comando, proxy.example ten que converterse nun enderezo antes de que ocorra calquera outra cousa, e esa busca é sempre local. Mover a resolución de service.example ao proxy non fai nada polo nome propio do proxy, que segue necesitando un resolutor que a súa máquina poida alcanzar. Aquí é onde unha VPN cambia o panorama.

Se o nome do proxy só se resolve dentro do túnel, a conexión depende de que o túnel estea levantado antes de que curl arrinque. Que esquema gaña entón depende de que lado pode responder. Cando a súa máquina non pode resolver o destino pero o proxy si, socks5 falla e socks5h ten éxito. Cando a súa máquina o resolve a través do túnel e o proxy non pode, socks5 funciona e socks5h falla.

O esquema non coloca a conexión co proxy dentro ou fóra da VPN; faino a táboa de rutas, e o esquema nunca a ve. Por iso un túnel pode arranxar un esquema e romper o outro na mesma máquina. A letra só decide quen fai a pregunta.

Que pode resolver cada lado

Un proxy público non pode resolver un nome exclusivo da empresa, así que enviarlle o nome de host falla no proxy e aparece como un erro de proxy en lugar dun erro DNS local. Un proxy dentro da mesma rede privada adoita poder resolver eses nomes, e aí é onde socks5h gaña o seu sitio. Escolla a localización do resolutor segundo a política que realmente necesite, porque o DNS remoto non é automaticamente máis capaz e si entrega o nome a un terceiro. Para un destino público funcionan ambas as formas, así que prefira a que xa usan as súas outras ferramentas.

Escriba esa elección no runbook e non nun comentario, e manteña as credenciais fóra do historial compartido e da saída de diagnóstico. Despois cambie unha variable cada vez: mesmo destino, mesmo binario, mesmo resolutor, unha letra.

Que binario respondeu

Dous binarios de curl na mesma máquina poden diferir en versión e características de compilación. Nunha shell tipo Unix, type -a curl enumera cada coincidencia na ruta e curl --version mostra as características do que se executaría. Un script envoltorio ou un alias máis arriba na ruta é unha causa habitual de que os resultados non coincidan co binario que cre que está a probar.

Un esquema non admitido, un proxy que non pode resolver o nome e un destino inalcanzable son tres erros distintos, así que lea a mensaxe antes de cambiar a letra. Unha compilación sen a sintaxe socks5h informa que a cadea de proxy non se admite, o que non é o mesmo que un nome que non se puido resolver. Non converta un informe antigo sobre un curl do sistema nunha regra permanente para cada plataforma.