Skip to main content

Hysteria2: proxy QUIC de alto rendimiento contra bloqueos y restricciones de red

Instalación y configuración inicial

Hysteria2, explicado en cristiano: es un protocolo de transporte basado en QUIC que se disfraza muy bien de tráfico legítimo. Su gracia está en que permite saltarse bloqueos, censura y limitaciones de red, porque cifra y mezcla el tráfico de forma que parece otra cosa. A diferencia de un simple proxy, está pensado para rendir en conexiones jodidas (alto lag, pérdidas de paquetes) y para que sea más difícil de detectar. Además, funciona como una VPN de alto rendimiento: cifra todo el tráfico, lo camufla y mantiene velocidades muy altas incluso en redes con restricciones fuertes. Con Blitz, básicamente automatizas su despliegue y gestión, y con Caddy encima lo vistes con certificados TLS de verdad para que no cante a “certificado cutre autofirmado”.

Requisitos previos

  • Sistema: Debian 11+ / Ubuntu 22+
  • Arquitectura: x86_64 o ARM64
  • RAM: 1 GB mínimo
  • Almacenamiento: 10 GB libres
  • Red: IPv4/IPv6 compatible
  • Acceso: privilegios root
  • Dominio: necesario para el uso de Hysteria2 y compatibilidad con clientes como SingBox
  • Router: redirección del puerto elegido hacia la IP local del servidor (recomendable usar IP fija)

Instalación base con Blitz

Antes de instalar, actualizar paquetes:

apt update && apt upgrade -y

Ejecutar el instalador:

bash <(curl https://raw.githubusercontent.com/ReturnFI/Blitz/main/install.sh)

Al finalizar, se accede al menú principal.

  1. Pulsar 1 para entrar en el menú de Hysteria2.

  2. Seleccionar Install and Configure Hysteria2.

  3. Introducir un SNI (o pulsar Enter para usar el predeterminado). Aquí lo correcto es poner el dominio propio que apunte al servidor, ya que el SNI es un nombre de host, no una IP. Si se usa Cloudflare, debe desactivarse para que apunte directamente a la IP real.

    • Ejemplo válido: bing.com (sin https:// ni barras). También se puede poner directamente la URL o la IP, siempre que el dominio apunte a la IP del servidor.

  4. Elegir un puerto de activación (ejemplo: 45443).

Nota: se recomienda el puerto 443 para mayor ocultación, pero si ya está ocupado (por ejemplo, por Caddy), se puede utilizar otro puerto alternativo. Esto reduce un poco la apariencia de tráfico legítimo, aunque sigue siendo funcional. Algunos clientes permiten usar directamente la IP del servidor como SNI, pero esto no es estándar y puede dar problemas con TLS. Siempre se recomienda usar un dominio con certificado válido (por ejemplo, gestionado por Caddy con Let’s Encrypt).

Uso de certificados con Caddy

Para evitar certificados autofirmados, se puede usar Caddy como emisor y aprovechar los certificados de Let’s Encrypt.

Configuración en Caddyfile:

Ruta donde Caddy genera certificados (en baremetal):

/var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/

Nota: el detalle de permisos y acceso a esos certificados se documenta en un artículo aparte: Hysteria2 + Caddy: acceso seguro a certificados (ACL + systemd).

Configuración de Hysteria

El servicio corre bajo hysteria-server.service. Su configuración principal se encuentra en /etc/hysteria/config.json.

Configuración base orientativa disponible en Gitea: config_default.json. Esta configuración es la que genera inicialmente el instalador Blitz, sirve como referencia.

  • Config modificada (certs Caddy, insecure=false, DNS locales, en mi caso, en el tuyo, puedes elegir los que desees, además, los clientes deben estar configurados para usar DNS remoto): config_modified.json. Esta es la configuración que se recomienda usar, ya que incorpora los ajustes preparados previamente (con los cambios pertinentes, no es para copiar y pegar tal cual, además, debe llamarse config.json).

Flujo de edición rápida

  1. Editar /etc/hysteria/config.json y apuntar tls.cert y tls.key a los de Caddy.
  2. Revisar permisos y traversal del path como en el artículo dedicado.
  3. Reiniciar servicio y revisar sudo systemctl status hysteria-server.service para localizar el fallo exacto.
  4. Probar conectividad UDP al puerto elegido desde el cliente (por ejemplo con Hiddify, desde Android).

Errores típicos

  • permission denied al leer .crt/.key → revisar artículo de permisos (ACL + systemd).
  • address already in use → puerto en uso; cambiar listen o liberar el socket.
  • tls: handshake failure → SNI del cliente no coincide, o cert/clave no alinean.
  • no such device en bindDevice → interfaz mal escrita; listar con ip link.

Enlaces de interés

Notas

  • Este artículo ahora solo mantiene lo básico de instalación y configuración. Los detalles de permisos se han movido a su propio artículo para mantener las cosas ordenadas.
Back to top