APT en Ubuntu 24.04 lento: trucos de caché/proxy para acelerar actualizaciones en oficinas

Rutina rápida de diagnóstico

Cuando la gente dice “APT va lento”, puede referirse a cualquiera de estos casos:

• La obtención de metadatos es lenta (apt update se queda en “Connecting”)
• Las descargas de paquetes son lentas (apt upgrade avanza a paso de tortuga)
• Desempaquetar/configurar es lento (CPU/disco limitados, nada que ver con la red)
• Todo es lento porque un proxy está “ayudando”

Primero: decide si es red, mirror o E/S local

1. Mide la velocidad de descarga al mirror desde un cliente y desde un host de red “conocido bueno”. Si ambos están mal, es WAN/mirror/proxy. Si solo los clientes están mal, es cliente/proxy/DNS.
2. Revisa la latencia DNS. Un DNS lento hace que APT parezca atascado, porque lo está—esperando.
3. Separa obtención vs instalación descargando solo (apt-get -d) y cronometrando el desempaquetado por separado.

Segundo: comprueba el comportamiento del proxy

1. Si estás detrás de un proxy corporativo, verifica si hace interceptación TLS, escaneo de contenido o “caché” malo.
2. Confirma que APT realmente está usando el proxy que crees. La mitad de las veces no está configurado en los servidores, y la otra mitad está configurado doblemente.

Tercero: decide la clase de solución

• Oficina con 10–300 máquinas Ubuntu: desplegar apt-cacher-ng en la LAN. Es la opción ideal.
• Cumplimiento estricto + conjunto de paquetes estable: considera un mirror completo o un gestor de repositorios (más operaciones, más control).
• Máquina única con Wi‑Fi malo: elige un mirror mejor y arregla el DNS; no construyas un imperio de caché.

Por qué APT “parece lento” en oficinas

El rendimiento de APT está formado por una pila de pequeñas latencias. En un centro de datos esas latencias son bajas y predecibles. En una oficina son caóticas: retransmisiones de Wi‑Fi, reenviadores DNS, proxies transparentes, dispositivos de “seguridad” y un enlace WAN compartido con videollamadas y alguien sincronizando una biblioteca de fotos del tamaño de una pequeña luna.

APT además tiene un perfil de tráfico específico:

• Muchos archivos pequeños de metadatos durante apt update (archivos Release, listas de índices).
• Luego menos descargas, pero más grandes, durante la instalación/actualización.
• Después E/S local de disco y CPU durante el desempaquetado y scripts post-instalación.

Esa primera fase es donde sufren las oficinas. APT puede obtener docenas de archivos a través de múltiples repositorios. Si cada conexión HTTPS tiene un apretón de manos lento o cada consulta DNS toma 200 ms, se acumula rápido. Un cache/proxy en la LAN colapsa esa latencia en un único salto rápido.

Consejo con opinión: Si tienes más de unas pocas máquinas Ubuntu en el mismo sitio, deja de permitir que cada una descargue los mismos paquetes desde Internet. Eso no es “descentralizado”. Es simplemente desperdicio.

Una breve broma, para amenizar: APT no está lento; solo espera pacientemente a que tu proxy termine de pensar.

Datos interesantes y contexto

• APT debutó a finales de los 1990s como una herramienta de paquetes de alto nivel para Debian, diseñada para manejar dependencias de forma fiable entre repositorios.
• “Acquire” es todo un subsistema dentro de APT; la mayoría de las quejas de “APT va lento” son realmente configuración de Acquire, DNS y transporte—no dpkg.
• Históricamente APT usaba múltiples conexiones cuidadosamente porque los mirrors y el ancho de banda solían ser escasos; las redes modernas invirtieron las restricciones, pero APT sigue priorizando la corrección.
• El ecosistema de mirrors de Ubuntu está distribuido globalmente; el “mejor” mirror para una oficina puede cambiar según el peering del ISP, no necesariamente por geografía.
• HTTPS se convirtió en la expectativa por defecto con el tiempo; mejora la integridad y la privacidad, pero aumenta la sobrecarga de handshake y hace inútiles algunos dispositivos de caché transparentes.
• Los índices de paquetes están comprimidos (a menudo .gz), lo cual es excelente para el ancho de banda, pero significa que la CPU puede importar en sistemas pequeños o VMs sobrecargadas.
• apt-cacher-ng se hizo popular porque es de baja ceremonia: puede cachear sin que tengas que ejecutar un mirror completo ni reescribir estructuras de repositorio.
• En muchas oficinas, DNS es el cuello de botella oculto porque los resolvers internos reenvían upstream con filtrado, logging y límites de tasa.

