{"id":151,"date":"2017-04-06T11:01:28","date_gmt":"2017-04-06T14:01:28","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/2017\/04\/usando-comando-wget-no-linux\/"},"modified":"2026-09-08T02:28:46","modified_gmt":"2026-09-08T05:28:46","slug":"usando-comando-wget-no-linux","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/es\/2017\/04\/usando-comando-wget-no-linux\/","title":{"rendered":"Usando el comando wget en Linux"},"content":{"rendered":"

\"Mascote<\/p>\n

Nota (2026):<\/strong> entrada de 2017, revisada. Los ejemplos se reh\u00edcieron (el enlace de Ubuntu 16.04 ya no existe) y a\u00f1ad\u00ed lo que el texto original no ten\u00eda: l\u00edmite de ancho de banda, lista de descargas, mirroring de sitio, la comparaci\u00f3n honesta con el curl<\/code> y el sucesor wget2<\/code>. La serie actual de GNU Wget es la 1.25<\/strong>.<\/div>\n

O wget<\/strong> descarga archivos desde la terminal y \u2014 la caracter\u00edstica que lo hizo insustituible \u2014 reanuda la descarga interrumpida<\/strong>. Quien ya ha perdido una ISO de 2 GB al final de la barra, con una conexi\u00f3n mala, sabe por qu\u00e9 esto importa. Sigue siendo la herramienta adecuada para scripting, para servidores sin interfaz gr\u00e1fica y para cuando la conexi\u00f3n no es fiable.<\/p>\n

<\/p>\n

De d\u00f3nde viene<\/h2>\n

El wget naci\u00f3 en 1995 como Geturl<\/strong>, escrito por Hrvoje Nik\u0161i\u0107. El nombre cambi\u00f3 cuando el autor se enter\u00f3 de un programa hom\u00f3nimo de Amiga, y la W<\/em> proviene de World Wide Web. Forma parte del Proyecto GNU, est\u00e1 escrito en C port\u00e1til y habla HTTP, HTTPS y FTP.<\/p>\n

Cubri\u00f3 un hueco real de la \u00e9poca: no exist\u00eda un \u00fanico programa fiable que descargase por HTTP y FTP sin depender de Perl. Y, en una \u00e9poca de conexi\u00f3n telef\u00f3nica y enlace universitario lento, la capacidad de sobrevivir a una ca\u00edda de red sin intervenci\u00f3n humana era la caracter\u00edstica, no un detalle.<\/p>\n

Una nota a pie de p\u00e1gina hist\u00f3rica: en 2010 la analista Chelsea Manning us\u00f3 wget, dentro de la red SIPRNet, para descargar los 250 mil telegramas diplom\u00e1ticos<\/strong> del banco Net-Centric Diplomacy, entregados despu\u00e9s a WikiLeaks. Los registros de las guerras de Irak y Afganist\u00e1n, que suelen aparecer en la misma frase, salieron por otro camino: se exportaron directamente desde el sistema CIDNE, sin el wget. La herramienta es neutra; el uso, no siempre.<\/p>\n

Lo b\u00e1sico<\/h2>\n
# baixa um arquivo no diretorio atual\nwget https:\/\/exemplo.com\/arquivo.iso\n\n# -c retoma de onde parou, se o arquivo ja existir parcialmente\nwget -c https:\/\/exemplo.com\/arquivo.iso\n\n# salva com outro nome\nwget -O ubuntu.iso https:\/\/exemplo.com\/arquivo.iso\n\n# salva em outro diretorio\nwget -P ~\/Downloads https:\/\/exemplo.com\/arquivo.iso\n\n# baixa em segundo plano, com log em wget-log\nwget -b https:\/\/exemplo.com\/arquivo-grande.iso\n<\/code><\/pre>\n
O -c<\/code> es el motivo por el que existe el comando. Indica al servidor que contin\u00fae desde el byte donde se qued\u00f3 el archivo local, en lugar de empezar de nuevo. Funciona si el servidor admite solicitudes parciales, algo que hacen casi todos.<\/p>\n
Un cuidado que casi nadie menciona: el comando -c<\/code> asume<\/strong> que el archivo local con ese nombre es el comienzo del archivo remoto. Si all\u00ed hay otro archivo cualquiera con el mismo nombre, pide el resto a partir de ese tama\u00f1o y lo pega sobre lo que ya existe: el resultado tiene el tama\u00f1o correcto, el contenido corrupto y ning\u00fan aviso. Retoma \u00fanicamente lo que t\u00fa mismo comenzaste.<\/p>\n
Cuando la red es mala<\/h2>\n
# tenta indefinidamente, com espera crescente de ate 30s entre tentativas\nwget -c --tries=0 --waitretry=30 https:\/\/exemplo.com\/arquivo.iso\n\n# desiste de uma tentativa que travar por mais de 30s\nwget -c --timeout=30 --tries=20 https:\/\/exemplo.com\/arquivo.iso\n\n# limita a banda, para nao engasgar a conexao da casa ou do escritorio\nwget --limit-rate=500k https:\/\/exemplo.com\/arquivo.iso\n<\/code><\/pre>\n
Sobre el --waitretry<\/code>: no es un intervalo fijo, es un techo<\/em>. wget espera 1 segundos tras el primer fallo, 2 tras el segundo, y as\u00ed sucesivamente hasta el valor que le indicaste. Y el valor por defecto ya es 10 segundos, as\u00ed que --waitretry=10<\/code> no cambia nada \u2014 solo merece la pena escribirlo para aumentarlo. El --tries<\/code> tambi\u00e9n viene ya en 20; --tries=0<\/code> es lo que significa infinito.<\/p>\n
O --limit-rate<\/code> est\u00e1 subestimado: en un servidor compartido, descargar a toda velocidad derriba la latencia de todo el mundo. Limitar a 500 KB\/s suele ser la diferencia entre una descarga educada y una llamada al soporte.<\/p>\n
Varios archivos a la vez<\/h2>\n
# um arquivo de texto com uma URL por linha\nwget -i lista-de-urls.txt\n\n# continuando e limitando a banda, para uma lista grande\nwget -c --limit-rate=1m -i lista-de-urls.txt\n\n# todos os PDFs de uma pagina, sem subir de diretorio\nwget -r -l 1 -np -A pdf https:\/\/exemplo.com\/documentos\/\n<\/code><\/pre>\n
En esta \u00faltima, cada opci\u00f3n cuenta: -r<\/code> es recursivo, -l 1<\/code> limita a un nivel de profundidad, -np<\/code> (no-parent<\/em>) evita que suba al directorio superior, y -A pdf<\/code> acepta solo PDFs. Sin el -np<\/code> y sin el -l<\/code>, un recursivo puede terminar descargando todo el sitio.<\/p>\n
Espejar un sitio web<\/h2>\n
# baixa uma pagina com tudo que ela precisa para abrir offline\nwget -p -k https:\/\/exemplo.com\/artigo.html\n\n# espelho completo do site, navegavel offline\nwget --mirror -p -k -P .\/copia https:\/\/exemplo.com\/\n<\/code><\/pre>\n
-p<\/code> trae im\u00e1genes, CSS y scripts de la p\u00e1gina; -k<\/code> convierte los enlaces para que apunten a los archivos locales; --mirror<\/code> equivale a -r -N -l inf --no-remove-listing<\/code> \u2014 recursi\u00f3n infinita con verificaci\u00f3n de fecha.<\/p>\n
Dos detalles que evitan bloqueos: usa --wait=1<\/code> para no martillear el servidor y respeta la robots.txt<\/code>. Existe -e robots=off<\/code>, pero ignorar la pol\u00edtica del sitio es decisi\u00f3n tuya y suele acabar en bloqueo de IP.<\/p>\n
Cabeceras, autenticaci\u00f3n y certificado<\/h2>\n
# identificar-se como um navegador\nwget -U \"Mozilla\/5.0\" https:\/\/exemplo.com\/arquivo\n\n# enviar um cabecalho (ex.: token de API)\nwget --header=\"Authorization: Bearer SEU_TOKEN\" https:\/\/api.exemplo.com\/dados\n\n# autenticacao HTTP basica\nwget --user=usuario --ask-password https:\/\/exemplo.com\/privado\/arquivo\n<\/code><\/pre>\n
Vas a encontrar, en foros, la sugerencia de usar --no-check-certificate<\/code> cuando da error de SSL. Eso desactiva la verificaci\u00f3n del certificado y abre la puerta a interceptaciones. Un error de certificado casi siempre es reloj del sistema mal ajustado o paquete de CAs desactualizado \u2014 corrige la causa (sudo apt install --reinstall ca-certificates<\/code>) en vez de desactivar la comprobaci\u00f3n.<\/p>\n
\u00bfwget o curl?<\/h2>\n
Ambos descargan archivos, pero resuelven problemas diferentes:<\/p>\n