Entrar Empezar
Herramienta gratuita

Qué deja pasar tu red

Cuando la VPN no conecta en una oficina, un hotel o un campus, el problema no suele ser la app. La red deja pasar solo el 80 y el 443, bloquea UDP o fuerza el DNS a su propio servidor, y cada uno de esos casos se resuelve con un protocolo distinto. Esta página comprueba los cuatro y te dice qué pasará aquí.

No se instala nada; todo se ve desde el navegador.

Listo para comprobar

Pulsa «Comprobar la red»: unos siete segundos.

Qué se deduce de esto

Qué mostró la comprobaciónQué conectará aquí
Pasa todoCualquier protocolo. Elige WireGuard: es más rápido en hardware modesto.
UDP cerrado, 443 funcionaUn protocolo sobre TCP 443: VLESS con Reality o similar. WireGuard e IKEv2 no conectarán.
Un puerto no estándar no pasaSolo nodos en el 443. Una configuración con un número de puerto inusual tras la dirección es inútil en esta red.
El DNS no sale fueraLa red tiene su propio resolutor. La conexión suele sobrevivir a eso, pero los nombres antes del túnel no los resuelves tú: mira el test de fuga de DNS.

Límites

Se comprueban nuestras direcciones y servidores STUN públicos, no el servidor concreto al que te conectas: una red puede dejar pasar el 443 a unos hosts y cortarlo a otros. El UDP se comprueba en los puertos STUN, 3478 y 19302; una red que deje pasar un puerto UDP y corte los demás aparecerá aquí como cerrada. QUIC no se comprueba aparte: en nuestro lado HTTP/3 aún no está activado, y medir el de otros sería hacer pasar sus reglas por las tuyas.

Más sobre el tema: quién resuelve tus nombres, más sobre UDP y qué servicios no abren en esta red.

¿Tu red corta la mitad de los protocolos?

404 VPN conecta por VLESS con Reality a través de TCP 443: para un filtro es indistinguible de un sitio normal. Donde el UDP está cerrado y los puertos no estándar no pasan, es lo único que funciona.

Cómo conectar 404 VPN →

Preguntas frecuentes

guest@404vpn:~$ cat network-faq.md
[01] $ ¿Por qué la VPN conecta con datos móviles y no con el Wi-Fi de la oficina? ▸
> Porque un operador móvil deja pasar casi todo, y una red corporativa solo lo que le parece. El conjunto típico de reglas: TCP 80 y 443 abiertos hacia fuera, UDP cerrado por completo, consultas DNS forzadas a un servidor interno. WireGuard nunca conectará en una red así, mientras que un protocolo sobre TCP 443 parece HTTPS normal y pasa.
[02] $ ¿Qué significa «los puertos no estándar no pasan»? ▸
> Llamamos a nuestro propio servidor por el puerto 8443: HTTPS normal, solo que no en el 443. Si esa sonda falló y el 443 funciona, la red filtra por número de puerto. Conclusión práctica: una conexión cuya dirección de servidor termina en un puerto inusual no funcionará aquí; hace falta un nodo en el 443.
[03] $ El test dice que el UDP está cerrado. ¿Es seguro? ▸
> Significa que en seis segundos no respondió ningún servidor STUN público, aunque el navegador encontró direcciones locales. Casi siempre es exactamente eso: cortan el UDP. Un matiz: una red puede dejar pasar un puerto UDP y cortar otro, así que algún raro WireGuard en un puerto inusual a veces pasa donde el test mostró el UDP cerrado.
[04] $ ¿Por qué hay aquí una comprobación de DNS? ▸
> Responde a si la red deja salir consultas a zonas externas. Si no, la red tiene su propio resolutor forzado, y eso es otra fuente de rarezas: los nombres pueden resolverse a direcciones equivocadas o no resolverse en absoluto. Quién resuelve exactamente tus nombres lo muestra la herramienta de al lado, el test de fuga de DNS.
[05] $ ¿Guardáis algo de la comprobación? ▸
> No. Las sondas son peticiones a nuestras propias direcciones, no se distinguen de abrir una página. El resumen para soporte va a tu portapapeles, no a nosotros: hasta que tú mismo lo pegues en un mensaje, no lo vemos.