curl-felkoder: Komplett referens

Snabbreferenstabell

Fel 6: Kunde inte slå upp värdnamnet

Vad det betyder

Din terminal visar curl: (6) Could not resolve host. curl kunde inte slå upp värdnamnet till en IP-adress — DNS-uppslagningen misslyckades innan någon anslutning försöktes.

Orsaker

De vanligaste orsakerna är: ett stavfel i värdnamnet (t.ex. curl https://apiexample.com istället för api.example.com), DNS-serverproblem (din konfigurerade DNS är nere eller oåtkomlig), ingen nätverksanslutning (Wi-Fi frånkopplat, VPN inte ansluten), eller domänen existerar verkligen inte.

Så åtgärdar du

Verifiera först att URL:en är korrekt. Testa sedan DNS-upplösning direkt: nslookup api.example.com eller dig api.example.com. Om DNS misslyckas, prova en annan DNS-server: curl --dns-servers 8.8.8.8 https://api.example.com. Kontrollera din /etc/resolv.conf eller nätverksinställningar. Om du sitter bakom ett företags-VPN, se till att den interna DNS:en kan slå upp värden.

$ curl https://api.exmple.com/users

Fel 7: Anslutning misslyckades

Vad det betyder

Din terminal visar curl: (7) Failed to connect to host port: Connection refused. curl slog upp värdnamnet men kunde inte upprätta en TCP-anslutning till servern — anslutningen nekades aktivt eller tidsgräns överskreds på TCP-nivå.

Orsaker

Vanliga orsaker inkluderar: servern är nere eller körs inte, en brandvägg blockerar porten (kontrollera både lokala och serverbaserade brandväggar), porten är fel (t.ex. tjänsten kör på 8080 men du ansluter till 443), eller serverns listen-backlog är full under hög belastning.

Så åtgärdar du

Verifiera att servern körs: ping api.example.com och telnet api.example.com 443. Kontrollera om rätt port är öppen: nmap -p 443 api.example.com. Inaktivera lokal brandvägg tillfälligt för att testa. Om du använder Docker, se till att containerns port är publicerad. Prova med verbose-läge: curl -v https://api.example.com för att se exakt var anslutningen misslyckas.

$ curl https://localhost:8080/api

Fel 22: HTTP returnerade fel

Vad det betyder

Din terminal visar curl: (22) The requested URL returned error. Servern returnerade en HTTP-felstatuskod (4xx eller 5xx) och curl anropades med -f eller --fail, vilket instruerar curl att behandla HTTP-fel som misslyckanden.

Orsaker

Felet utlöses av HTTP-statuskoder som 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found) eller 500 (Internal Server Error) — men bara när --fail används. Utan --fail avslutar curl med kod 0 även vid HTTP-fel. Vanliga orsaker: fel URL, saknad autentisering, otillräckliga behörigheter eller serversidans buggar.

Så åtgärdar du

Kör curl utan --fail för att se hela svarskroppen — den innehåller ofta det faktiska felmeddelandet. Kontrollera HTTP-statuskoden: curl -w "%{http_code}" -o /dev/null -s URL. För 401/403: verifiera din auth-token eller API-nyckel. För 404: dubbelkolla URL-sökvägen. För 500: problemet är på serversidan.

$ curl --fail https://api.example.com/nonexistent

Fel 28: Tidsgräns överskreds

Vad det betyder

Din terminal visar curl: (28) Operation timed out eller curl: (28) Connection timed out. Operationen tog längre tid än den tillåtna tiden. Detta är det vanligaste curl-felet — det kan uppstå under DNS-upplösning, TCP-anslutning, SSL-handskakning eller dataöverföring.

Orsaker

Typiska orsaker inkluderar: långsam eller överbelastad server som inte svarar i tid, nätverksträngsel eller paketförlust, brandvägg som tyst släpper paket (inget avvisande, bara tystnad), för strikta timeout-värden satta med --connect-timeout eller --max-time, eller en proxykonfigurationsfel som orsakar fördröjningar.

Så åtgärdar du

Öka tidsgränsen: curl --connect-timeout 30 --max-time 120 URL. Använd verbose-läge för att se var det hänger: curl -v URL. Testa nätverksfördröjning: ping api.example.com och traceroute api.example.com. Om du sitter bakom en proxy, prova att kringgå den: curl --noproxy '*' URL. För stora filöverföringar, överväg att använda --retry 3 med --retry-delay 5.

$ curl --connect-timeout 5 https://slow-api.example.com/data

Fel 35: SSL-anslutningsfel

