curl socks5h contre socks5 : qui résout le nom d'hôte

Les gens traitent socks5h comme socks5 avec une orthographe plus sympathique, et s'attendent à ce que les deux envoient la même requête au même endroit. La lettre supplémentaire déplace plutôt la requête DNS. Sur une machine dont le résolveur et le proxy se trouvent dans des réseaux différents, c'est la différence entre une requête qui fonctionne et une qui échoue.

Une lettre, deux résolveurs

Le schéma décide où le nom de destination devient une adresse. La résolution locale utilise le résolveur configuré sur votre machine. La résolution distante place le nom d'hôte dans la requête SOCKS, et le proxy le recherche avec son propre résolveur et sa propre vision du réseau. Les deux formes se connectent toujours à la même adresse de proxy sur le même port, donc la différence est dans le corps de la requête, pas dans le chemin.

Rien dans le schéma ne change le chiffrement ni l'authentification ; seul le chemin DNS se déplace. C'est pourquoi la lettre est facile à ignorer et coûteuse à se tromper.

Même proxy, requête différente

Les deux invocations diffèrent d'un seul caractère. Tout le reste est identique :

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

La référence du proxy de curl documente ces schémas séparément, et c'est la raison faisant autorité pour ne pas les traiter comme des alias. Lancez les deux vers un point de terminaison inoffensif que vous êtes autorisé à utiliser et lisez la différence. Une recherche distante réussie ne dit rien des autres applications, car les navigateurs, les gestionnaires de paquets et les environnements d'exécution des langages choisissent chacun pour eux-mêmes.

Le nom propre du proxy est résolu localement

Dans cette commande, proxy.example doit devenir une adresse avant que quoi que ce soit d'autre ne se produise, et cette recherche est toujours locale. Déplacer la résolution de service.example vers le proxy ne fait rien pour le nom propre du proxy, qui a encore besoin d'un résolveur que votre machine peut joindre. C'est ici qu'un VPN change la donne.

Si le nom du proxy n'est résolu qu'à l'intérieur du tunnel, la connexion dépend de l'état du tunnel avant le démarrage de curl. Le schéma qui l'emporte dépend alors du côté qui peut répondre. Quand votre machine ne peut pas résoudre la destination mais que le proxy le peut, socks5 échoue et socks5h réussit. Quand votre machine la résout par le tunnel et que le proxy ne le peut pas, socks5 fonctionne et socks5h échoue.

Le schéma ne place pas la connexion au proxy à l'intérieur ou à l'extérieur du VPN ; c'est la table de routage qui le fait, et le schéma ne la voit jamais. C'est pourquoi un tunnel peut réparer un schéma et casser l'autre sur la même machine. La lettre décide seulement qui pose la question.

Ce que chaque côté peut résoudre

Un proxy public ne peut pas résoudre un nom propre à l'entreprise, donc lui envoyer le nom d'hôte échoue au niveau du proxy et apparaît comme une erreur de proxy plutôt qu'une erreur DNS locale. Un proxy à l'intérieur du même réseau privé peut généralement résoudre ces noms, et c'est là que socks5h gagne sa place. Choisissez l'emplacement du résolveur selon la politique dont vous avez réellement besoin, car le DNS distant n'est pas automatiquement plus capable et il remet bien le nom à un tiers. Pour une destination publique, les deux formes fonctionnent, alors préférez celle que vos autres outils utilisent déjà.

Inscrivez ce choix dans le runbook plutôt que dans un commentaire, et gardez les identifiants hors de l'historique partagé et de la sortie de diagnostic. Puis changez une variable à la fois : même destination, même binaire, même résolveur, une lettre.

Quel binaire a répondu

Deux binaires curl sur la même machine peuvent différer par la version et les options de compilation. Dans un shell de type Unix, type -a curl liste chaque correspondance sur le chemin et curl --version montre les caractéristiques de celui qui s'exécuterait. Un script enveloppe ou un alias plus haut dans le chemin est une cause fréquente d'un décalage entre les résultats et le binaire que vous croyez tester.

Un schéma non pris en charge, un proxy qui ne peut pas résoudre le nom et une destination inaccessible sont trois erreurs différentes, alors lisez le message avant de changer la lettre. Une compilation sans la syntaxe socks5h signale la chaîne de proxy comme non prise en charge, ce qui n'est pas la même chose qu'un nom qui n'a pas pu être résolu. Ne transformez pas un vieux rapport sur un curl système en règle permanente pour toutes les plateformes.