Ho passato un numero assurdo di notti fino a tardi a debuggare script che, in teoria, dovevano solo “prendere un file e andare avanti”. Nove volte su dieci, il problema era cURL che faceva esattamente ciò che gli avevo chiesto, non ciò che volevo davvero. Insomma, c’è un bel divario tra “curl -O funziona” e “curl -O funziona in modo affidabile in produzione”.
È proprio questo il vuoto che colma questa guida. cURL è già installato su macOS, sulla maggior parte delle distribuzioni Linux e su Windows 10 e versioni successive, quindi con ogni probabilità lo hai già sul tuo computer. Ma tra redirect silenziosi che falliscono, misteriosi 403 e il salto da “scarica un file” a “scarica 500 file senza mandare in crisi il terminale”, le occasioni per bloccarsi non mancano. Ti guiderò attraverso i flag che contano davvero, i comandi passo passo che uso sul serio, gli errori in cui inciampano più spesso le persone e il punto in cui cURL non basta più — e cosa usare al suo posto.
Cos’è cURL (e perché dovrebbe interessarti)?
cURL è uno strumento da riga di comando gratuito e open source per trasferire dati da o verso un server tramite un URL. Parla HTTP, HTTPS, FTP, SFTP e una lunga lista di altri protocolli, ed è per questo che lo trovi ovunque: dagli script bash ai Dockerfile fino alle pipeline CI. Sotto il cofano, il comando curl che digiti nel terminale usa libcurl, la libreria C per il trasferimento dati che molte applicazioni e binding di linguaggio integrano. L’estensione cURL di PHP è un esempio; la popolare libreria Requests di Python è invece un client HTTP separato basato su urllib3, non su libcurl.
La release stabile attuale, al momento in cui scrivo, è curl 8.21.0, rilasciata nel giugno 2026 — ma non dare per scontato che il tuo sistema operativo includa proprio quella build. Le versioni distribuite dai repository delle distro spesso restano indietro rispetto al progetto upstream di mesi, a volte anche di più, quindi vale la pena eseguire curl --version prima di assumere che un flag come --parallel sia disponibile.
Perché scaricare file con cURL? I casi d’uso principali
Mi chiedono spesso perché qualcuno dovrebbe usare uno strumento da terminale quando i browser scaricano file senza problemi. La risposta onesta: i browser vanno benissimo finché non devi automatizzare qualcosa.
| Caso d’uso | Perché cURL dà il meglio |
|---|---|
| Scaricare binari nelle pipeline CI/CD | Automatizzabile, senza interfaccia grafica |
| Recuperare risposte API o esportazioni di dati | Supporta header personalizzati, autenticazione e piping dell’output |
| Riprendere download di file grandi via SSH | Supporto integrato alla ripresa (-C -) |
| Automatizzare download ricorrenti (cron job) | Leggero, facile da combinare con script shell |
| Scaricare file protetti da autenticazione | Flag di auth flessibili (basic, token, cookie, .netrc) |
Un download nel browser è un clic manuale e isolato. cURL trasforma la stessa azione in qualcosa che puoi pianificare, concatenare in una pipeline, ritentare in caso di errore ed eseguire in modo identico su cento server insieme. È questo il suo vero punto di forza: non è più sofisticato, è semplicemente ripetibile.
I flag essenziali di cURL per scaricare file
Torno sempre allo stesso paio di dozzine di flag per il 90% di quello che faccio. Ecco il foglio riepilogativo che avrei voluto qualcuno mi consegnasse anni fa, organizzato in base a ciò che fanno davvero.
Flag per l’output e il salvataggio dei file
-O(--remote-name) salva il file usando l’ultima parte dell’URL come nome. Comodo, ma può sovrascrivere in silenzio un file esistente con lo stesso nome.-o <filename>(--output) ti permette di scegliere esattamente il nome locale:curl -o report.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) usa il nome file indicato nell’headerContent-Dispositiondel server invece di quello nell’URL. È utile per i download da API, ma tratta i nomi forniti dal server come input non fidato — scarica in una cartella dedicata invece che nella tua home, come raccomanda la documentazione di sicurezza di curl.
Flag di comportamento che servono in ogni download
-L(--location) dice a curl di seguire i redirect HTTP. Senza, una risposta 3xx viene salvata come una piccola pagina HTML di redirect invece del file vero — è l’errore più comune che vedo quando qualcuno dice “perché il download è rotto?”.-C -(--continue-at -) riprende un download interrotto da dove si era fermato.-s/-Seseguono in modo silenzioso ma mostrano comunque gli errori — ottimo per gli script, dove non vuoi riempire i log con la barra di avanzamento.--limit-rate 1Mlimita la banda (utile su connessioni condivise o quando non vuoi saturare una rete a consumo).--connect-timeout 10e--max-time 300evitano che una connessione bloccata congeli lo script all’infinito.--retry 3e--retry-delay 5ritentano automaticamente in caso di errori temporanei — secondo la pagina man di curl, combina--retry-all-errorssolo quando ripetere esattamente la stessa richiesta è davvero sicuro.
Flag per progresso e debug
-#mostra una barra di progresso semplice invece della tabella statistica predefinita.-vstampa output dettagliato, inclusi tutti gli header di richiesta/risposta — il mio strumento di riferimento quando qualcosa non si comporta come dovrebbe.-I(--head) recupera solo gli header della risposta, un ottimo controllo preliminare prima di lanciarsi su un download pesante.-wti permette di stampare output personalizzato dopo il trasferimento, ad esempiocurl -o /dev/null -s -w "%{http_code}\n" <url>per verificare solo il codice di stato.
Prima di iniziare
- Difficoltà: da principiante a intermedio (le sezioni su batch e autenticazione diventano un po’ più avanzate)
- Tempo richiesto: circa 15-20 minuti per seguire i comandi principali
- Cosa ti serve: un terminale (Terminale di macOS, shell Linux o Windows PowerShell/WSL), curl installato (verifica con
curl --version) e un URL di prova — userò un asset pubblico di una release GitHub come esempio, perché è stabile e liberamente accessibile
Come scaricare file con cURL: guida passo passo
Passo 1: scaricare un singolo file
Le basi assolute: curl -O <url> salva il file con il nome originale, mentre curl -o myfile.zip <url> ti permette di rinominarlo al volo.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
Adesso aggiungo -L sempre, senza eccezioni — troppe volte un redirect ha trasformato in silenzio il mio “download” in un file HTML da 400 byte. Dovresti vedere un indicatore di avanzamento nel terminale, fino a quando il file compare nella directory corrente.
Quando il comando riesce, l’indicatore arriva al 100% e curl-8.21.0.tar.gz appare nella cartella corrente. Verifica il file prima di usarlo:
ls -lh curl-8.21.0.tar.gz
Passo 2: scaricare e rinominare il file
Usa -o quando vuoi un nome locale preciso invece di quello che termina nell’URL:
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
Qui -S riattiva la visualizzazione degli errori nel caso tu abbia anche usato -s altrove nello script. Questa combinazione — -L -o <nome> -S — è praticamente il mio comando predefinito per il download di un singolo file.
Passo 3: riprendere un download interrotto
Se un download grande si interrompe a metà (wifi instabile, VPN che fa i capricci, qualunque cosa), non ricominciare da zero. Esegui:
curl -C - -LO https://example.com/large-file.iso
Il punto critico: funziona solo se il server supporta le richieste a intervalli di byte. Accept-Ranges: bytes è un segnale positivo utile, ma la sua assenza non dimostra che gli intervalli non siano supportati. Il controllo affidabile è la risposta del server a una vera richiesta con range: una risposta riprendibile restituisce in genere 206 Partial Content con un Content-Range valido. Esegui il comando di ripresa e controlla lo stato con -v o -D -; se il server ignora il range o rifiuta l’offset, ricomincia di proposito invece di dare per scontato che il file parziale sia sicuro.
Passo 4: scaricare con barra di avanzamento o in silenzio
Per una visualizzazione più pulita in un terminale interattivo: curl -# -LO <url>. Per script e cron job, quando vuoi solo gli errori e non il rumore: curl -sS -LO <url>. Io uso quasi sempre la versione silenziosa, tranne quando sto debuggando a mano.
Passo 5: limitare la velocità di download
Su una connessione d’ufficio condivisa (o quando non voglio essere “quella persona” che occupa tutta la banda durante una videochiamata), limito la velocità con:
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
Le unità sono K, M e G per kilobyte, megabyte e gigabyte al secondo rispettivamente.
Passo 6: salvare gli header della risposta insieme al file
A volte ho bisogno di sapere esattamente cosa ha risposto il server — content type, header di cache e simili — senza sporcare il terminale:
curl -L -D headers.txt -o file.zip https://example.com/file.zip
Questo salva gli header della risposta in headers.txt, mentre il file vero finisce in file.zip. Ottimo per debuggare incongruenze nel content type o verificare che una CDN stia davvero facendo cache di ciò che credi.
Consigli e problemi comuni
- Consiglio: usa sempre
-Lcome impostazione predefinita. Non vedo davvero svantaggi nel includerlo e ho perso ore per dimenticarmelo. - Consiglio: negli script, abbina
--failal comando di download così una risposta non-2xx fa uscire lo script con errore, invece di salvare in silenzio una pagina di errore come se fosse il file giusto. - Problema: non combinare
-C -con--remove-on-error— curl li documenta come incompatibili, perché la ripresa ha bisogno che il file parziale resti lì. - Problema:
-Opuò sovrascrivere i file senza avvisi. Se stai scaricando in batch dentro una directory condivisa, usa--output-dirper tenere tutto sotto controllo.
Come scaricare più file e fare download batch con cURL
Gli esempi con un solo file sono la parte facile. I flussi di lavoro reali che ho costruito — recupero di esportazioni dati notturne, sincronizzazione di binari tra server di build — richiedevano concorrenza, ed è qui che molti tutorial… si fermano. Ci sono tre approcci da conoscere, ciascuno un passo più complesso del precedente.
Approccio 1: più URL in un solo comando cURL
L’opzione più semplice è elencare gli URL:
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
Funziona, ma in modo sequenziale: curl completa un file prima di iniziare il successivo. Bene per tre file, doloroso per trecento.
Approccio 2: download paralleli con --parallel (curl 7.66+)
Da curl 7.66 in poi, puoi aggiungere --parallel (o -Z) per scaricare più URL contemporaneamente:
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
Da sapere: il massimo parallelo predefinito è in realtà 50, cioè molte più connessioni concorrenti di quante la maggior parte dei server — o la tua rete — apprezzerà. Io imposto --parallel-max in modo esplicito e prudente — di solito tra 4 e 8 — invece di fidarmi del default.
Approccio 3: xargs e loop Bash per la concorrenza da una lista di URL
Per una lunga lista di URL in un file di testo, di solito uso xargs:
cat urls.txt | xargs -n1 -P 8 curl -O -L
Oppure, se voglio più controllo su ogni job, uso un loop Bash con processi in background:
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
Il wait alla fine è importante — senza di quello, lo script termina prima che i download in background siano finiti.
Quando usare wget o aria2 al posto di cURL
Lo dico chiaramente: cURL non è sempre lo strumento giusto. Se devi rispecchiare l’intera struttura di directory di un sito web, wget -r gestisce il crawling ricorsivo nativamente in un modo per cui cURL semplicemente non è stato progettato. Se ti servono download segmentati e multi-sorgente per ottenere il massimo throughput su un file enorme, aria2c è davvero più veloce.
| Strumento | Ideale per |
|---|---|
| cURL | Precisione, scripting, download di singoli file o piccoli batch, interazione con API |
| wget | Download ricorsivi o mirror di siti, recupero più semplice di file statici in massa |
| aria2 | Download multi-sorgente/segmentati, massimizzare il throughput su file grandi |
La forza di cURL è sempre stata la precisione e la componibilità — piping, scripting, flessibilità dei protocolli — non il crawling bruto.
Come scaricare file protetti con cURL: pattern di autenticazione
Molte guide su cURL si fermano a -u user:pass e chiudono lì. È un residuo di un internet più vecchio. Nel 2026, i file che scarico davvero arrivano da API REST, dashboard basate su sessione e sistemi CI — e ciascuno vuole un tipo di credenziale diverso.
Basic Auth
curl -u username:password -O https://legacy-server.example.com/file.zip
Va bene per vecchi server FTP o endpoint HTTP semplici. Tieni però presente che la password compare nella cronologia della shell e nella lista dei processi, a meno che tu non faccia attenzione — non è qualcosa che userei per dati sensibili.
Autenticazione con Bearer / OAuth Token
Questo è il caso che, in molti tutorial, è sorprendentemente sottorappresentato, ed è quello che uso più spesso oggi:
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
È un pattern reale per scaricare un asset privato di una release GitHub — basta sostituire il token e l’ID dell’asset. Le API REST e le risorse protette da OAuth2 parlano praticamente tutte questo linguaggio ormai.
Autenticazione basata su cookie e sessione
Per le web app in cui il login crea una sessione, salva il cookie jar al login e riutilizzalo al momento del download:
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
File .netrc per ambienti scriptati e CI
È il mio metodo preferito per tutto ciò che deve girare in modo non supervisionato. Crea un file ~/.netrc (o _netrc su Windows):
machine example.com
login myusername
password mypassword
Proteggilo con chmod 600 ~/.netrc, poi richiamalo con:
curl --netrc -LO https://example.com/protected-file.zip
Il vantaggio è che le credenziali non passano mai nella cronologia della shell né nel codice dello script — davvero importante in CI/CD, dove gli script vengono spesso registrati per intero.
| Metodo di auth | Flag/Opzione | Ideale per |
|---|---|---|
| Basic auth | -u user:pass | FTP legacy, HTTP semplice |
| Token Bearer | -H "Authorization: Bearer <token>" | API REST, OAuth2 |
| Cookie auth | -b cookies.txt (+ -c per salvare) | App web basate su sessione |
File .netrc | --netrc o --netrc-file | CI/CD, ambienti scriptati |
Risoluzione dei problemi più comuni nei download con cURL
Questa è la sezione che avrei voluto esistesse quando ho iniziato, perché quasi nessuno la copre. “Perché il mio download con curl non funziona” è una ricerca reale, frequente e frustrante — e le soluzioni, di solito, sono una riga sola, una volta capito il motivo.
| Sintomo | Causa probabile | Soluzione |
|---|---|---|
curl: (60) SSL certificate problem | Certificato autofirmato o scaduto | --cacert <file> oppure -k (solo sviluppo) |
403 Forbidden / file vuoto | Il server blocca lo user-agent predefinito di curl | -A "Mozilla/5.0..." oppure -H "User-Agent: ..." |
Il download riparte da 0 con -C - | Il server non supporta Range | Controlla con curl -I <url> la presenza di Accept-Ranges: bytes |
| Salvato un file da 0 byte | Redirect non seguito | Aggiungi il flag -L |
curl: (28) Operation timed out | Server lento o problemi di rete | --connect-timeout 10 --max-time 300 + --retry 3 |
| Salvata una pagina HTML invece del file | La pagina richiede rendering JavaScript | curl non esegue JS — vedi la sezione qui sotto |
Errori di certificato SSL: cosa significano e come risolverli
L’errore 60 significa che curl non è riuscito a verificare il certificato SSL del server — di solito perché è autofirmato, scaduto o emesso da una CA di cui curl non si fida. Se controlli tu il server, indica a curl il bundle CA corretto con --cacert /path/to/ca.pem. Il flag -k (--insecure) salta del tutto la verifica: va bene in un ambiente di sviluppo locale, ma è una pessima idea per qualsiasi cosa tocchi produzione o dati di utenti reali.
403 Forbidden e download vuoti
Un numero sorprendente di server blocca richieste che si identificano come curl/8.21.0 (la stringa User-Agent predefinita di curl), perché le considerano bot o scraper. La soluzione di solito è fingere di essere un browser:
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
Per controllare cosa sta tornando davvero prima di impegnarti in un download completo, uso: curl -o /dev/null -s -w "%{http_code}\n" <url>.
Timeout, retry e connessioni instabili
Questo è il comando che mi tatuerei sul braccio, se avessi il coraggio dei tatuaggi.
Il mio comando di download preferito, quello che uso davvero negli script di produzione, combina tutte le opzioni per l’affidabilità:
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
Segue i redirect, riprende i download, ritenta cinque volte con un ritardo di 3 secondi, impone un timeout di 10 secondi sulla connessione, un limite complessivo di 10 minuti e fallisce in modo netto su uno stato HTTP non valido — praticamente tutto ciò che ho imparato, a mie spese, a dover includere.
cURL nell’automazione reale: pipeline CI/CD, piping e sicurezza degli script
Inviare l’output di cURL ad altri strumenti
curl non deve per forza salvare nulla su disco — inviare direttamente l’output a un altro comando è una delle sue funzionalità più sottovalutate:
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
Scaricare ed estrarre, oppure scaricare e analizzare, in una sola riga. È un pattern che uso continuamente per recuperi di dati una tantum.
Usare cURL in GitHub Actions e CI/CD
Uno step minimo di GitHub Actions che scarica un binario con logica di retry e fallisce apertamente in caso di errore:
- name: Scarica binario
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
Conserva eventuali token come segreti della CI e richiamali tramite variabili d’ambiente — mai hardcodarli nello script. E usa --fail (o --fail-with-body se ti serve vedere il body dell’errore per il debug) così un download rotto rompe davvero la build invece di passare silenziosamente con dati corrotti.
La questione di sicurezza di curl | sh
Questa emerge quasi in ogni forum di sviluppo che abbia mai letto, e per una buona ragione: inviare curl direttamente a sh significa eseguire codice remoto che non hai esaminato, basandoti interamente sulla fiducia che il server non sia stato compromesso e la connessione non sia stata alterata. Questo è il rischio reale — non paranoia, ma una semplice preoccupazione di supply chain.
Il pattern più sicuro è scaricare prima, ispezionare lo script, verificare un checksum o una firma GPG se viene fornita, e solo allora eseguirlo:
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # leggilo davvero
sha256sum install.sh # confronta con il checksum pubblicato, se disponibile
bash install.sh
Installer molto noti come rustup e Homebrew continuano a usare il pattern curl | sh, e in quei casi è generalmente accettato perché i maintainer e il canale di distribuzione sono consolidati. Io, comunque, preferisco passare quei dieci secondi in più a controllare uno script piuttosto che scoprire troppo tardi di non dovermi fidare.
Quando cURL non basta: pagine renderizzate in JavaScript, siti anti-bot e dati strutturati
Ecco una modalità di fallimento che mette in difficoltà molte persone, e raramente è colpa loro: lanci curl -O su quella che sembra una pagina normale e, invece del contenuto che ti aspettavi, ottieni una shell HTML vuota, oppure una pagina di challenge di Cloudflare, o qualcosa che sembra spazzatura. curl ha fatto esattamente ciò per cui è stato creato — recuperare la risposta HTTP grezza — ma non può eseguire JavaScript, risolvere un CAPTCHA o superare un sistema anti-bot basato sul fingerprinting. Non sono bug di curl; sono semplicemente fuori dal suo perimetro.
Perché cURL fallisce sulle pagine web moderne
Le moderne single-page app spesso restituiscono uno scheletro HTML quasi vuoto, con il contenuto vero reso lato client da JavaScript dopo il caricamento della pagina — qualcosa che curl non esegue mai. In più, sistemi come Cloudflare e Akamai servono attivamente pagine di challenge a tutto ciò che non assomiglia a un browser reale, e richieste curl ripetute dallo stesso IP possono essere rapidamente limitate o classificate come traffico bot.
Il passo successivo: API di scraping AI per sviluppatori
Direi che curl è lo strumento giusto per circa l’80% dei download di file e dati in circolazione — asset statici, risposte API, qualunque cosa sia servita come semplice risorsa HTTP. È per quell’altro 20%, pagine pesanti di JavaScript o protette da bot, che ho visto sviluppatori passare ore a lottare con header e user-agent prima di arrendersi e passare a un livello diverso.
È proprio il divario che il mio team ha costruito Thunderbit per colmare, insieme all’estensione Chrome per cui la maggior parte delle persone ci conosce. Dal lato sviluppatore, la Open API di Thunderbit ti offre POST /distill, che restituisce Markdown pulito e pronto per LLM da un URL — con il rendering della pagina gestito dal servizio — e POST /extract, che restituisce JSON strutturato corrispondente allo schema quando ti servono dati realmente campi e non testo leggibile. C’è anche un server MCP, così gli agenti in Claude o Cursor possono chiamare thunderbit_distill e thunderbit_extract durante il task, oltre a una CLI (npx @thunderbit/thunderbit-cli distill <url>) che nel terminale si comporta molto come curl. Puoi instradare l’output JSON verso jq, per esempio thunderbit distill <url> --format json | jq -r '.data.markdown'; oppure inviare l’output --format markdown a uno strumento testuale o a un file.
Mettendo i due strumenti a confronto, la differenza è netta. Una richiesta curl verso una pagina prodotto renderizzata in JS potrebbe restituire un <div id="root"></div> quasi vuoto. Il corrispondente comando thunderbit distill restituisce il contenuto della pagina renderizzato in Markdown pulito. Distill costa 1 credito per URL e Extract 20 crediti per URL. I limiti specifici degli endpoint attuali sono diversi: Batch Distill supporta fino a 100 URL per job, mentre Batch Extract accetta fino a 50 URL con uno schema condiviso. Controlla la documentazione API aggiornata prima di dimensionare una coda di produzione.
Se sei più nuovo al concetto in generale, la nostra guida su che cos’è davvero il web scraping è un buon punto di partenza, e la guida allo scraping no-code copre il lato non tecnico dello stesso problema per chi nel tuo team non vuole mettere mano al terminale. Per un confronto più ampio degli strumenti in questo spazio, abbiamo anche preparato una panoramica dei migliori AI web scraper da conoscere.
Riferimento rapido: cheat sheet per i download con cURL
| Attività | Comando |
|---|---|
| Download base | curl -LO <url> |
| Nome file personalizzato | curl -L -o myfile.zip <url> |
| Riprendere un download | curl -C - -LO <url> |
| Silenzioso con errori mostrati | curl -sSL -O <url> |
| Download paralleli | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Autenticazione con token Bearer | curl -H "Authorization: Bearer <token>" -LO <url> |
| Comando scriptato consigliato | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| Inviare a uno strumento di estrazione | curl -sL <url> | tar xz |
Conclusione e punti chiave
Scaricare un file con curl parte in modo semplice — curl -O e hai quasi finito — ma la vera competenza sta negli strati sotto: sapere quando aggiungere -L, quando riprendere invece di ricominciare, quale pattern di autenticazione si adatta davvero al tuo flusso di lavoro e cosa fare nel momento in cui compare un 403 o una shell HTML vuota al posto del file atteso. Mi sono appoggiato a tutti questi pattern, a un certo punto, di solito subito dopo aver imparato nel modo più difficile perché fossero importanti.
curl resta, senza dubbio, il mio strumento predefinito per i download semplici di file e per il lavoro HTTP scriptabile: è veloce, ovunque e si combina benissimo con il resto di una pipeline shell. Ma quando incontri una pagina renderizzata in JavaScript o un muro anti-bot, il problema non si risolve con altri flag di curl; è il segnale che ti serve un livello diverso, ed è proprio lì che un’API come quella di Thunderbit prende il controllo senza costringerti a uscire dal terminale.
Salva il cheat sheet nei preferiti, prova il comando di retry e resume sul tuo prossimo download instabile e, se arrivi a quel punto in cui curl restituisce solo spazzatura, sai già qual è il passo successivo — la pagina prezzi di Thunderbit mostra la ripartizione attuale dei crediti se vuoi capire quanto costa davvero fare il salto, e il nostro canale YouTube offre walkthrough se preferisci guardare invece di leggere.
FAQ sul download di file con cURL
Come faccio a scaricare un file con cURL e salvarlo con un nome specifico?
Usa -o seguito dal nome file desiderato: curl -L -o nomefile.ext <url>. Aggiungi -L così i redirect non mandano all’aria il download.
Come faccio a riprendere un download cURL fallito?
Esegui curl -C - -LO <url>. Funziona solo se il server supporta le richieste range — verifica prima con curl -I <url> e cerca Accept-Ranges: bytes nella risposta.
cURL può scaricare file che richiedono il login?
Sì, in quattro modi principali: basic auth (-u user:pass), token bearer (-H "Authorization: Bearer <token>"), sessioni basate su cookie (-b cookies.txt) o un file .netrc per ambienti scriptati. Vedi la sezione sull’autenticazione qui sopra per il dettaglio completo e per capire quando usare ciascuno.
Qual è la differenza tra cURL e wget per scaricare file?
cURL supporta più protocolli ed è in genere migliore per scripting, piping e download precisi di singoli file o piccoli batch. wget è progettato per il crawling ricorsivo e per rispecchiare intere directory di un sito, quindi è la scelta migliore per recuperare in massa file statici.
Perché cURL scarica una pagina HTML invece del file vero?
Di solito ci sono due colpevoli: hai dimenticato il flag -L e il server ti ha reindirizzato altrove, oppure la pagina richiede JavaScript per mostrare il contenuto reale — cosa che curl semplicemente non può eseguire. Nel secondo caso, ti serve uno strumento capace di rendering, non altri flag di curl.
