Auf dem Papier sind es zwei Zeilen Konfiguration, in der Praxis kostet es manchmal eine Stunde: Ein Wget-Proxy gilt als trivial, bis die Anfragen den Proxy klammheimlich umgehen und Wget dazu keinen Mucks von sich gibt. Diese Erfahrung machen Junior-Entwickler genauso wie altgediente Sysadmins.
Schuld ist dabei selten der Proxy. Verantwortlich sind in den meisten Fällen drei Dinge: Wget liest seine Proxy-Vorgaben aus gleich vier Quellen, vertippte Variablen scheitern lautlos, und Firmennetzwerke bringen Eigenheiten mit, die kein Handbuch sauber dokumentiert. Genau diese Lücken schließt der folgende Leitfaden – mit jeder Konfigurationsmethode, den exakten Prioritätsregeln im Konfliktfall, echten Terminalausgaben zu typischen Fehlern und einem eigenen Kapitel für Windows und Firmenproxys, also für die Gruppe, die andere Tutorials konsequent übergehen.
- Schwierigkeitsgrad: Anfänger bis Fortgeschrittene
- Zeitaufwand: rund 15 Minuten zum Lesen und Einrichten; etwa 2 Minuten mit etwas Routine
- Voraussetzungen: eine lauffähige Wget-Installation (Anleitung folgt), eine Proxy-Adresse aus Host und Port sowie optional Zugangsdaten
Thunderbit für strukturierte Datenerfassung testen
Wget und Proxy: Was steckt dahinter?
Mit Wget lädst du Dateien und ganze Webseiten direkt aus dem Netz – ohne einen Browser zu öffnen, allein über die Kommandozeile. In der GNU-Beschreibung heißt es „non-interactive network downloader“: ein Downloader fürs Hintergrundgeschehen, der abgebrochene Übertragungen wieder aufnimmt und rekursiv ganze Verzeichnisbäume holt, ganz ohne Mausklick.
Ein Proxy schiebt sich als Zwischenstation in diesen Ablauf. Dein Rechner spricht dann nicht mehr direkt mit der Zielseite, sondern Wget übergibt die Anfrage an den Proxy, der sie weiterleitet. Üblich ist das aus diesen Gründen:
- Firmenvorgaben – das Unternehmen verlangt, dass jeder ausgehende Traffic über einen freigegebenen Proxy läuft
- Datenschutz und IP-Steuerung – nach außen erscheint die IP des Proxys statt deiner eigenen
- Geo-Tests – regional begrenzte Inhalte abrufen oder das CDN-Verhalten aus einer bestimmten Region prüfen
- Datenpipelines – HTML über rotierende Proxys für Recherche oder Monitoring beziehen
- CI/CD-Umgebungen – abgeschottete Build-Runner, die nur über einen Proxy nach draußen kommen
Nativ beherrscht Wget HTTP-, HTTPS- und FTP-Proxys. SOCKS5 bleibt dagegen außen vor. Brauchst du SOCKS5, springt curl mit nativer Unterstützung für socks4://, socks5:// und socks5h:// ein – alternativ kapselst du Wget über ein Werkzeug wie proxychains4.
Wget unter Linux, macOS und Windows installieren
Ohne installiertes Wget kein Proxy. Dieser Abschnitt bleibt knapp – er ist nur die Pflicht vor der eigentlichen Kür.
Linux (Debian/Ubuntu und RHEL/CentOS)
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# Prüfen
wget --version
Aktuell stehen die Versionsstände so: Ubuntu 24.04 LTS bringt Wget 1.21.4 mit, Debian Trixie setzt auf 1.25.0 und CentOS Stream 10 führt 1.24.5.
macOS (Homebrew)
brew install wget
wget --version
Über die Homebrew-Formel kommt derzeit das stabile Wget 1.25.0 – im vergangenen Jahr mit 396.818 Installationen.
Windows (Chocolatey und manuelle Installation)
choco install wget
wget --version
Insgesamt hat das GNU-Wget-Paket bei Chocolatey die Marke von 10 Millionen Downloads überschritten, hängt aber noch bei Version 1.21.4. Die Binärdatei findet sich in der Regel unter C:\ProgramData\chocolatey\bin\wget.exe.
Eine Besonderheit gleich vorweg: Wo Wget unter Windows seine .wgetrc erwartet, richtet sich nach dem konkreten Build. Mehr dazu im Windows-Kapitel.
Vier Wege zum Wget-Proxy – und wann welcher passt
Es gibt vier Methoden, jede mit eigenem Geltungsbereich und eigener Priorität:
- Kommandozeilen-Flags über
-e– für den einmaligen Befehl - Benutzerkonfiguration (
~/.wgetrc) – greift bei allen Wget-Aufrufen dieses Nutzers - Systemkonfiguration (
/etc/wgetrc) – greift für alle Nutzer des Rechners - Umgebungsvariablen (
http_proxy,https_proxy) – greifen für die gesamte Shell-Sitzung
Methode 1: Kommandozeilen-Flags (einmaliger Proxy)
Perfekt für den schnellen Test: Nach dem Befehl ist die Einstellung wieder weg.
wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip
Bei HTTPS-Zielen:
wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/
Ein schneller Funktionstest, der die nach außen sichtbare IP über den Proxy abfragt:
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
Erscheint in der Ausgabe die Proxy-IP statt deiner eigenen, sitzt alles richtig.
Methode 2: Benutzerkonfiguration (~/.wgetrc)
Trag diese Zeilen in ~/.wgetrc ein und leg die Datei bei Bedarf neu an:
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
Wichtig sind die Leerzeichen rund um das =, so verlangt es die dokumentierte .wgetrc-Syntax. Ab jetzt läuft jeder Wget-Aufruf dieses Nutzers über den Proxy.
Methode 3: Systemweite Konfiguration (/etc/wgetrc)
Hier gelten dieselben Direktiven wie in ~/.wgetrc, nur in der Systemdatei. GNU bezeichnet das als globale Startdatei, deren genauer Pfad vom Installationspräfix abhängt. Verbreitet sind:
/etc/wgetrc(bei den meisten Linux-Paketmanagern)/usr/local/etc/wgetrc(bei manchen Homebrew-Builds)- der Pfad, den
wget --versionunter „Wgetrc:“ ausgibt
Sinnvoll ist das überall dort, wo alle denselben Proxy nutzen sollen: geteilte Server, Docker-Container und ähnliche Umgebungen.
Methode 4: Umgebungsvariablen (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
Diese Variablen wirken über die ganze Shell-Sitzung hinweg, nicht nur auf Wget – curl und andere Tools ziehen sie ebenfalls heran.
Achtung: Wget akzeptiert die Umgebungsvariablen ausschließlich in Kleinschreibung. Ein groß geschriebenes HTTP_PROXY landet kommentarlos im Papierkorb. Keine Meldung, keine Warnung, nichts. Die genaue Terminalausgabe folgt im Kapitel zu den Stolperfallen – merken solltest du dir das aber schon jetzt.
Welche Proxy-Methode überschreibt welche?
Was passiert, wenn ein Proxy gleichzeitig per Umgebungsvariable, in .wgetrc und auf der Kommandozeile gesetzt ist – wer gewinnt? Dazu findet man kaum eine klare Antwort, deshalb habe ich es selbst durchgespielt.
So sieht die getestete und dokumentierte Rangfolge aus:
| Priorität | Methode | Bereich | Überschreibt |
|---|---|---|---|
| 1 (höchste) | -e CLI-Flags | Ein einzelner Befehl | Alles |
| 2 | ~/.wgetrc | Aktueller Nutzer | Systemkonfig + Umgebungsvariablen |
| 3 | /etc/wgetrc | Systemweit | Nur Umgebungsvariablen |
| 4 (niedrigste) | Umgebungsvariablen http_proxy / https_proxy | Shell-Sitzung | Nichts |
Geprüft habe ich das mit Wget 1.25.0, indem ich auf jeder Ebene einen anderen Proxy vorgab – Umgebung auf Port 3128, Konfigurationsdatei auf 3129, CLI auf 3130:
- Konfiguration vor Umgebung: Wget wählte Port 3129 und ließ 3128 links liegen.
- CLI vor Konfiguration: Wget wählte Port 3130 und überging sowohl 3129 als auch 3128.
Als Notbremse dient --no-proxy. Damit ignoriert Wget jede gesetzte Proxy-Einstellung, unabhängig von der Quelle:
wget --no-proxy https://internal-server.company.com/report.pdf
Ein typischer Fall: In /etc/wgetrc hat der Sysadmin einen Proxy hinterlegt, du musst aber einen internen Server direkt ansprechen. Statt die Systemkonfiguration umzuschreiben, setzt du für genau diesen Aufruf --no-proxy.
Wget mit authentifiziertem Proxy verwenden
Business- und Residential-Proxys verlangen meist Benutzername und Passwort. Wget bietet dafür zwei Wege, beide auf Basis der HTTP-Basic-Authentifizierung für die Proxy-Zugangsdaten.
Zugangsdaten direkt in der Proxy-URL
wget -e use_proxy=on \
-e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
http://example.com/file.zip
Genauso lässt sich das in .wgetrc notieren:
http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
Über die Flags --proxy-user und --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
Diese Flags setzen sich gegen jeden in der URL eingebetteten user:pass@-Teil durch.
Zugangsdaten sicher verwahren
Beide Varianten können die Zugangsdaten preisgeben. GNU weist darauf hin, dass Passwörter auf der Kommandozeile über ps und ähnliche Prozess-Tools einsehbar sein können. Dem beugst du so vor:
- Einzelplatzrechner: Zugangsdaten in
~/.wgetrcablegen und die Datei mitchmod 600 ~/.wgetrcschützen - CI/CD-Pipelines: verschlüsselte Secrets in GitHub Actions oder das Pendant deiner Plattform nutzen und sie im Schritt als kleingeschriebene Umgebungsvariablen übergeben – niemals fest ins YAML schreiben
- Docker-Builds: weder
ARGnochENVfür Secrets verwenden. Docker warnt ausdrücklich davor, dass Build-Argumente im fertigen Image landen können. Greif stattdessen zu BuildKit-Secret-Mounts - Versionskontrolle: keine
.wgetrcmit Zugangsdaten committen, sondern in die.gitignoreaufnehmen
Speziell bei GitHub Actions ist eines zu beachten: Secret-Namen speichert man konventionell in Großbuchstaben, doch die Umgebungsvariablen, die bei Wget ankommen, müssen klein sein (http_proxy, nicht HTTP_PROXY).
Wget unter Windows und hinter Firmen-Firewalls
Die meisten Anleitungen enden bei „mit Chocolatey installieren“. Unter Windows oder hinter einem Firmenproxy beginnen die Schwierigkeiten genau dort.
Wo Windows nach .wgetrc sucht
Laut GNU-Dokumentation liest Wget $HOME/.wgetrc, solange die Variable WGETRC nicht auf einen anderen Pfad verweist. Unter Windows kann $HOME auf %USERPROFILE% zeigen (etwa C:\Users\alice) – muss es aber nicht, je nachdem, ob du den Chocolatey-Build, einen MSYS2-Build, Git Bash oder ein Standalone-Binary einsetzt.
Statt zu raten, empfehle ich für eindeutiges Verhalten das Flag --config:
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
Willst du herausfinden, ob dein Build eine Konfigurationsdatei an einem bestimmten Ort einliest, leg eine Testdatei mit einem garantiert falschen Proxy an:
; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/
Dann ausführen:
wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/
Versucht Wget jetzt, 127.0.0.1:3128 zu erreichen, wurde die Datei gelesen.
Proxy-Umgebungsvariablen unter Windows setzen
CMD (nur in der aktuellen Sitzung):
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell (nur in der aktuellen Sitzung):
$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/
Dauerhaft (übersteht auch einen Neustart):
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
Nach setx musst du ein neues Terminalfenster öffnen – die laufende Sitzung bekommt die Änderung nicht mit.
Stolpersteine im Firmennetz: PAC-Dateien, NTLM und die Proxy-Adresse finden
Drei Punkte bringen Nutzer im Unternehmensumfeld besonders häufig aus dem Tritt:
PAC-Dateien: Viele Firmen arbeiten mit Proxy Auto-Configuration (PAC) – JavaScript-Skripten, die dem Browser je URL den passenden Proxy vorgeben. Wget hat keinen JavaScript-Interpreter und kann PAC-Dateien deshalb nicht auswerten. Dieselbe Einschränkung nennt die curl-Dokumentation. Die Lösung: PAC-Datei öffnen (oder die IT fragen), den Eintrag PROXY host:port für die Ziel-Domain heraussuchen und diese feste Adresse in Wget eintragen.
NTLM-Authentifizierung: Bei der Proxy-Authentifizierung beherrscht Wget nur Basic Auth. Verlangt dein Firmenproxy NTLM und du bekommst die Meldung 407 Proxy Authentication Required, spar dir das Durchprobieren verschiedener --proxy-user-Varianten. Installiere Cntlm – einen lokalen Relay-Dienst, der NTLM/NTLMv2 übernimmt und Wget eine schlichte Basic-Auth-Schnittstelle vorsetzt. Cntlm wird weiterhin gepflegt, das letzte Update stammt von Oktober 2025 bei rund 395 Downloads pro Woche.
Entscheidungsbaum für Firmenproxys:
- Setz
set http_proxy=http://YOUR_PROXY:PORT/und starte Wget. - Kommt ein
407-Fehler und dein Unternehmen nutzt NTLM → Cntlm installieren, mit deinen Domain-Zugangsdaten einrichten und Wget auf den lokalen Cntlm-Port lenken (üblicherweisehttp://127.0.0.1:3128/). - Setzt dein Unternehmen eine PAC-Datei ein → den realen
PROXY host:portaus der Datei ziehen oder die IT nach der festen Proxy-Adresse fragen.
Gängige Ports im Firmenumfeld sind 3128 (Squid-typisch), 8080 (allgemeiner HTTP-Proxy) und 8888 (Debug-Proxys wie Fiddler/Charles). Das sind Konventionen, keine Gewissheiten.
Wget-Proxy-Stolperfallen – mit echtem Fehler-Output
Jetzt kommt das Versprechen aus dem Titel zum Tragen. Sämtliche Ausgaben unten habe ich am 2026-06-01 mit Wget 1.25.0 (macOS, Homebrew) nachgestellt.
Stolperfalle 1: Das http://-Präfix fehlt
Ältere Anleitungen behaupten gern, das gehe immer schief. In Wget 1.25.0 läuft http_proxy=127.0.0.1:3128 jedoch durch – Wget ergänzt stillschweigend das http://:
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.
Der richtige Proxy wurde also dennoch angesprochen. Trotzdem rate ich dir, http:// und einen abschließenden Slash immer mitzuschreiben. Das räumt Unklarheiten zwischen den Wget-Versionen aus und hält die Zugangsdaten-Syntax (http://user:pass@host:port/) eindeutig.
Stolperfalle 2: use_proxy=yes gegen use_proxy=on
Bei meinen Tests mit Wget 1.25.0 zogen sowohl yes als auch on. Ein ungültiger Wert führt dagegen zu einer klaren Meldung:
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
Für die beste Kompatibilität nimmst du on – so steht es im dokumentierten Booleschen Format des Handbuchs und so weist es auch Wgets eigene Fehlermeldung an.
Stolperfalle 3: Großgeschriebenes HTTP_PROXY verpufft lautlos
Das ist die heimtückischste Falle, denn eine Fehlermeldung bleibt aus. Wget verbindet sich einfach direkt, als hättest du nie einen Proxy gesetzt.
Großschreibung (fehlerhaft – kein Proxy aktiv):
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
Kleinschreibung (funktioniert – Proxy aktiv):
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.
Der Unterschied springt ins Auge: Die Großschreibungs-Variante hat example.com direkt aufgelöst, die Kleinschreibungs-Variante den Proxy kontaktiert. In beiden Fällen warnt nichts. Eine vergleichbare Eigenheit hat curl – es schluckt die meisten Proxy-Variablen auch in Großschreibung, lehnt HTTP_PROXY aber aus Sicherheitsgründen bewusst ab.
Konsequenz: http_proxy und https_proxy grundsätzlich klein schreiben.
Stolperfalle 4: Veralteter Proxy in .wgetrc bringt „Connection refused“
Hat jemand – du selbst, dein Sysadmin oder ein Docker-Image – eine alte Proxy-Adresse in einer Konfigurationsdatei hinterlassen, sieht das etwa so aus:
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.
Der Fehler zeigt auf die alte Proxy-IP, nicht auf das Ziel. Bei der Fehlersuche gehst du der Priorität nach vor:
- den Befehl auf
-e-Flags und Shell-Aliase abklopfen ~/.wgetrcprüfen (oder die perWGETRCbenannte Datei)- die Systemkonfiguration prüfen (Pfad aus
wget --version) - die Umgebung prüfen:
env | grep -i proxy
Beim Debuggen ist --no-config dein bester Freund – damit überspringt Wget sämtliche Konfigurationsdateien:
wget --no-config --spider http://example.com/
Klappt es so, steckt das Problem in einer Konfigurationsdatei.
Stolperfalle 5: Wirrwarr bei der HTTPS-Proxy-Syntax
Hier verheddern sich viele. Setzt du https_proxy, lautet die Proxy-URL selbst normalerweise http:// und eben nicht https://. Der Grund: Wget schickt über den Proxy eine HTTP-CONNECT-Anfrage, um einen Tunnel für die verschlüsselte HTTPS-Sitzung zu öffnen.
Korrekt:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
Wget sendet daraufhin CONNECT example.com:443 HTTP/1.1 an den Proxy und tunnelt HTTPS darüber.
Falsch (HTTP-Ziel-URL mit HTTPS-Proxy-Endpunkt):
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 verweigert https:// als Proxy-URL für HTTP-Ziele sofort. Nimm https_proxy=http://HOST:PORT/ – es sei denn, deine Organisation hat einen HTTPS-Proxy-Endpunkt ausdrücklich dokumentiert und du hast ihn mit deinem Wget-Build erprobt.
Spickzettel: alle Wget-Proxy-Befehle auf einen Blick
Diese Tabelle gehört in deine Lesezeichen. Sie bündelt alle proxybezogenen Wget-Flags und Konfigurationsdirektiven an einer Stelle.
| Flag / Direktive | Kontext | Beispiel | Hinweise |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on ist am sichersten; manche Builds akzeptieren auch yes |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | http://-Präfix und abschließenden / angeben |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | Die Proxy-URL ist meist http://, auch bei HTTPS-Zielen |
--proxy-user | CLI | --proxy-user=admin | Überschreibt eingebettetes user:pass@ |
--proxy-password | CLI | --proxy-password=secret | In ps sichtbar – auf geteilten Systemen vermeiden |
--no-proxy | CLI | --no-proxy | Umgeht ALLE Proxy-Einstellungen aus allen Quellen |
--no-config | CLI | --no-config | Überspringt alle Konfigurationsdateien – nützlich zum Debuggen |
--config=FILE | CLI | --config=/tmp/wgetrc | Fester Config-Pfad – sehr praktisch für Windows und CI |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | In Konfigurationsdateien mit Leerzeichen um =; als Env-Var klein schreiben |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | Gleiches Format wie http_proxy |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | Für FTP-Abrufe |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | Kommagetrennte Domain-Liste |
proxy_user | .wgetrc | proxy_user = admin | Entspricht --proxy-user |
proxy_password | .wgetrc | proxy_password = secret | Datei mit chmod 600 schützen |
Wann Wget plus Proxy die falsche Wahl ist – und was besser passt
Nach so viel Proxy-Konfiguration eine bewusst gegen den Strich gebürstete Beobachtung: Manchmal lohnt sich der ganze Aufwand gar nicht.
Wer nach „wget proxy“ sucht, will oft überhaupt keine einzelne Datei laden. Das eigentliche Ziel sind strukturierte Daten von Websites – Produktpreise, Kontaktlisten, Immobilienangebote –, und Wget kommt nur ins Spiel, weil es das vertraute Kommandozeilen-Tool ist. Der Haken: Wget liefert rohes HTML, das du danach parsen, säubern und strukturieren musst. Und sobald du gegen Sperren rotierende Proxys einsetzt, pflegst du am Ende eine Proxy-Liste, ein Download-Skript, einen Parser und eine Export-Pipeline gleichzeitig.
| Ihr Ziel | Bestes Tool | Warum |
|---|---|---|
| Eine einzelne Datei über einen Proxy laden | wget mit Proxy-Flags | Einfach, ein Befehl |
| Eine Website oder ein Verzeichnis über einen Proxy spiegeln | wget --recursive + Proxy-Konfiguration | Rekursive Downloads sind eine Kernstärke von Wget |
| Strukturierte Daten scrapen (Tabellen, Listings, Kontakte) | Thunderbit | Wget liefert nur HTML – das muss man noch parsen. Thunderbit liest die Seite per KI aus und exportiert strukturierte Daten ohne Code nach Excel, Google Sheets, Airtable oder Notion. Das Cloud-Scraping übernimmt IP-Rotation und Anti-Bot-Maßnahmen, sodass du die Proxy-Einrichtung komplett sparst. |
| REST-API-Aufrufe über einen Proxy | curl | Bessere Header-Kontrolle, native JSON-Unterstützung, SOCKS5-Unterstützung |
| Laufende, geplante Datenerfassung | Thunderbit Scheduled Scraper oder cron + wget | Thunderbit passt sich an, wenn sich Layouts ändern; cron- + wget-Skripte brechen oft stillschweigend |
Beim Herunterladen von Dateien spielt Wget seine Stärken aus. Doch die Kette „Proxy einrichten → IPs rotieren → HTML laden → Parser schreiben → in Tabellen exportieren“ hat viele bewegliche Teile, wenn du am Ende nur eine Datentabelle brauchst. Trifft das auf dich zu, erledigt unsere Chrome-Erweiterung die ganze Pipeline mit zwei Klicks. Mehr zu diesem Weg liest du in unseren Leitfäden zu AI-Web-Scraping und Web-Scraping ohne Programmierung.
Lautet dein Ziel dagegen schlicht „diese ZIP-Datei über einen Firmenproxy laden“, bleibt Wget genau das passende Werkzeug – und jetzt weißt du, wie du es korrekt einrichtest.
Zentrale Erkenntnisse
Das Wichtigste in Kürze:
- Vier Methoden, eine klare Rangfolge: CLI-Flags schlagen die Benutzerkonfiguration, diese schlägt die Systemkonfiguration, und diese schlägt die Umgebungsvariablen.
--no-proxysetzt sich über alles hinweg. - Umgebungsvariablen stets klein schreiben (
http_proxystattHTTP_PROXY) – Großbuchstaben verpuffen lautlos. - In der Proxy-URL immer
http://angeben, auch beihttps_proxy. Der Proxy-Endpunkt arbeitet per HTTP; HTTPS läuft als CONNECT-Tunnel darüber. - Für Boolesche Werte
onnehmen in.wgetrcund bei-e-Flags – das ist die sicherste Wahl über alle Wget-Versionen hinweg. - Unter Windows
--config=C:\path\to\wgetrcverwenden, um Unklarheiten bei Konfigurationsdateien zu vermeiden, undset(CMD) bzw.$env:(PowerShell) für Session-Proxy-Variablen. - Im Firmennetz kann Wget keine PAC-Dateien lesen und unterstützt NTLM nicht von Haus aus. Bei Bedarf hilft Cntlm als lokaler Relay.
- Den Spickzettel oben merken – das spart dir das ewige Nachschlagen der Flags.
Geht es dir in Wahrheit um strukturierte Datenerfassung, sind Thunderbit oder curl häufig die klügere Wahl. Das beste Debugging ist ohnehin jenes, das gar nicht erst nötig wird.
FAQs
1. Unterstützt Wget SOCKS5-Proxys?
Nein. GNU Wget 1.x kennt nur HTTP-, HTTPS- und FTP-Proxys. Im Wget2-Projekt steht SOCKS5 zwar als Wunsch auf der Liste, ist aber keine standardmäßig dokumentierte Option. Für SOCKS5 greifst du zu curl mit den nativen Schemata socks5:// oder socks5h:// oder koppelst Wget mit proxychains4, um den Traffic über SOCKS zu zwingen.
2. Warum wird mein Proxy ignoriert, wenn ich HTTP_PROXY groß schreibe?
Wget liest Umgebungsvariablen ausschließlich klein (http_proxy, https_proxy, ftp_proxy, no_proxy). Großgeschriebene Varianten wie HTTP_PROXY verpuffen lautlos – ohne Fehler, ohne Warnung. Das gehört zu den häufigsten und nervigsten Problemen, weil man gar nicht merkt, dass etwas hakt. Also: immer klein schreiben.
3. Wie umgehe ich den Proxy für bestimmte Domains?
Dafür ist die Direktive no_proxy da, entweder als Umgebungsvariable oder in .wgetrc:
export no_proxy=localhost,127.0.0.1,.mycompany.com
Oder in ~/.wgetrc:
no_proxy = localhost,127.0.0.1,.mycompany.com
Die Domains stehen kommagetrennt nebeneinander. Ein führender Punkt (.mycompany.com) deckt sämtliche Subdomains ab.
4. Lässt sich Wget mit rotierenden Proxys betreiben?
Eine eingebaute Proxy-Rotation hat Wget nicht. Dir bleiben zwei Wege: Entweder nimmst du einen Proxy-Anbieter, der die IPs serverseitig rotiert – du sprichst dann stets dieselbe Gateway-Adresse an, während die Exit-IP wechselt. Oder du schreibst ein Shell-Skript, das bei jedem Aufruf zufällig einen Proxy aus einer Liste zieht und ihn per -e http_proxy=... übergibt. Für alles Anspruchsvollere – automatische Rotation, Retry-Logik, Anti-Bot-Handling – ist ein spezialisiertes Scraping-Tool meist die bessere Wahl.
5. Worin unterscheiden sich http_proxy und https_proxy in Wget?
http_proxy kommt zum Zug, wenn die Ziel-URL mit http:// beginnt, https_proxy bei einer Ziel-URL mit https://. In beiden Fällen ist die Proxy-URL selbst in der Regel eine http://-Adresse. Bei HTTPS-Zielen schickt Wget eine HTTP-CONNECT-Anfrage über den Proxy, um einen Tunnel aufzubauen; die eigentliche HTTPS-Verschlüsselung läuft Ende-zu-Ende zwischen Wget und dem Zielserver. Der Proxy erfährt aus der CONNECT-Anfrage nur den Hostnamen, den verschlüsselten Datenverkehr kann er nicht mitlesen.
Thunderbit für KI-Web-Scraping testen Get Started Free
Mehr erfahren
