Español
Guía de VLESS + Reality: Configuración segura de proxy
Palabras clave
Antes de profundizar en la configuración, aquí están los términos clave que probablemente necesiten aclaración en esta guía.
| Palabra clave | Definición |
|---|---|
| 🔐 VLESS | Un protocolo proxy ligero del ecosistema V2Ray/Xray que autentica a los usuarios con un UUID y normalmente se combina con transportes stealth modernos como Reality. |
| 🔀 Proxy vs VPN | Un proxy normalmente reenvía el tráfico de la aplicación a través de un servidor, mientras que una VPN tradicional suele crear un túnel de red virtual completo para el dispositivo o sistema. |
| 🎭 Reality | Un mecanismo de transporte stealth para Xray que hace que el tráfico se parezca mucho más al HTTPS normal mediante huellas TLS similares a las de un navegador y una validación especial basada en claves. |
| 🔍 DPI (Deep Packet Inspection) | Una técnica de filtrado de red que analiza patrones de paquetes, handshakes y huellas de protocolo para identificar y bloquear tráfico como VPNs y proxies. |
| 🖥️ VPS | Un Virtual Private Server que alquilas y controlas de forma remota, y que actúa como la máquina host 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 ajustes de Reality sin editar JSON manualmente. |
| 🚀 Xray | El motor proxy principal que funciona debajo de 3x-ui y que realmente gestiona VLESS, Reality, el enrutamiento y las conexiones de clientes. |
| 🆔 UUID | Un identificador único asignado a cada cliente y usado por VLESS como el valor principal de autenticación. |
| 🌐 SNI | Server Name Indication, un campo TLS que indica al servidor qué hostname se está solicitando y debe coincidir correctamente con la configuración de destino de Reality. |
| 🧬 x25519 Key Pair | El par de claves pública/privada usado por Reality para que los clientes aprobados puedan completar la conexión mientras las sondas no deseadas se tratan de forma diferente. |
| 🔑 Public key vs private key | La public key se comparte con el cliente para que pueda conectarse, mientras que la private key permanece solo en el servidor y nunca debe exponerse. |
| 🧭 uTLS Fingerprint | Una huella TLS de cliente que imita a un navegador, como chrome, usada para hacer que la conexión se parezca al tráfico normal de un navegador. |
| 📡 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 ajustes 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. |
| ✅ ACME validation | El paso de verificación pública usado por servicios de certificados como Let’s Encrypt para confirmar que tu servidor o dominio es accesible y puede 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 luego una mañana te despiertas y descubres que está bloqueado. La conexión que funcionó ayer falla hoy. No has cambiado nada, pero 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 Deep Packet Inspection ha evolucionado para identificar y bloquear incluso el tráfico correctamente cifrado.
El problema: por qué se bloquean las VPNs estándar
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 Deep Packet Inspection (DPI) ha avanzado enormemente, y ya no se trata solo de detectar tráfico no cifrado. Los sistemas DPI modernos examinan múltiples características de tu tráfico de red para identificar conexiones VPN con una precisión notable.
Considera lo que ocurre cuando te conectas usando OpenVPN o WireGuard estándar. El tráfico está cifrado, pero sigue teniendo una forma reconocible. OpenVPN a menudo expone un handshake TLS y un patrón de tráfico que no se parece a una sesión normal de navegador. WireGuard no usa TLS en absoluto, pero su handshake basado en UDP y el comportamiento de sus paquetes siguen siendo lo bastante distintivos como para destacar en redes filtradas. Es como tener un pasaporte con el código de país equivocado: 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 antes una VPN recién desplegada podía funcionar durante meses antes de ser detectada, ahora los nuevos servidores pueden identificarse en cuestión de días o incluso horas después de ponerse en línea. 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 distinto.
¿Qué es VLESS? Explicación del protocolo
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. Donde VMess agrupaba cifrado, autenticación y transporte en un sistema estrechamente acoplado, VLESS elimina las capas innecesarias y deja un protocolo de transporte limpio y sin estado.
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 los 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 IP del servidor. Pero esta arquitectura proxy es precisamente por lo que VLESS funciona tan bien con Reality, ya que la menor sobrecarga del protocolo permite que el mecanismo stealth opere sin interferencias.
El diseño proxy también implica menos sobrecarga en comparación con los protocolos VPN tradicionales. No hay una 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 stealth modernos basados en TLS. Esta simplicidad es una ventaja, no una limitación: significa menos cosas que pueden salir mal y menos huellas que pueden ser detectadas.
Entendiendo Reality: la tecnología stealth
Reality es lo que transforma VLESS de otro protocolo proxy en algo mucho más difícil de distinguir del tráfico web cifrado normal. El mecanismo es elegante en su simplicidad: en lugar de intentar ocultar lo que haces, Reality hace que tu tráfico parezca algo completamente distinto.
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 TLS ClientHello que imita a un navegador real, usando la biblioteca uTLS para replicar la huella de Chrome, Firefox u otro navegador popular. Luego el servidor valida la conexión usando el material de claves de Reality y parámetros del cliente construidos alrededor de un x25519 key pair. Si el cliente presenta los valores Reality esperados, la conexión continúa como un proxy VLESS. Si no lo hace, que es lo que ocurre 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.
Piensa en ello como llevar un uniforme. Un guardia fronterizo que inspecciona vehículos no revisa cada coche a fondo: deja pasar los que parecen legítimos según su registro, matrícula 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 otra cosa. La huella uTLS es el disfraz, y el intercambio 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 stealth anteriores requerían que poseyeras un dominio y obtuvieras certificados Let’s Encrypt, lo que creaba un rastro documental y complejidad adicional. Reality no requiere nada más que una IP de VPS. Los sitios de destino (Microsoft, Apple, Google) tienen una disponibilidad cercana al 100% y soportan el último protocolo TLS 1.3, lo que los convierte en anclas perfectas para esta técnica.
El puerto 443 le da a este disfraz su mejor oportunidad de pasar desapercibido. El tráfico HTTPS estándar normalmente usa el puerto 443, así que mantener Reality en ese puerto hace que la conexión se parezca mucho más a la navegación web normal. 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 seguir adelante, abordemos tres conceptos erróneos que suelen confundir 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 se manipulan tablas de enrutamiento. Sin embargo, desde la perspectiva funcional del usuario, proporciona exactamente lo que esperarías de una VPN: tu tráfico de internet parece provenir de la IP del servidor. La distinción importa para los ingenieros de red, pero rara vez importa para los usuarios finales.
«Reality necesita un dominio.» Esto era cierto en técnicas stealth anteriores que usaban dominios propios y certificados Let’s Encrypt. Reality fue diseñado específicamente para funcionar sin ningún dominio que controles. Usa imitación de huella de navegador y autenticación con x25519 key, lo que significa que no necesitas registrar, gestionar ni renovar nada. Lo configuras una vez y sigue funcionando.
«Esto es imposible de hackear.» Nada es imposible de hackear. Reality es altamente resistente a la detección y al bloqueo porque realmente parece tráfico HTTPS normal. Pero no es inmune a futuras mejoras en la tecnología DPI, al posible fingerprinting de protocolo o a ataques dirigidos. Lo que ofrece 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 empezar
Necesitarás un VPS de cualquier proveedor (es decir, AvaHost), y servicios similares también funcionan bien. Para un rendimiento típico de un solo usuario, un plan básico con 1 CPU core y 1GB RAM es suficiente. El servidor debe ejecutar Ubuntu 22.04 LTS o 24.04 LTS; estas versiones tienen soporte de kernel para las funciones de red requeridas desde el primer momento.
El acceso Root SSH es esencial. Necesitas poder conectarte a tu servidor por línea de comandos y ejecutar comandos privilegiados. La mayoría de los proveedores de VPS lo ofrecen por defecto: recibirás una IP, un nombre de usuario (normalmente root) y una contraseña o una SSH key después del despliegue.
Para las aplicaciones cliente, según tus dispositivos necesitarás: v2rayNG para Android, v2rayN para Windows, V2Box o Streisand para macOS, y Shadowrocket o FoXray para iOS. Cubriremos esto en detalle en la sección de aplicaciones cliente más adelante en esta guía.
Una ventaja importante del método Reality: no necesitas un dominio que controles. Muchas configuraciones stealth 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 pensadas para 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 el uso de estas herramientas cumpla 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 principio.
💡 TIP: Usa BBR antes del despliegue — a menudo mejora el rendimiento y la latencia en enlaces limitados o de mayor latencia.
Primero, actualiza los paquetes del sistema. Esto garantiza que tengas las últimas actualizaciones de seguridad y dependencias necesarias:
apt update && apt upgrade -yEste paso puede tardar entre 1-5 minutos dependiendo de tu proveedor de VPS y de 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 VPS.
# Verify BBR module is available
lsmod | grep tcp_bbrSi 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.confVerifica que BBR esté activo:
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_controlDeberías ver bbr como el algoritmo activo.
Algunos sistemas se benefician de un reinicio después de habilitar BBR: esto asegura que el módulo se cargue correctamente y que todas las optimizaciones de red surtan efecto:
rebootAhora asegúrate de que el puerto 443 sea accesible. Si planeas usar el flujo integrado de Let’s Encrypt del instalador de 3x-ui para el panel, permite también 80/tcp — ese puerto se usa para la validación de certificados ACME, no para el panel en sí. Si tu proveedor de VPS también tiene una capa de cloud firewall o security group, permite los mismos puertos allí también. En Ubuntu, la ruta más segura 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 muy recomendable porque coincide con el tráfico HTTPS normal. Otros puertos pueden funcionar técnicamente, pero se camuflan menos de forma natural 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
Antes de ejecutar el instalador, ten en cuenta un requisito fácil de pasar por alto: si quieres 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 antiguo menú numerado Install / Update / Uninstall que muchos tutoriales todavía muestran. En su lugar, el script inicia la instalación de inmediato, instala cualquier dependencia que falte, descarga la última versión y luego te guía por los mensajes de configuración del panel.
Un flujo de instalación típico ahora se ve así:
- Elige si quieres establecer un puerto personalizado para el panel o dejar que el instalador genere uno aleatorio.
- Deja que el instalador genere un nombre de usuario, una contraseña y un 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 usas el flujo integrado de Let’s Encrypt.
⚠️ IMPORTANTE: El puerto del panel no es lo mismo que el puerto de validación ACME. Puedes ejecutar el panel en un puerto aleatorio como 13525 y aun así necesitar 80/tcp público abierto para que Let’s Encrypt pueda validar el certificado.
La regla importante es simple: usa las credenciales, la ruta y la URL exactas que imprime tu propio instalador, no supongas valores copiados de tutoriales antiguos.
Tu salida final se verá más o menos 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 esté en ejecución:
systemctl status x-ui
Esta comprobación importa. Mira específicamente la línea del servidor web en la salida del 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 SSL no se completó.
Accede al panel usando la URL, el nombre de usuario y la contraseña exactos 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.
💡 TIP 1: Para volver a ver la configuración actual del panel e imprimir el Access URL, en la CLI ejecuta el comando «x-ui» y elige el número 10 «View Current Settings» del menú.
💡 TIP 2: Si el Access URL no carga, asegúrate de que el puerto del panel 3x-ui esté abierto en el firewall de tu VPS. Por ejemplo, si tu panel está ejecutándose en el puerto «13525», permítelo con: » ufw allow 13525/tcp «. Sustituye 13525 por el puerto real que configuraste para el panel 3x-ui.
Si el instalador termina 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 seguir instalándose e iniciándose, pero la emisión del certificado falla.
Primero corrige el firewall:
ufw allow 80/tcp
ufw statusSi tu proveedor de VPS tiene una capa de cloud firewall o security group, permite también 80/tcp allí. Luego vuelve a ejecutar la configuración del certificado del panel desde el script de gestión de 3x-ui:
x-uiPara un certificado del panel basado en IP, elige:
- 19 → 6 (Get SSL for IP Address)
Para un certificado del panel basado en dominio, elige:
- 19 → 1 (Get SSL (Domain))
Después de emitir el certificado, verifica de nuevo:
systemctl status x-uiQuieres que la salida del estado muestre Web server running HTTPS … antes de continuar.
💡 TIP: Guarda inmediatamente las credenciales generadas y la URL del panel. También ten en cuenta que el resumen del instalador puede ser engañoso si falla la emisión del certificado: si el bloque final imprime una URL HTTPS pero systemctl status x-ui sigue mostrando HTTP, confía en la salida del estado del servicio y corrige SSL antes de seguir.
Configuración del inbound VLESS + Reality
Este es el paso crítico de configuración donde realmente se crea tu sistema tipo VPN. Dentro del panel 3x-ui, navega a Inbounds → Add Inbound.
Configura los campos de la siguiente manera:
| Campo | Valor | Notas |
|---|---|---|
| Protocol | VLESS | Seleccionar 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 como predeterminado |
| Client → Flow | xtls-rprx-vision | Configúralo 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) | Usar transporte TCP directo |
| Security | reality | Seleccionar de las opciones de seguridad |
| uTLS | chrome | Usar una huella de navegador común |
| Target | www.microsoft.com:443 | Destino TLS 1.3 estable para fallback/sondeo |
| SNI | www.microsoft.com | Mantenerlo alineado con Target |
| Short IDs | Generar o usar el valor predeterminado del panel | Copiar un valor generado al cliente |
| SpiderX | / | Predeterminado simple |
| Public Key | Generar con Get New Cert | Copiar esto al cliente |
| Private Key | Generar con Get New Cert | Mantener esto solo en el servidor |
📋 NOTA: Deja los demás 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 — con sus valores predeterminados para esta configuración básica.
Por último, haz clic en Save para crear el inbound.
⚠️ ADVERTENCIA: El puerto 443 es el mejor valor predeterminado porque coincide con el tráfico HTTPS normal. Si lo cambias, el inbound puede seguir funcionando, pero ya no se camufla con tanta naturalidad.
⚠️ ADVERTENCIA: El destino Reality debe soportar TLS 1.3 — Microsoft, Apple y Google son opciones seguras. Usar un destino que no soporte TLS 1.3 hará 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 destino TLS 1.3 estable ofrece a las sondas un lugar legítimo al que llegar, y la huella chrome mantiene el lado cliente alineado con una de las huellas de navegador más comunes en internet. Empieza de forma simple, consigue una ruta que funcione y luego amplía si necesitas varios destinos.
Gestión de usuarios en 3x-ui
Con el inbound configurado, necesitas crear conexiones de usuario que usarán tus dispositivos para autenticarse. En 3x-ui, navega a Inbounds → [Click on your VLESS inbound Menu] → Add Client.
Cada usuario obtiene un UUID único (generado automáticamente), junto con un email para identificación y límites opcionales de tráfico/expiración. Cuando creas un cliente, el panel genera los valores que necesitas para la conexión: dirección del servidor, UUID, flow, public key, short ID y ajustes relacionados con SNI.
Al pulsar el signo más («+») del inbound seleccionado, aparecerá la lista de usuarios.
Exportar un cliente
Para exportar los detalles de conexión de un solo cliente, primero expande la fila del inbound para que la tabla de clientes sea visible. En la fila del cliente, usa las dos acciones de exportación por cliente:
- QR icon → abre el modal QR
- Info icon → abre el modal de detalles
Estas corresponden a los dos primeros métodos de compartición.
QR Code: Haz clic en el icono QR del cliente. Si las suscripciones están habilitadas, el modal QR puede mostrar dos códigos QR:
- Subscription → un QR para la URL de suscripción del cliente
- Client QR (etiquetado con el email o identificador del cliente, como example@mail.com) → un QR para la URI directa VLESS Reality
El QR de suscripción es útil para clientes que admiten actualizaciones automáticas. El Client QR es la importación directa única para ese cliente específico.
Share Link / URL: Haz clic en el icono Info del cliente. En el modal de detalles, puedes ver dos tipos de exportación de texto:
- Subscription URL → un endpoint de suscripción actualizable
- URL → la URI directa VLESS Reality para ese cliente
Usa el botón de copiar junto a la sección URL para la importación en escritorio.
Como mínimo, una URI directa Reality utilizable debe incluir valores rellenados como:
type=tcp encryption=none security=reality sni=www.microsoft.com fp=chrome pbk=YOUR_PUBLIC_KEY sid=YOUR_SHORT_ID spx=/ flow=xtls-rprx-vision
pbk= es la public key de Reality y pertenece a la URI directa VLESS. La propia URL de suscripción normalmente no contendrá pbk= porque solo es el endpoint de obtención; la configuración devuelta contiene los parámetros Reality reales.
Algunas versiones de 3x-ui han tenido errores en los enlaces compartidos de Reality donde pbk= está vacío. Si la URI directa no incluye pbk= o sid=, no confíes en ella a ciegas. En ese caso, usa la configuración manual en su lugar.
Configuración manual: No existe un botón separado de exportación de “manual config”. En la práctica, la configuración manual significa introducir los valores directamente en la app cliente o componer y verificar tú mismo la URI final VLESS Reality a partir de los valores en bruto. Reúne los valores necesarios de:
- el modal Info: dirección del servidor, puerto, UUID, flow y la URI directa
- los ajustes Reality del inbound: SNI, public key, short ID, fingerprint (chrome) y SpiderX (/) si hace falta
Puedes crear varios usuarios para distintos dispositivos o distintas personas. Cada UUID es independiente, así que revocar el acceso de un usuario no afecta a los demás.
Configuración manual de Xray (breve)
Algunos usuarios prefieren no usar una interfaz gráfica y quieren editar la configuración de Xray directamente. En una instalación estándar de Linux 3x-ui, la configuración activa en tiempo de ejecución se escribe en /usr/local/x-ui/bin/config.json, así que puedes inspeccionarla o hacer cambios manuales temporales allí.
Trata ese archivo como un artefacto generado en tiempo de ejecución, no como la fuente de verdad del panel. 3x-ui reconstruye config.json a partir de sus ajustes respaldados por base de datos, por lo que las ediciones manuales pueden sobrescribirse cuando Xray se reinicia o cuando guardas cambios en el panel.
Antes de editarlo, crea una copia de seguridad:
cp /usr/local/x-ui/bin/config.json /usr/local/x-ui/bin/config.json.bakLa edición manual puede ser útil para pruebas rápidas o depuración, pero un JSON incorrecto puede impedir que Xray arranque. Si 3x-ui cubre tus necesidades, quédate con el panel para los cambios persistentes y usa ediciones directas de config.json solo en casos avanzados.
Aplicaciones cliente por plataforma
Para conectarte a tu servidor, necesitarás software cliente en tus dispositivos. Esto es lo disponible:
| Plataforma | Apps recomendadas | Notas |
|---|---|---|
| Windows | v2rayN | Cliente GUI con integración en la bandeja del sistema |
| macOS | V2Box, Streisand | V2Box es gratis; 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: se mantiene activamente, tiene una interfaz limpia y maneja la configuración Reality de forma nativa. Para móvil, v2rayNG y V2Box admiten importación por QR, lo que hace que la configuración sea rápida.
📋 NOTA: La disponibilidad de clientes para plataformas Apple cambia con frecuencia. Si una app listada no está disponible en tu región, consulta el sitio oficial del proyecto, la ficha de App Store o la ruta de TestFlight antes de asumir que el problema es el protocolo en sí.
Conectando tu primer cliente
Vamos a ver cómo conectar un cliente Windows usando v2rayN: el proceso es similar en otras plataformas, pero esto te da un ejemplo completo.
Paso 1: Descargar v2rayN
Visita https://github.com/2dust/v2rayN/releases y descarga la compilación actual para Windows de escritorio. A partir de 2026, la opción más sencilla suele ser v2rayN-windows-64-desktop.zip (o el paquete de escritorio equivalente actual que aparezca en la página de lanzamiento).
Paso 2: Extraer y ejecutar
Extrae el ZIP a una carpeta (por ejemplo, C:v2rayN). Ejecuta v2rayN.exe. Las compilaciones recientes de escritorio suelen ser autocontenidas, así que normalmente no necesitas instalar un runtime .NET desktop aparte. La aplicación aparece en la bandeja del sistema.
Paso 3: Importar la configuración
Para esta conexión, usa la direct VLESS URL de 3x-ui — la que empieza con vless:// — no la URL de suscripción. Si tu enlace Reality exportado no incluye valores requeridos como pbk= o sid=, vuelve a la sección anterior de 3x-ui y usa en su lugar los valores manuales de la configuración del inbound.
En v2rayN, abre el menú Configuration en la zona superior izquierda de la ventana. El método más sencillo es copiar la direct VLESS URL desde 3x-ui y luego seleccionar Configuration → Import Share Links from clipboard. En la mayoría de las compilaciones, también puedes simplemente pulsar Ctrl+V. Asegúrate de haber copiado primero la direct VLESS URL, para que la app pueda pegar el valor.
Si la importación desde el portapapeles no es la opción deseada, también se puede usar el QR code o la importación manual.
Paso 4: Conectar
Después de importar el cliente, para activar el túnel entre el cliente Windows y el servidor, pulsa «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 IP mostrada 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.
Verificando tu configuración
La verificación de la conexión confirma que todo funciona como se espera. Además de comprobar tu IP en el navegador, hay algunas pruebas adicionales que vale la pena ejecutar.
Comprobación de IP: Visita https://whatismyipaddress.com/ o https://ip.sb mientras estás conectado. La IP mostrada debe coincidir con la IP de tu servidor VPS, no con la IP de tu hogar o red local.
Prueba de fuga DNS: Visita https://dnsleak.com o https://browserleaks.com/dns y ejecuta la prueba. Un cliente correctamente configurado no debería exponer tus resolvers DNS locales normales mientras el proxy está activo.
Problemas comunes y soluciones
| Problema | Causa | Solución |
|---|---|---|
| Sin conexión | Puerto 443 bloqueado | Revisa el firewall: ufw allow 443/tcp y la consola del proveedor cloud |
| El panel no abre | URL incorrecta o suposición antigua de /panel | Usa la URL HTTPS exacta que imprimió el instalador |
| El enlace importado no conecta | Enlace Reality sin pbk o sid | Inspecciona el enlace o cambia a configuración manual del cliente |
| Tiempo de espera de conexión | SNI incorrecto | Verifica que SNI coincida (www.microsoft.com) en los ajustes del cliente |
| Error TLS | Fingerprint incorrecto o valores Reality no coincidentes | Establece el fingerprint en chrome y vuelve a comprobar SNI, public key y short ID |
| Velocidad lenta | BBR no habilitado | Vuelve a habilitar BBR según la sección de preparación del servidor |
| «No server response» | Firewall bloqueando | Revisa tanto el firewall del servidor como los security groups del proveedor cloud |
Si encuentras problemas, verifica que la configuración de tu cliente coincida exactamente con lo generado en 3x-ui: UUID, SNI, public key, short ID y flow deben coincidir entre servidor y cliente.
Próximos pasos y opciones avanzadas
Ahora tienes una VPN VLESS + Reality funcionando. A partir de aquí, hay varias mejoras disponibles:
Añadir 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 otra superficie más que asegurar y depurar.
Escalar para varios usuarios: Crea clientes adicionales en 3x-ui para familiares o dispositivos. Cada uno obtiene un UUID único, y puedes hacer un seguimiento del uso por separado.
Ajuste de rendimiento: BBR ya está habilitado, pero puedes explorar la optimización TCP/UDP, el ajuste de buffers de red y el ajuste TCP del lado del servidor para mejoras marginales.
Destinos SNI alternativos: Aunque Microsoft/Apple/Google son fiables, algunos usuarios prefieren www.oracle.com u otros destinos. 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 administración 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 autoalojada sólida para 2026 si necesitas una configuración que se camufle mejor que los protocolos VPN tradicionales. Su ventaja no es la invisibilidad mágica; es que el tráfico se parece mucho más al tráfico web cifrado normal que las conexiones estilo OpenVPN o WireGuard en redes muy filtradas.
Si entiendes el modelo mental — huella TLS similar a la de un navegador, material de claves Reality, un destino creíble y un puerto HTTPS estándar — te resultará mucho más fácil desplegar, depurar y mantener la configuración. A partir de aquí, los siguientes pasos naturales son reforzar la seguridad del panel, añadir más dispositivos cliente y validar qué destinos y apps cliente funcionan mejor en tu propio entorno. Para hosting, proveedores como AvaHost pueden darte una base estable para ejecutar tu configuración VLESS + Reality, garantizando una disponibilidad fiable y una gestión sencilla.
Entradas relacionadas
