Le notifiche push Android non funzionano con una VPN? Controlla questo

Le notifiche smettono di arrivare su un telefono che per il resto naviga bene attraverso la VPN aziendale. Le pagine web si caricano, l'app si apre e i messaggi compaiono solo a casa o dopo aver disattivato il tunnel. In un'app basata su Firebase Cloud Messaging, il canale push è una connessione in uscita separata e di lunga durata, non il percorso HTTPS che il browser ha appena dimostrato. Segui questi controlli in ordine e fermati al primo che fallisce.

Verifica che l'app usi davvero FCM

Non ogni notifica è un push. Alcune sono pianificate localmente dall'app, altre vengono interrogate via HTTPS e altre arrivano tramite un canale del fornitore che non ha nulla a che fare con Firebase. Se il manifest e le dipendenze dell'app includono Firebase Messaging, le sue notifiche viaggiano di norma sulla connessione FCM, e la libreria client registra la registrazione sotto un tag prevedibile.

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

Un token di registrazione nel log conferma il trasporto. Senza, stai eseguendo il debug di una pipeline di notifiche a livello di app, e le modifiche al firewall non aiuteranno. Questa distinzione conta perché un messaggio consegnato ma mai mostrato e un messaggio che non arriva mai appaiono identici all'utente.

Controlla le porte in uscita, non il sito web

Le connessioni dei dispositivi a FCM sono TCP originate dal dispositivo verso la porta 5228, con 5229 e 5230 come riserve e 443 come ultima risorsa. Un firewall che consente la 443 per la navigazione può comunque rompere il push, e una regola che consente il dominio API di un'app non copre gli endpoint di messaggistica, che sono servizi separati.

Sono connessioni in uscita dal telefono. Non pubblichi una porta in entrata sul dispositivo né sul gateway VPN, quindi se qualcuno propone un port forwarding, il progetto è già sbagliato. Lo stesso vale per una regola che apre una porta a ogni indirizzo di internet: limitarla alle destinazioni documentate.

Le indicazioni di rete di Firebase afferma anche che il protocollo di consegna FCM non può essere trasportato su un normale proxy HTTP. Il fatto che un browser funzioni attraverso il proxy web aziendale non dimostra quindi nulla sul socket push: sono due client diversi con percorsi diversi.

Controlla i timeout di inattività che uccidono il socket

La connessione FCM resta aperta tra i messaggi, il che la rende sensibile ai timeout NAT e di ispezione stateful. Le indicazioni di Firebase chiedono almeno 30 minuti di tolleranza all'inattività dove si applicano tali politiche. Un timeout di sessione di cinque minuti rimuove silenziosamente la mappatura, e il telefono si riconnette solo quando qualcosa lo sveglia, così i messaggi arrivano a raffiche o non arrivano affatto.

Leggi la tabella delle sessioni sul firewall o sul gateway VPN e trova la connessione del telefono verso 5228-5230. Confronta la sua vita residua con il valore documentato. Se è più breve, aumenta il timeout per quelle porte invece di cambiare tutte le politiche sul dispositivo, perché una modifica globale del timeout è difficile da giustificare e ancora più difficile da annullare.

La consegna push dipende anche dal fatto che la mappatura dell'endpoint sopravviva a un roaming tra Wi-Fi e rete mobile. Una mappatura legata a una sola interfaccia può essere scartata al passaggio anche quando entrambe le reti consentono le porte.

Decidi se il bypass della VPN è accettabile

I client VPN Android possono consentire al traffico di aggirare il tunnel, e FCM può usare la rete sottostante quando quel bypass è consentito. In quel caso il canale push resta crittografato, ma non porta più l'indirizzo del tunnel, quindi il mascheramento IP della VPN non si applica. È un compromesso di politica, non un malfunzionamento.

Se la tua politica vieta il bypass, il percorso del tunnel deve portare la connessione: porte aperte, timeout abbastanza lunghi, proxy fuori dai piedi. Non escludere silenziosamente un servizio gestito e non allentare il blocco solo perché le notifiche funzionano su una rete non gestita. L'icona della VPN non dice quale percorso ha scelto un dato servizio

Separa la consegna dalla visualizzazione, poi prova una volta

Permesso, impostazioni del canale, Non disturbare e interruttori per app decidono se un messaggio consegnato viene mostrato. Su Android 13 e versioni successive il permesso per le notifiche è una concessione a runtime, e una concessione negata produce un silenzio che appare esattamente come una porta bloccata. Un messaggio arrivato ma non mostrato è un problema di presentazione; trattalo a parte.

Esegui un test controllato invece di inviare messaggi a caso. Mantieni fissi dispositivo, account e app, invia un solo messaggio con un timestamp noto e confronta la condizione VPN con una rete senza VPN approvata. Registra l'ora di ricezione in logcat e l'ora di visualizzazione per ogni esecuzione. Se la consegna differisce ma la visualizzazione no, la variabile è il percorso di rete; se entrambe sono identiche, continua a guardare l'app.

Consegna al responsabile di rete le porte, il limite del proxy, il timeout misurato e la decisione sul bypass in un'unica nota. «Spegni la VPN» non è un risultato, e consentire tutto il traffico Google non è una correzione mirata.