Elección de SNI para VLESS Reality: cómo verificar un dominio y evitar bloqueos

Qué configuramos y por qué

VLESS Reality es un esquema de transporte de Xray-core para una conexión cliente-servidor protegida. Utiliza un protocolo de enlace TLS similar a la conexión con un sitio HTTPS convencional, pero la verificación del cliente se basa en el par de claves Reality, el short ID y los parámetros VLESS. A diferencia de un proxy TLS convencional, el servidor no necesita un dominio público ni su propio certificado para la conexión entrante.

El principal parámetro que suele generar dudas es SNI, Server Name Indication. Es el nombre de host que el cliente transmite al inicio de la sesión TLS. En la configuración de Reality, la lista de nombres permitidos se establece mediante el parámetro serverNames, y el host HTTPS público de destino mediante el parámetro dest. Normalmente se utiliza el mismo dominio tanto en serverNames como hostname en dest.

El objetivo de la configuración es obtener un servidor personal controlado para acceder de forma segura a sus propios recursos y proteger el tráfico en redes no confiables. Tras completar los pasos tendrá:

• un VPS con acceso SSH mínimamente protegido y firewall;
• una versión actual de Xray-core instalada;
• un par de claves X25519 para Reality;
• una configuración VLESS Reality en el puerto TCP 443;
• una metodología para verificar un dominio SNI antes de añadirlo a la configuración operativa;
• un procedimiento de copia de seguridad de configuraciones y material de claves;
• diagnóstico de errores de conexión habituales.

Cómo utiliza Reality el SNI

El cliente se conecta a la dirección IP de su VPS, pero en TLS ClientHello indica el nombre elegido, por ejemplo www.example.net. El servidor Xray acepta la conexión solo si el SNI coincide con la lista permitida y la verificación criptográfica de los parámetros Reality se realiza correctamente. Para un observador externo, la conexión parece una sesión TLS con el nombre indicado; sin embargo, la ruta de red conduce a la IP de su servidor.

El parámetro dest es necesario para Reality como perfil TLS de destino y dirección fallback para conexiones no válidas. Es importante que el dominio realmente sirva HTTPS y sea técnicamente similar al tráfico esperado de un navegador. Un dominio inadecuado puede provocar tiempos de espera, errores de protocolo de enlace o funcionamiento inestable después de cambios en el sitio.

Qué dominios no conviene elegir

No elija un dominio únicamente porque sea conocido o tenga una clasificación alta. Cuanto más vinculado esté un dominio a organizaciones financieras, servicios gubernamentales, infraestructura de pagos, correo o seguridad corporativa, mayor será la probabilidad de políticas TLS especiales, restricciones regionales, protección antibots compleja y cambios frecuentes de configuración.

• No utilice sitios de bancos, bolsas, sistemas de pago ni portales gubernamentales.
• No utilice dominios que ya no estén disponibles en su red o requieran DNS no estándar.
• Evite sitios que solo admitan TLS 1.2, con certificados autofirmados o una cadena de CA incorrecta.
• No elija dominios que respondan únicamente por IPv6 si sus clientes tienen IPv6 inestable.
• No utilice hosts que cambien constantemente de CDN, certificados o requieran verificación JavaScript ya en el nivel de conexión.
• No utilice marcas ajenas en los nombres de perfiles, códigos QR e instrucciones públicas para usuarios.

Alternativas: servicios gestionados y VPS propio

Los servicios VPN gestionados son más fáciles de iniciar: no es necesario actualizar el sistema, configurar el firewall ni almacenar claves. Sin embargo, no controla la configuración del servidor, el registro, el enrutamiento ni el período de retención de datos. Además, el proveedor puede cambiar direcciones, reglas de acceso y protocolos disponibles sin su aprobación.

VLESS Reality autohospedado en un VPS requiere administración básica de Linux, pero ofrece control sobre la dirección IP, los puertos, el acceso de usuarios y las copias de seguridad. Para un propietario o un equipo pequeño, normalmente se justifica si está dispuesto a instalar actualizaciones periódicamente y revisar los registros.

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

