El VPN cayó a mitad de página: ¿siguen saliendo las peticiones en segundo plano?

La pestaña todavía muestra el panel de antes de que muriera el túnel. Los números de estado se congelan, un pequeño indicador sigue girando y la barra de direcciones aún lleva la aplicación que abriste hace una hora. No tocaste nada tras la caída, y sin embargo la página puede seguir intentando llegar a su servidor según su propio calendario. Esa es la parte que la gente pasa por alto: una página que solo es visible y una página que aún envía peticiones se ven iguales desde fuera, y solo una de ellas aparece en un registro de red.

Trabajo que una página empieza sin ti

Cuatro mecanismos mantienen ocupado un documento cargado. Un temporizador repetitivo puede volver a ejecutar una llamada de estado cada pocos segundos. Un fetch puede dispararse cuando la pestaña vuelve a ser visible después de que regreses a ella. Un canal en vivo construido sobre WebSocket o eventos enviados por el servidor puede intentar una reconexión según su propio calendario de retroceso. Un service worker registrado por el sitio puede despertar para una sincronización en cola incluso cuando no hay ninguna pestaña delante de ti.

Ninguno de ellos necesita un clic, y ninguno recarga el documento. La barra de direcciones, la posición de desplazamiento y los valores representados se quedan donde estaban. Lo único que cambia es el lado de la red: cada nuevo intento es una decisión nueva tomada en el momento en que empieza.

Esa distinción importa porque la página visible se almacena localmente. Los píxeles ya pintados no dicen nada sobre si la siguiente petición tuvo éxito. Un gráfico congelado con un indicador es el aspecto habitual de una página cuyas peticiones ahora fallan. Leer la pantalla te dice lo que el servidor dijo hace minutos, no lo que el navegador está haciendo ahora.

Por qué la carga anterior de la página no mantiene una ruta

Nada en la carga de la página vincula el documento al túnel. El enrutamiento se resuelve por paquete, en el momento del envío, a partir de la tabla que existe cuando el paquete sale. Cuando la interfaz del túnel desaparece, esa búsqueda ya no coincide con la ruta del túnel. O bien cae al adaptador físico o no encuentra nada, según lo que haya dejado atrás el cliente.

Las llamadas de retorno repetidas son tareas programadas ordinarias. La sección de temporizadores del estándar HTML describe cómo se ponen en cola y trata el intervalo como un retraso mínimo en lugar de una promesa de cadencia exacta, por lo que una pestaña en segundo plano puede sondear mucho menos a menudo de lo que pide su código. Menos intentos no es lo mismo que ningún intento, y traer una pestaña al frente es un momento habitual para una ráfaga de ellos.

Dónde aterriza la política de fallo

El bloqueo del cliente se evalúa cuando se intenta una conexión, no cuando se obtuvo la página. Si el acceso ordinario sigue permitido, el reintento puede salir por el enlace físico en claro. Si la política retiene ese tráfico hasta que vuelva el túnel, el intento falla en el momento de conectar y la página muestra un error que puede reintentar unos segundos después.

Dos detalles deciden cuál de esos obtienes. El primero es el alcance de aplicación que admite el cliente: un bloqueo para todo el dispositivo, un bloqueo limitado al adaptador del túnel o un conjunto de reglas con exclusiones. El segundo es si el destino cae dentro de una exclusión que añadiste antes para una impresora local, un portal cautivo o un servicio de streaming.

El cifrado a nivel de aplicación no cambia nada de esto. HTTPS protege los bytes entre el navegador y el servidor; no dice nada sobre qué interfaz los transporta. Una página puede estar perfectamente cifrada y aun así salir por la ruta equivocada, y eso es exactamente lo que permite un bloqueo estrecho.

Una comprobación controlada con una página desechable

Usa un host que controles y una página que no haga nada más que llamarlo, para que no haya datos reales en juego. Desde un terminal, toma una muestra de la ruta antes y después de la caída:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

Ejecútalo con el túnel levantado, luego baja el túnel y ejecútalo de nuevo. Una respuesta desde una dirección pública mientras el túnel está caído te dice que la ruta directa está abierta. Un tiempo de espera agotado o una conexión rechazada te dice que la política aguanta. Repítelo una vez más después de que el cliente se reconecte, para que veas volver la ruta del túnel en lugar de suponerlo.

En el navegador, el panel Red separa las dos preguntas. Filtra a Fetch/XHR y luego lee la columna de iniciador: una entrada iniciada por un temporizador o un script, sin navegación registrada antes, es un intento en segundo plano y no una recarga. Compara su hora de inicio con el momento en que cayó el túnel. Si la entrada sigue pendiente cuando el túnel ya no está, la petición espera una ruta que ya no existe.

La evidencia del lado del servidor es más fuerte que cualquier cosa que muestre el navegador. Un registro de peticiones con una marca de tiempo y una dirección de origen demuestra que el paquete llegó. Las entradas del navegador pueden llevar cookies, tokens y URL completas, así que conserva solo los campos que tu pregunta necesita y redacta el resto antes de pegarlas en cualquier sitio.

Qué hacer con la respuesta

Si los intentos en segundo plano siguen teniendo éxito mientras el túnel está caído, el bloqueo es más estrecho de lo que suponías, y esa brecha merece cerrarse antes de confiar el cliente para trabajo sensible. Si fallan, la política hace su trabajo y la página congelada es cosmética. En cualquier caso, cerrar una pestaña no es un control para todo el dispositivo: otras pestañas, otros navegadores y otras aplicaciones programan cada uno su propio trabajo.

Pasos siguientes que merece la pena dar: enumera qué exclusiones has añadido y por qué, confirma si el cliente bloquea solo el tráfico del ámbito del túnel o todo el tráfico, y observa una petición en segundo plano de principio a fin con el registro del servidor abierto. Esas tres respuestas cubren la mayor parte de lo que realmente contiene un informe de «el VPN cayó y algo sigue conectado».