Guía VLESS + Reality: Configuración de Proxy Seguro

abril 27, 2026 09:49 31 min

Palabras clave

Antes de profundizar en la configuración, aquí están los términos clave que probablemente necesitarán aclaración en esta guía.

Palabra clave	Definición
🔐 VLESS	Un protocolo proxy ligero del ecosistema V2Ray/Xray que autentica usuarios con un UUID y se empareja comúnmente con transportes de sigilo modernos como Reality.
🔀 Proxy vs VPN	Un proxy generalmente reenvía el tráfico de aplicaciones a través de un servidor, mientras que una VPN tradicional típicamente crea un túnel de red virtual completo para el dispositivo o sistema.
🎭 Reality	Un mecanismo de transporte de sigilo para Xray que hace que el tráfico se parezca mucho más a HTTPS normal utilizando fingerprints TLS similares a navegadores y validación especial basada en claves.
🔍 DPI (Inspección Profunda de Paquetes)	Una técnica de filtrado de red que analiza patrones de paquetes, handshakes y fingerprints de protocolo para identificar y bloquear tráfico como VPNs y proxies.
🖥️ VPS	Un Servidor Privado Virtual que alquilas y controlas remotamente, que actúa como la máquina anfitriona para tu configuración VLESS + Reality.
⚙️ 3x-ui	Un panel de gestión basado en web para Xray que te permite crear inbounds, usuarios y configuraciones de Reality sin editar JSON manualmente.
🚀 Xray	El motor proxy central que se ejecuta debajo de 3x-ui y que realmente maneja VLESS, Reality, enrutamiento y conexiones de clientes.
🆔 UUID	Un identificador único asignado a cada cliente y utilizado por VLESS como el valor de autenticación principal.
🌐 SNI	Server Name Indication, un campo TLS que le dice al servidor qué nombre de host se está solicitando y debe coincidir correctamente con la configuración del objetivo de Reality.
🧬 Par de claves x25519	El par de claves pública/privada utilizado por Reality para que los clientes aprobados puedan completar la conexión mientras que los sondeos no deseados se tratan de manera diferente.
🔑 Clave pública vs clave privada	La clave pública se comparte con el cliente para que pueda conectarse, mientras que la clave privada permanece solo en el servidor y nunca debe exponerse.
🧭 Fingerprint uTLS	Un fingerprint de cliente TLS que imita navegadores, como chrome, utilizado para hacer que la conexión se parezca al tráfico ordinario de navegadores.
📡 Inbound	La configuración del listener del lado del servidor en Xray/3x-ui que define cómo se conectan los clientes, incluyendo protocolo, puerto, transporte y configuración de seguridad.
⚡ BBR	Un algoritmo de control de congestión TCP de Google que puede mejorar el rendimiento y la capacidad de respuesta en algunas rutas de red de VPS.
✅ Validación ACME	El paso de verificación pública utilizado por servicios de certificados como Let’s Encrypt para confirmar que tu servidor o dominio es accesible y está autorizado para solicitar el certificado.

Configuración de VLESS VPN con Reality Stealth en 2026

La frustración es familiar: configuras un servidor VPN, todo funciona perfectamente, y entonces una mañana te despiertas para descubrir que está bloqueado. La conexión que funcionaba ayer falla hoy. Sin cambios de tu parte, sin embargo, de repente nada funciona. Este no es un escenario hipotético—es la realidad de usar protocolos VPN tradicionales en 2026, donde la tecnología de inspección profunda de paquetes ha evolucionado para identificar y bloquear incluso el tráfico correctamente encriptado.

La solución no es un algoritmo de encriptación diferente o un protocolo más rápido—es un enfoque fundamentalmente diferente sobre cómo aparece tu tráfico en la red. VLESS combinado con el protocolo stealth Reality es uno de los enfoques autohospedados más efectivos disponibles en 2026 para hacer que el tráfico proxy se parezca mucho más al tráfico HTTPS ordinario. Esta guía te lleva a través del despliegue de tu propio servidor VLESS + Reality usando el panel de control 3x-ui, desde entender por qué este enfoque funciona hasta tener una conexión funcional en tu dispositivo.

El Problema: Por Qué las VPN Estándar se Bloquean

Los días en que un simple servidor OpenVPN o WireGuard funcionaba de forma fiable durante meses—o incluso años—han terminado. La tecnología de Inspección Profunda de Paquetes (DPI) ha avanzado dramáticamente, y ya no se trata solo de detectar tráfico sin cifrar. Los sistemas DPI modernos examinan múltiples características de tu tráfico de red para identificar conexiones VPN con una precisión notable.

