Comment utiliser Wget avec un proxy (et éviter les pièges les plus courants)

Configurer un proxy avec Wget peut sembler être une histoire de cinq secondes — jusqu’au moment où vous perdez une heure à comprendre pourquoi vos requêtes passent complètement à côté du proxy, sans le moindre message d’erreur. J’ai vu ça arriver aussi bien à des administrateurs système chevronnés qu’à des développeurs débutants.

Le vrai souci vient presque jamais du proxy lui-même. Le problème, c’est plutôt les quatre endroits différents où Wget peut lire les paramètres de proxy, les échecs silencieux quand on utilise la mauvaise casse de variable, et les particularités des réseaux d’entreprise que la documentation n’explique jamais vraiment. Ce guide passe en revue toutes les méthodes pour configurer Wget avec un proxy, l’ordre de priorité exact quand plusieurs méthodes se contredisent, des exemples réels de sortie terminal pour chaque erreur fréquente, ainsi qu’une section dédiée à Windows et aux utilisateurs derrière un pare-feu d’entreprise — un public que presque tous les autres tutoriels font comme s’il n’existait pas.

• Niveau de difficulté : Débutant à intermédiaire
• Temps nécessaire : ~15 minutes pour lire et configurer ; ~2 minutes une fois que vous maîtrisez la méthode
• Ce qu’il vous faut : Une installation fonctionnelle de Wget (instructions ci-dessous), une adresse de proxy (hôte + port) et, éventuellement, des identifiants de proxy

Essayez Thunderbit pour extraire des données structurées

Qu’est-ce que Wget et pourquoi l’utiliser avec un proxy ?

Wget est un outil en ligne de commande qui télécharge des fichiers et des pages web depuis Internet, sans navigateur. La propre description de GNU le présente comme un « téléchargeur réseau non interactif » — autrement dit, il tourne en arrière-plan, reprend les transferts interrompus et gère les téléchargements récursifs sans qu’un humain ait besoin de cliquer.

Dans ce contexte, un proxy est un serveur intermédiaire. Au lieu que votre machine se connecte directement au site cible, Wget envoie la requête au proxy, qui la relaie ensuite. Les raisons les plus courantes d’utiliser cette approche sont :

• Respect des politiques de pare-feu d’entreprise — votre société exige que tout le trafic sortant passe par un proxy approuvé
• Confidentialité et gestion de l’adresse IP — les requêtes apparaissent avec l’IP du proxy, pas la vôtre
• Tests géographiques — accéder à des ressources limitées par région ou tester le comportement d’un CDN depuis un emplacement précis
• Chaînes de collecte de données — télécharger du HTML via des proxys tournants pour de la recherche ou de la surveillance
• Environnements CI/CD — des runners de build sur des réseaux verrouillés qui ne peuvent atteindre Internet que via un proxy

Wget prend en charge nativement les proxys HTTP, HTTPS et FTP. Il ne prend pas en charge SOCKS5. Si vous avez besoin de SOCKS5, curl gère nativement les schémas socks4://, socks5:// et socks5h:// — ou vous pouvez encapsuler Wget avec un outil comme proxychains4.

Comment installer Wget sous Linux, macOS et Windows

Avant de configurer les proxys, il faut installer Wget sur votre machine. C’est rapide : c’est un prérequis, pas le cœur du sujet.

Linux (Debian/Ubuntu et RHEL/CentOS)

# Debian/Ubuntu
sudo apt update
sudo apt install wget

# RHEL/CentOS/Fedora
sudo dnf install wget

# Vérifier
wget --version

Ubuntu 24.04 LTS embarque Wget 1.21.4, tandis que Debian Trixie propose la version 1.25.0. Les paquets de CentOS Stream 10 indiquent la version 1.24.5.

macOS (Homebrew)

brew install wget
wget --version

La formule Homebrew distribue actuellement Wget 1.25.0 stable, avec 396 818 installations au cours de l’année écoulée.

