Deja de probar en redes perfectas: Túneles de caos y la nueva disciplina de degradación de redes locales

Cuando desarrollas localmente, tus solicitudes fetch() no cruzan internet. Están alcanzando una interfaz de loopback con cero jitter, sin congestión y sin interferencias de señal. En este entorno estéril, las condiciones de carrera permanecen ocultas, tus indicadores de carga parecen perfectos porque solo parpadean por una fracción de segundo, y tu lógica de reintento nunca realmente vuelve a intentar nada. Luego, lanzas a producción — y la realidad golpea.

Construir software en un localhost de latencia cero es como probar un submarino en una bañera. Los componentes funcionan en aislamiento, pero no aprendes nada sobre cómo sobreviven a la presión real. Este es el problema que la ingeniería del caos en localhost resuelve.

Implementando lo que ahora llaman “Túneles de caos” — proxies que degradan intencionadamente tu conexión local — puedes realizar pruebas de estrés en el manejo de errores, gestión de estado y lógica de reintento antes de que una sola línea de código llegue a producción.

---

La red real no se parece en nada a localhost

Antes de profundizar en las herramientas, vale la pena fundamentar esto en datos. Una investigación comparando redes públicas 5G Standalone (SA) y No-Standalone (NSA), publicada en febrero de 2026, encontró que la NSA 5G pública mostraba una latencia de aproximadamente 54 ms en promedio — con jitter casi diez veces mayor que una red privada SA, y picos ocasionales de más de 50 ms por encima de la mediana.

¿Tu viaje de ida y vuelta en localhost? Menos de milisegundo. Esa brecha — entre el ciclo estéril de 127.0.0.1 y la realidad hostil de una red móvil pública — es donde nacen los bugs y se destruye la confianza del usuario.

La ingeniería del caos es la disciplina de cerrar esa brecha deliberadamente, en experimentos controlados, antes de que los usuarios la encuentren en el mundo real.

---

Las herramientas: lo que realmente se usa en 2026

Toxiproxy: el caballo de batalla

La herramienta más adoptada para degradación de redes locales sigue siendo Toxiproxy, un framework proxy TCP originalmente desarrollado por Shopify para probar la resiliencia de su infraestructura. Según un estudio académico de 2025 analizando la adopción en GitHub en 971 repositorios, Toxiproxy, Chaos Mesh y Chaos Monkey de Netflix representan colectivamente más del 64% de todos los repositorios que usan herramientas de ingeniería del caos — haciendo de Toxiproxy una de las tres herramientas más usadas en el ecosistema.

Toxiproxy es independiente del lenguaje, se distribuye como un binario en Go, y expone una API de gestión HTTP que facilita su control desde código de prueba o scripts de CI.

Configurar un túnel de caos es sencillo. Supón que tu API backend corre en localhost:3000. Creas un túnel proxy en localhost:4000 que enruta a través de Toxiproxy, y luego inyectas “toxics” — el término de la librería para condiciones de fallo configurables — en ese tráfico:

# Iniciar el servidor Toxiproxy (el plano de control corre en el puerto 8474)
toxiproxy-server

# Crear un túnel proxy desde el puerto 4000 → tu API en el puerto 3000
toxiproxy-cli create mi_api -l localhost:4000 -u localhost:3000

# Inyectar latencia de 1000ms con jitter de 500ms — simulando una conexión 4G congestionada
toxiproxy-cli toxic add -t latency -a latency=1000 -a jitter=500 mi_api

# O cortar completamente la conexión — simulando un fallo en la base de datos
toxiproxy-cli toxic add -t timeout -a timeout=0 postgres_proxy

Toxiproxy soporta múltiples tipos de toxics de forma nativa: latency, bandwidth (limitación de ancho de banda), slow_close (simula conexiones que se cuelgan antes de cerrar), reset_peer (resets TCP abruptos), y limit_data (cortar la conexión después de N bytes). Cada uno puede aplicarse en la dirección upstream o downstream de forma independiente.

Integración con Testcontainers: Herramientas como Testcontainers ahora ofrecen módulos nativos de Toxiproxy para Java, Node y Python. Esto permite levantar una base de datos real en Docker, envolverla en un proxy de caos, escribir una prueba que ejecute una consulta, cortar intencionadamente la red a mitad de la query, y verificar que la aplicación lanza el error correcto — todo en un pipeline automatizado de CI/CD, sin configuración manual.

Trixter: la alternativa más moderna basada en Rust

Una alternativa emergente para equipos que buscan mayor rendimiento y configuración más sencilla es Trixter, lanzada en octubre de 2025. Escrito en Rust usando el framework async Tokio, es un proxy de caos de alto rendimiento diseñado para inyectar fallos en la red a nivel TCP. A diferencia de tc netem (control de tráfico a nivel kernel en Linux), Trixter no requiere privilegios root ni configuraciones especiales de red — simplemente apuntas tu servicio a la dirección del proxy y solo ese tráfico recibe el caos.