DPI analiza varios aspectos al inspeccionar tu tráfico. Los tamaños de paquete revelan patrones que no coinciden con la navegación web normal—los protocolos VPN tradicionales producen distribuciones de tamaño de paquete distintivas que los algoritmos entrenados pueden reconocer. Los patrones de tiempo también importan; el intervalo entre paquetes en un handshake VPN difiere del comportamiento legítimo del navegador. Y cuando un protocolo utiliza TLS, su fingerprint TLS importa: si tu cliente inicia una conexión con parámetros que no coinciden con ningún navegador real, el sistema puede marcarlo.

Considera qué sucede cuando te conectas usando OpenVPN o WireGuard estándar. El tráfico está cifrado, pero aún tiene una forma reconocible. OpenVPN a menudo expone un handshake TLS y un patrón de tráfico que no parece una sesión de navegador ordinaria. WireGuard no utiliza TLS en absoluto, pero su handshake basado en UDP y el comportamiento de paquetes siguen siendo lo suficientemente distintivos para destacar en redes filtradas. Es como tener un pasaporte con el código de país incorrecto—el documento es válido, pero los detalles no coinciden con ningún viajero legítimo.

En 2026, este bloqueo ocurre más rápido que nunca. Donde una vez un servidor VPN recién implementado podría funcionar durante meses antes de ser detectado, ahora los servidores nuevos pueden identificarse en cuestión de días o incluso horas después de entrar en funcionamiento. El bloqueo también es más generalizado, ocurriendo a nivel de ISP, a nivel de red corporativa, y en algunas jurisdicciones, a nivel de firewall nacional. Necesitas una solución que no solo cifre tu tráfico—que haga que tu tráfico parezca algo completamente diferente.

¿Qué es VLESS? El protocolo explicado

VLESS significa «VMess Less»—un nombre que refleja directamente su filosofía de diseño. Fue creado como un sucesor más ligero y simple del protocolo VMess, que era el protocolo de transporte predeterminado original en el proyecto V2Ray. Mientras que VMess agrupaba cifrado, autenticación y transporte en un sistema fuertemente acoplado, VLESS elimina las capas innecesarias y deja un protocolo de transporte limpio y sin estado.

A diferencia de su predecesor VMess, VLESS no tiene dependencia de tiempo. VMess requería relojes sincronizados entre cliente y servidor y utilizaba un mecanismo AlterID que se ha convertido en una huella digital reconocible. VLESS elimina ambos requisitos, haciéndolo más ligero y más sencillo de configurar. El mecanismo de autenticación utiliza UUID (Identificador Único Universal)—el mismo formato que encuentras en sistemas de autenticación estándar, lo que lo hace familiar para trabajar con él.

Aquí está la distinción crítica: VLESS funciona como un proxy, no como un túnel VPN completo. El protocolo redirige tu tráfico a través del servidor en lugar de crear una interfaz de red virtual completa. Para la mayoría de usuarios, esta distinción es académica—el resultado funcional es exactamente lo que esperas de una VPN: tu tráfico parece originarse desde la dirección IP del servidor. Pero esta arquitectura de proxy es precisamente por qué VLESS funciona tan bien con Reality, ya que la sobrecarga de protocolo más ligera permite que el mecanismo de sigilo funcione sin interferencias.

El diseño de proxy también significa menos sobrecarga en comparación con los protocolos VPN tradicionales. No hay interfaz de túnel a nivel de kernel que gestionar, no hay capas de cifrado adicionales más allá de lo necesario, y el protocolo fue diseñado desde cero para funcionar con mecanismos de sigilo modernos basados en TLS. Esta simplicidad es una característica, no una limitación—significa menos cosas que pueden salir mal y menos huellas digitales que pueden ser detectadas.

Entendiendo la Realidad: La Tecnología Encubierta

Reality es lo que transforma VLESS de un simple protocolo proxy en algo mucho más difícil de distinguir del tráfico web encriptado ordinario. El mecanismo es elegante en su simplicidad: en lugar de intentar ocultar lo que estás haciendo, Reality hace que tu tráfico parezca algo completamente diferente.

Reality logra esto mediante una técnica que opera a nivel del handshake TLS. Cuando un cliente se conecta a tu servidor, envía un ClientHello TLS que imita un navegador real, utilizando la librería uTLS para replicar la huella digital de Chrome, Firefox u otro navegador popular. El servidor valida la conexión usando el material de clave de Reality y los parámetros del cliente construidos alrededor de un par de claves x25519. Si el cliente presenta los valores de Reality esperados, la conexión procede como un proxy VLESS. Si no lo hace—lo que sucede cuando un sistema DPI o una sonda activa golpea tu servidor—el tráfico se reenvía a un sitio web legítimo como www.microsoft.com o www.apple.com. Para el sistema de sondeo, tu servidor parece un sitio web normal en lugar de un endpoint proxy obvio.

