تطبيق Android يرفض العمل عبر VPN: أي طبقة تقرّر

عندما يتوقف تطبيق Android عن العمل في اللحظة التي يرتفع فيها النفق، فقد تكون ثلاثة أمور مختلفة هي المسؤولة، وهي تُنتج أعطالًا متشابهة في المظهر. قد يقرأ التطبيق حالة الشبكة الخاصة بالهاتف ويرفض محليًا. وقد يصنّف الخادم العنوان الذي تصل منه ويرفضه. أو قد لا يكون للرفض أي علاقة بشبكة VPN إطلاقًا. الترتيب أدناه يجمع الأدلة قبل أن يغيّر أي شيء، لأن تغيير المخرج هو الخطوة الأكثر كلفة والأقل احتمالًا للمساعدة إذا كان الفحص محليًا.

الخطوة 1: اكتشف متى يرفض التطبيق

التوقيت هو أول أداة تمييز. امسح مخزن السجلات، وأعد إنتاج العطل، وانظر فيما فعله التطبيق قبل أن يشتكي:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

إذا رفض التطبيق قبل محاولة أي طلب صادر، فأنت أمام قرار محلي. وإذا اتصل وأرسل شيئًا ثم أظهر خطأً، فقد جاء الرفض من الجهة الأخرى. وإذا فشل التطبيق بالطريقة نفسها والنفق مغلق، فلم تكن شبكة VPN هي المتغير أصلًا.

تعامل مع هذا التوقيت كدليل لا كبرهان. فالتطبيق قد يعيد تشغيل استجابة مخزنة مؤقتًا، وقد تكون الطلبات الخلفية قد نجحت أو فشلت قبل أن تنظر. سجّل الطوابع الزمنية لآخر طلب ناجح وللخطأ، وليس فقط لحظة ظهور الرسالة.

الخطوة 2: اقرأ رؤية الهاتف نفسه للشبكة

يكشف Android حالة VPN كقدرة من قدرات الشبكة، لذا لا يحتاج التطبيق إلى قائمة بمزودين تجاريين ليلاحظ أن نفقًا نشط. فهو يسأل خدمة الاتصال عن الشبكة الحالية، والجواب يتضمن بت النقل الخاص بشبكة VPN:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

هذا الفحص محلي ورخيص، وهو يفسّر فئة كاملة من التقارير التي تقول «هذا التطبيق لا يعمل عبر VPN» دون أي تصنيف من بعيد. وما يستطيع التطبيق رؤيته يبقى معتمدًا على سياقه الشبكي الخاص، فلا تفترض أن كل تطبيق يفحص كل ملف تعريف على الجهاز.

من محطة عمل يمكنك رؤية الحالة نفسها على جهاز اختبار باستخدام adb shell dumpsys connectivity وبالبحث عن مدخل شبكة VPN. قارن تشغيلًا والنفق مفتوح بآخر والنفق مغلق، واحتفظ بكلا المخرجين.

الخطوة 3: اقرأ ما تراه الخدمة فعليًا

المراقب الآخر هو الخدمة. فهي ترى عنوان المصدر الذي يصل، وقد تتصرف بناءً على العنوان، أو شبكة الاستضافة خلفه، أو المنطقة، أو الناقل، أو إشارات مرتبطة بالحساب والجهاز. ولا شيء من ذلك هوية فريدة، والعنونة المشتركة تجعل الحجب الجانبي أمرًا طبيعيًا: عنوان واحد مقيّد يمكن أن يخرج مستخدمين لا علاقة لهم به يقفون خلف الترجمة نفسها.

احصل على العنوان من المسار نفسه الذي يستخدمه التطبيق، لا من متصفح على حاسوب محمول. على الهاتف، يُظهر طلب بسيط إلى خدمة استرجاع العنوان ما تستقبله الجهة البعيدة، ومقارنة ذلك بطلب عبر شبكة الهاتف المحمول تخبرك هل تغيّر العنوان أصلًا.

إذا كان التطبيق يعمل عبر شبكة الهاتف المحمول ويفشل عبر النفق بالحساب نفسه، فالرفض عند الطرف البعيد أو في سياسة التطبيق الخاصة. وإذا فشل في الحالتين، فشبكة VPN ليست العامل المميّز وعليك التوقف عن اختبار نقاط النهاية.

الخطوة 4: طابق الأدلة مع واحد من ثلاثة أحكام

ثلاث توليفات تغطي معظم التقارير تقريبًا. رفض دون أي محاولة صادرة بينما النفق نشط يشير إلى فحص محلي للنقل. وطلب يخرج ويعود بخطأ، أو مهلة على مضيف محدد، أو رسالة منطقة، يشير إلى الطرف البعيد. وفشل يتكرر عبر شبكة الهاتف المحمول دون نفق يشير إلى الحساب أو إصدار التطبيق أو سياسة الخدمة نفسها، ولن يحرّكه أي تغيير في VPN.

اكتب الحكم مع الدليل الذي أنتجه. وقيمة هذه الخطوة أنها توقف الحلقة التي يغيّر فيها أحدهم عقد الخروج أربع مرات لإصلاح فحص يعمل على الجهاز نفسه.

وهي أيضًا تحافظ على صدق الادعاءات. فالاستضافة الذاتية تغيّر نقطة النهاية ومخرجها إلى الإنترنت؛ لكنها لا تجعل Android ينسى أن شبكة VPN نشطة، ولا تضمن القبول لدى خدمة تصنّف العناوين. والمرشح المحلي يمكن أن ينطلق على شبكة VPN تملكها أنت بسهولة كما ينطلق على شبكة تجارية.

الخطوة 5: اسلك المسار المدعوم وتحقّق منه

ابدأ بسياسة المنتج الموثقة وبمسؤول الدعم فيه. أرسل إصدار العميل والرسالة الدقيقة ونافذة فشل ضيقة؛ ولا ترسل عمليات التقاط كاملة للحركة أو بيانات اعتماد لمجرد إثبات وجود خطأ.

إذا كانت الخدمة تسمح بالوصول المباشر وسياسة الجهاز تسمح به، فإن الاستبعاد لكل تطبيق هو الآلية المدعومة، وهو يزيل ذلك التطبيق من النفق عن قصد بدلًا من إخفاء النفق. عندها تخرج حركة التطبيق في مسارها الخاص، وهو قرار سياسة يجب أن يملكه أحدهم. وفي إعداد يحجب دون VPN قد يفقد تطبيق مستبعد الاتصال ببساطة، فاختبر تلك التوليفة قبل أن تعد بأنها تعمل.

بعد أي تغيير، أعد اختبار التوقيت الخاص بالخطوة الأولى، وتأكد من عمل التطبيق، وتأكد من أن كل تطبيق آخر ما زال يستخدم النفق. ثم أعد الإعداد السابق وتحقق من عودة العطل، لأن الإصلاح الذي لا تستطيع إعادة إنتاجه مصادفة ستلقاها مرة أخرى.