Notificările push Android nu funcționează cu VPN? Verifică acestea

Notificările nu mai sosesc pe un telefon care, în rest, navighează bine prin VPN-ul companiei. Paginile web se încarcă, aplicația se deschide, iar mesajele apar doar acasă sau după oprirea tunelului. Într-o aplicație construită pe Firebase Cloud Messaging, canalul push este o conexiune de ieșire separată și de lungă durată, nu calea HTTPS pe care browserul tocmai a dovedit-o. Parcurge aceste verificări în ordine și oprește-te la prima care eșuează.

Confirmă că aplicația folosește într-adevăr FCM

Nu orice notificare este push. Unele sunt programate local de aplicație, altele sunt interogate prin HTTPS, iar altele sosesc printr-un canal al furnizorului care nu are nimic de-a face cu Firebase. Dacă manifestul și dependențele aplicației includ Firebase Messaging, notificările ei circulă de obicei prin conexiunea FCM, iar biblioteca client înregistrează înregistrarea sub o etichetă previzibilă.

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

Un token de înregistrare în log confirmă transportul. Fără el, depanezi o conductă de notificări la nivel de aplicație, iar modificările de firewall nu vor ajuta. Această distincție contează pentru că un mesaj livrat dar niciodată afișat și un mesaj care nu ajunge niciodată arată la fel pentru utilizator.

Verifică porturile de ieșire, nu site-ul web

Conexiunile dispozitivelor la FCM sunt TCP inițiate de dispozitiv către portul 5228, cu 5229 și 5230 ca rezerve și 443 ca ultimă soluție. Un firewall care permite 443 pentru navigare poate totuși rupe push-ul, iar o regulă care permite domeniul API al unei aplicații nu acoperă punctele terminale de mesagerie, care sunt servicii separate.

Sunt conexiuni de ieșire de pe telefon. Nu publici un port de intrare pe dispozitiv sau pe gateway-ul VPN, așa că dacă cineva propune redirecționare de port, proiectarea a greșit deja. La fel se întâmplă cu o regulă care deschide un port către toate adresele de pe internet: limiteaz-o la destinațiile documentate.

Recomandările de rețea ale Firebase afirmă de asemenea că protocolul de livrare FCM nu poate fi transportat printr-un proxy HTTP obișnuit. Faptul că un browser funcționează prin proxy-ul web al companiei nu dovedește deci nimic despre socketul push: sunt doi clienți diferiți cu trasee diferite.

Verifică timeout-urile de inactivitate care omoară socketul

Conexiunea FCM rămâne deschisă între mesaje, ceea ce o face sensibilă la timeout-urile NAT și de inspecție cu stare. Recomandările Firebase cer cel puțin 30 de minute de toleranță la inactivitate acolo unde se aplică astfel de politici. Un timeout de sesiune de cinci minute elimină discret maparea, iar telefonul se reconectează doar când ceva îl trezește, așa că mesajele sosesc în rafale sau deloc.

Citește tabelul de sesiuni de pe firewall sau de pe gateway-ul VPN și găsește conexiunea telefonului către 5228-5230. Compară durata de viață rămasă cu valoarea documentată. Dacă este mai scurtă, crește timeout-ul pentru acele porturi în loc să schimbi toate politicile de pe dispozitiv, pentru că o modificare globală a timeout-ului este greu de justificat și și mai greu de anulat.

Livrarea push depinde și de supraviețuirea mapării punctului terminal la un roaming între Wi-Fi și rețeaua mobilă. O mapare legată de o singură interfață poate fi eliminată la transfer chiar și atunci când ambele rețele permit porturile.

Decide dacă ocolirea VPN este acceptabilă

Clienții VPN Android pot permite traficului să ocolească tunelul, iar FCM poate folosi rețeaua de dedesubt când acea ocolire este permisă. În acest caz canalul push rămâne criptat, dar nu mai poartă adresa tunelului, deci mascarea IP a VPN nu se aplică asupra lui. Este un compromis de politică, nu o defecțiune.

Dacă politica ta interzice ocolirea, traseul tunelului trebuie să transporte conexiunea: porturi deschise, timeout-uri suficient de lungi, proxy în afara drumului. Nu exclude discret un serviciu administrat și nu slăbi blocarea doar pentru că notificările funcționează într-o rețea neadministrată. Pictograma VPN nu spune ce traseu a ales un anumit serviciu

Separă livrarea de afișare, apoi testează o dată

Permisiunea, setările canalului, Nu deranja și comutatoarele pentru fiecare aplicație decid dacă un mesaj livrat este afișat. Pe Android 13 și versiunile ulterioare permisiunea de notificare este o acordare la rulare, iar o acordare refuzată produce o tăcere care arată exact ca un port blocat. Un mesaj care a sosit dar nu a fost afișat este o problemă de prezentare; tratează-l separat.

Fă un singur test controlat în loc să trimiți mesaje la întâmplare. Menține dispozitivul, contul și aplicația nemodificate, trimite un singur mesaj cu un marcaj de timp cunoscut și compară starea cu VPN cu o rețea fără VPN aprobată. Notează ora de primire în logcat și ora de afișare pentru fiecare rulare. Dacă livrarea diferă dar afișarea nu, traseul de rețea este variabila; dacă ambele sunt identice, continuă să te uiți la aplicație.

Dă responsabilului de rețea porturile, limitarea proxy-ului, timeout-ul măsurat și decizia privind ocolirea într-o singură notă. «Oprește VPN-ul» nu este o constatare, iar permiterea întregului trafic Google nu este o corectare delimitată.