شارلز مغلق، لكن جهاز Mac لديك ما زال يشير إلى 127.0.0.1

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

القفزة الأولى هي هذا الجهاز، لا الخادم

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

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

الخطوة 1: اقرأ حالة الوكيل الحالية

ابدأ بالعرض للقراءة فقط، لأنه يخبرك بما يعتقده النظام قبل أن يفسره أي تطبيق:

scutil --proxy

انظر إلى HTTPEnable، HTTPProxy، HTTPPort، وما يقابلها في HTTPS، وأي ProxyAutoConfigEnable مع عنوان URL الخاص به. وكيل مفعّل على منفذ لا يستمع عليه شيء هو عطلك. عنوان PAC هو الشكل الآخر: يمكن أن يكون الإعداد نشطًا دون عنوان يدوي مرئي، لأن الملف يختار الوكيل وقت الطلب.

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

الخطوة 2: اعرف من يملك الإعداد

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

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

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

الخطوة 3: غيّر أضيق شيء

عطّل الإدخال غير المقصود المحدد للخدمة المحددة. لا تبدّل كل خدمة ولا تمسح لوحة الوكلاء بأكملها، لأن خدمة الـ VPN وخدمة Wi-Fi الأساسية تحتفظان بإعدادات منفصلة وقد تكون إحداهما صحيحة.

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

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

الخطوة 4: إذا اختفى الوكيل وما زال يفشل

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

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

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

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