Jag har ägnat orimligt många sena nätter åt att felsöka skript som egentligen bara skulle “hämta en fil och gå vidare”. I nio fall av tio var boven cURL — inte för att verktyget var trasigt, utan för att det gjorde precis det jag hade bett om, inte det jag faktiskt menade. Det visade sig vara en stor skillnad mellan att “curl -O fungerar” och att “curl -O fungerar stabilt i produktion.”
Det är precis den skillnaden den här guiden handlar om. cURL är förinstallerat på macOS, de flesta Linux-distributioner och Windows 10 eller senare, så chansen är stor att du redan har det på din dator. Men mellan tysta omdirigeringsfel, mystiska 403:or och steget från att ladda ner en fil till att ladda ner 500 filer utan att terminalen kollapsar, finns det gott om fallgropar. Här går jag igenom de viktigaste flaggorna, de kommandon jag faktiskt använder, de vanligaste felen och till slut när cURL helt enkelt inte räcker längre — och vad du bör använda istället.
Vad är cURL, och varför ska du bry dig?
cURL är ett gratis kommandoradsverktyg med öppen källkod för att överföra data till eller från en server via en URL. Det pratar HTTP, HTTPS, FTP, SFTP och en lång rad andra protokoll, vilket är anledningen till att det dyker upp överallt — från bash-skript och Dockerfiles till CI-pipelines. Under huven använder kommandot curl i din terminal libcurl, C-biblioteket för överföringar som många program och språkbindningar bygger in. PHP:s cURL-extension är ett exempel; Pythons populära Requests-bibliotek är däremot en separat HTTP-klient byggd på urllib3, inte libcurl.
Den senaste stabila versionen när detta skrivs är curl 8.21.0, släppt i juni 2026 — men utgå inte från att ditt operativsystem levererar exakt den versionen. Paketversioner av curl släpar ofta efter uppströmsprojektet med månader, ibland längre, så det är klokt att köra curl --version innan du antar att en flagga som --parallel finns tillgänglig.
Varför ladda ner filer med cURL? Vanliga användningsområden
Jag får ofta frågan varför någon ens skulle bry sig om ett kommandoradsverktyg när webbläsare kan ladda ner filer helt okej. Det korta svaret: webbläsare är toppen tills du vill automatisera något.
| Användningsfall | Varför cURL är starkt |
|---|---|
| Ladda ner binärfiler i CI/CD-pipelines | Kan skriptas, inget GUI behövs |
| Hämta API-svar eller dataexporter | Stöd för egna headers, autentisering och utmatning via pipe |
| Återuppta stora nedladdningar över SSH | Inbyggt stöd för återupptagning (-C -) |
| Automatisera återkommande nedladdningar (cron-jobb) | Lättviktigt, går att kombinera med shell-skript |
| Hämta filer bakom autentisering | Flexibla auth-flaggor (basic, token, cookies, .netrc) |
En nedladdning i webbläsaren är en engångshändelse där du klickar manuellt. cURL gör samma sak till något du kan schemalägga, kedja in i en pipeline, försöka igen vid fel och köra identiskt på hundra servrar samtidigt. Det är hela poängen — inte att det är mer avancerat, utan att det går att upprepa.
De viktigaste cURL-flaggorna för filnedladdning
Jag kommer tillbaka till samma dussin flaggor för runt 90 % av det jag gör. Här är fusklappen jag önskar att någon hade gett mig för flera år sedan, uppdelad efter vad de faktiskt gör.
Flaggor för utdata och filsparande
-O(--remote-name) sparar filen med den sista delen av URL:en som filnamn. Smidigt, men den kan skriva över en befintlig fil med samma namn utan varning.-o <filnamn>(--output) låter dig själv välja exakt filnamn:curl -o report.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) använder filnamnet från servernsContent-Disposition-header i stället för URL:en. Praktiskt för API-nedladdningar, men behandla serverns filnamn som opålitlig input — ladda ner till en särskild mapp i stället för hemkatalogen, enligt curl:s egen säkerhetsrådgivning.
Beteendeflaggor som varje nedladdning behöver
-L(--location) säger åt curl att följa HTTP-omdirigeringar. Utan den sparas ett 3xx-svar som en liten HTML-sida för omdirigering i stället för den riktiga filen — det här är det vanligaste “varför är min nedladdning trasig?”-felet jag ser.-C -(--continue-at -) återupptar en avbruten nedladdning där den slutade.-s/-Skör tyst men visar ändå fel — bra för skript där du inte vill ha en progressbar som skräpar ner loggarna.--limit-rate 1Mstryper bandbredden (bra på delade uppkopplingar eller när du inte vill sluka ett mätbart nätverk).--connect-timeout 10och--max-time 300hindrar en hängande anslutning från att låsa ditt skript för alltid.--retry 3och--retry-delay 5försöker automatiskt igen vid tillfälliga fel — enligt curl-manualen bör du bara kombinera detta med--retry-all-errorsnär det verkligen är säkert att skicka exakt samma begäran igen.
Flaggor för progress och felsökning
-#ger dig en enkel progressbar i stället för den vanliga statistiktabellen.-vvisar utförlig output, inklusive hela request-/response-headrarna — min favorit när något beter sig konstigt.-I(--head) hämtar bara responsens headers, vilket är ett bra förtest innan du satsar på en stor nedladdning.-wlåter dig skriva ut anpassad information efter överföringen, till exempelcurl -o /dev/null -s -w "%{http_code}\n" <url>om du bara vill kontrollera en statuskod.
Innan du börjar
- Svårighetsgrad: Nybörjare till medel (avsnitten om batch och autentisering blir lite mer avancerade)
- Tidsåtgång: Cirka 15–20 minuter för att gå igenom de viktigaste kommandona
- Det här behöver du: En terminal (macOS Terminal, Linux-shell eller Windows PowerShell/WSL), curl installerat (kontrollera med
curl --version) och en test-URL — jag använder en publik GitHub-releasefil som exempel eftersom den är stabil och fritt tillgänglig
Så laddar du ner filer med cURL: steg för steg
Steg 1: Ladda ner en enstaka fil
Det enklaste: curl -O <url> sparar filen under sitt originalnamn, medan curl -o myfile.zip <url> låter dig döpa om den direkt när den laddas ner.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
Jag lägger numera alltid till -L, utan undantag — jag har blivit bränd för många gånger av att en omdirigering i tysthet förvandlar min “nedladdning” till en 400 bytes HTML-fil. Du bör se en progressindikator i terminalen och sedan att filen hamnar i din nuvarande katalog.
När kommandot lyckas når progressen 100 % och curl-8.21.0.tar.gz dyker upp i den aktuella katalogen. Kontrollera filen innan du använder den:
ls -lh curl-8.21.0.tar.gz
Steg 2: Ladda ner och byt namn på filen
Använd -o när du vill ha ett specifikt lokalt filnamn i stället för vad URL:en råkar sluta på:
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 här slår på felvisning igen ifall du också har använt -s någon annanstans i ett skript. Kombinationen — -L -o <namn> -S — är i princip mitt standardkommando för enstaka filnedladdningar.
Steg 3: Återuppta en avbruten nedladdning
Om en stor nedladdning bryts halvvägs (dåligt wifi, VPN-strul, vad som helst), börja inte om från noll. Kör:
curl -C - -LO https://example.com/large-file.iso
Haken: detta fungerar bara om servern stöder byte-range-förfrågningar. Accept-Ranges: bytes är en bra positiv signal, men avsaknaden av den bevisar inte att stöd saknas. Det pålitliga testet är serverns svar på en faktisk range-förfrågan: ett återupptagbart svar ger normalt 206 Partial Content med en giltig Content-Range. Kör återupptagningskommandot och kontrollera status med -v eller -D -; om servern ignorerar rangeringen eller avvisar offseten, börja om medvetet i stället för att anta att den delvisa filen är säker.
Steg 4: Ladda ner med progressbar (eller helt tyst)
För en renare vy i en interaktiv terminal: curl -# -LO <url>. För skript och cron-jobb där du bara vill ha fel, inte brus: curl -sS -LO <url>. Jag använder nästan alltid den tysta varianten, utom när jag felsöker manuellt.
Steg 5: Begränsa nedladdningshastigheten
På ett delat kontorsnät (eller när jag inte vill vara den där personen som äter upp all bandbredd under ett videosamtal) stryper jag med:
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
Enheterna är K, M och G för kilobyte, megabyte och gigabyte per sekund.
Steg 6: Spara responsheaders tillsammans med filen
Ibland behöver jag veta exakt vad servern skickade tillbaka — content type, cache-headers och liknande — utan att skräpa ner terminalen:
curl -L -D headers.txt -o file.zip https://example.com/file.zip
Det här lägger responsheaders i headers.txt medan själva filen sparas som file.zip. Perfekt för att felsöka mismatch mellan content-type eller kontrollera att en CDN faktiskt cachar det du tror att den cachar.
Tips och vanliga fallgropar
- Tips: Utgå alltid från
-L. Jag kan ärligt talat inte komma på någon nackdel med att ha med den, och jag har förlorat timmar på att glömma den. - Tips: När du skriver skript, kombinera
--failmed nedladdningen så att ett svar utanför 2xx faktiskt gör att skriptet avslutas med fel, i stället för att tyst spara en felsida som om det vore din fil. - Fallgrop: Kombinera inte
-C -med--remove-on-error— curl dokumenterar dessa som inkompatibla, eftersom återupptagning kräver att den delvisa filen fortfarande finns kvar. - Fallgrop:
-Okan skriva över filer utan varning. Om du batch-laddar ner till en delad katalog, använd--output-dirför att hålla saker avgränsade.
Så laddar du ner flera filer och batchar nedladdningar med cURL
Exemplen med enstaka filer är den enkla delen. De verkliga flöden jag byggt — nattliga dataexporter, synk av binärer mellan build-servrar — krävde samtidighet, och det är här de flesta guider bara... slutar. Det finns tre metoder som är värda att känna till, var och en ett steg upp i komplexitet.
Metod 1: Flera URL:er i ett enda cURL-kommando
Det enklaste alternativet är bara att lista URL:erna:
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
Det här fungerar, men är sekventiellt — curl laddar klart en fil helt innan nästa börjar. Okej för tre filer, smärtsamt för trehundra.
Metod 2: Parallella nedladdningar med --parallel (curl 7.66+)
Sedan curl 7.66 kan du lägga till --parallel (eller -Z) för att hämta flera URL:er samtidigt:
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
Värt att känna till: standardvärdet för parallel max är faktiskt 50, vilket är betydligt fler samtidiga anslutningar än de flesta servrar (eller ditt eget nät) kommer att uppskatta. Jag anger alltid --parallel-max själv och håller det försiktigt — oftast 4 till 8 — i stället för att lita på standarden.
Metod 3: xargs och Bash-loopar för samtidighet från en URL-lista
För en stor lista URL:er i en textfil tar jag oftast till xargs:
cat urls.txt | xargs -n1 -P 8 curl -O -L
Eller, om jag vill ha mer kontroll över vad som händer med varje jobb, en Bash-loop med bakgrundsprocesser:
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
wait längst ner är viktigt — utan det avslutas skriptet innan bakgrundsnedladdningarna är klara.
När du ska välja wget eller aria2 i stället
Jag ska vara rak: cURL är inte alltid rätt verktyg. Om du vill spegla en hel webbplatskatalog gör wget -r rekursiv genomsökning direkt på ett sätt som cURL helt enkelt inte är byggt för. Om du behöver nedladdningar från flera källor och segmentering för maximal hastighet på en enda stor fil, är aria2c genuint snabbare.
| Verktyg | Bäst för |
|---|---|
| cURL | Precision, skript, nedladdning av enstaka filer eller små batcher, API-anrop |
| wget | Rekursiv spegling av webbplatser, enklare masshämtning av statiska filer |
| aria2 | Flerkälls-/segmenterade nedladdningar, maximal throughput för stora filer |
cURL:s styrka har alltid varit precision och komponerbarhet — pipe:ar, skript, protokollflexibilitet — inte råstyrka för att crawla allt i sin väg.
Så laddar du ner skyddade filer med cURL: autentiseringsmönster
De flesta cURL-guider slutar vid -u user:pass och nöjer sig där. Det är ett arv från ett äldre internet. År 2026 kommer filerna jag faktiskt laddar ner från REST-API:er, sessionbaserade dashboards och CI-system — och var och en kräver olika sorters autentisering.
Basic Auth
curl -u username:password -O https://legacy-server.example.com/file.zip
Fungerar fint för gamla FTP-servrar eller enkla HTTP-endpoints. Tänk bara på att lösenordet syns i shell-historiken och processlistan om du inte är försiktig — inget jag skulle använda för något känsligt.
Bearer-/OAuth-tokenautentisering
Det här är den som faktiskt är underrepresenterad i de flesta guider, och den jag använder oftast numera:
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
Det är ett verkligt mönster för att hämta en privat GitHub-releasefil — byt ut token och asset-ID mot dina egna. REST-API:er och OAuth2-skyddade resurser pratar i princip alla det här språket nu.
Cookiebaserad sessionautentisering
För webbappar där inloggning skapar en session kan du spara cookie-filen vid inloggning och återanvända den vid nedladdningen:
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-fil för skript och CI-miljöer
Min föredragna metod för allt som körs utan tillsyn. Skapa en ~/.netrc-fil (eller _netrc i Windows):
machine example.com
login myusername
password mypassword
Lås ner den med chmod 600 ~/.netrc, och använd sedan:
curl --netrc -LO https://example.com/protected-file.zip
Fördelen är att uppgifterna aldrig hamnar i shell-historiken eller i skriptkoden — riktigt viktigt i CI/CD där skript ofta loggas i sin helhet.
| Autentiseringsmetod | Flagga/alternativ | Bäst för |
|---|---|---|
| Basic auth | -u user:pass | Äldre FTP, enkel HTTP |
| Bearer-token | -H "Authorization: Bearer <token>" | REST-API:er, OAuth2 |
| Cookie-auth | -b cookies.txt (+ -c för att spara) | Sessionbaserade webbappar |
.netrc-fil | --netrc eller --netrc-file | CI/CD, skriptmiljöer |
Felsök vanliga cURL-nedladdningsfel
Det här är avsnittet jag önskar fanns när jag började, eftersom nästan ingen går igenom det ordentligt. “Varför fungerar inte min curl-nedladdning” är en verklig, vanlig och frustrerande sökning — och lösningarna är oftast bara en rad när du väl vet orsaken.
| Symptom | Trolig orsak | Lösning |
|---|---|---|
curl: (60) SSL certificate problem | Självsignerat eller utgånget certifikat | --cacert <fil> eller -k (endast för dev) |
403 Forbidden / tom fil | Servern blockerar curl:s standard-User-Agent | -A "Mozilla/5.0..." eller -H "User-Agent: ..." |
Nedladdningen startar om från 0 med -C - | Servern stöder inte Range | Kontrollera med curl -I <url> efter Accept-Ranges: bytes |
| 0-byte-fil sparas | Omdirigering följdes inte | Lägg till -L |
curl: (28) Operation timed out | Långsam server eller nätverksproblem | --connect-timeout 10 --max-time 300 + --retry 3 |
| HTML-sida sparas i stället för fil | Sidan kräver JavaScript-rendering | curl kan inte köra JS — se avsnittet nedan |
SSL-certifikatfel: vad de betyder och hur du fixar dem
Fel 60 betyder att curl inte kunde verifiera serverns SSL-certifikat — oftast för att det är självsignerat, har gått ut eller utfärdats av en CA som curl inte litar på. Om du kontrollerar servern själv, peka curl mot rätt CA-bundle med --cacert /path/to/ca.pem. Flaggan -k (--insecure) hoppar över verifiering helt, vilket är okej i en lokal utvecklingsmiljö och en riktigt dålig idé för allt som rör produktion eller verkliga användardata.
403 Forbidden och tomma nedladdningar
Förvånansvärt många servrar blockerar förfrågningar som identifierar sig som curl/8.21.0 (curl:s standard-User-Agent), eftersom de antar att det är bottar eller scrapers. Lösningen är oftast att låtsas vara en webbläsare:
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
För att se vad som faktiskt kommer tillbaka innan jag kör en full nedladdning använder jag: curl -o /dev/null -s -w "%{http_code}\n" <url>.
Timeouts, retries och ostabila anslutningar
Det här är kommandot jag skulle tatuera på armen om jag vore modigare med tatueringar.
Mitt favoritkommando för nedladdningar, det jag faktiskt använder i produktionsskript, bygger ihop alla tillförlitlighetsflaggor:
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
Det är alltså omdirigering, återupptagning, fem nya försök med 3 sekunders väntan, 10 sekunders anslutningstimeout, 10 minuters totalgräns och ett hårt fel vid dålig HTTP-status — i princip allt jag lärt mig den hårda vägen att lägga till.
cURL i verklig automation: CI/CD-pipelines, pipes och säkerhet i skript
Skicka cURL-utdata vidare till andra verktyg
cURL behöver inte spara något alls på disk — att pipe:a direkt till ett annat kommando är en av dess mest underskattade funktioner:
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
Ladda ner och packa upp, eller ladda ner och analysera, på en enda rad. Det här är ett mönster jag använder hela tiden för engångshämtningar av data.
Använda cURL i GitHub Actions och CI/CD
Ett minimalt GitHub Actions-steg som laddar ner en binärfil med retry-logik och tydliga fel:
- name: Ladda ner binärfil
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
Lagra eventuella tokens som CI-secrets och referera till dem via miljövariabler — hårdkoda dem aldrig i själva skriptet. Och använd --fail (eller --fail-with-body om du behöver se felmeddelandet för felsökning) så att en trasig nedladdning faktiskt stoppar bygget i stället för att tyst gå vidare med skräp.
Säkerhetsfrågan kring curl | sh
Det här dyker upp i nästan varje utvecklarforum jag läst, och med goda skäl: att pipe:a curl direkt till sh betyder att du kör fjärrkod du inte har granskat, helt baserat på förtroendet att servern inte har komprometterats och att anslutningen inte har manipulerats. Det är den faktiska risken — inte paranoia, utan ett rakt supply-chain-problem.
Det säkrare arbetssättet är att först ladda ner, sedan granska skriptet, verifiera checksumma eller GPG-signatur om sådan finns, och först därefter köra det:
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # läs faktiskt igenom det
sha256sum install.sh # jämför med publicerad checksumma om den finns
bash install.sh
Kända installatörer som rustup och Homebrew använder fortfarande mönstret curl | sh, och det anses i regel okej just där eftersom underhållarna och distributionskanalen är väl etablerade. Jag skulle ändå hellre lägga de extra tio sekunderna på att inspektera ett skript än upptäcka i efterhand att jag inte borde ha litat på det.
När cURL inte räcker: JS-renderade sidor, anti-bot-sajter och strukturerad data
Här är ett felbeteende som ställer till det för många, och det är sällan deras fel: du kör curl -O mot något som ser ut som en vanlig sida, och i stället för innehållet du väntade dig får du ett tomt HTML-skal, en Cloudflare-utmaningssida eller något som mest ser ut som skräp. curl gjorde exakt det det är byggt för — hämtade det råa HTTP-svaret — men det kan inte köra JavaScript, lösa CAPTCHA eller ta sig förbi anti-bot-system som använder fingerprinting. Det är inte buggar i curl; det ligger helt enkelt utanför verktygets uppdrag.
Varför cURL misslyckas på moderna webbsidor
Moderna single-page-appar returnerar ofta ett nästan tomt HTML-skelett, där det riktiga innehållet renderas på klientsidan av JavaScript efter att sidan laddats — något curl aldrig kör. Dessutom skickar system som Cloudflare och Akamai aktivt ut utmaningssidor till allt som inte ser ut som en riktig webbläsare, och upprepade curl-begäranden från samma IP kan snabbt börja rate-limited eller fingerprintas som bottrafik.
Nästa steg: AI-scraping-API:er för utvecklare
Jag skulle säga att curl är rätt verktyg för ungefär 80 % av alla fil- och datahämtningar där ute — statiska tillgångar, API-svar, allt som serveras som en vanlig HTTP-resurs. Det är de andra 20 %, alltså JavaScript-tunga eller bot-skyddade sidor, där jag sett utvecklare lägga timmar på att kämpa med headers och User-Agent-strängar innan de till slut ger upp och väljer ett annat lager helt.
Det är faktiskt just det gapet mitt team byggde Thunderbit för att täppa till, tillsammans med Chrome-tillägget som de flesta känner oss för. På utvecklarsidan ger Thunderbits Open API dig POST /distill, som returnerar ren, LLM-anpassad Markdown från en URL — med sidrendering hanterad av tjänsten — och POST /extract, som returnerar schema-matchad strukturerad JSON när du behöver verkliga fältdata i stället för läsbar text. Det finns också en MCP-server så agenter i Claude eller Cursor kan anropa thunderbit_distill och thunderbit_extract mitt i ett arbetsflöde, samt en CLI (npx @thunderbit/thunderbit-cli distill <url>) som beter sig ganska mycket som curl i terminalen. Pipe:a JSON-utdata till jq, till exempel thunderbit distill <url> --format json | jq -r '.data.markdown'; skicka --format markdown-utdata till ett textverktyg eller en fil i stället.
Jämfört sida vid sida blir skillnaden tydlig. En curl-begäran mot en JS-renderad produktsida kan ge tillbaka ett i princip tomt <div id="root"></div>. Motsvarande thunderbit distill-kommando returnerar renderat sidinnehåll som ren Markdown. Distill kostar 1 kredit per URL och Extract 20 krediter per URL. De nuvarande gränserna per endpoint skiljer sig också: Batch Distill stöder upp till 100 URL:er per jobb, medan Batch Extract tar upp till 50 URL:er med ett gemensamt schema. Kontrollera alltid aktuell API-dokumentation innan du dimensionerar en produktionskö.
Om du är nyare till begreppet i stort är vår egen förklaring av vad web scraping faktiskt innebär en bra start, och guiden om scraping utan kod täcker den icke-tekniska sidan av samma problem för alla i teamet som inte vill öppna en terminal. För en bredare jämförelse av verktyg inom området har vi också satt ihop en genomgång av de bästa AI-webbscraparna som är värda att känna till.
Snabbreferens: fusklapp för cURL-nedladdningar
| Uppgift | Kommando |
|---|---|
| Enkel nedladdning | curl -LO <url> |
| Eget filnamn | curl -L -o myfile.zip <url> |
| Återuppta nedladdning | curl -C - -LO <url> |
| Tyst med fel visade | curl -sSL -O <url> |
| Parallella nedladdningar | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Bearer-token-autentisering | curl -H "Authorization: Bearer <token>" -LO <url> |
| Mitt-i-prick-skriptad nedladdning | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| Pipe:a till extraktionsverktyg | curl -sL <url> | tar xz |
Slutsats och viktigaste lärdomar
Att ladda ner en fil med curl börjar enkelt — curl -O och du är nästan klar — men den verkliga skickligheten ligger i lagren under: att veta när du ska lägga till -L, när du ska återuppta i stället för att börja om, vilket autentiseringsmönster som faktiskt passar ditt arbetsflöde och vad du gör när en 403 eller ett tomt HTML-skal dyker upp i stället för filen du väntade dig. Jag har använt varje enskilt mönster här någon gång, oftast precis efter att jag lärt mig på det hårda sättet varför det spelade roll.
curl förblir, utan tvekan, mitt förstaval för raka filnedladdningar och skriptbar HTTP-hantering — det är snabbt, finns överallt och passar utmärkt i resten av en shell-pipeline. Men när du stöter på en sida som renderas med JavaScript eller ett anti-bot-lås är det inte ett problem som löses med fler flaggor; det är ett tecken på att du behöver ett annat lager, och där tar ett API som Thunderbit vid utan att tvinga dig ut ur terminalen.
Bokmärk fusklappen, testa kommandot för retry och återupptagning på din nästa ostabila nedladdning, och om du når den väggen där curl bara returnerar skräp vet du vad nästa steg är — Thunderbits prissida visar aktuell kreditfördelning om du vill se vad ett sådant steg faktiskt kostar, och vår YouTube-kanal har genomgångar om du hellre tittar än läser.
Vanliga frågor om att ladda ner filer med cURL
Hur laddar jag ner en fil med cURL och sparar den med ett specifikt namn?
Använd -o följt av önskat filnamn: curl -L -o yourname.ext <url>. Lägg till -L så att omdirigeringar inte saboterar nedladdningen.
Hur återupptar jag en misslyckad cURL-nedladdning?
Kör curl -C - -LO <url>. Det fungerar bara om servern stöder range-förfrågningar — kontrollera först med curl -I <url> och leta efter Accept-Ranges: bytes i svaret.
Kan cURL ladda ner filer som kräver inloggning?
Ja, på fyra huvudsakliga sätt: basic auth (-u user:pass), bearer-tokens (-H "Authorization: Bearer <token>"), cookiebaserade sessioner (-b cookies.txt) eller en .netrc-fil för skriptmiljöer. Se autentiseringsavsnittet ovan för hela genomgången och när varje metod passar.
Vad är skillnaden mellan cURL och wget för filnedladdningar?
cURL stöder fler protokoll och är generellt bättre för skript, pipes och precisa nedladdningar av enstaka filer eller små batcher. wget är byggt för rekursiv crawling och spegling av hela webbplatskataloger, vilket gör det till ett bättre val för masshämtning av statiska sajter.
Varför laddar cURL ner en HTML-sida i stället för den faktiska filen?
Två vanliga orsaker: du glömde -L och servern omdirigerade dig någon annanstans, eller så kräver sidan JavaScript för att rendera sitt faktiska innehåll — något curl helt enkelt inte kan köra. I det senare fallet behöver du ett verktyg som kan rendera sidan, inte fler curl-flaggor.
