Hindi gumagana ang push notification ng Android sa VPN? Suriin ito
May sariling outbound na koneksyon ang FCM sa mga port 5228-5230. Suriin ang proxy rule, NAT timeout at VPN bypass bago hawakan ang mga setting ng notification.
Humihinto ang pagdating ng mga notification sa teleponong maayos namang nagba-browse sa corporate VPN. Naglo-load ang mga web page, bumubukas ang app, at lumalabas lang ang mga mensahe sa bahay o pagkatapos patayin ang tunnel. Sa app na binuo sa Firebase Cloud Messaging, ang push channel ay hiwalay at pangmatagalang outbound na koneksyon, hindi ang HTTPS na ruta na katatunayan lang ng browser. Sundin ang mga pagsusuring ito nang sunod-sunod at tumigil sa unang mabibigo.
Kumpirmahin na talagang gumagamit ng FCM ang app
Hindi lahat ng notification ay push. Ang iba ay iniiskedyul ng app sa lokal, ang iba ay hinihingi via HTTPS, at ang iba ay dumarating sa channel ng vendor na walang kinalaman sa Firebase. Kung kasama sa manifest at dependencies ng app ang Firebase Messaging, karaniwang dumadaan ang mga notification nito sa FCM connection, at itinatala ng client library ang registration sa ilalim ng mahuhulaang tag.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseAng registration token sa log ang nagpapatunay ng transport. Kung wala ito, nagde-debug ka ng pipeline ng notification sa antas ng app, at hindi makakatulong ang mga pagbabago sa firewall. Mahalaga ang pagkakaibang ito dahil ang mensaheng naihatid pero hindi kailanman naipakita at ang mensaheng hindi dumarating ay magkamukha para sa user.
Suriin ang outbound na port, hindi ang website
Ang mga koneksyon ng device sa FCM ay TCP na sinisimulan ng device patungo sa port 5228, na may 5229 at 5230 bilang backup at 443 bilang huling opsyon. Ang firewall na nagpapahintulot ng 443 para sa pag-browse ay maaari pa ring makasira ng push, at ang rule na nagpapahintulot ng API domain ng app ay hindi sumasaklaw sa mga messaging endpoint, na hiwalay na serbisyo.
Ito ay mga outbound na koneksyon mula sa telepono. Hindi ka naglalathala ng inbound na port sa device o sa VPN gateway, kaya kung may magmungkahi ng port forwarding, mali na ang disenyo. Ganoon din sa rule na nagbubukas ng isang port sa lahat ng address sa internet: limitahan ito sa mga dokumentadong destinasyon.
| 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 |
Sinasabi rin ng Ang gabay sa network ng Firebase na hindi maaaring dalhin ang FCM delivery protocol sa ordinaryong HTTP proxy. Kaya ang paggana ng browser sa corporate web proxy ay walang pinapatunayan tungkol sa push socket: dalawang magkaibang client sila na may magkaibang ruta.
Suriin ang idle timeout na pumapatay sa socket
Nananatiling bukas ang FCM connection sa pagitan ng mga mensahe, kaya sensitibo ito sa NAT at stateful-inspection timeout. Hinihiling ng gabay ng Firebase ang hindi bababa sa 30 minutong pagpapahintulot sa idle kung saan nalalapat ang ganitong patakaran. Ang limang minutong session timeout ay tahimik na nag-aalis ng mapping, at nag-reconnect lang ang telepono kapag may gumising dito, kaya dumarating ang mga mensahe nang sabay-sabay o hindi talaga.
Basahin ang session table sa firewall o VPN gateway at hanapin ang koneksyon ng telepono sa 5228-5230. Ihambing ang natitirang buhay nito sa dokumentadong halaga. Kung mas maikli, taasan ang timeout para sa mga port na iyon sa halip na baguhin ang lahat ng patakaran sa device, dahil mahirap ipagtanggol ang pandaigdigang pagbabago ng timeout at mas mahirap itong bawiin.
Nakadepende rin ang push delivery sa kung ang endpoint mapping ay makakaligtas sa roaming sa pagitan ng Wi-Fi at cellular. Ang mapping na nakatali sa isang interface ay maaaring itapon sa handover kahit pinapayagan ng parehong network ang mga port.
Magpasya kung katanggap-tanggap ang VPN bypass
Maaaring payagan ng Android VPN client ang trapik na lumampas sa tunnel, at maaaring gamitin ng FCM ang underlying network kapag pinapayagan ang bypass na iyon. Sa ganitong kaso, nananatiling naka-encrypt ang push channel, pero hindi na nito dinadala ang address ng tunnel, kaya hindi nalalapat dito ang IP masking ng VPN. Iyon ay trade-off sa patakaran, hindi sira.
Kung ipinagbabawal ng patakaran mo ang bypass, dapat dalhin ng tunnel path ang koneksyon: bukas ang mga port, sapat ang haba ng timeout, wala sa daan ang proxy. Huwag tahimik na ibukod ang managed service at huwag luwagan ang lock dahil lang gumagana ang notification sa unmanaged network. Hindi sinasabi ng icon ng VPN kung aling ruta ang pinili ng isang serbisyo
Ihiwalay ang delivery sa display, pagkatapos ay subukan nang isang beses
Permission, channel setting, Huwag Abalahin at per-app toggle ang nagpapasya kung ipapakita ang naihatid na mensahe. Sa Android 13 at mas bago, ang notification permission ay runtime na pagbibigay, at ang tinanggihang pagbibigay ay nagdudulot ng katahimikang kamukhang-kamukha ng naka-block na port. Ang mensaheng dumating pero hindi naipakita ay problema sa presentasyon; hiwalay na tratuhin.
Gumawa ng isang kontroladong pagsubok sa halip na magpadala ng mensahe nang basta-basta. Panatilihing hindi nagbabago ang device, account at app, magpadala ng isang mensahe na may kilalang timestamp, at ihambing ang kalagayan sa VPN sa isang aprubadong network na walang VPN. Itala ang oras ng pagtanggap sa logcat at oras ng pagpapakita sa bawat pagtakbo. Kung iba ang delivery pero hindi ang display, ang network path ang variable; kung pareho ang dalawa, patuloy na tingnan ang app.
Ibigay sa may-ari ng network ang mga port, limitasyon ng proxy, nasukat na timeout at desisyon sa bypass sa isang tala. «Patayin ang VPN» ay hindi natuklasan, at ang pagpayag sa lahat ng trapik ng Google ay hindi limitadong pagwawasto.