الوكيل المؤسسي وتطبيقات ويندوز — ترتيب حلّ الوكيل في WinINET وWinHTTP و.NET

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

في معظم الحالات السبب ليس انقطاع خادم الوكيل ولا خطأ التطبيق. ويندوز فيه عدّة عائلات منفصلة ممّا يسمّيه الناس «إعدادات الوكيل»، وأيّ إعدادات من يقرأ يختلف حسب التطبيق (حسب كومة HTTP التي يستخدمها) وحسب حساب التشغيل — ذلك التباين. الإعدادات التي يقرأها المتصفّح، والتي تقرأها خدمة، والتي يقرأها HttpClient لـ .NET يمكن أن تكون كلّ منها شيئاً مختلفاً. متى صارت هذه البنية في الرأس، عزل «يعمل في المتصفّح، لكن…» يصير سريعاً على نحو مفاجئ.

يستهدف المقال موظّفي تقنيّة المعلومات في الشركات الصغيرة والمتوسّطة ومطوّري تطبيقات ويندوز. يربط في صورة واحدة عائلات إعدادات الوكيل الثلاث — WinINET وWinHTTP ومتغيّرات البيئة — والتكوين التلقائي بـ PAC وWPAD، وفرق حلّ الوكيل بين .NET Framework و.NET (Core وما بعده)، والوكلاء المصادقين (407)، وتفتيش TLS، وإجراء العزل العملي. أنماط إنشاء HttpClient وتصميم المهلة نفسها تُعالَج في «لا تُحِط HttpClient بـ using»، لذلك يركّز هذا المقال على حلّ الوكيل.

1. الخلاصة أوّلاً

• إعدادات وكيل ويندوز ليست شيئاً واحداً؛ ثمّة ثلاث عائلات على الأقلّ. (1) إعدادات WinINET لكلّ مستخدم (صفحة «الوكيل» في تطبيق الإعدادات = خيارات الإنترنت القديمة)، (2) إعدادات آلة WinHTTP (netsh winhttp)، و(3) متغيّرا البيئة HTTP_PROXY / HTTPS_PROXY. أيّها يُقرأ يُقرَّر في جانب التطبيق.¹²
• «الوكيل» الذي ترونه في تطبيق الإعدادات هو إعدادات WinINET لكلّ مستخدم. المتصفّحات والتطبيقات التفاعليّة تقرأها؛ خدمات ويندوز لا تقرأها. WinINET غير مدعوم للاستخدام في خدمة؛ استخدام الخدمة عمل WinHTTP.¹³
• السبب الأكثر شيوعاً لـ «يعمل يدوياً ولا يعمل كخدمة» هو فرق حساب التشغيل. LocalSystem وحساب الخدمة لا يريان الوكيل لكلّ مستخدم الذي ضبطه مسؤول على شاشته.³⁴
• netsh winhttp set proxy إعداد ثابت؛ لا يعالج PAC ولا الكشف التلقائي ولا مصادقة الوكيل. إن أردتم ضبط PAC أو WPAD لكلّ آلة، تحتاجون جانب netsh winhttp set advproxy.⁴²
• نتائج PAC تتغيّر لكلّ عنوان URL. دالّة FindProxyForURL في ملفّ PAC تأخذ عنواناً ومضيفاً وتعيد قائمة وكلاء أو اتّصالاً مباشراً (DIRECT). «ذلك الموقع يعمل، وهذه الواجهة وحدها لا» قد يكون فرعاً في PAC.⁵⁶
• HttpClient على .NET (Core وما بعده) يهيّئ الوكيل الافتراضي بترتيب متغيّرات البيئة → إعدادات وكيل مستخدم ويندوز. إن عُرِّف أيّ من HTTP_PROXY أو HTTPS_PROXY أو ALL_PROXY، يتقدّم على إعدادات نظام التشغيل، فيحدث حادث «ترك أحدهم متغيّر بيئة».⁷
• افتراضي .NET Framework هو خيارات الإنترنت لحساب التشغيل، ويمكن تجاوزه بـ defaultProxy في app.config. إعدادات ملفّ التكوين تتقدّم على إعدادات النظام.⁸⁹
• 407 خطأ مصادقة وكيل؛ وهو شيء مختلف عن 401 (مصادقة الخادم). المخطّطات تشمل Negotiate وNTLM وBasic، وفي .NET تمرّرون الاعتمادات بـ DefaultProxyCredentials أو WebProxy.UseDefaultCredentials. راقبوا أنّ محتوى «الاعتمادات الافتراضيّة» يتغيّر تحت حساب خدمة.¹⁰¹¹¹²
• وكيل تفتيش TLS لا يستقيم إلا كمجموعة مع توزيع شهادة مرجع التصديق الداخليّة. الآلات وأوقات التشغيل التي لم تستلمها تحصل على خطأ تحقّق من الشهادة. حلّوه بالتوزيع إلى مخزن الشهادات، لا بتعطيل التحقّق في التطبيق.¹³⁴

في جملة واحدة: كلّما قلتم «فحصت إعدادات الوكيل»، كونوا قادرين دائماً على قول أيّ العائلات الثلاث فحصتم، ومن أيّ حساب — ذلك موضوع هذا المقال.

2. في ويندوز ثلاث عائلات من «إعدادات الوكيل»

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

(1) هو ما يتعرّف عليه الناس عموماً بوصفه «إعدادات وكيل ويندوز»؛ الجوهر هو تكوين WinINET. تاريخيّاً هو خيارات إنترنت Internet Explorer، ويُخزَّن افتراضيّاً لكلّ مستخدم.⁴

(2) هو الافتراضي لكلّ آلة لسياقات مثل خدمة حيث «لا مستخدم مسجّل الدخول». (3) هو أساساً اصطلاح أدوات جاءت من عالم عبر المنصّات؛ على ويندوز يقرأه أيضاً .NET (Core وما بعده) وcurl وما شابه.⁷

النقطة المهمّة أنّ أيّ عائلة تُقرأ يُقرَّر في جانب التطبيق، لا في جانب الإعدادات. إن استخدم التطبيق WinINET داخليّاً قرأ (1)؛ وإن WinHTTP فـ (2) (أو تجاوزاً خاصّاً بالتطبيق)؛ وإن .NET (Core وما بعده) فـ (3) ثمّ (1). إذن عادةً ليست «إعدادات الوكيل صحيحة لكنّه لا يتّصل»؛ الواقع أنّ «العائلة التي كان التطبيق يقرأها كانت عائلة مختلفة عن التي فحصتموها».

