Hysteria 2: análisis completo del protocolo, diferencias con Hysteria 1, configuración de servidor y cliente

Introducción

En los últimos años, los sistemas de bloqueo y análisis profundo de paquetes se han vuelto más precisos, agresivos y astutos. Las VPN tradicionales basadas en TCP cada vez pierden más velocidad y previsibilidad, especialmente en redes móviles y saturadas. En este contexto, Hysteria 2 se ha consolidado como uno de los transportes más prácticos para un túnel resistente sobre QUIC/UDP: arranque rápido, alta tolerancia a pérdidas, ocultación efectiva y administración sencilla. En este artículo exploraremos la arquitectura del protocolo, las diferencias clave con Hysteria 1, las mejores prácticas para configurar servidores y clientes, además de listas de verificación, optimización y casos reales.

Qué obtendrás: un modelo mental claro de Hysteria 2, configuraciones y pasos comprobados, herramientas de diagnóstico, estrategias para evadir DPI y respuestas detalladas a dudas complejas. Nuestra meta es que este texto sea tu referencia principal sobre Hysteria 2 «de la práctica para la práctica».

Conceptos básicos

¿Qué es Hysteria 2 y por qué QUIC/UDP?

Hysteria 2 es un túnel de alto rendimiento sobre QUIC/UDP con autenticación, cifrado TLS 1.3 y ofuscación opcional. A diferencia de las VPN basadas en TCP, QUIC opera sobre UDP, implementando control de congestión y entrega confiable en espacio de usuario. En la práctica esto significa: arranques más rápidos, menos bloqueos por pérdida de paquetes, mejor rendimiento en redes inestables y sin los problemas de restauración lenta típicos de sesiones TCP largas.

Fortalezas destacadas de Hysteria 2

• Redes con alta latencia y pérdida (móviles, Wi‑Fi en ambientes saturados).
• Evasión de DPI orientado a firmas TCP, huellas TLS y patrones de comportamiento no usuales.
• Escenarios con muchas solicitudes cortas: rápido calentamiento del pipeline y menor overhead.

Diferencias entre Hysteria 2 y Hysteria 1

• Modelo de transporte: Hysteria 1 soportaba modos adicionales de camuflaje (como faketcp), mientras que Hysteria 2 se centra en un QUIC/UDP limpio y de calidad, minimizando artefactos detectables.
• Pureza del protocolo: mayor compatibilidad con comportamiento estándar de QUIC y TLS 1.3, lo que reduce la probabilidad de detección de características específicas del transporte.
• Ofuscación: en Hysteria 2 se aplica una ofuscación ligera antes del handshake TLS (por ejemplo, el modo 'salamander') para ocultar señales al DPI antes de establecer cifrado.
• Modelo de autenticación: simplificado, basado en contraseñas/tokens, mejor adaptado para escenarios multiusuario.
• Rendimiento: parámetros de control de congestión y buffering actualizados según experiencia práctica; heurísticas mejoradas para estimación inicial del ancho de banda.
• Camuflaje/mascarada: es más sencillo configurar respuestas plausibles para escáneres aleatorios, reduciendo riesgo de bloqueo específico por puerto.

Exploración profunda

Pila de protocolos de Hysteria 2

• UDP como transporte base: minimiza problemas de bloqueo por cabeza de línea, independencia de la máquina de estados TCP en dispositivos de red.
• QUIC: aporta cifrado a nivel de transporte, control independiente de congestión, multiplexación de flujos sin bloqueo global.
• TLS 1.3 sobre QUIC: handshakes rápidos, reanudación de sesiones, conjuntos de cifrado compactos, fuga limitada de metadatos. Generalmente visible solo SNI, salvo uso de ECH (aún poco extendido en práctica).
• Ofuscación previa a TLS: capa ligera para que el tráfico inicial sea menos predecible para DPI, reduciendo la detección por firmas antes de establecer canal seguro.

Autenticación y modelo de acceso

Práctica estándar: contraseña/token simétrico, único o grupos para varios usuarios. Esto baja la complejidad de despliegue y facilita integración en múltiples plataformas (PC y móviles). Cambiar contraseña es sencillo, ideal para rotaciones regulares.