Windows (Chocolatey et installation manuelle)

choco install wget
wget --version

Le package GNU Wget de Chocolatey affiche plus de 10 millions de téléchargements au total, même s’il est actuellement en version 1.21.4. L’exécutable se trouve généralement dans C:\ProgramData\chocolatey\bin\wget.exe.

Un point important pour les utilisateurs Windows : l’emplacement où Wget cherche le fichier .wgetrc varie selon la build. Les détails sont donnés dans la section Windows plus bas.

4 façons d’utiliser Wget avec un proxy (et laquelle choisir)

Quatre méthodes, chacune avec sa portée et son niveau de priorité :

1. Options -e en ligne de commande — usage ponctuel, une seule commande
2. Fichier de configuration utilisateur (~/.wgetrc) — s’applique à toutes les commandes Wget de votre utilisateur
3. Fichier de configuration système (/etc/wgetrc) — s’applique à tous les utilisateurs de la machine
4. Variables d’environnement (http_proxy, https_proxy) — s’applique à toute la session de terminal

Méthode 1 : options en ligne de commande (proxy ponctuel)

Idéal pour les tests rapides. Les paramètres disparaissent une fois la commande terminée.

wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip

Pour une cible HTTPS :

wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/

Petit test rapide : récupérer votre IP apparente via le proxy :

wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me

Si la sortie affiche l’IP du proxy au lieu de la vôtre, c’est bon.

Méthode 2 : fichier de configuration utilisateur (~/.wgetrc)

Ajoutez ces lignes à ~/.wgetrc (créez le fichier s’il n’existe pas) :

use_proxy = on
http_proxy = http://proxy.company.com:8080/
https_proxy = http://proxy.company.com:8080/
no_proxy = localhost,127.0.0.1,.internal.company.com

Remarquez les espaces autour de = — c’est la syntaxe documentée de .wgetrc. Toutes les commandes Wget lancées par cet utilisateur passeront désormais par le proxy.

Méthode 3 : configuration à l’échelle du système (/etc/wgetrc)

Les mêmes directives que dans ~/.wgetrc, mais placées dans le fichier système. GNU décrit cela comme un fichier de démarrage global — le chemin exact dépend du préfixe d’installation. Emplacements courants :

• /etc/wgetrc (la plupart des gestionnaires de paquets Linux)
• /usr/local/etc/wgetrc (certaines installations Homebrew)
• Le chemin affiché par wget --version sous « Wgetrc: »

C’est utile pour des serveurs partagés, des conteneurs Docker ou tout environnement où tous les utilisateurs doivent passer par le même proxy.

Méthode 4 : variables d’environnement (http_proxy / https_proxy)

export http_proxy=http://HOST:PORT/
export https_proxy=http://HOST:PORT/
export no_proxy=localhost,127.0.0.1,.internal.company.com

Ces variables affectent toute votre session shell, pas seulement Wget. Des outils comme curl les utiliseront aussi.

Avertissement essentiel : Wget ne lit que les noms de variables d’environnement en minuscules. HTTP_PROXY (en majuscules) est ignoré silencieusement. Aucune erreur, aucun avertissement, rien du tout. Je montrerai la sortie exacte du terminal dans la section des pièges, mais il vaut mieux retenir ce point dès maintenant.

Priorité des méthodes de proxy : qu’est-ce qui l’emporte quand plusieurs méthodes sont définies ?

Si un proxy est défini à la fois dans vos variables d’environnement, dans .wgetrc et en ligne de commande, lequel gagne ? Comme ce n’est expliqué clairement nulle part, je l’ai testé.

Voici l’ordre de priorité, testé et documenté :

Priorité	Méthode	Portée	Écrase
1 (la plus élevée)	Options CLI -e	Une seule commande	Tout
2	~/.wgetrc	Utilisateur courant	Config système + variables d’environnement
3	/etc/wgetrc	Système entier	Variables d’environnement uniquement
4 (la plus faible)	Variables d’environnement http_proxy / https_proxy	Session shell	Rien

