Notifikasi push Android tidak berfungsi dengan VPN? Semak ini
FCM mengekalkan sambungan keluar sendiri pada port 5228-5230. Semak peraturan proksi, tamat masa NAT dan pintasan VPN sebelum menyentuh tetapan notifikasi.
Notifikasi berhenti tiba pada telefon yang sebaliknya melayari dengan baik melalui VPN korporat. Halaman web dimuatkan, aplikasi terbuka, dan mesej hanya muncul di rumah atau selepas terowong dimatikan. Dalam aplikasi yang dibina atas Firebase Cloud Messaging, saluran push ialah sambungan keluar berasingan yang berumur panjang, bukan laluan HTTPS yang baru dibuktikan oleh pelayar. Lakukan semakan ini mengikut urutan dan berhenti pada yang pertama gagal.
Sahkan aplikasi benar-benar menggunakan FCM
Bukan setiap notifikasi ialah push. Sesetengah dijadualkan secara setempat oleh aplikasi, sesetengah diambil melalui HTTPS, dan sesetengah tiba melalui saluran vendor yang tiada kaitan dengan Firebase. Jika manifes dan kebergantungan aplikasi menyertakan Firebase Messaging, notifikasinya biasanya bergerak melalui sambungan FCM, dan pustaka klien merekodkan pendaftaran di bawah tag yang boleh dijangka.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase
Token pendaftaran dalam log mengesahkan pengangkutan. Tanpanya, anda menyahpepijat saluran notifikasi pada peringkat aplikasi, dan perubahan firewall tidak akan membantu. Perbezaan ini penting kerana mesej yang dihantar tetapi tidak pernah dipaparkan dan mesej yang tidak pernah tiba kelihatan sama kepada pengguna.
Semak port keluar, bukan laman web
Sambungan peranti FCM ialah TCP yang bermula dari peranti ke port 5228, dengan 5229 dan 5230 sebagai sandaran dan 443 sebagai pilihan terakhir. Firewall yang membenarkan 443 untuk pelayaran masih boleh memutuskan push, dan peraturan yang membenarkan domain API sesuatu aplikasi tidak meliputi titik akhir pemesejan, yang merupakan perkhidmatan berasingan.
Ini ialah sambungan keluar dari telefon. Anda tidak menerbitkan port masuk pada peranti atau gateway VPN, jadi jika seseorang mencadangkan pemajuan port, reka bentuknya sudah salah. Perkara sama berlaku untuk peraturan yang membuka satu port kepada semua alamat di internet: hadkan kepada destinasi yang didokumenkan.
| 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 |
Panduan rangkaian Firebase juga menyatakan bahawa protokol penghantaran FCM tidak boleh dibawa melalui proksi HTTP biasa. Oleh itu, kejayaan pelayar melalui proksi web korporat tidak membuktikan apa-apa tentang soket push: kedua-duanya klien berbeza dengan laluan berbeza.
Semak tamat masa melahu yang mematikan soket
Sambungan FCM kekal terbuka antara mesej, menjadikannya sensitif terhadap tamat masa NAT dan pemeriksaan stateful. Panduan Firebase meminta sekurang-kurangnya 30 minit toleransi melahu di tempat dasar sedemikian terpakai. Tamat masa sesi lima minit membuang pemetaan secara senyap, dan telefon hanya menyambung semula apabila sesuatu mengejutkannya, jadi mesej tiba secara berkelompok atau tidak sama sekali.
Baca jadual sesi pada firewall atau gateway VPN dan cari sambungan telefon ke 5228-5230. Bandingkan baki jangka hayatnya dengan nilai yang didokumenkan. Jika lebih pendek, naikkan tamat masa untuk port tersebut dan bukannya menukar semua dasar pada peranti, kerana perubahan tamat masa global sukar dijustifikasi dan lebih sukar untuk dibatalkan.
Penghantaran push juga bergantung pada pemetaan titik akhir yang bertahan semasa perayauan antara Wi-Fi dan selular. Pemetaan yang terikat pada satu antara muka boleh digugurkan semasa penyerahan walaupun kedua-dua rangkaian membenarkan port tersebut.
Tentukan sama ada pintasan VPN boleh diterima
Klien VPN Android boleh membenarkan trafik memintas terowong, dan FCM boleh menggunakan rangkaian di bawahnya apabila pintasan itu dibenarkan. Saluran push kekal disulitkan dalam kes itu, tetapi ia tidak lagi membawa alamat terowong, jadi penyamaran IP VPN tidak terpakai padanya. Itu pertukaran dasar, bukan kerosakan.
Jika dasar anda melarang pintasan, laluan terowong mesti membawa sambungan: port terbuka, tamat masa cukup panjang, proksi tidak menghalang. Jangan senyap mengecualikan perkhidmatan terurus atau melonggarkan kunci hanya kerana notifikasi berfungsi pada rangkaian tidak terurus. Ikon VPN tidak memberitahu laluan mana yang dipilih oleh sesuatu perkhidmatan
Asingkan penghantaran daripada paparan, kemudian uji sekali
Kebenaran, tetapan saluran, Jangan Ganggu dan togol setiap aplikasi menentukan sama ada mesej yang dihantar dipaparkan. Pada Android 13 dan kemudian, kebenaran notifikasi ialah pemberian masa jalan, dan pemberian yang ditolak menghasilkan kesunyian yang kelihatan sama seperti port tersekat. Mesej yang tiba tetapi tidak dipaparkan ialah masalah persembahan; tangani secara berasingan.
Lakukan satu ujian terkawal dan bukannya menghantar mesej secara sembarangan. Kekalkan peranti, akaun dan aplikasi tetap sama, hantar satu mesej dengan cap masa yang diketahui, dan bandingkan keadaan VPN dengan rangkaian tanpa VPN yang diluluskan. Catat masa penerimaan dalam logcat dan masa paparan bagi setiap larian. Jika penghantaran berbeza tetapi paparan tidak, laluan rangkaian ialah pemboleh ubah; jika kedua-duanya sama, terus periksa aplikasi.
Berikan kepada pemilik rangkaian port, had proksi, tamat masa yang diukur dan keputusan pintasan dalam satu nota. «Matikan VPN» bukan penemuan, dan membenarkan semua trafik Google bukan pembetulan yang berskop.