Algoritmos y parámetros de rendimiento

• Estimación inicial de ancho de banda (subida/bajada): defines la capacidad esperada del cliente; el transporte usa esta guía para ventana y velocidad, reduciendo oscilaciones en el pipeline.
• MTU y fragmentación: QUIC exige 1200 bytes mínimo para MTU inicial. En rutas problemáticas conviene limitar tamaño de datagramas en cliente (por ejemplo, 1200 bytes) para evitar agujeros PMTU.
• Keepalive: envíos mínimos periódicos mantienen activo el estado NAT, previniendo cortes inesperados en sesiones largas inactivas.
• Multiplexación de flujos: decenas de streams bidireccionales simultáneos sin bloqueo, acelerando carga web y escenarios API.

Camuflaje como tráfico común

Elementos clave para plausibilidad: puerto 443/UDP, ALPN 'h3' (cuando el cliente lo soporte), certificado válido y adecuado SNI. Ante accesos externos aleatorios (escaneos o clientes curiosos) el servidor puede entregar contenido estático o hacer proxy de un sitio legítimo (mascarada), sin revelar que es un servicio de túnel.

DPI y bloqueos: tendencias actuales para 2026

• DPI híbrido: combinación de firmas y criterios de comportamiento: tamaño, frecuencia, tiempos de paquetes, también huellas persistentes TLS/QUIC.
• Limitación de tasa UDP: algunos proveedores restringen UDP, especialmente en puertos populares. Es crucial probar puertos alternativos y configurar fragmentación controlada.
• Reputación IP individual: direcciones VPN compartidas entran más rápido a listas negras. IP individual reduce correlación masiva y ruido de vecinos.

Práctica 1: Diseño de arquitectura y perfilado de riesgos

Paso 1. Definir objetivos

• Evasión DPI para navegación web y peticiones API.
• Resistencia a pérdidas y latencias altas (red móvil o ruta «lejano»).
• Bajo perfil de detección: puerto plausible, TLS válido, comportamiento sin «rasgos» peculiares.

Paso 2. Elección de plataforma y ubicación

• Servidor: VPS ligero con soporte garantizado UDP, 1–2 vCPU, 1–2 GB RAM suficiente para empezar. Almacenamiento de 10–20 GB.
• SO: Linux LTS actual, kernel reciente (para mejores pilas y temporizadores de red).
• Pila de red: priorizar nftables, systemd-networkd o NetworkManager, chrony/ntpd para sincronización precisa.

Paso 3. Dominio, certificado y puerto

• Dominio: nombre neutral sin indicios de «vpn». Ideal un dominio donde alojar sitio legítimo para mascarada.
• Certificado: certificado público válido para el dominio, RSA o ECDSA. Auto-renovación crítica.
• Puerto: 443/UDP por defecto para plausibilidad; puerto alternativo 8443/UDP u otro no evidente.

Paso 4. Modelo de secretos y rotación

• Contraseña/token en configuración servidor y cliente — único, complejo, distinto a otros servicios.
• Rotación frecuente: cada 1–3 meses o tras incidentes.
• Secretos separados por grupos de usuarios para facilitar revocación.

Lista de verificación de diseño

• UDP abierto en firewall y panel proveedor.
• Tiempo del servidor sincronizado (sin desfases importantes).
• Certificado válido y auto-renovable.
• Puerto 443/UDP y reserva definidos.
• Contraseñas y reglas de rotación establecidas.
• Contenido de mascarada listo (página estática o proxy inverso).

Práctica 2: Configuración servidor Hysteria 2 en Linux

Requisitos previos

• Binario 'hysteria' compilado o instalado con soporte para Hysteria 2.
• Certificado válido y clave privada en formato PEM.
• Permisos para ejecutar bajo usuario dedicado sin acceso shell.

Configuración básica de servidor (ejemplo)

Abajo un YAML ilustrativo. Nombres de campos pueden variar según versión, verifica con tu build. Valores entre comillas son ejemplos; usa tus propios secretos y rutas.

