Por qué una aplicación de Android bloqueada sigue mostrando consumo de red

Bloquea una aplicación en su cortafuegos VPN de Android, la aplicación deja de funcionar y su fila de consumo sigue subiendo. La conclusión tentadora es que el bloqueo se filtró o que el contador está roto. Ninguna de las dos se sigue. Un registro de consumo dice que se atribuyeron bytes a esa identidad en algún punto de observación; no dice nada sobre si un servicio remoto aceptó una solicitud. Cuando sabe qué frontera se midió y a qué identidad se le cargó, las dos observaciones dejan de contradecirse.

El contador mide bytes, no entrega

Android atribuye el tráfico a un UID y lo cuenta en ambos sentidos, y lo hace en una frontera de interfaz, no en el momento en que una solicitud de la aplicación tiene éxito.

Un intento de conexión rechazado sigue moviendo paquetes: el SYN, el reset o las retransmisiones que le siguen, más la consulta DNS que precedió a ambos. Esos bytes existen aunque no se haya entregado nada, y en algunas rutas se cuentan antes de que ningún filtro decida qué hacer con ellos.

Por eso la fila de una aplicación bloqueada puede crecer mientras todas las solicitudes fallan. El contador responde «cuántos bytes se atribuyeron a esta identidad», no «si esta identidad llegó a internet». Un gráfico no puede distinguir un flujo aceptado de un apretón de manos rechazado con cortesía, y un total que suma ambos sentidos tampoco.

La atribución sigue al UID, no al icono

La fila es por UID, y un UID puede ser compartido por más de un paquete, mientras que una aplicación visible puede ceder el trabajo a un componente separado que se ejecuta con su propia identidad. Una pestaña del navegador dibujada por un proceso WebView compartido, un servicio de sincronización en segundo plano o un paquete complementario instalado junto a la aplicación principal producen tráfico que la pantalla de consumo puede mostrar con un nombre que no esperaba, o bajo la aplicación que sí bloqueó. Un paquete bloqueado y un ayudante que transporta sus solicitudes son dos sujetos distintos, y la regla solo cubría uno de ellos.

Cuando las cifras parezcan mal, compare el UID en lugar de la etiqueta. La API de consumo se consulta por UID, y adb shell dumpsys package <package> | grep userId= imprime el número con el que debe comparar, así que dos entradas con el mismo UID son la misma identidad desde el punto de vista del contador.

La ventana temporal puede ser anterior a su regla

Los datos de consumo se recogen en bloques y se consultan periódicamente, no se transmiten en vivo. Un total diario puede incluir los minutos previos a activar el bloqueo, una sincronización en segundo plano de la hora anterior o tráfico que ya estaba en curso. Comparar un total acumulado con una sola solicitud rechazada y llamar filtración a la diferencia es un error de medición, no un hallazgo del cortafuegos.

Use una ventana más corta y un inicio limpio. Anote la marca de tiempo al cambiar la regla, espere un intervalo de recogida y luego mire solo los datos posteriores. Si el total sigue subiendo en una ventana que empieza después de la regla, tiene algo que investigar; si deja de subir, el crecimiento anterior era historia que se mostraba.

El servicio VPN puede no ser el que configuró

Un cortafuegos VPN solo ve el tráfico que transporta su propio servicio. Si otra aplicación VPN se inicia y toma la conexión activa, su filtro ya no está en la ruta mientras su interfaz sigue existiendo en los ajustes. Las listas de omisión por aplicación hacen lo mismo a propósito, y un perfil que excluye una aplicación no es una filtración cuando la aplicación después funciona.

IPv4, IPv6 y DNS también pueden divergir. Un filtro que maneja IPv4 puede dejar IPv6 o un resolutor DNS privado fuera de él, de modo que parte del tráfico de la aplicación sigue una ruta que sus reglas nunca describieron. Compruebe qué aplicación posee ahora la VPN y qué dice la lista de exclusiones antes de reescribir nada:

adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail

Pruebe una solicitud nueva y anote cuatro hechos

Elija una solicitud inocua, ejecútela una vez y anote cuatro hechos: la regla vigente, el UID de la aplicación, el estado de la red y la hora. Luego compruebe si su filtro registró el flujo y si el destino o la puerta de enlace vieron la misma conexión. Un flujo identificado en ambos lados es una prueba; un total agregado no lo es.

Una conclusión defendible nombra qué se denegó y qué observación lo confirmó. «El contador subió» no es un hallazgo, y «todos los contadores de consumo son falsos» tampoco. Un eslogan de capa OSI no resuelve esto: la respuesta honesta es que el contador y el bloqueo pueden ser ambos correctos mientras describen cosas distintas. La referencia NetworkStatsManager de Android documenta cómo se consultan y se atribuyen esos bloques.