Una app de Android se niega a funcionar con VPN: qué capa decide

Cuando una app de Android deja de funcionar en el momento en que sube el túnel, tres cosas distintas pueden ser responsables, y todas producen fallos de aspecto parecido. La app puede leer el estado de red del propio teléfono y negarse localmente. El servidor puede clasificar la dirección desde la que llega y rechazarla. O el rechazo puede no tener nada que ver con la VPN. El orden de abajo reúne pruebas antes de cambiar nada, porque cambiar la salida es el paso más caro y el que menos probablemente ayuda si la comprobación es local.

Paso 1: averiguar cuándo se niega la app

El momento es el primer discriminante. Vacíe el búfer del registro, reproduzca el fallo y mire qué hizo la app antes de quejarse:

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

Si la app se niega antes de que se intente cualquier petición saliente, está ante una decisión local. Si se conecta, envía algo y luego muestra un error, el rechazo vino del otro lado. Si falla igual con el túnel apagado, la VPN nunca fue la variable.

Trate ese momento como prueba y no como confirmación. Una app puede reproducir una respuesta en caché, y las peticiones en segundo plano pueden haber tenido éxito o haber fallado antes de que usted mirara. Anote las marcas de tiempo de la última petición correcta y del error, no solo el instante en que apareció el mensaje.

Paso 2: leer la visión que tiene el teléfono de la red

Android expone el estado de la VPN como una capacidad de red, así que una app no necesita una lista de proveedores comerciales para notar que hay un túnel activo. Pregunta al servicio de conectividad cuál es la red actual, y la respuesta incluye 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 es local y barata, y explica toda una clase de informes del tipo «esta app no funciona con VPN» sin ninguna clasificación remota. Lo que la app puede ver sigue dependiendo de su propio contexto de red, así que no suponga que toda app inspecciona todos los perfiles del dispositivo.

Desde una estación de trabajo puede ver el mismo estado en un dispositivo de prueba con adb shell dumpsys connectivity y buscando la entrada de red VPN. Compare una ejecución con el túnel levantado con otra con el túnel bajado, y guarde ambas salidas.

Paso 3: leer qué ve realmente el servidor

El otro observador es el servicio. Ve la dirección de origen que llega, y puede actuar sobre la dirección, la red de alojamiento que hay detrás, la región, el operador o señales ligadas a la cuenta y al dispositivo. Nada de eso es una identidad única, y el direccionamiento compartido hace normales los bloqueos colaterales: una dirección restringida puede dejar fuera a usuarios sin relación que están detrás de la misma traducción.

Obtenga la dirección por el mismo camino que usa la app, no desde un navegador en un portátil. En el teléfono, una petición simple a un servicio de eco de dirección muestra qué recibe el lado remoto, y compararlo con una petición por la red móvil le dice si la dirección cambió o no.

Si la app funciona por la red móvil y falla por el túnel con la misma cuenta, el rechazo está en el extremo remoto o en la política propia de la app. Si falla en ambos casos, la VPN no es el factor diferencial y debería dejar de probar puntos finales.

Paso 4: encajar las pruebas con uno de los tres veredictos

Tres combinaciones cubren casi todos los informes. Un rechazo sin ningún intento saliente mientras hay un túnel activo apunta a una comprobación local del transporte. Una petición que sale y vuelve con un error, un tiempo de espera agotado en un host concreto o un mensaje de región apunta al lado remoto. Un fallo que se repite por la red móvil sin túnel apunta a la cuenta, a la versión de la app o a la política del propio servicio, y ningún cambio de VPN lo moverá.

Escriba el veredicto junto con la prueba que lo produjo. El valor de este paso es que detiene el bucle en el que alguien cambia cuatro veces los nodos de salida para arreglar una comprobación que se ejecuta en el propio teléfono.

También mantiene honestas las afirmaciones. Alojar el servidor uno mismo cambia el punto final y su salida a internet; no hace que Android olvide que hay una red VPN activa ni garantiza que lo acepte un servicio que clasifica direcciones. Un filtro local puede dispararse en una red VPN propia con la misma facilidad que en una comercial.

Paso 5: tomar el camino soportado y verificarlo

Empiece por la política documentada del producto y por su responsable de soporte. Envíe la versión del cliente, el mensaje exacto y una ventana de fallo estrecha; no envíe capturas completas de tráfico ni credenciales solo para demostrar que existe un error.

Si el servicio permite el acceso directo y la política del dispositivo lo permite, la exclusión por app es el mecanismo soportado, y saca deliberadamente esa app del túnel en lugar de esconder el túnel. El tráfico de la app sale entonces por su propio camino, que es una decisión de política que alguien debe asumir. En una configuración que bloquea sin VPN, una app excluida puede simplemente perder la conectividad, así que pruebe esa combinación antes de prometer que funciona.

Después de cualquier cambio, repita la prueba de tiempo del primer paso, confirme que la app funciona y confirme que todas las demás apps siguen usando el túnel. Luego restaure la configuración anterior y compruebe si el fallo vuelve, porque un arreglo que no puede reproducir es una casualidad que volverá a encontrar.