• listen: ':443'
• tls:
•   cert: '/etc/hysteria/cert.pem'
•   key: '/etc/hysteria/key.pem'
• auth:
•   type: 'password'
•   password: 'S3cure-Long-Secret-Token'
• obfs:
•   type: 'salamander'
•   password: 'Another-Obfs-Secret'
• masquerade:
•   type: 'file'
•   dir: '/var/www/masq'
• quic:
•   alpn: ['h3']
•   max_idle_timeout: '30s'
•   disable_path_mtu_discovery: false
• bandwidth:
•   up: '50 Mbps'
•   down: '200 Mbps'

Sistema y seguridad

• Crea usuario: `useradd --system --no-create-home --shell /usr/sbin/nologin hysteria`.
• Permisos en claves: `chown -R root:hysteria /etc/hysteria` y `chmod 640` en clave.
• Abre puertos: nftables o iptables para UDP 443 (y puerto reserva).
• SELinux/AppArmor: otorga permisos necesarios al binario y configuraciones.

Servicio systemd (mínimo)

• [Unit] Description='Hysteria 2 Server' After=network.target
• [Service] User=hysteria Group=hysteria AmbientCapabilities=CAP_NET_BIND_SERVICE CapabilityBoundingSet=CAP_NET_BIND_SERVICE ExecStart='/usr/local/bin/hysteria' 'server' '-c' '/etc/hysteria/config.yaml' Restart=on-failure
• [Install] WantedBy=multi-user.target

Activa el servicio automático: `systemctl enable --now hysteria.service`. Verifica logs: `journalctl -u hysteria -f`.

Optimización de red (kernel)

• net.core.rmem_max=67108864; net.core.wmem_max=67108864
• net.ipv4.udp_mem='262144 524288 1048576'
• net.ipv4.udp_rmem_min=4096; net.ipv4.udp_wmem_min=4096
• net.ipv4.ip_local_port_range='10000 65000'
• net.core.default_qdisc=fq (kernels modernos)

Aplica mediante sysctl.d y recarga configuraciones. Monitorea límites con `ss -u -a`, `ethtool -S`, `nstat`.

Camuflaje: respuesta plausible

• Tipo 'file': archivos estáticos en '/var/www/masq' (sitio simple de reemplazo).
• Tipo 'proxy': proxy inverso a sitio externo (sin saturar, el objetivo es realismo, no tráfico).

Verificación

• Puerto UDP: `nmap -sU -p 443 tu_IP` debe estar abierto.
• Paquetes QUIC: `tcpdump -ni any udp port 443` para confirmar intercambio Initial, Handshake.
• Certificado: prueba TLS 1.3 en puerto QUIC (o navegador con HTTP/3 y mascarada activada).

Práctica 3: Configuración de clientes (Desktop)

Opción A: Cliente nativo 'hysteria'

Config cliente YAML básico (ejemplo):

• server: 'tu_dominio:443'
• auth:
•   type: 'password'
•   password: 'S3cure-Long-Secret-Token'
• obfs:
•   type: 'salamander'
•   password: 'Another-Obfs-Secret'
• tls:
•   sni: 'tu_dominio'
•   insecure: false
• quic:
•   alpn: ['h3']
• bandwidth:
•   up: '20 Mbps'
•   down: '150 Mbps'
• socks5:
•   listen: '127.0.0.1:1080'
• http:
•   listen: '127.0.0.1:8080'

Ejecuta: `hysteria client -c client.yaml`. En navegador configura proxy local SOCKS5 127.0.0.1:1080 o HTTP 127.0.0.1:8080.

Opción B: sing-box (cliente universal)

Ejemplo JSON con outbound 'hysteria2' y inbound SOCKS local. Comillas simples para lectura (cámbialas a dobles en JSON real):