J’ai vérifié cela sur Wget 1.25.0 en définissant des proxys contradictoires à chaque niveau. Avec l’environnement pointant vers le port 3128, le fichier de configuration vers le 3129, et la ligne de commande vers le 3130 :

• La configuration l’emporte sur l’environnement : Wget s’est connecté au port 3129 et a ignoré 3128.
• La ligne de commande l’emporte sur la configuration : Wget s’est connecté au port 3130 et a ignoré 3129 et 3128.

L’option de secours est --no-proxy. Elle contourne tous les paramètres de proxy, quelle que soit leur source :

wget --no-proxy https://internal-server.company.com/report.pdf

Cas pratique : votre administrateur système a défini un proxy dans /etc/wgetrc, mais vous devez accéder directement à un serveur interne. Utilisez --no-proxy pour cette seule commande au lieu de modifier la configuration système.

Comment utiliser Wget avec un proxy authentifié

La plupart des proxys grand public et professionnels exigent un nom d’utilisateur et un mot de passe. Wget le prend en charge via deux approches, toutes deux basées sur l’authentification HTTP Basic pour les identifiants du proxy.

Identifiants intégrés dans l’URL du proxy

wget -e use_proxy=on \
  -e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
  http://example.com/file.zip

Cela fonctionne aussi dans .wgetrc :

http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/

Utiliser les options --proxy-user et --proxy-password

wget --proxy-user=USERNAME --proxy-password=PASSWORD \
  -e use_proxy=on \
  -e http_proxy=http://proxy.company.com:8080/ \
  http://example.com/file.zip

Ces options prennent le pas sur tout identifiant user:pass@ intégré dans l’URL du proxy.

Protéger vos identifiants

Les deux méthodes exposent des identifiants. GNU avertit que les mots de passe passés en ligne de commande sont visibles via ps ou d’autres outils qui listent les processus. Mesures de protection :

• Machines à utilisateur unique : stockez les identifiants dans ~/.wgetrc et verrouillez le fichier : chmod 600 ~/.wgetrc
• Pipelines CI/CD : utilisez les secrets chiffrés de GitHub Actions ou l’équivalent de votre plateforme. Exposez-les comme variables d’environnement en minuscules dans l’étape — ne les écrivez jamais en dur dans le YAML.
• Builds Docker : n’utilisez pas ARG ni ENV pour des secrets. La documentation Docker le précise : les arguments de build peuvent rester dans l’image finale. Utilisez plutôt les montages de secrets BuildKit.
• Contrôle de version : ne committez jamais un .wgetrc contenant des identifiants. Ajoutez-le à .gitignore.

Une nuance spécifique à Wget dans GitHub Actions : par convention, les noms des secrets sont stockés en majuscules, mais les variables d’environnement que vous exposez à Wget doivent être en minuscules (http_proxy, pas HTTP_PROXY).

Comment utiliser Wget avec un proxy sous Windows et derrière un pare-feu d’entreprise

La plupart des articles sur le sujet s’arrêtent à « installez-le avec Chocolatey ». Si vous êtes sous Windows ou derrière un proxy d’entreprise, c’est là que vos problèmes commencent.

Où Windows cherche le fichier .wgetrc

La documentation GNU indique que Wget lit $HOME/.wgetrc sauf si la variable d’environnement WGETRC pointe ailleurs. Sous Windows, $HOME peut correspondre à %USERPROFILE% (par exemple C:\Users\alice) — ou non — selon que vous utilisez la version Chocolatey, MSYS2, Git Bash ou un binaire autonome.

Mon conseil : évitez les suppositions et utilisez l’option --config pour un comportement déterministe :

wget --config=C:\Users\alice\wgetrc https://example.com/file.zip

Pour tester si votre build lit un fichier de configuration à un emplacement précis, créez un fichier test qui pointe vers un proxy volontairement invalide :

; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/

Puis exécutez :

wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/

Si Wget tente de se connecter à 127.0.0.1:3128, c’est qu’il a bien lu le fichier.

Définir les variables d’environnement proxy sous Windows

CMD (session uniquement) :

set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/

PowerShell (session uniquement) :

$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/

Permanent (persiste après redémarrage) :

setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/

Après setx, vous devez ouvrir une nouvelle fenêtre de terminal. La session en cours ne verra pas le changement.

Pièges courants en entreprise : fichiers PAC, authentification NTLM et trouver l’adresse du proxy

Trois points bloquent régulièrement les utilisateurs en entreprise :

Fichiers PAC : de nombreuses entreprises utilisent des fichiers Proxy Auto-Configuration (PAC) — des scripts JavaScript qui indiquent au navigateur quel proxy utiliser pour quelle URL. Wget n’embarque pas d’interpréteur JavaScript, donc il ne peut pas lire les fichiers PAC. La documentation de curl dit la même chose. La solution : ouvrez le fichier PAC (ou demandez à l’IT), repérez le résultat PROXY host:port pour votre domaine cible, puis configurez cette adresse statique dans Wget.

Authentification NTLM : l’authentification proxy de Wget ne gère que Basic auth. Si votre proxy d’entreprise exige NTLM et que vous obtenez une erreur 407 Proxy Authentication Required, ne perdez pas de temps à tester différentes syntaxes de --proxy-user. Installez Cntlm — un relais local qui gère NTLM/NTLMv2 et présente à Wget une interface compatible Basic auth. Cntlm est toujours maintenu (dernière mise à jour en octobre 2025, ~395 téléchargements/semaine).

Arbre de décision pour les utilisateurs derrière un proxy d’entreprise :

