Hysteria 2 en VPS: instalación y configuración en 10 minutos

Qué configuramos y por qué

En esta guía se configura un servidor Hysteria 2 propio en Ubuntu Server 24.04 LTS. Hysteria 2 utiliza QUIC, que funciona sobre UDP, y TLS 1.3 para cifrar el tráfico. El cliente se conecta a su nombre de dominio, se autentica y envía el tráfico de Internet a través del VPS.

Este servidor resulta útil cuando se necesita un proxy personal para un portátil, teléfono, ordenador doméstico o un equipo pequeño. A diferencia de las VPN públicas, usted controla la dirección IP, la configuración, los registros, la contraseña de acceso y las actualizaciones. Sin embargo, el VPS no hace que el tráfico sea «anónimo»: los sitios finales seguirán viendo la IP del servidor y el proveedor del VPS podrá ver los metadatos de la infraestructura.

Después de la configuración, tendrá:

• un nombre de dominio que apunta al VPS;
• un certificado TLS válido de Let's Encrypt;
• el servicio hysteria-server.service, que se inicia después de reiniciar;
• un puerto UDP 443 cerrado, accesible solo mediante autenticación de Hysteria 2;
• una configuración YAML de cliente para Windows, Linux, macOS, Android o un cliente iOS compatible con Hysteria 2;
• una copia de seguridad de la configuración y los certificados.

Por qué Hysteria 2

La principal diferencia entre Hysteria 2 y una VPN clásica es el transporte. WireGuard utiliza su propio protocolo UDP, OpenVPN se usa a menudo sobre UDP o TCP, mientras que Hysteria 2 transmite datos mediante QUIC con TLS. QUIC puede funcionar mejor ante pérdida de paquetes y cambios en la ruta de red, lo que puede ser útil en redes móviles y conexiones inestables.

Self-hosted o servicio VPN listo para usar

Un servicio VPN listo para usar es cómodo: no es necesario administrar el servidor, renovar el certificado ni seguir las actualizaciones. Pero comparte la infraestructura con otros usuarios, no controla la configuración del servidor y confía en el operador del servicio.

Hysteria 2 self-hosted requiere administración básica de Linux, pero ofrece un servidor independiente, control de las claves y la posibilidad de cambiar de proveedor simplemente desplegando la configuración en otro VPS. Para uno o dos usuarios, suele ser el escenario más sencillo de infraestructura personal.

Utilice el servidor de conformidad con las leyes de su país, las normas del centro de datos y las condiciones de los servicios a los que se conecta. Hysteria 2 es una herramienta de red, no un medio para eludir obligaciones legales.

Qué configuración de VPS se necesita para esta tarea

Hysteria 2 en sí consume poca memoria y CPU. La carga no depende del número de configuraciones, sino de la cantidad de clientes simultáneos, la velocidad del canal, el cifrado y el volumen de tráfico transmitido. Para uso personal, normalmente son más importantes la calidad de la red y la ausencia de restricciones estrictas para UDP que una gran capacidad de disco.

Una opción inicial práctica: 1 vCPU, 1 GB de RAM, 20 GB NVMe/SSD, IPv4 público, canal de 100 Mbit/s y UDP habilitado. Para este escenario puede elegir un VPS con las características indicadas o un servidor virtual similar de otro proveedor.

Cuándo basta un VPS

Un VPS es adecuado casi siempre: proxy personal, varios dispositivos, una familia pequeña, trabajo remoto y entornos de prueba. Hysteria 2 no almacena grandes bases de datos ni requiere un disco dedicado. Incluso a velocidades de cientos de megabits, el cuello de botella suele ser el límite del canal o la cuota mensual de tráfico, no los recursos de procesamiento.

Cuándo se necesita un dedicado

Un servidor dedicado tiene sentido si decenas de usuarios consumen de forma constante cientos de megabits o gigabits, si se necesita CPU garantizada sin el efecto de noisy neighbor, varias IP de red, reglas de enrutamiento no estándar o un volumen mensual de tráfico muy elevado. Para un único usuario, un dedicado casi siempre es excesivo.

Cómo elegir la ubicación

La ubicación influye en la latencia, la ruta y la velocidad. Elija una región cercana a los usuarios principales: cuanto menor sea el RTT, mayor será la capacidad de respuesta de los sitios web, las llamadas y las aplicaciones interactivas. Antes de contratar, compruebe si el proveedor permite UDP/443 y si no hay filtrado de QUIC. Tenga también en cuenta que la dirección IP del servidor determinará las versiones regionales disponibles de sitios y servicios.