Una idea para recordar en operaciones: Werner Vogels ha defendido muchas veces la idea de que “todo falla, así que diseña para la falla” (paráfrasis). La lentitud de APT suele ser una falla blanda: no lo bastante rota para generar una alerta, pero sí suficiente para desperdiciar el tiempo de todos.

Tareas prácticas: comandos, salidas, qué significa y la decisión

Estas son tareas de campo. Ejecútalas primero en un cliente afectado y luego en el host que planeas usar como cache/proxy. No adivines. Mide.

Tarea 1: Confirma qué parte está lenta (update vs download vs install)

cr0x@server:~$ sudo time apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://security.ubuntu.com/ubuntu noble-security InRelease [110 kB]
Fetched 110 kB in 8s (13.2 kB/s)
Reading package lists... Done

real    0m9.214s
user    0m0.391s
sys     0m0.103s

Qué significa: Estás pasando segundos obteniendo metadatos pequeños. Eso huele a DNS, handshake de proxy o latencia por solicitud individual.

Decisión: Enfócate en DNS/proxy/caché, no en disco o CPU.

Tarea 2: Mide solo el tiempo de descarga para las actualizaciones (omite el tiempo de instalación)

cr0x@server:~$ sudo time apt-get -y -d dist-upgrade
Reading package lists... Done
Building dependency tree... Done
The following packages will be upgraded:
  openssl openssh-client
Need to get 4,812 kB of archives.
Get:1 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 openssl amd64 3.0.13-0ubuntu3.2 [1,402 kB]
Get:2 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 openssh-client amd64 1:9.6p1-3ubuntu13.4 [3,410 kB]
Fetched 4,812 kB in 2s (2,406 kB/s)

real    0m3.011s
user    0m0.233s
sys     0m0.116s

Qué significa: Si esto es rápido pero la actualización completa es lenta, tu cuello de botella es la instalación/desempaquetado local y los scripts.

Decisión: Si la descarga es rápida, deja de culpar a los mirrors. Revisa disco y bloqueos de dpkg.

Tarea 3: Revisa bloqueos de dpkg/apt y procesos atascados

cr0x@server:~$ ps aux | egrep 'apt|dpkg' | head
root        1421  0.0  0.1  18220  4800 ?        Ss   09:01   0:00 /usr/lib/apt/apt.systemd.daily
root        1507  0.2  0.3  56340 12420 ?        S    09:02   0:01 /usr/bin/dpkg --configure -a

Qué significa: El trabajo diario de systemd puede estar ya actualizando o configurando paquetes.

Decisión: No lo combatas. Déjalo terminar o programa las actualizaciones de oficina fuera del horario laboral.

Tarea 4: Verifica los repositorios y transportes configurados (HTTP vs HTTPS)

cr0x@server:~$ grep -R --no-filename -E '^(deb|deb-src)\s' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null | head -n 8
deb http://archive.ubuntu.com/ubuntu noble main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu noble-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu noble-security main restricted universe multiverse

Qué significa: Aquí estás usando HTTP (común para repos principales de Ubuntu). HTTPS puede ser más lento a través de appliances de inspección; HTTP puede estar bloqueado en algunos entornos.

Decisión: Elige el transporte que funcione de forma limpia con tu política de red; el caché funciona mejor cuando la ruta es estable.

Tarea 5: Comprueba a qué mirror realmente accedes (y si hay redirección)

cr0x@server:~$ apt-cache policy | sed -n '1,60p'
Package files:
 100 /var/lib/dpkg/status
     release a=now
 500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
     release v=24.04,o=Ubuntu,a=noble-updates,n=24.04,l=Ubuntu,c=main,b=amd64
     origin archive.ubuntu.com

Qué significa: Confirma el origen y las prioridades del repositorio.

Decisión: Si luego despliegas un caché, validarás que el origen cambie a tu host de caché.

Tarea 6: Diagnostica la latencia DNS (a menudo el verdadero culpable)

cr0x@server:~$ resolvectl status | sed -n '1,40p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.10
       DNS Servers: 10.20.0.10 10.20.0.11

Qué significa: Estás usando DNS interno. Eso está bien—hasta que está lento o filtra agresivamente.

Decisión: Si el DNS interno está sobrecargado, arréglalo o añade un resolvedor caché local por sitio.

Tarea 7: Cronometra búsquedas DNS para los mirrors

cr0x@server:~$ time getent ahosts archive.ubuntu.com | head -n 3
91.189.91.83    STREAM archive.ubuntu.com
91.189.91.83    DGRAM
91.189.91.83    RAW

real    0m0.215s
user    0m0.004s
sys     0m0.004s