1. Essayez set http_proxy=http://VOTRE_PROXY:PORT/ puis lancez Wget.
2. Si vous obtenez une erreur 407 et que votre entreprise utilise NTLM → installez Cntlm, configurez-le avec vos identifiants de domaine, puis faites pointer Wget vers le port local de Cntlm (généralement http://127.0.0.1:3128/).
3. Si l’entreprise utilise un fichier PAC → extrayez l’adresse réelle PROXY host:port du PAC ou demandez à l’IT l’adresse statique du proxy.

Ports de proxy d’entreprise courants : 3128 (style Squid), 8080 (proxy HTTP général), 8888 (proxys de débogage comme Fiddler/Charles). Ce sont des conventions, pas des garanties.

Pièges fréquents lors de l’utilisation de Wget avec un proxy (avec des erreurs réelles)

Passons maintenant à la partie la plus utile promise dans le titre. Tous les exemples ci-dessous ont été reproduits avec Wget 1.25.0 (macOS, Homebrew) le 2026-06-01.

Piège 1 : absence du préfixe http://

Certains guides anciens affirment que cela casse toujours tout. Avec Wget 1.25.0, définir http_proxy=127.0.0.1:3128 fonctionne en réalité : Wget ajoute silencieusement http:// devant :

Prepended http:// to '127.0.0.1:3128'
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:38:15--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Operation not permitted.

La connexion s’est bien faite vers le bon proxy. Mais je recommande quand même d’inclure systématiquement le préfixe http:// et une barre oblique finale. Cela évite toute ambiguïté selon les versions de Wget et rend la syntaxe des identifiants (http://user:pass@host:port/) parfaitement claire.

Piège 2 : use_proxy=yes ou use_proxy=on ?

Dans mes tests sur Wget 1.25.0, yes et on fonctionnaient tous les deux. En revanche, les valeurs invalides échouent avec une erreur explicite :

wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.

Utilisez on pour la compatibilité la plus large — cela correspond au format booléen documenté dans le manuel et à l’indication d’erreur fournie par Wget.

Piège 3 : HTTP_PROXY en majuscules ignoré silencieusement

C’est le piège le plus frustrant parce qu’il n’y a aucune erreur. Wget se connecte directement, comme si aucun proxy n’avait été défini.

Majuscules (ne fonctionne pas — aucun proxy utilisé) :

HTTP_PROXY=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:06--  http://example.com/
Resolving example.com (example.com)... 198.18.58.61
Connecting to example.com (example.com)|198.18.58.61|:80... connected.
HTTP request sent, awaiting response... 200 OK

Minuscules (fonctionne — tentative de passage par le proxy) :

http_proxy=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:16--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.

Vous voyez la différence ? La version en majuscules résout example.com directement. La version en minuscules essaie le proxy. Aucune alerte dans les deux cas. curl a une particularité similaire : il accepte généralement les majuscules pour la plupart des variables de proxy, mais rejette explicitement HTTP_PROXY pour des raisons de sécurité.

Correctif : utilisez toujours http_proxy et https_proxy en minuscules.

Piège 4 : un ancien proxy dans .wgetrc provoque « Connection refused »

Si vous (ou votre administrateur système, ou une image Docker) avez laissé une vieille adresse de proxy dans un fichier de configuration, vous verrez quelque chose comme ceci :

Spider mode enabled. Check if remote file exists.
--2026-06-01 10:39:10--  http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.

L’erreur pointe vers l’ancien proxy, pas vers le site cible. Ordre de diagnostic (en suivant la hiérarchie de priorité) :

1. Vérifiez votre commande pour des options -e ou des alias shell
2. Vérifiez ~/.wgetrc (ou le fichier indiqué par WGETRC)
3. Vérifiez la config système (chemin affiché par wget --version)
4. Vérifiez l’environnement : env | grep -i proxy

Pour déboguer, --no-config est votre meilleur allié : il indique à Wget d’ignorer tous les fichiers de configuration :

wget --no-config --spider http://example.com/

Si cela fonctionne, le problème vient d’un fichier de configuration.

Piège 5 : confusion autour de la syntaxe du proxy HTTPS

C’est un point qui piège beaucoup de monde. Quand vous définissez https_proxy, l’URL du proxy elle-même est généralement en http://, pas en https://. C’est parce que Wget envoie une requête HTTP CONNECT via le proxy pour créer un tunnel vers la session HTTPS chiffrée.

Correct :

https_proxy=http://proxy.company.com:8080/
wget https://example.com/

Wget envoie alors CONNECT example.com:443 HTTP/1.1 au proxy, puis tunnelise le HTTPS à travers celui-ci.

Incorrect (pour des URL cibles HTTP avec un endpoint proxy HTTPS) :

http_proxy=https://127.0.0.1:18082/
wget http://example.com/

Error in proxy URL https://127.0.0.1:18082/: Must be HTTP.

Wget 1.25.0 refuse carrément https:// comme URL de proxy pour des cibles HTTP. Utilisez https_proxy=http://HOST:PORT/ sauf si votre organisation a explicitement documenté un endpoint proxy HTTPS et que vous l’avez testé avec votre build de Wget.

Mémo des commandes Wget avec proxy (référence rapide à garder sous la main)

Ajoutez ce tableau à vos favoris. Il regroupe toutes les options et directives de configuration Wget liées au proxy en un seul endroit.

Option / Directive	Contexte	Exemple	Remarques
-e use_proxy=on	CLI	-e use_proxy=on	on est le plus sûr ; certaines builds acceptent aussi yes
-e http_proxy=	CLI	-e http_proxy=http://proxy:8080/	Inclure le préfixe http:// et le / final
-e https_proxy=	CLI	-e https_proxy=http://proxy:8080/	L’URL du proxy est généralement en http://, même pour des cibles HTTPS
--proxy-user	CLI	--proxy-user=admin	Écrase le format intégré user:pass@
--proxy-password	CLI	--proxy-password=secret	Visible via ps — à éviter sur des systèmes partagés
--no-proxy	CLI	--no-proxy	Ignore TOUS les réglages proxy, quelle que soit leur source
--no-config	CLI	--no-config	Ignore tous les fichiers de configuration — utile pour le débogage
--config=FILE	CLI	--config=/tmp/wgetrc	Chemin de config déterministe — idéal pour Windows et CI
http_proxy	.wgetrc / env	http_proxy = http://proxy:8080/	Le fichier de config utilise des espaces autour de = ; la variable d’env est en minuscules
https_proxy	.wgetrc / env	https_proxy = http://proxy:8080/	Même format que http_proxy
ftp_proxy	.wgetrc / env	ftp_proxy = http://proxy:8080/	Pour les téléchargements FTP
no_proxy	.wgetrc / env	no_proxy = localhost,127.0.0.1,.corp	Liste de domaines séparés par des virgules
proxy_user	.wgetrc	proxy_user = admin	Équivalent à --proxy-user
proxy_password	.wgetrc	proxy_password = secret	Protégez le fichier avec chmod 600

Quand Wget + proxy n’est pas le bon choix (et quoi utiliser à la place)

Après toute cette configuration de proxy, voici un point de vue un peu à contre-courant : parfois, il ne faut tout simplement pas s’embêter.

Beaucoup de personnes qui cherchent « wget proxy » n’essaient pas vraiment de télécharger un seul fichier. Elles cherchent à collecter des données structurées sur des sites web — prix de produits, listes de contacts, annonces immobilières — et elles se tournent par défaut vers Wget parce que c’est l’outil en ligne de commande qu’elles connaissent. Le problème, c’est que Wget fournit du HTML brut. Il faut ensuite l’analyser, le nettoyer et le structurer. Et si vous faites tourner des proxys pour éviter les blocages, vous vous retrouvez à maintenir une liste de proxys, un script de téléchargement, un parseur et une chaîne d’export.

Votre objectif	Meilleur outil	Pourquoi
Télécharger un fichier unique via un proxy	wget avec options de proxy	Simple, une seule commande
Miroiter un site ou un répertoire via un proxy	wget --recursive + config proxy	La récupération récursive est un point fort de Wget
Extraire des données structurées (tableaux, listes, contacts)	Thunderbit	Wget donne du HTML brut — il faut encore le parser. L’IA de Thunderbit lit la page et exporte des données structurées vers Excel, Google Sheets, Airtable ou Notion sans code. Son scraping cloud gère la rotation d’IP et les mesures anti-bot, ce qui vous évite complètement la configuration du proxy.
Appels d’API REST via un proxy	curl	Meilleur contrôle des en-têtes, support natif du JSON, support SOCKS5
Collecte de données récurrente et planifiée	Thunderbit Scheduled Scraper ou cron + wget	Thunderbit s’adapte lorsque la structure des pages change ; les scripts cron + wget cassent parfois sans prévenir

Wget est excellent pour télécharger des fichiers. Mais le workflow « configurer le proxy → faire tourner les IP → télécharger le HTML → écrire un parseur → exporter vers un tableur » comporte beaucoup trop d’étapes quand ce que vous voulez réellement, c’est un tableau de données. Si cela vous ressemble, notre extension Chrome prend en charge tout le pipeline en deux clics. Pour en savoir plus, consultez nos guides sur le web scraping IA et le web scraping sans code.

Mais si votre objectif est « télécharger ce fichier ZIP à travers un proxy d’entreprise », Wget reste le bon outil — et vous savez maintenant comment le configurer correctement.

Points clés à retenir

En résumé :

• Quatre méthodes, une priorité claire : les options CLI priment sur la config utilisateur, qui prime sur la config système, qui prime sur les variables d’environnement. --no-proxy l’emporte sur tout.
• Utilisez toujours les minuscules pour les variables d’environnement (http_proxy, pas HTTP_PROXY). Les majuscules sont ignorées silencieusement.
• Incluez toujours http:// dans l’URL du proxy, même pour https_proxy. Le point d’entrée du proxy est HTTP ; il relaie HTTPS via CONNECT.
• Utilisez on pour les valeurs booléennes dans .wgetrc et avec les options -e. C’est le choix le plus sûr selon les versions de Wget.
• Utilisateurs Windows : utilisez --config=C:\path\to\wgetrc pour éviter toute ambiguïté sur le fichier de config. Utilisez set (CMD) ou $env: (PowerShell) pour les variables proxy de session.
• Utilisateurs en entreprise : Wget ne lit pas les fichiers PAC et ne gère pas nativement l’authentification NTLM. Utilisez Cntlm comme relais local si nécessaire.
• Ajoutez le mémo aux favoris ci-dessus — il vous évitera de relire tout l’article à chaque fois que vous devez vous souvenir du nom d’une option.

Si votre vrai besoin est l’extraction de données structurées, Thunderbit ou curl peuvent être plus adaptés. Le meilleur débogage est celui que vous n’avez jamais à lancer.

FAQ

1. Wget prend-il en charge les proxys SOCKS5 ?

Non. GNU Wget 1.x ne prend en charge que les proxys HTTP, HTTPS et FTP. Le projet Wget2 a reçu une demande de fonctionnalité pour SOCKS5, mais ce n’est pas une option standard documentée. Pour SOCKS5, utilisez curl avec ses schémas natifs socks5:// ou socks5h://, ou encapsulez Wget avec proxychains4 pour forcer le routage via SOCKS.

2. Pourquoi mon réglage de proxy est-il ignoré quand j’utilise HTTP_PROXY en majuscules ?

Wget ne lit que les noms de variables d’environnement en minuscules (http_proxy, https_proxy, ftp_proxy, no_proxy). Les variantes en majuscules comme HTTP_PROXY sont ignorées silencieusement — aucune erreur, aucun avertissement. C’est l’un des problèmes les plus fréquents et les plus frustrants, parce qu’aucun indice n’indique que quelque chose ne va pas. Utilisez toujours les minuscules.

3. Comment contourner le proxy pour certains domaines ?

Utilisez la directive no_proxy, soit comme variable d’environnement, soit dans .wgetrc :

export no_proxy=localhost,127.0.0.1,.mycompany.com

Ou dans ~/.wgetrc :

no_proxy = localhost,127.0.0.1,.mycompany.com

Les domaines sont séparés par des virgules. Un point initial (.mycompany.com) correspond à tous les sous-domaines.

4. Peut-on utiliser Wget avec des proxys tournants ?

Wget n’a pas de rotation de proxy intégrée. Deux options s’offrent à vous : utiliser un fournisseur de proxy qui fait tourner les IP côté serveur (vous conservez la même adresse de passerelle, mais l’IP de sortie change), ou écrire un script shell qui choisit un proxy au hasard dans une liste et le passe via -e http_proxy=... à chaque exécution. Pour quelque chose de plus complexe — rotation automatique, logique de retry, gestion anti-bot — un outil de scraping dédié est généralement plus adapté.

5. Quelle est la différence entre http_proxy et https_proxy dans Wget ?

http_proxy est utilisé lorsque l’URL cible commence par http://. https_proxy est utilisé lorsque l’URL cible commence par https://. Dans les deux cas, l’URL du proxy elle-même est généralement une adresse http://. Pour les cibles HTTPS, Wget envoie une requête HTTP CONNECT via le proxy pour établir un tunnel, et le chiffrement HTTPS réel se fait de bout en bout entre Wget et le serveur cible. Le proxy voit le nom d’hôte (via la requête CONNECT), mais ne peut pas lire le trafic chiffré.

Essayez Thunderbit pour le web scraping IA Get Started Free

En savoir plus

• Meilleurs outils automatisés de web scraping
• Comment extraire des données d’un site web avec Python
• Meilleurs services de web scraping
• Web scraping sans se faire bloquer
• Comment configurer un serveur proxy