Piénsalo como usar un uniforme. Un guardia fronterizo inspeccionando vehículos no revisa cada coche a fondo—deja pasar los que se ven legítimos según su registro, placas y apariencia del conductor. Tu tráfico viste el uniforme de una gran corporación, así que el inspector de red lo deja pasar sin la inspección detallada que revelaría que en realidad es algo más. La huella digital uTLS es el disfraz, y el intercambio de claves x25519 es el apretón de manos secreto que solo tu cliente conoce.

Un punto crítico: no necesitas tu propio dominio para que esto funcione. Los métodos de sigilo anteriores te requerían poseer un dominio y obtener certificados Let’s Encrypt, lo que creaba un rastro de papel y complejidad adicional. Reality no requiere nada más que una dirección IP de VPS. Los sitios web de destino (Microsoft, Apple, Google) tienen un tiempo de actividad cercano al 100% y soportan el protocolo TLS 1.3 más reciente, lo que los hace anclas perfectas para esta técnica.

El puerto 443 le da a este disfraz su mejor oportunidad de mimetizarse. El tráfico HTTPS estándar normalmente usa el puerto 443, así que mantener Reality en ese puerto hace que la conexión se vea mucho más cercana a la navegación web ordinaria. Otros puertos pueden funcionar técnicamente, pero debilitan el camuflaje porque ya no coinciden con la forma predeterminada del tráfico HTTPS cotidiano.

Conceptos Erróneos Comunes

Antes de continuar, aclaremos tres conceptos erróneos que confunden a quienes exploran VLESS + Reality por primera vez.

«VLESS es una VPN.» En términos técnicos, VLESS es un protocolo proxy, no una VPN en el sentido tradicional. No hay interfaz TUN/TAP, no hay adaptador de red virtual y no hay manipulación de tabla de enrutamiento. Sin embargo, desde una perspectiva funcional del usuario, proporciona exactamente lo que esperarías de una VPN: tu tráfico de internet parece provenir de la dirección IP del servidor. La distinción importa para ingenieros de red pero rara vez importa para usuarios finales.

«Reality necesita un dominio.» Esto era cierto en técnicas de sigilo anteriores que usaban dominios de propiedad propia y certificados de Let’s Encrypt. Reality fue diseñado específicamente para funcionar sin ningún dominio que controles. Utiliza mimicry de fingerprint de navegador y autenticación de clave x25519, lo que significa que no necesitas registrar, gestionar ni renovar nada. Configúralo una vez y continuará funcionando.

«Esto es inviolable.» Nada es inviolable. Reality es altamente resistente a la detección y bloqueo porque genuinamente parece tráfico HTTPS normal. Pero no es inmune a futuras mejoras en tecnología DPI, posible fingerprinting de protocolo o ataques dirigidos. Lo que proporciona es la mejor protección disponible en 2026 contra las formas más comunes de filtrado de red. Trátalo como una solución robusta, no como un escudo mágico.

Lo que necesitas antes de comenzar

Esta es una lista de verificación práctica. Antes de comenzar la implementación, verifica que tengas todo en su lugar. Esto evita llegar a mitad de la instalación y descubrir que te falta un componente crítico.

Necesitarás un VPS de cualquier proveedor (p. ej. AvaHost), y servicios similares funcionan igual de bien. Para un rendimiento típico de un solo usuario, un plan básico con 1 núcleo de CPU y 1 GB de RAM es suficiente. El servidor debe ejecutar Ubuntu 22.04 LTS o 24.04 LTS; estas versiones tienen soporte de kernel para las características de red requeridas de forma nativa.

El acceso root SSH es esencial. Necesitas la capacidad de conectarte a tu servidor a través de la línea de comandos y ejecutar comandos privilegiados. La mayoría de proveedores de VPS ofrecen esto por defecto: recibirás una dirección IP, nombre de usuario (generalmente root) y una contraseña o clave SSH después del despliegue.

Para aplicaciones cliente, dependiendo de tus dispositivos necesitarás: v2rayNG para Android, v2rayN para Windows, V2Box o Streisand para macOS, y Shadowrocket o FoXray para iOS. Cubriremos estos en detalle en la sección de aplicaciones cliente más adelante en esta guía.

Una ventaja significativa del método Reality: no necesitas un dominio que controles. Muchas configuraciones sigilosas requieren que registres y gestiones uno, pero Reality puede funcionar directamente desde la IP del VPS mientras toma prestada la apariencia de un destino TLS legítimo.