flowchart TB
    accTitle: ثلاث عائلات لإعدادات وكيل ويندوز
    accDescr: WinINET إعدادات لكلّ مستخدم وخيارات إنترنت، وWinHTTP افتراضي الآلة عبر netsh، ومتغيّرات البيئة نطاق عمليّة. أيّ عائلة تُقرأ يقرّره التطبيق لا جانب الإعدادات
    fam{"أيّ عائلة؟"}
    fam --> wininet["إعدادات WinINET لكلّ مستخدم"]
    fam --> winhttp["إعدادات آلة WinHTTP"]
    fam --> env["HTTP_PROXY وأشباهه"]
    wininet -.-> r1["المتصفّحات وتطبيقات سطح المكتب"]
    winhttp -.-> r2["الخدمات وأجزاء من النظام"]
    env -.-> r3[".NET Core+ وcurl"]

الشكل 1: ثلاث عائلات جنباً إلى جنب. التطبيق يختار أيّها يقرأ.

إن فعّلتم نهج المجموعة «اجعل إعدادات الوكيل لكلّ آلة (لا لكلّ مستخدم)»، يمكن تحويل (1) إلى لكلّ آلة وتطبيق الإعدادات نفسها على كلّ مستخدم. مع MDM (Intune وما شابه) يمكن ضبطه لكلّ جهاز بـ NetworkProxy CSP.⁴

3. WinINET وWinHTTP — للتطبيقات التفاعليّة وللخدمات

3.1. فرق الأدوار

WinINET وWinHTTP كلاهما كومة عميل HTTP مضمّنة في ويندوز، لكنّهما يفترضان استخدامات مختلفة.

• WinINET: موجَّه إلى تطبيقات سطح المكتب التفاعليّة. يرث تلقائيّاً خيارات إنترنت المستخدم (الوكيل وملفات الارتباط وذاكرة الاعتمادات) ويمكنه حتّى إظهار واجهة إدخال اعتمادات إن لزم. الاستخدام في خدمة أو عمليّة شبيهة بالخدمة غير مدعوم.¹
• WinHTTP: موجَّه إلى الخدمات وجانب الخادم. يدعم التشغيل تحت حساب خدمة وانتحال هويّة الخيط وعزل الجلسة؛ مقابل ذلك لا يشارك إعدادات متصفّح المستخدم ولا ملفات الارتباط ولا الاعتمادات. ولا يظهر واجهة أيضاً.³

توجيه مايكروسوفت نفسه واضح بالقدر نفسه: «استخدموا WinINET ما لم تشغّلوا داخل خدمة، أو في عمليّة شبيهة بالخدمة تحتاج عزل الجلسة وانتحال الهويّة» — بالمقلوب، إن كانت خدمة فاستخدموا WinHTTP.¹

flowchart TB
    accTitle: WinINET للتطبيقات التفاعليّة وWinHTTP للخدمات
    accDescr: WinINET يرث خيارات إنترنت المستخدم المسجّل ولا يُدعم في خدمة. WinHTTP يعمل تحت حساب خدمة بلا واجهة ولا يشارك إعدادات متصفّح المستخدم
    q{"تطبيق سطح مكتب تفاعلي؟"}
    q -->|"نعم"| ie["WinINET"]
    q -->|"خدمة أو شبيه بها"| wh["WinHTTP"]
    ie -.-> ieNote["يقرأ خيارات إنترنت المستخدم"]
    wh -.-> whNote["إعدادات الآلة، بلا واجهة"]

الشكل 2: التطبيقات التفاعليّة تستخدم WinINET. الخدمة تستخدم WinHTTP.

3.2. عمليّات netsh winhttp الأساسيّة

وكيل WinHTTP الافتراضي للآلة يُشغَّل بـ netsh.²

:: Display the current WinHTTP proxy settings
netsh winhttp show proxy

:: Set a static proxy (with a bypass list)
netsh winhttp set proxy proxy-server="proxy.example.co.jp:8080" bypass-list="*.example.co.jp;<local>"

:: Import the Internet Options (WinINET) settings
netsh winhttp import proxy source=ie

:: Return to the default (DIRECT)
netsh winhttp reset proxy

قيدان جديران بالتذكّر هنا.

1. netsh winhttp set proxy إعداد ثابت. لا يعالج الكشف التلقائي للوكيل، ولا تحديد عنوان PAC، ولا مصادقة الوكيل.⁴
2. import proxy source=ie ينسخ الإعدادات الثابتة في تلك اللحظة فقط؛ ولا يتبع التغييرات اللاحقة في جانب خيارات الإنترنت. عندما تحتاجون تكويناً لكلّ آلة يشمل PAC أو الكشف التلقائي، اضبطوا الإعدادات التفصيليّة بصيغة JSON (Proxy وProxyBypass وAutoconfigUrl وAutoDetect) بـ netsh winhttp set advproxy.²

3.3. المطَبّ الأكثر شيوعاً: الخدمة لا تقرأ إعدادات IE للمستخدم

النمط الذي ترونه أكثر في الميدان، بترتيب الزمن، يبدو هكذا.

1. مطوّر يشغّل الأداة على حاسوبه → إعدادات الوكيل لكلّ مستخدم (1) تسري فيعمل
2. في الإنتاج يُترَك مقيماً كخدمة ويندوز (كيفيّة إنشاء خدمات Windows وتشغيلها) تحت LocalSystem
3. الإعدادات المرئيّة من LocalSystem شيء آخر (إعدادات كلّ مستخدم غير مرئيّة، وإعدادات آلة WinHTTP غير مضبوطة = DIRECT) → يحاول اتّصالاً مباشراً بواجهة البرمجة الخارجيّة وتنتهي المهلة

ليست «لا يعمل مع أنّها الآلة نفسها»؛ حتّى على الآلة نفسها، حساب تشغيل مختلف يعني مجموعة مختلفة من إعدادات الوكيل المرئيّة. لعمليّة تتواصل حتّى عندما لا يكون مستخدم مسجّل الدخول، النهج الصحيح إعداد إعدادات لكلّ آلة بالشكل الذي تقرأه كومة HTTP لتلك العمليّة فعلاً. لتطبيق أصلي أو مكوّن ويندوز يستخدم WinHTTP، تسري إعدادات WinHTTP في netsh.⁴ أمّا HttpClient على .NET (Core وما بعده) فلا يقرأ إعدادات آلة WinHTTP (انظر الفصل 5)، لذلك لخدمة .NET تضبطون متغيّر بيئة نظام (HTTPS_PROXY وما شابه) أو تحدّدون HttpClientHandler.Proxy صراحة من إعدادات التطبيق.

