Android-pushmeldingen wurkje net mei in VPN? Kontrolearje dit
FCM hâldt syn eigen útgeande ferbining op poarten 5228-5230. Kontrolearje de proxyregel, NAT-timeout en VPN-bypass foardat jo de meldingsynstellingen oanreitsje.
Meldingen komme net mear oan op in tillefoan dy't oars prima browset fia it bedriuws-VPN. Websiden lade, de app iepenet, en berjochten ferskine allinnich thús of nei't de tunnel útskeakele is. Foar in app boud op Firebase Cloud Messaging is it pushkanaal in aparte, langduorjende útgeande ferbining, net it HTTPS-paad dat de browser krekt bewizen hat. Wurkje dizze kontrôles yn folchoarder ôf en stop by de earste dy't mislearret.
Befêstigje dat de app echt FCM brûkt
Net elke melding is in push. Guon wurde lokaal troch de app pland, guon wurde fia HTTPS oproppen, en guon komme fia in leveransierkanaal dat neat mei Firebase te meitsjen hat. As it manifest en de ôfhinklikheden fan de app Firebase Messaging befetsje, reizgje de meldingen normaal oer de FCM-ferbining, en de kliïntbibleteek logt de registraasje ûnder in foarsisbere tag.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseIn registraasjetoken yn de log befêstiget it ferfier. Sûnder ien debugge jo in meldingspiip op appnivo, en fjoerwâlwizigingen helpe net. Dit ûnderskied is wichtich, want in levere berjocht dat nea toand wurdt en in berjocht dat nea oankomt sjogge der foar de brûker itselde út.
Kontrolearje de útgeande poarten, net de website
FCM-apparaatferbinings binne troch it apparaat begûn TCP nei poarte 5228, mei 5229 en 5230 as fallback en 443 as lêste opsje. In fjoerwâl dy't 443 tastean foar browsen kin push noch hieltyd brekke, en in regel dy't it API-domein fan in app tastiet, dekt de berjochtsjende-einpunten net, dy't aparte tsjinsten binne.
Dit binne útgeande ferbinings fan de tillefoan. Jo publisearje gjin yngeande poarte op it apparaat of de VPN-gateway, dus as immen port-forwarding foarstelt, is it ûntwerp al ferkeard gien. Itselde jildt foar in regel dy't ien poarte iepenet foar alle adressen op it ynternet: behein it ta de dokumintearre bestimmingen.
| 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 |
De netwurkrieding fan Firebase stelt ek dat it FCM-leveringsprotokol net oer in gewoane HTTP-proxy ferfierd wurde kin. Dat in browser fia de bedriuwswebproxy wurket, bewiist dus neat oer de pushsocket: it binne twa ferskillende kliïnten mei ferskillende paden.
Kontrolearje de idle-timeouts dy't de socket deadzje
De FCM-ferbining bliuwt iepen tusken berjochten, wat har gefoelich makket foar NAT- en stateful-inspection-timeouts. De rjochting fan Firebase freget om teminsten 30 minuten idle-tolerânsje wêr't sok belied jildt. In sesje-timeout fan fiif minuten ferwideret de mapping stil, en de tillefoan ferbynt pas wer as iets him wekker makket, dus berjochten komme yn bursts of hielendal net.
Lês de sesjetabel op de fjoerwâl of VPN-gateway en fyn de ferbining fan de tillefoan nei 5228-5230. Fergelykje har oerbleaune libbensdoer mei de dokumintearre wearde. As dy koarter is, ferheegje dan de timeout foar dy poarten ynstee fan al it belied op it apparaat te feroarjen, want in globale timeoutwiziging is min te rjochtfeardigjen en noch hurder werom te draaien.
Push-levering hinget ek ôf fan it feit dat de einpuntmapping in roam tusken Wi-Fi en mobyl oerlibbet. In mapping dy't oan ien interface bûn is, kin by de oerdracht ferlern gean, sels as beide netwurken de poarten tastean.
Beslis oft VPN-bypass akseptabel is
Android-VPN-kliïnten kinne ferkear tastean it tunnel te bypassen, en FCM kin it ûnderlizzende netwurk brûke as dy bypass tastien is. It pushkanaal bliuwt yn dat gefal fersifere, mar it ferfiert net langer it adres fan de tunnel, dus de IP-maskering fan it VPN jildt der net foar. Dat is in beliedskompromis, gjin steuring.
As jo belied bypass ferbiedt, moat it tunnelpaad de ferbining drage: poarten iepen, timeouts lang genôch, proxy net yn de wei. Slút in beheard tsjinst net stil bûten en fersoarge it slot net allinnich om't meldingen op in net-beheard netwurk wurkje. It VPN-ikoan fertelt net hokker paad in tsjinst keazen hat
Skied levering fan werjaan, en test ien kear
Tastimming, kanaalynstellingen, Net steure en skiften per app beslisse oft in levere berjocht toand wurdt. Op Android 13 en letter is de meldingstastimming in runtime-ferliening, en in wegere ferliening produsearret stilte dy't der krekt as in blokkearre poarte útsjocht. In berjocht dat oankaam mar net toand waard, is in presintaasjeprobleem; behannelje it apart.
Doch ien kontrolearre test ynstee fan berjochten ad hoc te stjoeren. Hâld it apparaat, it akkount en de app fêst, stjoer ien berjocht mei in bekend tiidstimpel, en fergelykje de VPN-situaasje mei in goedkard netwurk sûnder VPN. Registrearje de ûntfangstiid yn logcat en de werjaantiid foar elke run. As de levering ferskilt mar it werjaan net, is it netwurkpaad de fariabele; as beide identyk binne, bliuw dan nei de app sjen.
Jou de netwurkeigner de poarten, de proxybeheining, de metten timeout en de bypassbeslissing yn ien notysje. «Skeakel it VPN út» is gjin befinning, en al it Google-ferkear tastean is gjin beheinde oplossing.