VLESS Reality por sí mismo consume poca memoria y tiempo de procesador. La carga no está determinada por el número de líneas de configuración, sino por la cantidad de conexiones TLS simultáneas, la velocidad de cifrado, el volumen de datos transmitidos y los servicios adicionales del servidor.

Una opción inicial práctica es 2 vCPU, 2 GB de RAM, 20 GB NVMe, IPv4 y un canal de 1 Gbit/s. Este margen permite alojar Xray-core, fail2ban, un sistema de copias de seguridad, monitoreo y varios usuarios sin competir por la memoria. Al elegir, puede contratar un VPS con las características indicadas o un plan similar de otro proveedor.

Qué considerar además de CPU y RAM

• IPv4 dedicado. Simplifica la conexión desde redes antiguas y clientes móviles.
• IPv6. Es útil como ruta adicional, pero no debe ser el único punto de acceso.
• Tráfico. Evalúe el límite mensual. Las videollamadas y actualizaciones del sistema operativo lo consumen notablemente más rápido que la navegación web habitual.
• Política de uso aceptable. No infrinja las normas del centro de datos ni la legislación local.
• Posibilidad de reinstalar el sistema operativo y snapshot. Reduce el tiempo de recuperación tras un error.
• Acceso a consola. VNC, serial console o rescue mode son necesarios si se equivoca en el firewall y bloquea SSH.

Cuándo se necesita un servidor dedicado en lugar de un VPS

Un servidor dedicado no es necesario para un solo usuario y normalmente tampoco para un equipo pequeño. Se justifica con una carga sostenida de cientos de megabits por segundo, un gran número de clientes simultáneos, la necesidad de aislar recursos de vecinos de virtualización o al alojar servicios adicionales exigentes.

Si el problema son caídas de velocidad breves, primero verifique el límite del canal, la pérdida de paquetes, la ruta y la carga de CPU. Migrar a un servidor dedicado no solucionará un SNI incorrecto, un puerto bloqueado, una configuración errónea del cliente ni las limitaciones de la red móvil.

Cómo influye la ubicación del VPS

La ubicación determina la latencia, la ruta hacia los clientes y la disponibilidad del dominio SNI elegido desde el centro de datos. Para tareas interactivas, elija un servidor más cercano a la audiencia principal: una latencia de hasta 60–100 ms suele ser cómoda para navegación y llamadas. Verifique no solo el ping al VPS, sino también la velocidad real de las conexiones TCP durante las horas punta.

Si los clientes se encuentran en distintas regiones, no intente resolverlo todo con un solo servidor. Es más fiable desplegar dos nodos independientes, preparar perfiles separados y cambiar entre ellos manualmente o mediante su propio sistema de acceso.

Preparación del servidor

A continuación se utiliza Ubuntu Server 24.04 LTS. A principios de 2026, es una base LTS estable con soporte de seguridad hasta 2029. Los comandos también son adecuados para Debian 12/13 con pequeños cambios en los nombres de paquetes.

Conéctese al servidor con el usuario proporcionado por el proveedor y actualice inmediatamente el sistema. No deje habilitado el acceso SSH con contraseña si puede utilizar claves.

ssh root@SERVER_IP
apt update && apt full-upgrade -y
reboot

Los comandos instalan actualizaciones de seguridad y reinician el servidor si se actualizó el kernel.

ssh root@SERVER_IP
adduser deploy
usermod -aG sudo deploy

Se crea un usuario independiente deploy con permiso para ejecutar comandos administrativos mediante sudo.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Añada al archivo la clave SSH pública de su equipo. No cierre la sesión root actual hasta verificar el inicio de sesión con el nuevo usuario.

ssh deploy@SERVER_IP
sudo -v
exit

Esta verificación confirma que el inicio de sesión mediante clave y sudo funcionan antes de deshabilitar el acceso root.

sudo apt install -y curl wget jq ca-certificates gnupg lsb-release \
unzip ufw fail2ban openssl dnsutils mtr-tiny cron

Se instalan utilidades para descargar versiones, verificar DNS/TLS, firewall, proteger SSH y programar tareas.

sudo nano /etc/ssh/sshd_config.d/10-hardening.conf

