NCA Social Media
Grüner curl Matrix Rain mit Neon Flag Badges fsSL IL v auf dunklem Hintergrund

Was ist curl im Linux Terminal?

curl ist ein Kommandozeilen Werkzeug zum Übertragen von Daten über Netzwerkprotokolle wie HTTP, HTTPS, FTP oder SFTP. Das Programm ist auf fast jedem Linux System, auf macOS und seit Windows 10 auch nativ in der Eingabeaufforderung verfügbar. Entwickler nutzen curl für API Requests, zum Herunterladen von Dateien, zum Debuggen von HTTP Verbindungen und als zentralen Baustein in Install Skripten.

Die Macht von curl steckt in den Flags: kurze Parameter wie -f, -s, -L oder -o, die das Verhalten steuern. Wer die Kombination curl -fsSL https://bun.sh/install | bash blind kopiert, führt fremden Code aus, ohne zu verstehen, was passiert. Dieser Guide erklärt alle wichtigen curl Flags 2026 mit Praxis Beispielen aus KI Tool Installationen, sicheren Install Befehlen und HTTP Debugging.

Bei NCA Vibe Coding Consulting begleiten wir Teams dabei, Terminal Workflows professionell einzusetzen. Statt Copy und Paste aus Tutorials lernen Entwickler, was jeder Flag bewirkt, wo Sicherheitsrisiken entstehen und wie sich robuste Install Skripte für CI und Produktion bauen lassen.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Die 12 wichtigsten curl Flags im Überblick

Jede curl Option hat eine Kurzform (ein Buchstabe mit Minuszeichen) und eine Langform (doppeltes Minuszeichen plus Wort). Beide sind gleichwertig. In Skripten, die andere lesen und warten müssen, empfiehlt sich die Langform, weil sie selbsterklärend ist. Im Terminal Alltag nutzen die meisten Entwickler die Kurzformen.

Diese 12 Flags decken etwa 95 Prozent aller täglichen curl Anwendungen ab:

  • -f (--fail): Bei HTTP Fehlern wie 404 oder 500 mit Fehler Exit Code abbrechen
  • -s (--silent): Progress Bar und Fortschritts Ausgabe unterdrücken
  • -S (--show-error): Zusammen mit -s Fehler trotzdem anzeigen
  • -L (--location): Redirects (301, 302) automatisch folgen
  • -I (--head): Nur HTTP Header abrufen, keinen Body
  • -o (--output): Response in Datei speichern
  • -O (--remote-name): Datei mit Original Namen speichern
  • -H (--header): Custom HTTP Header mitsenden
  • -d (--data): POST Body mitsenden
  • -X (--request): HTTP Methode setzen (GET, POST, PUT, DELETE, PATCH)
  • --max-time: Timeout in Sekunden
  • -v (--verbose): Debug Ausgabe mit Request und Response Headern

Die folgenden Abschnitte erklären jeden Flag einzeln mit Praxis Beispiel und typischer Fallstrick Situation.

curl -f und --fail: Bei HTTP Fehler sauber abbrechen

Standardmäßig gibt curl auch bei einem HTTP 404 oder 500 den Exit Code 0 zurück. Der Request war technisch ja erfolgreich, es kam nur eine Fehler Seite zurück. In Skripten ist das gefährlich: Die nächste Zeile läuft weiter, der Fehler bleibt unbemerkt, der HTML Fehler Text landet in der Output Datei.

Mit -f wechselt curl in den Fail Modus. Bei jedem HTTP Statuscode ab 400 bricht curl mit Exit Code 22 ab und schreibt keinen Body. Genau das Verhalten, das man in CI Pipelines und Deployment Skripten braucht.

Code: 
          
# Ohne -f: Skript läuft weiter, Fehler bleibt unbemerkt
curl https://api.example.com/data -o data.json
echo "Exit: $?"  # Exit: 0 (auch bei 404)

# Mit -f: Skript bricht sauber ab
curl -f https://api.example.com/data -o data.json
echo "Exit: $?"  # Exit: 22 bei 404

