Ich habe unzählige späte Nächte damit verbracht, Skripte zu debuggen, die eigentlich nur „eine Datei holen und weitermachen“ sollten. In neun von zehn Fällen lag der Fehler nicht bei cURL selbst, sondern daran, dass es exakt das getan hat, was ich gesagt hatte — nicht das, was ich eigentlich wollte. Zwischen „curl -O funktioniert“ und „curl -O funktioniert auch in der Produktion zuverlässig“ liegt nämlich ein großer Unterschied.
Genau für diese Lücke ist dieser Leitfaden da. cURL ist auf macOS, den meisten Linux-Distributionen sowie unter Windows 10 und neuer bereits vorinstalliert. Das heißt: Sehr wahrscheinlich ist es schon jetzt auf deinem Rechner vorhanden. Aber zwischen stillen Redirect-Fehlern, mysteriösen 403-Meldungen und dem Sprung von „eine Datei herunterladen“ zu „500 Dateien herunterladen, ohne das Terminal lahmzulegen“ gibt es reichlich Stolperfallen. Ich zeige dir die wichtigen Flags, die Schritt-für-Schritt-Befehle, die ich wirklich nutze, die Fehler, über die die meisten Leute stolpern, und den Punkt, an dem cURL tatsächlich nicht mehr weiterhilft — und was du dann stattdessen einsetzen solltest.
Was ist cURL überhaupt – und warum sollte es dich interessieren?
cURL ist ein kostenloses Open-Source-Kommandozeilenwerkzeug, mit dem sich Daten über eine URL zu oder von einem Server übertragen lassen. Es unterstützt HTTP, HTTPS, FTP, SFTP und viele weitere Protokolle. Deshalb taucht es überall auf: in Bash-Skripten, Dockerfiles und CI-Pipelines. Der Befehl curl, den du im Terminal eingibst, nutzt im Hintergrund libcurl, die Transferbibliothek in C, die viele Anwendungen und Sprach-Bindings einbetten. Die cURL-Erweiterung von PHP ist ein Beispiel dafür; die beliebte Python-Bibliothek Requests ist dagegen ein separater HTTP-Client, der auf urllib3 basiert und nicht auf libcurl.
Die aktuell stabile Version zum Zeitpunkt des Schreibens ist curl 8.21.0, veröffentlicht im Juni 2026 — geh aber nicht davon aus, dass dein Betriebssystem genau diesen Build mitbringt. Von Distributionen mitgelieferte curl-Versionen hinken dem Upstream-Projekt oft um Monate hinterher, manchmal sogar länger. Deshalb lohnt sich ein Blick auf curl --version, bevor du annimmst, dass ein Flag wie --parallel schon verfügbar ist.
Warum Dateien mit cURL herunterladen? Die wichtigsten Anwendungsfälle
Ich werde ziemlich oft gefragt, warum man überhaupt ein Kommandozeilenwerkzeug nutzen sollte, wenn Browser Dateien doch problemlos herunterladen können. Die ehrliche Antwort: Browser sind großartig — bis du etwas automatisieren willst.
| Anwendungsfall | Warum cURL glänzt |
|---|---|
| Binärdateien in CI/CD-Pipelines herunterladen | Skriptbar, keine GUI nötig |
| API-Antworten oder Datenexporte abrufen | Unterstützt eigene Header, Authentifizierung und Ausgabe-Piping |
| Große Downloads über SSH fortsetzen | Integrierte Resume-Funktion (-C -) |
| Wiederkehrende Downloads automatisieren (Cronjobs) | Leichtgewichtig, gut mit Shell-Skripten kombinierbar |
| Dateien hinter Authentifizierung abrufen | Flexible Auth-Flags (Basic, Token, Cookies, .netrc) |
Ein Browser-Download ist ein einmaliger manueller Klick. cURL macht daraus etwas, das sich planen, in eine Pipeline einhängen, bei Fehlern erneut versuchen und auf hundert Servern identisch ausführen lässt. Genau darin liegt der Reiz — nicht, weil es schicker ist, sondern weil es reproduzierbar ist.
Die wichtigsten cURL-Flags für Downloads
Ich komme immer wieder auf dieselben rund ein Dutzend Flags zurück, die 90 % meiner Arbeit abdecken. Hier ist die kompakte Übersicht, die ich mir vor Jahren gewünscht hätte — sortiert nach ihrer tatsächlichen Funktion.
Flags für Ausgabe und Dateispeicherung
-O(--remote-name) speichert die Datei unter dem letzten Teil der URL als Dateinamen. Praktisch, kann aber eine vorhandene Datei gleichen Namens unbemerkt überschreiben.-o <filename>(--output) lässt dich den Zielnamen selbst festlegen:curl -o report.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) verwendet den Dateinamen aus demContent-Disposition-Header des Servers statt aus der URL. Das ist bei API-Downloads praktisch, aber serverseitige Dateinamen solltest du nicht blind vertrauen — lade sie lieber in einen separaten Ordner statt direkt ins Home-Verzeichnis herunter, wie es die Sicherheitsrichtlinien von curl empfehlen.
Verhaltens-Flags, die jeder Download braucht
-L(--location) weist curl an, HTTP-Weiterleitungen zu folgen. Ohne dieses Flag wird eine 3xx-Antwort als kleine HTML-Weiterleitungsseite gespeichert statt als eigentliche Datei — das ist der häufigste „Warum ist mein Download kaputt?“-Fehler, den ich sehe.-C -(--continue-at -) setzt einen unterbrochenen Download an der Stelle fort, an der er abgebrochen wurde.-s/-Slaufen still, zeigen aber weiterhin Fehler an — ideal für Skripte, in denen du keinen Fortschrittsbalken in den Logs haben willst.--limit-rate 1Mdrosselt die Bandbreite (nützlich in geteilten Netzwerken oder wenn du kein Metered Network überlasten willst).--connect-timeout 10und--max-time 300verhindern, dass eine hängende Verbindung dein Skript für immer blockiert.--retry 3und--retry-delay 5versuchen es bei vorübergehenden Fehlern automatisch erneut — laut curl-Manpage sollte man--retry-all-errorsnur dann dazunehmen, wenn es wirklich sicher ist, exakt dieselbe Anfrage mehrfach zu senden.
Flags für Fortschritt und Debugging
-#zeigt einen einfachen Fortschrittsbalken statt der Standard-Statistik-Tabelle.-vgibt ausführliche Informationen aus, inklusive der kompletten Request- und Response-Header — mein Favorit, wenn etwas nicht richtig läuft.-I(--head) ruft nur die Antwort-Header ab — ein hervorragender Vorabcheck, bevor du einen großen Download startest.-werlaubt dir, nach dem Transfer eigene Ausgaben zu erzeugen, zum Beispielcurl -o /dev/null -s -w "%{http_code}\n" <url>, um nur den Statuscode zu prüfen.
Bevor du loslegst
- Schwierigkeit: Anfänger bis Fortgeschrittene (die Abschnitte zu Batch und Authentifizierung werden etwas anspruchsvoller)
- Benötigte Zeit: Etwa 15–20 Minuten, um die Kernbefehle durchzugehen
- Was du brauchst: Ein Terminal (macOS Terminal, Linux-Shell oder Windows PowerShell/WSL), installiertes curl (Prüfung mit
curl --version) und eine Test-URL — ich verwende als Beispiel ein öffentliches GitHub-Release-Asset, weil es stabil und frei zugänglich ist
Dateien mit cURL herunterladen: Schritt für Schritt
Schritt 1: Eine einzelne Datei herunterladen
Das absolute Grundprinzip: curl -O <url> speichert die Datei unter ihrem ursprünglichen Namen, während curl -o myfile.zip <url> dir erlaubt, sie direkt umzubenennen.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
Ich setze -L inzwischen grundsätzlich immer ein — ohne Ausnahme. Zu oft hat mich eine Weiterleitung heimlich aus meinem „Download“ eine 400-Byte-HTML-Datei machen lassen. Du solltest im Terminal einen Fortschrittsbalken sehen, der bis zum Ende durchläuft, und danach liegt die Datei im aktuellen Verzeichnis.
Wenn der Befehl erfolgreich war, erreicht der Fortschrittsbalken 100 % und curl-8.21.0.tar.gz erscheint im aktuellen Verzeichnis. Prüfe die Datei, bevor du sie weiterverwendest:
ls -lh curl-8.21.0.tar.gz
Schritt 2: Datei herunterladen und umbenennen
Nutze -o, wenn du einen bestimmten lokalen Dateinamen haben willst statt des Namens, der zufällig am Ende der URL steht:
curl -L -o curl-latest.tar.gz -S https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
-S schaltet hier die Fehleranzeige wieder ein, falls du andernorts in einem Skript auch -s verwendet hast. Diese Kombination — -L -o <name> -S — ist im Grunde mein Standardbefehl für den Download einzelner Dateien.
Schritt 3: Einen unterbrochenen Download fortsetzen
Wenn ein großer Download mittendrin abbricht (schlechtes WLAN, VPN-Aussetzer, was auch immer), starte nicht von vorn. Nutze:
curl -C - -LO https://example.com/large-file.iso
Wichtig: Das funktioniert nur, wenn der Server Byte-Range-Anfragen unterstützt. Accept-Ranges: bytes ist ein gutes positives Signal, beweist aber nicht, dass Range-Anfragen wirklich funktionieren. Der verlässliche Check ist die Antwort des Servers auf eine echte Range-Anfrage: Eine fortsetzbare Antwort liefert normalerweise 206 Partial Content zusammen mit einem gültigen Content-Range. Führe den Resume-Befehl aus und prüfe den Status mit -v oder -D -; wenn der Server die Range ignoriert oder den Offset ablehnt, starte bewusst neu, statt anzunehmen, dass die Teildatei sicher ist.
Schritt 4: Mit Fortschrittsbalken herunterladen – oder still im Hintergrund
Für eine sauberere Anzeige im interaktiven Terminal: curl -# -LO <url>. Für Skripte und Cronjobs, bei denen du nur Fehler, nicht aber Ausgabechaos willst: curl -sS -LO <url>. Die stille Variante nutze ich fast überall, außer beim manuellen Debugging.
Schritt 5: Download-Geschwindigkeit begrenzen
In einem geteilten Büro-Netzwerk (oder wenn ich während eines Videocalls nicht die ganze Bandbreite belegen will) drossele ich mit:
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
Die Einheiten sind K, M und G für Kilobytes, Megabytes und Gigabytes pro Sekunde.
Schritt 6: Response-Header zusammen mit der Datei speichern
Manchmal muss ich ganz genau wissen, was der Server zurückgegeben hat — Content-Type, Cache-Header und ähnliches — ohne das Terminal mit Ausgabe zu überladen:
curl -L -D headers.txt -o file.zip https://example.com/file.zip
Damit landen die Response-Header in headers.txt, während die eigentliche Datei in file.zip gespeichert wird. Perfekt, um Content-Type-Abweichungen zu debuggen oder zu prüfen, ob ein CDN wirklich das cached, was es cachen soll.
Tipps und typische Stolperfallen
- Tipp: Standardmäßig immer
-Lverwenden. Mir fällt ehrlich gesagt kein Nachteil ein, es immer mitzunehmen — und ich habe schon Stunden verloren, weil ich es vergessen hatte. - Tipp: Kombiniere beim Skripten deinen Download-Befehl mit
--fail, damit eine Nicht-2xx-Antwort das Skript tatsächlich mit einem Fehler beendet, statt stillschweigend eine Fehlerseite als vermeintliche Datei zu speichern. - Stolperfalle:
-C -nicht mit--remove-on-errorkombinieren — curl dokumentiert diese Kombination als inkompatibel, da Resume voraussetzt, dass die Teildatei erhalten bleibt. - Stolperfalle:
-Okann Dateien ohne Warnung überschreiben. Wenn du in ein gemeinsames Verzeichnis im Batch herunterlädst, nutze--output-dir, um alles sauber zu begrenzen.
Mehrere Dateien und Batch-Downloads mit cURL
Beispiele für einzelne Dateien sind der leichte Teil. Die echten Workflows, die ich gebaut habe — etwa nächtliche Datenexports oder das Synchronisieren von Binärdateien über Build-Server — brauchten Parallelität. Genau hier hören viele Anleitungen einfach auf. Es gibt drei sinnvolle Ansätze, die du kennen solltest, jeweils mit steigender Komplexität.
Ansatz 1: Mehrere URLs in einem cURL-Befehl
Die einfachste Variante ist, die URLs einfach aufzulisten:
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
Das funktioniert, ist aber sequentiell — curl lädt erst die erste Datei vollständig, bevor es mit der nächsten beginnt. Für drei Dateien okay, für dreihundert mühsam.
Ansatz 2: Parallele Downloads mit --parallel (curl 7.66+)
Seit curl 7.66 kannst du --parallel (oder -Z) hinzufügen, um mehrere URLs gleichzeitig abzurufen:
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
Wichtig zu wissen: Das Standardlimit für Parallelität liegt tatsächlich bei 50 — deutlich mehr gleichzeitige Verbindungen, als die meisten Server oder dein eigenes Netzwerk dir danken würden. Ich setze --parallel-max daher immer explizit und eher konservativ, meist auf 4 bis 8, statt dem Standard blind zu vertrauen.
Ansatz 3: xargs und Bash-Loops für Parallelität aus einer URL-Liste
Bei einer großen Liste von URLs in einer Textdatei greife ich meistens zu xargs:
cat urls.txt | xargs -n1 -P 8 curl -O -L
Oder, wenn ich mehr Kontrolle darüber will, was mit jedem einzelnen Job passiert, nutze ich eine Bash-Schleife mit Hintergrundprozessen:
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
Das wait am Ende ist wichtig — ohne es beendet sich das Skript, bevor die Downloads im Hintergrund fertig sind.
Wann wget oder aria2 die bessere Wahl ist
Ich sage es ganz offen: cURL ist nicht immer das richtige Werkzeug. Wenn du einen kompletten Website-Verzeichnisbaum spiegeln willst, erledigt wget -r rekursives Crawling direkt aus dem Werkzeug heraus — etwas, wofür cURL schlicht nicht gebaut wurde. Wenn du Multi-Source- oder Segment-Downloads brauchst, um aus einer riesigen Datei maximale Übertragungsleistung herauszuholen, ist aria2c tatsächlich schneller.
| Werkzeug | Am besten geeignet für |
|---|---|
| cURL | Präzision, Skripting, Einzeldateien oder kleine Batches, API-Zugriffe |
| wget | Rekursive/mirroring Downloads von Websites, einfaches Sammeln statischer Dateien |
| aria2 | Multi-Source-/Segment-Downloads, maximale Performance bei großen Dateien |
cURLs Stärke lag schon immer in Präzision und Kombinierbarkeit — Piping, Skripting, Protokollflexibilität — nicht im brachialen Crawling.
Geschützte Dateien mit cURL herunterladen: Authentifizierungsmuster
Die meisten cURL-Tutorials hören bei -u user:pass auf und sind damit fertig. Das ist ein Relikt aus einer früheren Internet-Ära. Im Jahr 2026 kommen die Dateien, die ich wirklich herunterlade, meist aus REST-APIs, sessionbasierten Dashboards und CI-Systemen — und jedes davon erwartet eine andere Art von Zugangsdaten.
Basic Auth
curl -u username:password -O https://legacy-server.example.com/file.zip
Funktioniert gut für ältere FTP-Server oder einfache HTTP-Endpunkte. Beachte aber: Das Passwort landet in deiner Shell-History und im Prozess-Listing, wenn du nicht aufpasst — nichts, was ich für sensible Daten verwenden würde.
Bearer-/OAuth-Token-Authentifizierung
Das ist die Variante, die in den meisten Anleitungen erstaunlich wenig vorkommt, obwohl ich sie heute am häufigsten nutze:
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
Das ist ein echtes Muster, um ein privates GitHub-Release-Asset abzurufen — ersetze einfach Token und Asset-ID. REST-APIs und OAuth2-geschützte Ressourcen sprechen heute im Wesentlichen genau diese Sprache.
Cookie-basierte Session-Authentifizierung
Bei Web-Apps, in denen der Login eine Session erzeugt, speichere beim Einloggen das Cookie-Jar und verwende es beim Download erneut:
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
.netrc-Datei für Skripte und CI-Umgebungen
Meine bevorzugte Methode für alles, was unbeaufsichtigt läuft. Erstelle eine Datei ~/.netrc (unter Windows _netrc):
machine example.com
login myusername
password mypassword
Sichere sie mit chmod 600 ~/.netrc und verwende sie dann so:
curl --netrc -LO https://example.com/protected-file.zip
Der Vorteil: Die Zugangsdaten tauchen weder in deiner Shell-History noch im Quelltext des Skripts auf — und das ist in CI/CD wirklich wichtig, weil Skripte dort oft vollständig geloggt werden.
| Auth-Methode | Flag/Option | Am besten geeignet für |
|---|---|---|
| Basic Auth | -u user:pass | Legacy-FTP, einfaches HTTP |
| Bearer-Token | -H "Authorization: Bearer <token>" | REST-APIs, OAuth2 |
| Cookie-Auth | -b cookies.txt (+ -c zum Speichern) | Sessionbasierte Web-Apps |
.netrc-Datei | --netrc oder --netrc-file | CI/CD, automatisierte Umgebungen |
Häufige cURL-Downloadfehler beheben
Das ist der Abschnitt, den ich mir selbst am Anfang gewünscht hätte — denn kaum jemand erklärt ihn. „Warum funktioniert mein curl-Download nicht?“ ist eine reale, häufige und frustrierende Suche. Die gute Nachricht: Die Lösung ist meist ein Einzeiler, sobald du die Ursache kennst.
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
curl: (60) SSL certificate problem | Selbstsigniertes oder abgelaufenes Zertifikat | --cacert <file> oder -k (nur für Entwicklung) |
403 Forbidden / leere Datei | Server blockiert den Standard-User-Agent von curl | -A "Mozilla/5.0..." oder -H "User-Agent: ..." |
Download startet mit -C - wieder bei 0 | Server unterstützt Range nicht | Mit curl -I <url> prüfen und auf Accept-Ranges: bytes achten |
| 0-Byte-Datei gespeichert | Weiterleitung nicht gefolgt | -L hinzufügen |
curl: (28) Operation timed out | Langsamer Server oder Netzwerkprobleme | --connect-timeout 10 --max-time 300 + --retry 3 |
| HTML-Seite statt Datei gespeichert | Seite benötigt JavaScript-Rendering | curl kann kein JS ausführen — siehe Abschnitt unten |
SSL-Zertifikatsfehler: Was sie bedeuten und wie du sie behebst
Fehler 60 bedeutet, dass curl das SSL-Zertifikat des Servers nicht verifizieren konnte — meist, weil es selbstsigniert, abgelaufen oder von einer CA ausgestellt ist, der curl nicht vertraut. Wenn du den Server kontrollierst, gib curl das richtige CA-Bundle mit --cacert /path/to/ca.pem. Das Flag -k (--insecure) überspringt die Prüfung komplett — für eine lokale Entwicklungsumgebung okay, für alles, was mit Produktion oder echten Nutzerdaten zu tun hat, eine wirklich schlechte Idee.
403 Forbidden und leere Downloads
Erstaunlich viele Server blockieren Anfragen, die sich mit curl/8.21.0 identifizieren — also mit dem Standard-User-Agent von curl — weil sie sie für Bots oder Scraper halten. Die Lösung ist meist einfach: Gib dich als Browser aus:
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
Um vor einem vollständigen Download zu prüfen, was tatsächlich zurückkommt, nutze ich: curl -o /dev/null -s -w "%{http_code}\n" <url>.
Timeouts, Retries und instabile Verbindungen
Das ist der Befehl, den ich mir auf den Arm tätowieren würde, wenn ich mutiger wäre.
Mein bevorzugter Download-Befehl, den ich tatsächlich in Produktionsskripten verwende, kombiniert alle wichtigen Zuverlässigkeits-Flags:
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
Das bedeutet: Weiterleitungen folgen, Download fortsetzen, fünf Wiederholungen mit drei Sekunden Verzögerung, zehn Sekunden Verbindungs-Timeout, zehn Minuten Gesamtzeitlimit und ein harter Fehler bei schlechten HTTP-Statuscodes — im Grunde alles, was ich aus Erfahrung dazunehme.
cURL in echter Automatisierung: CI/CD-Pipelines, Piping und Skriptsicherheit
cURL-Ausgabe an andere Tools weiterleiten
curl muss nicht einmal etwas auf die Festplatte schreiben — direkt in einen anderen Befehl zu pipen ist eine seiner unterschätztesten Stärken:
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
Herunterladen und entpacken oder herunterladen und parsen in einer einzigen Zeile. Dieses Muster nutze ich ständig für einmalige Datenabrufe.
cURL in GitHub Actions und CI/CD verwenden
Ein minimalistischer GitHub-Actions-Schritt, der eine Binärdatei mit Retry-Logik herunterlädt und bei Fehlern laut scheitert:
- name: Download binary
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
Speichere Tokens als CI-Secrets und greife über Umgebungsvariablen darauf zu — niemals direkt im Skript hart verdrahten. Und nutze --fail (oder --fail-with-body, wenn du den Fehlertext zum Debuggen brauchst), damit ein kaputter Download den Build wirklich bricht, statt stillschweigend mit Müll erfolgreich zu sein.
Die Sicherheitsfrage zu curl | sh
Diese Frage taucht in fast jedem Entwicklerforum auf, das ich gelesen habe — und das aus gutem Grund: Wenn du curl direkt in sh leitest, führst du entfernten Code aus, den du nicht überprüft hast, und verlässt dich komplett darauf, dass der Server nicht kompromittiert wurde und die Verbindung nicht manipuliert ist. Das ist das eigentliche Risiko — keine Paranoia, sondern schlicht ein klassisches Supply-Chain-Problem.
Sicherer ist es, die Datei zuerst herunterzuladen, das Skript zu prüfen, falls vorhanden eine Prüfsumme oder GPG-Signatur zu verifizieren und erst dann auszuführen:
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # wirklich lesen
sha256sum install.sh # mit veröffentlichter Prüfsumme vergleichen, falls vorhanden
bash install.sh
Bekannte Installer wie rustup und Homebrew verwenden den Ansatz curl | sh weiterhin, und für genau diese Fälle ist er allgemein akzeptiert, weil die Maintainer und der Distributionskanal etabliert sind. Ich würde trotzdem lieber die zusätzlichen zehn Sekunden investieren, um ein Skript zu prüfen, als später feststellen zu müssen, dass ich ihm nicht hätte vertrauen sollen.
Wann cURL nicht reicht: JS-gerenderte Seiten, Anti-Bot-Schutz und strukturierte Daten
Es gibt einen Fehlerfall, der viele Leute ausbremst — und oft tragen sie nicht einmal die Schuld daran: Du führst curl -O gegen eine Seite aus, die völlig normal aussieht, und statt des erwarteten Inhalts bekommst du eine leere HTML-Hülle, eine Cloudflare-Challenge oder etwas, das einfach nur kaputt aussieht. curl hat genau das getan, wofür es gebaut wurde — die rohe HTTP-Antwort abzurufen. Es kann nur kein JavaScript ausführen, kein CAPTCHA lösen und kein Anti-Bot-Fingerprinting umgehen. Das sind keine Fehler in curl; sie gehören schlicht nicht zu seinem Aufgabenbereich.
Warum cURL bei modernen Webseiten scheitert
Moderne Single-Page-Apps liefern oft nur ein fast leeres HTML-Gerüst zurück. Der eigentliche Inhalt wird anschließend clientseitig per JavaScript gerendert — etwas, das curl niemals ausführt. Zusätzlich spielen Systeme wie Cloudflare und Akamai an alles, was nicht wie ein echter Browser aussieht, aktiv Challenge-Seiten aus. Und wiederholte curl-Anfragen von derselben IP können recht schnell als Bot-Traffic gedrosselt oder per Fingerprinting erkannt werden.
Der nächste Schritt: KI-Scraping-APIs für Entwickler
Ich würde sagen, dass curl für etwa 80 % aller Datei- und Datendownloads die richtige Wahl ist — statische Assets, API-Antworten, alles, was einfach als HTTP-Ressource ausgeliefert wird. Die restlichen 20 % sind die JavaScript-lastigen oder botgeschützten Seiten, bei denen Entwickler oft stundenlang mit Headern und User-Agent-Strings kämpfen, bevor sie schließlich aufgeben und eine andere Ebene einsetzen.
Genau diese Lücke hat mein Team mit Thunderbit, neben der Chrome-Erweiterung, für die uns die meisten kennen. Auf Entwicklerseite bietet die Thunderbit Open API POST /distill, das aus einer URL sauberes, für LLMs geeignetes Markdown liefert — inklusive Seiten-Rendering durch den Service — sowie POST /extract, das schema-genaues strukturiertes JSON zurückgibt, wenn du echte Felder statt lesbaren Text brauchst. Außerdem gibt es einen MCP-Server, damit Agenten in Claude oder Cursor während einer Aufgabe thunderbit_distill und thunderbit_extract aufrufen können, sowie eine CLI (npx @thunderbit/thunderbit-cli distill <url>), die sich im Terminal sehr ähnlich wie curl verhält. Du kannst JSON-Ausgaben zum Beispiel an jq weiterleiten: thunderbit distill <url> --format json | jq -r '.data.markdown'; oder --format markdown an ein Text-Tool oder direkt in eine Datei ausgeben.
Im direkten Vergleich ist der Unterschied deutlich. Eine curl-Anfrage an eine JS-gerenderte Produktseite liefert vielleicht nur ein weitgehend leeres <div id="root"></div>. Der entsprechende thunderbit distill-Befehl liefert den gerenderten Seiteninhalt als sauberes Markdown. Distill kostet 1 Credit pro URL und Extract 20 Credits pro URL. Die aktuellen Limits unterscheiden sich je nach Endpunkt: Batch Distill unterstützt bis zu 100 URLs pro Job, während Batch Extract bis zu 50 URLs mit einem gemeinsamen Schema akzeptiert. Prüfe vor dem Dimensionieren einer Produktionswarteschlange immer die aktuelle API-Dokumentation.
Wenn du das Konzept insgesamt noch neu findest, ist unser eigener Einstieg zu was Web Scraping eigentlich bedeutet ein guter Startpunkt. Der No-Code-Leitfaden zum Web Scraping behandelt die nicht-technische Seite desselben Problems für alle im Team, die kein Terminal anfassen wollen. Für einen breiteren Vergleich der Werkzeuge in diesem Bereich haben wir außerdem eine Übersicht der besten KI-Web-Scraper zusammengestellt.
Kurzreferenz: cURL-Download-Cheatsheet
| Aufgabe | Befehl |
|---|---|
| Einfacher Download | curl -LO <url> |
| Eigener Dateiname | curl -L -o myfile.zip <url> |
| Download fortsetzen | curl -C - -LO <url> |
| Still, aber mit Fehleranzeige | curl -sSL -O <url> |
| Parallele Downloads | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Bearer-Token-Authentifizierung | curl -H "Authorization: Bearer <token>" -LO <url> |
| Empfohlener Skript-Download | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| Ausgabe an Extraktions-Tool weiterleiten | curl -sL <url> | tar xz |
Fazit und wichtigste Erkenntnisse
Eine Datei mit curl herunterzuladen beginnt simpel — curl -O und fast fertig — aber die eigentliche Fähigkeit steckt in den Ebenen darunter: zu wissen, wann -L nötig ist, wann man fortsetzt statt neu startet, welches Authentifizierungsmuster wirklich zum eigenen Workflow passt und was zu tun ist, wenn plötzlich eine 403-Meldung oder eine leere HTML-Hülle statt der erwarteten Datei auftaucht. Ich habe mich auf jeden einzelnen dieser Ansätze irgendwann verlassen — meist direkt nachdem ich auf die harte Tour gelernt hatte, warum er wichtig ist.
curl bleibt für mich ganz klar das Standardwerkzeug für einfache Datei-Downloads und skriptfähige HTTP-Aufgaben — schnell, überall verfügbar und hervorragend mit dem Rest einer Shell-Pipeline kombinierbar. Aber wenn du auf eine JavaScript-gerenderte Seite oder eine Anti-Bot-Sperre triffst, ist das kein Problem, das du mit noch mehr Flags lösen kannst; es ist ein Zeichen dafür, dass du eine andere Ebene brauchst. Genau dort übernimmt eine API wie die von Thunderbit die Arbeit, ohne dass du dein Terminal verlassen musst.
Speichere dir das Cheatsheet als Lesezeichen, teste den Retry-und-Resume-Befehl beim nächsten instabilen Download, und wenn du an die Wand läufst, an der curl nur noch Müll zurückliefert, weißt du, wie der nächste Schritt aussieht — auf der Pricing-Seite von Thunderbit findest du die aktuelle Aufschlüsselung der Credits, falls du wissen willst, was dieser Wechsel konkret kostet, und unser YouTube-Kanal bietet Schritt-für-Schritt-Anleitungen, falls du lieber schaust als liest.
FAQs zum Herunterladen von Dateien mit cURL
Wie lade ich mit cURL eine Datei unter einem bestimmten Namen herunter?
Nutze -o gefolgt vom gewünschten Dateinamen: curl -L -o deinname.ext <url>. Füge -L hinzu, damit Weiterleitungen den Download nicht stören.
Wie setze ich einen fehlgeschlagenen cURL-Download fort?
Führe curl -C - -LO <url> aus. Das funktioniert nur, wenn der Server Range-Requests unterstützt — prüfe vorher mit curl -I <url> und achte in der Antwort auf Accept-Ranges: bytes.
Kann cURL Dateien herunterladen, die eine Anmeldung erfordern?
Ja, auf vier Hauptwegen: Basic Auth (-u user:pass), Bearer-Token (-H "Authorization: Bearer <token>"), Cookie-basierte Sessions (-b cookies.txt) oder eine .netrc-Datei für automatisierte Umgebungen. Im Authentifizierungsabschnitt oben findest du die vollständige Einordnung und wann welche Methode passt.
Was ist der Unterschied zwischen cURL und wget beim Datei-Download?
cURL unterstützt mehr Protokolle und eignet sich meist besser für Skripting, Piping sowie präzise Einzeldatei- oder Kleinbatch-Downloads. wget ist für rekursives Crawling und das Spiegeln ganzer Website-Verzeichnisse gebaut und daher die bessere Wahl für große Mengen statischer Seiteninhalte.
Warum lädt cURL eine HTML-Seite statt der eigentlichen Datei herunter?
Meist gibt es zwei Ursachen: Du hast das -L-Flag vergessen, und der Server hat dich weitergeleitet, oder die Seite benötigt JavaScript, um ihren eigentlichen Inhalt zu rendern — etwas, das curl schlicht nicht ausführen kann. Im zweiten Fall brauchst du ein Tool mit Rendering-Fähigkeit statt noch mehr curl-Flags.
