Powiadomienia push w Androidzie nie działają z VPN? Sprawdź to

Powiadomienia przestają docierać na telefonie, który poza tym dobrze przegląda sieć przez firmowy VPN. Strony się ładują, aplikacja się otwiera, a wiadomości pojawiają się tylko w domu lub po wyłączeniu tunelu. W aplikacji zbudowanej na Firebase Cloud Messaging kanał push to osobne, długotrwałe połączenie wychodzące, a nie ścieżka HTTPS, którą właśnie udowodniła przeglądarka. Przejdź te kontrole po kolei i zatrzymaj się na pierwszej, która zawiedzie.

Potwierdź, że aplikacja naprawdę używa FCM

Nie każde powiadomienie to push. Część aplikacja planuje lokalnie, część jest odpytywana przez HTTPS, a część przychodzi kanałem dostawcy, który nie ma nic wspólnego z Firebase. Jeśli manifest i zależności aplikacji zawierają Firebase Messaging, jej powiadomienia zwykle podróżują połączeniem FCM, a biblioteka klienta zapisuje rejestrację pod przewidywalnym znacznikiem.

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

Token rejestracji w logu potwierdza transport. Bez niego debugujesz potok powiadomień na poziomie aplikacji, a zmiany w zaporze nie pomogą. To rozróżnienie ma znaczenie, bo dostarczona, ale nigdy niepokazana wiadomość i wiadomość, która nigdy nie dociera, wyglądają dla użytkownika tak samo.

Sprawdź porty wychodzące, nie stronę internetową

Połączenia urządzeń do FCM to TCP inicjowane przez urządzenie na port 5228, z 5229 i 5230 jako zapasowymi oraz 443 jako ostatnią deską ratunku. Zapora, która pozwala na 443 do przeglądania, nadal może zepsuć push, a reguła zezwalająca na domenę API aplikacji nie obejmuje punktów końcowych obsługi wiadomości, które są osobnymi usługami.

To połączenia wychodzące z telefonu. Nie publikujesz portu wejściowego na urządzeniu ani na bramie VPN, więc jeśli ktoś proponuje przekierowanie portu, projekt jest już błędny. To samo dotyczy reguły otwierającej jeden port dla wszystkich adresów w internecie: ogranicz ją do udokumentowanych celów.

Wskazówki sieciowe Firebase stwierdza również, że protokołu dostarczania FCM nie można przenieść przez zwykłe proxy HTTP. To, że przeglądarka działa przez firmowe proxy internetowe, niczego więc nie dowodzi w kwestii gniazda push: to dwa różne klienty o różnych ścieżkach.

Sprawdź limity bezczynności, które zabijają gniazdo

Połączenie FCM pozostaje otwarte między wiadomościami, co czyni je wrażliwym na limity czasu NAT i inspekcji stanowej. Wskazówki Firebase proszą o co najmniej 30 minut tolerancji bezczynności tam, gdzie obowiązują takie zasady. Pięciominutowy limit sesji po cichu usuwa mapowanie, a telefon łączy się ponownie tylko wtedy, gdy coś go obudzi, więc wiadomości przychodzą seriami albo wcale.

Odczytaj tabelę sesji na zaporze lub bramie VPN i znajdź połączenie telefonu do 5228-5230. Porównaj jego pozostały czas życia z udokumentowaną wartością. Jeśli jest krótszy, zwiększ limit czasu dla tych portów, zamiast zmieniać wszystkie zasady na urządzeniu, bo globalna zmiana limitu jest trudna do uzasadnienia i jeszcze trudniejsza do cofnięcia.

Dostarczanie push zależy też od tego, czy mapowanie punktu końcowego przetrwa roaming między Wi-Fi a siecią komórkową. Mapowanie przypisane do jednego interfejsu może zostać odrzucone przy przełączeniu, nawet gdy obie sieci zezwalają na te porty.

Zdecyduj, czy obejście VPN jest dopuszczalne

Klienty VPN w Androidzie mogą zezwolić ruchowi na ominięcie tunelu, a FCM może wtedy korzystać z sieci pod spodem. Kanał push pozostaje w tym przypadku zaszyfrowany, ale nie przenosi już adresu tunelu, więc maskowanie IP przez VPN go nie obejmuje. To kompromis polityki, a nie usterka.

Jeśli zasady zabraniają obejścia, ścieżka tunelu musi przenosić połączenie: porty otwarte, limity czasu wystarczająco długie, proxy nie na drodze. Nie wykluczaj po cichu usługi zarządzanej i nie poluzowuj blokady tylko dlatego, że powiadomienia działają w sieci niezarządzanej. Ikona VPN nie mówi, którą trasę wybrała dana usługa

Oddziel dostarczanie od wyświetlania, a potem przetestuj raz

Uprawnienie, ustawienia kanału, Nie przeszkadzać i przełączniki dla poszczególnych aplikacji decydują, czy dostarczona wiadomość zostanie pokazana. W Androidzie 13 i nowszych uprawnienie do powiadomień jest przyznawane w czasie działania, a odmowa daje ciszę, która wygląda dokładnie jak zablokowany port. Wiadomość, która dotarła, ale nie została pokazana, to problem prezentacji; zajmij się nim osobno.

Wykonaj jeden kontrolowany test zamiast wysyłać wiadomości bez planu. Utrzymuj urządzenie, konto i aplikację bez zmian, wyślij jedną wiadomość ze znanym znacznikiem czasu i porównaj stan z VPN oraz w zatwierdzonej sieci bez VPN. Zapisz czas odbioru w logcat i czas wyświetlenia dla każdego przebiegu. Jeśli dostarczanie się różni, a wyświetlanie nie, zmienną jest ścieżka sieciowa; jeśli oba są identyczne, przyglądaj się dalej aplikacji.

Przekaż właścicielowi sieci porty, ograniczenie proxy, zmierzony limit czasu i decyzję o obejściu w jednej notatce. «Wyłącz VPN» nie jest ustaleniem, a zezwolenie na cały ruch Google nie jest ukierunkowaną poprawką.