Oznámení přestanou docházet na telefon, který jinak přes firemní VPN normálně prohlíží web. Stránky se načítají, aplikace se otevře, ale zprávy se objeví jen doma nebo po vypnutí tunelu. U aplikace postavené na Firebase Cloud Messaging je push kanál samostatné dlouhodobé odchozí spojení, ne cesta HTTPS, kterou právě prokázal prohlížeč. Projděte tyto kontroly popořadě a zastavte se u první, která selže.

Ověřte, že aplikace skutečně používá FCM

Ne každé oznámení je push. Některá plánuje aplikace lokálně, některá se stahují přes HTTPS a některá přicházejí kanálem dodavatele, který s Firebase nemá nic společného. Pokud manifest a závislosti aplikace obsahují Firebase Messaging, její oznámení obvykle putují přes spojení FCM a klientská knihovna zapisuje registraci pod předvídatelnou značkou.

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

Registrační token v logu potvrzuje přenos. Bez něj ladíte oznamovací řetězec na úrovni aplikace a změny ve firewallu nepomohou. Tento rozdíl je důležitý, protože doručená, ale nikdy nezobrazená zpráva a zpráva, která nikdy nedorazila, vypadají pro uživatele stejně.

Kontrolujte odchozí porty, ne web

Spojení zařízení FCM jsou odchozí TCP z telefonu na port 5228, s 5229 a 5230 jako záložními a 443 jako poslední možností. Firewall, který povoluje 443 pro prohlížení, může push přesto zlomit, a pravidlo povolující doménu API aplikace nepokrývá koncové body zasílání zpráv, protože to jsou samostatné služby.

Jsou to odchozí spojení z telefonu. Na zařízení ani na VPN bráně nepublikujete vstupní port, takže pokud někdo navrhne přesměrování portu, návrh je už špatný. Totéž platí pro pravidlo, které otevírá jeden port na každou adresu na internetu: omezme je na dokumentované cíle.

PortRoleWhat to verify
5228Primary FCM connectionOutbound allowed and session state kept
5229, 5230Fallback portsOften missing from hand-written allowlists
443Last-resort fallbackWorks only if the client actually falls back
HTTP proxyNot a supported FCM transportProxy exclusion or bypass, not a port rule

Síťové pokyny Firebase také uvádějí, že doručovací protokol FCM nelze přenášet přes běžnou HTTP proxy. Úspěch prohlížeče přes firemní webovou proxy tedy o push socketu nic nedokazuje: jsou to různí klienti s různými cestami.

Zkontrolujte časové limity nečinnosti, které socket zabíjejí

Spojení FCM zůstává mezi zprávami otevřené, což je citlivé na časové limity NAT a stavové inspekce. Pokyny Firebase žádají alespoň 30 minut tolerance nečinnosti tam, kde takové zásady platí. Časový limit relace pět minut mapování tiše odstraní a telefon se připojí znovu, jen když ho něco probudí, takže zprávy přicházejí v dávkách nebo vůbec.

Přečtěte tabulku relací na firewallu nebo VPN bráně a najděte spojení telefonu na 5228-5230. Porovnejte zbývající životnost s dokumentovanou hodnotou. Pokud je kratší, zvyšte limit pro tyto porty, místo abyste měnili všechny zásady na zařízení.

Doručení také závisí na tom, zda mapování koncového bodu přežije přechod mezi Wi-Fi a mobilní sítí. Mapování vázané na jedno rozhraní může být při předání ztraceno, i když obě sítě porty povolují.

Rozhodněte, zda je obcházení VPN přijatelné

Klienti Android VPN mohou povolit provozu obejít tunel a FCM pak může použít podkladovou síť, když je to povoleno. Push kanál zůstává šifrovaný, ale nese už adresu tunelu, takže maskování IP přes VPN na něj neplatí. Je to kompromis v politice, ne porucha.

Pokud vaše politika obcházení zakazuje, musí spojení nést cesta tunelem: porty otevřené, limity dost dlouhé, proxy v cestě není. Nevylučujte tiše spravovanou službu a nepovolujte uzamčení jen proto, že oznámení fungují v nespravované síti. Ikona VPN neříká, kterou cestu daná služba zvolila.

Oddělte doručení od zobrazení a otestujte jednou

Oprávnění, nastavení kanálu, Nerušit a přepínače pro aplikaci rozhodují, zda se doručená zpráva zobrazí. Na Androidu 13 a novějším se oprávnění k oznámením uděluje za běhu a odmítnutí vytvoří ticho, které vypadá přesně jako blokovaný port. Zpráva, která dorazila, ale nezobrazila se, je problém prezentace, řešte ji odděleně.

Proveďte jeden řízený test místo posílání zpráv nahodile. Držte zařízení, účet a aplikaci pevně, pošlete jednu zprávu se známým časovým razítkem a porovnejte stav s VPN se schválenou sítí bez VPN. Zapište čas přijetí v logcatu a čas zobrazení pro každé kolo. Pokud se doručení liší a zobrazení ne, proměnnou je síťová cesta; pokud jsou obě stejná, hledejte dál v aplikaci.

Dejte správci sítě porty, omezení proxy, změřený limit a rozhodnutí o obcházení v jedné poznámce. Vypněte VPN není zjištění a povolení veškerého provozu Google není omezená oprava.

Související články