¿Las notificaciones push de Android no funcionan con la VPN? Revisa esto

Las notificaciones dejan de llegar en un teléfono que, por lo demás, navega sin problemas a través de la VPN corporativa. Las páginas web cargan, la aplicación se abre y los mensajes solo aparecen en casa o después de desconectar el túnel. En una aplicación basada en Firebase Cloud Messaging, el canal push es una conexión saliente independiente y de larga duración, no la ruta HTTPS que el navegador acaba de demostrar. Sigue estas comprobaciones en orden y detente en la primera que falle.

Confirma que la aplicación usa realmente FCM

No toda notificación es un push. Algunas las programa localmente la aplicación, otras se consultan por HTTPS y otras llegan por un canal del proveedor que no tiene nada que ver con Firebase. Si el manifiesto y las dependencias de la aplicación incluyen Firebase Messaging, sus notificaciones suelen viajar por la conexión de FCM, y la biblioteca cliente registra el alta bajo una etiqueta predecible.

adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase

Un token de registro en el log confirma el transporte. Sin él, estás depurando una canalización de notificaciones a nivel de aplicación y los cambios en el cortafuegos no ayudarán. Esta distinción importa porque un mensaje entregado que nunca se muestra y un mensaje que nunca llega se ven iguales para el usuario.

Comprueba los puertos salientes, no el sitio web

Las conexiones de los dispositivos a FCM son TCP originadas por el dispositivo hacia el puerto 5228, con 5229 y 5230 como alternativas y 443 como último recurso. Un cortafuegos que permite el 443 para navegar puede seguir rompiendo el push, y una regla que permite el dominio de la API de una aplicación no cubre los endpoints de mensajería, que son servicios distintos.

Son conexiones salientes desde el teléfono. No publicas un puerto entrante en el dispositivo ni en la puerta de enlace VPN, así que si alguien sugiere una redirección de puertos, el diseño ya ha fallado. Lo mismo ocurre con una regla que abre un puerto a todas las direcciones de internet: limítala a los destinos documentados.

La guía de red de Firebase también indica que el protocolo de entrega de FCM no puede transportarse por un proxy HTTP normal. Por tanto, que un navegador funcione a través del proxy web corporativo no demuestra nada sobre el socket push: son dos clientes distintos con rutas distintas.

Revisa los tiempos de espera de inactividad que cierran el socket

La conexión de FCM permanece abierta entre mensajes, lo que la hace sensible a los tiempos de espera de NAT y de inspección con estado. La guía de Firebase pide al menos 30 minutos de tolerancia a la inactividad donde se apliquen esas políticas. Un tiempo de espera de sesión de cinco minutos elimina el mapeo en silencio, y el teléfono solo se reconecta cuando algo lo despierta, así que los mensajes llegan a ráfagas o no llegan.

Lee la tabla de sesiones del cortafuegos o de la puerta de enlace VPN y busca la conexión del teléfono a 5228-5230. Compara su vida restante con el valor documentado. Si es más corta, aumenta el tiempo de espera para esos puertos en lugar de cambiar todas las políticas del dispositivo, porque un cambio global del tiempo de espera es difícil de justificar y más difícil de deshacer.

La entrega push también depende de que el mapeo del endpoint sobreviva a un roaming entre Wi-Fi y red móvil. Un mapeo asociado a una interfaz puede descartarse en el traspaso incluso cuando ambas redes permiten los puertos.

Decide si el bypass de la VPN es aceptable

Los clientes VPN de Android pueden permitir que el tráfico omita el túnel, y FCM puede usar la red subyacente cuando se permite ese bypass. En ese caso el canal push sigue cifrado, pero ya no lleva la dirección del túnel, así que el enmascaramiento de IP de la VPN no se aplica. Es una decisión de política, no un fallo.

Si tu política prohíbe el bypass, la ruta del túnel tiene que transportar la conexión: puertos abiertos, tiempos de espera suficientemente largos y el proxy sin estorbar. No excluyas en silencio un servicio gestionado ni relajes el bloqueo solo porque las notificaciones funcionen en una red no gestionada. El icono de la VPN no indica qué ruta eligió un servicio determinado

Separa la entrega de la visualización y prueba una vez

El permiso, la configuración de canales, No molestar y los interruptores por aplicación deciden si se muestra un mensaje entregado. En Android 13 y versiones posteriores el permiso de notificaciones es una concesión en tiempo de ejecución, y una concesión denegada produce un silencio que parece exactamente un puerto bloqueado. Un mensaje que llegó pero no se mostró es un problema de presentación; trátalo por separado.

Ejecuta una prueba controlada en lugar de enviar mensajes de forma improvisada. Mantén fijos el dispositivo, la cuenta y la aplicación, envía un único mensaje con una marca de tiempo conocida y compara la situación con VPN con una red sin VPN aprobada. Registra la hora de recepción en logcat y la hora de visualización en cada ejecución. Si la entrega difiere pero la visualización no, la ruta de red es la variable; si ambas son idénticas, sigue mirando la aplicación.

Entrega al responsable de red los puertos, la limitación del proxy, el tiempo de espera medido y la decisión sobre el bypass en una sola nota. «Apaga la VPN» no es un hallazgo, y permitir todo el tráfico de Google no es una solución acotada.