Qué significa: 215 ms para una consulta no es catastrófico, pero multiplícalo por decenas de solicitudes, más reintentos y proxies, y se vuelve feo.

Decisión: Si ves >100 ms repetidamente dentro de la LAN, trata el DNS como una dependencia de producción y cáchealo localmente.

Tarea 8: Mide el tiempo de establecimiento TCP/TLS bruto

cr0x@server:~$ curl -I -s -o /dev/null -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' http://archive.ubuntu.com/ubuntu/
dns:0.021 connect:0.034 tls:0.000 ttfb:0.102 total:0.103

Qué significa: Para HTTP no hay TLS. Si haces lo mismo contra un repo HTTPS y ves un tls grande, puede que haya un proxy o caja de inspección implicada.

Decisión: La latencia se arregla con un caché en LAN porque los handshakes lentos ocurren una vez por objeto de otro modo.

Tarea 9: Revisa problemas de MTU (clásico “funciona pero lento”)

cr0x@server:~$ ip link show dev eth0 | sed -n '1,3p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Qué significa: MTU 1500 es normal. Si estás en VPN/VXLAN/PPPoE y hay MTU desajustada, puedes tener retransmisiones y bloqueos.

Decisión: Si las descargas se quedan atascadas aleatoriamente, prueba la MTU del camino y arregla el borde de red, no APT.

Tarea 10: Comprueba si APT está usando un proxy (y cuál)

cr0x@server:~$ apt-config dump | egrep -i 'Acquire::(http|https)::Proxy' | head
Acquire::http::Proxy "http://proxy.office.local:3128/";
Acquire::https::Proxy "http://proxy.office.local:3128/";

Qué significa: APT está configurado explícitamente para usar un proxy.

Decisión: Si ese proxy está en remoto (HQ) y tu oficina no, acabas de añadir RTT innecesario. Pon el caché más cerca o evita el proxy para los repositorios de Ubuntu.

Tarea 11: Confirma la alcanzabilidad del proxy y si es el punto de estrangulamiento

cr0x@server:~$ curl -s -o /dev/null -w 'proxy_connect:%{time_connect} total:%{time_total}\n' http://proxy.office.local:3128/
proxy_connect:0.003 total:0.004

Qué significa: El proxy LAN es accesible rápidamente. Si esto toma segundos, tu “proxy de oficina” no es local o está sobrecargado.

Decisión: Arregla la localidad/capacidad del proxy antes de reescribir configuraciones de APT.

Tarea 12: Inspecciona el comportamiento de reintentos/timeout de APT (síntomas de pérdida)

cr0x@server:~$ sudo apt -o Debug::Acquire::http=true update 2>&1 | egrep -i 'Connecting|Waiting|Retrying' | head -n 20
Connecting to archive.ubuntu.com (91.189.91.83)
Waiting for headers
Connecting to security.ubuntu.com (185.125.190.39)
Waiting for headers

Qué significa: Los retrasos “Waiting for headers” indican latencia del servidor/proxy, congestión o pérdida de paquetes más que límites brutos de ancho de banda.

Decisión: Despliega un caché en la LAN para reducir viajes de ida y vuelta externos; si persiste, investiga pérdida en la WAN y la sobrecarga de inspección del proxy.

Tarea 13: Valida que tienes suficiente espacio en disco para caché en el host de caché

cr0x@server:~$ df -h /var/cache | tail -n 1
/dev/sda2        200G   38G  153G  20% /var

Qué significa: Mucha capacidad para un caché de paquetes. apt-cacher-ng es eficaz incluso con almacenamiento modesto, pero no debe quedarse corto.

Decisión: Si el espacio es escaso, asigna un volumen dedicado para caché y establece una política de expulsión.

Tarea 14: Confirma que tu caché realmente sirve hits una vez desplegado

cr0x@server:~$ sudo tail -n 8 /var/log/apt-cacher-ng/apt-cacher.log
2025-12-29 10:12:41|O|171|archive.ubuntu.com|ubuntu|pool/main/o/openssl/libssl3_3.0.13-0ubuntu3.2_amd64.deb
2025-12-29 10:13:02|H|612|archive.ubuntu.com|ubuntu|pool/main/o/openssl/libssl3_3.0.13-0ubuntu3.2_amd64.deb

Qué significa: O es una obtención de origen (miss). H es un hit de caché. Los hits son donde ocurre la aceleración y el ahorro de ancho de banda.

Decisión: Si solo ves obtenciones de origen, tus clientes no apuntan al caché o el cache está deshabilitado para la ruta del repositorio.

Opciones de caché y proxy (qué desplegar)