• {
•  'inbounds': [ {'type':'socks','listen':'127.0.0.1','listen_port':1080} ],
•  'outbounds': [
•   { 'type':'hysteria2', 'server':'tu_dominio', 'server_port':443, 'password':'S3cure-Long-Secret-Token', 'obfs':'salamander', 'obfs-password':'Another-Obfs-Secret', 'tls':{'enabled':true,'server_name':'tu_dominio','alpn':['h3']}, 'udp_fragment':{'enabled':true,'length':1200,'interval':0}, 'multiplex':{'enabled':true,'max_streams':32} }
•  ]
• }

Inicia sing-box con esta configuración y apunta tus apps al proxy SOCKS local. Si hay problemas con MTU, reduce 'udp_fragment.length' a 1200 o incluso 1180.

Opción C: v2rayN / Clash Meta / Nekoray

• Importa perfil Hysteria 2 manualmente: especifica servidor, puerto, contraseña, obfs 'salamander' y su clave, SNI, habilita ALPN 'h3' si el cliente lo permite.
• Configura proxy local SOCKS/HTTP o activa modo TUN para interceptar todo el tráfico.

Pruebas de velocidad y estabilidad

• Latencia: `ping` al servidor (estimación), luego latencias reales de apps.
• Pérdidas: `mtr` hacia servidor sin proxy y con túnel (análisis indirecto).
• Ancho de banda: descarga de archivos grandes, streaming 1080p/4K, cargas paralelas; fija atención en estabilidad, no solo picos de velocidad.

Práctica 4: Clientes móviles y router

Android: v2rayNG y similares

• Crea perfil Hysteria 2: servidor, puerto 443, contraseña, obfs 'salamander' y su clave, SNI — tu dominio, activa opciones QUIC/HTTP3 donde estén disponibles.
• Modo: elige TUN/VPN para capturar tráfico del sistema o proxy manual en apps.
• MTU: si las páginas se atascan, habilita fragmentación o reduce tamaño de datagramas a 1200.

iOS: Shadowrocket, FoXray, etc.

• Importa configuración Hysteria 2 o rellena campos manualmente. Verifica que el certificado sea válido; evita insecure=true salvo necesidad extrema.
• Perfiles de evasión: añade reglas para dominios internos y redes locales.

OpenWrt/router: proxy transparente

• Instala sing-box en el router, configura outbound hysteria2 e inbound TUN.
• Enruta todo el tráfico por TUN, excluyendo subredes locales, NTP y actualizaciones de firmware.
• Prueba clientes: estabilidad de YouTube 4K, descargas en mensajería, juegos en línea (verifica modo UDP).

Práctica 5: Estrategias anti-DPI y camuflaje

Estrategia básica

• Puerto 443/UDP, certificado público válido, SNI correcto.
• ALPN 'h3' si el cliente lo soporta, mascarada tipo 'file' o 'proxy'.
• Ofuscación 'salamander' con clave separada de la contraseña principal de autenticación.

Refuerzos

• Rotación de puerto y contraseñas cada 1–3 meses.
• Duplicación de punto de entrada: puerto principal 443 y reserva (ej. 8443/UDP) en configuración cliente.
• IPv6+IPv4: vector adicional para bloqueos selectivos.
• Límite en tamaño de datagramas (1200) para reducir patrones problemáticos de fragmentación.

Marco de reacción ante bloqueo

1. Evento: degradación o caída solo del UDP 443.
2. Diagnóstico: prueba UDP en puerto de reserva; revisión de logs; captura pcap en entrada.
3. Respuesta: cambia cliente a puerto reserva; rota contraseñas; si hace falta, cambia SNI y dominio.
4. Consolidación: actualiza mascarada, mejora ajuste MTU, redistribuye tráfico entre IPv4/IPv6.

Práctica 6: Rendimiento y estabilidad

Optimización del kernel y red

• Aumenta rmem/wmem y buffers UDP según carga.
• Activa fq como qdisc por defecto para suavizar colas.
• Revisa CPU governor — modo performance en instancias cargadas reduce jitter en timers.
• IRQ affinity y NUMA: asigna IRQ de red a núcleo dedicado bajo alta carga.

Parámetros cliente

• bandwidth up/down — asigna valores realistas, no exagerados.
• udp_fragment length — 1200 en rutas complejas, 1250–1350 donde es seguro (probar).
• multiplex max_streams — 16–64 para carga web, menos para juegos o tiempo real.

