En git.kernel.org hay ahora catorce núcleos de CPU, repartidos en cinco nodos geodistribuidos, dedicados full-time a una sola tarea: convertir commits del kernel de Linux en HTML que ningún humano va a leer. Lo reveló Konstantin Ryabitsev, el administrador de la infraestructura git del kernel, el 29 de agosto de 2026, con una cifra que resume el problema de fondo: la plataforma gasta más ciclos de procesador sirviendo a crawlers de IA que en todo el resto del tráfico legítimo junto, git clones incluidos.
No es una anécdota aislada. Es el último capítulo de una guerra de desgaste que lleva más de un año entre los administradores de infraestructura open source y los crawlers de IA que alimentan a los modelos de lenguaje.
TL;DR
- El 29 de agosto de 2026, Konstantin Ryabitsev publicó cifras duras sobre el impacto de los crawlers de IA en git.kernel.org.- git.kernel.org dedica 14 núcleos de CPU en 5 nodos geodistribuidos solo a renderizar commits en HTML para scrapers.- linux.git tiene cerca de 1,48 millones de commits y 922 forks en git.kernel.org, miles de millones de URLs escaneables.- Los bots pasaron de mentir con el user-agent a usar IPs residenciales y móviles vía proxy SDK monetization.- Anubis, el proxy de proof-of-work con SHA-256, frenó a los bots meses hasta que empezaron a resolver dificultad 5.- cgit permite generar hasta 1,2 billones de URLs válidas por fork, con diffs y patches entre commits arbitrarios.- GNOME y VideoLAN también adoptaron Anubis para frenar el mismo tipo de rastreo agresivo de crawlers de IA.
Qué pasó
Ryabitsev publicó en su blog personal un desglose técnico de lo que llama la 'radiación de fondo': una carga constante de peticiones automatizadas que consume capacidad de cómputo sin ningún beneficio para el proyecto. El dato central es contundente: git.kernel.org quema más CPU renderizando commits en HTML para bots que atendiendo todo el tráfico humano y automatizado legítimo combinado.
El repositorio de Linux (linux.git) acumula cerca de 1,48 millones de commits. A eso hay que sumarle 922 forks alojados en git.kernel.org, que en el backend comparten casi todos los mismos objetos de git (el almacenamiento es eficiente), pero que para un scraper representan 922 copias distintas del mismo historial para rastrear desde cero.
El resultado, según Ryabitsev, es que un solo fork de linux.git puede generar del orden de 1,2 billones de URLs válidas, porque cgit, el visor web de git que usa kernel.org, no solo permite ver cada commit por separado: también genera parches, diffs entre cualquier par de commits arbitrarios y renders planos bajo demanda.
922 forks de linux.git multiplican las URLs escaneables por scraper.
Por qué git.kernel.org es un blanco perfecto para los crawlers de IA
Para un modelo de lenguaje, el historial de Linux es una mina de oro de datos de entrenamiento por un motivo muy específico: está garantizado libre de contenido generado por IA. Todo el desarrollo del kernel ocurre en abierto, desde los repositorios clonables hasta los archivos de las listas de correo, y gran parte de ese historial es anterior a la explosión de los LLM.
💭 Clave: entrenar un modelo con texto generado por otro modelo produce degradación acumulada, comparada por algunos investigadores con una enfermedad priónica digital. Por eso una fuente garantizada 'pre-IA', como el historial completo de commits del kernel, vale su peso en oro para cualquier laboratorio que entrena modelos nuevos.
Lo llamativo es que la forma más eficiente de aprovechar ese dato ya existe: clonar los repositorios con git clone y recorrer el historial commit por commit, localmente, sin tocar los servidores del proyecto más de lo necesario. Es justo lo que sugiere Ryabitsev en su publicación: se puede clonar la totalidad de LKML y después hacer lo que se quiera con eso. Pero los crawlers, en su inmensa mayoría, eligen la ruta más costosa: pedirle a cgit que renderice cada commit como página HTML, uno por uno, para después parsear ese HTML.
Contexto e historia: de banear user-agents a fingir ser tu TV
La respuesta inicial de kernel.org fue la más simple: revisar los logs, identificar qué IPs se comportaban como bots evidentes y banearlas con fail2ban. Al principio funcionaba porque los bots se identificaban con su propio user-agent en la cabecera HTTP.
Luego los bots empezaron a mentir, haciéndose pasar por navegadores comunes. El equipo pasó entonces a banear por IP: era fácil detectar que una dirección pidiendo cada commit posible de un fork abandonado hace ocho años no era un usuario de Chrome haciendo clic manualmente. Cuando los bots se repartieron en subredes completas alquiladas a proveedores cloud, kernel.org empezó a banear el ASN entero, aun sabiendo que ocasionalmente eso atrapaba a algún usuario legítimo automatizando la verificación de links en commits.
El punto de quiebre llegó cuando los crawlers empezaron a operar desde millones de IPs residenciales y móviles distintas, cada una simulando un navegador moderno, haciendo apenas 4 o 5 peticiones antes de desaparecer para siempre de los logs. Banear esas direcciones no servía de nada: para cuando el equipo detectaba el patrón, el bot ya se había ido y no iba a volver desde esa misma IP. Ryabitsev lo describe como un enjambre de langostas: golpean fuerte y rápido hasta tumbar el sistema, se mudan al siguiente objetivo y vuelven más tarde a repetir el ciclo.
Ese tráfico proviene de lo que la industria llama 'proxy SDK monetization': empresas que pagan a desarrolladores de apps, incluidas apps para smart TVs, por integrar un SDK que convierte el dispositivo del usuario final en un nodo de una red de proxies residenciales, sin que ese usuario final sepa que su TV o su celular está siendo usado para rastrear git.kernel.org a las tres de la mañana.
Detalles técnicos y rendimiento: Anubis y la carrera de dificultad
Hace aproximadamente un año, kernel.org probó una estrategia distinta: en lugar de identificar y bloquear, cambiar la economía del ataque. La idea es simple: obligar a cada cliente a resolver un problema matemático desechable antes de dejarlo pasar, algo barato para un humano ocasional y costoso para un scraper que necesita completar miles de millones de peticiones.
Esa es la lógica detrás de Anubis: un proxy inverso que antepone un reto de prueba de trabajo a cada visitante nuevo. El desafío consiste en encontrar una cadena que, combinada con la IP del cliente y un secreto del servidor, produzca un hash SHA-256 con una cantidad determinada de ceros iniciales. Cuantos más ceros exige el servidor (la 'dificultad'), más intentos de fuerza bruta necesita el cliente para encontrar una solución válida.
Al desplegarlo, el efecto fue inmediato: los bots simplemente se rindieron y migraron a blancos más fáciles. Durante varios meses hubo una paz relativa: los usuarios legítimos notaban una demora mínima y tolerable, y el stack de Anubis era sencillo de desplegar en cualquier servicio detrás de un proxy inverso.
La paz duró poco. Meses después, los bots volvieron resolviendo dificultad 4. Kernel.org subió a dificultad 5, lo que en un dispositivo móvil implica varios segundos de cómputo intensivo y, según reporta Ryabitsev, calienta perceptiblemente el teléfono mientras resuelve el reto. Funcionó de nuevo, por un tiempo. Pero los crawlers terminaron resolviendo también dificultad 5.
EstrategiaCuándo usarlaVentajaLimitaciónBloqueo por user-agentBots que se identifican honestamenteTrivial de implementarInútil en cuanto el bot falsea la cabeceraBloqueo por IPBots desde direcciones fijas y reincidentesEfectivo contra scrapers poco sofisticadosNo sirve si el bot no vuelve a usar la misma IPBloqueo por ASNTráfico masivo desde un mismo proveedor cloudCorta de raíz rangos completosPuede bloquear también a usuarios legítimos del mismo proveedorAnubis (proof-of-work)Bots con proxies residenciales rotativos, imposibles de listarEncarece cada petición sin depender de listas negrasCada aumento de dificultad también penaliza a usuarios en móviles modestosAnubis exige resolver un hash SHA-256 antes de servir el contenido real.
flowchart TD
A["Cliente (browser o bot)"] --> B["Anubis: reto proof-of-work"]
B -->|"resuelve sha256 con N ceros"| C["cgit / git.kernel.org"]
B -->|"no resuelve o abandona"| D["Bloqueado, sin acceso"]
C --> E[("Commits de linux.git")]
Cómo probar Anubis en tu propio servidor
Si administrás un git server, un wiki o cualquier servicio con contenido interesante para un LLM, podés desplegar Anubis hoy mismo delante de tu backend, sin tocar el código de la aplicación protegida. Anubis corre como un proxy inverso independiente, así que solo necesitás redirigir el tráfico hacia él en vez de directamente al servicio.
docker run -d \
--name anubis \
-p 8923:8923 \
-e BIND=:8923 \
-e TARGET=http://localhost:80 \
-e DIFFICULTY=5 \
ghcr.io/techarohq/anubis:latest
Ese comando levanta Anubis escuchando en el puerto 8923, reenviando el tráfico ya filtrado hacia tu backend real en el puerto 80, con dificultad 5. Ajustá DIFFICULTY según cuánto tráfico automatizado estés viendo: subirlo demasiado rápido castiga a tus usuarios legítimos en móviles antes de frenar a los bots más persistentes.
Después, en tu proxy de borde (nginx, Caddy o el que uses), apuntá el server_name hacia el puerto de Anubis en vez de hacia el backend original:
server {
listen 443 ssl;
server_name git.midominio.org;
location / {
proxy_pass http://127.0.0.1:8923;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Para confirmar que Anubis está realmente intermediando el tráfico, pedí la página con curl y fijate en las cabeceras de respuesta: un visitante nuevo sin cookie válida debe recibir el desafío de JavaScript embebido, no el contenido real del sitio.
curl -sI https://git.midominio.org | grep -i set-cookie
Si ves una cookie relacionada con Anubis en la respuesta, el proxy está activo y filtrando antes de llegar al backend.
Impacto y análisis
El caso de kernel.org no es único. GNOME y VideoLAN atravesaron el mismo problema y también terminaron adoptando Anubis para frenar el rastreo agresivo de bots de IA sobre su infraestructura, un patrón que confirma que el fenómeno no depende del stack tecnológico ni del tamaño del proyecto: cualquier repositorio de código abierto con historial extenso es un blanco.
El costo real no es solo el de la factura de cómputo. Es el tiempo de ingeniería que un proyecto mantenido en gran parte por voluntarios tiene que dedicar a una carrera armamentista contra empresas de proxy SDK monetization que monetizan el ancho de banda de smart TVs ajenas. Ese tiempo no se invierte en revisar parches del kernel ni en mejorar la infraestructura para los desarrolladores reales.
⚠️ Ojo: subir la dificultad de Anubis mejora el bloqueo, pero también empeora la experiencia de usuarios legítimos en dispositivos móviles, cuyo teléfono se calienta perceptiblemente mientras resuelve el reto.
Hay además una asimetría económica de fondo: para el operador del crawler, cada petición cuesta prácticamente cero porque corre sobre un dispositivo residencial ajeno pagado por otro. Para kernel.org, cada petición cuesta CPU real, en servidores reales, con una factura real. El proof-of-work de Anubis intenta revertir esa asimetría trasladando el costo de vuelta al cliente, pero solo funciona mientras al bot le resulte más barato desistir que resolver el desafío.
Qué sigue
La siguiente movida obvia, subir a dificultad 6, ya está sobre la mesa, pero cada escalón adicional castiga más a los usuarios legítimos en hardware modesto antes de disuadir al scraper mejor financiado. Ryabitsev no ofrece en su publicación una solución definitiva: documenta un problema que la comunidad de infraestructura open source todavía está resolviendo en tiempo real.
Es probable que veamos más proyectos migrar de listas negras reactivas a mecanismos de costo computacional como Anubis, y que la propia industria de proxy SDK monetization se vuelva un blanco de presión entre operadores de infraestructura, de forma parecida a como hoy ya se comparten listas de IPs maliciosas.
📖 Resumen en Telegram: Ver resumen
Probalo vos: cloná linux.git con git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git y compará cuánto tarda esa única operación contra la carga que le impondría a un servidor rastrear cada commit uno por uno vía HTTP.
Preguntas frecuentes
¿Qué es Anubis y por qué usa proof-of-work?
Es un proxy inverso open source que antepone un desafío criptográfico a cada visitante nuevo antes de dejarlo llegar al servicio real. Resolver el desafío es barato para un usuario ocasional, pero costoso a escala para un scraper que necesita completar millones de peticiones.
¿Por qué los crawlers no simplemente clonan el repositorio con git clone?
Sería la forma más eficiente, pero la mayoría de los bots analizados por Ryabitsev prefieren pedirle a cgit que renderice cada commit como página HTML y después parsear ese HTML, un método mucho más costoso tanto para el bot como para el servidor.
¿Qué es la 'proxy SDK monetization' que menciona el artículo?
Es un modelo de negocio en el que empresas pagan a desarrolladores de apps, incluidas apps de smart TVs, por integrar un SDK que convierte el dispositivo del usuario final en un nodo de una red de proxies residenciales, usada después para rastrear sitios sin que el dueño del dispositivo lo sepa.
¿Cuántos commits y forks tiene que atender git.kernel.org?
linux.git acumula cerca de 1,48 millones de commits, y git.kernel.org aloja 922 forks del repositorio, la mayoría compartiendo los mismos objetos de git en el backend pero representando blancos separados para un scraper.
¿Puedo instalar Anubis en mi propio servidor Git o wiki?
Sí. Anubis corre como contenedor Docker independiente y se coloca delante de cualquier backend HTTP mediante tu proxy inverso habitual, sin requerir cambios en la aplicación protegida.
¿Qué otros proyectos open source enfrentaron el mismo problema?
GNOME y VideoLAN documentaron públicamente haber adoptado Anubis para frenar el rastreo agresivo de crawlers de IA sobre su infraestructura, confirmando que el patrón se repite en distintos ecosistemas de software libre.
Referencias
- Creepy crawlies, Konstantin Ryabitsev: el artículo original con las cifras de carga de git.kernel.org.- Repositorio de Anubis en GitHub: código fuente y documentación del proxy de proof-of-work.- git.kernel.org: la instancia de cgit que aloja linux.git y sus forks.- Web scraping, Wikipedia: contexto general sobre técnicas de rastreo automatizado.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
