إشعارات Android لا تعمل عبر VPN؟ تحقق من هذه النقاط
يحتفظ FCM باتصاله الصادر على المنافذ 5228-5230. تحقق من قاعدة الوسيط ومهلة NAT واستثناء VPN قبل تعديل إعدادات الإشعارات.
تتوقف الإشعارات عن الوصول على هاتف يتصفح بشكل طبيعي عبر شبكة VPN الخاصة بالشركة. تُفتح صفحات الويب ويُفتح التطبيق، لكن الرسائل لا تظهر إلا في المنزل أو بعد إيقاف النفق. في تطبيق مبني على Firebase Cloud Messaging، قناة الدفع اتصال صادر طويل الأمد منفصل، وليست مسار HTTPS الذي أثبته المتصفح. نفّذ هذه الفحوص بالترتيب وتوقف عند أول فحص يفشل.
تأكد من أن التطبيق يستخدم FCM فعلياً
ليست كل الإشعارات دفعاً. بعضها مجدول محلياً داخل التطبيق، وبعضها يُسحب عبر HTTPS، وبعضها يصل عبر قناة مورّد لا علاقة لها بـ Firebase. إذا تضمن بيان التطبيق وتبعياته Firebase Messaging، فعادة تمر إشعاراته عبر اتصال FCM، وتسجل مكتبة العميل التسجيل تحت وسم متوقع.
adb logcat -s FirebaseMessaging:V
adb shell dumpsys package <package> | grep -i firebaseوجود رمز تسجيل في السجل يؤكد وسيلة النقل. وبغيابه تكون تصحيح مسار إشعارات على مستوى التطبيق، ولن تساعد تغييرات الجدار الناري. هذا التمييز مهم لأن رسالة وصلت ولم تُعرض أبداً ورسالة لم تصل قط تبدوان للمستخدم متطابقتين.
افحص المنافذ الصادرة، لا موقع الويب
اتصالات أجهزة FCM هي اتصالات TCP تنشأ من الجهاز نحو المنفذ 5228، مع 5229 و 5230 كبدائل و 443 كخيار أخير. جدار ناري يسمح بـ 443 للتصفح قد يكسر الدفع، والقاعدة التي تسمح بنطاق API الخاص بالتطبيق لا تغطي نقاط نهاية المراسلة، فهي خدمات منفصلة.
هذه اتصالات صادرة من الهاتف. أنت لا تنشر منفذاً داخلاً على الجهاز أو بوابة VPN، فإن اقترح أحدهم تحويل منفذ فقد أخطأ التصميم أصلاً. الأمر نفسه لقاعدة تفتح منفذاً لكل عنوان على الإنترنت: قيّدها بالوجهات الموثقة.
| 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 |
إرشادات Firebase للشبكة تنص أيضاً على أن بروتوكول تسليم FCM لا يمكن نقله عبر وسيط HTTP عادي. نجاح المتصفح عبر وسيط الويب المؤسسي لا يثبت شيئاً عن مقبس الدفع: هما عميلان مختلفان ومساران مختلفان.
افحص مهل الخمول التي تقتل المقبس
يبقى اتصال FCM مفتوحاً بين الرسائل، ما يجعله حساساً لمهل NAT وفحص الحالة. تطلب إرشادات Firebase تحملاً للخمول لا يقل عن 30 دقيقة حيث تنطبق هذه السياسات. مهلة جلسة مدتها خمس دقائق تحذف التعيين بصمت، ولا يعيد الهاتف الاتصال إلا عند إيقاظه، فتصل الرسائل دفعات أو لا تصل.
اقرأ جدول الجلسات على الجدار الناري أو بوابة VPN واعثر على اتصال الهاتف بـ 5228-5230. قارن عمره المتبقي بالقيمة الموثقة. إن كان أقصر، ارفع المهلة لهذه المنافذ بدل تغيير كل سياسة على الجهاز.
يعتمد التسليم أيضاً على بقاء تعيين نقطة النهاية عبر التنقل بين Wi-Fi والشبكة الخلوية. التعيين المرتبط بواجهة واحدة قد يُسقط عند التسليم حتى لو سمحت الشبكتان بالمنافذ.
قرر ما إذا كان تجاوز VPN مقبولاً
يمكن لعملاء VPN على Android السماح للمرور بتجاوز النفق، وقد يستخدم FCM الشبكة الأساسية عند السماح بذلك. تبقى قناة الدفع مشفرة لكنها لا تحمل عنوان النفق، فلا ينطبق إخفاء IP الخاص بـ VPN عليها. هذه مقايضة سياسة لا عطل.
إذا كانت سياستك تمنع التجاوز، فعلى مسار النفق حمل الاتصال: منافذ مفتوحة، ومهل كافية، ووسيط لا يعترض الطريق. لا تستبعد خدمة مُدارة بصمت ولا ترخِ الإغلاق لأن الإشعارات تعمل على شبكة غير مُدارة. أيقونة VPN لا تخبرك بالمسار الذي اختاره كل خدمة.
افصل التسليم عن العرض ثم اختبر مرة واحدة
الإذن وإعدادات القناة وعدم الإزعاج ومفاتيح كل تطبيق تحدد ما إذا كانت الرسالة الواصلة ستُعرض. في Android 13 وما بعده إذن الإشعارات منح وقت التشغيل، والرفض ينتج صمتاً يشبه منفذاً محظوراً تماماً. الرسالة التي وصلت ولم تُعرض مشكلة عرض، فتعامل معها منفصلة.
نفّذ اختباراً واحداً مضبوطاً بدل إرسال رسائل عشوائياً. ثبّت الجهاز والحساب والتطبيق، وأرسل رسالة واحدة بطابع زمني معروف، وقارن حالة VPN بشبكة معتمدة بلا VPN. سجّل وقت استلام logcat ووقت العرض لكل محاولة. إن اختلف التسليم ولم يختلف العرض فمسار الشبكة هو المتغير؛ وإن تطابق الاثنان فواصل فحص التطبيق.
أعطِ مالك الشبكة المنافذ وحدود الوسيط والمهلة المقاسة وقرار التجاوز في مذكرة واحدة. إيقاف VPN ليس نتيجة، والسماح لكل مرور Google ليس إصلاحاً محدداً.