curl -s und --silent: Progress Bar unterdrücken

Der Flag -s schaltet die Progress Bar, Download Speed und restliche Statistik Ausgabe auf stderr ab. Pflicht in jedem Skript, das curl mit einer Pipe weiterverarbeitet. Ohne -s müllt curl Logs und CI Oberflächen mit Zeilen wie % Total % Received % Xferd Average Speed voll.

Achtung: -s unterdrückt auch echte Fehlermeldungen wie Could not resolve host. Ein stummes Skript ist ein schlechtes Skript. Deshalb fast immer zusammen mit -S nutzen, das im nächsten Abschnitt erklärt wird.

Code: 
          
# JSON Response direkt an jq weitergeben
curl -s https://api.github.com/users/octocat | jq '.name'

# Status Code in Variable speichern, Body verwerfen
status=$(curl -s -o /dev/null -w "%{http_code}" https://nevercodealone.de)
echo "HTTP Status: $status"

curl -S und --show-error: Fehler trotz Silent zeigen

Der Partner Flag zu -s. Mit -S zeigt curl trotz Silent Modus die echten Fehler Meldungen an: DNS Fehler, TLS Handshake Probleme, Connection Refused. Die Kombination -sS ist der Goldstandard für robuste Skripte: leise im Normalfall, laut bei echten Problemen.

Diese Kombination gehört in jeden Health Check, jedes Monitoring Skript und jede CI Pipeline. Sie verhindert, dass ein Ausfall der Gegenseite unbemerkt ein Deployment durchwinkt.

Code: 
          
# Health Check mit klarer Fehler Ausgabe
curl -sS --max-time 10 https://nevercodealone.de/api/health

# In CI: Body verwerfen, nur Exit Code prüfen
curl -sS -o /dev/null https://api.example.com/ping

curl -L und --location: Redirects automatisch folgen

curl folgt standardmäßig keinen HTTP Redirects. Bei einem 301 oder 302 bekommt man nur den Location Header zurück, nicht den eigentlichen Inhalt der Ziel URL. Für moderne Webseiten, die häufig von HTTP auf HTTPS umleiten oder von Root Domain auf www, ist das praktisch unbrauchbar.

Der Flag -L löst das Problem: curl folgt jeder 3xx Umleitung bis zur finalen URL. GitHub Release URLs leiten auf CDN Adressen um, Package Manager wie npm oder Homebrew nutzen intern Redirects, und fast jedes Install Skript benötigt diesen Flag. Wer ohne -L eine Datei von github.com/.../releases/latest herunterladen will, bekommt nur eine 0 Byte Datei.

Code: 
          
# Ohne -L: nur Location Header, kein Inhalt
curl https://github.com/user/repo/archive/main.tar.gz

# Mit -L: folgt dem Redirect zum CDN
curl -L https://github.com/user/repo/archive/main.tar.gz -o repo.tar.gz

# Maximale Redirects begrenzen (Loop Schutz)
curl -L --max-redirs 5 https://short.ly/abc123

curl -I und --head: Nur HTTP Header abrufen

Der Flag -I sendet einen HEAD Request statt eines GET Requests. curl bekommt nur die HTTP Header zurück: Status Code, Content Type, Cache Control, Content Length. Der eigentliche Body wird nicht geladen. Das ist der schnellste Weg, eine URL auf Verfügbarkeit, Redirect Verhalten oder Cache Header zu prüfen.

Kombiniert mit -L bekommt man die komplette Redirect Kette sichtbar gemacht: Jeder einzelne Hop mit seinem Status Code und der Location der Weiterleitung. Unverzichtbar beim Debuggen von SEO Problemen, HTTPS Migrationen und unsauberen 301 Ketten.

Code: 
          
# Nur Header einer URL
curl -I https://nevercodealone.de

# Redirect Kette komplett durchlaufen und alle Header zeigen
curl -IL https://nevercodealone.de/glossare

curl -o und -O: Output in Datei speichern

Ohne expliziten Output schreibt curl die Response auf stdout, also direkt ins Terminal. Das ist für HTML Seiten oder große Binaries unhandlich. Mit dem kleinen -o wird der Output in eine Datei mit frei wählbarem Namen umgeleitet.

Das große -O nimmt den Dateinamen direkt aus der URL. Das spart Tipparbeit, hat aber einen Fallstrick: Bei Redirects mit -L wird der Name der ursprünglichen URL verwendet, nicht der finalen Ziel URL. Für Downloads von GitHub Releases, wo die Ziel URL meist den eigentlichen Dateinamen trägt, empfiehlt sich curl -LJO. Der zusätzliche -J Flag respektiert den Content-Disposition Header.

Code: 
          
# Datei mit eigenem Namen speichern
curl -o installer.sh https://example.com/install.sh

# Original Dateiname aus URL
curl -O https://example.com/downloads/tool-v1.2.3.tar.gz

# Mit Content Disposition Header (GitHub Releases)
curl -LJO https://github.com/user/repo/releases/latest/download/tool.tar.gz

curl -H und --header: Custom HTTP Header senden

Mit -H werden beliebige HTTP Header zum Request hinzugefügt. Der häufigste Einsatz: API Authentifizierung mit Bearer Token und das Setzen des Content-Type bei POST Requests mit JSON Body. Jeder Header wird mit einem eigenen -H Flag übergeben, beliebig viele lassen sich kombinieren.

Wichtig: Anführungszeichen nicht vergessen, wenn der Header Wert Leerzeichen oder Sonderzeichen enthält. Shell Interpretation führt sonst zu sehr verwirrenden Fehlern, die beim Debuggen viel Zeit kosten.

Code: 
          
# API Request mit Bearer Token
curl -H "Authorization: Bearer $API_TOKEN" \
     https://api.example.com/data

# JSON POST mit mehreren Headern
curl -H "Content-Type: application/json" \
     -H "Accept: application/json" \
     -H "X-Request-ID: $(uuidgen)" \
     -d '{"name":"Roland"}' \
     https://api.example.com/users

curl -d und -X: POST, PUT, DELETE Requests

Sobald -d im Befehl auftaucht, wechselt curl automatisch auf POST. Ein explizites -X POST ist nicht nötig. Bei JSON APIs muss der Content-Type: application/json Header mitgesendet werden, sonst interpretieren viele Server den Body als Form URL Encoded.

Für andere HTTP Methoden wie PUT, PATCH, DELETE oder OPTIONS setzt -X die Methode explizit. Besonders beim Debuggen von REST APIs unverzichtbar. Für sehr große Bodies nutzt man --data-binary @datei.json, das liest den Inhalt aus einer Datei und vermeidet Shell Limits.

Code: 
          
# POST mit JSON (automatisch durch -d)
curl -H "Content-Type: application/json" \
     -d '{"name":"Roland","role":"CEO"}' \
     https://api.example.com/users

# DELETE Request
curl -X DELETE https://api.example.com/users/123

# PATCH mit JSON aus Datei
curl -X PATCH \
     -H "Content-Type: application/json" \
     --data-binary @update.json \
     https://api.example.com/users/123

curl --max-time und --retry: Timeouts und Retry Logik

Ohne Timeout wartet curl praktisch unendlich, wenn eine Gegenstelle nicht antwortet. In Skripten führt das zu hängenden CI Jobs und blockierten Deployments. Der Flag --max-time begrenzt die gesamte Request Dauer in Sekunden. Für feinere Kontrolle gibt es zusätzlich --connect-timeout, das nur die Zeit für den Verbindungsaufbau begrenzt.

Bei unzuverlässigen APIs hilft --retry: curl versucht den Request bei temporären Fehlern automatisch neu, mit optional einstellbarer Pause zwischen den Versuchen. Für produktive Health Checks ist die Kombination aus --max-time, --retry und -f der Industriestandard.

Code: 
          
# Health Check mit 5 Sekunden Timeout
curl -fsS --max-time 5 https://api.example.com/health

# Retry bis zu 3 Mal mit 2 Sekunden Pause
curl --retry 3 --retry-delay 2 --max-time 30 \
     https://unreliable-api.com/data

# Separate Connect und Total Timeouts
curl --connect-timeout 5 --max-time 30 \
     https://slow-api.example.com

curl -v und --verbose: Debug Ausgabe für Troubleshooting

Wenn ein curl Aufruf nicht funktioniert, ist -v der erste Griff. Der Verbose Modus zeigt den kompletten Request mit allen gesendeten Headern, den TLS Handshake inklusive Zertifikat Informationen und die vollständige Response inklusive aller Header des Servers. Damit lässt sich fast jedes HTTP Problem innerhalb weniger Sekunden eingrenzen.

Für noch tiefere Analysen gibt es --trace und --trace-ascii: Die schreiben die komplette Kommunikation byteweise in eine Datei. Unverzichtbar bei Binär Protokollen oder wenn der Server HTTP/2 oder HTTP/3 spricht und man die Frames sehen will.

Code: 
          
# Standard Debug Ausgabe
curl -v https://nevercodealone.de

# Verbose mit API Authentifizierung
curl -v -H "Authorization: Bearer $TOKEN" \
     https://api.example.com/users

# Komplettes Trace in Datei schreiben
curl --trace-ascii trace.log https://api.example.com/data

Die Kombi curl -fsSL: Der Install Skript Standard erklärt

Wer KI Tools wie Claude Code, Bun oder Ollama installiert, sieht immer dieselbe Kombination: curl -fsSL URL | bash. Die vier Buchstaben sind kein Zufall, sondern eine durchdachte Sicherheits Konfiguration.

Jeder Buchstabe hat eine klare Aufgabe: f bricht bei HTTP 4xx oder 5xx sofort ab, damit kein Fehler HTML als Shell Skript ausgeführt wird. s verhindert, dass die Progress Bar als Text in die Pipe fließt und das Skript verwirrt. S sorgt dafür, dass echte Fehler wie DNS Probleme sichtbar bleiben. L folgt Redirects, weil Installer meist auf CDNs liegen, die umleiten.

Code: 
          
# Die klassische Pipe to Shell Installation
curl -fsSL https://bun.sh/install | bash

# In Langform für bessere Lesbarkeit in CI Skripten
curl --fail --silent --show-error --location \
     https://bun.sh/install | bash

# Mit zusätzlichem Timeout für Produktion
curl -fsSL --max-time 60 https://bun.sh/install | bash

Sicherheit bei curl pipe bash: Was man wissen muss

Die Kombination curl | bash ist praktisch, aber nicht ohne Risiko. Man führt fremden Code mit den Rechten des aktuellen Users aus. Wenn der Server kompromittiert ist, die URL manipuliert wurde oder die HTTPS Verbindung unterwandert wird, läuft Schadcode auf dem eigenen Rechner. Für produktive Server und CI Umgebungen ist dieses Muster deshalb oft nicht akzeptabel.

Drei sicherere Alternativen: Skript erst herunterladen, dann prüfen, dann ausführen gibt eine Kontrollinstanz. Paket Manager statt Curl Skripte nutzen, wo immer verfügbar (apt, dnf, brew, snap, pkg). Prüfsummen oder GPG Signaturen verifizieren, die seriöse Projekte anbieten. Bei NCA Vibe Coding Consulting setzen wir mit unseren Kunden DevOps Pipelines auf, die diese Kontrollen automatisieren, ohne Entwickler Workflows auszubremsen.

Code: 
          
# Sicherer: Download, Review, Execute
curl -fsSL https://bun.sh/install -o install-bun.sh
less install-bun.sh   # Inhalt prüfen
bash install-bun.sh   # Ausführen

# Mit SHA256 Prüfsumme verifizieren
curl -fsSLO https://example.com/tool.tar.gz
curl -fsSL https://example.com/tool.tar.gz.sha256 | sha256sum -c

Die Kombi curl -IL: URL Checker für Redirect Ketten

Die zweite wichtige curl Kombination ist -IL. Sie sendet einen HEAD Request und folgt dabei allen Redirects. Statt eines einzigen Status Codes bekommt man die komplette Redirect Kette zu sehen: Jeder 301, jeder 302, jede Location, bis zur finalen URL mit dem endgültigen 200 OK. Ideal für SEO Audits, Debugging von HTTPS Migrationen und die Prüfung von Canonical Redirects.

Typischer Einsatz: Sie haben eine alte URL von einer Marketing Kampagne und wollen wissen, ob sie sauber auf die neue Ziel Seite umleitet, oder ob mehrere Zwischen Redirects Performance und SEO Rankings schaden. Mit -IL sehen Sie die Kette in Sekunden.

Code: 
          
# Redirect Kette einer URL prüfen
curl -IL https://nevercodealone.de/glossare

# Nur die finalen Status Codes extrahieren
curl -ILs https://nevercodealone.de/glossare | grep -i '^HTTP'

# Die finale URL nach allen Redirects
curl -ILs -o /dev/null -w "%{url_effective}\n" \
     https://nevercodealone.de/glossare

We want to make sure that all those 20 billion installations run fine.

Daniel Stenberg, Gründer und Lead Developer curl – FOSDEM 2025, via The New Stack

Praxis Beispiele: curl in KI Tool Installationen

Jedes moderne Entwickler Tool nutzt curl für die Erst Installation. Die Muster sind sehr ähnlich, die Flag Kombinationen fast identisch. Wer die oben erklärten Flags kennt, kann jeden Install Befehl in Sekunden einordnen. Drei konkrete Beispiele aus dem Alltag von NCA:

Code: 
          
# Claude Code: Node basierte Installation
curl -fsSL https://claude.ai/install.sh | bash

# Bun JavaScript Runtime
curl -fsSL https://bun.sh/install | bash

# Ollama für lokale LLMs
curl -fsSL https://ollama.com/install.sh | sh

# Homebrew auf macOS und Linux
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Rust via rustup
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Besonders auffällig: rustup setzt zusätzlich --proto '=https' und --tlsv1.2, um Downgrade Angriffe zu verhindern. Das ist der Gold Standard für Pipe to Shell Installationen und ein gutes Vorbild für eigene Skripte. Bei NCA nutzen wir diese Muster täglich, wenn wir für Kunden DSGVO konforme KI Infrastrukturen aufbauen und dabei Toolchains aus dem europäischen Raum bevorzugen.

Sie möchten Ihr Team im sicheren Umgang mit Terminal Tools schulen oder eine eigene Installation Pipeline für interne Tools aufbauen? Kostenlose Erstberatung per Mail oder telefonisch unter +49 176 24747727.

Lass uns sprechen

Finde das passende Angebot für dein Projekt

🤖

Hey! Ich bin CodeBot. Lass uns herausfinden, wie wir dein Projekt zum Fliegen bringen.

Was soll entstehen?

Häufige Fragen zu curl Flags im Linux Terminal

Antworten auf die häufigsten Fragen rund um curl Flags, Install Befehle und Terminal Workflows. Bei tiefergehenden Anforderungen unterstützt NCA mit individuellem Vibe Coding Consulting.

Was bedeutet curl -fsSL 2026 wirklich?

Die vier Flags stehen für fail, silent, show-error und location. curl bricht bei HTTP Fehlern ab, unterdrückt die Progress Bar, zeigt aber echte Fehler an und folgt Redirects. Diese Kombination ist der Standard für Install Skripte in 2026, weil sie robust und sicher ist, ohne Debugging Informationen zu verlieren.

Warum folgt curl Redirects 2026 nicht standardmäßig?

Das ist eine historische Design Entscheidung aus Sicherheitsgründen. Ein automatischer Redirect kann von einer HTTPS Seite auf eine HTTP Seite führen oder zu einer anderen Domain umleiten. curl zwingt Nutzer, sich bewusst für dieses Verhalten mit dem Flag -L zu entscheiden, statt es stillschweigend anzunehmen.

Wie prüfe ich mit curl eine URL 2026 ohne Download?

Mit dem Flag -I sendet curl einen HEAD Request und bekommt nur die HTTP Header zurück. Der Befehl curl -I https://nevercodealone.de zeigt Status Code, Content Type und Cache Header, ohne den HTML Body zu laden. Kombiniert mit -L sieht man die komplette Redirect Kette.

Was ist der Unterschied zwischen -s und -S bei curl 2026?

Das kleine -s unterdrückt die Progress Bar und auch Fehlermeldungen. Das große -S ist das Gegenstück: Es zeigt Fehler auch im Silent Modus an. Die Kombination -sS macht curl leise im Normalfall, aber laut bei echten Problemen wie DNS Ausfällen oder TLS Fehlern.

Wie sende ich einen POST Request mit JSON per curl 2026?

Mit den Flags -H für den Content Type und -d für den Body. Der Befehl curl -H 'Content-Type: application/json' -d '{"key":"value"}' https://api.example.com/endpoint sendet einen POST Request mit JSON Body. Das -X POST ist nicht nötig, curl erkennt den POST automatisch durch -d.

Welcher Exit Code zeigt einen HTTP Fehler bei curl?

Mit dem Flag -f gibt curl bei HTTP 4xx oder 5xx den Exit Code 22 zurück. Ohne -f liefert curl auch bei 404 oder 500 den Exit Code 0, weil der Request technisch erfolgreich war. Für Skripte ist -f deshalb Pflicht, sonst bleiben HTTP Fehler unbemerkt.

Wie setze ich einen Timeout für curl?

Mit --max-time begrenzt man die gesamte Request Dauer in Sekunden. Der Befehl curl --max-time 10 prüft, ob eine Antwort innerhalb von 10 Sekunden kommt. Für feinere Kontrolle gibt es --connect-timeout, das nur die Zeit für den Verbindungsaufbau begrenzt.

Was macht der Flag -I bei curl genau?

Der Flag -I sendet einen HEAD Request statt eines GET Requests. curl empfängt nur die HTTP Header des Servers, nicht den Body. Das ist deutlich schneller und spart Bandbreite, wenn man nur Status Code, Content Type oder Cache Header prüfen will. Ideal für URL Verfügbarkeits Checks.

Wann sollte ich curl pipe bash vermeiden?

Auf produktiven Servern, bei unbekannten Quellen und in Umgebungen mit hohen Compliance Anforderungen. Die sichere Alternative ist, das Skript erst mit -o in eine Datei zu speichern, den Inhalt zu prüfen und erst dann mit bash auszuführen. Seriöse Projekte bieten SHA256 Prüfsummen, die vor der Ausführung verifiziert werden sollten.

Wie debugge ich einen fehlerhaften curl Request?

Mit dem Flag -v aktiviert man den Verbose Modus. curl zeigt dann alle gesendeten Request Header, den kompletten TLS Handshake und die empfangenen Response Header. Für noch tiefere Analysen hilft --trace-ascii, das die komplette Kommunikation byteweise in eine Datei schreibt.

Was ist der Unterschied zwischen curl -o und -O?

Der kleine -o speichert die Response unter einem frei wählbaren Dateinamen. Das große -O nimmt den Dateinamen aus der URL. Achtung: Bei Redirects mit -L nutzt -O weiterhin den Namen der ursprünglichen URL. Für GitHub Releases ist deshalb -LJO die bessere Wahl, weil es den Content Disposition Header respektiert.

Kann curl Cookies speichern und wiederverwenden?

Ja, dafür gibt es zwei Flags. Mit -c cookies.txt speichert curl alle empfangenen Cookies in einer Datei. Mit -b cookies.txt liest curl die Cookies aus der Datei und sendet sie mit. Das ermöglicht Login Sessions, die über mehrere curl Aufrufe hinweg bestehen bleiben, ohne manuelle Header Verwaltung.