Notifikasi push Android tidak berfungsi saat pakai VPN? Periksa ini
FCM mempertahankan koneksi keluar sendiri pada port 5228-5230. Periksa aturan proxy, batas waktu NAT, dan bypass VPN sebelum menyentuh pengaturan notifikasi.
Notifikasi berhenti datang pada ponsel yang sebaliknya menjelajah dengan baik melalui VPN perusahaan. Halaman web dimuat, aplikasi terbuka, dan pesan hanya muncul di rumah atau setelah terowongan dimatikan. Pada aplikasi yang dibangun di atas Firebase Cloud Messaging, kanal push adalah koneksi keluar terpisah yang berumur panjang, bukan jalur HTTPS yang baru saja dibuktikan browser. Jalankan pemeriksaan ini secara berurutan dan berhenti pada yang pertama gagal.
Pastikan aplikasi benar-benar memakai FCM
Tidak setiap notifikasi adalah push. Sebagian dijadwalkan secara lokal oleh aplikasi, sebagian diambil melalui HTTPS, dan sebagian datang melalui kanal vendor yang tidak ada hubungannya dengan Firebase. Jika manifes dan dependensi aplikasi menyertakan Firebase Messaging, notifikasinya biasanya berjalan melalui koneksi FCM, dan pustaka klien mencatat pendaftaran di bawah tag yang dapat diprediksi.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebase
Token pendaftaran di log memastikan transportnya. Tanpanya, Anda men-debug saluran notifikasi tingkat aplikasi, dan perubahan firewall tidak akan membantu. Perbedaan ini penting karena pesan yang terkirim tetapi tidak pernah ditampilkan dan pesan yang tidak pernah tiba terlihat sama bagi pengguna.
Periksa port keluar, bukan situs webnya
Koneksi perangkat ke FCM adalah TCP yang berasal dari perangkat ke port 5228, dengan 5229 dan 5230 sebagai cadangan dan 443 sebagai pilihan terakhir. Firewall yang mengizinkan 443 untuk penjelajahan tetap dapat memutus push, dan aturan yang mengizinkan domain API suatu aplikasi tidak mencakup titik akhir perpesanan, yang merupakan layanan terpisah.
Ini adalah koneksi keluar dari ponsel. Anda tidak menerbitkan port masuk di perangkat atau gateway VPN, jadi jika seseorang menyarankan penerusan port, desainnya sudah salah. Hal yang sama berlaku untuk aturan yang membuka satu port ke semua alamat di internet: batasi ke tujuan yang terdokumentasi.
| 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 jaringan Firebase juga menyatakan bahwa protokol pengiriman FCM tidak dapat dibawa melalui proxy HTTP biasa. Karena itu, keberhasilan browser melalui proxy web perusahaan tidak membuktikan apa pun tentang soket push: keduanya klien berbeda dengan jalur berbeda.
Periksa batas waktu diam yang mematikan soket
Koneksi FCM tetap terbuka di antara pesan, sehingga peka terhadap batas waktu NAT dan inspeksi stateful. Panduan Firebase meminta toleransi diam minimal 30 menit di tempat kebijakan semacam itu berlaku. Batas waktu sesi lima menit menghapus pemetaan secara diam-diam, dan ponsel hanya tersambung kembali ketika sesuatu membangunkannya, sehingga pesan datang bergelombang atau tidak sama sekali.
Baca tabel sesi pada firewall atau gateway VPN dan temukan koneksi ponsel ke 5228-5230. Bandingkan sisa masa hidupnya dengan nilai yang terdokumentasi. Jika lebih pendek, naikkan batas waktu untuk port tersebut alih-alih mengubah semua kebijakan pada perangkat, karena perubahan batas waktu global sulit dibenarkan dan lebih sulit dibatalkan.
Pengiriman push juga bergantung pada pemetaan titik akhir yang bertahan saat berpindah antara Wi-Fi dan seluler. Pemetaan yang terikat pada satu antarmuka dapat hilang saat serah terima bahkan ketika kedua jaringan mengizinkan port tersebut.
Putuskan apakah bypass VPN dapat diterima
Klien VPN Android dapat mengizinkan lalu lintas melewati terowongan, dan FCM dapat memakai jaringan di bawahnya ketika bypass itu diizinkan. Kanal push tetap terenkripsi dalam kasus itu, tetapi tidak lagi membawa alamat terowongan, sehingga penyamaran IP VPN tidak berlaku padanya. Itu kompromi kebijakan, bukan kerusakan.
Jika kebijakan Anda melarang bypass, jalur terowongan harus membawa koneksi: port terbuka, batas waktu cukup panjang, proxy tidak menghalangi. Jangan diam-diam mengecualikan layanan terkelola atau melonggarkan penguncian hanya karena notifikasi berfungsi di jaringan tak terkelola. Ikon VPN tidak memberi tahu jalur mana yang dipilih suatu layanan
Pisahkan pengiriman dari tampilan, lalu uji sekali
Izin, pengaturan kanal, Jangan Ganggu, dan tombol per aplikasi menentukan apakah pesan yang terkirim ditampilkan. Pada Android 13 dan setelahnya izin notifikasi adalah pemberian saat runtime, dan pemberian yang ditolak menghasilkan kesunyian yang tampak persis seperti port terblokir. Pesan yang tiba tetapi tidak ditampilkan adalah masalah penyajian; tangani secara terpisah.
Lakukan satu uji terkendali alih-alih mengirim pesan secara sembarangan. Jaga perangkat, akun, dan aplikasi tetap sama, kirim satu pesan dengan stempel waktu yang diketahui, dan bandingkan kondisi VPN dengan jaringan tanpa VPN yang disetujui. Catat waktu penerimaan di logcat dan waktu tampil untuk setiap percobaan. Jika pengiriman berbeda tetapi tampilan tidak, jalur jaringan adalah variabelnya; jika keduanya identik, terus periksa aplikasinya.
Berikan kepada pemilik jaringan port, batasan proxy, batas waktu terukur, dan keputusan bypass dalam satu catatan. «Matikan VPN» bukan temuan, dan mengizinkan semua lalu lintas Google bukan perbaikan yang terarah.