O VPN caeu a metade de páxina: seguen saíndo as peticións en segundo plano?

A lapela aínda mostra o panel de antes de que morrese o túnel. Os números de estado conxélanse, un pequeno indicador segue xirando e a barra de enderezos aínda leva a aplicación que abriches hai unha hora. Non tocou nada tras a caída, e con todo a páxina pode seguir intentando chegar ao seu servidor segundo o seu propio calendario. Esa é a parte que a xente pasa por alto: unha páxina que só é visible e unha páxina que aínda envía peticións ven igual desde fóra, e só unha delas aparece nun rexistro de rede.

Traballo que unha páxina comeza sen ti

Catro mecanismos manteñen ocupado un documento cargado. Un temporizador repetitivo pode volver executar unha chamada de estado cada poucos segundos. Un fetch pode dispararse cando a lapela volve ser visible despois de que volvas a ela. Unha canle en vivo construída sobre WebSocket ou eventos enviados polo servidor pode tentar unha reconexión segundo o seu propio calendario de retroceso. Un service worker rexistrado polo sitio pode espertar para unha sincronización en cola mesmo cando non hai ningunha lapela diante de ti.

Ningún deles necesita un clic, e ningún recarga o documento. A barra de enderezos, a posición de desprazamento e os valores representados quedan todos onde estaban. O único que cambia é o lado da rede: cada novo intento é unha decisión nova tomada no momento en que comeza.

Esa distinción importa porque a páxina visible gárdase localmente. Os píxeles xa pintados non din nada sobre se a seguinte petición tivo éxito. Un gráfico conxelado cun indicador é o aspecto habitual dunha páxina cuxas peticións agora fallan. Ler a pantalla dinte o que o servidor dixo hai minutos, non o que está a facer o navegador agora.

Por que a carga anterior da páxina non mantén unha ruta

Nada na carga da páxina vincula o documento ao túnel. O enrutamento resólvese por paquete, no momento do envío, a partir da táboa que existe cando o paquete sae. Cando a interface do túnel desaparece, esa busca xa non coincide coa ruta do túnel. Ou cae ao adaptador físico ou non atopa nada, segundo o que deixase atrás o cliente.

As chamadas de retorno repetidas son tarefas programadas ordinarias. A sección de temporizadores do estándar HTML describe como se poñen en cola e trata o intervalo como un atraso mínimo en lugar dunha promesa de cadencia exacta, polo que unha lapela en segundo plano pode sondar moito menos a miúdo do que pide o seu código. Menos intentos non é o mesmo que ningún intento, e traer unha lapela á fronte é un momento habitual para unha ráfaga deles.

Onde aterriza a política de fallo

O bloqueo do cliente avalíase cando se intenta unha conexión, non cando se obtivo a páxina. Se o acceso ordinario aínda está permitido, o reintento pode saír polo enlace físico en claro. Se a política retén ese tráfico ata que volva o túnel, o intento falla no momento de conectar e a páxina mostra un erro que pode reintentar uns segundos despois.

Dous detalles deciden cal destes obténs. O primeiro é o alcance de aplicación que admite o cliente: un bloqueo para todo o dispositivo, un bloqueo limitado ao adaptador do túnel ou un conxunto de regras con exclusións. O segundo é se o destino cae dentro dunha exclusión que engadiches antes para unha impresora local, un portal cativo ou un servizo de streaming.

O cifrado a nivel de aplicación non cambia nada disto. HTTPS protexe os bytes entre o navegador e o servidor; non di nada sobre que interface os transporta. Unha páxina pode estar perfectamente cifrada e aínda saír polo camiño incorrecto, e iso é exactamente o que permite un bloqueo estreito.

Unha comprobación controlada cunha páxina dun só uso

Usa un servidor que controles e unha páxina que non faga nada máis que chamalo, para que non haxa datos reais en xogo. Desde un terminal, toma unha mostra do camiño antes e despois da caída:

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

Execútao co túnel levantado, despois baixa o túnel e execútao de novo. Unha resposta desde un enderezo público mentres o túnel está baixado dinte que o camiño directo está aberto. Un tempo de espera esgotado ou unha conexión rexeitada dinte que a política aguanta. Repíteo unha vez máis despois de que o cliente se reconecte, para que vexas volver o camiño do túnel en lugar de supoñelo.

No navegador, o panel Rede separa as dúas preguntas. Filtra a Fetch/XHR e despois le a columna de iniciador: unha entrada iniciada por un temporizador ou un script, sen navegación rexistrada antes, é un intento en segundo plano e non unha recarga. Compara a súa hora de inicio co momento en que caeu o túnel. Se a entrada segue pendente cando o túnel xa non está, a petición espera un camiño que xa non existe.

A evidencia do lado do servidor é máis forte que calquera cousa que mostre o navegador. Un rexistro de peticións cunha marca de tempo e un enderezo de orixe demostra que o paquete chegou. As entradas do navegador poden levar cookies, tokens e URL completos, así que conserva só os campos que a túa pregunta necesita e redacta o resto antes de pegalos en calquera sitio.

Que facer coa resposta

Se os intentos en segundo plano seguen tendo éxito mentres o túnel está baixado, o bloqueo é máis estreito do que supuxeches, e esa fenda merece pecharse antes de confiar o cliente para traballo sensible. Se fallan, a política fai o seu traballo e a páxina conxelada é cosmética. En calquera caso, pechar unha lapela non é un control para todo o dispositivo: outras lapelas, outros navegadores e outras aplicacións programan cada un o seu propio traballo.

Pasos seguintes que paga a pena dar: enumera que exclusións engadiches e por que, confirma se o cliente bloquea só o tráfico do ámbito do túnel ou todo o tráfico, e observa unha petición en segundo plano de principio a fin co rexistro do servidor aberto. Esas tres respostas cobren a maior parte do que realmente contén un informe de «o VPN caeu e algo segue conectado».