Para el dominio necesitará un registro A, por ejemplo hy.example.com, que apunte al IPv4 del VPS. Si habilita IPv6, añada un registro AAAA solo cuando el servidor realmente tenga un IPv6 público funcional y el puerto UDP necesario esté abierto en el firewall.

Preparación del servidor

A continuación se asume un servidor Ubuntu 24.04 LTS limpio con acceso SSH como usuario root. Realice la conexión inicial desde una terminal local. Antes de deshabilitar el inicio de sesión de root, asegúrese de que el inicio de sesión mediante clave SSH con el nuevo usuario funciona en una ventana de terminal independiente.

Actualice el sistema e instale las utilidades básicas

Este comando actualiza el índice de paquetes, instala todas las actualizaciones disponibles y añade herramientas para el firewall, certificados y diagnóstico.

apt update && apt upgrade -y
apt install -y curl wget ca-certificates gnupg ufw fail2ban certbot qrencode

Reinicie el servidor si se actualizó el kernel. Después de reiniciar, vuelva a conectarse por SSH.

reboot

Cree un administrador independiente

Sustituya admin por su nombre de usuario. El comando crea una cuenta, un directorio personal y añade el usuario al grupo sudo.

adduser admin
usermod -aG sudo admin

En el ordenador local, cree una clave si aún no la tiene. No transfiera la clave privada al servidor ni la envíe por mensajería.

ssh-keygen -t ed25519 -a 100 -C "admin@local"

Copie la clave pública al servidor. Indique la dirección IP de su VPS.

ssh-copy-id admin@SERVER_IP

Compruebe el nuevo inicio de sesión en una terminal independiente antes de cambiar los parámetros de SSH.

ssh admin@SERVER_IP

Deshabilite el inicio de sesión de root y la autenticación por contraseña

Abra la configuración de SSH mediante el editor nano.

sudo nano /etc/ssh/sshd_config

Añada o modifique los siguientes parámetros. Si la línea ya existe en el archivo, edítela en lugar de crear un duplicado.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no

Compruebe la sintaxis y reinicie el servicio SSH. No cierre la sesión actual hasta comprobar de nuevo que el inicio de sesión mediante clave funciona.

sudo sshd -t && sudo systemctl restart ssh

Configure el firewall

Para emitir el certificado mediante HTTP-01 se necesitará TCP/80. Hysteria 2 acepta tráfico en UDP/443. Dejamos SSH abierto únicamente porque el servidor debe administrarse. Si tiene una IP doméstica estática, más adelante puede restringir SSH solo a esa dirección.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/udp
sudo ufw enable
sudo ufw status verbose

No abra TCP/443 sin necesidad. Hysteria 2 de este artículo utiliza UDP/443. TCP/443 será necesario si más adelante implementa Caddy, Nginx u otro servidor web para un sitio o reverse proxy.

Habilite Fail2ban

Fail2ban protege principalmente SSH contra intentos de fuerza bruta de contraseñas y claves. Con la autenticación por contraseña deshabilitada, el riesgo ya es menor, pero el servicio sigue siendo útil como capa adicional de protección.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Compruebe el DNS antes de emitir el certificado

En el panel DNS, cree un registro A. El ejemplo utiliza el dominio hy.example.com. Sustituya por su propio nombre de dominio y la IP real del servidor.

dig +short A hy.example.com
curl -4 ifconfig.me

El primer comando debe mostrar la IP del VPS y el segundo, el IPv4 público del servidor. Si las direcciones difieren, no continúe: Let's Encrypt no podrá confirmar la propiedad del dominio.

Instalación de Hysteria 2 — paso a paso

A principios de 2026, se recomienda utilizar la rama estable actual de Hysteria 2, en lugar de la antigua Hysteria 1. Antes de instalar, compruebe el número de la última versión en el repositorio oficial del proyecto. El ejemplo utiliza el instalador oficial: descarga el archivo binario adecuado, crea un servicio systemd y el directorio /etc/hysteria.

Emita un certificado TLS de Let's Encrypt

Certbot en modo standalone inicia temporalmente un pequeño servidor HTTP en TCP/80. Asegúrese de que el puerto esté abierto en UFW y en el panel del proveedor. Sustituya la dirección de correo electrónico y el dominio por los suyos.

