¿Por qué algunas webs fallan solo cuando la VPN está activa?

Que un solo sitio falle mientras todo lo demás carga demuestra que el túnel transporta tráfico, lo que acota el problema más de lo que la mayoría espera. Tres observaciones ordenan el resto: si recibiste una respuesta HTTP, si el nombre de host se resolvió a una dirección y si las peticiones pequeñas pasan mientras las grandes se atascan. Adivinar la VPN antes de tener esas respuestas suele mover la avería en lugar de resolverla.

Trabaja las observaciones en orden, porque un sitio que respondió no puede haber fallado también al resolverse. Si no carga nada en absoluto, estás en la rama equivocada y valen las comprobaciones de conectado pero sin Internet.

Deja que el mensaje de error elija la rama

Un rechazo, un desafío antibot o una página de error significan que el servicio respondió, así que los paquetes llegaron a una aplicación y volvieron. Eso traslada la pregunta a la política de acceso del sitio, que puede ponderar la dirección de salida, la cuenta o patrones de petición que no publica. Un fallo de resolución de nombres nunca llegó al sitio, y la dirección es lo primero que hay que inspeccionar. Un tiempo de espera queda entre ambos: se envió algo y nada lo confirmó.

Los avisos de certificado pertenecen a una cuarta rama. Significan que la conexión fue respondida por algo cuya identidad el navegador no pudo verificar, ya sea un proxy de tu lado o una discrepancia real por la que no deberías hacer clic. Trátalo como una cuestión de confianza, no de enrutamiento.

Un sitio que responde no ha demostrado un túnel roto

Cuando la respuesta es una página de bloqueo, compara la misma página por una segunda salida manteniendo el navegador y la máquina sin cambios. Si el resultado sigue a la dirección de salida, el sitio trata esa dirección de otra forma, y ninguna configuración de cliente lo cambiará. Si el bloqueo sigue a tu navegador, la causa está en una extensión, un proxy guardado o un ajuste del resolutor. Dos pasadas separan esas explicaciones a bajo coste.

Los fallos solo del navegador son lo bastante comunes para probarlos pronto. Una página que carga en un navegador compatible y falla en otro apunta al estado del perfil, a un bloqueador de contenido o a DNS cifrado configurado dentro del propio navegador. Las indicaciones de Chrome sobre DNS seguro cubren dónde vive ese ajuste, y cambiarlo por el control admitido es mejor que reiniciar el dispositivo.

Cuando solo se atascan las transferencias grandes, mira el tamaño de paquete

Una página que dibuja su cabecera y luego se cuelga tiene una firma distinta de una página que nunca arranca. Las respuestas pequeñas pueden pasar mientras una carga de tamaño completo se descarta en algún punto que no puede avisar al emisor, y así se ve un fallo de MTU de ruta desde un navegador. Compara una petición minúscula y una grande al mismo host antes de teorizar sobre filtrado. El descubrimiento de MTU de ruta debe aprender el menor tamaño de enlace del camino, y depende de respuestas ICMP que las redes filtradas descartan de forma rutinaria.

Prueba esa hipótesis con un barrido de tamaños en vez de un solo ping. Un fallo que empieza en un tamaño de carga constante es una prueba sólida, mientras que uno que se mueve no lo es.

Confirma la corrección en la petición que falló

Vuelve a probar la operación original, no la portada, porque un armazón en caché puede dibujarse mientras la llamada a la API tras un inicio de sesión sigue fallando. Los comandos de abajo separan la resolución de nombres, una petición pequeña y una grande contra el mismo host. Sustituye el nombre de host y la ruta por los de la petición que realmente se rompió.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

Si la respuesta de dig difiere de la que usó el navegador, el resolutor es la variable, y el ajuste DNS del propio navegador es el lugar donde mirar. Si la petición pequeña devuelve un estado mientras la grande se atasca, trabaja la rama del tamaño de paquete. Si ambas agotan el tiempo, la ruta de salida y el trato del sitio a esa dirección vuelven a la mesa.

Conserva el cambio que hizo triunfar la petición original y deshaz el resto. Un montón de cambios simultáneos en navegador, resolutor y cliente te deja sin poder decir cuál importaba.