Les notificacions push d’Android no funcionen amb VPN? Comprova això
FCM manté la seva pròpia connexió de sortida als ports 5228-5230. Comprova la regla del proxy, el temps d’espera NAT i l’excepció del VPN abans de tocar la configuració de notificacions.
Les notificacions deixen d’arribar a un telèfon que, d’altra banda, navega bé per la VPN corporativa. Les pàgines carreguen, l’aplicació s’obre, i els missatges només apareixen a casa o després de desconnectar el túnel. Per a una aplicació feta sobre Firebase Cloud Messaging, el canal push és una connexió de sortida de llarga durada a part, no el camí HTTPS que el navegador acaba de demostrar. Fes aquestes comprovacions en ordre i atura’t a la primera que falli.
Confirma que l’aplicació realment utilitza FCM
No tota notificació és un push. Algunes les programa l’aplicació localment, algunes es consulten per HTTPS, i d’altres arriben per un canal de proveïdor que no té res a veure amb Firebase. Si el manifest i les dependències de l’aplicació inclouen Firebase Messaging, les seves notificacions solen viatjar pel canal FCM, i la biblioteca client registra l’alta sota una etiqueta previsible.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseUn testimoni de registre al log confirma el transport. Sense ell estàs depurant un circuit de notificacions a nivell d’aplicació, i els canvis al tallafoc no ajudaran. Aquesta distinció importa perquè un missatge lliurat però mai mostrat i un missatge que no ha arribat mai es veuen iguals per a l’usuari.
Comprova els ports de sortida, no el lloc web
Les connexions dels dispositius FCM són TCP de sortida des del telèfon cap al port 5228, amb 5229 i 5230 com a alternatives i 443 com a últim recurs. Un tallafoc que permet 443 per navegar pot trencar el push, i una regla que permet el domini de l’API de l’aplicació no cobreix els punts finals de missatgeria, que són serveis separats.
Són connexions de sortida des del telèfon. No publiques cap port d’entrada al dispositiu ni a la passarel·la VPN, així que si algú proposa un reenviament de port, el disseny ja ha fallat. El mateix val per a una regla que obre un port a totes les adreces d’internet: limita-la a les destinacions documentades.
| 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 |
Les guies de xarxa de Firebase també diuen que el protocol de lliurament FCM no es pot transportar per un proxy HTTP corrent. Per tant, que el navegador passi pel proxy web corporatiu no demostra res sobre el sòcol push: són dos clients diferents amb camins diferents.
Comprova els temps d’espera d’inactivitat que maten el sòcol
La connexió FCM queda oberta entre missatges, cosa que la fa sensible als temps d’espera de NAT i d’inspecció amb estat. Les guies de Firebase demanen almenys 30 minuts de tolerància a la inactivitat on s’apliquen aquestes polítiques. Un temps d’espera de sessió de cinc minuts elimina el mapatge en silenci, i el telèfon només es reconecta quan alguna cosa el desperta, així que els missatges arriben a munts o no arriben.
Llegeix la taula de sessions del tallafoc o de la passarel·la VPN i troba la connexió del telèfon cap a 5228-5230. Compara la vida restant amb el valor documentat. Si és més curta, apuja el temps d’espera d’aquells ports en lloc de canviar totes les polítiques del dispositiu.
El lliurament també depèn que el mapatge del punt final sobrevisqui un canvi entre Wi-Fi i mòbil. Un mapatge lligat a una interfície es pot perdre en el traspàs encara que les dues xarxes permetin els ports.
Decideix si l’excepció del VPN és acceptable
Els clients VPN d’Android poden permetre que el trànsit eviti el túnel, i FCM pot usar la xarxa subjacent quan aquesta excepció està permesa. El canal push continua xifrat, però ja no porta l’adreça del túnel, així que l’emmascarament d’IP del VPN no s’hi aplica. És un compromís de política, no un mal funcionament.
Si la teva política prohibeix l’excepció, el camí del túnel ha de portar la connexió: ports oberts, temps d’espera prou llargs, proxy fora del camí. No excloguis en silenci un servei gestionat ni afluixis el bloqueig només perquè les notificacions funcionen en una xarxa no gestionada. La icona del VPN no diu quin camí ha triat cada servei.
Separa el lliurament de la visualització i prova un cop
El permís, la configuració del canal, No molestar i els interruptors per aplicació decideixen si es mostra un missatge lliurat. A Android 13 i posteriors el permís de notificacions s’atorga en temps d’execució, i una denegació produeix un silenci que sembla exactament un port bloquejat. Un missatge que ha arribat però no s’ha mostrat és un problema de presentació; tracta’l a part.
Fes una prova controlada en lloc d’enviar missatges a l’atzar. Mantén fixos el dispositiu, el compte i l’aplicació, envia un sol missatge amb una marca de temps coneguda i compara la condició VPN amb una xarxa aprovada sense VPN. Anota l’hora de recepció al logcat i l’hora de visualització a cada passada. Si el lliurament difereix però la visualització no, el camí de xarxa és la variable; si tots dos són iguals, continua mirant l’aplicació.
Dona al responsable de xarxa els ports, la limitació del proxy, el temps d’espera mesurat i la decisió sobre l’excepció en una sola nota. Apagar la VPN no és una troballa, i permetre tot el trànsit de Google no és una correcció acotada.