Deux outils en ligne de commande qui récupèrent tous deux des données via HTTP, installés sur presque toutes les machines, sans cesse comparés et rarement distingués de manière utile.
La source la plus fiable concernant cette différence est, heureusement, la comparaison publiée par le responsable de curl lui-même — un document qui comprend une section explicite sur ce que wget fait mieux que curl. Chaque affirmation factuelle ci-dessous renvoie à ce document ou aux manuels des projets eux-mêmes, plutôt qu’à l’impression de quiconque, ce qui est important dans une comparaison souvent rédigée de mémoire.
Nous sommes Geonode, nous vendons des proxys, et notre remarque en toute honnêteté est brève : aucun de ces deux outils n’a besoin d’un proxy pour la grande majorité des usages auxquels les gens les destinent. Récupérer un fichier, appeler une API, vérifier si un service répond — rien de tout cela n’en nécessite un. Il existe une différence réelle et peu documentée entre les deux outils en matière de prise en charge des proxys, et j’y consacre une section ci-dessous, mais si vous êtes arrivé ici pour choisir un outil de téléchargement, vous pouvez sans crainte l’ignorer.
En résumé, ces outils ont été conçus selon des modèles conceptuels différents, et presque toutes les différences apparentes en découlent. curl se comporte comme cat — il récupère un élément et l’écrit sur la sortie standard. wget se comporte comme cp — il récupère un élément et l’écrit dans un fichier. C’est là le cadre de référence proposé par le responsable du projet, et une fois que vous l’avez intégré, les redirection par défaut, les différences entre les options et la capacité de récursivité cessent toutes d’être arbitraires.
La recommandation en bref, pour ceux qui souhaitent en connaître les détails : utilisez wget lorsque vous souhaitez enregistrer des fichiers sur le disque, et curl pour tout le reste.
La différence en une phrase
curl fonctionne, selon les termes de son développeur, « comme la commande traditionnelle Unix cat
». wget fonctionne « davantage comme cp
».
Cette seule distinction explique en grande partie ce qui suit.
Ce que cela signifie en pratique
curl https://example.com/file.txt # prints the contents to your terminal
wget https://example.com/file.txt # saves file.txt to the current directory
Aucune des deux commandes n’est erronée. Elles répondent à des questions différentes.
La conception de curl part du principe que vous voulez les données, et que ce que vous en faites ensuite ne regarde que vous : les acheminer via un pipeline, les analyser, les rediriger, les lire. L'écriture vers la sortie standard est le choix qui permet la composabilité, et c’est pourquoi curl s’intègre naturellement dans les pipelines du shell.
La conception de wget part du principe que vous voulez le fichier. Il choisit le nom de fichier, le crée, affiche une barre de progression et termine par un fichier sur le disque.
Pourquoi les conséquences sont plus importantes qu’il n’y paraît
Dès lors que la tâche d’un outil consiste à « copier le fichier sur le disque », tout un ensemble de comportements devient manifestement correct : suivre les redirections, car le fichier a été déplacé ; réessayer en cas d’échec, car l’objectif est le fichier et non la tentative ; reprendre un téléchargement partiel, car un fichier à moitié téléchargé ne correspond pas à la tâche. wget effectue toutes ces actions par défaut.
Lorsque la mission d’un outil est « d’effectuer ce transfert et de me fournir le résultat », les comportements appropriés sont différents : signaler ce qui s’est passé plutôt que de décider à ma place, faire exactement ce qui a été demandé et laisser l’utilisateur se charger du reste. curl signale la redirection et s’arrête, car la suivre n’était pas ce que vous aviez demandé.
Aucun de ces deux jeux de paramètres par défaut n’est meilleur que l’autre. Ils sont cohérents avec des objectifs différents, et la plupart des frustrations que les utilisateurs éprouvent avec l’un ou l’autre de ces outils proviennent du fait qu’ils s’attendent à ce que l’autre fonctionne selon les mêmes principes.
Ce que curl fait et que wget ne fait pas
D'après la comparaison établie par le responsable du projet, et la liste est longue.
C'est avant tout une bibliothèque
curl intègre libcurl, décrite comme disposant d'« une API stable accessible à tous ». C'est la différence la plus importante, mais aussi la moins visible depuis un terminal.
libcurl est intégrée à une quantité considérable de logiciels : liaisons de langage, applications, périphériques. L'outil en ligne de commande est, en quelque sorte, une démonstration de la bibliothèque. wget est un programme ; curl est un programme s'appuyant sur une bibliothèque utilisée par d'autres programmes.
Si vous avez déjà utilisé les fonctions cURL de PHP ou une liaison HTTP de langage basée sur libcurl, vous avez utilisé curl sans exécuter curl.
Bien plus de protocoles
La liste publiée est longue : « FTP(S), GOPHER(S), HTTP(S), SCP, SFTP, TFTP, TELNET, DICT, LDAP(S), MQTT, FILE, POP3(S), IMAP(S), SMB(S), SMTP(S), RTMP, RTSP et WS(S) ».
wget prend en charge HTTP, HTTPS et FTP. Pour le Web, cela suffit généralement. Pour tout ce qui concerne les protocoles de messagerie, SFTP, MQTT ou WebSocket, curl est le seul des deux à entrer en ligne de compte.
Versions HTTP plus récentes
curl prend en charge les versions HTTP 0.9, 1.0, 1.1, 2 et 3. Si vous avez besoin de tester spécifiquement le comportement d’un serveur sous HTTP/2 ou HTTP/3, c’est à curl de s’en charger.
Autres types de proxys
curl prend en charge les proxys HTTPS ainsi que les proxys SOCKS4 et SOCKS5. Cela fait partie des fonctionnalités de curl que wget ne propose pas, et cela a des conséquences concrètes — voir la section sur les proxys ci-dessous.
Transferts parallèles
curl peut effectuer plusieurs transferts simultanés grâce à l’option -Z. Utile lors de la récupération de nombreuses petites ressources, lorsque la latence liée à leur traitement un par un devient prépondérante.
Transfert bidirectionnel et envois de formulaires
Envoyer des données, pas seulement les recevoir. Envois de formulaires en plusieurs parties, PUT, méthodes arbitraires. wget est fondamentalement un outil de récupération ; curl est un outil de transfert, et les envois constituent un cas de figure à part entière.
Il est déjà installé sur davantage de machines
curl est préinstallé sur macOS ainsi que sur Windows 10 et 11. Sur une machine Windows sans aucun logiciel supplémentaire, curl est disponible, contrairement à wget en général — ce qui a plus d’importance qu’il n’y paraît pour les scripts multiplateformes.
Ce que wget fait et que curl ne fait pas
Ces informations proviennent également du responsable de curl lui-même, ce qui rend cette liste digne de confiance.
Téléchargement récursif
« Le principal atout de wget par rapport à curl réside dans sa capacité à télécharger de manière récursive. »
C’est un atout majeur, et ce n’est pas une fonctionnalité mineure. wget peut suivre les liens d’une page et télécharger ce qu’il trouve, jusqu’à une profondeur spécifiée, en convertissant les liens pour une consultation locale au fur et à mesure. La création d’un miroir d’un site de documentation pour une lecture hors ligne se fait en une seule commande.
wget -r -np -k -p https://example.com/docs/
Téléchargement récursif, sans répertoires parents, conversion des liens pour une consultation locale, récupération des éléments indispensables à la page tels que les images et les feuilles de style.
curl n’est absolument pas capable de faire cela. curl récupère les URL que vous lui fournissez. Il n’analyse pas le HTML, ne détecte pas les liens et n’a aucune notion de ce qu’est un site. Si votre tâche consiste à « copier cette section d’un site web », wget est la solution et il n’existe aucun équivalent de curl valant la peine d’être essayé.
Reprise des transferts interrompus
wget « peut récupérer un transfert interrompu prématurément et poursuivre le téléchargement ». Avec l’option -c, un téléchargement interrompu reprend là où il s’était arrêté.
curl peut également le faire avec l’option -C -, mais le comportement de wget en matière de tentatives et de reprise est plus automatique et plus tolérant — ce qui est important lorsque le transfert est volumineux et que la connexion n’est pas fiable.
Aucune option n’est nécessaire pour le cas de figure évident
wget télécharge un fichier sans aucun indicateur. curl « nécessite -o ou -O » pour écrire dans un fichier plutôt que dans le terminal.
Pour la tâche la plus courante que l’on effectue avec l’un ou l’autre de ces outils — télécharger ce fichier —, wget est la commande la plus courte, et cette concision constitue un réel avantage pour un outil que l’on utilise quotidiennement.
Des paramètres par défaut plus judicieux pour le téléchargement
wget « active davantage de fonctionnalités par défaut : les cookies, le suivi des redirections, l’horodatage ».
L’horodatage mérite une mention particulière : avec l’option « -N », wget ne télécharge à nouveau un fichier que si la version distante est plus récente. Pour la synchronisation planifiée d’un ensemble de fichiers, c’est exactement le comportement souhaité et curl ne dispose d’aucun équivalent direct.
Licence
wget est sous licence GPL v3 ; curl est sous licence MIT. Si vous intégrez l’un ou l’autre dans un produit, cette différence aura probablement plus d’importance que n’importe quelle fonctionnalité mentionnée sur cette page.
Les paramètres par défaut qui vous font perdre du temps
Les différences les plus susceptibles de vous valoir un après-midi de confusion.
Redirections
wget suit les redirections par défaut. Ce n'est pas le cas de curl.
C'est la cause la plus courante de la question « pourquoi curl n'a-t-il rien renvoyé ? ». Le serveur a répondu avec un code 301, curl l'a signalé et s'est arrêté, et la sortie standard semble vide.
curl -L https://example.com/moved # follow them
wget https://example.com/moved # already following them
Ce n’est pas une erreur de la part de curl. Suivre une redirection revient à envoyer une requête que vous n’avez pas demandée, vers un hôte que vous n’avez pas spécifié, et le principe de curl est de faire ce qu’on lui demande et de signaler le reste. Le principe de wget est de récupérer le fichier, et celui-ci a été déplacé.
Destination de la sortie
Ce point a été abordé plus haut, mais mérite d’être répété car il piège constamment les utilisateurs. curl URL affiche le contenu ; wget URL l’enregistre.
Gestion des erreurs
Les deux outils présentent une particularité. curl traite un code 404 comme un transfert réussi et se termine avec un code de sortie nul — le transfert a fonctionné, le serveur a répondu. Utilisez -f pour que les erreurs HTTP génèrent un code de sortie non nul.
wget renvoie par défaut un code de sortie non nul en cas d’erreurs HTTP, ce qui est le comportement le plus intuitif pour un outil de téléchargement.
Dans les scripts : curl -sSf est la combinaison à retenir, et son absence est une raison courante pour laquelle une tâche défaillante semble fonctionner.
Nouvelles tentatives
wget effectue des nouvelles tentatives par défaut. curl ne le fait pas, sauf si vous le lui demandez avec --retry.
Là encore, cela correspond aux modèles : un outil de téléchargement doit persévérer, un outil de transfert doit signaler les problèmes.
Conseils pratiques
Si vous écrivez un programme automatisé, définissez explicitement le comportement plutôt que de vous fier aux paramètres par défaut de l’un ou l’autre outil. curl -sSfL --max-time 30 indique ce que vous souhaitez. Il en va de même pour wget --tries=3 --timeout=30. Les commandes explicites resteront compréhensibles même si quelqu’un d’autre les lit dans un an.
Comparaison côte à côte
| Tâche | curl | wget |
|---|
| Afficher dans le terminal | curl URL | wget -O - URL |
| Enregistrer dans un fichier | curl -O URL | wget URL |
| Enregistrer sous un nom de votre choix | curl -o name URL | wget -O name URL |
| Suivre les redirections | curl -L URL | par défaut |
| Reprendre un téléchargement | curl -C - -O URL | wget -c URL |
| En-têtes uniquement | curl -I URL | wget --spider -S URL |
| En-tête personnalisé | curl -H "K: V" URL | wget --header="K: V" URL |
| Authentification de base | curl -u user:pass URL | wget --user=u --password=p URL |
| Données POST | curl -d "a=b" URL | wget --post-data="a=b" URL |
| Silencieux | curl -s URL | wget -q URL |
| Mettre en miroir un site | impossible | wget -m URL |
| Télécharger un fichier | curl -T file URL | impossible |
| Utiliser SOCKS5 | curl -x socks5h://host URL | pas en natif |
| Transferts parallèles | curl -Z ... | non pris en charge |
Lecture du tableau
Cette symétrie s'applique aux opérations courantes : la plupart des tâches ont un équivalent direct, avec des variantes d'orthographe des options qui sont plus gênantes qu'importantes.
Ce sont les quatre lignes marquées comme « impossibles » qui déterminent en réalité votre choix. La mise en miroir d’un site se fait uniquement avec wget. Le téléchargement se fait uniquement avec curl. L’utilisation d’un proxy SOCKS se fait uniquement avec curl. Les transferts parallèles se font uniquement avec curl.
Si votre tâche figure dans l’une de ces lignes, la comparaison est terminée et vous pouvez arrêter votre lecture. Si ce n’est pas le cas, les deux outils fonctionnent et vous devriez utiliser celui que vous maîtrisez le mieux.
Remarque sur la confusion entre les options
« -O » a des significations différentes dans les deux outils, ce qui constitue un véritable piège.
Dans curl, -O signifie « enregistrer en utilisant le nom de fichier de l’URL » et -o name signifie « enregistrer sous ce nom ». Dans wget, -O name signifie « enregistrer sous ce nom » et l’autre option n’est pas nécessaire.
Ainsi, curl -O et wget -O ne sont pas équivalents, et une commande traduite sans précaution entre les deux produira un résultat inattendu.
Quelle option choisir en fonction de la tâche
Une liste de recommandations plutôt qu'un verdict.
Utilisez wget lorsque
Vous souhaitez enregistrer un fichier sur le disque. Pas d'options, pas de barre de progression, des paramètres par défaut raisonnables. C'est le cas de figure le plus courant pour la plupart des utilisateurs.
Vous souhaitez créer un miroir ou effectuer un téléchargement récursif. C’est la seule option possible. wget -m ou wget -r avec les limites appropriées.
La connexion est instable et le fichier est volumineux. Reprises automatiques et reprise des téléchargements en cas d’-c.
Vous synchronisez une copie locale. -N : le téléchargement ne porte que sur les modifications, grâce à l’horodatage.
Vous souhaitez une commande la plus courte possible pour un téléchargement simple dans un script que quelqu’un d’autre lira.
Utilisez curl lorsque
Vous travaillez avec une API. En-têtes, méthodes, corps de requête et sortie redirigée vers un processeur JSON.
Vous devez envoyer des données, et pas seulement les récupérer.
Vous effectuez un débogage. -v et -w vous fournissent la requête telle qu’elle a été envoyée, la réponse et les durées détaillées par phase. C’est de loin le principal avantage de curl au quotidien.
Vous avez besoin d’un protocole autre que HTTP et FTP.
Vous avez besoin d’une prise en charge des proxys SOCKS ou HTTPS.
Vous êtes sous Windows ou macOS sans rien d’installé, où curl est présent et wget ne l’est généralement pas.
Vous écrivez quelque chose qui deviendra du code, car grâce aux liaisons de libcurl, la structure de la commande se traduit naturellement.
Utilisez les deux
C’est la réponse la plus honnête pour la plupart des configurations de travail. Ces outils sont légers, gratuits et excellents dans des domaines différents. Les avoir tous les deux installés et choisir celui qui convient n’est pas un signe d’indécision — c’est la conséquence logique du fait qu’il s’agit d’outils véritablement différents.
Les proxys dans les deux cas
Notre domaine, et il existe une différence importante qu’il convient de connaître.
curl
# HTTP proxy
curl -x http://proxy.example.com:8080 https://example.com
# With credentials
curl -x http://user:pass@proxy.example.com:8080 https://example.com
# SOCKS5, with the proxy resolving hostnames
curl -x socks5h://proxy.example.com:1080 https://example.com
curl prend en charge les proxys HTTP, HTTPS et SOCKS4/SOCKS5
, le tout via la même option -x
avec un schéma.
wget
# Via environment variables
export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"
wget https://example.com
# With credentials
wget --proxy-user=user --proxy-password=pass https://example.com
wget lit les variables d’environnement standard relatives aux proxys et dispose d’options pour les identifiants de proxy.
La différence qui compte
wget ne prend pas en charge SOCKS de manière native. La comparaison de curl répertorie SOCKS4 et SOCKS5
parmi les fonctionnalités prises en charge par curl mais pas par wget.
Si votre proxy est exclusivement SOCKS, wget ne peut pas l’utiliser directement. Les solutions de contournement habituelles consistent à exécuter wget via un outil tel que proxychains, ou à placer un pont HTTP-vers-SOCKS local en amont — ces deux méthodes fonctionnent, mais elles ajoutent chacune un composant susceptible de tomber en panne sans avertissement.
Si vous devez choisir entre les deux et que SOCKS fait partie de votre configuration, cela fait pencher la balance.
Le détail du DNS, encore une fois
Cela vaut la peine d’être répété, car cela s’applique chaque fois que curl est utilisé avec SOCKS. socks5://
résout les noms d’hôte sur votre machine ; socks5h://
envoie le nom d’hôte au proxy. La première option divulgue chaque hôte que vous visitez à votre résolveur local, même si le trafic est correctement acheminé, et peut vous fournir une adresse géographiquement erronée pour les sites dont l’infrastructure dépend de la localisation.
Utilisez socks5h://
sauf si vous avez une raison spécifique de ne pas le faire.
Et la partie où nous nous dissuadons nous-mêmes de conclure une vente
Si vous téléchargez un fichier, appelez une API pour laquelle vous disposez d’identifiants, ou vérifiez si un service est opérationnel, vous n’avez absolument pas besoin de proxy. Les proxys trouvent leur utilité dans ces outils pour la vérification géographique et pour les tâches volumineuses soumises à des limites de débit par adresse. Pour tout le reste, ils ajoutent de la latence, un point de défaillance et une facture.
Quand aucun des deux outils ne convient
Plusieurs situations courantes nécessitent une autre approche, et se tourner vers l’un ou l’autre de ces outils revient à perdre un après-midi.
La page est générée par JavaScript. Les deux outils récupèrent ce que le serveur envoie. Si le contenu est assemblé par la suite dans le navigateur, vous obtenez une coquille vide et aucun indicateur ne permet d’y remédier. Vous avez besoin d’un navigateur sans interface graphique — Playwright, Puppeteer ou un outil similaire.
Vous devez interagir avec la page. Cliquer, faire défiler, remplir des formulaires, attendre qu’un élément s’affiche. La réponse est la même.
Vous développez une solution maintenable dans le code. L’appel de curl depuis une application est un raccourci courant qui vieillit mal. Utilisez la bibliothèque HTTP de votre langage ou les liaisons de libcurl pour bénéficier d’une gestion correcte des erreurs.
Vous devez synchroniser un répertoire dans les deux sens. rsync est l’outil qu’il vous faut, et il est nettement plus performant que wget en mode récursif.
Vous effectuez un transfert entre des serveurs que vous contrôlez. scp, rsync ou sftp — des outils spécialement conçus, plus rapides, qui gèrent correctement les autorisations et les transferts partiels.
Vous devez inspecter ou modifier le trafic en cours de transmission. Un proxy d’interception est l’outil qu’il vous faut.
Vous téléchargez des fichiers multimédias depuis une plateforme vidéo. Des outils spécialement conçus gèrent l’analyse du manifeste et l’assemblage du flux, ce qu’aucune de ces solutions ne permet de faire.
Les données sont proposées d’une autre manière. Une API, un téléchargement en masse, un ensemble de données public, un flux RSS. La vérification prend dix minutes et met souvent fin au projet avant même qu’il ne commence.
Mise en garde concernant le téléchargement récursif
Une mise en garde spécifique concernant l’wget -r : cette fonction est puissante, mais peut facilement cibler des éléments que vous ne souhaitiez pas.
Sans -np, elle peut remonter dans les répertoires parents. Sans --level, elle peut descendre très loin. Sans --wait, il enverra des requêtes aussi vite que le serveur y répondra, ce qui est impoli envers l’infrastructure d’autrui et un bon moyen de se faire bloquer.
Au minimum : wget -r -np --level=3 --wait=1 URL. Et vérifiez d’abord robots.txt ainsi que les conditions d’utilisation du site — wget respecte robots.txt par défaut, et la désactiver est un choix plutôt qu’une simple commodité.
Questions fréquentes
Quelle est la différence entre curl et wget ?
curl fonctionne comme cat : il récupère les données et les affiche sur la sortie standard. wget fonctionne comme cp : il récupère les données et les enregistre dans un fichier. curl prend en charge beaucoup plus de protocoles, les envois, les proxys SOCKS et les transferts parallèles ; wget peut télécharger de manière récursive et créer des miroirs de sites, ce que curl ne peut absolument pas faire.
curl est-il meilleur que wget ?
Aucun des deux n’est meilleur que l’autre. curl est un outil de transfert s’appuyant sur une bibliothèque et offrant une gamme de protocoles bien plus large ; wget est un téléchargeur doté de meilleurs paramètres par défaut pour le téléchargement et d’une capacité récursive unique. La plupart des utilisateurs ont intérêt à disposer des deux.
curl peut-il télécharger de manière récursive comme wget ?
Non. curl récupère les URL que vous lui fournissez et n’analyse pas le HTML ni ne détecte les liens. Le téléchargement récursif et la création de sites miroirs sont des fonctionnalités propres à wget, et le responsable de curl lui-même considère cela comme le principal atout de wget.
Pourquoi curl ne suit-il pas les redirections ?
C’est voulu. curl se contente de rapporter ce que le serveur a indiqué plutôt que d’effectuer des requêtes que vous n’avez pas demandées. Ajoutez -L pour que les redirections soient suivies. wget suit les redirections par défaut, car son objectif est de récupérer le fichier, et celui-ci a été déplacé.
Quel est le plus rapide, curl ou wget ?
Pour un transfert unique, la différence est négligeable : les deux sont limités par le réseau. curl peut effectuer plusieurs transferts en parallèle grâce à l’option -Z, ce qui le rend nettement plus rapide lors de la récupération de nombreuses petites ressources.
wget prend-il en charge les proxys SOCKS ?
Pas en natif. curl prend en charge les proxys SOCKS4, SOCKS5 et HTTPS ; wget utilise les variables d’environnement standard des proxys HTTP. Pour utiliser SOCKS avec wget, vous avez besoin d’un wrapper tel que proxychains ou d’un pont local.
Lequel dois-je utiliser dans un script ?
L’un ou l’autre, avec des options explicites. Pour les API et tout ce qui nécessite d’inspecter la réponse, curl -sSfL --max-time 30. Pour récupérer des fichiers, wget --tries=3 --timeout=30. Ne vous fiez pas aux paramètres par défaut de ces outils dans le cadre d’une automatisation.
curl ou wget est-il installé par défaut ?
curl est préinstallé sur macOS et Windows 10 et 11. wget est standard sur la plupart des distributions Linux, mais souvent absent sur macOS et Windows. Pour les scripts multiplateformes, il est plus prudent de partir du principe que curl est installé.
Conclusion
La comparaison s'avère plus simple que ne le laisse supposer la popularité de ces outils, car ceux-ci ont été conçus autour de verbes différents.
curl transfère. wget télécharge. curl écrit sur la sortie standard, comme dans cat ; il fait exactement ce qu’on lui demande et rend compte du reste — c’est pourquoi il ne suit pas les redirections, ne tente pas de nouvelles tentatives et nécessite un indicateur pour écrire un fichier. wget écrit sur le disque, comme dans cp, et tout ce qu’il fait par défaut découle de l’objectif final : obtenir un fichier existant.
Quatre fonctionnalités déterminent d’emblée le choix, et si votre tâche implique l’une d’entre elles, le reste de la comparaison n’a aucune pertinence. Le téléchargement récursif et la mise en miroir de sites sont l’apanage de wget — le responsable de curl lui-même le qualifie de principal atout de wget, et curl n’a pas d’équivalent. Les téléchargements, les proxys SOCKS et les transferts parallèles sont l’apanage de curl.
En dehors de cela, les deux outils fonctionnent, et les différences pratiques se limitent à la syntaxe des options et aux paramètres par défaut. Faites attention à la confusion entre « -O » lors de la conversion des commandes d’un outil à l’autre, car ces termes ont des significations opposées dans chacun d’eux. Et dans tout processus automatisé, énoncez explicitement vos intentions plutôt que de vous fier aux suppositions de l’un ou l’autre outil — « curl -sSfL --max-time 30 » et « wget --tries=3 --timeout=30 » sont deux commandes qui auront toujours du sens pour quiconque les lira l’année prochaine.
Concernant les proxys : nous en vendons, mais la plupart des utilisations de ces outils n’en nécessitent pas. Lorsque vous en avez besoin, curl offre une prise en charge plus étendue, et le détail qui importe davantage que l’outil lui-même est d’utiliser socks5h:// plutôt que socks5:// afin que vos requêtes de nom d’hôte empruntent le même chemin que votre trafic.
Honnêtement, je recommande d’installer les deux. Ils sont légers, gratuits, et le débat sur lequel est le meilleur est réglé depuis des années par le fait que la plupart des machines en service les ont tous les deux.