Hay tres estrategias principales para oficinas. Cada una tiene su lugar. Dos de ellas son fáciles de complicar en exceso.

1) apt-cacher-ng en la LAN (mejor por defecto)

Qué es: Un proxy HTTP que entiende los patrones de repositorios Debian/Ubuntu y cachea paquetes y archivos de índice a medida que los clientes los solicitan.

Por qué funciona: El segundo cliente obtiene paquetes a velocidad de LAN. El cliente número 50 apenas toca la WAN.

Compromisos: Es una dependencia compartida. Si lo haces frágil, te lo harán saber. Si lo gestionas de forma rutinaria, nadie se dará cuenta—que es el mayor cumplido en operaciones.

2) Proxy HTTP genérico (Squid o proxy corporativo)

Qué es: Un proxy general que puede o no cachear contenido eficazmente, dependiendo del comportamiento HTTPS y reglas de caché.

Cuándo funciona: Si la mayor parte del tráfico de repositorios es HTTP y la política de caché del proxy es sensata.

Cuándo es dolor: Repos HTTPS más interceptación y escaneo pueden convertir APT en un documental en cámara lenta sobre handshakes TLS.

3) Mirror local completo / gestión de repositorios

Qué es: Haces mirror de repositorios de Ubuntu localmente (o ejecutas un gestor de repositorios que sincroniza contenido seleccionado).

Cuándo merece la pena: Grandes flotas, control de cambios estricto, redes casi aisladas o necesitas disponibilidad determinística durante cortes upstream.

Inconveniente: Más almacenamiento, más operaciones, más tickets “por qué este repo no está sincronizando”.

Desplegar apt-cacher-ng (recomendado para la mayoría de oficinas)

Esta es la victoria en la oficina: una pequeña VM o mini-PC por sitio, unas pocas líneas de configuración y de repente las actualizaciones dejan de ser un incidente semanal de red.

Configuración del servidor en Ubuntu 24.04

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Reading package lists... Done

Significado: El estado base es lo bastante sano para instalar paquetes.