Una breve nota sobre consideraciones legales: Las técnicas descritas en esta guía están destinadas a necesidades legítimas de privacidad y acceso. Las leyes de filtrado de Internet varían significativamente según la jurisdicción. Asegúrate de que tu uso de estas herramientas cumple con las leyes aplicables en tu región.

Preparación del servidor: BBR y conceptos básicos

Con los requisitos previos verificados, preparemos el servidor. Esta fase optimiza tu VPS antes de instalar cualquier software, garantizando el máximo rendimiento desde el inicio.

💡 CONSEJO: Utiliza BBR antes de desplegar — a menudo mejora el rendimiento y la latencia en enlaces con restricciones o latencia más alta.

Primero, actualiza los paquetes del sistema. Esto garantiza que tengas las últimas actualizaciones de seguridad y dependencias requeridas:
apt update && apt upgrade -y
Este paso puede tardar entre 1 y 5 minutos dependiendo de tu proveedor de VPS y la velocidad de la red. Algunos proveedores preactualizan sus imágenes durante el despliegue, por lo que esto podría completarse rápidamente en algunos sistemas.

A continuación, habilita el control de congestión Google BBR. BBR (Bottleneck Bandwidth and Round-trip propagation time) es el algoritmo de control de congestión de Google. En lugar de depender principalmente de la pérdida de paquetes como señal, intenta modelar el ancho de banda disponible y el tiempo de ida y vuelta de forma más directa, lo que puede mejorar el rendimiento y la capacidad de respuesta en algunos enlaces de VPS.

# Verify BBR module is available
 lsmod | grep tcp_bbr

Si no aparece nada, carga el módulo manualmente:
modprobe tcp_bbr

Ahora crea la configuración sysctl para habilitar BBR de forma persistente:

cat >> /etc/sysctl.d/99-bbr.conf << 'EOF'
 net.core.default_qdisc=fq
 net.ipv4.tcp_congestion_control=bbr
 EOF

Aplica la configuración:
sysctl -p /etc/sysctl.d/99-bbr.conf
Verifica que BBR esté activo:

sysctl net.ipv4.tcp_congestion_control
 sysctl net.ipv4.tcp_available_congestion_control

Deberías ver bbr como el algoritmo activo.

Algunos sistemas se benefician de un reinicio después de habilitar BBR — garantiza que el módulo se cargue correctamente y que todas las optimizaciones de red surtan efecto:
reboot
Ahora asegúrate de que el puerto 443 sea accesible. Si planeas utilizar el flujo integrado de Let’s Encrypt del instalador 3x-ui para el panel, permite también 80/tcp — ese puerto se utiliza para la validación del certificado ACME, no para el panel en sí. Si tu proveedor de VPS también tiene un firewall en la nube o una capa de grupo de seguridad, permite los mismos puertos allí también. En Ubuntu, el camino más seguro suele ser UFW.

# If this is a remote VPS and you're enabling UFW for the first time, allow SSH before enabling the firewall
 ufw allow OpenSSH
 # Allow HTTPS-style Reality traffic
 ufw allow 443/tcp
 # Allow ACME validation for the 3x-ui panel's built-in Let's Encrypt setup
 ufw allow 80/tcp
 # Review rules, then enable only if UFW is not already active
 ufw status
 ufw enable

⚠️ ADVERTENCIA: El puerto 443 es fuertemente recomendado porque coincide con el tráfico HTTPS normal. Otros puertos pueden funcionar técnicamente, pero se mezclan menos naturalmente y hacen que la configuración sea más fácil de detectar.

Tu servidor ahora está optimizado y listo para la instalación de 3x-ui.

Instalación del Panel 3x-ui

El panel de control web 3x-ui proporciona una interfaz gráfica para gestionar tu servidor VLESS + Reality. Se encarga de gran parte de la configuración de Xray por ti y hace que la generación de claves sea mucho más sencilla que editar JSON manualmente. Utilizaremos el fork de MHSanaei, que se mantiene activamente y es compatible con los protocolos actuales, incluido Reality. Una advertencia: el proyecto en sí presenta 3x-ui como un panel de uso personal, así que trátalo como una capa de conveniencia administrativa y asegura el panel cuidadosamente.

Antes de ejecutar el instalador, ten en cuenta un requisito fácil de pasar por alto: si deseas que la configuración integrada de Let’s Encrypt del instalador emita un certificado SSL para el panel, 80/tcp debe estar abierto y ser accesible desde Internet público. Este puerto de validación ACME es independiente del puerto del panel que elijas durante la configuración.

Ejecuta el comando de instalación:

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

