He perdido una cantidad absurda de noches intentando depurar scripts que, en teoría, solo tenían que “bajar un archivo y seguir con la vida”. Nueve de cada diez veces, el problema era que cURL hacía exactamente lo que yo le había pedido, no lo que realmente quería. Al final, hay una gran diferencia entre “curl -O funciona” y “curl -O funciona de forma fiable en producción”.
De eso va esta guía. cURL viene preinstalado en macOS, en la mayoría de distribuciones Linux y en Windows 10 en adelante, así que casi seguro ya lo tienes en tu equipo. Pero entre fallos silenciosos por redirecciones, misteriosos 403 y el salto de “descargar un archivo” a “descargar 500 sin derretir el terminal”, hay mucho margen para atascarse. Aquí te voy a mostrar los flags que de verdad importan, los comandos paso a paso que uso yo, los errores que más suelen tropezar a la gente y el punto en el que cURL deja de servirte y conviene tirar de otra herramienta.
¿Qué es cURL y por qué debería importarte?
cURL es una herramienta gratuita y de código abierto para línea de comandos que sirve para transferir datos hacia o desde un servidor mediante una URL. Soporta HTTP, HTTPS, FTP, SFTP y una larga lista de protocolos, por eso aparece en todas partes: scripts de bash, Dockerfiles y pipelines de CI. Por debajo, el comando curl que escribes en el terminal usa libcurl, la librería de transferencia en C que muchas aplicaciones y bindings de lenguaje integran. La extensión cURL de PHP es un ejemplo; la popular librería Requests de Python es un cliente HTTP aparte basado en urllib3, no en libcurl.
La versión estable actual, en el momento de escribir esto, es curl 8.21.0, publicada en junio de 2026, aunque no asumas que tu sistema operativo trae exactamente esa compilación. Las versiones empaquetadas por las distribuciones suelen ir con retraso respecto al proyecto original, a veces durante meses. Por eso vale la pena ejecutar curl --version antes de dar por hecho que un flag como --parallel ya está disponible.
¿Por qué descargar archivos con cURL? Principales casos de uso
Me preguntan bastante por qué alguien usaría una herramienta de línea de comandos cuando el navegador ya descarga archivos perfectamente. La respuesta honesta: los navegadores van genial hasta que necesitas automatizar algo.
| Caso de uso | Por qué cURL destaca |
|---|---|
| Descargar binarios en pipelines de CI/CD | Se puede automatizar, sin interfaz gráfica |
| Obtener respuestas de API o exportaciones de datos | Soporta cabeceras personalizadas, autenticación y salida encadenada |
| Reanudar descargas grandes por SSH | Soporte nativo para reanudar (-C -) |
| Automatizar descargas periódicas (cron jobs) | Ligero, fácil de combinar con scripts de shell |
| Descargar archivos detrás de autenticación | Flags de autenticación flexibles (basic auth, token, cookies, .netrc) |
Una descarga en el navegador es un clic manual y puntual. cURL convierte esa misma acción en algo que puedes programar, encadenar en un flujo, reintentar si falla y ejecutar igual en cien servidores a la vez. Esa es su gran ventaja: no es más vistoso, es más repetible.
Los flags esenciales de cURL para descargar archivos
Siempre vuelvo al mismo grupo de una docena de flags para el 90% de lo que hago. Aquí tienes la chuleta que me habría encantado tener hace años, organizada según su función real.
Flags de salida y guardado de archivos
-O(--remote-name) guarda el archivo usando como nombre la última parte de la URL. Es útil, pero puede sobrescribir sin avisar un archivo existente con el mismo nombre.-o <archivo>(--output) te permite elegir el nombre exacto:curl -o informe.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) usa el nombre de archivo indicado en la cabeceraContent-Dispositiondel servidor, en lugar de tomarlo de la URL. Es muy cómodo para descargas de API, pero trata los nombres enviados por el servidor como entrada no confiable: mejor descargar en una carpeta dedicada y no en tu directorio personal, tal y como recomienda la guía de seguridad de curl.
Flags de comportamiento que toda descarga necesita
-L(--location) le dice a curl que siga redirecciones HTTP. Sin esto, una respuesta 3xx se guarda como una pequeña página HTML de redirección en lugar del archivo real; este es el error más común que veo cuando la gente dice “mi descarga no funciona”.-C -(--continue-at -) reanuda una descarga interrumpida desde donde se quedó.-s/-Sejecutan en modo silencioso, pero mostrando errores; va muy bien en scripts donde no quieres una barra de progreso ensuciando los logs.--limit-rate 1Mlimita el ancho de banda (útil en conexiones compartidas o cuando no quieres acaparar una red con límite de datos).--connect-timeout 10y--max-time 300evitan que una conexión colgada deje tu script bloqueado para siempre.--retry 3y--retry-delay 5reintentan automáticamente ante fallos transitorios. Según la página de manual de curl, combínalo con--retry-all-errorssolo cuando repetir exactamente la misma petición sea realmente seguro.
Flags de progreso y depuración
-#muestra una barra de progreso simple en lugar de la tabla de estadísticas por defecto.-vvuelca salida detallada, incluidas las cabeceras completas de petición y respuesta; es mi opción favorita cuando algo se comporta raro.-I(--head) obtiene solo las cabeceras de respuesta, ideal como comprobación previa antes de lanzarte a una descarga grande.-wpermite imprimir salida personalizada después de la transferencia, comocurl -o /dev/null -s -w "%{http_code}\n" <url>para comprobar solo el código de estado.
Antes de empezar
- Dificultad: de principiante a intermedio (las secciones de lotes y autenticación suben un poco el nivel)
- Tiempo necesario: unos 15-20 minutos para recorrer los comandos principales
- Lo que necesitarás: un terminal (Terminal de macOS, shell de Linux o PowerShell/WSL en Windows), curl instalado (compruébalo con
curl --version) y una URL de prueba; usaré un recurso público de una release de GitHub como ejemplo porque es estable y de acceso libre
Cómo descargar archivos con cURL: paso a paso
Paso 1: Descargar un solo archivo
Lo más básico: curl -O <url> guarda el archivo con su nombre original, mientras que curl -o miarchivo.zip <url> te deja renombrarlo al descargarlo.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
Ahora añado -L por defecto, siempre, sin excepciones: me han fastidiado demasiadas veces las redirecciones que convertían en silencio una “descarga” en un archivo HTML de 400 bytes. Deberías ver cómo avanza el indicador de progreso en el terminal hasta que el archivo queda guardado en el directorio actual.
Cuando el comando se completa, el progreso llega al 100% y aparece curl-8.21.0.tar.gz en el directorio actual. Compruébalo antes de usarlo:
ls -lh curl-8.21.0.tar.gz
Paso 2: Descargar y renombrar el archivo
Usa -o cuando quieras un nombre local concreto y no el que venga al final de la 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
Aquí -S vuelve a mostrar errores en caso de que también hayas usado -s en otra parte del script. Esta combinación —-L -o <nombre> -S— es básicamente mi comando estándar para descargar un solo archivo.
Paso 3: Reanudar una descarga interrumpida
Si una descarga grande se corta a mitad de camino (wifi inestable, VPN con mal día, lo que sea), no empieces desde cero. Ejecuta:
curl -C - -LO https://example.com/large-file.iso
El matiz: esto solo funciona si el servidor admite peticiones por rangos de bytes. Accept-Ranges: bytes es una señal positiva útil, pero su ausencia no prueba que no haya soporte. La comprobación fiable es la respuesta real del servidor a una petición de rango: una respuesta reanudable normalmente devuelve 206 Partial Content con un Content-Range válido. Ejecuta el comando de reanudación y revisa el estado con -v o -D -; si el servidor ignora el rango o rechaza el desplazamiento, reinicia de forma explícita en lugar de asumir que el archivo parcial es seguro.
Paso 4: Descargar con barra de progreso o en silencio
Si quieres una visual más limpia en un terminal interactivo: curl -# -LO <url>. Para scripts y cron jobs, donde solo quieres errores y no ruido: curl -sS -LO <url>. Yo uso casi siempre la versión silenciosa, salvo cuando estoy depurando a mano.
Paso 5: Limitar la velocidad de descarga
En una conexión compartida de oficina, o cuando no quiero ser “esa persona” que acapara ancho de banda en mitad de una videollamada, limito la velocidad así:
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
Las unidades son K, M y G para kilobytes, megabytes y gigabytes por segundo, respectivamente.
Paso 6: Guardar las cabeceras de respuesta junto con el archivo
A veces necesito saber exactamente qué devolvió el servidor —tipo de contenido, cabeceras de caché y demás— sin llenar el terminal de información:
curl -L -D headers.txt -o file.zip https://example.com/file.zip
Esto guarda las cabeceras de respuesta en headers.txt mientras el archivo real se guarda como file.zip. Va genial para depurar discrepancias en el content-type o para verificar si una CDN realmente está cacheando lo que crees que está cacheando.
Consejos y errores comunes
- Consejo: usa
-Lcomo opción por defecto. Sinceramente, no se me ocurre ninguna desventaja real y he perdido horas por olvidarlo. - Consejo: al hacer scripts, combina
--failcon tu comando de descarga para que una respuesta que no sea 2xx haga que el script termine con error, en vez de guardar en silencio una página de error como si fuera el archivo. - Error común: no mezcles
-C -con--remove-on-error; curl los documenta como incompatibles, porque la reanudación necesita que el archivo parcial siga existiendo. - Error común:
-Opuede sobrescribir archivos sin avisar. Si vas a descargar por lotes en un directorio compartido, usa--output-dirpara mantener todo controlado.
Cómo descargar varios archivos y hacer descargas por lotes con cURL
Los ejemplos de un solo archivo son la parte fácil. Los flujos reales que he montado —descargar exportaciones de datos nocturnas, sincronizar binarios entre servidores de compilación— necesitaban concurrencia, y aquí es donde la mayoría de tutoriales… se quedan cortos. Hay tres enfoques que conviene conocer, cada uno un paso más complejo que el anterior.
Enfoque 1: varias URL en un solo comando cURL
La opción más simple es listar varias URL:
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
Funciona, pero es secuencial: curl termina un archivo por completo antes de empezar el siguiente. Vale para tres archivos; para trescientos, duele.
Enfoque 2: descargas paralelas con --parallel (curl 7.66+)
Desde curl 7.66, puedes añadir --parallel (o -Z) para descargar varias URL a la vez:
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
Conviene saber que el máximo paralelo por defecto es 50, bastante más concurrencia de la que suelen agradecer la mayoría de servidores, o incluso tu propia red. Yo prefiero indicar --parallel-max de forma explícita y conservadora —normalmente entre 4 y 8— en lugar de confiar en el valor por defecto.
Enfoque 3: xargs y bucles Bash para concurrencia a partir de una lista de URL
Para una lista grande de URL en un archivo de texto, normalmente recurro a xargs:
cat urls.txt | xargs -n1 -P 8 curl -O -L
O, si quiero más control sobre lo que hace cada tarea, un bucle Bash con procesos en segundo plano:
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
El wait del final importa: sin él, el script termina antes de que acaben las descargas en segundo plano.
Cuándo usar wget o aria2 en su lugar
Voy a ser claro: cURL no siempre es la herramienta adecuada. Si necesitas reflejar toda una estructura de directorios de un sitio web, wget -r hace rastreo recursivo de forma nativa, algo para lo que cURL simplemente no fue diseñado. Si necesitas descargas segmentadas y desde múltiples fuentes para exprimir al máximo la velocidad de un archivo enorme, aria2c es realmente más rápido.
| Herramienta | Ideal para |
|---|---|
| cURL | Precisión, scripts, descargas de uno o pocos archivos, interacción con APIs |
| wget | Descargas recursivas o espejo de sitios, capturas masivas de archivos estáticos |
| aria2 | Descargas segmentadas y desde múltiples fuentes, máximo rendimiento en archivos grandes |
La fortaleza de cURL siempre ha sido la precisión y la capacidad de combinarse con otras herramientas: pipes, scripts, flexibilidad de protocolos; no el rastreo por fuerza bruta.
Cómo descargar archivos protegidos con cURL: patrones de autenticación
La mayoría de los tutoriales de cURL se quedan en -u user:pass y listo. Eso es herencia de una web más antigua. En 2026, los archivos que realmente descargo vienen de APIs REST, paneles con sesión y sistemas de CI, y cada uno pide un tipo distinto de credencial.
Basic Auth
curl -u username:password -O https://legacy-server.example.com/file.zip
Perfecto para servidores FTP clásicos o endpoints HTTP sencillos. Solo ten en cuenta que la contraseña puede aparecer en el historial de tu shell y en la lista de procesos, salvo que tengas cuidado; no es algo que yo usaría para nada sensible.
Autenticación con Bearer / token OAuth
Este es el patrón que, sinceramente, menos aparece en la mayoría de guías y el que más uso ahora:
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
Es un patrón real para descargar un asset privado de una release de GitHub; solo cambia el token y el ID del asset. Las APIs REST y los recursos protegidos con OAuth2 prácticamente hablan este idioma hoy en día.
Autenticación con sesión basada en cookies
Para aplicaciones web en las que iniciar sesión crea una sesión, guarda la jarra de cookies al iniciar sesión y reutilízala al descargar:
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
Archivo .netrc para entornos automatizados y CI
Mi método preferido para cualquier cosa que se ejecute sin supervisión. Crea un archivo ~/.netrc (o _netrc en Windows):
machine example.com
login myusername
password mypassword
Protégelo con chmod 600 ~/.netrc y luego úsalo así:
curl --netrc -LO https://example.com/protected-file.zip
La ventaja es que las credenciales nunca pasan por el historial del shell ni por el código fuente del script, algo realmente importante en CI/CD, donde a menudo los scripts quedan registrados íntegros.
| Método de autenticación | Flag/opción | Ideal para |
|---|---|---|
| Basic auth | -u usuario:contraseña | FTP heredado, HTTP simple |
| Token Bearer | -H "Authorization: Bearer <token>" | APIs REST, OAuth2 |
| Autenticación con cookies | -b cookies.txt (+ -c para guardar) | Aplicaciones web basadas en sesión |
Archivo .netrc | --netrc o --netrc-file | CI/CD, entornos automatizados |
Solución de problemas: fallos comunes al descargar con cURL
Esta es la sección que realmente me habría gustado tener cuando empecé, porque casi nadie la explica. “Por qué no funciona mi descarga con curl” es una búsqueda muy real, frecuente y frustrante, y casi siempre la solución es una línea cuando ya sabes cuál es la causa.
| Síntoma | Causa probable | Solución |
|---|---|---|
curl: (60) SSL certificate problem | Certificado autofirmado o caducado | --cacert <archivo> o -k (solo desarrollo) |
403 Forbidden / archivo vacío | El servidor bloquea el User-Agent por defecto de curl | -A "Mozilla/5.0..." o -H "User-Agent: ..." |
La descarga empieza de cero con -C - | El servidor no admite Range | Comprueba con curl -I <url> si aparece Accept-Ranges: bytes |
| Se guarda un archivo de 0 bytes | No se siguió la redirección | Añade el flag -L |
curl: (28) Operation timed out | Servidor lento o problemas de red | --connect-timeout 10 --max-time 300 + --retry 3 |
| Se guarda una página HTML en lugar del archivo | La página requiere renderizado con JavaScript | curl no puede ejecutar JS: mira la sección de abajo |
Errores de certificado SSL: qué significan y cómo resolverlos
El error 60 significa que curl no pudo verificar el certificado SSL del servidor, normalmente porque es autofirmado, está caducado o lo emitió una CA en la que curl no confía. Si controlas el servidor, apunta curl al bundle de CA correcto con --cacert /ruta/al/ca.pem. El flag -k (--insecure) se salta la verificación por completo, algo que puede valer para un entorno local de desarrollo, pero que me parece una mala idea para cualquier cosa que toque producción o datos reales de usuarios.
403 Forbidden y descargas vacías
Muchos servidores bloquean peticiones que se identifican como curl/8.21.0 —la cadena de User-Agent por defecto de curl— porque asumen que son bots o scrapers. La solución suele ser simplemente fingir que eres un navegador:
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
Para comprobar qué está devolviendo realmente el servidor antes de lanzarme a una descarga completa, uso: curl -o /dev/null -s -w "%{http_code}\n" <url>.
Timeouts, reintentos y conexiones inestables
Este es el comando que me tatuaría en el brazo si fuera más valiente con los tatuajes.
Mi comando de descarga de referencia, el que uso de verdad en scripts de producción, combina varias capas de fiabilidad:
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
Eso incluye seguir redirecciones, reanudar, cinco reintentos con una pausa de 3 segundos, un timeout de conexión de 10 segundos, un límite global de 10 minutos y un fallo duro ante códigos HTTP erróneos: básicamente todo lo que he aprendido por las malas que conviene añadir.
cURL en automatización real: pipelines de CI/CD, pipes y seguridad en scripts
Enviar la salida de cURL a otras herramientas
curl no tiene por qué guardar nada en disco: encadenarlo directamente a otro comando es una de sus funciones más infravaloradas:
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
Descargar y extraer, o descargar y procesar, en una sola línea. Este es el patrón que uso constantemente para extracciones puntuales de datos.
Usar cURL en GitHub Actions y CI/CD
Un paso mínimo de GitHub Actions para descargar un binario con lógica de reintento y fallar con claridad si hay error:
- name: Download binary
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
Guarda cualquier token como secreto del CI y referencia esos valores mediante variables de entorno; nunca los escribas directamente en el script. Y usa --fail (o --fail-with-body si necesitas ver el cuerpo del error para depurar) para que una descarga rota rompa realmente la compilación, en vez de “funcionar” silenciosamente con basura.
La cuestión de seguridad de curl | sh
Esta aparece en casi todos los foros de desarrollo que he leído, y con razón: enviar curl directamente a sh significa ejecutar código remoto que no has revisado, confiando por completo en que el servidor no ha sido comprometido y la conexión no ha sido manipulada. Ese es el riesgo real: no paranoia, sino una preocupación muy básica de la cadena de suministro.
El patrón más seguro es descargar primero, inspeccionar el script, verificar un checksum o una firma GPG si se proporciona, y solo entonces ejecutarlo:
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # léelo de verdad
sha256sum install.sh # compáralo con el checksum publicado si existe
bash install.sh
Instaladores conocidos como rustup y Homebrew siguen usando el patrón curl | sh, y en esos casos concretos suele aceptarse porque los mantenedores y el canal de distribución están bien establecidos. Aun así, yo prefiero dedicar diez segundos extra a revisar un script antes que descubrir, demasiado tarde, que no debía haber confiado en él.
Cuando cURL no basta: páginas renderizadas con JS, sitios anti-bot y datos estructurados
Hay un modo de fallo que pilla a muchísima gente, y casi nunca es culpa suya: lanzas curl -O sobre lo que parece una página normal y, en vez del contenido que esperabas, obtienes una carcasa HTML vacía, una página de desafío de Cloudflare o algo que parece basura. curl hizo exactamente lo que se diseñó para hacer —traer la respuesta HTTP en bruto—, solo que no puede ejecutar JavaScript, resolver un CAPTCHA ni saltarse un sistema anti-bot basado en fingerprinting. Eso no son bugs de curl; simplemente están fuera de su cometido.
Por qué cURL falla en las páginas web modernas
Muchas aplicaciones modernas de una sola página devuelven un HTML casi vacío, y el contenido real se renderiza en el cliente mediante JavaScript después de cargar la página, algo que curl nunca ejecuta. Además, sistemas como Cloudflare y Akamai sirven páginas de desafío a cualquier cosa que no parezca un navegador real, y las peticiones repetidas de curl desde la misma IP pueden acabar bastante rápido limitadas o marcadas como tráfico de bot.
El siguiente paso: APIs de scraping con IA para desarrolladores
Diría que curl es la herramienta correcta para aproximadamente el 80% de las descargas de archivos y datos que hay ahí fuera: recursos estáticos, respuestas de API, cualquier cosa servida como recurso HTTP plano. Es en el otro 20% —las páginas pesadas en JavaScript o protegidas por anti-bot— donde he visto a desarrolladores perder horas peleando con cabeceras y user-agent antes de rendirse y subir de nivel.
Precisamente para cubrir ese hueco mi equipo creó Thunderbit, junto con la extensión de Chrome por la que muchos nos conocen. En el lado técnico, la API abierta de Thunderbit te ofrece POST /distill, que devuelve Markdown limpio, listo para LLM, a partir de una URL —con el renderizado de la página gestionado por el servicio— y POST /extract, que devuelve JSON estructurado alineado con un esquema cuando necesitas datos con campos reales en lugar de texto legible. También hay un servidor MCP para que agentes en Claude o Cursor puedan llamar a thunderbit_distill y thunderbit_extract durante una tarea, y una CLI (npx @thunderbit/thunderbit-cli distill <url>) que se comporta bastante como curl en el terminal. Puedes enviar la salida JSON a jq, por ejemplo thunderbit distill <url> --format json | jq -r '.data.markdown'; o enviar la salida --format markdown a una herramienta de texto o a un archivo.
Comparado lado a lado, la diferencia es enorme. Una petición de curl contra una página de producto renderizada con JS puede devolver un <div id="root"></div> casi vacío. El comando equivalente thunderbit distill devuelve el contenido de la página ya renderizado en Markdown limpio. Distill cuesta 1 crédito por URL y Extract 20 créditos por URL. Los límites concretos de cada endpoint cambian: Batch Distill admite hasta 100 URL por trabajo, mientras que Batch Extract acepta hasta 50 URL con un esquema compartido. Revisa la documentación actual de la API antes de dimensionar una cola de producción.
Si estás empezando con este concepto en general, nuestro propio artículo sobre qué implica realmente el web scraping es un buen punto de partida, y la guía de scraping sin código cubre la parte no técnica de este mismo problema para cualquiera de tu equipo que no vaya a tocar un terminal. Para una comparación más amplia de herramientas en este espacio, también hemos preparado un resumen de los mejores AI web scrapers que conviene conocer.
Referencia rápida: chuleta de descargas con cURL
| Tarea | Comando |
|---|---|
| Descarga básica | curl -LO <url> |
| Nombre de archivo personalizado | curl -L -o miarchivo.zip <url> |
| Reanudar descarga | curl -C - -LO <url> |
| Silencioso pero mostrando errores | curl -sSL -O <url> |
| Descargas paralelas | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Autenticación con token Bearer | curl -H "Authorization: Bearer <token>" -LO <url> |
| Comando ideal para scripts | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| Enviar a una herramienta de extracción | curl -sL <url> | tar xz |
Conclusión y puntos clave
Descargar un archivo con curl empieza de forma muy simple —curl -O y casi listo—, pero la verdadera habilidad está en lo que hay debajo: saber cuándo añadir -L, cuándo reanudar en vez de reiniciar, qué patrón de autenticación encaja con tu flujo y qué hacer en cuanto aparece un 403 o una carcasa HTML vacía en lugar del archivo esperado. Yo he dependido de cada uno de estos patrones en algún momento, normalmente justo después de aprender por las malas por qué importaban.
curl sigue siendo, sin duda, mi herramienta por defecto para descargas sencillas y trabajo HTTP automatizable: es rápido, está en todas partes y se integra de maravilla con el resto de un pipeline de shell. Pero cuando te topas con una página renderizada con JavaScript o con una barrera anti-bot, eso no se arregla con más flags de curl; es señal de que necesitas otra capa, y ahí es exactamente donde una API como la de Thunderbit toma el relevo sin obligarte a salir del terminal.
Guarda la chuleta, prueba el comando de reintento y reanudación en tu próxima descarga inestable, y si llegas a ese muro en el que curl solo devuelve basura, ya sabes cuál es el siguiente paso. La página de precios de Thunderbit muestra el desglose actual de créditos si quieres ver cuánto cuesta ese salto, y nuestro canal de YouTube tiene tutoriales si prefieres ver antes que leer.
Preguntas frecuentes sobre cómo descargar archivos con cURL
¿Cómo descargo un archivo con cURL y lo guardo con un nombre específico?
Usa -o seguido del nombre que quieras: curl -L -o tuarchivo.ext <url>. Añade -L para que las redirecciones no arruinen la descarga.
¿Cómo reanudo una descarga de cURL que falló?
Ejecuta curl -C - -LO <url>. Esto solo funciona si el servidor admite peticiones por rangos; compruébalo antes con curl -I <url> y busca Accept-Ranges: bytes en la respuesta.
¿Puede cURL descargar archivos que requieren inicio de sesión?
Sí, de cuatro formas principales: basic auth (-u user:pass), tokens bearer (-H "Authorization: Bearer <token>"), sesiones basadas en cookies (-b cookies.txt) o un archivo .netrc para entornos automatizados. Mira la sección de autenticación más arriba para ver el desglose completo y cuándo encaja cada opción.
¿Cuál es la diferencia entre cURL y wget para descargar archivos?
cURL soporta más protocolos y suele ser mejor para scripts, pipes y descargas precisas de uno o pocos archivos. wget está pensado para rastreo recursivo y para reflejar directorios completos de un sitio, así que suele ser mejor para capturas masivas de sitios estáticos.
¿Por qué cURL descarga una página HTML en lugar del archivo real?
Los dos sospechosos habituales: olvidaste el flag -L y el servidor te redirigió a otro sitio, o la página necesita JavaScript para renderizar su contenido real, algo que curl no puede ejecutar. En el segundo caso, necesitarás una herramienta capaz de renderizar, no más flags de curl.