Monitorización

• Logs del servidor: warn/info para producción, debug temporalmente para análisis.
• pca selectivos: filtrar por udp y puerto; examinar tamaños e intervalos.
• Métricas del sistema: latencia, pérdidas, CPU, softirq, drops en controlador NIC.

Práctica 7: Operación, actualizaciones y seguridad

Checklist operativo

• Auto-renovación de certificados funcionando y alertas en fallos activadas.
• Rotación de contraseñas; revocación de acceso al comprometer cliente.
• Puerto reserva y perfiles clientes preparados y testeados.
• Logs sin detalles excesivos de secretos; rotación de registros activada.

Actualizaciones

• Planifica reinicios graduales en horas de baja carga.
• Guarda versión previa segura binaria para respaldo.
• Verifica cambios en formato de configuraciones con ejemplos en entorno de pruebas.

Seguridad

• Permisos mínimos al proceso; usuario/grupo dedicados separados.
• Firewall por defecto deny, whitelist solo puertos necesarios.
• Monitoreo de picos inusuales UDP o actividad de escaneo.

Errores comunes y anti-patrones

• Certificado o SNI incorrectos: causa fallos en el handshake y reintentos sospechosos.
• Solo TCP 443 abierto: olvidan UDP, el cliente no conecta.
• Bandwidth exagerado: velocidad inconsistente, caídas bajo carga.
• Sin mascarada: puerto con respuesta «vacía» atrae atención de escáneres.
• Misma contraseña para muchos clientes: complica revocación y análisis de incidentes.
• MTU demasiado grande: bloqueos por agujeros PMTU, sobre todo en redes móviles.
• Hora incorrecta en servidor: errores TLS y fallos inexplicables.

Herramientas y recursos

Administración y diagnóstico

• tcpdump, Wireshark: capturas puntuales para revisar QUIC Initial/Handshake y tamaños de datagramas.
• nftables, iptables: reglas para puertos UDP y rate-limits básicos.
• journalctl, systemd: gestión y visualización de logs de servicio.
• iperf3 (UDP): estimación básica de ancho de banda y pérdidas.
• mtr: traceroute combinado con análisis de pérdidas hacia el servidor.

Aplicaciones cliente

• hysteria (cliente y servidor), sing-box (cliente universal con TUN), v2rayN, Nekoray, Clash Meta, clientes móviles para Android e iOS.
• OpenWrt: sing-box como servicio de sistema con TUN para toda la red.

Alternativa práctica a implementación propia

Si buscas una opción práctica y rápida sin desplegar por tu cuenta, considera el servicio vpn.how: servidor VPN personal con IP propia (no compartida), reduciendo riesgo de listado en bloqueos masivos; soporte para protocolos WireGuard, OpenVPN, IKEv2, L2TP, SSTP — elige según necesidad y entorno de red; ubicaciones en Moscú, San Petersburgo, Ámsterdam, Frankfurt, Londres, Nueva York, San José, Chicago, Singapur, Sídney, Madrid, Helsinki, Estocolmo, Varsovia, Copenhague, Stavanger; aceptan tarjetas rusas (incluidos bancos populares), SBP, USDT/BTC; tarifas desde 490 ₽ al día y 2490 ₽ al mes con descuentos por periodos largos; servidor activo en minutos tras pago, sin logs. Para evadir DPI útil usar protocolos robustos: ejemplo, WireGuard en puertos no estándar o IKEv2 en 4500/UDP.

Casos y resultados

Caso 1: Red móvil con pérdidas del 2–5%

• Condiciones: RTT 120–180 ms, pérdidas 2–5%, VPN TCP básico ofrece velocidad irregular 2–6 Mbps.
• Hysteria 2: alpn 'h3', udp_fragment 1200, ancho de banda up/down 10/80 Mbps.
• Resultado: 12–18 Mbps estables en tres descargas paralelas, vídeo 1080p sin buffering, desaparecen microinterrupciones.