Las versiones actuales del instalador no comienzan con el menú antiguo numerado Instalar / Actualizar / Desinstalar que muchos tutoriales aún muestran. En su lugar, el script inicia la instalación inmediatamente, instala las dependencias que falten, descarga la versión más reciente y luego te guía a través de los mensajes de configuración del panel.

Un flujo de instalación típico ahora se ve así:

Elige si deseas establecer un puerto de panel personalizado o dejar que el instalador genere uno aleatorio.
Deja que el instalador genere un nombre de usuario, contraseña y webBasePath aleatorios.
Elige cómo configurar el SSL del panel:
- 1 = Let’s Encrypt para un dominio
- 2 = Let’s Encrypt para la IP del servidor
- 3 = usar un certificado existente
Completa los mensajes del certificado si utilizas el flujo integrado de Let’s Encrypt.

⚠️ IMPORTANTE: El puerto del panel no es lo mismo que el puerto de validación ACME. Podrías ejecutar el panel en un puerto aleatorio como 13525 y aún así necesitar que 80/tcp público esté abierto para que Let’s Encrypt pueda validar el certificado.

La regla importante es simple: utiliza las credenciales exactas, la ruta y la URL imprimidas por tu propio instalador, no suposiciones copiadas de tutoriales antiguos.

Tu salida final se verá más así:

Username:    GENERATED_USERNAME
Password:    GENERATED_PASSWORD
Port:        13525
WebBasePath: RANDOM_PATH
Access URL:  https://YOUR_SERVER_IP:13525/RANDOM_PATH

Verifica que el servicio se está ejecutando:

systemctl status x-ui

Esta verificación es importante. Busca específicamente la línea del servidor web en la salida de estado:

Si ves Web server running HTTPS …, el SSL del panel funciona correctamente.
Si ves Web server running HTTP …, el panel se instaló correctamente pero la configuración de SSL no se completó.

Accede al panel utilizando la URL exacta, nombre de usuario y contraseña generados por tu propia instalación. No asumas que la ruta es /panel, y no asumas que las credenciales son admin/admin a menos que tu propia instalación lo indique explícitamente.

💡 CONSEJO 1: Para ver nuevamente la configuración actual del panel e imprimir la URL de acceso, en la CLI ejecuta el comando «x-ui» y elige el número 10 «Ver configuración actual» de la salida del menú.

💡 CONSEJO 2: Si la URL de acceso no se carga, asegúrate de que el puerto del panel 3x-ui esté abierto en el firewall de tu VPS. Por ejemplo, si tu panel se ejecuta en el puerto «13525», permítelo con: » ufw allow 13525/tcp «. Reemplaza 13525 con el puerto real que configuraste para el panel 3x-ui.

Si el instalador finaliza pero systemctl status x-ui muestra HTTP en lugar de HTTPS

La causa más común es que 80/tcp no era accesible desde Internet público durante la validación de Let’s Encrypt. En ese caso, el panel puede instalarse e iniciarse, pero la emisión del certificado falla.

Primero, corrige el firewall:

ufw allow 80/tcp
 ufw status

Si tu proveedor de VPS tiene una capa de firewall en la nube o grupo de seguridad, permite 80/tcp allí también. Luego vuelve a ejecutar la configuración del certificado del panel desde el script de gestión de 3x-ui:

x-ui

Para un certificado de panel basado en IP, elige:

19 → 6 (Obtener SSL para dirección IP)

Para un certificado de panel basado en dominio, elige:

19 → 1 (Obtener SSL (Dominio))

Después de que se emita el certificado, verifica nuevamente:

systemctl status x-ui

Deseas que la salida de estado muestre Web server running HTTPS … antes de continuar.

💡 CONSEJO: Guarda las credenciales generadas y la URL del panel inmediatamente. También ten en cuenta que el resumen del instalador puede ser engañoso si la emisión del certificado falla — si el bloque final imprime una URL HTTPS pero systemctl status x-ui aún muestra HTTP, confía en la salida del estado del servicio y corrige SSL antes de continuar.

Configuración de VLESS + Reality Inbound

Este es el paso de configuración crítico donde tu sistema tipo VPN se crea realmente. Dentro del panel 3x-ui, navega a Inbounds → Add Inbound.

Configura los campos de la siguiente manera:

