Androidin push-ilmoitukset eivät toimi VPN:n kanssa? Tarkista nämä
FCM pitää omaa lähtevää yhteyttään porteilla 5228-5230. Tarkista välityspalvelimen sääntö, NAT-aikakatkaisu ja VPN:n ohitus ennen kuin kosket ilmoitusasetuksiin.
Ilmoitukset lakkaavat saapumasta puhelimeen, joka muuten selaa yrityksen VPN:n kautta ongelmitta. Verkkosivut latautuvat, sovellus avautuu ja viestit ilmestyvät vain kotona tai kun tunneli on kytketty pois. Firebase Cloud Messagingiin rakennetussa sovelluksessa push-kanava on erillinen pitkäkestoinen lähtevä yhteys, ei HTTPS-polku, jonka selain juuri todisti. Käy nämä tarkistukset järjestyksessä läpi ja pysähdy ensimmäiseen, joka epäonnistuu.
Varmista, että sovellus todella käyttää FCM:ää
Jokainen ilmoitus ei ole push. Jotkin sovellus ajoittaa paikallisesti, jotkin kysellään HTTPS:n yli ja jotkin saapuvat toimittajan kanavaa pitkin, jolla ei ole mitään tekemistä Firebasen kanssa. Jos sovelluksen manifesti ja riippuvuudet sisältävät Firebase Messagingin, sen ilmoitukset kulkevat yleensä FCM-yhteyden kautta, ja asiakasohjelmakirjasto kirjaa rekisteröinnin ennustettavan tunnisteen alle.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase
Lokissa oleva rekisteröintitunnus vahvistaa siirtotien. Ilman sitä debuggaat sovellustason ilmoitusputkea, eivätkä palomuurin muutokset auta. Tämä ero on tärkeä, koska toimitettu viesti, jota ei koskaan näytetä, ja viesti, joka ei koskaan saavu, näyttävät käyttäjälle samalta.
Tarkista lähtevät portit, älä verkkosivua
FCM-laitteiden yhteydet ovat laitteen aloittamia TCP-yhteyksiä porttiin 5228, varavaihtoehtoina 5229 ja 5230 ja viimeisenä keinona 443. Palomuuri, joka sallii 443:n selaamista varten, voi silti rikkoa pushin, eikä sääntö, joka sallii sovelluksen API-verkkotunnuksen, kata viestinnän päätepisteitä, jotka ovat erillisiä palveluita.
Nämä ovat puhelimesta lähteviä yhteyksiä. Et julkaise saapuvaa porttia laitteessa etkä VPN-yhdyskäytävässä, joten jos joku ehdottaa portin edelleenohjausta, suunnittelu on jo mennyt pieleen. Sama koskee sääntöä, joka avaa yhden portin kaikille internetin osoitteille: rajaa se dokumentoituihin kohteisiin.
| 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 |
Firebasen verkko-opas toteaa myös, että FCM:n toimitusprotokollaa ei voi kuljettaa tavallisen HTTP-välityspalvelimen yli. Siksi selaimen onnistuminen yrityksen verkkoproksin kautta ei todista mitään push-soketista: ne ovat kaksi eri asiakasta, joilla on eri polut.
Tarkista joutokäynnin aikakatkaisut, jotka tappavat soketin
FCM-yhteys pysyy avoinna viestien välillä, mikä tekee siitä herkän NAT- ja tilallisen tarkastuksen aikakatkaisuille. Firebasen ohje pyytää vähintään 30 minuutin joutokäyntisietoa siellä, missä tällaisia käytäntöjä sovelletaan. Viiden minuutin istuntoaikakatkaisu poistaa mappauksen hiljaa, ja puhelin yhdistää uudelleen vasta kun jokin herättää sen, joten viestit saapuvat purskeina tai eivät lainkaan.
Lue palomuurin tai VPN-yhdyskäytävän istuntotaulukkoa ja etsi puhelimen yhteys portteihin 5228-5230. Vertaa sen jäljellä olevaa elinikää dokumentoituun arvoon. Jos se on lyhyempi, kasvata näiden porttien aikakatkaisua sen sijaan että muuttaisit laitteen kaikkia käytäntöjä, koska globaalia aikakatkaisun muutosta on vaikea perustella ja vielä vaikeampi perua.
Push-toimitus riippuu myös siitä, että päätepisteen mappaus säilyy Wi-Fi:n ja matkapuhelinverkon välisessä roamingissa. Yhteen liitäntään sidottu mappaus voi pudota siirtymässä, vaikka molemmat verkot sallivat portit.
Päätä, onko VPN:n ohitus hyväksyttävää
Androidin VPN-asiakkaat voivat sallia liikenteen ohittaa tunnelin, ja FCM voi käyttää alla olevaa verkkoa, kun ohitus on sallittu. Push-kanava pysyy siinä tapauksessa salattuna, mutta se ei enää kanna tunnelin osoitetta, joten VPN:n IP-naamiointi ei koske sitä. Se on käytäntökompromissi, ei toimintahäiriö.
Jos käytäntösi kieltää ohituksen, tunnelipolun on kuljetettava yhteys: portit auki, aikakatkaisut riittävän pitkät, välityspalvelin ei tiellä. Älä hiljaa jätä hallittua palvelua pois äläkä löysää lukitusta vain siksi, että ilmoitukset toimivat hallitsemattomassa verkossa. VPN-kuvake ei kerro, minkä reitin tietty palvelu valitsi
Erota toimitus näyttämisestä ja testaa kerran
Lupa, kanava-asetukset, Älä häiritse ja sovelluskohtaiset kytkimet päättävät, näytetäänkö toimitettu viesti. Android 13:ssa ja uudemmissa ilmoituslupa on ajonaikainen myönnytys, ja evätty myönnytys tuottaa hiljaisuuden, joka näyttää täsmälleen estetyltä portilta. Viesti, joka saapui mutta jota ei näytetty, on esitysongelma; käsittele se erikseen.
Tee yksi valvottu testi sen sijaan, että lähettäisit viestejä sattumanvaraisesti. Pidä laite, tili ja sovellus samoina, lähetä yksi viesti tunnetulla aikaleimalla ja vertaa VPN-tilannetta hyväksyttyyn verkkoon ilman VPN:ää. Kirjaa logcatin vastaanottoaika ja näyttöaika jokaisesta ajosta. Jos toimitus eroaa mutta näyttäminen ei, verkkopolku on muuttuja; jos molemmat ovat samat, katso edelleen sovellusta.
Anna verkon omistajalle portit, välityspalvelimen rajoitus, mitattu aikakatkaisu ja ohituspäätös yhdessä muistiinpanossa. «Kytke VPN pois» ei ole löydös, eikä kaiken Google-liikenteen salliminen ole rajattu korjaus.