Android-pushnotiser fungerar inte med VPN? Kontrollera detta

Notiser slutar komma på en telefon som annars surfar bra genom företagets VPN. Webbsidor laddas, appen öppnas och meddelanden dyker bara upp hemma eller efter att tunneln stängts av. I en app byggd på Firebase Cloud Messaging är pushkanalen en separat långlivad utgående anslutning, inte den HTTPS-väg som webbläsaren just bevisade. Gå igenom dessa kontroller i ordning och stanna vid den första som misslyckas.

Bekräfta att appen verkligen använder FCM

Inte varje notis är en push. Vissa schemaläggs lokalt av appen, andra hämtas via HTTPS och ytterligare andra kommer via en leverantörskanal som inte har något med Firebase att göra. Om appens manifest och beroenden innehåller Firebase Messaging går dess notiser vanligtvis över FCM-anslutningen, och klientbiblioteket loggar registreringen under en förutsägbar tagg.

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

En registreringstoken i loggen bekräftar transporten. Utan den felsöker du en notispipeline på appnivå, och brandväggsändringar hjälper inte. Skillnaden spelar roll eftersom ett levererat meddelande som aldrig visas och ett meddelande som aldrig kommer fram ser likadana ut för användaren.

Kontrollera de utgående portarna, inte webbplatsen

FCM-enhetsanslutningar är TCP som enheten initierar mot port 5228, med 5229 och 5230 som reserv och 443 som sista utväg. En brandvägg som tillåter 443 för surfande kan ändå bryta push, och en regel som tillåter en apps API-domän täcker inte meddelandetjänstens slutpunkter, som är separata tjänster.

Detta är utgående anslutningar från telefonen. Du publicerar ingen inkommande port på enheten eller på VPN-gatewayen, så om någon föreslår portvidarebefordran har designen redan gått fel. Samma sak gäller en regel som öppnar en port mot alla adresser på internet: begränsa den till de dokumenterade målen.

Firebases nätverksriktlinjer säger också att FCM:s leveransprotokoll inte kan bäras över en vanlig HTTP-proxy. Att en webbläsare fungerar genom företagets webbproxy bevisar därför ingenting om push-socketen: de är två olika klienter med olika vägar.

Kontrollera idle-timeouterna som dödar socketen

FCM-anslutningen hålls öppen mellan meddelanden, vilket gör den känslig för NAT- och tillståndskontrolltimeouter. Firebases riktlinjer begär minst 30 minuters tolerans för inaktivitet där sådana policyer gäller. En sessionstimeout på fem minuter tar bort mappningen tyst, och telefonen återansluter bara när något väcker den, så meddelanden kommer i skurar eller inte alls.

Läs sessionstabellen i brandväggen eller VPN-gatewayen och hitta telefonens anslutning till 5228-5230. Jämför återstående livslängd med det dokumenterade värdet. Är den kortare höjer du timeouten för dessa portar i stället för att ändra alla policyer på enheten, eftersom en global timeoutändring är svår att motivera och ännu svårare att ångra.

Pushleverans beror också på att slutpunktsmappningen överlever roaming mellan Wi-Fi och mobilnät. En mappning knuten till ett gränssnitt kan släppas vid överlämningen även när båda näten tillåter portarna.

Avgör om VPN-bypass är acceptabelt

Android VPN-klienter kan tillåta trafik att gå förbi tunneln, och FCM kan använda det underliggande nätet när den bypassen är tillåten. Pushkanalen förblir krypterad i så fall, men den bär inte längre tunnelns adress, så VPN:ens IP-maskering gäller inte för den. Det är en policyavvägning, inte ett fel.

Om din policy förbjuder bypass måste tunnelvägen bära anslutningen: portar öppna, timeouter tillräckligt långa, proxy ur vägen. Uteslut inte tyst en hanterad tjänst och lätta inte på låset bara för att notiser fungerar i ett ohanterat nät. VPN-ikonen säger inte vilken väg en viss tjänst valde

Separera leverans från visning och testa en gång

Behörighet, kanalinställningar, Stör ej och reglage per app avgör om ett levererat meddelande visas. I Android 13 och senare ges notisbehörigheten vid körning, och ett avslag ger tystnad som ser precis ut som en blockerad port. Ett meddelande som kom men inte visades är ett visningsproblem; hantera det separat.

Gör ett kontrollerat test i stället för att skicka meddelanden slumpmässigt. Håll enheten, kontot och appen oförändrade, skicka ett enda meddelande med en känd tidsstämpel och jämför VPN-läget med ett godkänt nätverk utan VPN. Anteckna mottagningstiden i logcat och visningstiden för varje körning. Om leveransen skiljer sig men visningen inte gör det är nätverksvägen variabeln; om båda är lika, fortsätt titta på appen.

Ge nätverksansvarig portarna, proxybegränsningen, den uppmätta timeouten och beslutet om bypass i en enda anteckning. «Stäng av VPN:en» är inget fynd, och att tillåta all Google-trafik är ingen avgränsad åtgärd.