الحادث يقع أيضاً في الاتجاه الآخر. إن خبزتم وكيلاً ثابتاً في حاسوب محمول يتنقّل بين الشبكة المؤسسيّة والخارج بـ netsh winhttp set proxy، ذلك الوكيل غير قابل للوصول خارج الشركة وتموت الاتصالات تماماً. عاملوا إعداداً ثابتاً للآلة كوسيلة موجَّهة إلى خوادم لا تتغيّر تكوين شبكتها.⁴

flowchart TB
    accTitle: لماذا لا ترى الخدمة إعدادات IE للمستخدم
    accDescr: تشغيل المطوّر يقرأ إعدادات WinINET لكلّ مستخدم ويعمل. كـ LocalSystem تلك الإعدادات غير مرئيّة. تطبيق WinHTTP أصلي يتبع عندئذٍ إعدادات آلة غير مضبوطة (DIRECT). خدمة .NET Core+ ما زالت تستخدم متغيّرات البيئة أو handler.Proxy صريحاً ولا تنتقل إلى netsh winhttp
    dev["تشغيل يدوي كالمستخدم"] --> ok["تسري إعدادات WinINET لكلّ مستخدم"]
    svc["خدمة ويندوز كـ LocalSystem"] --> miss["إعدادات كلّ مستخدم غير مرئيّة"]
    miss --> stack{"أيّ كومة HTTP؟"}
    stack -->|"WinHTTP"| direct["WinHTTP غير مضبوط = DIRECT"]
    stack -->|".NET Core+"| env["متغيّرات بيئة أو handler.Proxy"]
    direct --> fail["واجهة البرمجة الخارجيّة تنتهي مهلتها"]

الشكل 3: الآلة نفسها، حساب مختلف، مجموعة مختلفة من إعدادات الوكيل المرئيّة.

4. PAC وWPAD — ما هو «التكوين التلقائي» فعلاً

4.1. ملفّات PAC وFindProxyForURL

ملفّ PAC (Proxy Auto-Configuration) جافاسكربت (ECMAScript) يحسب «أيّ وكيل يُستخدم لهذا العنوان»، ويحتوي دائماً دالّة اسمها FindProxyForURL(url, host). تعيد الدالّة قائمة وكلاء ينبغي استخدامها، أو قيمة عودة خاصّة (DIRECT) تعني أنّ الاتّصال مباشرة بلا وكيل جائز.⁵