cr0x@server:~$ sudo apt install -y apt-cacher-ng
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  apt-cacher-ng
Setting up apt-cacher-ng (3.7.4-1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/apt-cacher-ng.service → /usr/lib/systemd/system/apt-cacher-ng.service.

Significado: El servicio está instalado y habilitado.

Decisión: Decide dónde los clientes accederán al servicio (nombre DNS) y si necesitas que escuche en todas las interfaces.

Confirma que está escuchando

cr0x@server:~$ sudo ss -lntp | egrep ':3142'
LISTEN 0      4096         0.0.0.0:3142      0.0.0.0:*    users:(("apt-cacher-ng",pid=1824,fd=7))

Significado: El puerto por defecto 3142 está abierto en todas las interfaces. Si eso es demasiado permisivo para tu red, restríngelo con reglas de firewall.

Firewall básico (restringir a subredes de oficina)

cr0x@server:~$ sudo ufw allow from 10.20.0.0/16 to any port 3142 proto tcp
Rule added

Significado: Solo esa subred puede usar el caché.

Decisión: Si tienes múltiples VLAN, añade reglas explícitas por subred; no lo abras al mundo y esperes lo mejor.

Configuración del cliente: apunta APT al caché

En cada cliente Ubuntu, crea un pequeño fragmento de configuración. Usa DNS para el host cache para poder moverlo después sin visitar cada máquina otra vez.

cr0x@server:~$ echo 'Acquire::http::Proxy "http://aptcache.office.local:3142";' | sudo tee /etc/apt/apt.conf.d/02proxy
Acquire::http::Proxy "http://aptcache.office.local:3142";

Significado: Las adquisiciones HTTP usarán tu caché.

Decisión: Si tus fuentes son HTTPS, aún puedes proxificar HTTPS vía un proxy HTTP, pero prueba con tu stack de seguridad de red; algunos entornos bloquean CONNECT.

Valida que los clientes están golpeando el caché

Ejecuta update en el cliente y luego revisa los logs en el servidor de caché.

cr0x@server:~$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Fetched 126 kB in 1s (148 kB/s)
Reading package lists... Done

Significado: La salida del cliente no siempre mostrará el proxy explícitamente. La verdad está en los logs del caché.

cr0x@server:~$ sudo tail -n 5 /var/log/apt-cacher-ng/apt-cacher.log
2025-12-29 11:03:11|O|250|archive.ubuntu.com|ubuntu|dists/noble-updates/InRelease
2025-12-29 11:03:12|O|411|archive.ubuntu.com|ubuntu|dists/noble-updates/main/binary-amd64/Packages.gz
2025-12-29 11:04:02|H|7|archive.ubuntu.com|ubuntu|dists/noble-updates/InRelease

Significado: La primera solicitud se obtuvo del origen, la segunda ejecución o cliente fue hit de caché.

Decisión: Si nunca ves hits, tus clientes pueden estar evitando el proxy por configuración existente, variables de entorno o política de red.

Higiene operativa que lo mantiene rápido

• Coloca los datos del caché en un disco que no compita con logs pesados o bases de datos.
• Monitorea el uso de disco y de inodos (suceden muchos archivos pequeños).
• Planifica reinicios: asegúrate de que el servicio arranque rápido y que las reglas de firewall persistan.
• Manténlo simple. El caché no es un lugar para expresar creatividad.

Usar un proxy HTTP(S) corporativo correctamente

Algunas oficinas ya tienen un proxy corporativo. Si es local, sano y configurado para no sabotear las descargas de paquetes, puede que puedas reutilizarlo. Si es remoto (hairpin hacia HQ), a menudo es la razón por la cual APT va lento en oficinas remotas.

Decide si debes saltarte el proxy para repos de Ubuntu

Si la política lo permite, evitar el proxy para mirrors de actualización conocidos puede mejorar mucho. El enfoque correcto depende de cómo tu organización controle el egress. Si la seguridad requiere visibilidad por proxy, entonces despliega un caché/proxy en sitio y deja que haga egress de forma controlada.

Configura el proxy explícitamente (no dependas de variables de entorno)

cr0x@server:~$ sudo tee /etc/apt/apt.conf.d/02proxy >/dev/null <<'EOF'
Acquire::http::Proxy "http://proxy.office.local:3128/";
Acquire::https::Proxy "http://proxy.office.local:3128/";
EOF

Significado: APT usará el proxy independientemente del entorno del shell del usuario.

Decisión: Centraliza esto mediante gestión de configuración. Las configuraciones de proxy editadas a mano son la causa de “funciona en mi portátil” en forma de administración de sistemas.

Atento a los efectos secundarios de la interceptación TLS

Si tu proxy hace interceptación TLS, puedes observar:

• Tiempos largos de handshake TLS (el cliente espera la inspección del proxy)
• Bloqueos aleatorios en descargas grandes (buffering/escaneo de contenido)
• Errores de mismatch de hash ocasionales si la ruta es alterada (raro, pero sucede)

APT está enfocado en la integridad. Eso es bueno. También significa que cajas “útiles” que reescriben contenido no son tus amigas.

Segunda broma corta (y la última): Lo único peor que un proxy lento es un proxy lento que insiste en acelerar tu tráfico.

Mirror local completo: cuándo merece la pena (y cuándo es solo un hobby)

Un mirror completo es la opción madura para entornos grandes. Te da:

• Independencia frente a caídas upstream o mirrors inestables
• Contenido repetible (lo que probaste es lo que despliegas)
• Mejores argumentos de cumplimiento (qué estaba disponible cuándo)

También te da tareas:

• Horarios de sincronización, planificación de almacenamiento y detección de corrupción
• Gestión de claves y flujos de firmado si rehosteas o curas
• Más partes móviles que te despertarán a las 2 AM

Usa esta regla: si el problema de la oficina es “demasiadas máquinas descargan lo mismo”, apt-cacher-ng lo resuelve con mínima ceremonia. Si el problema es “necesitamos repositorios controlados y curados”, entonces construye un mirror/gestor de repositorios y acepta la carga operativa.

Ajustes en clientes que realmente ayudan

El ajuste en clientes es donde la gente pierde tiempo. Un caché/proxy da la gran ganancia. Aún así, algunos ajustes en clientes pueden reducir el dolor.

Elige un mejor mirror (pero no lo conviertas en un deporte)

Los valores por defecto de Ubuntu suelen estar bien, pero “suelen” no es una garantía de rendimiento. El mirror adecuado para tu ISP y sitio puede variar.

Método práctico: prueba dos o tres mirrors desde la oficina en horas laborales y fuera de ellas. Si un mirror es rápido a la 1 AM y lento a las 10 AM, probablemente sea congestión/peering, no tu configuración. En oficinas, quieres consistencia, no “mejor en el mejor de los casos”.

Limita sorpresas de unattended-upgrades

Los unattended upgrades son buenos. Las actualizaciones no coordinadas en todo un sitio son la forma en que descubres que tu enlace WAN no es infinito.

Escalónalas. O haz que tiren a través de un caché del sitio para que el impacto en WAN ocurra una vez.

No “optimices” deshabilitando verificaciones de firma

Si alguien sugiere omitir la verificación para que las actualizaciones sean “más rápidas”, rechaza la sugerencia como rechazarías un paracaídas usado. Las comprobaciones de integridad no son opcionales; son el punto entero de un gestor de paquetes.

Pequeñas historias corporativas de producción

Incidente: la suposición equivocada (“es el mirror”) que quemó una semana

Una empresa mediana tenía una sucursal donde las actualizaciones Ubuntu tardaban 20–40 minutos. El equipo asumió que el mirror de Ubuntu era el problema, porque un traceroute parecía “largo” y una prueba de velocidad a un sitio aleatorio estaba bien. Rotaron mirrors tres veces e incluso intentaron fijarse a un endpoint regional específico.

Nada cambió. Algunas mañanas era aceptable; las tardes eran terribles. Miseria intermitente clásica.

El verdadero culpable fue DNS. El resolver de la sucursal reenviaba todas las consultas al HQ, a través de un stack de seguridad que registraba y filtraba. Durante las horas pico, esa ruta tenía picos de latencia y timeouts ocasionales. El patrón “muchas solicitudes pequeñas” de APT hizo que pareciera un problema de mirror porque la resolución del nombre del mirror se quedaba atascada antes de que se movieran bytes.

Lo arreglaron añadiendo un resolvedor DNS caché local en la sucursal y luego desplegando apt-cacher-ng. Los cambios de mirror dejaron de ser tema. La categoría de tickets desapareció. La lección fue dolorosamente simple: no culpes al servicio que ves hasta que hayas medido la dependencia que no ves.

Optimización que salió mal: “un proxy para todos los sitios”

Otra organización consolidó todo detrás de un único proxy central para “mejor control”. Las sucursales se configuraron para usarlo para APT, navegadores, todo. El proxy tenía CPU y memoria suficientes, y su panel mostraba todo en verde. Corporativo hasta ahí.

Pero las sucursales estaban separadas por enlaces de alta latencia. El tráfico APT se convirtió en un desfile de túneles CONNECT y pequeñas obtenciones, cada una pagando la tasa RTT. Peor aún, el proxy realizaba escaneo de contenido que bufferizaba descargas antes de liberarlas, que es fantástico para malware, menos fantástico para un gestor de paquetes que tira cientos de megabytes.

Intentaron afinar la concurrencia y timeouts de APT. Eso lo volvió más ruidoso, no más rápido. Algunos clientes empezaron a expirar más a menudo porque ahora eran más agresivos estableciendo conexiones destinadas a ser lentas.

La solución fue dejar de tratar sucursales como clientes ligeros del HQ. Desplegaron un pequeño caché/proxy por sitio (aún controlado, aún registrado en el egress) y permitieron que el caché local hablara hacia afuera. El uso de WAN cayó, las quejas bajaron y el proxy central pudo hacer lo que mejor hace: aplicar políticas sin ser un ancla de rendimiento a larga distancia.

Práctica aburrida pero correcta que salvó el día: “host de caché como ganado”

Un equipo desplegó apt-cacher-ng en docenas de sitios. Hicieron algo profundamente poco sexy: estandarizaron la imagen de VM de caché, usaron el mismo puerto, las mismas reglas de firewall, la misma disposición de disco y gestionaron el snippet proxy del cliente mediante gestión de configuración.

También trataron el caché como desechable. Sin afinamientos artesanales en la caja. Si algo iba raro, lo redeployaban. Los logs se enviaban centralmente; las métricas eran básicas (uso de disco, servicio arriba, tasa de peticiones). El contenido del caché en sí no era precioso. Podía reconstruirse por uso.

Entonces un sitio tuvo un evento de energía que corrompió el disco del caché. Los usuarios empezaron a reportar actualizaciones lentas de nuevo, pero nada más estaba roto. La VM de caché se redeplegó desde la plantilla estándar en menos de una hora, DNS apuntó a la nueva instancia y los clientes siguieron. Sin heroísmos, sin llamadas nocturnas. Solo la recompensa de ser aburrido.

Errores comunes: síntoma → causa raíz → solución

1) apt update “se queda” en Connecting/Waiting for headers