sudo certbot certonly --standalone \
  --agree-tos \
  --no-eff-email \
  --email [email protected] \
  -d hy.example.com

Tras completarse correctamente, el certificado estará en el directorio:

sudo ls -la /etc/letsencrypt/live/hy.example.com/

Nos interesan los archivos fullchain.pem y privkey.pem. No publique el contenido de privkey.pem: es una clave TLS privada.

Descargue e instale Hysteria 2

El siguiente comando ejecuta el instalador oficial. Antes de ejecutarlo, conviene revisar el script en el navegador o descargarlo por separado para auditarlo, especialmente si el servidor se utiliza en infraestructura de producción.

bash <(curl -fsSL https://get.hy2.sh/)

El instalador normalmente ofrece elegir la instalación del componente de servidor. Tras finalizar, compruebe la versión del archivo binario. Se espera una versión con el formato v2.x.x.

hysteria version

Compruebe qué archivos unit se han creado. En la mayoría de instalaciones, el servidor se denomina hysteria-server.service.

sudo systemctl list-unit-files | grep hysteria

Cree una contraseña de acceso segura

La contraseña de Hysteria 2 no es la contraseña de un usuario de Linux. Es un secreto independiente que deben conocer el servidor y cada cliente autorizado. Genere al menos 32 caracteres aleatorios.

openssl rand -base64 36

Guarde el valor en un gestor de contraseñas. Para insertarlo automáticamente en la configuración, puede escribirlo temporalmente en una variable de la sesión shell actual. La variable desaparecerá tras reiniciar el terminal.

export HY2_PASSWORD='ВСТАВЬТЕ_СЮДА_СГЕНЕРИРОВАННЫЙ_ПАРОЛЬ'

Prepare el directorio de configuración

El instalador normalmente ya crea el directorio. El siguiente comando garantiza su existencia y restringe la lectura de la configuración al usuario root.

sudo install -d -m 700 /etc/hysteria
sudo touch /etc/hysteria/config.yaml
sudo chmod 600 /etc/hysteria/config.yaml

En esta etapa, el archivo binario está instalado, el certificado se ha obtenido y el servidor está listo para configurarse.

Configuración del servidor y del cliente

Hysteria 2 utiliza YAML. La configuración mínima del servidor establece la dirección de escucha, el certificado TLS y la contraseña de autenticación. Para un servidor personal, es mejor no activar la ofuscación sin necesidad: complica el diagnóstico y no sustituye a TLS.

Configuración del servidor

Abra el archivo:

sudo nano /etc/hysteria/config.yaml

Inserte la configuración. Sustituya el dominio y la contraseña. El puerto :443 significa escuchar UDP/443 en todas las interfaces de red.

listen: :443

tls:
  cert: /etc/letsencrypt/live/hy.example.com/fullchain.pem
  key: /etc/letsencrypt/live/hy.example.com/privkey.pem

auth:
  type: password
  password: "ВСТАВЬТЕ_ДЛИННЫЙ_СЛУЧАЙНЫЙ_ПАРОЛЬ"

masquerade:
  type: proxy
  proxy:
    url: https://www.cloudflare.com/
    rewriteHost: true

El bloque masquerade define la respuesta a solicitudes HTTP normales si llegan al servidor sin ser tráfico válido de Hysteria 2. No afecta a la autenticación por contraseña de los clientes. Como URL, indique un sitio HTTPS accesible; no utilice su propio dominio si no tiene un servidor web independiente.

Es mejor no almacenar el secreto en un repositorio Git, capturas de pantalla o notas públicas. Para una máquina personal, es aceptable guardar la contraseña directamente en el archivo con permisos 600. En comandos de automatización, puede utilizar una variable de entorno, pero no la transmita mediante el historial de la shell ni la lista de procesos.

Permisos de los certificados

Hysteria se ejecuta con permisos de root en una configuración systemd típica y puede leer la clave de Let's Encrypt. Compruebe las rutas para evitar errores tipográficos.

sudo test -r /etc/letsencrypt/live/hy.example.com/fullchain.pem && echo "cert OK"
sudo test -r /etc/letsencrypt/live/hy.example.com/privkey.pem && echo "key OK"

Inicie el servicio

El comando activa el inicio automático después de reiniciar e inicia el servidor de inmediato.

sudo systemctl enable --now hysteria-server.service
sudo systemctl status hysteria-server.service --no-pager

Si la unit tiene otro nombre, utilice el resultado del comando systemctl list-unit-files | grep hysteria de la sección anterior. Tras iniciarse correctamente, el estado debe ser active (running).

Compruebe el puerto UDP

El comando muestra el proceso que escucha en UDP/443. Hysteria debe aparecer en la salida.

sudo ss -lunp | grep ':443'

Configuración del cliente Hysteria 2

Cree un archivo client.yaml en el equipo cliente. Es adecuado para el cliente CLI de Hysteria 2 y contiene únicamente los parámetros necesarios. Los valores de dominio y contraseña deben coincidir exactamente con los del servidor.

server: hy.example.com:443

auth: "ВСТАВЬТЕ_ДЛИННЫЙ_СЛУЧАЙНЫЙ_ПАРОЛЬ"

tls:
  sni: hy.example.com
  insecure: false

socks5:
  listen: 127.0.0.1:1080

http:
  listen: 127.0.0.1:8080

El parámetro insecure: false es fundamental: el cliente verifica el certificado y el nombre incluido en él. No establezca true como una «solución rápida» para un error de TLS. Si la verificación falla, corrija el DNS, la fecha del dispositivo, el SNI o el certificado.

Tras iniciar el cliente, el proxy SOCKS5 local estará disponible en 127.0.0.1:1080 y el proxy HTTP en 127.0.0.1:8080. En el navegador o la aplicación, indique SOCKS5 127.0.0.1, puerto 1080. No haga que SOCKS5 escuche en 0.0.0.0, de lo contrario otros dispositivos de la red podrían utilizar el proxy local.

Iniciar el cliente mediante CLI

Si el archivo binario de Hysteria 2 está instalado en el cliente, inícielo con este comando:

hysteria -c client.yaml client

Para los clientes gráficos, importe los valores manualmente: tipo de protocolo Hysteria 2, dirección hy.example.com, puerto 443, contraseña, SNI hy.example.com y verificación de certificado activada. Los nombres de los campos dependen de la aplicación, pero el significado de los parámetros es el mismo.

Renovación automática del certificado

Certbot en Ubuntu instala un temporizador systemd. Sin embargo, Hysteria debe reiniciarse después de actualizar los archivos del certificado; de lo contrario, el proceso seguirá utilizando el certificado antiguo en memoria. Cree un deploy hook.

sudo install -d -m 755 /etc/letsencrypt/renewal-hooks/deploy
sudo nano /etc/letsencrypt/renewal-hooks/deploy/restart-hysteria.sh

Añada el siguiente script:

#!/bin/sh
systemctl restart hysteria-server.service

Haga ejecutable el archivo y pruebe el modo seguro de renovación.

sudo chmod 755 /etc/letsencrypt/renewal-hooks/deploy/restart-hysteria.sh
sudo certbot renew --dry-run

Comprobación del funcionamiento

La comprobación debe realizarse en tres etapas: servicio del servidor, accesibilidad del puerto y paso real del tráfico a través del cliente. No se limite al estado de systemd: el servicio puede estar funcionando, pero el UDP puede estar bloqueado por el firewall del proveedor o el dominio puede apuntar a otra IP.

Compruebe los registros del servidor

Muestre las últimas 100 líneas del registro y mantenga abierto el flujo de registros durante la primera conexión del cliente.

sudo journalctl -u hysteria-server.service -n 100 --no-pager
sudo journalctl -u hysteria-server.service -f

Durante un inicio normal no debe haber errores de lectura del certificado, sintaxis YAML ni vinculación del puerto. El error address already in use significa que otro proceso ya ocupa UDP/443.

Compruebe el DNS y el certificado

Desde la máquina cliente, compruebe que el dominio se resuelva a la IPv4 correcta. Un curl normal no prueba Hysteria 2, ya que no es un servidor HTTP, pero la comprobación de DNS sigue siendo necesaria.

dig +short hy.example.com
ping -c 3 hy.example.com

Ping puede estar bloqueado por las reglas de red y no es un diagnóstico definitivo. Es más importante que la dirección IP de dig coincida con la IP del VPS y que el cliente Hysteria se conecte correctamente.

Compruebe el tráfico mediante SOCKS5

Después de iniciar el proceso del cliente, realice una solicitud a través del SOCKS5 local. El comando debe mostrar la IP pública de su VPS, no la IP de su proveedor doméstico.

curl --proxy socks5h://127.0.0.1:1080 https://ifconfig.me/ip
echo

La opción socks5h hace que curl resuelva el nombre de dominio a través del proxy, en lugar de hacerlo localmente. Esto es útil para comprobar que las consultas DNS de esta solicitud también pasan por el servidor remoto.

Compruebe la velocidad y las pérdidas

Primero mida la velocidad normal del VPS y después pruebe a través del proxy. Para una comprobación rápida de la descarga de un archivo grande, utilice cualquier recurso público permitido. Si la velocidad es notablemente inferior a la esperada, compruebe el límite del plan, la carga de CPU, la ruta y la presencia de filtrado UDP.

top
sudo ss -s
sudo journalctl -u hysteria-server.service --since "10 minutes ago"

No evalúe la calidad con una sola prueba de velocidad: el resultado depende de la ruta al servidor de prueba, la hora del día y la red del cliente. Para una evaluación real, compruebe sitios web, videollamadas, descargas de archivos y la red móvil.

Copias de seguridad y mantenimiento

Hysteria 2 no almacena una base de datos de usuarios en el escenario básico, por lo que las copias de seguridad son más sencillas que para GitLab o Mattermost. Sin embargo, la pérdida de la configuración, la clave TLS y los datos del dominio seguirá complicando la recuperación. La copia de seguridad no debe permanecer únicamente en el mismo VPS: si se elimina el servidor, se perderá junto con los datos.

Qué incluir en la copia de seguridad

• /etc/hysteria/config.yaml — configuración del servidor y contraseña de acceso;
• /etc/letsencrypt/ — certificados, claves privadas y configuraciones de renovación;
• /etc/ufw/ — reglas de UFW, si las modificó manualmente;
• /etc/ssh/sshd_config y archivos adicionales de /etc/ssh/sshd_config.d/;
• lista del software instalado y de las configuraciones de systemd;
• configuración del cliente o parámetros de conexión guardados por separado.

No es necesario hacer una copia de seguridad del propio archivo binario de Hysteria: puede descargarse de nuevo desde la versión oficial. Es más importante conservar la configuración verificada y los secretos.

Copia de seguridad archivada sencilla mediante rsync

El siguiente ejemplo copia los directorios críticos a un VPS de backup independiente mediante SSH. En el servidor de respaldo, cree previamente el usuario backup, el directorio /srv/backups/hysteria y una clave SSH independiente con permisos restringidos.

sudo nano /usr/local/sbin/backup-hysteria.sh

Contenido del script:

#!/bin/bash
set -euo pipefail

DATE=$(date +%F)
BACKUP_DIR="/tmp/hysteria-backup-${DATE}"
REMOTE="backup@BACKUP_SERVER_IP:/srv/backups/hysteria/"

mkdir -p "${BACKUP_DIR}"

tar -czf "${BACKUP_DIR}/hysteria-config.tar.gz" \
  /etc/hysteria \
  /etc/letsencrypt \
  /etc/ufw \
  /etc/ssh/sshd_config \
  /etc/ssh/sshd_config.d 2>/dev/null

rsync -a --delete "${BACKUP_DIR}/" "${REMOTE}"
rm -rf "${BACKUP_DIR}"

Haga el script ejecutable y ejecútelo manualmente. Compruebe siempre la primera ejecución antes de añadirlo a cron.

sudo chmod 700 /usr/local/sbin/backup-hysteria.sh
sudo /usr/local/sbin/backup-hysteria.sh

Para un escenario de producción, es preferible usar restic o borg: cifran el contenido, admiten deduplicación, historial de instantáneas y almacenamiento en buckets compatibles con S3. Si utiliza rsync, SSH proporciona el cifrado durante la transferencia, pero los propios archivos en el servidor de respaldo estarán accesibles para su administrador.

Añada una tarea cron

Abra el crontab de root y ejecute la copia de seguridad cada noche. El registro será útil para diagnosticar copias fallidas.

sudo crontab -e

30 3   * /usr/local/sbin/backup-hysteria.sh >> /var/log/hysteria-backup.log 2>&1

Actualización de Hysteria 2

Para un servidor personal, actualice Hysteria 2 en una breve ventana de mantenimiento una vez al mes o después de versiones importantes de seguridad. Antes de actualizar, cree una copia de seguridad, lea el changelog y guarde la versión actual. La actualización normalmente interrumpe las conexiones activas durante unos segundos.

hysteria version
sudo /usr/local/bin/hysteria version
sudo systemctl stop hysteria-server.service
sudo cp /usr/local/bin/hysteria /root/hysteria.backup
sudo systemctl start hysteria-server.service

El comando de actualización específico depende del método de instalación y puede estar disponible en el instalador oficial. Después de actualizar, ejecute siempre hysteria version, compruebe el estado de systemd y la conexión del cliente. Si la nueva versión no se inicia, restaure el archivo binario y la configuración desde la copia de seguridad.

Para un solo servidor no se necesita una «rolling update»: use una breve ventana de mantenimiento. Para varios servidores, primero actualice un nodo, compruébelo, luego dirija hacia él los clientes o el balanceador y actualice los demás.

Solución de problemas y FAQ

El servicio Hysteria 2 no se inicia: ¿qué comprobar?

Primero ejecute sudo systemctl status hysteria-server.service --no-pager y sudo journalctl -u hysteria-server.service -n 100 --no-pager. Las causas más frecuentes son un error en la indentación YAML, una ruta incorrecta a fullchain.pem o privkey.pem, el puerto UDP/443 ya está ocupado o la contraseña contiene caracteres sin escapar. Use espacios, no tabulaciones, y encierre la contraseña entre comillas dobles. Después de corregirlo, ejecute sudo systemctl restart hysteria-server.service.

Certbot informa que no pudo superar el HTTP-01 challenge. ¿Cómo solucionarlo?

Compruebe el registro A con el comando dig +short hy.example.com: debe apuntar a la IP del VPS. Asegúrese de que TCP/80 esté abierto tanto en UFW como en el firewall externo del panel del proveedor. El comando sudo ss -ltnp | grep ':80' mostrará si el puerto está ocupado por un servidor web. Si Nginx o Caddy ya escucha en TCP/80, use certbot con el método webroot o detenga temporalmente el servidor web mientras se emite el certificado.

El cliente muestra el error TLS certificate verification failed. ¿Qué hacer?

No active insecure: true como solución permanente. Compruebe que el cliente tenga configurado sni: hy.example.com, y no la dirección IP del VPS, y que ese dominio concreto esté indicado en el certificado. Verifique la fecha y hora en el dispositivo cliente. Asegúrese también de que el DNS del dominio apunte al servidor correcto. Si el certificado se emitió recientemente, compruebe la ruta a los archivos y reinicie Hysteria después de la renovación.

El servidor está iniciado, pero el cliente no se conecta y no hay eventos en los registros. ¿Por qué?

Lo más probable es que UDP/443 esté bloqueado antes de llegar al servidor. Compruebe sudo ufw status, la existencia de la regla 443/udp ALLOW y el firewall de red en el panel del VPS. Algunas redes, especialmente las corporativas o Wi-Fi de invitados, restringen UDP o QUIC. Pruebe la conexión desde una red móvil. Asegúrese también de que el servidor realmente escuche en UDP/443: sudo ss -lunp | grep ':443'.

¿Por qué Hysteria 2 tiene baja velocidad?

Compare la velocidad sin proxy y a través del proxy, luego compruebe la CPU con el comando top durante la prueba. La causa puede estar en el límite de ancho de banda del VPS, la cuota mensual de tráfico, una ruta saturada, una restricción en la red del cliente o pérdidas de paquetes UDP. Elija una ubicación más cercana al usuario y pruebe varios destinos. No aumente los parámetros de velocidad en la configuración al azar: primero asegúrese de que el problema no esté en el canal del proveedor.

¿Qué configuración de VPS es mínimamente adecuada?

Para un usuario o varios dispositivos personales, basta como mínimo con 1 vCPU, 1 GB de RAM, 10 GB de SSD e IPv4 pública. Se necesita tráfico UDP disponible y UDP/443 abierto. Es mejor elegir directamente 20 GB de disco: proporcionará margen para actualizaciones, registros y certificados. En cuanto a red, un mínimo razonable es 100 Mbit/s y 1 TB de tráfico al mes, pero para vídeo activo o descargas es más importante una cuota ampliada.

¿Qué elegir para esta tarea: VPS o dedicated?

Para Hysteria 2, casi siempre conviene empezar con un VPS. Es más económico, se despliega rápidamente y proporciona recursos suficientes para un proxy personal o un equipo pequeño. Se necesita un dedicated con carga alta constante, decenas de usuarios activos, requisito de CPU garantizada, 1 Gbit/s sin virtualización intensa o tráfico muy elevado. Migrar a dedicated no cambia la configuración de Hysteria: basta con transferir el dominio, el certificado y el archivo YAML.

¿Se pueden conectar varios dispositivos con una sola contraseña?

Técnicamente sí, y para un solo propietario es una opción cómoda. La desventaja es que, si se filtra la contraseña, tendrá que cambiarla en el servidor y en todos los dispositivos. Para una familia o un equipo, use credenciales independientes si su esquema de gestión de Hysteria 2 y el cliente utilizado lo admiten, o cree servidores o configuraciones separados. Nunca publique una configuración de cliente con una contraseña real en acceso público.

¿Es necesario abrir TCP/443?

Para la configuración mínima de Hysteria 2 sobre QUIC se necesita UDP/443, no TCP/443. TCP/80 solo es necesario durante la emisión y renovación del certificado mediante el método HTTP-01. TCP/443 puede permanecer cerrado si no hay un sitio web o reverse proxy en el servidor. Abra puertos adicionales únicamente para una tarea específica: esto reduce la superficie de ataque y simplifica el diagnóstico de las reglas del firewall.

Seguridad y limitaciones prácticas

Un servidor proxy funcional no es solo un archivo YAML. La seguridad mínima incluye claves SSH, inicio de sesión de root desactivado, firewall, actualizaciones periódicas y copias de seguridad. La causa más frecuente de la vulneración de VPS pequeños no es una vulnerabilidad de Hysteria, sino una contraseña SSH débil, un panel de administración expuesto o un servicio olvidado sin actualizar.

Lista de verificación después de la configuración

• El acceso por SSH solo está permitido mediante claves.
• El inicio de sesión remoto para el usuario root está desactivado.
• Solo están abiertos SSH, TCP/80 y UDP/443.
• Las actualizaciones de seguridad de Ubuntu están instaladas.
• La contraseña de Hysteria contiene al menos 32 caracteres aleatorios.
• La verificación TLS está activada en los clientes.
• Certbot completa correctamente renew --dry-run.
• La configuración y los certificados se copian fuera del VPS.
• Se ha comprobado la restauración de al menos una copia de seguridad.

No publique secretos

El archivo del cliente contiene la dirección del servidor y la contraseña. No debe enviarse a chats públicos, añadirse a GitHub, incluirse en capturas de pantalla ni almacenarse en un documento en la nube sin protección. Si la configuración se envió a la persona equivocada, considere la contraseña comprometida: genere una nueva, modifique el YAML del servidor, reinicie el servicio y actualice todos los clientes.

Supervise el tráfico

Compruebe el consumo de tráfico en el panel del VPS y los registros del sistema. Un crecimiento inusual del tráfico saliente puede indicar una filtración de la contraseña o el uso del servidor por terceros. Si sospecha de una vulneración, cambie inmediatamente la contraseña de Hysteria, las claves SSH si es necesario, actualice el sistema y examine los registros de inicio de sesión.

sudo journalctl -u hysteria-server.service --since "24 hours ago"
sudo last -a | head -20
sudo apt update && sudo apt upgrade -y

Limitaciones de Hysteria 2

Hysteria 2 depende de la disponibilidad de UDP. En algunas redes corporativas, hoteles, centros educativos y Wi-Fi públicos, UDP puede estar restringido o funcionar de forma inestable. En ese caso, es útil disponer de un método de acceso remoto de respaldo, por ejemplo WireGuard o un servicio HTTPS convencional para la administración. No elimine el acceso SSH hasta haber probado la conexión de Hysteria desde las redes reales que planea utilizar.

Conclusiones y siguientes pasos

Ahora Hysteria 2 funciona en el VPS con un certificado TLS, autenticación por contraseña, firewall y renovación automática del certificado. El cliente se conecta a su dominio mediante UDP/443 y crea un proxy SOCKS5 o HTTP local.

1. Compruebe la conexión desde la red doméstica, Internet móvil y Wi-Fi del trabajo.
2. Configure una copia de seguridad cifrada en un VPS independiente o almacenamiento S3 y pruebe la restauración.
3. Actualice Ubuntu y Hysteria 2 una vez al mes y, a medida que aumente la carga, supervise el tráfico, la CPU y la calidad de la ruta.

Si varias personas van a utilizar el servidor, separe los accesos, documente los cambios de contraseñas y prepare con antelación un procedimiento de migración a una nueva IP o a un servidor más potente.