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 बायपास स्वीकार्य है या नहीं
Android VPN क्लाइंट ट्रैफ़िक को टनल से बाहर जाने दे सकते हैं, और जब यह बायपास अनुमत हो तो FCM अंतर्निहित नेटवर्क का उपयोग कर सकता है। उस स्थिति में पुश चैनल एन्क्रिप्टेड रहता है, पर अब टनल का पता नहीं ले जाता, इसलिए VPN का IP मास्किंग उस पर लागू नहीं होता। यह नीति का सौदा है, खराबी नहीं।
अगर आपकी नीति बायपास मना करती है, तो टनल पथ को कनेक्शन ले जाना होगा: पोर्ट खुले, टाइमआउट पर्याप्त लंबे, प्रॉक्सी रास्ते में नहीं। किसी प्रबंधित सेवा को चुपचाप बाहर न रखें और केवल इसलिए लॉकडाउन ढीला न करें कि सूचनाएँ अपरिचालित नेटवर्क पर काम करती हैं। VPN आइकन यह नहीं बताता कि किसी सेवा ने कौन-सा रास्ता चुना
डिलीवरी को प्रदर्शन से अलग करें, फिर एक बार परीक्षण करें
अनुमति, चैनल सेटिंग्स, परेशान न करें और प्रति-ऐप टॉगल तय करते हैं कि पहुँचाया गया संदेश दिखेगा या नहीं। Android 13 और उसके बाद सूचना अनुमति रनटाइम अनुदान है, और अस्वीकृत अनुदान वह खामोशी पैदा करता है जो बिल्कुल अवरुद्ध पोर्ट जैसी दिखती है। जो संदेश आया पर दिखा नहीं, वह प्रस्तुति की समस्या है; उसे अलग से देखें।
संदेश यूँ ही भेजने के बजाय एक नियंत्रित परीक्षण करें। डिवाइस, खाता और ऐप स्थिर रखें, ज्ञात टाइमस्टैम्प वाला एक ही संदेश भेजें, और VPN स्थिति की तुलना स्वीकृत बिना-VPN नेटवर्क से करें। हर रन के लिए logcat प्राप्ति समय और प्रदर्शन समय दर्ज करें। अगर डिलीवरी अलग है पर प्रदर्शन नहीं, तो नेटवर्क पथ चर है; अगर दोनों समान हैं, तो ऐप को देखते रहें।
नेटवर्क मालिक को पोर्ट, प्रॉक्सी की सीमा, मापा गया टाइमआउट और बायपास निर्णय एक ही नोट में दें। «VPN बंद करो» कोई निष्कर्ष नहीं है, और सारा Google ट्रैफ़िक अनुमत करना कोई सीमित समाधान नहीं है।