خلال اليومين الماضيين، تلقيت درسًا جديدًا من منظومة البروكسي في Windows. الأعراض الظاهرية كانت:
- Chrome يتصفح الإنترنت بشكل طبيعي
- سطر الأوامر يستطيع أيضًا الوصول إلى معظم المواقع
- Microsoft Store يخبرني بجدية تامة: أنت غير متصل بالإنترنت
وفي النهاية كانت الحقيقة: ليست المشكلة عدم وجود إنترنت، بل لأنهم “يسلكون مكدس شبكة مختلفًا”.
أولًا الخلاصة (للمشغولين)
في Windows غالبًا توجد على الأقل ثلاث مداخل شائعة للبروكسي:
WinINet: كثير من تطبيقات سطح المكتب، والمتصفحات، وواجهة UWP الأمامية تقرأه (و“بروكسي النظام” عادة يقصد هذه المنظومة)WinHTTP: كثير من خدمات النظام/المكوّنات الخلفية تمر عبره (مجموعة أوامرnetsh winhttp show proxy)- بروكسي متغيرات البيئة:
HTTP_PROXY/HTTPS_PROXY/NO_PROXY، موجهة أساسًا لأدوات CLI
عندما تضغط في Clash على “System Proxy/بروكسي النظام”، فعادةً ما يغيّر WinINet، وليس بالضرورة WinHTTP.
حالتي: لماذا “المتجر أوفلاين، والمتصفح أونلاين”
إعدادي وقتها كان:
- WinINet =
127.0.0.1:7890(بروكسي محلي mihomo) - WinHTTP =
DIRECT - تشغيل Clash TUN
النتيجة:
- Chrome يستخدم WinINet، فيستفيد من البروكسي، لذلك يبدو “كل شيء طبيعي”
- Microsoft Store (UWP/AppContainer) يرمي خطأ شبكة
0x80072EFD(CannotConnect)
النقطة المحورية هنا:
تطبيقات UWP افتراضيًا لا تستطيع الوصول إلى عنوان الحلقة المحلية (loopback) على الجهاز (
127.0.0.1/localhost).
لذلك عندما يحاول المتجر الاتصال بمنفذ البروكسي المحلي لديك، قد يتم حظره مباشرة بواسطة قواعد العزل (sandbox). ليست المشكلة أنه لا يستطيع الوصول للإنترنت، بل أنه لا يستطيع أولًا الوصول إلى “مدخل البروكسي”.
لماذا حتى “متجر الصين يمكنه الاتصال مباشرة” قد يفشل؟
كثيرون سيقولون: storeedge.microsoft.com داخل الصين القارية يمكن الاتصال به مباشرة أصلًا. هذا صحيح، لكنه غير كامل.
لأن المسار هو:
تطبيق UWP -> بروكسي محلي(127.0.0.1:7890) -> توزيع حسب القواعد(DIRECT/PROXY) -> الموقع الهدف
إذا كانت القفزة الأولى (من UWP إلى الحلقة المحلية) محجوبة، فلن تتاح أصلًا فرصة حدوث “الاتصال المباشر المفترض”.
ما الذي أصلح المشكلة فعليًا هذه المرة
لم أوقف البروكسي العام، ولم أغيّر WinHTTP، ولم ألمس أي خدمة تعتمد على الإعدادات الحالية؛ فقط أجريت أقل تغيير ممكن:
checknetisolation loopbackexempt -a -n=microsoft.windowsstore_8wekyb3d8bbwe
checknetisolation loopbackexempt -a -n=microsoft.storepurchaseapp_8wekyb3d8bbwe
checknetisolation loopbackexempt -a -n=microsoft.xboxidentityprovider_8wekyb3d8bbwe
ثم أعدت فتح Store، فعاد للعمل.
هذا يُسمّى استثناء الحلقة المحلية لتطبيقات UWP (loopback exempt): إضافة اسم حزمة UWP محدد إلى قائمة بيضاء للسماح له بالوصول إلى localhost/127.0.0.1 على الجهاز.
لماذا يبدو بروكسي Windows “فوضويًا”
لأنه ليس طريقًا واحدًا، بل “عدة مسارات متوازية”:
- المتصفحات/بعض تطبيقات سطح المكتب: تقرأ WinINet
- خدمات النظام: تقرأ WinHTTP
- أدوات الطرفية: قد لا تعترف إلا بمتغيرات البيئة
- UWP: تتأثر أيضًا بسياسة أمان الحلقة المحلية الخاصة بـ AppContainer
- TUN: قد يستولي كذلك على جزء من الحركة على مستوى IP
أنت ترى “مفتاحًا واحدًا”، لكن داخل النظام فعليًا توجد “خمسة بوابات”.
مقارنة مع Linux / macOS
Linux
- لا يوجد “مفتاح بروكسي للنظام” موحّد يغطي كل التطبيقات
- الشائع: متغيرات env + إعدادات كل تطبيق على حدة
- البروكسي الشفاف غالبًا يعتمد على
tun + iptables/nftables + policy routing - الميزة: قابل للتحكم والبرمجة بالسكربتات؛ العيب: التجزئة واضحة
macOS
- لديه إعدادات بروكسي موحّدة نسبيًا ضمن خدمات الشبكة (System Settings)
- لكن أدوات CLI غالبًا ما تزال تنظر إلى متغيرات env
- لا توجد دلالات AppContainer loopback مثل UWP (نموذج العزل مختلف)
Windows
- تجربة GUI تبدو كأنها “مدخل موحّد”، لكن أكبر عبء تاريخي في الطبقات السفلية
- تعايش WinINet / WinHTTP / UWP / TUN يجعل ظهور “هذا يعمل وذاك أوفلاين” أمرًا شائعًا جدًا
ترتيب التشخيص الذي أستخدمه الآن غالبًا
- افحص WinINet: هل البروكسي مضبوط على
127.0.0.1:xxxx؟ - افحص WinHTTP:
netsh winhttp show proxy - افحص هل منفذ البروكسي يستمع فعليًا (
Get-NetTCPConnection) - افحص استثناء الحلقة المحلية لـ UWP (
checknetisolation loopbackexempt -s) - افحص رمز الخطأ في سجلات التطبيق (مثل
0x80072EFDفي المتجر) - بعدها قرر: هل المشكلة بروكسي، أم DNS، أم الموقع الهدف
كلمة تذمر أخيرة
مشكلة بروكسي Windows ليست “أنك ضبطته خطأ”، بل “أنك ضبطت طبقة واحدة فقط بشكل صحيح”.
عندما تلاحظ: المتصفح يعمل تمامًا، لكن المتجر يصرخ أنه لا توجد شبكة، لا تشكك في نفسك أولًا؛ اشكك أولًا في أنهم أصلًا لا يسلكون الطريق نفسه. 