Campo	Valor	Notas
Protocol	VLESS	Selecciona del menú desplegable
Listen IP	0.0.0.0	Predeterminado / todas las interfaces
Port	443	Recomendado para el camuflaje HTTPS más natural
Client → Authentication	Dejar vacío / predeterminado	No uses Get New keys para esta configuración básica
Client → decryption	none	Requerido para VLESS
Client → encryption	none	Dejar en predeterminado
Client → Flow	xtls-rprx-vision	Establece esto en la subsección Client. Si aún no ves este campo, primero establece Transmission en TCP (RAW) y Security en reality.
Transmission	TCP (RAW)	Usa transporte TCP directo
Security	reality	Selecciona de las opciones de seguridad
uTLS	chrome	Usa una huella digital de navegador común
Target	www.microsoft.com:443	Objetivo TLS 1.3 estable para fallback/probing
SNI	www.microsoft.com	Mantenlo alineado con Target
Short IDs	Generar o usar predeterminado del panel	Copia un valor generado al cliente
SpiderX	/	Predeterminado simple
Public Key	Generar con Get New Cert	Copia esto al cliente
Private Key	Generar con Get New Cert	Mantén esto solo en el servidor

📋 NOTA: Deja los otros campos visibles — como Total Flow, Traffic Reset, Duration, Fallbacks, Proxy Protocol, HTTP Obfuscation, Sockopt, External Proxy, Show, Xver, Max Time Diff, Min Client Ver, Max Client Ver, Sniffing, y los campos ML-DSA — en sus valores predeterminados para esta configuración básica.

Finalmente, haz clic en Save para crear el inbound.

⚠️ ADVERTENCIA: El puerto 443 es el mejor predeterminado porque coincide con el tráfico HTTPS ordinario. Si lo cambias, el inbound puede seguir funcionando, pero ya no se camufla tan limpiamente.

⚠️ ADVERTENCIA: El objetivo Reality debe soportar TLS 1.3 — Microsoft, Apple y Google son apuestas seguras. Usar un objetivo que no soporta TLS 1.3 causará que Reality falle, ya que el protocolo está diseñado específicamente para handshakes TLS 1.3.

La razón por la que estos valores importan: el puerto 443 te da el perfil HTTPS más creíble, un objetivo TLS 1.3 estable da a los probes un lugar legítimo donde aterrizar, y la huella digital chrome mantiene el lado del cliente alineado con una de las huellas digitales de navegador más comunes en internet. Comienza simple, obtén una ruta funcionando, luego expande más tarde si necesitas múltiples objetivos.

Gestión de usuarios en 3x-ui

Con el inbound configurado, necesitas crear conexiones de usuario que tus dispositivos utilizarán para autenticarse. En 3x-ui, navega a Inbounds → [Haz clic en tu menú de inbound VLESS] → Add Client.

Cada usuario obtiene un UUID único (generado automáticamente), junto con un correo electrónico para identificación y límites opcionales de tráfico/caducidad. Cuando creas un cliente, el panel genera los valores que necesitas para la conexión: dirección del servidor, UUID, flow, clave pública, ID corto y configuraciones relacionadas con SNI.

Al presionar el signo más («+») del inbound seleccionado, aparecerá la lista de usuarios.

Exportar un cliente

Para exportar los detalles de conexión de un único cliente, primero expande la fila del inbound para que la tabla de clientes sea visible. En la fila del cliente, utiliza las dos acciones de exportación por cliente:

Icono QR → abre el modal QR
Icono Info → abre el modal de detalles

Estos corresponden a los dos primeros métodos de compartición.

Código QR: Haz clic en el icono QR del cliente. Si las suscripciones están habilitadas, el modal QR puede mostrar dos códigos QR:

Suscripción → un código QR para la URL de suscripción del cliente
QR del cliente (etiquetado con el correo electrónico del cliente o identificador, como example@mail.com) → un código QR para el URI directo de VLESS Reality

El código QR de suscripción es útil para clientes que admiten actualizaciones automáticas. El código QR del cliente es la importación directa única para ese cliente específico.

Enlace de compartición / URL: Haz clic en el icono Info del cliente. En el modal de detalles, puedes ver dos tipos de exportación de texto:

URL de suscripción → un punto final de suscripción actualizable
URL → el URI directo de VLESS Reality para ese cliente

Utiliza el botón de copia junto a la sección URL para importación en escritorio.

Como mínimo, un URI directo de Reality utilizable debe incluir valores poblados como:

vless://[UUID]@[server]:[port]?type=tcp&security=reality&pbk=[public-key]&fp=chrome&sni=[SNI]&sid=[short-id]&spx=[SpiderX]#[email]

pbk= es la clave pública de Reality y pertenece al URI directo de VLESS. La URL de suscripción en sí generalmente no contendrá pbk= porque es solo el punto final de obtención; la configuración devuelta contiene los parámetros reales de Reality.

Algunas versiones de 3x-ui han tenido errores en los enlaces de compartición de Reality donde pbk= está vacío. Si el URI directo carece de pbk= o sid=, no confíes en él ciegamente. En ese caso, utiliza configuración manual en su lugar.