Caso 2: Wi‑Fi corporativo con DPI agresivo

• Condiciones: filtrado de huellas TLS no estándar, bloqueo UDP en casi todos los puertos, abierto 443/UDP.
• Hysteria 2: certificado válido, mascarada 'file' con sitio simple, obfs 'salamander'.
• Resultado: túnel estable, escáner ve un 443 «normal» con sitio simulado; ancho de banda promedio 30–40 Mbps en horario laboral.

Caso 3: Router doméstico con OpenWrt

• Condiciones: proveedor bloquea picos UDP periódicamente, IPv6 disponible.
• Solución: sing-box en router, outbound hysteria2, inbound TUN para toda la red, puerto reserva 8443.
• Resultado: vídeo 4K estable, juegos UDP más predecibles, latencia y jitter menores comparado con VPN TCP.

Preguntas frecuentes

1) ¿Hysteria 2 es HTTP/3 o un QUIC propio?

Hysteria 2 usa QUIC y TLS 1.3; algunos clientes permiten ALPN 'h3' para simular HTTP/3. La lógica del túnel es propia, no es una implementación completa de proxy HTTP/3.

2) ¿Es obligatorio usar puerto 443/UDP?

No, pero 443/UDP mejora la plausibilidad. Mantén un puerto reserva en caso de bloqueo selectivo. Prueba tu red específica.

3) ¿Se puede usar certificado autofirmado?

Técnicamente sí, activando insecure en clientes. En práctica empeora camuflaje y aumenta riesgo de detección. Se recomienda certificado público válido.

4) ¿Qué pasa con ECH y ocultar SNI?

ECH está poco extendido y es complejo de integrar en túneles genéricos. Considera SNI visible; escoge dominio neutral y mascarada correcta.

5) ¿Sirve Hysteria 2 para juegos?

Depende del juego. Si el tráfico es sobre TCP, Hysteria 2 ayuda contra pérdidas y jitter. Para juegos que usen UDP puro peer-to-peer, es útil modo proxy UDP en cliente o apps, aunque no todos los clientes lo soportan directamente.

6) ¿Hay fallback a TCP?

Hysteria 2 no tiene modo TCP nativo. Implementa fallback en cliente: perfil alternativo (WireGuard/IKEv2/OpenVPN) o transporte separado. Ten un «plan B» listo.

7) ¿Se puede poner servidor detrás de proxy inverso?

Proxy UDP es más complicado que TCP. Existen soluciones para QUIC, pero es más simple y fiable escuchar UDP directo en servidor. Para mascarada usa mecanismos internos.

8) ¿Por qué la velocidad es menor a la esperada?

Comúnmente: hints de bandwidth inflados, buffers del sistema pequeños, problemas PMTU, limitaciones del proveedor sobre UDP. Reduce MTU a 1200, aumenta rmem/wmem y prueba puerto reserva.

9) ¿Soporta acceso multiusuario?

Sí, con contraseña común o secretos separados. Para mejor gestión, asigna contraseñas individuales por grupos o usuarios y lleva registro.

10) ¿Es necesario IPv6?

Recomendado. El doble stack mejora resistencia: si un stack falla o está filtrado, el otro puede funcionar.

Conclusión

Hysteria 2 es un transporte QUIC maduro y práctico diseñado para la era de bloqueos agresivos y redes inestables. Arranca rápido, resiste pérdidas, se camufla naturalmente como tráfico habitual con configuración TLS/ALPN correcta, y ofrece al administrador palancas claras: ofuscación previa al handshake, mascarada, estimación de ancho de banda, control de MTU y multiplexación. Hemos analizado la arquitectura, diferencias con Hysteria 1, configuración de servidores y clientes, optimización, estrategias anti-DPI, errores comunes y resultados reales. Ahora toca la práctica: monta un entorno básico, sigue listas de diseño y operación, realiza capturas pcap en varios escenarios, abre puerto reserva, gestiona rotación de secretos y prueba varios días bajo carga real. La conectividad estable no es un punto, sino un proceso, y con Hysteria 2 ese proceso se vuelve más claro y manejable.