Síntoma: Parece atascado y luego continúa.

Causa raíz: Lentitud DNS, sobrecarga de handshake de proxy, pérdida de paquetes o una caja de seguridad bufferizando respuestas.

Solución: Cronometra búsquedas DNS; mide connect/TTFB con curl; despliega un caché en LAN; arregla pérdida en WAN; evita proxies remotos en hairpin.

2) Las descargas empiezan rápidas y luego se ralentizan hasta casi detenerse

Síntoma: Los primeros MB van bien, luego se atasca o se vuelve errático.

Causa raíz: Problemas de MTU/PMTUD, escaneo/buffering del proxy o retransmisiones de Wi‑Fi.

Solución: Verifica MTU y sobrecarga de VPN; prueba con cable; evita o localiza el proxy; mantén el caché en LAN para reducir sensibilidad a la WAN.

3) “Hash Sum mismatch” o errores de firma de repositorio aparecen de forma intermitente

Síntoma: APT se niega a usar metadatos descargados.

Causa raíz: Proxy transparente alterando contenido, capa de caché rota sirviendo archivos parciales o inconsistencias en ventanas de sincronización del mirror.

Solución: Desactiva el caché transparente para tráfico de repos; limpia cachés del proxy para objetos afectados; cambia a un mirror estable; asegúrate de que el disco del servidor de caché esté sano.