Trixter también es ajustable en tiempo de ejecución: puedes modificar los parámetros de fallo en vivo por conexión sin reiniciar el proxy, mediante una API REST sencilla. Su binario pesa 3.3MB, facilitando su incorporación en cada ejecución de suite de pruebas. Para pods en Kubernetes, laptops de desarrollador en macOS/Windows, y pipelines de CI donde no hay acceso root, esto representa una ventaja significativa frente a la aproximación basada en tc.

# Ejecutar Trixter como proxy: escuchar en 8080, reenviar al servicio upstream en 3000
# Con tasa de terminación de conexión del 1% y tasa de corrupción de paquetes del 1%
docker run --network host -it --rm ghcr.io/brk0v/trixter \
  --listen 0.0.0.0:8080 \
  --upstream 127.0.0.1:3000 \
  --api 127.0.0.1:8888 \
  --terminate-probability-rate 0.001 \
  --corrupt-probability-rate 0.01

Este patrón hace que el caos sea determinista y reproducible — esencialmente pruebas basadas en propiedades para tu capa de red.

---

Caos a nivel de capa de aplicación: manipulación HTTP

Los proxies TCP son excelentes para degradar la red en bruto. Pero el desarrollo moderno de UI también requiere caos a nivel de capa de aplicación (Capa 7) — manipular el tráfico HTTP en sí, no solo la conexión subyacente.

Los equipos ahora construyen o usan Agentes Proxy de Caos personalizados que se colocan justo delante del API local. Estos proxies pueden mutar inteligentemente el tráfico HTTP de formas que un proxy TCP no puede.

La ruleta 502. Configura el proxy para devolver aleatoriamente 502 Bad Gateway en el 15% de las mutaciones de GraphQL. Esto obliga al desarrollador frontend a implementar lógica de reintento automática robusta — típicamente con backoff exponencial y jitter — y a verificar que la UI muestra un error significativo en lugar de fallar silenciosamente.

El 401 silencioso. Un fallo arquitectónico persistente es cómo las apps manejan la expiración del token de autenticación. Cuando una API devuelve 401 Unauthorized en medio de una sesión, las apps mal diseñadas redirigen abruptamente al usuario a la pantalla de login, destruyendo cualquier estado no guardado del formulario. Un proxy de caos puede interceptar una solicitud válida, eliminar el encabezado Authorization, y forzar un 401. Esto permite al desarrollador ajustar su lógica de “refresco silencioso”: capturar el 401, pausar la cola de solicitudes salientes, obtener un token nuevo en segundo plano usando el refresh token, reintentar la solicitud fallida, y permitir que el usuario continúe sin notar nada. Sin inyectar este escenario localmente, esa lógica es casi imposible de probar de forma confiable.

Fuzzing de respuestas. Proxies más avanzados — incluyendo la API de Proxy de Caos anunciada en diciembre de 2025 para pipelines de CI/CD — pueden manipular automáticamente los cuerpos JSON de respuesta para mostrar cómo se comporta la aplicación cuando recibe datos malformados. Esto es especialmente valioso para probar cómo los analizadores y mappers de datos manejan cambios inesperados en el esquema de APIs de terceros.

---

Integrando el caos en pruebas E2E con Playwright

Quizá el cambio más importante en 2025-2026 es que las pruebas de caos han salido de los flujos manuales de los desarrolladores y ahora están integradas en pipelines automatizados de CI/CD, directamente con frameworks de pruebas E2E como Playwright y Cypress.

La API page.route() de Playwright permite interceptar la red a nivel del navegador, simulando condiciones degradadas en rutas específicas durante los recorridos reales del usuario — sin necesidad de proxies externos.

// Prueba en Playwright: la compra debe sobrevivir a un timeout de red
test('La compra sobrevive a una caída repentina de red', async ({ page }) => {
  await page.goto('/checkout');
  await page.fill('#credit-card', '4242 4242 4242 4242');

  // Interceptar la llamada a la API de pago y simular un timeout de 10 segundos
  await page.route('**/api/payment', async route => {
    await new Promise(f => setTimeout(f, 10000));
    route.abort('timedout');
  });

  await page.click('#submit-payment');

  // Verificar que la UI maneja el timeout correctamente:
  // sin fallos, sin doble envío
  await expect(page.locator('#payment-status')).toHaveText('Red lento. Reintentando de forma segura...');
  await expect(page.locator('#submit-payment')).toBeDisabled();
});

Este tipo de prueba valida que un recorrido crítico — el flujo de pago — sobreviva a fallos de red sin pérdida de datos ni doble cobro. Se ejecuta en CI en cada pull request y detecta regresiones automáticamente.

Más allá de fallos de red, los equipos usan Playwright para simular expiración de tokens en medio del proceso (el escenario del 401 silencioso mencionado arriba), respuestas API malformadas durante el envío de formularios, y cargas parciales de página donde algunos recursos sí y otros no.

