شبكة VPN تعمل لكن تطبيقًا واحدًا بلا إنترنت؟ افحص الوكيل الخاص به

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

أي طبقة تملك إعداد الوكيل

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

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

اقرأ القيمة التي تستخدمها كل أداة فعلًا

اطبع التهيئة قبل تغييرها، وانسخ سلسلة الوكيل الدقيقة إلى مكان يمكنك الاستعادة منه. متغيرات الصدفة هي أسرع فحص لأدوات سطر الأوامر، لأن عميل VPN عادة لا يمسها.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

نفّذ فقط السطر المطابق للمنصة أمامك، ثم اقرأ الخرج بحثًا عن المضيف والمنفذ وبيانات الاعتماد. قيمة مثل http://proxy.corp.example:8080 تعني أن الأداة تسأل ذلك المضيف عن كل طلب، بينما نتيجة فارغة تعني أنها تمر مباشرة وأن العطل الحقيقي في مكان آخر. احجب جزء المستخدم وكلمة المرور قبل لصق الخرج في تذكرة، لأن تلك السلاسل بيانات اعتماد حية أكثر بكثير مما يفترض الناس.

الأدوات التي تملك محرك وكيل خاصًا بها تحتاج إلى دليل خاص بها. يعلن Curl القرار الذي اتخذه عندما ترفع مستوى التفصيل، وهذا أفضل من التخمين من البيئة، والعلم نفسه يوضح ما إذا جرى تحليل الأسماء محليًا أم عند الوكيل.

امسح التجاوز وأعد اختبار الطلب نفسه

غيّر طبقة واحدة، ثم كرر الطلب نفسه الذي فشل، لأن عنوان URL مختلفًا لا يثبت شيئًا. امسح متغيرات البيئة في الصدفة الحالية أولًا، لأن هذا التعديل قابل للعكس ولا يمكنه كسر النفق:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

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

على macOS، تحقق من أن ملف تهيئة تلقائية لا يوفّر القيمة، ثم أوقف وكيل الخدمة وأكد التغيير. على Windows، تذكر أن إعداد WinHTTP وإعداد المتصفح لكل مستخدم كائنان مختلفان، لذا يمكن لأداة سطر أوامر نظيفة أن تتعايش مع متصفح ما زال يشير إلى خادم قديم. الإضافات تستحق الشيء نفسه من الشك: إضافة وكيل يمكنها إعادة كتابة الطلبات لملف شخصي واحد فقط، وهذا بالضبط شكل عطل يصيب متصفحًا واحدًا ولا شيء غيره.

تحقق من أن الإصلاح يصمد بعد إعادة التشغيل

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

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

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

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