2.9 curl – HTTP-, HTTPS-, API-, DNS-, Proxy- und Verbindungsdiagnose Ziel dieser Seite curl überträgt Daten anhand einer URL und eignet sich besonders zur Diagnose von Webdiensten und APIs. Administratoren können damit unter anderem prüfen: ob ein TCP-Dienst erreichbar ist; ob ein Webserver auf HTTP oder HTTPS antwortet; welchen HTTP-Statuscode ein Server zurückgibt; ob Weiterleitungen funktionieren; ob DNS-Auflösung und Zielserver zusammenpassen; ob TLS-Verbindungen und Zertifikatsprüfungen funktionieren; ob SNI und virtuelle Hosts korrekt verarbeitet werden; wie lange DNS, TCP-Verbindungsaufbau, TLS und Serverantwort dauern; ob ein Proxy Verbindungen erlaubt oder verändert; ob bestimmte HTTP-Header übertragen werden; ob eine API auf GET-, POST-, PUT-, PATCH- oder DELETE-Anfragen reagiert; ob IPv4 und IPv6 unterschiedliche Ergebnisse liefern. curl ist kein vollständiger Browser. JavaScript, grafische Darstellung, Browser-Erweiterungen und komplexe Browser-Sitzungen werden nicht wie in einem normalen Webbrowser ausgeführt. Kennzeichnungen Kennzeichnung Bedeutung [RO] Lokale Informationsabfrage [TEST] Aktive Netzwerk- oder Anwendungsanfrage [PRIV] Erhöhte Berechtigungen können erforderlich sein [FILE] Befehl liest oder erstellt eine Datei [SENS] Anfrage oder Ausgabe kann sensible Informationen enthalten [CHANGE] Anfrage kann Daten oder einen Zustand verändern [DISRUPT] Anfrage kann einen Dienst oder produktive Daten beeinflussen 1. Wie wird curl unter Windows, Linux und macOS aufgerufen? Betriebssystemübersicht anzeigen Aufgabe Windows Linux macOS Programmpfad [RO] Get-Command curl.exe [RO] command -v curl [RO] command -v curl Version [RO] curl.exe --version [RO] curl --version [RO] curl --version Kurzhilfe [RO] curl.exe --help [RO] curl --help [RO] curl --help Gesamte Hilfe [RO] curl.exe --manual [RO] curl --manual [RO] curl --manual Lokales Handbuch Nicht standardmäßig [RO] man curl [RO] man curl Wichtig unter Windows PowerShell In älteren Windows-PowerShell-Versionen kann curl als Alias für Invoke-WebRequest definiert sein. Dann verhält sich der Befehl nicht wie das echte curl-Programm. Deshalb unter Windows eindeutig verwenden: [RO] curl.exe --version Alias prüfen: [RO] Get-Command curl Wenn als Befehlstyp Alias und als Ziel Invoke-WebRequest erscheint, muss für die in dieser Seite gezeigte Syntax ausdrücklich curl.exe verwendet werden. Build-Funktionen prüfen [RO] curl --version Die Ausgabe zeigt unter anderem: curl-Version; verwendete TLS-Bibliothek; unterstützte Protokolle; unterstützte Funktionen; HTTP/2- oder HTTP/3-Unterstützung; IPv6-Unterstützung; Kompressionsunterstützung. Nicht jede curl-Installation unterstützt alle Optionen und Protokolle. Entscheidend ist der lokal installierte Build. 2. Was passiert bei einem einfachen curl-Aufruf? Grundlegende Anfrage anzeigen Linux und macOS: [TEST][SENS] curl https://example.com/ Windows: [TEST][SENS] curl.exe https://example.com/ Ohne weitere Optionen schreibt curl den empfangenen Antwortinhalt auf die Standardausgabe. Bei einer HTML-Seite erscheint daher der HTML-Quelltext: ... Explizites URL-Schema verwenden Empfohlen: https://example.com/ Nicht empfohlen: example.com Ohne Schema versucht curl, das Protokoll zu erraten. Für reproduzierbare Diagnosen sollte immer ausdrücklich http:// oder https:// angegeben werden. URL in Anführungszeichen setzen [TEST][SENS] curl 'https://example.com/search?q=test&lang=de' Besonders Zeichen wie diese können von einer Shell interpretiert werden: & ? * [ ] { } In PowerShell und klassischen Windows-Kommandozeilen können sich die Regeln für Anführungszeichen unterscheiden. Bei einfachen URLs funktionieren doppelte Anführungszeichen meist plattformübergreifend: [TEST][SENS] curl "https://example.com/search?q=test&lang=de" 3. Wie werden HTTP-Header angezeigt? Headeroptionen anzeigen Nur Antwortheader anfordern [TEST][SENS] curl -I https://example.com/ -I beziehungsweise --head veranlasst curl bei HTTP, eine HEAD -Anfrage zu senden. Header und Antwortinhalt anzeigen [TEST][SENS] curl -i https://example.com/ -i fügt die Antwortheader vor dem Inhalt ein. Antwortheader separat auf die Standardausgabe schreiben [TEST][SENS] curl -D - https://example.com/ Header in eine Datei schreiben [TEST][FILE][SENS] curl -D response-headers.txt -o response-body.html https://example.com/ Wichtiger Unterschied Option Wirkung -I Sendet bei HTTP eine HEAD-Anfrage -i Zeigt Header und Antwortinhalt einer normalen Anfrage -D DATEI Schreibt empfangene Header separat -o DATEI Schreibt den Antwortinhalt in eine Datei Nicht jeder Server behandelt HEAD und GET identisch. Ein erfolgreicher HEAD-Test beweist deshalb nicht sicher, dass ein GET-Aufruf denselben Status erhält. GET ausführen, aber Antwortinhalt verwerfen Linux und macOS: [TEST][SENS] curl -sS -o /dev/null -D - https://example.com/ Windows: [TEST][SENS] curl.exe -sS -o NUL -D - https://example.com/ Damit wird eine normale GET-Anfrage durchgeführt, ohne den vollständigen Inhalt im Terminal auszugeben. 4. Wie wird nur der HTTP-Statuscode ausgegeben? Statuscode-Prüfung anzeigen Linux und macOS: [TEST] curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/ Windows: [TEST] curl.exe -sS -o NUL -w "%{http_code}\n" https://example.com/ Statuscode und Ziel-URL nach Weiterleitungen Linux und macOS: [TEST] curl -sS -L -o /dev/null -w "HTTP=%{http_code} URL=%{url_effective}\n" https://example.com/ Windows: [TEST] curl.exe -sS -L -o NUL -w "HTTP=%{http_code} URL=%{url_effective}\n" https://example.com/ HTTP-Statusgruppen Bereich Bedeutung 100–199 Information 200–299 Erfolgreiche Verarbeitung 300–399 Weiterleitung 400–499 Anfrage- oder Clientfehler 500–599 Serverfehler Häufige Statuscodes Status Bedeutung 200 OK Anfrage erfolgreich 201 Created Ressource erstellt 204 No Content Erfolgreich, aber ohne Antwortinhalt 301 Moved Permanently Dauerhafte Weiterleitung 302 Found Temporäre Weiterleitung 304 Not Modified Ressource seit Cacheprüfung nicht geändert 307 Temporary Redirect Temporäre Weiterleitung unter Beibehaltung der Methode 308 Permanent Redirect Dauerhafte Weiterleitung unter Beibehaltung der Methode 400 Bad Request Anfrage syntaktisch oder fachlich ungültig 401 Unauthorized Authentifizierung fehlt oder ist ungültig 403 Forbidden Anfrage verstanden, Zugriff verweigert 404 Not Found Ressource nicht gefunden 405 Method Not Allowed HTTP-Methode nicht erlaubt 408 Request Timeout Server wartete zu lange auf die Anfrage 409 Conflict Konflikt mit aktuellem Ressourcenstatus 429 Too Many Requests Rate Limit erreicht 500 Internal Server Error Interner Serverfehler 502 Bad Gateway Gateway oder Proxy erhielt ungültige Upstream-Antwort 503 Service Unavailable Dienst momentan nicht verfügbar 504 Gateway Timeout Gateway erhielt nicht rechtzeitig eine Upstream-Antwort Ein HTTP-Fehlercode bedeutet, dass die HTTP-Kommunikation grundsätzlich stattgefunden hat. DNS, TCP und normalerweise auch TLS waren bis zu diesem Punkt bereits erfolgreich. 5. Warum liefert curl bei einem HTTP-Fehler trotzdem Exitcode 0? HTTP-Status und curl-Exitcode unterscheiden Ohne --fail bewertet curl eine erfolgreich empfangene HTTP-Antwort als erfolgreiche Übertragung – auch wenn der Server beispielsweise 404 oder 500 zurückgibt. HTTP-Statuscode 404 curl-Exitcode 0 Das bedeutet: Übertragung technisch erfolgreich Anwendung meldet HTTP-Fehler Bei HTTP-Fehlern mit Exitcode ungleich 0 beenden [TEST] curl --fail https://example.com/missing Kurzform: [TEST] curl -f https://example.com/missing HTTP-Fehlercode liefern und Antwortinhalt behalten [TEST][SENS] curl --fail-with-body https://example.com/missing --fail-with-body : liefert bei HTTP-Status 400 oder höher einen curl-Fehler; behält den Server-Antwortinhalt bei; verwendet bei einem entsprechenden HTTP-Fehler normalerweise curl-Exitcode 22 . Für Skripte häufig sinnvoll [TEST] curl -sS --fail-with-body https://example.com/health Option Verhalten -s Fortschrittsanzeige unterdrücken -S Fehlermeldung trotz -s anzeigen --fail-with-body HTTP-Fehler als curl-Fehler behandeln und Inhalt behalten 6. Wie werden Weiterleitungen untersucht? Redirect-Diagnose anzeigen Nur erste Antwort anzeigen [TEST][SENS] curl -I http://example.com/ Mögliche Ausgabe: HTTP/1.1 301 Moved Permanently Location: https://example.com/ Weiterleitungen automatisch verfolgen [TEST][SENS] curl -L http://example.com/ Header aller Weiterleitungsstufen anzeigen [TEST][SENS] curl -L -I http://example.com/ Maximale Anzahl Weiterleitungen begrenzen [TEST][SENS] curl -L --max-redirs 5 https://example.com/ Effektive Ziel-URL ausgeben Linux und macOS: [TEST] curl -sS -L -o /dev/null -w "%{url_effective}\n" http://example.com/ Windows: [TEST] curl.exe -sS -L -o NUL -w "%{url_effective}\n" http://example.com/ Typische Redirect-Probleme HTTP leitet nicht auf HTTPS weiter; Weiterleitung zeigt auf falschen Hostnamen; Endlosschleife zwischen zwei URLs; falscher Port in Location ; interne Serveradresse wird offengelegt; Reverse Proxy erzeugt falsches Schema; Anwendung berücksichtigt X-Forwarded-Proto nicht; Authentifizierungscookie gilt nicht für das neue Ziel; Weiterleitung funktioniert im Browser wegen Cache, mit curl aber nicht. --location-trusted kann Zugangsdaten auch an andere Weiterleitungsziele weitergeben. Diese Option sollte aus Sicherheitsgründen nicht unüberlegt verwendet werden. 7. Wie wird eine ausführliche Verbindungsdiagnose durchgeführt? Verbose-Ausgabe `-v` anzeigen [TEST][SENS] curl -v https://example.com/ Die ausführliche Ausgabe enthält unter anderem: DNS-Ergebnis; ausgewählte IP-Adresse; TCP-Verbindungsaufbau; TLS-Verhandlung; Zertifikatsinformationen; ausgehandeltes Protokoll; gesendete HTTP-Header; empfangene HTTP-Header; Weiterleitungsinformationen; Wiederverwendung einer Verbindung. Kennzeichnungen in der Ausgabe Zeichen Bedeutung * curl-interne Status- oder Verbindungsinformation > Von curl an den Server gesendete Daten beziehungsweise Header < Vom Server empfangene Daten beziehungsweise Header { oder } In bestimmten Trace-Ausgaben übertragene Daten Beispiel: > GET / HTTP/1.1 > Host: example.com > User-Agent: curl/... > Accept: */* < HTTP/1.1 200 OK < Content-Type: text/html < Content-Length: 1256 Nur Header und Verbindungsinformationen, Inhalt verwerfen Linux und macOS: [TEST][SENS] curl -v -o /dev/null https://example.com/ Windows: [TEST][SENS] curl.exe -v -o NUL https://example.com/ Die Verbose-Ausgabe kann Zugangsdaten, Cookies, API-Token oder interne Header enthalten. Sie muss vor einer Weitergabe geprüft und bereinigt werden. 8. Wie wird eine detaillierte Ablaufverfolgung erstellt? Trace-Optionen anzeigen ASCII-Trace in eine Datei schreiben [TEST][FILE][SENS] curl --trace-ascii curl-trace.txt https://example.com/ Trace mit Zeitstempeln [TEST][FILE][SENS] curl --trace-time --trace-ascii curl-trace.txt https://example.com/ Binären Trace schreiben [TEST][FILE][SENS] curl --trace curl-trace.bin https://example.com/ Ein Trace kann deutlich mehr Informationen als -v enthalten, darunter: vollständige Header; Nutzdaten; Cookies; Formulardaten; Authentifizierungsinformationen; API-Antworten; interne Adressen. Trace-Dateien sind daher als sensible Diagnosedaten zu behandeln. Nicht gleichzeitig unkontrolliert verwenden -v --trace --trace-ascii --trace beziehungsweise --trace-ascii überschreibt die frühere Auswahl der Trace-Ausgabe. Für eine reproduzierbare Diagnose sollte nur die tatsächlich benötigte Variante verwendet werden. 9. Wie werden DNS-, TCP-, TLS- und Serverzeiten gemessen? Zeitmessung mit `--write-out` anzeigen Linux und macOS: [TEST] curl -sS -o /dev/null -w "DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Gesamt=%{time_total}s HTTP=%{http_code}\n" https://example.com/ Windows: [TEST] curl.exe -sS -o NUL -w "DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Gesamt=%{time_total}s HTTP=%{http_code}\n" https://example.com/ Bedeutung der Zeitwerte Variable Bedeutung time_namelookup Zeit bis zum Abschluss der Namensauflösung time_connect Zeit vom Start bis zur hergestellten TCP-Verbindung time_appconnect Zeit bis zum Abschluss des TLS- oder anderen Anwendungs-Handshakes time_pretransfer Zeit bis unmittelbar vor Beginn der Übertragung time_starttransfer Zeit bis zum ersten empfangenen Antwortbyte time_redirect Gesamtdauer vorheriger Weiterleitungen time_total Gesamtdauer der Übertragung http_code Letzter empfangener HTTP-Statuscode remote_ip Tatsächlich verwendete Ziel-IP-Adresse remote_port Tatsächlich verwendeter Zielport local_ip Verwendete lokale IP-Adresse num_redirects Anzahl verfolgter Weiterleitungen url_effective Effektive URL nach Weiterleitungen Erweiterte Messung Linux und macOS: [TEST] curl -sS -L -o /dev/null -w "Lokal=%{local_ip} Remote=%{remote_ip}:%{remote_port} DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Redirect=%{time_redirect}s Gesamt=%{time_total}s Status=%{http_code} Redirects=%{num_redirects} URL=%{url_effective}\n" https://example.com/ Windows: [TEST] curl.exe -sS -L -o NUL -w "Lokal=%{local_ip} Remote=%{remote_ip}:%{remote_port} DNS=%{time_namelookup}s TCP=%{time_connect}s TLS=%{time_appconnect}s TTFB=%{time_starttransfer}s Redirect=%{time_redirect}s Gesamt=%{time_total}s Status=%{http_code} Redirects=%{num_redirects} URL=%{url_effective}\n" https://example.com/ 10. Wie werden Zeitmessungen richtig interpretiert? Zeitanteile einordnen Die Zeitvariablen sind überwiegend kumulativ seit Beginn des curl-Aufrufs. Für einzelne Phasen müssen Differenzen gebildet werden. DNS-Dauer DNS = time_namelookup TCP-Aufbau nach DNS TCP-Phase = time_connect - time_namelookup TLS-Handshake nach TCP-Aufbau TLS-Phase = time_appconnect - time_connect Serververarbeitung bis zum ersten Byte Bei HTTPS vereinfacht: Server-/Anwendungsphase = time_starttransfer - time_appconnect Übertragung nach dem ersten Byte Downloadphase = time_total - time_starttransfer Beispiel Messwert Wert time_namelookup 0,020 s time_connect 0,050 s time_appconnect 0,120 s time_starttransfer 0,420 s time_total 0,500 s Daraus folgt: DNS = 0,020 s TCP = 0,050 - 0,020 = 0,030 s TLS = 0,120 - 0,050 = 0,070 s Server bis erstes Byte = 0,420 - 0,120 = 0,300 s Restliche Übertragung = 0,500 - 0,420 = 0,080 s Diese Zuordnung ist eine Diagnosehilfe. Proxys, wiederverwendete Verbindungen, Weiterleitungen und unterschiedliche Protokolle können die Interpretation verändern. 11. Wie werden Verbindungs- und Gesamtzeit begrenzt? Timeouts anzeigen Maximal fünf Sekunden für den Verbindungsaufbau [TEST] curl --connect-timeout 5 https://example.com/ Maximal 15 Sekunden für den gesamten Vorgang [TEST] curl --max-time 15 https://example.com/ Kurzform: [TEST] curl -m 15 https://example.com/ Kombination [TEST] curl --connect-timeout 5 --max-time 15 https://example.com/ Option Begrenzter Bereich --connect-timeout Verbindungsphase einschließlich notwendiger DNS-, TCP- und gegebenenfalls Proxy-/TLS-Vorgänge bis zur Verbindung --max-time Gesamter curl-Vorgang Langsame Übertragung abbrechen [TEST] curl --speed-limit 1000 --speed-time 10 https://example.com/large-file Der Vorgang wird abgebrochen, wenn die Übertragungsrate während des festgelegten Zeitraums unter dem Grenzwert liegt. Zu kurze Timeouts können langsame, aber funktionierende Verbindungen fälschlich als Fehler erscheinen lassen. 12. Wie werden IPv4 und IPv6 getrennt geprüft? IPv4-/IPv6-Vergleich anzeigen IPv4 erzwingen [TEST] curl -4 -v https://example.com/ IPv6 erzwingen [TEST] curl -6 -v https://example.com/ Nur Status und Ziel-IP vergleichen Linux und macOS: [TEST] curl -4 -sS -o /dev/null -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ [TEST] curl -6 -sS -o /dev/null -w "IPv6=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ Windows: [TEST] curl.exe -4 -sS -o NUL -w "IPv4=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ [TEST] curl.exe -6 -sS -o NUL -w "IPv6=%{remote_ip} HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ Interpretation IPv4 IPv6 Mögliche Ursache Funktioniert Funktioniert nicht IPv6-DNS, Routing, Firewall, Neighbor Discovery oder MTU Langsam Schnell Unterschiedlicher Netzwerkpfad oder unterschiedliche Gegenstelle Schnell Langsam IPv6-Pfad, Tunnel oder Zielserver prüfen Unterschiedliche Inhalte DNS-/CDN-/Proxy-Zuordnung untersuchen 13. Wie wird ein Hostname gezielt gegen eine bestimmte IP-Adresse getestet? DNS umgehen, Hostname und TLS-SNI erhalten Für HTTPS muss der Hostname normalerweise gleichzeitig für diese Funktionen erhalten bleiben: HTTP- Host -Header; TLS-SNI; Zertifikatsprüfung; virtuelle Hostauswahl. Dafür eignet sich --resolve . [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/ Dieser Befehl bedeutet: Hostname in URL: example.com Zielport: 443 Tatsächliche Ziel-IP: 192.0.2.20 HTTP-Host: example.com TLS-SNI: example.com Zertifikatsname: example.com Ausführlicher Test [TEST][SENS] curl -v --resolve example.com:443:192.0.2.20 https://example.com/ HTTP ohne TLS [TEST][SENS] curl --resolve example.com:80:192.0.2.20 http://example.com/ Warum nicht nur die IP-Adresse aufrufen? curl https://192.0.2.20/ Dabei verwendet curl die IP-Adresse als Zielnamen. Das kann verursachen: falschen virtuellen Host; falsches TLS-SNI; Zertifikatsnamensfehler; andere Serverantwort; Standardseite des Reverse Proxys. Nur einen Host-Header setzen curl -H "Host: example.com" https://192.0.2.20/ setzt zwar den HTTP-Host-Header, aber nicht automatisch das passende TLS-SNI für example.com . Für HTTPS ist --resolve deshalb in der Regel die richtige Diagnoseoption. 14. Was ist der Unterschied zwischen --resolve und --connect-to ? Zielumleitung erklären --resolve [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/ --resolve fügt für die angegebene Host-/Portkombination eine temporäre Namenszuordnung hinzu. --connect-to [TEST][SENS] curl --connect-to example.com:443:192.0.2.20:8443 https://example.com/ Damit verbindet sich curl tatsächlich mit: 192.0.2.20:8443 Die ursprüngliche URL bleibt: https://example.com/ Dadurch bleiben insbesondere: URL-Hostname; TLS-SNI; Zertifikatsprüfung; HTTP-Host auf example.com bezogen. Typischer Einsatz neuen Reverse Proxy vor DNS-Umschaltung testen; Backend auf einem anderen Port prüfen; Load-Balancer-Knoten gezielt untersuchen; Blue-Green-Deployment vergleichen; fehlerhaften DNS-Eintrag umgehen, ohne Hostname und SNI zu verlieren. Beide Optionen gelten nur für den jeweiligen curl-Aufruf und verändern nicht dauerhaft die lokale DNS-Konfiguration. 15. Wie werden TLS und Zertifikate geprüft? TLS-Diagnose anzeigen Normale Zertifikatsprüfung [TEST][SENS] curl -v https://example.com/ curl prüft dabei abhängig vom verwendeten TLS-Backend unter anderem: Vertrauenskette; Gültigkeitszeitraum; Hostname; unterstützte TLS-Versionen; Zertifizierungsstelle; TLS-Handshake. Bestimmte CA-Datei verwenden [TEST][FILE][SENS] curl --cacert company-ca.pem https://internal.example.com/ TLS 1.2 oder höher anfordern [TEST][SENS] curl --tlsv1.2 https://example.com/ --tlsv1.2 legt die minimale TLS-Version auf 1.2 fest. Neuere Versionen können weiterhin ausgehandelt werden. Maximal TLS 1.2 [TEST][SENS] curl --tlsv1.2 --tls-max 1.2 https://example.com/ TLS 1.3 oder höher anfordern [TEST][SENS] curl --tlsv1.3 https://example.com/ Die Unterstützung hängt von curl-Version und TLS-Bibliothek ab. Clientzertifikat [TEST][FILE][SENS] curl --cert client.pem --key client.key https://example.com/ Format und Optionen können vom verwendeten TLS-Backend abhängen. Zertifikatsprüfung deaktivieren [TEST][SENS] curl -k https://example.com/ -k beziehungsweise --insecure deaktiviert die normale Echtheitsprüfung. Dadurch kann curl keine vertrauenswürdige Identität des Servers garantieren. -k darf höchstens als klar gekennzeichneter Vergleichstest verwendet werden. Es ist keine Lösung für ein Zertifikatsproblem. Sinnvolle Interpretation Normaler Test Mit -k Mögliche Ursache Fehler Erfolgreich Zertifikatsvertrauen, Hostname oder Zertifikatskette prüfen Fehler Fehler Problem wahrscheinlich nicht nur Zertifikatsprüfung Erfolgreich Erfolgreich Kein Grund, -k dauerhaft zu verwenden 16. Wie werden HTTP-Versionen geprüft? HTTP/1.1, HTTP/2 und HTTP/3 anzeigen HTTP/1.1 anfordern [TEST][SENS] curl --http1.1 -v https://example.com/ HTTP/2 anfordern [TEST][SENS] curl --http2 -v https://example.com/ HTTP/3 versuchen [TEST][SENS] curl --http3 -v https://example.com/ Ausschließlich HTTP/3 [TEST][SENS] curl --http3-only -v https://example.com/ Die Optionen funktionieren nur, wenn der installierte curl-Build die jeweilige Protokollversion unterstützt: [RO] curl --version Interpretation Beobachtung Mögliche Ursache HTTP/1.1 funktioniert, HTTP/2 nicht Proxy, TLS-ALPN, Server- oder curl-Buildproblem HTTP/2 funktioniert, HTTP/3 nicht QUIC/UDP, Firewall, Serverunterstützung oder curl-Build HTTP/3 funktioniert nur ohne VPN VPN oder Firewall blockiert beziehungsweise beeinträchtigt UDP Unterschiedliche Antworten Reverse Proxy oder Anwendung behandelt Protokolle unterschiedlich HTTP/3 verwendet QUIC über UDP. Ein erfolgreicher HTTPS-Test über TCP beweist deshalb nicht, dass HTTP/3 erreichbar ist. 17. Wie werden eigene Request-Header gesetzt? Header mit `-H` anzeigen Accept-Header setzen [TEST][SENS] curl -H "Accept: application/json" https://api.example.com/status Benutzerdefinierten Header setzen [TEST][SENS] curl -H "X-Diagnostic-ID: test-001" https://example.com/ Mehrere Header [TEST][SENS] curl -H "Accept: application/json" -H "X-Diagnostic-ID: test-001" https://api.example.com/status User-Agent setzen [TEST][SENS] curl -A "IT-Diagnose/1.0" https://example.com/ Alternativ: [TEST][SENS] curl -H "User-Agent: IT-Diagnose/1.0" https://example.com/ Header entfernen [TEST][SENS] curl -H "User-Agent:" https://example.com/ Ein Header mit leerem Wert nach dem Doppelpunkt wird entfernt. Vorsicht Benutzerdefinierte Header können: Routing im Reverse Proxy verändern; Authentifizierung beeinflussen; Caches umgehen; Sicherheitsregeln auslösen; sensible Informationen enthalten. Header aus Browser-Entwicklerwerkzeugen dürfen nicht ungeprüft übernommen werden. Insbesondere Cookies, Tokens und Sitzungskennungen müssen geschützt werden. 18. Wie werden GET-Parameter korrekt übertragen? Query-Parameter anzeigen Parameter direkt in der URL [TEST][SENS] curl "https://api.example.com/search?q=server&limit=10" Parameter URL-codieren [TEST][SENS] curl -G --data-urlencode "q=Server Fehleranalyse" --data-urlencode "limit=10" https://api.example.com/search -G sorgt dafür, dass die mit --data-urlencode angegebenen Daten als URL-Query und nicht als POST-Body verwendet werden. Ergebnis sinngemäß: https://api.example.com/search?q=Server%20Fehleranalyse&limit=10 Warum URL-Encoding wichtig ist Zeichen wie diese besitzen in URLs eine besondere Bedeutung: Leerzeichen & = ? # + % --data-urlencode verhindert viele Fehler durch nicht korrekt codierte Werte. 19. Wie werden POST-, PUT-, PATCH- und DELETE-Anfragen getestet? HTTP-Methoden und API-Beispiele anzeigen Ändernde API-Anfragen dürfen nur gegen ausdrücklich freigegebene Testressourcen ausgeführt werden. POST mit Formulardaten [TEST][CHANGE][SENS] curl -X POST -d "name=Max Mustermann" -d "active=true" https://api.example.com/users Bei Verwendung von -d wählt curl bei HTTP automatisch POST, sofern keine andere Methode angegeben wird. -X POST ist deshalb häufig nicht erforderlich: [TEST][CHANGE][SENS] curl -d "name=Max Mustermann" -d "active=true" https://api.example.com/users POST mit JSON [TEST][CHANGE][SENS] curl -H "Content-Type: application/json" -d '{"name":"Max Mustermann","active":true}' https://api.example.com/users Neuere curl-Versionen unterstützen: [TEST][CHANGE][SENS] curl --json '{"name":"Max Mustermann","active":true}' https://api.example.com/users --json setzt geeignete JSON-Header und verwendet die Daten als Request-Body. Die Verfügbarkeit hängt von der curl-Version ab. JSON aus Datei [TEST][FILE][CHANGE][SENS] curl -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users PUT [TEST][CHANGE][SENS] curl -X PUT -H "Content-Type: application/json" --data-binary @request.json https://api.example.com/users/123 PATCH [TEST][CHANGE][SENS] curl -X PATCH -H "Content-Type: application/json" -d '{"active":false}' https://api.example.com/users/123 DELETE [TEST][CHANGE][DISRUPT][SENS] curl -X DELETE https://api.example.com/users/123 OPTIONS [TEST][SENS] curl -i -X OPTIONS https://api.example.com/users OPTIONS kann Hinweise auf erlaubte Methoden oder CORS-Header liefern. Server müssen jedoch nicht alle Fähigkeiten vollständig darüber offenlegen. 20. Was ist der Unterschied zwischen -d und --data-binary ? Übertragung von Request-Daten erklären Option Verhalten -d beziehungsweise --data Sendet HTTP-Daten; Zeilenenden und Dateieinlesung folgen den Regeln dieser Option --data-raw Wie --data , aber @ wird nicht als Dateiverweis behandelt --data-binary Überträgt Daten weitgehend unverändert --data-urlencode URL-codiert die Daten --json Sendet JSON und setzt passende Header Textdaten [TEST][CHANGE][SENS] curl -d "name=Max Mustermann" https://api.example.com/users Datei binär beziehungsweise unverändert senden [TEST][FILE][CHANGE][SENS] curl --data-binary @request.json https://api.example.com/import Wörtliches @ senden [TEST][CHANGE][SENS] curl --data-raw "@example" https://api.example.com/test Bei -d @datei interpretiert curl den Wert als Dateipfad. Bei --data-raw wird ein führendes @ dagegen wörtlich übertragen. 21. Wie werden Dateien hoch- und heruntergeladen? Dateitransfer anzeigen Antwort in benannte Datei schreiben [TEST][FILE][SENS] curl -o download.bin https://example.com/file.bin Remote-Dateinamen verwenden [TEST][FILE][SENS] curl -O https://example.com/file.bin Weiterleitung verfolgen und Remote-Dateinamen verwenden [TEST][FILE][SENS] curl -L -O https://example.com/file.bin Teilweise Übertragung fortsetzen [TEST][FILE][SENS] curl -C - -O https://example.com/file.bin Download bei Fehler entfernen [TEST][FILE][SENS] curl --fail --remove-on-error -o download.bin https://example.com/file.bin Datei mit PUT hochladen [TEST][FILE][CHANGE][SENS] curl -T upload.bin https://example.com/upload.bin Multipart-Formularupload [TEST][FILE][CHANGE][SENS] curl -F "file=@upload.bin" https://example.com/upload Vor einem Upload müssen Ziel, Methode, Überschreibverhalten und Berechtigung geprüft werden. 22. Wie wird eine HTTP-Authentifizierung getestet? Basic, Digest, Bearer und Negotiate anzeigen Benutzername angeben und Passwort interaktiv abfragen [TEST][SENS] curl -u "max.mustermann" https://example.com/protected curl fordert das Passwort interaktiv an. Benutzername und Passwort direkt angeben [TEST][SENS] curl -u "max.mustermann:BEISPIELPASSWORT" https://example.com/protected Diese Schreibweise ist für reale Zugangsdaten nicht empfohlen, weil das Passwort: in der Shell-Historie; in Prozessinformationen; in Bildschirmaufzeichnungen; in Supportprotokollen sichtbar werden kann. Basic Authentication ausdrücklich verwenden [TEST][SENS] curl --basic -u "max.mustermann" https://example.com/protected Digest Authentication [TEST][SENS] curl --digest -u "max.mustermann" https://example.com/protected Unterstützte Methode automatisch auswählen [TEST][SENS] curl --anyauth -u "max.mustermann" https://example.com/protected --anyauth kann eine zusätzliche Anfrage erzeugen, um die angebotenen Methoden zu erkennen. Bearer-Token [TEST][SENS] curl -H "Authorization: Bearer TOKEN_NICHT_HIER_EINTRAGEN" https://api.example.com/status Negotiate/Kerberos, sofern Build und Umgebung es unterstützen [TEST][SENS] curl --negotiate -u : https://example.com/protected Zugangsdaten, Tokens und Cookies dürfen nicht in BookStack-Seiten, Tickets oder allgemein lesbaren Skripten gespeichert werden. 23. Wie werden Cookies untersucht? Cookie-Befehle anzeigen Cookie direkt senden [TEST][SENS] curl -b "session=BEISPIELWERT" https://example.com/ Cookies aus Datei lesen [TEST][FILE][SENS] curl -b cookies.txt https://example.com/ Empfangene Cookies speichern [TEST][FILE][SENS] curl -c cookies.txt https://example.com/login Cookies lesen und aktualisiert wieder speichern [TEST][FILE][SENS] curl -b cookies.txt -c cookies.txt https://example.com/ Option Bedeutung -b beziehungsweise --cookie Cookies senden oder aus Datei lesen -c beziehungsweise --cookie-jar Empfangene Cookies speichern Cookie-Dateien können aktive Sitzungen ermöglichen und sind daher sensible Zugangsdaten. Typische Cookie-Probleme falsche Domain; falscher Pfad; Secure -Cookie über HTTP; abgelaufenes Cookie; SameSite-Verhalten; Weiterleitung zu anderem Host; mehrere Cookies mit gleichem Namen; Anwendung erwartet zusätzliche CSRF-Token. curl bildet nicht jedes Browser-Sicherheitsverhalten vollständig identisch ab. Ein mit curl funktionierender Cookie-Test beweist daher nicht automatisch, dass eine Browseranwendung fehlerfrei arbeitet. 24. Wie wird ein HTTP-Proxy getestet? Proxy-Diagnose anzeigen HTTP-Proxy verwenden [TEST][SENS] curl -x http://proxy.example.com:8080 https://example.com/ Langform: [TEST][SENS] curl --proxy http://proxy.example.com:8080 https://example.com/ Proxy-Benutzername interaktiv verwenden [TEST][SENS] curl -x http://proxy.example.com:8080 -U "max.mustermann" https://example.com/ Proxy umgehen [TEST][SENS] curl --noproxy example.com https://example.com/ Proxy für alle Ziele umgehen [TEST][SENS] curl --noproxy "*" https://example.com/ Umgebungsvariablen prüfen Linux und macOS: [RO][SENS] env | grep -i proxy PowerShell: [RO][SENS] Get-ChildItem Env: | Where-Object Name -Match 'proxy' Häufig verwendete Variablen: http_proxy https_proxy all_proxy NO_PROXY no_proxy Wichtiger Sicherheitshinweis Die Variable http_proxy wird von curl aus Sicherheitsgründen nur in Kleinschreibung akzeptiert. Andere Proxyvariablen können je nach Protokoll und Umgebung unterschiedliche Groß-/Kleinschreibungen unterstützen. Direkt- und Proxytest vergleichen Direkt: [TEST][SENS] curl --noproxy "*" -v https://example.com/ Über Proxy: [TEST][SENS] curl -x http://proxy.example.com:8080 -v https://example.com/ 25. Wie wird ein SOCKS-Proxy getestet? SOCKS4- und SOCKS5-Optionen anzeigen SOCKS5-Proxy, DNS-Auflösung durch den Proxy [TEST][SENS] curl --socks5-hostname 192.0.2.50:1080 https://example.com/ SOCKS5-Proxy, lokale DNS-Auflösung [TEST][SENS] curl --socks5 192.0.2.50:1080 https://example.com/ SOCKS4a [TEST][SENS] curl --socks4a 192.0.2.50:1080 https://example.com/ Wichtiger Unterschied Option DNS-Auflösung --socks5 Lokal durch curl --socks5-hostname Durch den SOCKS5-Proxy --socks4 Lokal --socks4a Durch den Proxy Der Unterschied ist wichtig, wenn: interne DNS-Namen nur am Proxy auflösbar sind; DNS-Leaks vermieden werden sollen; lokale und entfernte DNS-Ergebnisse voneinander abweichen. 26. Wie werden komprimierte Antworten geprüft? Kompression anzeigen [TEST][SENS] curl --compressed -v https://example.com/ Mit --compressed fordert curl eine unterstützte komprimierte Antwort an und dekomprimiert sie anschließend. In der Anfrage kann beispielsweise erscheinen: Accept-Encoding: deflate, gzip, br, zstd Die tatsächlich angebotenen Verfahren hängen vom curl-Build ab. Header prüfen [TEST][SENS] curl --compressed -I https://example.com/ Mögliche Antwort: Content-Encoding: gzip Typische Probleme Proxy entfernt Accept-Encoding ; Server sendet falschen Content-Length ; Inhalt wird doppelt komprimiert; Reverse Proxy und Anwendung komprimieren gleichzeitig; bestimmte Kompressionsverfahren werden vom curl-Build nicht unterstützt. 27. Wie werden lokale Unix-Sockets getestet? Unix-Domain-Socket-Diagnose anzeigen Auf Linux und anderen Unix-Systemen können HTTP-Dienste über einen Unix-Domain-Socket erreichbar sein. [TEST][SENS] curl --unix-socket /run/example/app.sock http://localhost/health curl verbindet sich dabei mit dem lokalen Socket. Der Hostname in der URL wird weiterhin für die HTTP-Anfrage verwendet. Typische Einsatzbereiche Docker Engine API; lokale Reverse-Proxy-Backends; PHP-FPM-nahe Testdienste; lokale Verwaltungs-APIs; systemd-aktivierte Dienste. Beispiel Docker-Socket [TEST][PRIV][SENS] curl --unix-socket /var/run/docker.sock http://localhost/_ping Zugriff auf /var/run/docker.sock entspricht auf vielen Systemen weitreichenden administrativen Rechten. Dieser Zugriff darf nicht leichtfertig vergeben oder in Container durchgereicht werden. 28. Wie werden Wiederholungsversuche verwendet? Retry-Optionen anzeigen Bis zu drei Wiederholungsversuche [TEST][SENS] curl --retry 3 https://example.com/ Maximale Gesamtzeit für Wiederholungen [TEST][SENS] curl --retry 3 --retry-max-time 30 https://example.com/ Feste Verzögerung zwischen Versuchen [TEST][SENS] curl --retry 3 --retry-delay 2 https://example.com/ Auch abgelehnte TCP-Verbindungen erneut versuchen [TEST][SENS] curl --retry 3 --retry-connrefused https://example.com/ Alle Fehler wiederholen [TEST][CHANGE][DISRUPT][SENS] curl --retry 3 --retry-all-errors https://example.com/ --retry-all-errors darf bei ändernden Anfragen nicht unüberlegt verwendet werden. Ein POST, PUT oder DELETE könnte auf dem Server bereits verarbeitet worden sein, obwohl curl die Antwort nicht erhalten hat. Dadurch könnte eine Wiederholung: eine Ressource doppelt anlegen; eine Buchung doppelt ausführen; eine Nachricht mehrfach senden; einen Löschvorgang wiederholen. Wiederholungsversuche sind bei idempotenten GET- oder HEAD-Anfragen meist leichter zu bewerten als bei ändernden API-Aufrufen. 29. Welche curl-Exitcodes sind für die Diagnose wichtig? Exitcode-Tabelle anzeigen Exitcode Bedeutung 0 Vorgang aus Sicht von curl erfolgreich 3 URL fehlerhaft 5 Proxyname konnte nicht aufgelöst werden 6 Hostname konnte nicht aufgelöst werden 7 Verbindung zum Ziel konnte nicht hergestellt werden 22 HTTP-Fehler bei Verwendung von --fail oder --fail-with-body 23 Fehler beim Schreiben empfangener Daten 26 Fehler beim Lesen lokaler Daten 28 Zeitüberschreitung 35 TLS-/SSL-Verbindungsfehler 47 Zu viele Weiterleitungen 52 Leere Serverantwort 55 Fehler beim Senden von Netzwerkdaten 56 Fehler beim Empfangen von Netzwerkdaten 60 Zertifikat konnte nicht verifiziert werden 77 Problem beim Lesen der CA-Zertifikatsdatei 92 HTTP/2-Protokollfehler Die vollständige Liste hängt von der curl-Version ab: [RO] curl --manual Exitcode unter Linux und macOS anzeigen curl -sS --fail-with-body https://example.com/health echo $? Exitcode unter PowerShell anzeigen curl.exe -sS --fail-with-body https://example.com/health $LASTEXITCODE Wichtige Unterscheidung HTTP-Statuscode ≠ curl-Exitcode Beispiel: HTTP 404 ohne --fail → curl-Exitcode kann 0 sein HTTP 404 mit --fail → curl-Exitcode 22 30. Wie werden Fehler nach Diagnoseebene eingeordnet? Fehlerkette anzeigen curl-Beobachtung Wahrscheinliche Ebene Exitcode 6 DNS-Auflösung Exitcode 7 TCP-Verbindung, Routing, Firewall oder Listener Exitcode 28 DNS, Verbindung, Server oder Übertragung zu langsam Exitcode 35 TLS-Handshake Exitcode 60 Zertifikatsvertrauen oder Hostname HTTP 301/302 Weiterleitung HTTP 401 Authentifizierung HTTP 403 Autorisierung, WAF oder Richtlinie HTTP 404 URL, Routing oder Ressource HTTP 429 Rate Limit HTTP 500 Anwendung oder Backend HTTP 502 Proxy/Gateway und Upstream HTTP 503 Dienst nicht verfügbar oder Wartungszustand HTTP 504 Gateway wartet vergeblich auf Upstream Verbindung funktioniert, Antwort langsam Anwendung, Datenbank, Upstream oder Serverlast IP funktioniert, Name nicht DNS --resolve funktioniert, normaler Aufruf nicht DNS-Zuordnung oder Load-Balancer-Ziel -k funktioniert, normaler Test nicht Zertifikatsprüfung IPv4 funktioniert, IPv6 nicht IPv6-DNS, Routing, Firewall oder MTU Direkt funktioniert, Proxy nicht Proxy, Authentifizierung oder Proxy-Richtlinie 31. Welche typischen Fehlinterpretationen gibt es? Praxisfallen anzeigen Fehlinterpretation Richtige Einordnung curl ohne Fehler bedeutet HTTP 200 Ohne --fail kann auch HTTP 404 oder 500 Exitcode 0 ergeben -I prüft exakt dasselbe wie GET -I sendet bei HTTP eine HEAD-Anfrage -k behebt TLS Es deaktiviert nur die Zertifikatsprüfung Aufruf über IP testet denselben virtuellen Host Host-Header, SNI und Zertifikatsprüfung können abweichen Eigener Host -Header setzt automatisch SNI TLS-SNI wird dadurch nicht zuverlässig angepasst --resolve verändert lokales DNS dauerhaft Gilt nur für den jeweiligen curl-Aufruf time_connect ist nur die TCP-Dauer Wert ist kumulativ seit Beginn des Aufrufs Hohe TTFB beweist Netzwerkproblem Server, Anwendung oder Backend können langsam sein HTTP 403 bedeutet falsches Passwort Authentifizierung kann korrekt sein, aber Zugriff ist verboten HTTP 502 ist immer der Webserver Häufig meldet ein Gateway ein Upstream-Problem Bearer-Token in der Kommandozeile ist sicher Token kann in Historie und Prozessinformationen erscheinen Verbose-Ausgabe kann bedenkenlos geteilt werden Header, Cookies und Tokens können enthalten sein curl verhält sich wie ein Browser JavaScript und Browserkontext fehlen Retry ist bei POST immer sicher Änderung kann bereits verarbeitet worden sein Proxyvariable ist ausgeschlossen, weil -x fehlt curl kann Proxyvariablen aus der Umgebung verwenden 32. Wie sieht ein systematischer curl-Diagnoseablauf aus? Empfohlene Schrittfolge anzeigen Vorbereitung Erwartete URL, Methode und Antwort dokumentieren. Hostname, IP-Adresse, Port und Protokoll bestimmen. Prüfen, ob Proxy, VPN oder Load Balancer beteiligt sind. Authentifizierung und Schutzbedarf der Daten klären. Ändernde Anfragen nur gegen freigegebene Testressourcen richten. Grundtest curl-Version und unterstützte Funktionen prüfen. URL mit explizitem https:// oder http:// verwenden. Verbindung mit -v untersuchen. HTTP-Statuscode und effektive URL ausgeben. Exitcode kontrollieren. Eingrenzung IPv4 mit -4 und IPv6 mit -6 vergleichen. DNS mit --resolve kontrolliert umgehen. Direktverbindung und Proxyverbindung vergleichen. Redirect-Kette mit -L -I prüfen. TLS normal und höchstens vergleichsweise mit -k testen. HTTP/1.1 und HTTP/2 bei Bedarf vergleichen. DNS-, TCP-, TLS-, TTFB- und Gesamtzeit messen. Anwendung Header und Content-Type prüfen. Erwartete HTTP-Methode verwenden. Request-Body und Zeichenkodierung kontrollieren. Authentifizierung ohne Offenlegung der Zugangsdaten testen. API-Antwort und Serverlogs zeitlich vergleichen. Validierung Ergebnis aus einem zweiten Netzwerksegment vergleichen. Reverse-Proxy-, Firewall- und Anwendungslogs prüfen. Bei Netzwerkverdacht Paketmitschnitt erstellen. Nach einer Änderung denselben curl-Befehl erneut ausführen. Befehl, Zeitpunkt, Exitcode, HTTP-Status und Zeiten dokumentieren. Diagnoseausgaben vor Weitergabe von Secrets bereinigen. 33. Kurzreferenz – häufige curl-Befehle Befehlstabelle anzeigen Aufgabe Linux/macOS Version [RO] curl --version Seite abrufen [TEST][SENS] curl https://example.com/ Nur HEAD-Anfrage [TEST][SENS] curl -I https://example.com/ Header und Inhalt [TEST][SENS] curl -i https://example.com/ Ausführliche Diagnose [TEST][SENS] curl -v https://example.com/ Redirects verfolgen [TEST][SENS] curl -L https://example.com/ Statuscode [TEST] curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/ HTTP-Fehler als Fehler behandeln [TEST] curl -sS --fail-with-body https://example.com/ Connect-Timeout [TEST] curl --connect-timeout 5 https://example.com/ Gesamttimeout [TEST] curl --max-time 15 https://example.com/ IPv4 [TEST] curl -4 https://example.com/ IPv6 [TEST] curl -6 https://example.com/ DNS temporär überschreiben [TEST][SENS] curl --resolve example.com:443:192.0.2.20 https://example.com/ Bestimmte CA-Datei [TEST][FILE][SENS] curl --cacert company-ca.pem https://example.com/ HTTP/1.1 [TEST] curl --http1.1 https://example.com/ HTTP/2 [TEST] curl --http2 https://example.com/ JSON senden [TEST][CHANGE][SENS] curl -H "Content-Type: application/json" -d '{"active":true}' https://api.example.com/item Datei herunterladen [TEST][FILE][SENS] curl -o file.bin https://example.com/file.bin Proxy verwenden [TEST][SENS] curl -x http://proxy.example.com:8080 https://example.com/ Proxy umgehen [TEST][SENS] curl --noproxy "*" https://example.com/ Trace erstellen [TEST][FILE][SENS] curl --trace-time --trace-ascii curl-trace.txt https://example.com/ Windows verwendet dieselbe Optionssyntax, aber eindeutig curl.exe und NUL statt /dev/null : [TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Zeit=%{time_total}s\n" https://example.com/ 34. Kurzreferenz – wichtigste Optionen Optionstabelle anzeigen Option Bedeutung -V , --version Version und Build-Funktionen anzeigen -v , --verbose Ausführliche Verbindungsinformationen -I , --head Bei HTTP HEAD-Anfrage senden -i , --show-headers Antwortheader zusammen mit Inhalt anzeigen -D , --dump-header Antwortheader separat schreiben -o , --output Antwortinhalt in Datei schreiben -O , --remote-name Remote-Dateinamen verwenden -s , --silent Fortschritts- und normale Fehlermeldungen unterdrücken -S , --show-error Fehler trotz --silent anzeigen -f , --fail HTTP-Fehler als curl-Fehler behandeln --fail-with-body HTTP-Fehler melden und Inhalt behalten -L , --location Weiterleitungen verfolgen --max-redirs Anzahl der Weiterleitungen begrenzen -w , --write-out Messwerte und Metadaten ausgeben --connect-timeout Verbindungszeit begrenzen -m , --max-time Gesamtdauer begrenzen -4 IPv4 erzwingen -6 IPv6 erzwingen --resolve Temporäre Host-/Port-/IP-Zuordnung --connect-to Tatsächliches Verbindungsziel ändern -k , --insecure Zertifikatsprüfung deaktivieren --cacert Bestimmte CA-Datei verwenden --cert Clientzertifikat verwenden --key Privaten Schlüssel verwenden --tlsv1.2 Mindestens TLS 1.2 --tls-max Maximale TLS-Version --http1.1 HTTP/1.1 verwenden --http2 HTTP/2 anfordern --http3 HTTP/3 versuchen -H , --header Request-Header setzen -A , --user-agent User-Agent setzen -d , --data Request-Daten senden --data-binary Daten weitgehend unverändert senden --data-urlencode Daten URL-codieren --json JSON-Daten senden -X , --request HTTP-Methode ausdrücklich festlegen -u , --user Serverauthentifizierung -U , --proxy-user Proxyauthentifizierung -b , --cookie Cookies senden beziehungsweise lesen -c , --cookie-jar Cookies speichern -x , --proxy Proxy verwenden --noproxy Proxy für Ziele umgehen --compressed Komprimierte Antwort anfordern --retry Wiederholungsversuche --trace-ascii Lesbaren Trace schreiben --trace-time Trace mit Zeitstempeln versehen Merksätze Unter Windows für echte curl-Syntax ausdrücklich curl.exe verwenden. Eine empfangene HTTP-Fehlerseite kann ohne --fail trotzdem curl-Exitcode 0 ergeben. HTTP-Statuscode und curl-Exitcode beantworten unterschiedliche Fragen. -I sendet bei HTTP eine HEAD-Anfrage und ist nicht identisch mit einem GET-Test. -v zeigt DNS, TCP, TLS und HTTP, kann aber sensible Header enthalten. --resolve umgeht DNS für den Test und erhält Hostname, HTTP-Host, TLS-SNI und Zertifikatsprüfung. Ein Aufruf über die reine IP-Adresse kann einen anderen virtuellen Host erreichen. -k deaktiviert die Zertifikatsprüfung und behebt kein TLS-Problem. time_connect , time_appconnect und time_starttransfer sind kumulative Zeitwerte. Eine hohe TTFB kann durch Anwendung, Datenbank, Proxy oder Backend entstehen. Bei UDP-basiertem HTTP/3 können andere Fehler als bei HTTP/1.1 oder HTTP/2 auftreten. Proxyvariablen können einen curl-Aufruf beeinflussen, auch wenn kein -x angegeben wurde. Zugangsdaten, Cookies und Tokens gehören nicht in Dokumentationen oder gemeinsam lesbare Skripte. POST-, PUT-, PATCH- und DELETE-Anfragen können Daten verändern und benötigen besondere Vorsicht. curl ist ein präzises Protokollwerkzeug, aber kein vollständiger Webbrowser. Quellen Offizielle curl-Manpage Offizielle curl-Dokumentationsübersicht Everything curl – Command Line Transfers Everything curl – Verbose Operations Everything curl – Name Resolve Tricks Everything curl – HTTP Responses Everything curl – Proxies curl – Exit Codes curl – SSL Certificate Verification curl – Supported Protocols