Cree un archivo independiente con los parámetros SSH para no editar la configuración principal de la distribución.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

sudo sshd -t && sudo systemctl restart ssh
sudo systemctl status ssh --no-pager

Primero se verifica la sintaxis de la configuración SSH y luego se reinicia el servicio de forma segura.

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

El firewall deniega todas las conexiones entrantes excepto SSH y el puerto TCP 443 para Xray.

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

Fail2ban supervisa intentos repetidos y fallidos de inicio de sesión SSH y bloquea temporalmente las fuentes de fuerza bruta.

Importante: si SSH funciona en un puerto no estándar, ábralo en UFW antes del comando ufw enable. Verifique también el cloud firewall en el panel del proveedor: puede existir por separado de UFW.

Instalación del software, paso a paso

Xray-core se desarrolla activamente, por lo que fijar el número de versión en el artículo es arriesgado: puede quedar obsoleto antes de la instalación. Es más seguro obtener el número de la última versión estable desde el repositorio oficial del proyecto y guardarlo en un archivo del sistema. Antes de actualizar, lea siempre el changelog de la versión, especialmente si hay cambios en el formato de configuración.

sudo install -d -m 0755 /etc/xray /var/log/xray /usr/local/lib/xray
sudo chown -R nobody:nogroup /var/log/xray

Se crean directorios para la configuración, los registros y los archivos adicionales de Xray.

XRAY_VERSION=$(curl -fsSL https://api.github.com/repos/XTLS/Xray-core/releases/latest | jq -r .tag_name)
echo "$XRAY_VERSION"

El comando obtiene la etiqueta de la última versión estable oficial de Xray-core mediante la API de GitHub.

ARCH=$(dpkg --print-architecture)
case "$ARCH" in
  amd64) XRAY_ARCH="64" ;;
  arm64) XRAY_ARCH="arm64-v8a" ;;
  ) echo "Arquitectura no compatible: $ARCH"; exit 1 ;;
esac
echo "$XRAY_ARCH"

cd /tmp
curl -fL -o xray.zip "https://github.com/XTLS/Xray-core/releases/download/${XRAY_VERSION}/Xray-linux-${XRAY_ARCH}.zip"
unzip -o xray.zip -d xray-release
sudo install -m 0755 xray-release/xray /usr/local/bin/xray
sudo install -m 0644 xray-release/geoip.dat xray-release/geosite.dat /usr/local/share/
xray version

sudo useradd --system --no-create-home --shell /usr/sbin/nologin xray || true
sudo chown -R xray:xray /etc/xray
sudo chmod 750 /etc/xray

sudo /usr/local/bin/xray x25519

openssl rand -hex 8

uuidgen

sudo tee /etc/systemd/system/xray.service > /dev/null <<'EOF'
[Unit]
Description=Xray Service
Documentation=https://github.com/XTLS/Xray-core
After=network-online.target nss-lookup.target
Wants=network-online.target

[Service]
Type=simple
User=xray
Group=xray
EnvironmentFile=/etc/xray/reality.env
ExecStartPre=/usr/bin/envsubst < /etc/xray/config.json.template > /run/xray-config.json
ExecStart=/usr/local/bin/xray run -config /run/xray-config.json
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ReadWritePaths=/run /var/log/xray

[Install]
WantedBy=multi-user.target
EOF

sudo apt install -y gettext-base
sudo systemctl daemon-reload

sudo tee /etc/logrotate.d/xray > /dev/null <<'EOF'
/var/log/xray/.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 0640 xray xray
}
EOF
sudo logrotate -d /etc/logrotate.d/xray

Se configura una rotación diaria de logs con conservación de 14 archivos. La opción -d realiza una prueba sin modificar realmente los archivos.

Copia de seguridad automática mediante restic

Restic crea copias de seguridad cifradas y deduplicadas. El repositorio puede alojarse en almacenamiento compatible con S3, en un VPS independiente mediante SFTP o en otro almacenamiento aislado. A continuación se muestra un ejemplo para un endpoint compatible con S3; guarde los secretos reales en un archivo accesible por root.