4) Caché desplegado, pero sin aceleración

Síntoma: Los clientes siguen descargando desde Internet; los logs del caché muestran mayormente misses.

Causa raíz: Clientes no configurados, repos HTTPS que evitan caché o otro proxy que sobrescribe ajustes.

Solución: Revisa apt-config dump; estandariza el snippet en /etc/apt/apt.conf.d/; valida con logs del caché y un cliente de prueba controlado.

5) apt-cacher-ng se queda sin disco

Síntoma: El host de caché se queda sin espacio y las actualizaciones fallan.

Causa raíz: Sin plan de expulsión/limpieza, demasiados repos (incluyendo PPAs) o disco dimensionado en exceso pequeño.

Solución: Dale disco real; reduce la proliferación de repos; establece retención/limpieza; monitoriza /var/cache/apt-cacher-ng.

6) “403 Forbidden” o “Proxy Authentication Required” desde APT

Síntoma: APT falla de inmediato vía proxy.

Causa raíz: El proxy requiere autenticación, bloquea CONNECT o bloquea ciertos dominios/rutas.

Solución: Usa un caché de sitio sin autenticar; configura autenticación del proxy en APT solo si la política lo permite y puedes gestionar credenciales de forma segura; whitelist para dominios de repos.

7) Las actualizaciones son rápidas, pero las instalaciones son lentas

Síntoma: Las descargas terminan rápido; luego “Unpacking…” tarda una eternidad.

Causa raíz: Disco lento, IOPS agotadas en almacenamiento compartido, VMs con CPU limitada o triggers/postinst que hacen trabajo pesado.

Solución: Separa tiempo de descarga vs instalación; mueve VMs a mejor almacenamiento; investiga scripts postinst pesados; evita ejecutar actualizaciones en hora punta.

Listas de verificación / plan paso a paso

Paso a paso: pasa de “APT va lento” a actualizaciones rápidas en una oficina

1. Elige un cliente representativo (por cable si es posible) y ejecuta Tarea 1 y Tarea 2 para separar lentitud en metadatos/descarga/instalación.
2. Mide la latencia DNS (Tarea 6 y Tarea 7). Si DNS es lento, arréglalo primero; un caché no solucionará demoras en resolución de nombres.
3. Revisa si existe un proxy (Tarea 10). Si es remoto, planifica reemplazar el comportamiento hairpin con un caché local.
4. Despliega apt-cacher-ng en una VM pequeña en el sitio (Tarea: instalar, verificar escucha, firewall).
5. Apunta 3–5 clientes de prueba al caché vía /etc/apt/apt.conf.d/02proxy.
6. Valida hits en el caché desde los logs (Tarea 14). No declares victoria hasta ver hits.
7. Despliega la configuración de cliente mediante tooling (Ansible, Puppet, Chef, Intune scripts, lo que uses). Las ediciones manuales no escalan y no revierten limpio.
8. Escalona los horarios de actualización o mantén unattended upgrades pero asegurando que tiren a través del caché.
9. Añade monitorización básica: servicio arriba, uso de disco y una métrica simple de ratio hit/miss en logs.
10. Escribe el plan de rollback: una línea para eliminar el snippet proxy, cambio de DNS de vuelta y cómo redeployar la VM de caché.

Lista: cómo se ve “bien” después de la corrección

• apt update completa en segundos en ejecuciones repetidas.
• Los logs del caché muestran una mezcla sana de obtenciones origen y hits; los hits dominan después del primer día.
• La utilización de WAN durante ventanas de parches es más plana (no sierra de descargas repetidas).
• Ningún cliente está hardcodeado a mirrors externos aleatorios sin motivo.
• La configuración de proxy es consistente y gestionada centralmente.
• El host de caché tiene margen de disco y no está paginando.

Lista: qué evitar (porque crea nuevos problemas)