Configuración manual: No hay un botón de exportación «configuración manual» separado. En la práctica, la configuración manual significa ingresar los valores directamente en la aplicación del cliente o componer y verificar el URI final de VLESS Reality tú mismo a partir de los valores sin procesar. Recopila los valores requeridos de:

el modal Infodirección del servidor, puerto, UUID, flow y el URI directo
la configuración de Reality del inbound: SNI, clave pública, ID corto, fingerprint (chrome) y SpiderX (/) si es necesario

Puedes crear múltiples usuarios para diferentes dispositivos o diferentes personas. Cada UUID es independiente, por lo que revocar el acceso para un usuario no afecta a otros.

Configuración Manual de Xray (Resumen)

Algunos usuarios prefieren no utilizar una interfaz gráfica y desean editar la configuración de Xray directamente. En una instalación estándar de 3x-ui en Linux, la configuración de tiempo de ejecución activa se escribe en /usr/local/x-ui/bin/config.json, por lo que puede inspeccionarla o realizar cambios manuales temporales allí.

Trate ese archivo como un artefacto de tiempo de ejecución generado, no como la fuente de verdad del panel. 3x-ui reconstruye config.json a partir de su configuración respaldada por base de datos, por lo que las ediciones manuales pueden sobrescribirse cuando Xray se reinicia o cuando guarda cambios en el panel.

Antes de editarlo, cree una copia de seguridad:

cp /usr/local/x-ui/bin/config.json /usr/local/x-ui/bin/config.json.bak

La edición manual puede ser útil para pruebas rápidas o depuración, pero un JSON incorrecto puede impedir que Xray se inicie. Si 3x-ui satisface sus necesidades, manténgase en el panel para cambios persistentes y utilice ediciones directas de config.json solo para casos avanzados.

Aplicaciones Cliente por Plataforma

Para conectarte a tu servidor, necesitarás software cliente en tus dispositivos. Aquí está lo disponible:

Plataforma	Aplicaciones Recomendadas	Notas
Windows	v2rayN	Cliente GUI con integración en la bandeja del sistema
macOS	V2Box, Streisand	V2Box es gratuito; Streisand está en App Store
Android	v2rayNG, NekoBox	Ambas disponibles en GitHub y F-Droid
iOS	Shadowrocket, FoXray, V2Box	Shadowrocket es de pago; la disponibilidad de FoXray puede variar

Para Windows, v2rayN es la opción recomendada—está activamente mantenida, tiene una interfaz limpia y maneja la configuración Reality de forma nativa. Para móvil, v2rayNG y V2Box ambas soportan importación por código QR, lo que hace la configuración rápida.

📋 NOTA: La disponibilidad de aplicaciones cliente en plataformas Apple cambia frecuentemente. Si una aplicación listada no está disponible en tu región, consulta el sitio oficial del proyecto, el listado en App Store o la ruta de TestFlight antes de asumir que el problema es el protocolo en sí.

Conectando Tu Primer Cliente

Vamos a recorrer la conexión de un cliente Windows usando v2rayN—el proceso es similar en otras plataformas, pero esto te proporciona un ejemplo completo.

Paso 1: Descargar v2rayN

Visita https://github.com/2dust/v2rayN/releases y descarga la compilación actual de escritorio para Windows. A partir de 2026, la opción más simple suele ser v2rayN-windows-64-desktop.zip (o el paquete de escritorio equivalente actual que se muestre en la página de lanzamientos).

Paso 2: Extraer y Ejecutar

Extrae el ZIP en una carpeta (por ejemplo, C:v2rayN). Ejecuta v2rayN.exe. Las compilaciones de escritorio recientes suelen ser autónomas, por lo que normalmente no necesitas instalar un runtime de escritorio .NET separado. La aplicación aparece en tu bandeja del sistema.

Paso 3: Importar Configuración

Para esta conexión, utiliza la URL VLESS directa de 3x-ui—la que comienza con vless://—no la URL de suscripción. Si tu enlace Reality exportado carece de valores requeridos como pbk= o sid=, vuelve a la sección anterior de 3x-ui y utiliza los valores manuales de la configuración de entrada en su lugar.

En v2rayN, abre el menú Configuration en el área superior izquierda de la ventana. El método más sencillo es copiar la URL VLESS directa de 3x-ui y luego seleccionar Configuration → Import Share Links from clipboard. En la mayoría de las compilaciones, también puedes simplemente presionar Ctrl+V. Asegúrate de haber copiado primero la URL VLESS directa, para que la aplicación pueda pegar el valor.