Vad det betyder

Din terminal visar curl: (35) SSL connect error. SSL/TLS-handskakningen misslyckades — curl kunde inte upprätta en säker anslutning med servern.

Orsaker

Vanliga orsaker: TLS-versionsinkompatibilitet (servern kräver TLS 1.3 men din curl stödjer bara upp till TLS 1.2), chiffer-svitinkompatibilitet, felaktig SSL-konfiguration på servern (utgånget certifikat presenteras under handskakning, ofullständig kedja), servern stödjer faktiskt inte HTTPS på den givna porten, eller en proxy eller brandvägg fångar upp SSL-anslutningen (MITM).

Så åtgärdar du

Tvinga en specifik TLS-version: curl --tlsv1.2 URL eller curl --tlsv1.3 URL. Kontrollera vad servern stödjer: openssl s_client -connect api.example.com:443. Uppdatera curl och OpenSSL till de senaste versionerna. Om servern använder ett självsignerat certifikat är det vanligtvis fel 60 istället — fel 35 indikerar vanligtvis ett protokollnivåfel vid handskakning.

$ curl https://legacy-server.example.com/api

Fel 56: Mottagningsfel — anslutningen återställdes

Vad det betyder

Din terminal visar curl: (56) Recv failure: Connection reset by peer. Anslutningen upprättades framgångsrikt, men datamottagningen misslyckades — servern stängde eller återställde anslutningen oväntat under överföringen.

Orsaker

Detta händer ofta när: servern kraschar eller startar om mitt i överföringen, en lastbalanserare eller proxy avbryter anslutningen (idle-timeout, för stor förfrågan), en brandvägg avslutar långvariga anslutningar, servern har en keep-alive-timeout som är kortare än förväntat, eller det finns ett nätverksavbrott mellan klient och server.

Så åtgärdar du

Prova förfrågan igen — tillfälliga nätverksproblem är den vanligaste orsaken. Använd verbose-läge: curl -v URL för att se exakt var felet uppstår. Om felet inträffar under stora uppladdningar, prova chunked-överföring: curl -H "Transfer-Encoding: chunked" URL. För Git-operationer som visar RPC failed; curl 56, öka bufferten: git config http.postBuffer 524288000.

$ curl https://api.example.com/large-download

Fel 60: SSL-certifikatproblem

Vad det betyder

Din terminal visar curl: (60) SSL certificate problem: unable to get local issuer certificate. curl kunde inte verifiera serverns SSL-certifikat mot dess CA-paket (Certificate Authority). TLS-handskakningen slutfördes på protokollnivå, men certifikatvalideringen misslyckades.

Orsaker

De vanligaste orsakerna: servern använder ett självsignerat certifikat, certifikatet har gått ut, certifikatkedjan är ofullständig (saknade mellanliggande certifikat), curls CA-paket är föråldrat (vanligt på äldre system eller i Docker-containrar), eller certifikatets Common Name / SAN matchar inte det begärda värdnamnet.

Så åtgärdar du

Uppdatera CA-paketet: curl --cacert /path/to/cacert.pem URL. Ladda ner ett uppdaterat paket från https://curl.se/ca/cacert.pem. För att diagnostisera: openssl s_client -connect api.example.com:443 -showcerts. För självsignerade certifikat i utvecklingsmiljö, använd curl -k URL (använd aldrig i produktion — det inaktiverar all certifikatverifiering). I Docker, installera paketet ca-certificates.

$ curl https://self-signed.example.com/api

Övriga felkoder

Hur man felsöker curl-fel

När curl misslyckas hjälper dessa tre flaggor dig att snabbt identifiera grundorsaken — från DNS-upplösning till SSL-handskakning till svarsinnehåll.

1. 1

   Aktivera verbose-utdata

   Kör curl -v URL för att se hela förfrågnings-/svarscykeln: DNS-upplösning, TCP-anslutning, TLS-handskakning, skickade förfrågningsheaders och mottagna svarsheaders. Detta är den enskilt mest användbara felsökningsflaggan.

2. 2

   Kontrollera HTTP-statuskoden

   Kör curl -o /dev/null -s -w "%{http_code}" URL för att bara få HTTP-statuskoden (200, 404, 500, etc.) utan svarskroppen. Användbart för snabba hälsokontroller och skript.

3. 3

   Visa fel tyst

   Kör curl -sS URL för att dölja förloppsindikatorn (-s) men fortfarande visa fel (-S). Perfekt för skript där du vill ha ren utdata men behöver fånga upp misslyckanden.

Vanliga frågor