function FindProxyForURL(url, host) {
    // Internal domains and private addresses go direct
    if (dnsDomainIs(host, ".example.co.jp") ||
        isInNet(host, "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
    // Everything else goes through a proxy. Fall back to the next if the first is unavailable
    return "PROXY proxy1.example.co.jp:8080; PROXY proxy2.example.co.jp:8080; DIRECT";
}

نتيجتان عمليّتان تتبعان.

• حلّ الوكيل يجب أن يكون لكلّ عنوان URL. لأنّ PAC يمكن أن يعيد وكيلاً مختلفاً أو اتّصالاً مباشراً حسب العنوان (المضيف)، فإنّ ميزة الوكيل التلقائي في WinHTTP مصمَّمة أيضاً لتمرير عنوان الطلب والاستعلام في كلّ مرّة.⁶ «المتصفّح يرى موقعاً آخر» ليس دليلاً على أنّ الواجهة المشكلة تسلك المسار نفسه.
• DIRECT تعليمات «امضِ بلا وكيل». إن لم تظهر حركة ينبغي أن تكون داخليّة في سجلّ الوكيل قطّ، اشكّوا أوّلاً في أنّ PAC أعاد DIRECT (أو طابق قائمة تجاوز).

4.2. الكشف التلقائي عبر WPAD

فعّلوا «اكتشف الإعدادات تلقائيّاً» فتبحث الآلة عن موضع ملفّ PAC ببروتوكول WPAD (Web Proxy Auto-Discovery). في تكوين نموذجي يسلّم DHCP عنوان PAC، أو يُستخدم DNS للبحث عن مضيف اسمه wpad ويُنزَّل PAC من عنوان مثل http://wpad/wpad.dat.¹⁴

بعبارة أخرى، «الكشف التلقائي» ليس سحراً؛ إنّه آليّة تعمل فقط على شبكة سبق أن أقامت ترتيباً لـ WPAD في DHCP/DNS. تفعيل الكشف التلقائي وحده على شبكة بلا مثل هذا الترتيب لا يضيف إلا وقت انتظار لفشل الكشف.

flowchart TB
    accTitle: PAC يحلّ وكيلاً لكلّ عنوان وWPAD يجد PAC فقط
    accDescr: FindProxyForURL يأخذ عنواناً ومضيفاً ويعيد قائمة وكلاء أو DIRECT. WPAD يحدّد موضع PAC فقط عبر DHCP أو DNS. عميل لا يستطيع تقييم PAC يسقط إلى وكيل ثابت أو متغيّرات بيئة
    url["عنوان الطلب"] --> pac["FindProxyForURL"]
    pac -->|"قائمة وكلاء"| via["المرور عبر وكيل"]
    pac -->|"DIRECT"| dir["الاتّصال بلا وكيل"]
    wpad["WPAD عبر DHCP أو DNS"] -.-> pac
    nopac["عميل لا يقيّم PAC"] -.-> fb["إعدادات ثابتة أو متغيّرات بيئة"]

الشكل 4: PAC يقرّر لكلّ عنوان. WPAD يجد ملفّ PAC فقط.

4.3. كيف يتصرّف العملاء الذين لا يستطيعون تقييم PAC

ليس كلّ عميل يستطيع تقييم PAC.

• الإعدادات الثابتة لـ netsh winhttp set proxy لا تقيّم PAC.⁴
• الأدوات التي تستخدم أسلوب متغيّر البيئة HTTP_PROXY تستطيع كقاعدة كتابة عنوان وكيل ثابت فقط (لا موضع لكتابة عنوان PAC).⁷
• لتطبيق أصلي يستخدم WinHTTP مباشرة، يعتمد الأمر على كيفيّة فتح الجلسة. تطبيق فُتح بـ WinHttpOpen على ويندوز 8.1 وما بعده محدّداً WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY يجعل WinHTTP يحلّ تلقائيّاً إعدادات وكيل النظام/المستخدم (بما فيها WPAD/PAC) لكلّ طلب.¹⁵ إن فُتح بالأقدم WINHTTP_ACCESS_TYPE_DEFAULT_PROXY (مهمل من 8.1 فصاعداً) أو ما شابه، لا يندمج الوكيل التلقائي في كومة HTTP، وعلى التطبيق أن يستدعي بنفسه WinHttpGetProxyForUrl ويطبّق النتيجة على الطلب. بعبارة أخرى، على تنفيذ أقدم، يمكن أن يكون PAC موجوداً ويبقى غير مستخدم.⁵

«المتصفّح يذهب إلى الوكيل الصحيح عبر PAC، والتطبيق التجاري لا يقرأ PAC ويحاول اتّصالاً مباشراً ويفشل» — هذا تباين أساسي آخر. على شبكة تُشغَّل بـ PAC تحتاجون إلى تقرير سقوط — إعدادات ثابتة أو متغيّرات بيئة — للعملاء الذين لا يستطيعون قراءة PAC.

5. حلّ وكيل .NET — Framework وCore وما بعده شيئان مختلفان

أيّ إعدادات وكيل يقرأها تطبيق .NET يختلف افتراضيّاً بين .NET Framework و.NET (Core وما بعده). اخلطوا الاثنين فتحقّقون في تطبيق .NET 8 بمعرفة عصر Framework وتفوّتون.

5.1. .NET Framework — الافتراضي خيارات الإنترنت، يُتجاوز بـ defaultProxy

على .NET Framework يستخدم HttpWebRequest وHttpClient الجالس فوقه الوكيل الافتراضي ما لم تحدّدوا Proxy صراحة. يُقرَّر الوكيل الافتراضي بجمع إعدادات إنترنت النظام (إعدادات WinINET لحساب التشغيل) وملفّ التكوين، وإعدادات ملفّ التكوين لها الأولويّة.⁸

يمكن التحكم بهذا الافتراضي بعنصر system.net/defaultProxy في app.config (أو machine.config).⁹

<configuration>
  <system.net>
    <!-- useDefaultCredentials: whether to send default credentials to an authenticating proxy -->
    <defaultProxy enabled="true" useDefaultCredentials="true">
      <proxy usesystemdefault="true"
             proxyaddress="http://proxy.example.co.jp:8080"
             bypassonlocal="true" />
      <bypasslist>
        <add address="[a-z]+\.example\.co\.jp$" />
      </bypasslist>
    </defaultProxy>
  </system.net>
</configuration>

اتركوا عنصر defaultProxy فارغاً فتُستخدم إعدادات النظام (خيارات الإنترنت)؛ اكتبوا proxyaddress وما شابه فتلك تتقدّم. من البرنامج يمكن استبدال الافتراضي نفسه بـ WebRequest.DefaultWebProxy.⁹⁸

مطَبّ الفصل 3.3 ينطبق هنا أيضاً. لأنّ الافتراضي «خيارات إنترنت حساب التشغيل»، تطبيق .NET Framework يعمل تحت حساب خدمة يقرأ مجموعة إعدادات مختلفة (غالباً فارغة) عن تلك المرئيّة على سطح مكتب المسؤول.

5.2. .NET (Core وما بعده) — متغيّرات البيئة أوّلاً ثمّ إعدادات مستخدم نظام التشغيل

لدى HttpClient على .NET (Core وما بعده) خاصّيّة ثابتة HttpClient.DefaultProxy. ما لم يحدّد معالج وكيلاً صراحة، تستخدمه كلّ نسخة HttpClient. قاعدة التهيئة على ويندوز هي «اقرأ متغيّرات البيئة، وإن لم تُعرَّف فاقرأ إعدادات وكيل المستخدم».⁷

متغيّرات البيئة المستخدمة كالتالي.⁷

ثلاث أمور للمراقبة.

• إن عُرِّف أيّ من HTTP_PROXY أو HTTPS_PROXY أو ALL_PROXY، يتقدّم على إعدادات الوكيل في جانب نظام التشغيل. تعريف NO_PROXY وحده لا يكوّن وكيلاً من متغيّرات البيئة، وعلى ويندوز تستمرّ إعدادات وكيل مستخدم نظام التشغيل. «إعدادات غير مرئيّة» مثل ترك HTTPS_PROXY متغيّر بيئة نظام بعد تجربة قديمة، أو قالب CI/CD يحقنه، مرتع للحوادث.
• NO_PROXY لا يدعم أحرف البدل (*) لمطابقة نطاق فرعي ضع نقطة بادئة (.example.com تطابق www.example.com لا example.com نفسه).⁷
• خارج ويندوز (حاويات لينكس وما شابه)، إن كانت متغيّرات البيئة غير معرَّفة تُهيَّأ بلا وكيل. تغيّر السلوك الافتراضي للتطبيق نفسه بين ويندوز ولينكس أمر يؤكَّد عند ترحيل الحاوية.⁷

5.3. التحديد الصريح — HttpClientHandler.Proxy وUseProxy

على أيّ وقت تشغيل، أعلى أولويّة تحديد صريح على المعالج. تحديد HttpClientHandler.Proxy يتقدّم على إعدادات نظام التشغيل وملفّ التكوين، وUseProxy = false لا يستخدم وكيلاً أصلاً.¹⁴

using System.Net;

// Use a proxy read from app settings explicitly
var handler = new HttpClientHandler
{
    Proxy = new WebProxy("http://proxy.example.co.jp:8080")
    {
        BypassProxyOnLocal = true,
        BypassList = new[] { @"^intra\.example\.co\.jp$" },
        UseDefaultCredentials = true // On an authenticating proxy, respond with the running account's credentials
    },
    UseProxy = true
};
var client = new HttpClient(handler);

// A client that never uses a proxy (for direct internal APIs)
var directHandler = new HttpClientHandler { UseProxy = false };
var directClient = new HttpClient(directHandler);

عندما لا يكون تحديد صريح وتُتَّبع إعدادات نظام التشغيل، لتجاوز الوجهات المحلّيّة التلقائي قواعد. اسم مسطّح بلا نقطة، عنوان حلقة، وجهة تطابق لاحقة نطاق الآلة نفسها، وما شابه يمكن معاملتها «محلّيّة».¹⁴ ظواهر مثل «السلوك يتغيّر إن حدّدت عنوان IP» أو «بدأ فجأة يمرّ بالوكيل عندما استخدمت FQDN» يمكن أن يسبّبها هذا الحكم.

ترتيب الأولويّة كالتالي.

flowchart TB
    accTitle: حلّ الوكيل الافتراضي في Framework مقابل Core وما بعده
    accDescr: HttpClientHandler.Proxy الصريح يفوز دائماً. Framework يستخدم بعد ذلك app.config defaultProxy وخيارات إنترنت حساب التشغيل. Core وما بعده يستخدم إسناداً إلى HttpClient.DefaultProxy ثمّ متغيّرات البيئة ثمّ إعدادات وكيل مستخدم ويندوز
    expl["handler.Proxy صريح"] --> done["يُستخدم ذلك الوكيل"]
    noexpl["لا Proxy صريح"] --> fw{"أيّ وقت تشغيل؟"}
    fw -->|"Framework"| cfg["app.config defaultProxy"]
    cfg --> ie["خيارات إنترنت حساب التشغيل"]
    fw -->|"Core وما بعده"| dp["HttpClient.DefaultProxy"]
    dp --> ev["HTTP_PROXY وأشباهه"]
    ev --> user["إعدادات وكيل مستخدم ويندوز"]

الشكل 5: التحديد الصريح يفوز دائماً. المسار الافتراضي يختلف حسب وقت التشغيل.

6. الوكلاء المصادقون — 407 خطأ مصادقة الوكيل

6.1. لا تخلطوا 407 بـ 401

عندما تحاولون المرور عبر وكيل يطلب مصادقة، يعيد الوكيل رمز الحالة 407 (Proxy Authentication Required) وترويسة Proxy-Authenticate تسرد المخطّطات المتاحة. ذلك شيء مختلف عن طلب مصادقة خادم الوجهة (401 وWWW-Authenticate)؛ الطرف الذي تسلّمون إليه الاعتمادات وموضع ضبطها كلاهما مختلف.¹⁰

flowchart TB
    accTitle: 407 هو الوكيل و401 خادم الوجهة
    accDescr: 407 وProxy-Authenticate يأتيان من الوكيل. 401 وWWW-Authenticate يأتيان من خادم الوجهة. الاعتمادات وموضع ضبطها يختلفان
    req["طلب صادر"] --> who{"من يطلب المصادقة؟"}
    who -->|"الوكيل"| e407["407 + Proxy-Authenticate"]
    who -->|"الوجهة"| e401["401 + WWW-Authenticate"]
    e407 -.-> cred["DefaultProxyCredentials"]

الشكل 6: 407 مصادقة وكيل. 401 مصادقة خادم.

المخطّطات تشمل Basic الذي يرسل اسم المستخدم وكلمة المرور كما هما، ومخطّطات تحدٍّ/استجابة مثل Negotiate (Kerberos/NTLM). في مخطّط تحدٍّ/استجابة لا تسير كلمة المرور نفسها على الشبكة، وتكتمل المصادقة على عدّة تبادلات.¹⁰ آليّة المخطّط الذي «يسقط» إليه تُعالَج بتفصيل أكبر في «شرح NTLM وKerberos بالمخطّطات».

6.2. كيف تمرّرون الاعتمادات في .NET

عندما تريدون استخدام الوكيل الافتراضي الآتي من إعدادات نظام التشغيل وإمرار المصادقة فقط، استخدموا HttpClientHandler.DefaultProxyCredentials. هذه الاعتمادات المُرسَلة إلى ذلك الوكيل الافتراضي عندما UseProxy = true وProxy = null (= وكيل النظام الافتراضي).¹¹

using System.Net;

var handler = new HttpClientHandler
{
    UseProxy = true,   // The default. Combined with a null Proxy, this uses the system-default proxy
    Proxy = null,
    // Respond to 407 with the credentials of the running account (signed-in user or service account)
    DefaultProxyCredentials = CredentialCache.DefaultCredentials
};
var client = new HttpClient(handler);

عندما تحدّدون الوكيل صراحة، ضعوا الاعتمادات في جانب WebProxy. في كثير من سيناريوهات العميل التوصية استخدام الاعتمادات الافتراضيّة للمستخدم المسجّل لا اسماً وكلمة مرور فرديّين، وWebProxy.UseDefaultCredentials = true هو ذلك.¹²

6.3. مشكلة 407 لحساب الخدمة

حساب التشغيل يهمّ هنا أيضاً. «الاعتمادات الافتراضيّة» تعني اعتمادات الحساب الذي يشغّل تلك العمليّة. شغّلوه كمستخدم تفاعلي فالمصادقة لدى الوكيل بذلك المستخدم؛ شغّلوه كخدمة LocalSystem فهي بحساب الحاسوب.

• إن كان الوكيل يصادق المستخدمين عبر Active Directory، لا يستطيع مصادقة حساب حاسوب أو حساب محلّي، ويستمرّ 407 فور تحويل التطبيق إلى خدمة
• بالمقابل، لبعض البيئات إعفاء مصادقة في جانب الوكيل للخدمات (حسب عنوان المصدر أو حسب الحساب)

إذن تحقيق 407 لا يُغلق على «إعدادات التطبيق» وحدها؛ هو مجموعة مع فحص تصميم في جانب البنية: هل يستطيع الوكيل مصادقة حساب التشغيل. لتطبيق ستحوّلونه إلى خدمة، ينبغي أن تقرّروا عند التصميم واحداً من: تشغيله تحت حساب خدمة نطاق (gMSA وما شابه)، وضع إعفاء مصادقة في جانب الوكيل، أو إقامة وكيل ترحيل داخلي لا يطلب مصادقة.

ثمّة أيضاً أسلوب يضمّن الاعتمادات في متغيّر بيئة، مثل HTTP_PROXY=http://user:pass@proxy:8080⁷، لكن كلمة مرور نصّاً واضحاً تُكشَف عندئذٍ في متغيّر بيئة (= معلومات عمليّة)، لذلك لا يُوصى به للتشغيل الدائم.

7. HTTPS والوكلاء — أنفاق CONNECT وتفتيش TLS

7.1. HTTPS يمرّ عبر وكيل كـ «نفق»

عندما تستخدمون وكيلاً لـ HTTPS، يرسل العميل أوّلاً إلى الوكيل طلباً CONNECT destination-host:443، ويفتح الوكيل نفقاً TCP. عند النجاح يعيد الوكيل 200، وبعد ذلك ينفّذ العميل وخادم الوجهة مصافحة TLS داخل ذلك النفق. إن لم يُفتح النفق، يعيد الوكيل 407 (مطلوبة المصادقة) أو 502 أو ما شابه.¹⁶

في هذا النموذج لا يستطيع الوكيل قراءة محتويات النفق (HTTPS المشفَّر). ما يبقى في سجلّ الوكيل اسم مضيف الوجهة ونجاح الاتّصال؛ مسار العنوان غير مرئي — ذلك سلوك وكيل «العبور».

flowchart TB
    accTitle: HTTPS عبر وكيل نفق CONNECT
    accDescr: العميل يرسل CONNECT إلى الوكيل، والوكيل يفتح نفقاً TCP ويعيد 200، ثمّ ينفّذ العميل والوجهة مصافحة TLS داخل النفق. سجلّ الوكيل يرى المضيف لا مسار العنوان
    cli["العميل"] -->|"CONNECT host:443"| px["الوكيل"]
    px -->|"200 ونفق TCP"| dest["الوجهة"]
    dest -->|"TLS داخل النفق"| cli
    px -.-> log["السجلّ: المضيف والنجاح فقط"]

الشكل 7: وكيل العبور يرى المضيف، لا المسار المشفَّر.

7.2. وكلاء تفتيش TLS وأخطاء الشهادة

وكلاء منتجات الأمن من الجهة الأخرى تشمل نوعاً لتفتيش TLS (فكّ تشفير SSL، القطع والتفتيش) ينهي TLS ويفتّش المحتويات ويعيد التشفير قبل التمرير. في هذا المخطّط شهادة الخادم المقدَّمة للعميل ليست الحقيقيّة؛ تُستبدَل بشهادة أعاد توقيعها مرجع التصديق الخاصّ بالوكيل.¹³

المقدّمة التي تجعل هذا التكوين يستقيم إذن هي «شهادة مرجع تصديق الوكيل وُزِّعت إلى الجذور الموثوقة لكلّ عميل». على آلة لم تستلمها، أو في وقت تشغيل لا ينظر إلى مخزن شهادات ويندوز (أدوات لها مخزن ثقة خاصّ)، تحصلون على خطأ تحقّق من الشهادة. في .NET يظهر عادةً كـ HttpRequestException يغلّف AuthenticationException (رسالة من نوع «the remote certificate is invalid»).

مبادئ التصحيح كالتالي.

• وزّعوا شهادة مرجع التصديق الداخليّة إلى مخزن «مراجع التصديق الجذريّة الموثوقة» للحاسوب المحلّي. انقسام مخزن المستخدم ومخزن الحاسوب يُعالَج في «مخزن شهادات ويندوز عمليّاً».
• لا تعطّلوا التحقّق من الشهادات في الشيفرة. حلّ ملتفّ يعيد دائماً true من ServerCertificateCustomValidationCallback يصبح تطبيقاً هشّاً لا يكتشف رجلاً في الوسط لحظة خروجه إلى شبكة خارجيّة.
• حركة تثبيت الشهادة لا يمكن تفتيشها أصلاً. الاتّصالات التي تتحقّق من شهادة مايكروسوفت معيّنة، كما تفعل بعض مكوّنات ويندوز، تفشل لحظة مبادلة الوكيل الشهادة، ولا حلّ سوى الاستثناء.⁴ للحركة المتّجهة إلى خدمات مثل Microsoft 365 توصي مايكروسوفت نفسها باستثنائها من فكّ التشفير والتفتيش على طبقة الشبكة.¹³

عَرَض «كلّ موقع داخلي مرئي، وخدمة سحابة معيّنة وحدها تُنتج خطأ شهادة في التطبيق» ينبغي أن يجعلكم تشكّون أوّلاً في جمع قائمة استثناء تفتيش TLS والتثبيت.

flowchart TB
    accTitle: وكيل تفتيش TLS يعيد توقيع الشهادة
    accDescr: الوكيل ينهي TLS ويفتّش المحتويات ويقدّم شهادة أعاد توقيعها مرجع تصديقه. التحقّق يستقيم فقط إن كان ذلك المرجع في الجذور الموثوقة. لا تعطّلوا التحقّق في الشيفرة
    real["شهادة الخادم الحقيقيّة"] --> px["وكيل تفتيش TLS"]
    px --> fake["أعاد توقيعها مرجع تصديق الوكيل"]
    fake --> client["تحقّق العميل"]
    client -->|"المرجع في الجذور"| ok["نجاح"]
    client -->|"المرجع غائب"| err["خطأ شهادة"]
    err -.-> fix["توزيع المرجع إلى المخزن"]

الشكل 8: التفتيش يعمل فقط كمجموعة مع توزيع مرجع التصديق الداخلي.

8. إجراء العزل — خمس خطوات لتحديد الجاني

حقّقوا في «لا يتّصل» آليّاً بهذا الترتيب.

يمكن جمع (2) دفعة واحدة بـ PowerShell.

# (1) Per-user (WinINET) settings — note that this reads HKCU of the running account
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# (2) Machine (WinHTTP) settings
netsh winhttp show proxy

# (3) Environment variables
Get-ChildItem env: | Where-Object Name -match 'proxy'

نصائح عمليّة قليلة.

• في اختبار الإعادة في (1)، كونوا واعين لأيّ عائلة إعدادات تقرأها الأداة. curl.exe المضمَّن في ويندوز يمكنه تحديد وكيل صراحة بـ -x http://proxy:8080، وللتحقّق من TLS يستخدم عادةً مخزن شهادات نظام التشغيل (Schannel). Invoke-WebRequest في Windows PowerShell 5.1 يتبع جانب .NET Framework (خيارات الإنترنت افتراضيّاً)؛ PowerShell 7 يتبع جانب .NET (متغيّرات البيئة أوّلاً). «curl يعمل والتطبيق لا» نفسه تلميح إلى تباين بين عائلات التكوين.
• إن كانت الوجهة في (3) خدمة، أعيدوا فحص (1) و(2) تحت الحساب نفسه للخدمة. فحص في جلسة المسؤول نفسه ليس دليلاً على ما يراه LocalSystem.
• في تصنيف الخطأ في (4)، خذوا الفصل 6 (المصادقة) أوّل مرشّح لـ 407، والفصل 7 (تفتيش TLS) لخطأ شهادة، و«لا يبلغ الوكيل» (المسار، حلّ الاسم، الجدار الناري) لانتهاء المهلة. النمط الذي فيه السبب قاعدة واردة لجدار ويندوز الناري لا الوكيل يُعالَج في «جدار ويندوز الناري والتطبيقات التجاريّة».
• إن وصلتم إلى (5) وما زال لا أثر في سجلّ الوكيل، فالحركة لم تبلغ الوكيل قطّ. اشكّوا في قرار DIRECT لـ PAC أو قائمة تجاوز أو متغيّر بيئة متروك، وإن لزم أكّدوا الوجهة الفعليّة بالتقاط حزم («التقاط الحزم على ويندوز عمليّاً — الاختيار بين pktmon وnetsh trace وWireshark»).

flowchart TB
    accTitle: خمس خطوات لعزل عطل وكيل
    accDescr: أعيدوا تحت الحساب نفسه، اجمعوا عائلات الإعدادات الثلاث، حدّدوا حساب التشغيل، صنّفوا الخطأ، ثمّ افحصوا سجلّ الوكيل
    s1["إعادة بـ curl"] --> s2["جمع ثلاث عائلات"]
    s2 --> s3["تحديد الحساب"]
    s3 --> s4["تصنيف الخطأ"]
    s4 --> s5["فحص سجلّ الوكيل"]
    s4 -.-> e407["407: مصادقة"]
    s4 -.-> ecert["خطأ شهادة: تفتيش"]
    s4 -.-> eto["انتهاء مهلة: لم يبلغ"]

الشكل 9: امشوا الخطوات الخمس بالترتيب. صنف الخطأ يختار الفصل التالي.

9. توصية تصميم — اجعلوا التطبيق ممّا يمكن «ضبط الوكيل عليه»

اقلبوا إجراء التحقيق فيصير دليلاً تصميميّاً في جانب التطبيق. لتطبيق ويندوز ستسلّمونه إلى بيئة فيها وكيل مؤسسي، يُوصى بما يلي.

1. اجعلوا الوكيل قابلاً للضبط من إعدادات التطبيق. الافتراضي «اتباع إعدادات نظام التشغيل». في معظم البيئات يكفي الافتراضي؛ فقط في البيئات الاستثنائيّة — لا يمكن قراءة PAC، يعمل كخدمة، تكوين وكيل خاصّ — تجعلون ممكناً تحديد عنوان وكيل وقائمة تجاوز و«لا تستخدم وكيلاً» من ملفّ إعدادات. HttpClientHandler.Proxy / UseProxy في القسم 5.3 نقطة التنفيذ.¹⁴
2. اكتبوا كيف تُعامَل الوجهات الداخليّة (واجهات البرمجة وقواعد البيانات وخوادم التراخيص وما شابه) كاستثناءات وكيل. ضعوا في شكل يمكن كتابته في إجراء النشر إن كانت تُستثنى بـ PAC DIRECT أو قائمة تجاوز أو NO_PROXY. قواعد مطابقة NO_PROXY (بلا أحرف بدل، معنى النقطة البادئة) يُساء فهمها على نطاق واسع، فألحقوا أمثلة.⁷
3. صمّموا المهلات وإعادة المحاولة بافتراض المرور عبر وكيل. إن سقط الوكيل أو علق على المصادقة، تنفيذ ينتظر مهلة افتراضيّة طويلة يجمد الواجهة والتشغيل معاً. افصلوا مهلة اتّصال أقصر، وحدّوا إعادة المحاولة بالطلبات متماثلة القدرة (تفاصيل التصميم في «لا تُحِط HttpClient بـ using»).
4. سجّلوا «أيّ وكيل استُخدم». اجعلوا التطبيق نفسه قادراً على إجابة السؤال الأوّل لتحقيق عطل.

سجلّ كالذي في (4) فعّال أصلاً إن سجّل نتيجة الحلّ فقط. النقطة اشتقاق المسار من الإعدادات (المعالج) التي استخدمتموها فعلاً لضبط العميل. إن سجّلتم HttpClient.DefaultProxy مباشرة، ستسجّلون قيمة تخالف المسار الفعلي عندما يحدّد المعالج Proxy صراحة أو يضع UseProxy = false.

using System.Net.Http;

// handler is the same instance used to create the HttpClient
// UseProxy=false is always direct. An explicit specification wins; otherwise DefaultProxy is used
var effectiveProxy = handler.UseProxy
    ? handler.Proxy ?? HttpClient.DefaultProxy
    : null;
var target = new Uri("https://api.example.com/v1/orders");
var route = effectiveProxy is null || effectiveProxy.IsBypassed(target)
    ? "DIRECT"
    : effectiveProxy.GetProxy(target)?.ToString() ?? "DIRECT";
logger.LogInformation("HTTP send {Target} route {Route} account {User}",
    target, route, Environment.UserName);

إن سجّلتم عند البدء مرّة «المسار» و«حساب التشغيل» للوجهات الرئيسيّة، تنتهي الخطوات من (1) إلى (3) في الفصل 8 بمجرّد قراءة السجلّ. عندما يقال لكم «يعمل في المتصفّح، لكن…»، القدرة على القول من جانب التطبيق «استخدمت هذا الإعداد، وهذا المسار» شرط تطبيق قويّ ضدّ متاعب الوكيل.

flowchart TB
    accTitle: اجعلوا الوكيل قابلاً للضبط وسجّلوا المسار
    accDescr: الافتراضي اتباع إعدادات نظام التشغيل، والسماح بعنوان وكيل صريح أو تجاوز أو بلا وكيل من إعدادات التطبيق، وتسجيل المسار المستخدم فعلاً مع حساب التشغيل
    def["الافتراضي: اتباع إعدادات النظام"] --> exc{"بيئة استثنائيّة؟"}
    exc -->|"PAC غير مقروء / خدمة / خاصّ"| cfg["ضبط عنوان أو تجاوز أو بلا وكيل"]
    exc -->|"الحالة المعتادة"| os["استخدام افتراضي النظام"]
    cfg --> log["تسجيل المسار والحساب"]
    os --> log

الشكل 10: اضبطوا عندما يجب. سجّلوا دائماً أيّ مسار استُخدم.

10. الخلاصة

• إعدادات وكيل ويندوز تنقسم إلى ثلاث عائلات — إعدادات WinINET لكلّ مستخدم وإعدادات آلة WinHTTP ومتغيّرات البيئة — وأيّها يُقرأ يقرّره التطبيق (كومته HTTP) وحساب التشغيل.
• WinINET للتطبيقات التفاعليّة وغير مدعوم للاستخدام في خدمة؛ استخدام الخدمة عمل WinHTTP (netsh winhttp). لـ «يعمل يدوياً ولا يعمل كخدمة» اشكّوا أوّلاً في فرق حساب التشغيل.
• netsh winhttp set proxy إعداد ثابت ولا يعالج PAC ولا الكشف التلقائي ولا المصادقة. على شبكة تُشغَّل بـ PAC تحتاجون إلى تقرير كيف يُعامَل العملاء الذين لا يستطيعون قراءة PAC.
• FindProxyForURL لـ PAC يعيد وكيلاً أو DIRECT لكلّ عنوان. WPAD يعمل فقط على شبكة فيها ترتيب DHCP/DNS.
• افتراضي .NET Framework خيارات إنترنت حساب التشغيل (قابل للتجاوز بـ defaultProxy)؛ .NET (Core وما بعده) متغيّرات البيئة ثمّ إعدادات وكيل المستخدم. التحديد الصريح (HttpClientHandler.Proxy) أعلى أولويّة دائماً.
• 407 خطأ مصادقة وكيل؛ في تطبيق يعمل تحت حساب خدمة السبب النموذجي أنّ «الاعتمادات الافتراضيّة» تصبح شخصاً آخر.
• وكيل تفتيش TLS يفترض توزيع شهادة مرجع التصديق الداخليّة، والإجابة الصحيحة لخطأ شهادة التوزيع إلى مخزن الشهادات لا تعطيل التحقّق. الحركة المثبَّتة تحتاج استثناءً.
• اعزلوا آليّاً بترتيب «إعادة → جمع عائلات الإعدادات الثلاث → تحديد حساب التشغيل → تصنيف الخطأ → سجلّ الوكيل». في جانب التطبيق، تصميم «يستطيع ضبط الوكيل ويسجّل المسار الذي استخدمه» أفضل وقاية.

في المرّة التالية التي تُستشارون فيها بـ «التطبيق التجاري وحده لا يتّصل»، اسألوا هذا أوّلاً.

تحت حساب من يعمل ذلك التطبيق، وأيّ عائلات إعدادات الوكيل الثلاث يقرأ؟

ذلك السؤال الواحد يغيّر مدخل التحقيق كثيراً.

مقالات ذات صلة

• لا تُحِط HttpClient بـ using ── الممارسة العمليّة للاتّصال عبر HTTP في تطبيقات C# للأعمال (أنماط الإنشاء، وضبط المهلة، وإعادة المحاولة)
• التقاط الحزم على ويندوز عمليّاً — الاختيار بين pktmon وnetsh trace وWireshark
• جدار ويندوز الناري والتطبيقات التجاريّة — سجّلوا القواعد الواردة من المثبّت
• كيفيّة إنشاء خدمات Windows وتشغيلها ── من التمييز عن جدولة المهام إلى تحويل BackgroundService إلى خدمة
• شرح NTLM وKerberos بالمخطّطات — لماذا تسقط المصادقة إلى NTLM
• مخزن شهادات ويندوز عمليّاً — المستخدم أم الحاسوب، أيّهما ينبغي أن تستخدموا؟

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تحقيق أعطال اتّصال تطبيقات ويندوز في بيئات الوكيل المؤسسي والوكيل المصادق وتفتيش TLS — «يعمل على آلة التطوير ولا يتواصل على شبكة العميل»، «بعد تحويله إلى خدمة لم يعد يبلغ واجهة البرمجة الخارجيّة» — والاستشارة حول تصميم اتّصال التطبيقات التجاريّة الذي يفترض بيئة وكيل (بنود الإعداد والمهلات وتصميم السجلّات). يجوز البدء من ترتيب خطوات الإعادة وكيفيّة جمع السجلّات.

• تطوير تطبيقات ويندوز
• التحقيق في الأخطاء وتحليل السبب الجذري
• الاستشارات التقنيّة ومراجعة التصميم
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

المتصفّح يتّصل، والتطبيق التجاري وحده لا يعبر الوكيل المؤسسي. لماذا؟

المتصفّح يقرأ إعدادات الوكيل لكلّ مستخدم في WinINET، لكن التطبيق التجاري لا يقرأ بالضرورة الإعدادات نفسها. تطبيق يعمل كخدمة ويندوز، أو تحت حساب آخر، يستشير الإعدادات المرئيّة من ذلك الحساب، أو إعدادات الآلة في WinHTTP، أو متغيّرات البيئة. حدّدوا أوّلاً حساب التشغيل، وافحصوا إعدادات الوكيل المرئيّة من ذلك الحساب بـ netsh winhttp show proxy وفي إعدادات المستخدم معاً. إن أمكنت الإعادة بـ curl.exe أو ما يشبهه تحت الحساب نفسه على الآلة نفسها، يمكن معاملتها كتباين بين عائلات الإعداد لا كمشكلة خاصّة بالتطبيق.

ضبطت netsh winhttp set proxy، لكن حركة التطبيق لم تتغيّر. لماذا؟

ما يضبطه netsh winhttp هو افتراضي آلة WinHTTP. لا يؤثّر في المتصفّحات ولا في التطبيقات التفاعليّة التي تقرأ WinINET، ولا في HttpClient لـ .NET (Core وما بعده) الذي يفضّل متغيّرات البيئة. netsh winhttp set proxy أيضاً إعداد ثابت؛ لا يعالج التكوين التلقائي بـ PAC ولا الكشف التلقائي ولا مصادقة الوكيل. تحتاجون أوّلاً إلى تأكيد أيّ كومة HTTP يستخدمها التطبيق المستهدف ومن أيّ عائلة إعداد يحلّ الوكيل.

أيّ إعدادات وكيل يقرأها تطبيق .NET؟

.NET Framework يستخدم افتراضيّاً خيارات الإنترنت (مكافئ WinINET) لحساب التشغيل، ويمكن تجاوزها بعنصر system.net/defaultProxy في app.config. HttpClient على .NET (Core وما بعده) يقرأ أوّلاً متغيّرات بيئة مثل HTTP_PROXY وHTTPS_PROXY وNO_PROXY، وإن لم تُعرَّف يسقط إلى إعدادات وكيل مستخدم ويندوز. في الحالتين يكون HttpClientHandler.Proxy الصريح أعلى أولويّة. ترتيب الحلّ الافتراضي يختلف إذن بين Framework وCore وما بعده، فينبغي إعادة فحص سلوك الوكيل عند الترحيل.

ماذا أفحص عندما يُرجَع 407 Proxy Authentication Required؟

407 علامة على أنّ الوكيل نفسه يطلب مصادقة؛ وهو شيء مختلف عن خطأ مصادقة خادم الوجهة (401). أكّدوا أوّلاً مخطّط المصادقة الذي يطلبه الوكيل (Negotiate أو NTLM أو Basic) من ترويسة Proxy-Authenticate، وفي .NET مرّروا الاعتمادات بـ HttpClientHandler.DefaultProxyCredentials أو WebProxy.UseDefaultCredentials. في تطبيق يعمل تحت حساب خدمة تصبح «الاعتمادات الافتراضيّة» اعتمادات حساب الخدمة ذلك، فالحادث النموذجي أن يعمل لمستخدم تفاعلي ثمّ يعطي 407 فور تحويله إلى خدمة. افحصوا أيضاً في سجلّ جانب الوكيل بوصفه من صادق.

وكيل تفتيش TLS يُنتج أخطاء شهادة. هل يجوز تعطيل التحقّق من الشهادات؟

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

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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