اعلان‌های فوری اندروید روی VPN کار نمی‌کنند؟ این موارد را بررسی کنید
FCM اتصال خروجی خود را روی پورت‌های 5228-5230 نگه می‌دارد. پیش از دست‌زدن به تنظیمات اعلان، قاعده پروکسی، مهلت NAT و دورزدن VPN را بررسی کنید.
اعلان‌ها روی تلفنی که در بقیه موارد از طریق VPN سازمانی خوب مرور می‌کند، دیگر نمی‌رسند. صفحه‌های وب باز می‌شوند، برنامه باز می‌شود و پیام‌ها فقط در خانه یا پس از خاموش‌کردن تونل ظاهر می‌شوند. در برنامه‌ای که بر Firebase Cloud Messaging ساخته شده، کانال push یک اتصال خروجی جداگانه و بلندمدت است، نه مسیر HTTPS که مرورگر همین حالا اثبات کرد. این بررسی‌ها را به ترتیب انجام دهید و در اولین موردی که شکست خورد توقف کنید.
تأیید کنید که برنامه واقعاً از FCM استفاده می‌کند
هر اعلانی push نیست. برخی را برنامه به‌صورت محلی زمان‌بندی می‌کند، برخی از طریق 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 را برای مرور مجاز می‌کند باز هم می‌تواند push را بشکند، و قاعده‌ای که دامنه 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 معمولی عبور داد. بنابراین موفقیت یک مرورگر از طریق پروکسی وب سازمانی هیچ چیزی درباره سوکت push اثبات نمی‌کند: این دو کلاینت متفاوت با مسیرهای متفاوت هستند.
مهلت‌های بی‌کاری را که سوکت را می‌کشند بررسی کنید
اتصال FCM بین پیام‌ها باز می‌ماند، و همین آن را نسبت به مهلت‌های NAT و بازرسی حالت‌دار حساس می‌کند. راهنمای Firebase در جایی که چنین سیاست‌هایی اعمال می‌شود، حداقل 30 دقیقه تحمل بی‌کاری می‌خواهد. مهلت نشست پنج‌دقیقه‌ای نگاشت را بی‌صدا حذف می‌کند و تلفن تنها زمانی دوباره وصل می‌شود که چیزی بیدارش کند، پس پیام‌ها به‌صورت دسته‌ای می‌رسند یا اصلاً نمی‌رسند.
جدول نشست را روی فایروال یا دروازه VPN بخوانید و اتصال تلفن به 5228-5230 را پیدا کنید. عمر باقی‌مانده آن را با مقدار مستند مقایسه کنید. اگر کوتاه‌تر است، مهلت آن پورت‌ها را افزایش دهید نه اینکه همه سیاست‌های دستگاه را تغییر دهید، چون تغییر مهلت سراسری سخت توجیه می‌شود و بازگرداندنش سخت‌تر است.
تحویل push همچنین به این بستگی دارد که نگاشت نقطه پایانی از جابه‌جایی میان Wi-Fi و شبکه همراه جان سالم به در ببرد. نگاشتی که به یک رابط گره خورده است می‌تواند در هنگام تحویل حذف شود، حتی وقتی هر دو شبکه پورت‌ها را مجاز می‌کنند.
تصمیم بگیرید آیا دورزدن VPN قابل قبول است
کلاینت‌های VPN اندروید می‌توانند اجازه دهند ترافیک از تونل دور بزند و FCM ممکن است وقتی این دورزدن مجاز است از شبکه زیرین استفاده کند. در آن حالت کانال push رمزنگاری‌شده می‌ماند، اما دیگر نشانی تونل را حمل نمی‌کند، پس پوشاندن IP توسط VPN بر آن اعمال نمی‌شود. این یک بده‌بستان سیاستی است، نه نقص فنی.
اگر سیاست شما دورزدن را ممنوع می‌کند، مسیر تونل باید اتصال را حمل کند: پورت‌ها باز، مهلت‌ها به‌اندازه کافی طولانی و پروکسی سر راه نباشد. یک سرویس مدیریت‌شده را بی‌صدا کنار نگذارید و قفل را فقط به این دلیل که اعلان‌ها روی شبکه مدیریت‌نشده کار می‌کنند شل نکنید. نماد VPN نمی‌گوید یک سرویس مشخص کدام مسیر را انتخاب کرده است
تحویل را از نمایش جدا کنید و یک بار آزمایش کنید
مجوز، تنظیمات کانال، مزاحم نشوید و کلیدهای هر برنامه تعیین می‌کنند که پیام تحویل‌شده نمایش داده شود یا نه. در اندروید 13 و بعد از آن، مجوز اعلان یک اعطای زمان اجراست و اعطای ردشده سکوتی ایجاد می‌کند که دقیقاً شبیه پورت مسدود است. پیامی که رسید اما نمایش داده نشد یک مشکل نمایش است؛ آن را جداگانه بررسی کنید.
به‌جای فرستادن پیام‌های پراکنده، یک آزمایش کنترل‌شده انجام دهید. دستگاه، حساب و برنامه را ثابت نگه دارید، یک پیام با زمان مشخص بفرستید و وضعیت VPN را با یک شبکه بدون VPN تأییدشده مقایسه کنید. زمان دریافت در logcat و زمان نمایش را برای هر اجرا ثبت کنید. اگر تحویل متفاوت بود اما نمایش نه، مسیر شبکه متغیر است؛ اگر هر دو یکسان بودند، همچنان به برنامه نگاه کنید.
پورت‌ها، محدودیت پروکسی، مهلت اندازه‌گیری‌شده و تصمیم دورزدن را در یک یادداشت به مسئول شبکه بدهید. «VPN را خاموش کن» یک یافته نیست و مجاز کردن تمام ترافیک گوگل یک اصلاح محدود نیست.