As notificacións push de Android non funcionan coa VPN? Revisa isto
FCM mantén a súa propia conexión saínte nos portos 5228-5230. Revisa a regra do proxy, o tempo de espera de NAT e a omisión da VPN antes de tocar os axustes de notificacións.
As notificacións deixan de chegar nun teléfono que, polo demais, navega sen problemas pola VPN corporativa. As páxinas web cargan, a aplicación ábrese e as mensaxes só aparecen na casa ou despois de desconectar o túnel. Nunha aplicación baseada en Firebase Cloud Messaging, a canle push é unha conexión saínte independente e de longa duración, non a ruta HTTPS que o navegador acaba de demostrar. Percorre estas comprobacións en orde e detente na primeira que falle.
Confirma que a aplicación usa realmente FCM
Non toda notificación é un push. Algunhas prógramas localmente a aplicación, outras son consultadas por HTTPS e outras chegan por unha canle do provedor que non ten nada que ver con Firebase. Se o manifesto e as dependencias da aplicación inclúen Firebase Messaging, as súas notificacións adoitan viaxar pola conexión de FCM, e a biblioteca cliente rexistra a alta baixo unha etiqueta previsible.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseUn token de rexistro no log confirma o transporte. Sen el, estás depurando unha canalización de notificacións a nivel de aplicación e os cambios no devasado non axudarán. Esta distinción importa porque unha mensaxe entregada que nunca se mostra e unha mensaxe que nunca chega vense iguais para o usuario.
Comproba os portos saíntes, non o sitio web
As conexións dos dispositivos a FCM son TCP orixinadas polo dispositivo cara ao porto 5228, con 5229 e 5230 como alternativas e 443 como último recurso. Un devasado que permite o 443 para navegar pode seguir rompendo o push, e unha regra que permite o dominio da API dunha aplicación non cobre os puntos finais de mensaxería, que son servizos distintos.
Son conexións saíntes desde o teléfono. Non publicas un porto entrante no dispositivo nin na pasarela VPN, así que se alguén suxire unha redirección de portos, o deseño xa fallou. O mesmo ocorre cunha regra que abre un porto a todos os enderezos de internet: limítaa aos destinos documentados.
| Port | Role | What to verify |
|---|---|---|
| 5228 | Primary FCM connection | Outbound allowed and session state kept |
| 5229, 5230 | Fallback ports | Often missing from hand-written allowlists |
| 443 | Last-resort fallback | Works only if the client actually falls back |
| HTTP proxy | Not a supported FCM transport | Proxy exclusion or bypass, not a port rule |
A guía de rede de Firebase tamén indica que o protocolo de entrega de FCM non se pode transportar por un proxy HTTP normal. Por tanto, que un navegador funcione polo proxy web corporativo non demostra nada sobre o socket push: son dous clientes distintos con rutas distintas.
Revisa os tempos de espera de inactividade que pechan o socket
A conexión de FCM permanece aberta entre mensaxes, o que a fai sensible aos tempos de espera de NAT e de inspección con estado. A guía de Firebase pide polo menos 30 minutos de tolerancia á inactividade onde se apliquen esas políticas. Un tempo de espera de sesión de cinco minutos elimina a asignación en silencio, e o teléfono só se reconecta cando algo o esperta, así que as mensaxes chegan a ráfagas ou non chegan.
Le a táboa de sesións no devasado ou na pasarela VPN e atopa a conexión do teléfono a 5228-5230. Compara a súa vida restante co valor documentado. Se é máis curta, aumenta o tempo de espera para eses portos en vez de cambiar todas as políticas do dispositivo, porque un cambio global do tempo de espera é difícil de xustificar e máis difícil de desfacer.
A entrega push tamén depende de que a asignación do punto final sobreviva a un roaming entre Wi-Fi e rede móbil. Unha asignación ligada a unha interface pode descartarse na transición mesmo cando ambas as redes permiten os portos.
Decide se a omisión da VPN é aceptable
Os clientes VPN de Android poden permitir que o tráfico omita o túnel, e FCM pode usar a rede subxacente cando se permite esa omisión. A canle push segue cifrada nese caso, pero xa non leva o enderezo do túnel, así que o enmascaramento de IP da VPN non se lle aplica. É unha decisión de política, non un fallo.
Se a túa política prohibe a omisión, a ruta do túnel ten que transportar a conexión: portos abertos, tempos de espera abondo longos e o proxy fóra do camiño. Non exclúas en silencio un servizo xestionado nin relaxes o bloqueo só porque as notificacións funcionan nunha rede non xestionada. A icona da VPN non indica que ruta escolleu un servizo determinado
Separa a entrega da visualización e proba unha vez
O permiso, os axustes de canle, Non molestar e os interruptores por aplicación deciden se se mostra unha mensaxe entregada. En Android 13 e posteriores o permiso de notificacións é unha concesión en tempo de execución, e unha concesión denegada produce un silencio que parece exactamente un porto bloqueado. Unha mensaxe que chegou pero non se mostrou é un problema de presentación; trátao por separado.
Fai unha proba controlada en lugar de enviar mensaxes de forma improvisada. Mantén fixos o dispositivo, a conta e a aplicación, envía unha única mensaxe cunha marca de tempo coñecida e compara a situación coa VPN cunha rede sen VPN aprobada. Rexistra a hora de recepción en logcat e a hora de visualización en cada execución. Se a entrega difire pero a visualización non, a ruta de rede é a variable; se ambas son idénticas, segue mirando a aplicación.
Entrega ao responsable de rede os portos, a limitación do proxy, o tempo de espera medido e a decisión sobre a omisión nunha soa nota. «Apaga a VPN» non é un achado, e permitir todo o tráfico de Google non é unha solución acoutada.