اینڈرائیڈ پش اطلاعات 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 بائی پاس قابل قبول ہے
Android VPN کلائنٹس ٹریفک کو ٹنل سے بچ کر جانے دیتے ہیں، اور جب یہ بائی پاس اجازت شدہ ہو تو FCM بنیادی نیٹ ورک استعمال کر سکتا ہے۔ اس صورت میں پش چینل خفیہ رہتا ہے، مگر اب ٹنل کا پتہ نہیں اٹھاتا، اس لیے VPN کی IP ماسکنگ اس پر لاگو نہیں ہوتی۔ یہ پالیسی کا سمجھوتہ ہے، خرابی نہیں۔
اگر آپ کی پالیسی بائی پاس منع کرتی ہے تو ٹنل راستے کو ہی کنکشن اٹھانا ہوگا: پورٹس کھلی، ٹائم آؤٹ کافی طویل، پراکسی راستے میں نہ ہو۔ کسی منظم سروس کو خاموشی سے خارج نہ کریں اور صرف اس لیے لاک ڈاؤن ڈھیلا نہ کریں کہ اطلاعات غیر منظم نیٹ ورک پر کام کرتی ہیں۔ VPN آئیکن یہ نہیں بتاتا کہ کسی سروس نے کون سا راستہ چنا
ڈیلیوری کو ڈسپلے سے الگ کریں، پھر ایک بار جانچیں
اجازت، چینل ترتیبات، ڈسٹرب نہ کریں اور فی ایپ ٹوگلز طے کرتے ہیں کہ پہنچایا گیا پیغام دکھایا جائے گا یا نہیں۔ Android 13 اور بعد میں اطلاعات کی اجازت رن ٹائم گرانٹ ہے، اور مسترد شدہ گرانٹ ایسی خاموشی پیدا کرتی ہے جو بالکل بلاک شدہ پورٹ جیسی دکھتی ہے۔ آیا مگر نہ دکھایا گیا پیغام پیشکش کا مسئلہ ہے؛ اسے الگ دیکھیں۔
پیغامات بے ترتیب بھیجنے کے بجائے ایک کنٹرول شدہ ٹیسٹ کریں۔ ڈیوائس، اکاؤنٹ اور ایپ کو مستقل رکھیں، معلوم ٹائم اسٹیمپ کے ساتھ ایک ہی پیغام بھیجیں، اور VPN کی حالت کا موازنہ منظور شدہ بغیر VPN نیٹ ورک سے کریں۔ ہر رن کے لیے logcat وصولی وقت اور ڈسپلے وقت درج کریں۔ اگر ڈیلیوری مختلف ہے مگر ڈسپلے نہیں، تو نیٹ ورک راستہ متغیر ہے؛ اگر دونوں یکساں ہیں تو ایپ کو دیکھتے رہیں۔
نیٹ ورک کے مالک کو پورٹس، پراکسی کی حد، ماپا گیا ٹائم آؤٹ اور بائی پاس کا فیصلہ ایک ہی نوٹ میں دیں۔ «VPN بند کرو» کوئی دریافت نہیں ہے، اور ساری Google ٹریفک کی اجازت دینا کوئی محدود اصلاح نہیں ہے۔