---

Lo que la ingeniería del caos obliga a que tu UI haga bien

Implementar un Túnel de Caos local no es solo para detectar bugs. Produce un cambio fundamental en cómo los ingenieros de UI piensan en la arquitectura.

1. UI optimista — con retrocesos honestos

Cuando los desarrolladores experimentan constantemente timeouts en la API local, dejan de esperar a que el servidor responda antes de actualizar la UI. Implementan UI optimista: renderizan inmediatamente el corazón “me gusta” o el comentario “publicado”, y luego reconcilian con la respuesta del servidor. Sin embargo, como un proxy de caos eventualmente forzará que esa solicitud falle, el desarrollador se ve obligado a construir el mecanismo de rollback — revertir el estado de la UI y mostrar una notificación no intrusiva cuando la red se caiga definitivamente. Sin pruebas de caos, esa ruta de rollback rara vez se escribe y aún menos se prueba.

2. Idempotencia como predeterminado, no como afterthought

Si un Túnel de Caos introduce jitter severo, una solicitud puede tardar tanto que el frontend asuma que falló y reintente — enviando la misma acción dos veces. Si el desarrollador no ha implementado claves de idempotencia (tokens únicos adjuntos a las solicitudes para que el servidor sepa no procesar la misma acción dos veces), verá inmediatamente entradas duplicadas en su base de datos local. El proxy de caos se convierte en un enforceador estricto del correcto diseño de API. Como señala una guía práctica, en sistemas distribuidos, la idempotencia no es opcional — es fundamental.

3. El fin del spinner infinito

Nada erosiona más la confianza del usuario que un spinner de carga que nunca desaparece porque un paquete se perdió y una Promise nunca se resolvió. Al inyectar pérdida de paquetes y toxics de cierre lento en conexiones localmente, los desarrolladores aprenden a establecer timeouts agresivos en el cliente. Si una API no responde en 8 segundos, la UI aborta la solicitud y ofrece un botón claro de “Reintentar”. Este patrón — afirmar el estado de carga, afirmar un timeout, afirmar la opción de reintentar — puede codificarse en pruebas de Playwright y ejecutarse en cada commit.

4. Flujos de checkout y pago con gracia

La ingeniería del caos es especialmente crítica en comercio electrónico. Simular timeouts en pasarelas de pago, respuestas inválidas de códigos de descuento, o fallos en la verificación OTP, obliga a la UI a manejar estos casos explícitamente: mantener los contenidos del carrito, mostrar mensajes de error accionables, y prevenir envíos duplicados de pago. Estos son los modos de fallo que causan pérdidas financieras reales y abandono de usuarios en producción, pero que casi nunca se prueban en entornos de desarrollo con red local perfecta.

---

Un punto de partida práctico

Empezar no requiere un cambio de infraestructura elaborado. Aquí tienes un flujo mínimo que cualquier equipo frontend puede adoptar hoy:

1. Instala Toxiproxy (brew install toxiproxy en macOS, o descarga el binario). Inicia toxiproxy-server.
2. Crea un proxy apuntando a tu backend local. Configura tu frontend de desarrollo para usar el puerto del proxy en lugar del backend real.
3. Escribe un toxico por cada modo de fallo que te importe: latencia para condiciones de red lentas, timeout para conexiones caídas, limitación de ancho de banda para simular 3G.
4. Agrega una prueba en Playwright usando page.route() para verificar que el recorrido más crítico — checkout, autenticación, envío de formulario — sobreviva a un timeout sin fallar ni enviar doble.
5. Ejecuta esa prueba en CI en cada pull request.

Empieza con el modo de fallo más costoso en tu producto. Para un SaaS, probablemente sea el flujo de pago. Para una app social, la creación de publicaciones. Para un producto de datos, la exportación o generación de reportes.

---

Conclusión: Abraza la red hostil

En un mundo distribuido y móvil, un localhost de latencia cero es una fantasía que perjudica activamente la calidad del software. Las redes 5G reales muestran jitter en un orden de magnitud mayor que las redes privadas controladas. Los usuarios reales envían formularios mientras viajan en trenes, túneles, cambian de Wi-Fi a celular, o están en edificios con señal degradada. Su experiencia no se mide en milisegundos — sino en frustración, pérdida de datos y sesiones abandonadas.

Implementando Túneles de Caos — ya sea a través de la API de toxic de Toxiproxy, el proxy ligero en Rust de Trixter, o la interceptación de rutas integrada en Playwright — los equipos de desarrollo pueden desmantelar sistemáticamente la ilusión de conectividad perfecta. Probar picos de latencia localmente, inyectar errores 502 aleatorios, cortar conexiones a mitad de vuelo: ya no son ejercicios niche de SRE. Son el requisito básico para un desarrollo de UI que se lanza con confianza.

Rompe tu entorno local hoy, para que tu aplicación no se rompa para tus usuarios mañana.