Hetzner ha abierto en fase beta hcnet, su nueva pila de red para Hetzner Cloud basada en eBPF, que ya mueve todos sus balanceadores de carga y que los clientes pueden activar servidor a servidor. Un benchmark publicado el 10 de noviembre de 2026 por Cloudfleet, una plataforma de Kubernetes gestionado, muestra mejoras claras en la capacidad del cortafuegos y en túneles WireGuard, pero también una caída de entre el 39 % y el 55 % en tráfico TCP con muchos flujos hacia una sola máquina virtual.
Las claves de hcnet, la nueva red de Hetzner, en 30 segundos
- hcnet es una pila de red propia de Hetzner basada en eBPF, en beta y opcional para servidores cloud.
- El límite de conexiones del cortafuegos pasa de 80.000 compartidas a 120.000 por IPv4 y otras tantas por IPv6.
- Cloudfleet mide WireGuard entre un 18 % y un 39 % más rápido.
- El TCP con ocho flujos hacia una VM cae hasta un 55 % por un límite de la tarjeta virtual.
Hetzner describe hcnet en su documentación como su propia pila de red basada en eBPF, la tecnología del núcleo Linux que permite ejecutar pequeños programas verificados en el camino de los paquetes, y la presenta como base para futuras funciones de red. La migración empezó por los balanceadores de carga el 9 de julio de 2026, y desde el 21 de agosto todos funcionan sobre hcnet. Para los servidores cloud es opcional: se activa desde la consola, en la pestaña Networking de cada servidor, con la opción «Try new network stack», y se puede volver atrás con «Restore standard network stack». La documentación no detalla en qué ubicaciones ni tipos de servidor está disponible, ni cuándo dejará de ser beta.
Qué cambia en el cortafuegos y en la red
El cambio más visible está en Hetzner Cloud Firewall. Con hcnet, cada cortafuegos se compila como un programa eBPF independiente colocado delante de la tarjeta de red virtual de cada servidor. El límite de conexiones con seguimiento de estado sube de 80.000, compartidas entre IPv4 e IPv6, a 120.000 para cada familia, sin coste adicional. También cambia qué ocurre cuando la tabla se llena: en lugar de descartar paquetes nuevos, hcnet los evalúa solo con las reglas del cortafuegos, de modo que el tráfico permitido de forma explícita sigue pasando. Hetzner advierte de que el tráfico que dependa del seguimiento de conexiones puede verse afectado igualmente.
Hay más ajustes de menor perfil. Un único servidor DHCP propio sustituye a los dos que había para red pública y privada, el servidor de metadatos responde también en IPv6 en fe80::a9fe:a9fe a través de todas las interfaces, los errores ICMP son más precisos y hay soporte parcial de multidifusión IPv6. Los paquetes llegan a la máquina virtual tal como viajan por el cable, sin reensamblar, por lo que el número de paquetes recibidos puede aumentar aunque el ancho de banda sea el mismo. Entre las limitaciones conocidas, Hetzner cita que al cambiar de pila algunas rutas DHCP pueden tardar en actualizarse o quedarse obsoletas hasta que expire la concesión o se reinicie el servidor.
Lo que mide el benchmark de Cloudfleet
Cloudfleet probó cuatro servidores CCX23 (cuatro vCPU dedicadas AMD EPYC Milan y 16 GB de RAM) en Falkenstein, con Ubuntu 24.04 y núcleo 6.8, comparando las dos pilas por parejas de servidores e intercambiándolas después. Midió IPv4 público, IPv6 público y red privada con iperf3, netperf y ping, con tres pasadas de 10 segundos y la mediana como resultado, e hizo una comprobación aparte con dos CPX42 compartidos de ocho vCPU.
Las mejoras se concentran en la capacidad de conexiones: 1,4 veces más en IPv4 y hasta 2,7 veces si se suman IPv4 e IPv6. La recuperación tras llenarse la tabla pasa de entre 44 y 64 segundos a entre 0 y 3, unas 20 veces más rápida. El rendimiento de un túnel WireGuard con cuatro flujos sube entre un 18 % y un 39 %, y la latencia p99 de peticiones TCP en IPv4 público baja entre un 13 % y un 21 %. La latencia mediana apenas cambia, y un único flujo TCP tampoco muestra diferencias consistentes.
La regresión está en el tráfico masivo con varios flujos hacia una misma VM: con ocho flujos TCP, el rendimiento cae entre un 39 % y un 50 % en CCX23 y en torno a un 55 % en CPX42. Según Cloudfleet, la causa es que la tarjeta virtual virtio tiene una sola cola de recepción, así que una única vCPU acaba haciendo de cuello de botella, y la solución pasaría por tarjetas virtio con varias colas, algo que la empresa espera que Hetzner añada. Es su interpretación; Hetzner no la ha comentado en la documentación.
Los resultados tienen límites que Cloudfleet reconoce: una sola ubicación, sin instancias Arm, diferencias por debajo del 10 % dentro del ruido y algunos datos descartados por variar demasiado entre parejas de servidores. Además, al ser una beta, el comportamiento puede cambiar. También conviene tener en cuenta que Cloudfleet ofrece Kubernetes gestionado sobre proveedores como Hetzner, por lo que su interés está en los escenarios de nodos con muchas conexiones, donde hcnet sale mejor parado.
Para quien quiera probarlo, la recomendación de ambas fuentes es hacerlo en una ventana de mantenimiento: activar o desactivar hcnet corta brevemente la conectividad y, si hay un cortafuegos asignado, puede cerrar las conexiones existentes. La nueva red llega en un año en el que Hetzner también ha subido precios y simplificado su catálogo de servidores, y la ampliación del límite de conexiones no tiene coste extra.
Preguntas frecuentes
¿Qué es hcnet de Hetzner?
La nueva pila de red de Hetzner Cloud basada en eBPF. Mueve todos los balanceadores de carga desde agosto de 2026 y está en beta opcional para servidores.
¿Cómo se activa hcnet?
En la consola de Hetzner, pestaña Networking del servidor, opción «Try new network stack». Provoca un breve corte de conectividad.
¿Cuántas conexiones admite el cortafuegos con hcnet?
120.000 para IPv4 y otras 120.000 para IPv6, frente a 80.000 compartidas en la pila estándar.
¿Empeora algo el rendimiento?
Según Cloudfleet, el TCP con ocho flujos hacia una sola VM cae entre un 39 % y un 55 %, porque la tarjeta virtual tiene una sola cola de recepción.
Fuentes:
