Passei uma quantidade absurda de madrugadas depurando scripts que, na teoria, eram só para “pegar um arquivo e seguir em frente”. Em nove de cada dez vezes, o problema era o cURL fazendo exatamente o que eu pedi — e não o que eu realmente queria. A verdade é que existe uma diferença enorme entre “curl -O funciona” e “curl -O funciona de forma confiável em produção”.
É justamente essa lacuna que este guia cobre. O cURL já vem instalado no macOS, na maioria das distros Linux e no Windows 10 em diante, então é bem provável que você já o tenha aí na sua máquina. Mas entre falhas silenciosas em redirecionamentos, 403 misteriosos e a transição de “baixar um arquivo” para “baixar 500 arquivos sem travar o terminal”, há muita coisa que pode dar errado. Vou mostrar as flags que realmente importam, os comandos passo a passo que eu uso de verdade, os erros que mais pegam as pessoas e o ponto em que o cURL realmente não consegue mais ajudar — e o que usar no lugar.
O que é o cURL e por que isso importa?
cURL é uma ferramenta gratuita e de código aberto para linha de comando, usada para transferir dados de ou para um servidor por meio de uma URL. Ele fala HTTP, HTTPS, FTP, SFTP e uma longa lista de outros protocolos, por isso aparece em todo tipo de lugar: scripts em bash, Dockerfiles e pipelines de CI. Por baixo dos panos, o comando curl que você digita no terminal usa o libcurl, a biblioteca C de transferência que muitas aplicações e bindings de linguagens incorporam. A extensão cURL do PHP é um exemplo; a popular biblioteca Requests do Python é um cliente HTTP separado, baseado em urllib3, e não em libcurl.
A versão estável mais recente no momento em que escrevo é o curl 8.21.0, lançada em junho de 2026 — mas não assuma que seu sistema operacional já traz exatamente essa build. Versões empacotadas pelas distros costumam ficar meses atrás do projeto principal, às vezes até mais, então vale rodar curl --version antes de presumir que uma flag como --parallel está disponível.
Por que baixar arquivos com cURL? Principais casos de uso
Muita gente me pergunta por que alguém usaria uma ferramenta de linha de comando quando o navegador baixa arquivos sem problema. A resposta honesta: navegador é ótimo até você precisar automatizar qualquer coisa.
| Caso de uso | Por que o cURL se destaca |
|---|---|
| Baixar binários em pipelines de CI/CD | É scriptável e não depende de interface gráfica |
| Buscar respostas de API ou exports de dados | Suporta cabeçalhos personalizados, autenticação e redirecionamento de saída |
| Retomar downloads grandes via SSH | Tem suporte nativo a retomada (-C -) |
| Automatizar downloads recorrentes (cron jobs) | Leve e fácil de combinar com scripts de shell |
| Pegar arquivos protegidos por autenticação | Flags flexíveis para auth (basic, token, cookies, .netrc) |
Baixar pelo navegador é uma ação manual, pontual. O cURL transforma isso em algo que você pode agendar, encaixar num pipeline, tentar novamente em caso de falha e executar igual em cem servidores ao mesmo tempo. Esse é o grande apelo — não é mais sofisticado, é simplesmente repetível.
As flags essenciais do cURL para baixar arquivos
Eu sempre volto às mesmas dez ou doze flags para resolver 90% do que preciso. Aqui está o resumo que eu gostaria que tivessem me dado anos atrás, organizado pelo que cada uma realmente faz.
Flags de saída e salvamento de arquivos
-O(--remote-name) salva o arquivo usando a última parte da URL como nome. É útil, mas pode sobrescrever silenciosamente um arquivo existente com o mesmo nome.-o <filename>(--output) deixa você escolher exatamente o nome local:curl -o relatorio.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) usa o nome do arquivo informado no cabeçalhoContent-Dispositiondo servidor, em vez da URL. É prático em downloads de API, mas trate nomes vindos do servidor como entrada não confiável — baixe para uma pasta dedicada, e não para sua home, seguindo a orientação de segurança do próprio curl.
Flags de comportamento que todo download precisa
-L(--location) manda o curl seguir redirecionamentos HTTP. Sem isso, uma resposta 3xx pode ser salva como uma pequena página HTML de redirecionamento em vez do arquivo real — esse é o erro mais comum de “por que meu download está quebrado” que eu vejo.-C -(--continue-at -) retoma um download interrompido de onde ele parou.-s/-Sexecutam em silêncio, mas ainda mostram erros — ótimo para scripts em que você não quer uma barra de progresso poluindo os logs.--limit-rate 1Mlimita a largura de banda (útil em conexões compartilhadas ou quando você não quer monopolizar uma rede com franquia).--connect-timeout 10e--max-time 300evitam que uma conexão travada congele seu script para sempre.--retry 3e--retry-delay 5tentam novamente automaticamente em falhas temporárias — de acordo com a página de manual do curl, combine isso com--retry-all-errorsapenas quando repetir exatamente a mesma requisição for realmente seguro.
Flags de progresso e depuração
-#mostra uma barra de progresso simples em vez da tabela de estatísticas padrão.-vexibe saída detalhada, incluindo todos os cabeçalhos da requisição e da resposta — é a minha escolha quando algo está se comportando mal.-I(--head) busca apenas os cabeçalhos da resposta, o que é um ótimo teste prévio antes de se comprometer com um download grande.-wpermite imprimir uma saída personalizada após a transferência, comocurl -o /dev/null -s -w "%{http_code}\n" <url>para verificar apenas o código de status.
Antes de começar
- Nível de dificuldade: Iniciante a intermediário (as seções de lote e autenticação ficam um pouco mais avançadas)
- Tempo necessário: Cerca de 15 a 20 minutos para passar pelos comandos principais
- O que você vai precisar: Um terminal (Terminal do macOS, shell Linux ou Windows PowerShell/WSL), o curl instalado (confira com
curl --version) e uma URL de teste — vou usar um asset público de release do GitHub como exemplo, porque é estável e livremente acessível
Como baixar arquivos com cURL: passo a passo
Passo 1: Baixar um único arquivo
O básico absoluto: curl -O <url> salva o arquivo com o nome original, enquanto curl -o meuarquivo.zip <url> permite renomeá-lo na hora do download.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
Hoje eu sempre adiciono -L, sem exceção — já me ferrei vezes demais com redirecionamentos que transformaram meu “download” em um arquivo HTML de 400 bytes. Você deve ver a barra de progresso avançando no terminal e, ao final, o arquivo na sua pasta atual.
Quando o comando funciona, o progresso chega a 100% e curl-8.21.0.tar.gz aparece no diretório atual. Confirme o arquivo antes de usar:
ls -lh curl-8.21.0.tar.gz
Passo 2: Baixar e renomear o arquivo
Use -o quando quiser um nome local específico, em vez do nome que vier no final da 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
O -S aqui faz os erros reaparecerem caso você também tenha usado -s em outra parte do script. Essa combinação — -L -o <nome> -S — é basicamente o meu comando padrão para baixar um único arquivo.
Passo 3: Retomar um download interrompido
Se um download grande cair no meio do caminho (wifi ruim, VPN oscilando, qualquer coisa assim), não comece do zero. Rode:
curl -C - -LO https://example.com/large-file.iso
O detalhe importante: isso só funciona se o servidor aceitar requisições por intervalo de bytes. Accept-Ranges: bytes é um sinal positivo útil, mas a ausência desse cabeçalho não prova que os ranges não são suportados. A verificação confiável é a resposta do servidor a uma requisição real por intervalo: um download retomável normalmente devolve 206 Partial Content com um Content-Range válido. Execute o comando de retomada e verifique o status com -v ou -D -; se o servidor ignorar o intervalo ou rejeitar o offset, reinicie de forma deliberada em vez de assumir que o arquivo parcial é seguro.
Passo 4: Baixar com barra de progresso ou em silêncio
Para uma visualização mais limpa em um terminal interativo: curl -# -LO <url>. Para scripts e tarefas agendadas, quando você quer só os erros e nada de ruído: curl -sS -LO <url>. Eu uso a versão silenciosa quase sempre, exceto quando estou depurando manualmente.
Passo 5: Limitar a velocidade de download
Em uma conexão compartilhada do escritório (ou quando eu não quero ser “aquela pessoa” sugando toda a banda durante uma reunião de vídeo), eu limito com:
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
As unidades são K, M e G para kilobytes, megabytes e gigabytes por segundo, respectivamente.
Passo 6: Salvar os cabeçalhos da resposta junto com o arquivo
Às vezes eu preciso saber exatamente o que o servidor devolveu — tipo de conteúdo, cabeçalhos de cache e coisas assim — sem poluir o terminal:
curl -L -D headers.txt -o file.zip https://example.com/file.zip
Isso grava os cabeçalhos da resposta em headers.txt enquanto o arquivo real vai para file.zip. Ótimo para depurar divergências de content-type ou verificar se uma CDN está realmente fazendo cache como você imagina.
Dicas e armadilhas comuns
- Dica: Sempre use
-Lpor padrão. Sinceramente, não consigo pensar em uma desvantagem em incluí-lo, e já perdi horas por ter esquecido isso. - Dica: Em scripts, combine
--failcom o comando de download para que uma resposta fora da faixa 2xx realmente faça o script sair com erro, em vez de salvar silenciosamente uma página de erro como se fosse o arquivo. - Armadilha: Não combine
-C -com--remove-on-error— o curl documenta que essas opções são incompatíveis, já que a retomada precisa que o arquivo parcial ainda exista. - Armadilha:
-Opode sobrescrever arquivos sem aviso. Se você estiver baixando em lote para um diretório compartilhado, use--output-dirpara manter tudo organizado.
Como baixar vários arquivos e fazer downloads em lote com cURL
Os exemplos de um único arquivo são a parte fácil. Os fluxos reais que construí — puxando exports noturnos de dados, sincronizando binários entre servidores de build — precisavam de concorrência, e é aqui que muitos tutoriais simplesmente... param. Existem três abordagens que vale a pena conhecer, cada uma um pouco mais complexa que a anterior.
Abordagem 1: várias URLs em um único comando cURL
A opção mais simples é listar as URLs:
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
Isso funciona, mas é sequencial — o curl termina completamente um arquivo antes de começar o próximo. Ok para três arquivos, doloroso para trezentos.
Abordagem 2: downloads paralelos com --parallel (curl 7.66+)
Desde o curl 7.66, você pode adicionar --parallel (ou -Z) para buscar várias URLs ao mesmo tempo:
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
Vale saber: o máximo paralelo padrão é, na verdade, 50, o que é concorrência demais para a maioria dos servidores — e até para a sua rede agradecer. Eu costumo definir --parallel-max de forma explícita e conservadora — normalmente entre 4 e 8 — em vez de confiar no padrão.
Abordagem 3: xargs e loops Bash para concorrência a partir de uma lista de URLs
Para uma lista grande de URLs em um arquivo de texto, eu geralmente uso xargs:
cat urls.txt | xargs -n1 -P 8 curl -O -L
Ou, se eu quiser mais controle sobre o que acontece com cada tarefa, uso um loop Bash com processos em segundo plano:
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
O wait no final é importante — sem ele, o script termina antes que os downloads em segundo plano acabem.
Quando usar wget ou aria2 no lugar
Vou ser direto: cURL nem sempre é a ferramenta certa. Se você precisa espelhar toda a árvore de diretórios de um site, wget -r faz crawling recursivo nativamente de um jeito que o cURL simplesmente não foi feito para fazer. Se você precisa de downloads segmentados e de múltiplas fontes para maximizar a velocidade em um arquivo gigantesco, aria2c é realmente mais rápido.
| Ferramenta | Ideal para |
|---|---|
| cURL | Precisão, scripts, downloads de um único arquivo ou em pequenos lotes, interação com APIs |
| wget | Downloads recursivos/espelhados de sites, captura em massa de arquivos estáticos |
| aria2 | Downloads segmentados e de múltiplas fontes, máxima taxa em arquivos grandes |
A força do cURL sempre foi a precisão e a capacidade de composição — pipe, script, flexibilidade de protocolo — e não o crawling bruto.
Como baixar arquivos protegidos com cURL: padrões de autenticação
A maioria dos tutoriais de cURL para em -u user:pass e pronto. Isso é resquício de uma internet antiga. Em 2026, os arquivos que eu realmente baixo vêm de APIs REST, painéis baseados em sessão e sistemas de CI — e cada um pede um tipo diferente de credencial.
Autenticação básica
curl -u username:password -O https://legacy-server.example.com/file.zip
Funciona bem para servidores FTP antigos ou endpoints HTTP simples. Só lembre que a senha aparece no histórico do shell e na lista de processos, a menos que você tome cuidado — não é algo que eu usaria para nada sensível.
Autenticação por token Bearer / OAuth
Essa é, honestamente, a menos representada na maioria dos guias, e a que eu mais uso hoje:
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
Esse é um padrão real para baixar um asset privado de release no GitHub — basta trocar o token e o ID do asset. APIs REST e recursos protegidos por OAuth2 falam praticamente essa linguagem hoje.
Autenticação baseada em cookies
Para aplicações web em que o login cria uma sessão, salve o cookie jar no login e reutilize-o no 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
Arquivo .netrc para ambientes automatizados e CI
Meu método preferido para qualquer coisa que rode sem supervisão. Crie um arquivo ~/.netrc (ou _netrc no Windows):
machine example.com
login myusername
password mypassword
Proteja com chmod 600 ~/.netrc e depois use:
curl --netrc -LO https://example.com/protected-file.zip
A vantagem é que as credenciais nunca tocam o histórico do shell nem o código do script — algo realmente importante em CI/CD, onde muitas vezes os scripts são registrados por inteiro.
| Método de autenticação | Flag/opção | Melhor para |
|---|---|---|
| Auth básica | -u user:pass | FTP legada, HTTP simples |
| Token Bearer | -H "Authorization: Bearer <token>" | APIs REST, OAuth2 |
| Auth por cookie | -b cookies.txt (+ -c para salvar) | Apps web baseadas em sessão |
Arquivo .netrc | --netrc ou --netrc-file | CI/CD, ambientes automatizados |
Solução de problemas: falhas comuns em downloads com cURL
Esta é a seção que eu realmente gostaria que existisse quando comecei, porque quase ninguém explica isso. “Por que meu download com curl não funciona” é uma busca real, frequente e extremamente frustrante — e as correções normalmente são uma linha só, quando você descobre a causa.
| Sintoma | Causa provável | Correção |
|---|---|---|
curl: (60) SSL certificate problem | Certificado autoassinado ou expirado | --cacert <arquivo> ou -k (só em dev) |
403 Forbidden / arquivo vazio | O servidor bloqueia o User-Agent padrão do curl | -A "Mozilla/5.0..." ou -H "User-Agent: ..." |
Download reinicia do zero com -C - | O servidor não suporta Range | Verifique com curl -I <url> se há Accept-Ranges: bytes |
| Arquivo de 0 bytes salvo | Redirecionamento não seguido | Adicione a flag -L |
curl: (28) Operation timed out | Servidor lento ou problemas de rede | --connect-timeout 10 --max-time 300 + --retry 3 |
| Página HTML salva em vez do arquivo | A página exige renderização JavaScript | O curl não executa JS — veja a seção abaixo |
Erros de certificado SSL: o que significam e como corrigir
O erro 60 significa que o curl não conseguiu verificar o certificado SSL do servidor — normalmente porque ele é autoassinado, expirado ou emitido por uma CA em que o curl não confia. Se você controla o servidor, aponte o curl para o bundle correto de CA com --cacert /caminho/para/ca.pem. A flag -k (--insecure) pula a verificação por completo, o que é aceitável em um ambiente local de desenvolvimento e uma péssima ideia para qualquer coisa que envolva produção ou dados reais de usuários.
403 Forbidden e downloads vazios
É surpreendente quantos servidores bloqueiam requisições que se identificam como curl/8.21.0 (o User-Agent padrão do curl), presumindo que sejam bots ou scrapers. A correção geralmente é só fingir ser um navegador:
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
Para checar o que realmente está voltando antes de fazer o download completo, eu uso: curl -o /dev/null -s -w "%{http_code}\n" <url>.
Timeouts, retries e conexões instáveis
Esse é o comando que eu tatuaria no braço se tivesse coragem para tatuagens.
Meu comando preferido para download, o que eu realmente uso em scripts de produção, combina várias flags de confiabilidade:
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
Isso inclui seguir redirecionamentos, retomar downloads, cinco tentativas com atraso de 3 segundos, timeout de conexão de 10 segundos, limite total de 10 minutos e falha imediata para códigos HTTP ruins — basicamente tudo que aprendi, na prática, a não esquecer.
cURL em automação real: pipelines de CI/CD, pipes e segurança em scripts
Enviar a saída do cURL para outras ferramentas
O curl nem precisa salvar nada em disco — mandar direto para outro comando é uma das funções mais subestimadas dele:
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
Baixar e extrair, ou baixar e analisar, em uma única linha. Esse é o padrão que eu uso o tempo todo para capturas pontuais de dados.
Usando cURL em GitHub Actions e CI/CD
Um passo mínimo no GitHub Actions que baixa um binário com lógica de retry e falha de forma explícita em caso de erro:
- name: Baixar binário
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
Guarde quaisquer tokens como segredos do CI e referencie-os como variáveis de ambiente — nunca os deixe codificados no script. E use --fail (ou --fail-with-body, se você precisar ver o corpo do erro para depuração) para que um download quebrado realmente falhe no build, em vez de passar silenciosamente com lixo.
A questão de segurança do curl | sh
Esse assunto aparece em quase todo fórum de desenvolvedores que já li, e com razão: mandar curl direto para sh significa executar código remoto que você não revisou, confiando totalmente que o servidor não foi comprometido e que a conexão não foi adulterada. Esse é o risco real — não é paranoia, é uma preocupação legítima de supply chain.
O padrão mais seguro é baixar primeiro, inspecionar o script, verificar um checksum ou assinatura GPG, se houver, e só então executá-lo:
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # leia de verdade
sha256sum install.sh # compare com o checksum publicado, se houver
bash install.sh
Instaladores conhecidos, como rustup e Homebrew, ainda usam o padrão curl | sh, e isso costuma ser aceito nesses casos específicos porque os mantenedores e o canal de distribuição são bem estabelecidos. Ainda assim, eu prefiro gastar dez segundos a mais inspecionando um script do que descobrir da pior forma que não deveria ter confiado nele.
Quando o cURL não é suficiente: páginas renderizadas por JS, sites anti-bot e dados estruturados
Aqui está um modo de falha que pega muita gente de surpresa — e quase nunca é culpa dela: você roda curl -O contra o que parece ser uma página normal e, em vez do conteúdo esperado, recebe um esqueleto HTML vazio, ou uma página de desafio do Cloudflare, ou algo que parece lixo. O curl fez exatamente o que foi feito para fazer — buscar a resposta HTTP bruta —, mas ele não executa JavaScript, não resolve CAPTCHA e não passa por sistemas de fingerprinting anti-bot. Isso não é um bug do curl; está fora da função dele.
Por que o cURL falha em páginas modernas
Aplicações modernas de página única geralmente retornam um HTML quase vazio, com o conteúdo real renderizado no cliente por JavaScript depois que a página carrega — algo que o curl nunca executa. Além disso, sistemas como Cloudflare e Akamai servem páginas de desafio ativamente para qualquer coisa que não pareça um navegador real, e requisições repetidas do curl a partir do mesmo IP podem receber limitação de taxa ou ser marcadas rapidamente como tráfego de bot.
O próximo passo: APIs de scraping com IA para desenvolvedores
Eu diria que o curl é a ferramenta certa para cerca de 80% dos downloads de arquivos e dados por aí — assets estáticos, respostas de API, qualquer coisa servida como um recurso HTTP simples. É nos outros 20%, as páginas pesadas em JavaScript ou protegidas por bot, que eu vejo desenvolvedores gastando horas brigando com cabeçalhos e User-Agents antes de, por fim, desistirem e recorrerem a outra camada.
Foi justamente essa lacuna que minha equipe construiu o Thunderbit para resolver, junto com a extensão Chrome pela qual a maioria das pessoas nos conhece. Do lado de desenvolvimento, a Open API do Thunderbit oferece POST /distill, que retorna Markdown limpo, pronto para LLM, a partir de uma URL — com a renderização da página feita pelo serviço — e POST /extract, que devolve JSON estruturado e compatível com o schema quando você precisa de dados com campos reais, em vez de texto legível. Há também um servidor MCP para que agentes no Claude ou no Cursor possam chamar thunderbit_distill e thunderbit_extract durante a tarefa, além de um CLI (npx @thunderbit/thunderbit-cli distill <url>) que se comporta de forma bem parecida com o curl no terminal. Você pode enviar a saída JSON para o jq, por exemplo thunderbit distill <url> --format json | jq -r '.data.markdown'; ou mandar a saída --format markdown para uma ferramenta de texto ou para um arquivo.
Comparando lado a lado, a diferença é gritante. Uma requisição curl para uma página de produto renderizada por JS pode retornar um <div id="root"></div> praticamente em branco. O comando equivalente thunderbit distill devolve o conteúdo renderizado da página em Markdown limpo. O Distill custa 1 crédito por URL e o Extract 20 créditos por URL. Os limites atuais por endpoint são diferentes: o Batch Distill suporta até 100 URLs por tarefa, enquanto o Batch Extract aceita até 50 URLs com um schema compartilhado. Confira a documentação atual da API antes de dimensionar uma fila de produção.
Se você é novo no assunto em geral, nosso próprio guia sobre o que realmente envolve web scraping é um bom ponto de partida, e o guia de scraping sem código cobre o lado não técnico desse mesmo problema para quem da sua equipe não vai tocar em terminal. Para uma comparação mais ampla das ferramentas nessa área, também reunimos um panorama com os melhores AI web scrapers que vale a pena conhecer.
Referência rápida: folha de consulta do cURL para downloads
| Tarefa | Comando |
|---|---|
| Download básico | curl -LO <url> |
| Nome de arquivo personalizado | curl -L -o meuarquivo.zip <url> |
| Retomar download | curl -C - -LO <url> |
| Silencioso, mostrando erros | curl -sSL -O <url> |
| Downloads paralelos | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Autenticação com token Bearer | curl -H "Authorization: Bearer <token>" -LO <url> |
| Comando padrão para script | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| Enviar para ferramenta de extração | curl -sL <url> | tar xz |
Conclusão e principais aprendizados
Baixar um arquivo com curl começa de forma simples — curl -O e pronto —, mas a verdadeira habilidade está nas camadas abaixo: saber quando adicionar -L, quando retomar em vez de recomeçar, qual padrão de autenticação realmente se encaixa no seu fluxo e o que fazer no momento em que aparece um 403 ou um HTML vazio no lugar do arquivo esperado. Em algum momento, eu dependi de todos esses padrões, geralmente logo depois de aprender, da pior maneira, por que eles importavam.
O curl continua sendo, sem dúvida, minha ferramenta padrão para downloads diretos e trabalho HTTP scriptável — é rápido, está em todo lugar e combina muito bem com o resto de um pipeline de shell. Mas, quando você encontra uma página renderizada por JavaScript ou um bloqueio anti-bot, isso não é um problema do curl que se resolve com mais flags; é um sinal de que você precisa de outra camada, e é exatamente aí que uma API como a do Thunderbit entra para assumir o trabalho sem te tirar do terminal.
Salve a folha de consulta, teste o comando com retry e resume no seu próximo download instável e, se você bater naquela parede em que o curl só devolve lixo, você já sabe qual é o próximo passo — a página de preços do Thunderbit mostra a distribuição atual de créditos, caso queira ver quanto custa essa evolução, e o nosso canal no YouTube tem tutoriais se você preferir assistir em vez de ler.
FAQs sobre baixar arquivos com cURL
Como baixo um arquivo com cURL e salvo com um nome específico?
Use -o seguido do nome desejado: curl -L -o seu_nome.ext <url>. Adicione -L para que redirecionamentos não atrapalhem o download.
Como retomo um download com cURL que falhou?
Execute curl -C - -LO <url>. Isso só funciona se o servidor aceitar requisições por intervalo — confira antes com curl -I <url> e procure Accept-Ranges: bytes na resposta.
O cURL consegue baixar arquivos que exigem login?
Sim, de quatro formas principais: autenticação básica (-u user:pass), tokens bearer (-H "Authorization: Bearer <token>"), sessões baseadas em cookies (-b cookies.txt) ou um arquivo .netrc para ambientes automatizados. Veja a seção de autenticação acima para o detalhamento completo e quando cada opção faz mais sentido.
Qual é a diferença entre cURL e wget para baixar arquivos?
O cURL suporta mais protocolos e costuma ser melhor para scripts, pipes e downloads precisos de um único arquivo ou em pequenos lotes. O wget foi feito para crawling recursivo e espelhamento de diretórios inteiros de sites, o que o torna a melhor escolha para capturas em massa de sites estáticos.
Por que o cURL baixa uma página HTML em vez do arquivo real?
Os dois suspeitos mais comuns: você esqueceu a flag -L e o servidor o redirecionou para outro lugar, ou a página precisa de JavaScript para renderizar seu conteúdo real — algo que o curl simplesmente não executa. No segundo caso, você vai precisar de uma ferramenta que consiga renderizar, e não de mais flags do curl.