sudo apt install -y restic
sudo install -d -m 0700 /root/.config/restic
sudo nano /root/.config/restic/env

Se instala restic y se crea un directorio protegido para los parámetros del almacenamiento de copias de seguridad.

export RESTIC_REPOSITORY="s3:https://s3.example-storage.net/xray-backup"
export RESTIC_PASSWORD="REPLACE_WITH_LONG_UNIQUE_PASSWORD"
export AWS_ACCESS_KEY_ID="REPLACE_WITH_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="REPLACE_WITH_SECRET_KEY"

sudo chmod 600 /root/.config/restic/env
sudo bash -c 'source /root/.config/restic/env && restic init'

Se establecen permisos estrictos para los secretos y se inicializa el repositorio cifrado de restic.

sudo tee /usr/local/sbin/backup-xray.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
source /root/.config/restic/env

restic backup \
  /etc/xray \
  /etc/systemd/system/xray.service \
  /etc/ufw \
  /etc/fail2ban \
  --tag xray --tag "$(hostname -s)"

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check
EOF
sudo chmod 700 /usr/local/sbin/backup-xray.sh

El script crea una copia de seguridad, elimina puntos antiguos según la política de conservación y verifica la integridad del repositorio.

sudo /usr/local/sbin/backup-xray.sh
sudo crontab -e

Primero ejecute la copia de seguridad manualmente. Tras completarse correctamente, añada una ejecución diaria al crontab de root.

20 03   * /usr/local/sbin/backup-xray.sh >> /var/log/backup-xray.log 2>&1

Actualizaciones y ventana de mantenimiento

Es mejor realizar las actualizaciones de Xray-core en una breve ventana de mantenimiento. Para un solo servidor, esto implica una interrupción de unos segundos o minutos: descargue la versión, compruebe la configuración, reinicie el servicio y conéctese con un cliente de prueba. No actualice el servidor si no dispone de una copia funcional de la configuración y acceso de emergencia mediante consola.

sudo systemctl stop xray
sudo cp /usr/local/bin/xray /usr/local/bin/xray.previous
sudo systemctl start xray
sudo systemctl is-active xray
sudo journalctl -u xray -n 30 --no-pager

Antes de reemplazar el archivo binario, guarde la versión anterior. En caso de error, puede restaurarla y reiniciar el servicio.

Para dos servidores, utilice un enfoque rolling: actualice el primer nodo, compruebe la conexión y luego actualice el segundo. Los clientes deben tener dos perfiles independientes o un mecanismo de conmutación para que el mantenimiento de un servidor no le deje sin acceso por completo.

Solución de problemas + FAQ

¿Por qué el cliente muestra «TLS handshake failed» o «reality verification failed»?

Primero compare los parámetros del cliente y del servidor: SNI, public key, short ID, UUID, puerto y tipo de transporte deben coincidir. Un error frecuente es introducir en el cliente la private key en lugar de la public key, o indicar un SNI con el prefijo https://. En el servidor, compruebe journalctl -u xray -n 100 y asegúrese de que el servicio utiliza el archivo actual /etc/xray/reality.env. Después de modificar variables, ejecute siempre sudo systemctl restart xray.

¿Cómo saber si el dominio SNI elegido es malo?

Un candidato malo es inestable durante comprobaciones TLS repetidas, no admite TLS 1.3, emite reset periódicamente o no es accesible desde la red del cliente. Compruébelo mediante openssl s_client y curl desde el VPS, y luego repita la prueba desde redes móviles y domésticas. No evalúe el dominio por un único intento exitoso: realice al menos cinco o diez solicitudes en distintos momentos. Si hay timeouts regulares, elija otro host HTTPS público técnicamente estable.

¿Por qué el puerto 443 no está escuchando después de iniciar Xray?

Lo más probable es que el puerto ya esté ocupado por otro proceso: Caddy, nginx, Apache, un contenedor Docker o una copia antigua de Xray. Ejecute sudo ss -lntp | grep ':443' para ver el propietario del socket. Detenga el servicio conflictivo o muévalo a otra dirección IP o puerto. Luego valide el JSON con el comando xray run -test -config y reinicie Xray. No intente ejecutar simultáneamente dos servicios TLS en el mismo IP:443 sin una arquitectura bien planificada.

