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 ਟ੍ਰੈਫ਼ਿਕ ਮਨਜ਼ੂਰ ਕਰਨਾ ਕੋਈ ਸੀਮਿਤ ਹੱਲ ਨਹੀਂ ਹੈ।