Unha app de Android négase a funcionar con VPN: que capa decide

Cando unha app de Android deixa de funcionar no momento en que sobe o túnel, tres cousas distintas poden ser responsables, e todas producen fallos de aspecto semellante. A app pode ler o estado de rede do propio teléfono e negarse localmente. O servidor pode clasificar o enderezo desde o que chega e rexeitalo. Ou o rexeitamento pode non ter nada que ver coa VPN. A orde de abaixo reúne probas antes de cambiar nada, porque cambiar a saída é o paso máis caro e o que menos probablemente axuda se a comprobación é local.

Paso 1: descubrir cando se nega a app

O momento é o primeiro discriminante. Baleire o búfer do rexistro, reproduza o fallo e mire que fixo a app antes de queixarse:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

Se a app se nega antes de que se tente calquera petición saínte, está ante unha decisión local. Se se conecta, envía algo e despois mostra un erro, o rexeitamento veu do outro lado. Se falla igual co túnel apagado, a VPN nunca foi a variable.

Trate ese momento como proba e non como confirmación. Unha app pode reproducir unha resposta na caché, e as peticións en segundo plano poden ter tido éxito ou fallado antes de que vostede mirase. Anote as marcas de tempo da última petición correcta e do erro, non só o instante en que apareceu a mensaxe.

Paso 2: ler a visión que ten o teléfono da rede

Android expón o estado da VPN como unha capacidade de rede, así que unha app non necesita unha lista de provedores comerciais para notar que hai un túnel activo. Pregunta ao servizo de conectividade cal é a rede actual, e a resposta inclúe un bit de transporte de VPN:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Esa comprobación é local e barata, e explica toda unha clase de informes do tipo «esta app non funciona con VPN» sen ningunha clasificación remota. O que a app pode ver segue dependendo do seu propio contexto de rede, así que non supoña que toda app inspecciona todos os perfís do dispositivo.

Desde unha estación de traballo pode ver o mesmo estado nun dispositivo de proba con adb shell dumpsys connectivity e buscando a entrada de rede VPN. Compare unha execución co túnel levantado con outra co túnel baixado, e garde ambas as saídas.

Paso 3: ler que ve realmente o servidor

O outro observador é o servizo. Ve o enderezo de orixe que chega, e pode actuar sobre o enderezo, a rede de aloxamento que hai detrás, a rexión, o operador ou sinais ligados á conta e ao dispositivo. Nada diso é unha identidade única, e o enderezo compartido fai normais os bloqueos colaterais: un enderezo restrinxido pode deixar fóra usuarios sen relación que están detrás da mesma tradución.

Obteña o enderezo polo mesmo camiño que usa a app, non desde un navegador nun portátil. No teléfono, unha petición simple a un servizo de eco de enderezos mostra que recibe o lado remoto, e comparalo cunha petición pola rede móbil dille se o enderezo cambiou ou non.

Se a app funciona pola rede móbil e falla polo túnel coa mesma conta, o rexeitamento está no extremo remoto ou na política propia da app. Se falla nos dous casos, a VPN non é o factor diferencial e debería deixar de probar puntos finais.

Paso 4: encaixar as probas cun dos tres veredictos

Tres combinacións cobren case todos os informes. Un rexeitamento sen ningún intento saínte mentres hai un túnel activo apunta a unha comprobación local do transporte. Unha petición que sae e volve cun erro, un tempo de espera esgotado nun host concreto ou unha mensaxe de rexión apuntan ao lado remoto. Un fallo que se repite pola rede móbil sen túnel apunta á conta, á versión da app ou á política do propio servizo, e ningún cambio de VPN o moverá.

Escriba o veredicto xunto coa proba que o produciu. O valor deste paso é que detén o bucle no que alguén cambia catro veces os nodos de saída para arranxar unha comprobación que se executa no propio teléfono.

También mantén honestas as afirmacións. Aloxar un mesmo o servidor cambia o punto final e a súa saída a internet; non fai que Android esqueza que hai unha rede VPN activa nin garante que o acepte un servizo que clasifica enderezos. Un filtro local pode dispararse nunha rede VPN propia coa mesma facilidade que nunha comercial.

Paso 5: tomar o camiño soportado e verificalo

Empece pola política documentada do produto e polo seu responsable de soporte. Envíe a versión do cliente, a mensaxe exacta e unha xanela de fallo estreita; non envíe capturas completas de tráfico nin credenciais só para demostrar que existe un erro.

Se o servizo permite o acceso directo e a política do dispositivo o permite, a exclusión por app é o mecanismo soportado, e saca deliberadamente esa app do túnel en lugar de agochar o túnel. O tráfico da app sae entón polo seu propio camiño, que é unha decisión de política que alguén debe asumir. Nunha configuración que bloquea sen VPN, unha app excluída pode simplemente perder a conectividade, así que probe esa combinación antes de prometer que funciona.

Despois de calquera cambio, repita a proba de tempo do primeiro paso, confirme que a app funciona e confirme que todas as demais apps seguen usando o túnel. Logo resture a configuración anterior e comprobe se o fallo volve, porque un arranxo que non pode reproducir é unha casualidade que volverá atopar.