La conexión funciona por Wi-Fi, pero no mediante la red móvil. ¿Qué hacer?

Compare la resolución DNS, la accesibilidad de la IP del VPS y la comprobación TLS desde ambas redes. El problema puede estar en la ruta del operador, IPv6, un filtro de red local o en que el SNI elegido no sea accesible precisamente allí. Asegúrese de que el cliente se conecta mediante IPv4 si IPv6 es inestable. No cambie todos los parámetros a la vez: primero compruebe la accesibilidad de TCP 443 hacia el VPS, luego la configuración del perfil y, después, pruebe otro SNI previamente verificado en un perfil de servidor independiente.

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

Para un propietario y varios dispositivos, como mínimo bastan 1 vCPU, 1 GB de RAM, 10 GB de SSD o NVMe, IPv4 dedicada y un canal de 100 Mbit/s o más. Sin embargo, un inicio más cómodo es con 2 vCPU, 2 GB de RAM y 20 GB de NVMe: quedará margen para actualizaciones, logs, fail2ban y restic. Más importantes que las características de la CPU son la calidad de red, el tráfico mensual disponible, un IPv4 estable y la posibilidad de restaurar el servidor mediante consola.

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

Para VLESS Reality personal y un equipo pequeño, elija VPS: es más económico, se escala más fácilmente y normalmente cubre por completo las necesidades de CPU y memoria. Dedicated tiene sentido con tráfico alto sostenido, decenas o cientos de usuarios simultáneos, una necesidad estricta de aislamiento de recursos o el alojamiento de servicios adicionales pesados. No migre a un servidor dedicado para corregir errores de configuración: primero descarte problemas de SNI, firewall, ruta y parámetros del cliente.

¿Es necesario emitir un certificado Let’s Encrypt o configurar Caddy?

No, para VLESS Reality no se necesita un certificado Let’s Encrypt y no participa en la autorización del cliente. El servidor Reality utiliza una private key X25519, y el cliente la public key correspondiente, SNI y short ID. Caddy o certbot solo son necesarios si aloja por separado un sitio HTTPS convencional o un panel web protegido. No instale Caddy en el mismo puerto TCP 443 de la misma IP donde Xray ya está ejecutándose, o recibirá un error de puerto ocupado.

¿Cómo añadir de forma segura un segundo usuario?

Cree un UUID independiente para él y, preferiblemente, un short ID independiente. Añada una nueva entrada al array clients y, si es necesario, un nuevo elemento a shortIds, luego compruebe el JSON resultante y reinicie Xray. No asigne un UUID común a dos personas: en caso de problema, no podrá revocar el acceso de un solo usuario. Mantenga una lista cifrada de correspondencias «usuario — UUID — fecha de emisión» fuera del VPS.

¿Cómo revocar rápidamente un perfil comprometido?

Elimine el UUID correspondiente del array clients, regenere la configuración y reinicie el servicio. Si existe riesgo de filtración no solo del UUID, sino también del URI completo con short ID y public key, cambie el short ID. Si sospecha de la filtración de la private key, cree un nuevo par X25519, sustituya la private key en el servidor y actualice la public key en todos los clientes de confianza. Después de los cambios, compruebe los registros y las copias de seguridad de la configuración.

Conclusiones y próximos pasos

Ahora dispone de un esquema básico de VLESS Reality en un VPS protegido y de un proceso claro para elegir SNI: el dominio se comprueba por DNS, TLS 1.3, certificado, estabilidad y accesibilidad desde redes de clientes reales. La regla principal es no buscar un dominio popular «mágico», sino utilizar un host HTTPS público técnicamente predecible y comprobar regularmente su disponibilidad.

1. Añada un segundo servidor independiente en otra ubicación y prepare un perfil de cliente de respaldo.
2. Cree UUID independientes para dispositivos y usuarios, y revoque periódicamente las credenciales no utilizadas.
3. Una vez al mes, compruebe las actualizaciones de Xray-core, el estado del firewall, el éxito de las copias de seguridad restic y los registros de errores.