• Ejecutar un único proxy centralizado para todos los sitios salvo que cada sitio tenga enlaces de baja latencia.
• Dispositivos de caché transparentes para tráfico de repos, especialmente con HTTPS en la mezcla.
• Docenas de PPAs a lo largo de la flota. Cada uno añade solicitudes de metadatos y churn en el caché.
• “Optimizaciones” que deshabiliten comprobaciones o relajen la seguridad de APT.

Preguntas frecuentes

1) ¿Realmente necesito un servidor de caché para solo 20 máquinas?

Si esas 20 máquinas se actualizan regularmente y comparten el mismo enlace WAN, sí—especialmente si la oficina tiene latencia, ancho de banda limitado o egress costoso. apt-cacher-ng es pequeño y se paga solo en menor espera y menos picos en el enlace.

2) ¿Funcionará apt-cacher-ng con repos HTTPS?

A menudo sí, vía proxying (CONNECT). Si funciona bien depende de las políticas de proxy del entorno y de la interceptación TLS. Prueba con un par de clientes y verifica hits en los logs. Si tu stack de seguridad rompe CONNECT o fuerza interceptación, considera un mirror completo dentro del perímetro de red.

3) ¿Un mirror completo siempre es más rápido que apt-cacher-ng?

No siempre. Un mirror puede ser muy rápido, pero es más pesado operativamente. apt-cacher-ng es dirigido por las peticiones: cachea lo que tu flota realmente usa. Para la mayoría de oficinas esa es la compensación adecuada.

4) ¿Por qué apt update es lento pero la descarga de apt upgrade parece bien?

Porque apt update implica “muchos archivos pequeños” y es sensible a DNS y al tiempo de establecimiento de conexiones. Un caché en LAN ayuda mucho porque convierte esas peticiones remotas en locales.

5) ¿Debería aumentar las descargas paralelas de APT?

Solo después de haber solucionado caché y selección de mirrors. Aumentar la paralelidad puede empeorar un proxy congestionado o una WAN inestable. Mide primero; no dispares conexiones al problema.

6) ¿Puedo compartir un caché entre varias oficinas?

Puedes, pero rara vez es óptimo a menos que la latencia inter-oficinas sea baja y la red sea fiable. El objetivo es eliminar RTT de WAN del camino caliente. Pon caches cerca de los clientes.

7) ¿Y los snaps—se benefician del caché APT?

No. Las descargas snap son separadas de APT y usan otra infraestructura. Soluciona APT primero y luego evalúa proxy/caché para snaps si también causan problemas.

8) ¿Cómo sé si el proxy es el cuello de botella?

Compara tiempos con y sin proxy en un host de prueba (o temporalmente moviendo la configuración del proxy). También cronometra la conexión al proxy vs al mirror y busca “Waiting for headers” en la salida debug de APT.

9) ¿Es seguro cachear paquetes de Ubuntu?

Sí, si cacheas correctamente y no alteras el contenido. Los paquetes están firmados y validados mediante metadatos del repositorio. No uses dispositivos “transparentes” que reescriban respuestas. Mantén el host de caché parcheado y restringido a tu red.

10) ¿Cuál es la monitorización mínima que debo añadir para el servidor de caché?

Disponibilidad del servicio (systemd), uso de disco y volumen de logs. Si quieres una métrica extra, sigue la ratio de hits del caché a lo largo del tiempo; te dice si los clientes realmente lo usan.

Conclusión: siguientes pasos que puedes hacer esta semana

Si las actualizaciones de Ubuntu 24.04 son lentas en tu oficina, trátalo como cualquier otro problema de rendimiento en producción: aísla la fase, mide las dependencias y luego arregla el cuello de botella de mayor palanca. Para oficinas, ese cuello de botella suele ser la latencia por petición y las descargas duplicadas, no el ancho de banda bruto.

Haz esto, en orden:

1. Ejecuta la rutina rápida de diagnóstico en un cliente: separa metadatos vs descarga vs instalación.
2. Mide DNS y comportamiento del proxy. Si DNS es lento, arréglalo primero.
3. Despliega apt-cacher-ng en la LAN y apunta a él a los clientes mediante un snippet de configuración APT gestionado.
4. Verifica hits en los logs del caché y observa cómo la utilización WAN se aplana durante ventanas de parches.
5. Manténlo aburrido: imagen estandarizada, monitorización básica y un procedimiento simple de redeploy.

El estado final que buscas no es “APT es rápido en mi máquina”. Es “las actualizaciones son un no-evento para toda la oficina”. Ese es el tipo de mejora de rendimiento con la que puedes vivir.