Si la importación desde el portapapeles no es la opción deseada, también se puede utilizar el código QR o la importación manual.

Paso 4: Conectar

Después de que el cliente haya sido importado, para activar el túnel entre el cliente Windows y el servidor, presiona «Enable tunnel» en la parte inferior de la interfaz de v2rayN.

Paso 5: Verificar

Abre tu navegador y visita https://whatismyipaddress.com/ o https://ip.sb. La dirección IP que se muestre debe ser la IP de tu servidor, no tu IP local. Esto confirma que tu tráfico se está enrutando a través de la VPN.

Verificación de tu Configuración

La verificación de conexión confirma que todo funciona como se espera. Más allá de comprobar tu dirección IP en el navegador, hay algunas pruebas adicionales que vale la pena ejecutar.

Comprobación de Dirección IP: Visita https://whatismyipaddress.com/ o https://ip.sb mientras estés conectado. La dirección IP mostrada debe coincidir con la IP de tu servidor VPS, no con tu IP doméstica o de red local.

Prueba de Fuga DNS: Visita https://dnsleak.com o https://browserleaks.com/dns y ejecuta la prueba. Un cliente correctamente configurado no debe exponer tus resolvedores DNS locales normales mientras el proxy está activo.

Problemas Comunes y Soluciones

Problema	Causa	Solución
Sin conexión	Puerto 443 bloqueado	Verifica el firewall: ufw allow 443/tcp y la consola del proveedor cloud
El panel no se abre	URL incorrecta o suposición antigua de /panel	Usa la URL HTTPS exacta impresa por el instalador
El enlace importado no se conecta	Enlace de Reality sin pbk o sid	Inspecciona el enlace o cambia a configuración manual del cliente
Timeout de conexión	SNI incorrecto	Verifica que SNI coincida (www.microsoft.com) en la configuración del cliente
Error TLS	Fingerprint incorrecto o valores de Reality no coinciden	Establece fingerprint en chrome y reverifica SNI, clave pública e ID corto
Velocidad lenta	BBR no habilitado	Reactiva BBR según la sección de preparación del servidor
«Sin respuesta del servidor»	Firewall bloqueando	Verifica tanto el firewall del servidor como los grupos de seguridad del proveedor cloud

Si encuentras problemas, verifica que la configuración de tu cliente coincida exactamente con lo generado en 3x-ui: el UUID, SNI, clave pública, ID corto y flow deben coincidir entre servidor y cliente.

Próximos Pasos y Opciones Avanzadas

Ahora tienes una VPN VLESS + Reality funcional. A partir de aquí, hay varias mejoras disponibles:

Añade un inbound de respaldo con cuidado: Si realmente necesitas un fallback, puedes añadir algo como VMess + WebSocket como inbound secundario. Solo recuerda que cada inbound adicional aumenta la complejidad y te da una superficie más para asegurar y solucionar problemas.

Escala para múltiples usuarios: Crea clientes adicionales en 3x-ui para miembros de la familia o dispositivos. Cada uno obtiene un UUID único, y puedes rastrear el uso por separado.

Optimización del rendimiento: BBR ya está habilitado, pero puedes explorar optimización TCP/UDP, ajuste de búferes de red y ajuste TCP del lado del servidor para mejoras marginales.

Objetivos SNI alternativos: Aunque Microsoft/Apple/Google son confiables, algunos usuarios prefieren www.oracle.com u otros objetivos. El principio sigue siendo el mismo—cualquier sitio con certificados TLS 1.3 válidos funciona.

Seguridad del panel: Restringe el puerto del panel a tu propia IP de administrador si es posible, rota las credenciales si las elegiste manualmente, y considera instalar Fail2Ban para proteger el panel de intentos de fuerza bruta.

Conclusión

VLESS + Reality es una opción robusta de auto-hospedaje para 2026 si necesitas una configuración que se camufle mejor que los protocolos VPN tradicionales. Su ventaja no es invisibilidad mágica; es que el tráfico se parece mucho más al tráfico web encriptado ordinario que las conexiones de estilo OpenVPN o WireGuard en redes fuertemente filtradas.

Si comprendes el modelo mental—fingerprinting TLS similar al navegador, material de clave Reality, un objetivo creíble y un puerto HTTPS estándar—tendrás mucha más facilidad para desplegar, depurar y mantener la configuración. A partir de aquí, los pasos naturales siguientes son reforzar la seguridad del panel, agregar más dispositivos cliente y validar qué objetivos y aplicaciones cliente funcionan mejor en tu propio entorno. Para hospedaje, proveedores como AvaHost pueden darte una base estable para ejecutar tu configuración VLESS + Reality, garantizando tiempo de actividad confiable y gestión directa.