कॉर्पोरेट प्रॉक्सी और Windows ऐप — WinINET, WinHTTP और .NET में प्रॉक्सी रिज़ॉल्यूशन सुलझाना

«ब्राउज़र बाहरी साइट खोल लेता है, पर केवल व्यावसायिक ऐप बाहरी API तक नहीं पहुँचता।» «डेवलपमेंट मशीन पर चलता है, पर ग्राहक नेटवर्क पर टाइम आउट होता है।» «हाथ से चलाऊँ तो संचार होता है, और Windows सेवा बनाते ही विफल हो जाता है।» — जब आप कॉर्पोरेट प्रॉक्सी वाले वातावरण में व्यावसायिक ऐप चलाते हैं, इस तरह की सलाह सबसे आम में है।

अधिकांश मामलों में कारण न प्रॉक्सी-सर्वर आउटेज है न ऐप बग। Windows में जिन्हें लोग «प्रॉक्सी सेटिंग» कहते हैं उनके कई अलग परिवार हैं, और कौन सी सेटिंग कौन पढ़ता है ऐप (उसके HTTP स्टैक) और चल रहे खाते के अनुसार भिन्न होता है — वही बेमेल। ब्राउज़र जो सेटिंग पढ़ता है, सेवा जो पढ़ती है, और .NET HttpClient जो पढ़ता है, प्रत्येक अलग चीज़ हो सकती है। एक बार वह संरचना सिर में हो, «ब्राउज़र में चलता है, पर…» को अलग करना आश्चर्यजनक रूप से तेज़ हो जाता है।

यह लेख छोटे-मझोले उद्यमों के IT कर्मचारी और Windows ऐप डेवलपर्स के लिए है। यह एक चित्र में तीन प्रॉक्सी-सेटिंग परिवार — WinINET, WinHTTP, और पर्यावरण चर — PAC और WPAD स्वतःकॉन्फ़िगरेशन, .NET Framework और .NET (Core और बाद) के बीच प्रॉक्सी रिज़ॉल्यूशन का अंतर, प्रमाणीकरण प्रॉक्सी (407), TLS निरीक्षण, और व्यावहारिक अलगाव प्रक्रिया बाँधता है। HttpClient निर्माण पैटर्न और टाइमआउट डिज़ाइन स्वयं «HttpClient को using ब्लॉक में न लपेटें» में हैं, इसलिए यह लेख प्रॉक्सी रिज़ॉल्यूशन पर केंद्रित है।

1. पहले निष्कर्ष

• Windows प्रॉक्सी सेटिंग एक चीज़ नहीं; कम से कम तीन परिवार हैं। (1) WinINET प्रति-उपयोगकर्ता सेटिंग (Settings ऐप का «Proxy» पृष्ठ = पुरानी Internet Options), (2) WinHTTP मशीन सेटिंग (netsh winhttp), और (3) HTTP_PROXY / HTTPS_PROXY पर्यावरण चर। कौन पढ़ा जाता है ऐप पक्ष पर तय होता है।¹²
• Settings ऐप में जो «Proxy» दिखता है वह WinINET की प्रति-उपयोगकर्ता सेटिंग है। ब्राउज़र और इंटरैक्टिव ऐप उन्हें पढ़ते हैं; Windows सेवाएँ नहीं। सेवा में WinINET समर्थित नहीं; सेवा उपयोग WinHTTP का काम है।¹³
• «हाथ से चलता है पर सेवा के रूप में नहीं» का सबसे आम कारण चल रहे खाते का अंतर है। LocalSystem और सेवा खाता उस प्रति-उपयोगकर्ता प्रॉक्सी को नहीं देख सकते जो व्यवस्थापक ने अपनी स्क्रीन पर कॉन्फ़िगर की।³⁴
• netsh winhttp set proxy स्थिर सेटिंग है; PAC, स्वचालित पहचान, या प्रॉक्सी प्रमाणीकरण नहीं संभालती। यदि मशीन-वार PAC या WPAD कॉन्फ़िगर करना हो, netsh winhttp set advproxy पक्ष चाहिए।⁴²
• PAC परिणाम URL के अनुसार बदलते हैं। PAC फ़ाइल का FindProxyForURL फ़ंक्शन URL और होस्ट लेता है और प्रॉक्सी सूची या सीधा कनेक्शन (DIRECT) लौटाता है। «वह साइट चलती है, पर केवल यह API नहीं» PAC शाखा हो सकती है।⁵⁶
• .NET (Core और बाद) पर HttpClient डिफ़ॉल्ट प्रॉक्सी पर्यावरण चर → Windows उपयोगकर्ता प्रॉक्सी सेटिंग के क्रम में आरंभ करता है। यदि HTTP_PROXY, HTTPS_PROXY, या ALL_PROXY में कोई परिभाषित है, वह OS सेटिंग पर प्राथमिकता लेता है, इसलिए «किसी ने पर्यावरण चर छोड़ दिया» दुर्घटना हो सकती है।⁷
• .NET Framework का डिफ़ॉल्ट चल रहे खाते की Internet Options है, और app.config में defaultProxy से ओवरराइड होता है। कॉन्फ़िगरेशन-फ़ाइल सेटिंग सिस्टम सेटिंग पर प्राथमिकता लेती हैं।⁸⁹
• 407 प्रॉक्सी-प्रमाणीकरण त्रुटि है; 401 (सर्वर प्रमाणीकरण) से अलग चीज़ है। स्कीम में Negotiate, NTLM, और Basic हैं, और .NET में साख DefaultProxyCredentials या WebProxy.UseDefaultCredentials से देते हैं। ध्यान रखें कि सेवा खाते के अधीन «डिफ़ॉल्ट साख» की सामग्री बदल जाती है।¹⁰¹¹¹²
• TLS-निरीक्षण प्रॉक्सी केवल आंतरिक CA प्रमाणपत्र वितरण के साथ सेट के रूप में टिकता है। जिन्हें वह नहीं मिला, मशीन और रनटाइम प्रमाणपत्र-सत्यापन त्रुटि पाते हैं। ऐप में सत्यापन बंद करके नहीं, प्रमाणपत्र स्टोर में वितरित करके हल करें।¹³⁴

एक वाक्य में: जब भी आप कहें «मैंने प्रॉक्सी सेटिंग जाँची», हमेशा कह सकें तीन परिवारों में से कौन जाँचा, और किस खाते से — यही इस लेख का विषय है।

2. Windows में «प्रॉक्सी सेटिंग» के तीन परिवार हैं

पहले, समग्र मानचित्र। Windows ऐप कॉर्पोरेट प्रॉक्सी खोजने के लिए जिन पथों का उपयोग करता है वे इन तीन परिवारों में पड़ते हैं।

(1) वह है जिसे लोग सामान्यतः «Windows प्रॉक्सी सेटिंग» मानते हैं; सार WinINET कॉन्फ़िगरेशन है। ऐतिहासिक रूप से यह Internet Explorer की Internet Options है, और डिफ़ॉल्ट प्रति उपयोगकर्ता संग्रहीत है।⁴

(2) सेवा जैसे संदर्भों के लिए प्रति-मशीन डिफ़ॉल्ट है जहाँ «कोई साइन-इन उपयोगकर्ता नहीं»। (3) मुख्यतः क्रॉस-प्लेटफ़ॉर्म दुनिया से आए उपकरणों की परिपाटी है; Windows पर .NET (Core और बाद) और curl आदि भी इसे पढ़ते हैं।⁷

महत्वपूर्ण बिंदु यह है कि कौन सा परिवार पढ़ा जाता है सेटिंग पक्ष पर नहीं, ऐप पक्ष पर तय होता है। यदि ऐप आंतरिक रूप से WinINET इस्तेमाल करे तो (1) पढ़ता है; WinHTTP हो तो (2) (या ऐप-विशिष्ट ओवरराइड); .NET (Core और बाद) हो तो (3) फिर (1)। इसलिए आमतौर पर «प्रॉक्सी सेटिंग सही है पर फिर भी जुड़ नहीं पाता» नहीं होता; वास्तविकता «ऐप जो परिवार पढ़ रहा था वह आपके जाँचे परिवार से अलग परिवार था» है।

flowchart TB
    accTitle: Windows प्रॉक्सी सेटिंग के तीन परिवार
    accDescr: WinINET प्रति-उपयोगकर्ता Settings और Internet Options है, WinHTTP netsh के माध्यम से मशीन डिफ़ॉल्ट है, और पर्यावरण चर प्रक्रिया-दायरे हैं। कौन सा परिवार पढ़ा जाता है सेटिंग पक्ष नहीं, ऐप तय करता है
    fam{"कौन सा परिवार?"}
    fam --> wininet["WinINET प्रति-उपयोगकर्ता सेटिंग"]
    fam --> winhttp["WinHTTP मशीन सेटिंग"]
    fam --> env["HTTP_PROXY और साथी"]
    wininet -.-> r1["ब्राउज़र और डेस्कटॉप ऐप"]
    winhttp -.-> r2["सेवाएँ और कुछ OS भाग"]
    env -.-> r3[".NET Core+ और curl"]

चित्र 1: तीन परिवार साथ-साथ बैठते हैं। ऐप चुनता है कि कौन पढ़े।

यदि आप Group Policy «Make proxy settings per-machine (rather than per-user)» सक्षम करें, (1) को प्रति-मशीन कर हर उपयोगकर्ता पर वही सेटिंग लागू कर सकते हैं। MDM (Intune आदि) से NetworkProxy CSP से प्रति डिवाइस कॉन्फ़िगर कर सकते हैं।⁴

3. WinINET और WinHTTP — इंटरैक्टिव ऐप के लिए और सेवाओं के लिए

3.1. भूमिकाओं का अंतर

WinINET और WinHTTP दोनों Windows इनबॉक्स HTTP क्लाइंट स्टैक हैं, पर अलग उपयोग मानते हैं।

• WinINET: इंटरैक्टिव डेस्कटॉप ऐप के लिए। उपयोगकर्ता की Internet Options (प्रॉक्सी, कुकी, साख कैश) स्वतः विरासत में लेता है और आवश्यकता हो तो साख-प्रविष्टि UI भी दिखा सकता है। सेवा या सेवा-जैसे प्रोसेस में उपयोग समर्थित नहीं।¹
• WinHTTP: सेवाओं और सर्वर पक्ष के लिए। सेवा खाते के अधीन चलना, थ्रेड प्रतिरूपण, और सत्र अलगाव समर्थन करता है; बदले में उपयोगकर्ता की ब्राउज़र सेटिंग, कुकी, या साख साझा नहीं करता। UI भी नहीं दिखाता।³

Microsoft का अपना मार्गदर्शन उतना ही स्पष्ट है: «WinINET इस्तेमाल करें जब तक आप सेवा के भीतर, या सत्र अलगाव और प्रतिरूपण चाहिए ऐसे सेवा-जैसे प्रोसेस में न चल रहे हों» — दूसरे शब्दों में, यदि सेवा है, WinHTTP इस्तेमाल करें।¹

flowchart TB
    accTitle: इंटरैक्टिव ऐप के लिए WinINET, सेवाओं के लिए WinHTTP
    accDescr: WinINET साइन-इन उपयोगकर्ता की Internet Options विरासत में लेता है और सेवा में समर्थित नहीं। WinHTTP बिना UI सेवा खाते के अधीन चलता है और उपयोगकर्ता की ब्राउज़र सेटिंग साझा नहीं करता
    q{"इंटरैक्टिव डेस्कटॉप ऐप?"}
    q -->|"हाँ"| ie["WinINET"]
    q -->|"सेवा या सेवा-जैसा"| wh["WinHTTP"]
    ie -.-> ieNote["उपयोगकर्ता की Internet Options पढ़ता है"]
    wh -.-> whNote["मशीन सेटिंग, कोई UI नहीं"]

चित्र 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 URL निर्दिष्ट करना, न प्रॉक्सी प्रमाणीकरण संभालती है।⁴
2. import proxy source=ie उस क्षण की स्थिर सेटिंग की प्रतिलिपि मात्र है; बाद में Internet Options पक्ष के बदलाव नहीं अपनाती। जब PAC या स्वतः-पहचान सहित प्रति-मशीन कॉन्फ़िगरेशन चाहिए, JSON-रूप विस्तृत सेटिंग (Proxy, ProxyBypass, AutoconfigUrl, AutoDetect) netsh winhttp set advproxy से कॉन्फ़िगर करें।²

3.3. सबसे आम ख़तरा: सेवा उपयोगकर्ता की IE सेटिंग नहीं पढ़ती

साइट पर सबसे अधिक दिखने वाला पैटर्न, समय क्रम में, ऐसा लगता है।

1. डेवलपर अपने PC पर उपकरण चलाता है → उसकी प्रति-उपयोगकर्ता प्रॉक्सी सेटिंग (1) लागू होती है और चलता है
2. उत्पादन में उसे LocalSystem के अधीन Windows सेवा (Windows सेवाएँ कैसे बनाएँ और चलाएँ) के रूप में निवासी छोड़ दिया जाता है
3. LocalSystem से दिखने वाली सेटिंग अलग चीज़ है (प्रति-उपयोगकर्ता सेटिंग अदृश्य, और WinHTTP मशीन सेटिंग असंयोजित = DIRECT) → बाहरी API से सीधा कनेक्शन आज़माता है और टाइम आउट होता है

«एक ही मशीन होने पर भी नहीं चलता» नहीं है; एक ही मशीन पर भी, अलग चल रहा खाता मतलब अलग दिखने वाली प्रॉक्सी सेटिंग का सेट। उस प्रोसेस के लिए जो कोई उपयोगकर्ता साइन इन न हो तब भी संचार करे, सही दृष्टिकोण प्रति-मशीन सेटिंग उस रूप में तैयार करना है जो उस प्रोसेस का HTTP स्टैक वास्तव में पढ़ता है। WinHTTP इस्तेमाल करने वाले नेटिव ऐप या Windows घटक के लिए netsh WinHTTP सेटिंग लागू होती है।⁴ दूसरी ओर .NET (Core और बाद) पर HttpClient 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 के रूप में Windows सेवा"] --> miss["प्रति-उपयोगकर्ता सेटिंग अदृश्य"]
    miss --> stack{"कौन सा HTTP स्टैक?"}
    stack -->|"WinHTTP"| direct["WinHTTP असंयोजित = DIRECT"]
    stack -->|".NET Core+"| env["पर्यावरण चर या handler.Proxy"]
    direct --> fail["बाहरी API टाइम आउट"]

चित्र 3: वही मशीन, अलग खाता, अलग दिखने वाली प्रॉक्सी सेटिंग का सेट।

4. PAC और WPAD — «स्वचालित कॉन्फ़िगरेशन» वास्तव में क्या है

4.1. PAC फ़ाइलें और FindProxyForURL

PAC (Proxy Auto-Configuration) फ़ाइल JavaScript (ECMAScript) है जो गणना करती है «इस URL के लिए कौन सी प्रॉक्सी इस्तेमाल करें», और उसमें हमेशा 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 URL (होस्ट) के अनुसार अलग प्रॉक्सी या सीधा कनेक्शन लौटा सकता है, WinHTTP की स्वचालित-प्रॉक्सी सुविधा भी अनुरोध URL पास कर हर बार पूछने के लिए डिज़ाइन है।⁶ «ब्राउज़र दूसरी साइट देख सकता है» प्रमाण नहीं कि समस्या API वही पथ लेती है।
• DIRECT «बिना प्रॉक्सी जाएँ» का निर्देश है। यदि आंतरिक होना चाहिए ट्रैफ़िक प्रॉक्सी लॉग में कभी न दिखे, पहले संदेह करें कि PAC ने DIRECT लौटाया (या बायपास सूची से मेल खाया)।

4.2. WPAD के माध्यम से स्वचालित पहचान

«Automatically detect settings» चालू करें और मशीन WPAD (Web Proxy Auto-Discovery) प्रोटोकॉल से PAC फ़ाइल का स्थान खोजती है। विशिष्ट कॉन्फ़िगरेशन में DHCP PAC URL सौंपता है, या DNS से wpad नाम का होस्ट देखा जाता है और PAC http://wpad/wpad.dat जैसे URL से डाउनलोड होता है।¹⁴

दूसरे शब्दों में, «स्वचालित पहचान» जादू नहीं; वह तंत्र है जो केवल उस नेटवर्क पर काम करता है जहाँ DHCP/DNS में पहले से WPAD व्यवस्था है। बिना ऐसी व्यवस्था वाले नेटवर्क पर केवल स्वचालित पहचान चालू करना पहचान विफलता की प्रतीक्षा समय जोड़ता है।

flowchart TB
    accTitle: PAC URL के अनुसार प्रॉक्सी रिज़ॉल्व करता है, WPAD केवल PAC खोजता है
    accDescr: FindProxyForURL URL और होस्ट लेता है और प्रॉक्सी सूची या DIRECT लौटाता है। WPAD केवल DHCP या DNS से PAC खोजता है। PAC मूल्यांकित न कर पाने वाला क्लाइंट स्थिर प्रॉक्सी या पर्यावरण चर पर गिरता है
    url["अनुरोध URL"] --> pac["FindProxyForURL"]
    pac -->|"प्रॉक्सी सूची"| via["प्रॉक्सी से जाएँ"]
    pac -->|"DIRECT"| dir["बिना प्रॉक्सी जुड़ें"]
    wpad["DHCP या DNS से WPAD"] -.-> pac
    nopac["क्लाइंट PAC मूल्यांकित नहीं कर सकता"] -.-> fb["स्थिर सेटिंग या पर्यावरण चर"]

चित्र 4: PAC URL के अनुसार तय करता है। WPAD केवल PAC फ़ाइल खोजता है।

4.3. PAC मूल्यांकित न कर पाने वाले क्लाइंट कैसे व्यवहार करते हैं

हर क्लाइंट PAC मूल्यांकित नहीं कर सकता।

• netsh winhttp set proxy की स्थिर सेटिंग PAC मूल्यांकित नहीं करती।⁴
• HTTP_PROXY पर्यावरण-चर शैली इस्तेमाल करने वाले उपकरण आमतौर पर केवल स्थिर प्रॉक्सी URL लिख सकते हैं (PAC URL लिखने की जगह नहीं)।⁷
• सीधे WinHTTP इस्तेमाल करने वाले नेटिव ऐप के लिए यह सत्र कैसे खोला गया इस पर निर्भर करता है। Windows 8.1 और बाद पर WinHttpOpen से 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 — डिफ़ॉल्ट Internet Options, defaultProxy से ओवरराइड

.NET Framework पर HttpWebRequest और उस पर बैठा HttpClient स्पष्ट Proxy न दें तो डिफ़ॉल्ट प्रॉक्सी इस्तेमाल करते हैं। डिफ़ॉल्ट प्रॉक्सी सिस्टम Internet सेटिंग (चल रहे खाते की WinINET सेटिंग) और कॉन्फ़िगरेशन फ़ाइल के संयोजन से तय होती है, और कॉन्फ़िगरेशन-फ़ाइल सेटिंग प्राथमिकता लेती हैं।⁸

इस डिफ़ॉल्ट को app.config (या machine.config) के system.net/defaultProxy तत्व से नियंत्रित कर सकते हैं।⁹

<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 तत्व खाली छोड़ें तो सिस्टम (Internet Options) सेटिंग इस्तेमाल होती है; proxyaddress आदि लिखें तो वे प्राथमिकता लेते हैं। प्रोग्राम से उसी डिफ़ॉल्ट को WebRequest.DefaultWebProxy से बदल सकते हैं।⁹⁸

अध्याय 3.3 का ख़तरा यहाँ भी लागू होता है। क्योंकि डिफ़ॉल्ट «चल रहे खाते की Internet Options» है, सेवा खाते के अधीन चलने वाला .NET Framework ऐप व्यवस्थापक के डेस्कटॉप पर दिखने वाली सेटिंग से अलग (आमतौर पर खाली) सेट पढ़ता है।

5.2. .NET (Core और बाद) — पहले पर्यावरण चर, फिर OS उपयोगकर्ता सेटिंग

.NET (Core और बाद) पर HttpClient की स्थैतिक संपत्ति HttpClient.DefaultProxy है। जब तक हैंडलर स्पष्ट प्रॉक्सी न दे, हर HttpClient इंस्टेंस उसे इस्तेमाल करता है। Windows पर आरंभ नियम है «पर्यावरण चर पढ़ें, और यदि परिभाषित नहीं हैं तो उपयोगकर्ता प्रॉक्सी सेटिंग पढ़ें»।⁷

इस्तेमाल पर्यावरण चर ये हैं।⁷

तीन बातें ध्यान दें।

• यदि HTTP_PROXY, HTTPS_PROXY, या ALL_PROXY में कोई परिभाषित है, वह OS-पक्ष प्रॉक्सी सेटिंग पर प्राथमिकता लेता है। केवल NO_PROXY परिभाषित करने से पर्यावरण चर से प्रॉक्सी कॉन्फ़िगर नहीं होती, और Windows पर OS उपयोगकर्ता प्रॉक्सी सेटिंग चलती रहती है। पुराने प्रयोग के बाद HTTPS_PROXY सिस्टम पर्यावरण चर छोड़ना, या CI/CD टेम्पलेट का इंजेक्ट करना, जैसी «अदृश्य सेटिंग» दुर्घटनाओं का प्रजनन स्थल हैं।
• NO_PROXY वाइल्डकार्ड (*) समर्थन नहीं करता। सबडोमेन मिलाने के लिए अग्रणी बिंदु लगाएँ (.example.com www.example.com से मेल खाता है पर example.com स्वयं से नहीं)।⁷
• गैर-Windows (Linux कंटेनर आदि) पर यदि पर्यावरण चर अपरिभाषित हैं तो बिना प्रॉक्सी आरंभ होता है। उसी ऐप का डिफ़ॉल्ट व्यवहार Windows और Linux के बीच बदलना कंटेनर-माइग्रेशन समय पुष्टि करने योग्य है।⁷

5.3. स्पष्ट निर्दिष्टीकरण — HttpClientHandler.Proxy और UseProxy

किसी भी रनटाइम पर सर्वोच्च प्राथमिकता हैंडलर पर स्पष्ट निर्दिष्टीकरण है। HttpClientHandler.Proxy निर्दिष्ट करना OS सेटिंग और कॉन्फ़िगरेशन फ़ाइल पर प्राथमिकता लेता है, और 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);

जब स्पष्ट निर्दिष्टीकरण न हो और OS सेटिंग अपनाई जाए, स्थानीय गंतव्यों का स्वचालित बायपास नियम रखता है। बिना बिंदु का सपाट नाम, लूपबैक पता, मशीन के अपने डोमेन प्रत्यय से मेल खाने वाला गंतव्य आदि «स्थानीय» माने जा सकते हैं।¹⁴ «IP पता निर्दिष्ट करूँ तो व्यवहार बदलता है» या «FQDN इस्तेमाल करने पर अचानक प्रॉक्सी से जाने लगा» जैसी घटनाएँ इसी निर्णय से हो सकती हैं।

प्राथमिकता क्रम इस प्रकार है।

flowchart TB
    accTitle: Framework बनाम Core और बाद में डिफ़ॉल्ट प्रॉक्सी रिज़ॉल्यूशन
    accDescr: स्पष्ट HttpClientHandler.Proxy हमेशा जीतता है। Framework फिर app.config defaultProxy और चल रहे खाते की Internet Options इस्तेमाल करता है। Core और बाद HttpClient.DefaultProxy असाइनमेंट, फिर पर्यावरण चर, फिर Windows उपयोगकर्ता प्रॉक्सी सेटिंग
    expl["स्पष्ट handler.Proxy"] --> done["वह प्रॉक्सी इस्तेमाल होती है"]
    noexpl["कोई स्पष्ट Proxy नहीं"] --> fw{"कौन सा रनटाइम?"}
    fw -->|"Framework"| cfg["app.config defaultProxy"]
    cfg --> ie["चल रहे खाते की Internet Options"]
    fw -->|"Core और बाद"| dp["HttpClient.DefaultProxy"]
    dp --> ev["HTTP_PROXY और साथी"]
    ev --> user["Windows उपयोगकर्ता प्रॉक्सी सेटिंग"]

चित्र 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 में साख कैसे दें

जब OS सेटिंग से आने वाला डिफ़ॉल्ट प्रॉक्सी इस्तेमाल करना हो और केवल प्रमाणीकरण पार करना हो, 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 जारी रहता है
• उलटा, कुछ वातावरणों में सेवाओं के लिए प्रॉक्सी पक्ष पर प्रमाणीकरण छूट है (स्रोत IP या खाते से)

इसलिए 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) नहीं पढ़ सकता। प्रॉक्सी लॉग में गंतव्य होस्ट नाम और कनेक्शन सफल हुआ या नहीं रह जाता है; URL पथ दिखाई नहीं देता — यही «पास-थ्रू» प्रॉक्सी का व्यवहार है।

flowchart TB
    accTitle: प्रॉक्सी से HTTPS CONNECT सुरंग है
    accDescr: क्लाइंट प्रॉक्सी को CONNECT भेजता है, प्रॉक्सी TCP सुरंग खोलकर 200 लौटाता है, फिर क्लाइंट और गंतव्य सुरंग के भीतर TLS हैंडशेक करते हैं। प्रॉक्सी लॉग होस्ट देखता है, URL पथ नहीं
    cli["क्लाइंट"] -->|"CONNECT host:443"| px["प्रॉक्सी"]
    px -->|"200 और TCP सुरंग"| dest["गंतव्य"]
    dest -->|"सुरंग के भीतर TLS"| cli
    px -.-> log["लॉग: केवल होस्ट और सफलता"]

चित्र 7: पास-थ्रू प्रॉक्सी होस्ट देखता है, एन्क्रिप्टेड पथ नहीं।

7.2. TLS-निरीक्षण प्रॉक्सी और प्रमाणपत्र त्रुटियाँ

दूसरी ओर सुरक्षा-उत्पाद प्रॉक्सी में TLS-निरीक्षण (SSL डिक्रिप्शन, break and inspect) प्रकार है जो TLS समाप्त करता है, सामग्री जाँचता है, और अग्रेषित करने से पहले पुनःएन्क्रिप्ट करता है। इस योजना में क्लाइंट को दिखाया सर्वर प्रमाणपत्र वास्तविक नहीं; प्रॉक्सी के अपने CA से पुनःहस्ताक्षरित प्रमाणपत्र से बदला जाता है।¹³

इसलिए यह कॉन्फ़िगरेशन टिके यह आधार है कि «प्रॉक्सी का CA प्रमाणपत्र हर क्लाइंट के विश्वसनीय रूट में वितरित हो»। जिसे वह नहीं मिला, या जो रनटाइम Windows प्रमाणपत्र स्टोर नहीं देखता (अपने ट्रस्ट स्टोर वाले उपकरण), प्रमाणपत्र-सत्यापन त्रुटि पाते हैं। .NET में यह आमतौर पर AuthenticationException लपेटे HttpRequestException के रूप में सतह पर आता है («the remote certificate is invalid» तरह का संदेश)।

सुधार के सिद्धांत इस प्रकार हैं।

• आंतरिक CA प्रमाणपत्र स्थानीय कंप्यूटर के «Trusted Root Certification Authorities» स्टोर में वितरित करें। उपयोगकर्ता स्टोर और कंप्यूटर स्टोर का विभाजन «व्यवहार में Windows प्रमाणपत्र स्टोर» में है।
• कोड में प्रमाणपत्र सत्यापन बंद न करें। ServerCertificateCustomValidationCallback से हमेशा true लौटाने वाला वर्कअराउंड बाहरी नेटवर्क पर जाते ही मैन-इन-द-मिडिल न पकड़ सकने वाला कमज़ोर ऐप बन जाता है।
• प्रमाणपत्र-पिन किया ट्रैफ़िक पहले स्थान पर निरीक्षित नहीं हो सकता। कुछ Windows घटक जैसे विशिष्ट Microsoft प्रमाणपत्र सत्यापित करने वाले कनेक्शन प्रॉक्सी प्रमाणपत्र बदलते ही विफल होते हैं, और छूट के अलावा कोई वर्कअराउंड नहीं।⁴ Microsoft 365 जैसे SaaS के गंतव्य ट्रैफ़िक के लिए Microsoft स्वयं नेटवर्क-परत डिक्रिप्शन और निरीक्षण से छूट की अनुशंसा करता है।¹³

«हर आंतरिक साइट दिखती है, पर केवल विशेष क्लाउड सेवा ऐप में प्रमाणपत्र त्रुटि देती है» लक्षण पहले TLS-निरीक्षण छूट सूची और पिनिंग के संयोजन का संदेह कराए।

flowchart TB
    accTitle: TLS-निरीक्षण प्रॉक्सी प्रमाणपत्र पुनःहस्ताक्षरित करता है
    accDescr: प्रॉक्सी TLS समाप्त करता है, सामग्री जाँचता है, और अपने CA से पुनःहस्ताक्षरित प्रमाणपत्र दिखाता है। सत्यापन तभी टिकता है जब वह CA विश्वसनीय रूट में हो। कोड में सत्यापन बंद न करें
    real["वास्तविक सर्वर प्रमाणपत्र"] --> px["TLS-निरीक्षण प्रॉक्सी"]
    px --> fake["प्रॉक्सी CA से पुनःहस्ताक्षरित"]
    fake --> client["क्लाइंट सत्यापन"]
    client -->|"CA विश्वसनीय रूट में"| ok["सफल"]
    client -->|"CA अनुपस्थित"| err["प्रमाणपत्र त्रुटि"]
    err -.-> fix["CA स्टोर में वितरित करें"]

चित्र 8: निरीक्षण केवल आंतरिक CA वितरित करने के साथ सेट के रूप में काम करता है।

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) के पुनरुत्पादन परीक्षण में जागरूक रहें कि उपकरण कौन सा सेटिंग परिवार पढ़ता है। Windows-इनबॉक्स curl.exe -x http://proxy:8080 से प्रॉक्सी स्पष्ट निर्दिष्ट कर सकता है, और TLS सत्यापन के लिए सामान्यतः OS प्रमाणपत्र स्टोर (Schannel) इस्तेमाल करता है। Windows PowerShell 5.1 का Invoke-WebRequest .NET Framework पक्ष (डिफ़ॉल्ट Internet Options) अपनाता है; PowerShell 7 .NET पक्ष (पहले पर्यावरण चर) अपनाता है। «curl चलता है पर ऐप नहीं» स्वयं कॉन्फ़िगरेशन परिवारों के बीच बेमेल का संकेत है।
• यदि (3) का लक्ष्य सेवा है, सेवा के समान खाते के अधीन (1) और (2) फिर जाँचें। व्यवस्थापक के अपने सत्र में जाँच LocalSystem जो देखता है उसका प्रमाण नहीं।
• (4) के त्रुटि वर्गीकरण में 407 के लिए अध्याय 6 (प्रमाणीकरण) पहला उम्मीदवार लें, प्रमाणपत्र त्रुटि के लिए अध्याय 7 (TLS निरीक्षण), और टाइमआउट के लिए «प्रॉक्सी तक पहुँचा ही नहीं» (पथ, नाम रिज़ॉल्यूशन, फ़ायरवॉल)। कारण प्रॉक्सी के बजाय Windows Firewall इनबाउंड नियम हो उस पैटर्न को «Windows फ़ायरवॉल और व्यावसायिक अनुप्रयोग» कवर करता है।
• यदि (5) तक पहुँचें और प्रॉक्सी लॉग में अभी भी कोई निशान न हो, ट्रैफ़िक प्रॉक्सी तक कभी नहीं पहुँचा। PAC का DIRECT निर्णय, बायपास सूची, या बचा पर्यावरण चर संदेह करें, और आवश्यकता हो तो पैकेट कैप्चर से वास्तविक गंतव्य पुष्टि करें («Windows पर व्यवहार में पैकेट कैप्चर — 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. डिज़ाइन अनुशंसा — ऐप ऐसा बनाएँ जिस पर «प्रॉक्सी कॉन्फ़िगर कर सकें»

जाँच प्रक्रिया पलटें तो वह ऐप पक्ष की डिज़ाइन मार्गदर्शिका बन जाती है। कॉर्पोरेट प्रॉक्सी वाले वातावरण में पहुँचाने वाले Windows ऐप के लिए निम्नलिखित अनुशंसित है।

1. ऐप सेटिंग से प्रॉक्सी कॉन्फ़िगर करने योग्य बनाएँ। डिफ़ॉल्ट «OS सेटिंग अपनाएँ» है। अधिकांश वातावरणों में डिफ़ॉल्ट पर्याप्त है; केवल असाधारण वातावरणों — PAC पढ़ा नहीं जा सकता, सेवा के रूप में चलता है, विशेष प्रॉक्सी कॉन्फ़िगरेशन — में सेटिंग फ़ाइल से प्रॉक्सी URL, बायपास सूची, और «प्रॉक्सी इस्तेमाल न करें» निर्दिष्ट संभव बनाएँ। धारा 5.3 का HttpClientHandler.Proxy / UseProxy कार्यान्वयन बिंदु है।¹⁴
2. लिखें कि आंतरिक गंतव्य (API, डेटाबेस, लाइसेंस सर्वर आदि) प्रॉक्सी अपवाद के रूप में कैसे व्यवहारित होते हैं। परिनियोजन प्रक्रिया में लिख सकें उस रूप में रखें कि वे PAC DIRECT, बायपास सूची, या NO_PROXY से छूटे हैं। NO_PROXY मिलान नियम (कोई वाइल्डकार्ड नहीं, अग्रणी बिंदु का अर्थ) व्यापक रूप से गलत समझे जाते हैं, इसलिए उदाहरण लगाएँ।⁷
3. प्रॉक्सी से गुज़रने की धारणा पर टाइमआउट और पुनःप्रयास डिज़ाइन करें। यदि प्रॉक्सी डाउन हो या प्रमाणीकरण पर अटका हो, लंबी डिफ़ॉल्ट टाइमआउट पर प्रतीक्षा करने वाली इम्प्लीमेंटेशन UI और संचालन दोनों जमा देती है। छोटा कनेक्ट टाइमआउट अलग करें, और पुनःप्रयास आइडेम्पोटेंट अनुरोधों तक सीमित करें (डिज़ाइन विवरण «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);

यदि स्टार्टअप पर मुख्य गंतव्यों के लिए एक बार «पथ» और «चल रहा खाता» रिकॉर्ड करें, अध्याय 8 के चरण (1) से (3) केवल लॉग पढ़कर पूरे होते हैं। जब कहा जाए «ब्राउज़र में चलता है, पर…», ऐप पक्ष से कह सकना «मैंने यह सेटिंग इस्तेमाल की, और यह पथ» प्रॉक्सी परेशानी के विरुद्ध मज़बूत ऐप की शर्त है।

flowchart TB
    accTitle: प्रॉक्सी कॉन्फ़िगर करने योग्य बनाएँ और पथ लॉग करें
    accDescr: डिफ़ॉल्ट OS सेटिंग अपनाना है, ऐप सेटिंग से स्पष्ट प्रॉक्सी URL या बायपास या बिना-प्रॉक्सी अनुमति दें, और वास्तव में इस्तेमाल पथ चल रहे खाते के साथ लॉग करें
    def["डिफ़ॉल्ट: OS सेटिंग अपनाएँ"] --> exc{"असाधारण वातावरण?"}
    exc -->|"PAC अपठित / सेवा / विशेष"| cfg["URL, बायपास, या बिना प्रॉक्सी सेट करें"]
    exc -->|"सामान्य मामला"| os["OS डिफ़ॉल्ट इस्तेमाल करें"]
    cfg --> log["पथ और खाता लॉग करें"]
    os --> log

चित्र 10: जब चाहिए तब कॉन्फ़िगर करें। हमेशा लॉग करें कौन सा पथ इस्तेमाल हुआ।

10. सारांश

• Windows प्रॉक्सी सेटिंग तीन परिवारों में बँटती है — WinINET प्रति-उपयोगकर्ता सेटिंग, WinHTTP मशीन सेटिंग, और पर्यावरण चर — और कौन पढ़ा जाता है ऐप (उसके HTTP स्टैक) और चल रहे खाते से तय होता है।
• WinINET इंटरैक्टिव ऐप के लिए है और सेवा में उपयोग समर्थित नहीं; सेवा उपयोग WinHTTP का काम है (netsh winhttp)। «हाथ से चलता है पर सेवा के रूप में नहीं» के लिए पहले चल रहे खाते का अंतर संदेह करें।
• netsh winhttp set proxy स्थिर सेटिंग है और PAC, स्वचालित पहचान, या प्रमाणीकरण नहीं संभालती। PAC-संचालित नेटवर्क पर PAC न पढ़ सकने वाले क्लाइंट का व्यवहार तय करना पड़ता है।
• PAC का FindProxyForURL URL के अनुसार प्रॉक्सी या DIRECT लौटाता है। WPAD केवल उस नेटवर्क पर काम करता है जहाँ DHCP/DNS व्यवस्था है।
• .NET Framework का डिफ़ॉल्ट चल रहे खाते की Internet Options है (defaultProxy से ओवरराइड); .NET (Core और बाद) पर्यावरण चर फिर उपयोगकर्ता प्रॉक्सी सेटिंग है। स्पष्ट निर्दिष्टीकरण (HttpClientHandler.Proxy) हमेशा सर्वोच्च प्राथमिकता है।
• 407 प्रॉक्सी-प्रमाणीकरण त्रुटि है; सेवा खाते के अधीन चलने वाले ऐप में विशिष्ट कारण यह है कि «डिफ़ॉल्ट साख» अलग व्यक्ति बन जाती हैं।
• TLS-निरीक्षण प्रॉक्सी आंतरिक CA प्रमाणपत्र वितरण मानता है, और प्रमाणपत्र त्रुटि का सही उत्तर सत्यापन बंद करना नहीं, स्टोर में वितरण है। पिन किया ट्रैफ़िक छूट चाहता है।
• «पुनरुत्पादित करें → तीन परिवार की सेटिंग संग्रहें → चल रहा खाता पहचानें → त्रुटि वर्गीकृत करें → प्रॉक्सी लॉग» क्रम में यंत्रवत अलग करें। ऐप पक्ष पर «प्रॉक्सी कॉन्फ़िगर कर सके, और इस्तेमाल पथ लॉग करे» डिज़ाइन सबसे अच्छा निवारण है।

अगली बार जब «केवल व्यावसायिक ऐप जुड़ नहीं सकता» सलाह आए, पहले यह पूछें।

वह ऐप किसके खाते के अधीन चल रहा है, और प्रॉक्सी सेटिंग के तीन परिवारों में से कौन पढ़ता है?

वह एक प्रश्न जाँच के प्रवेश द्वार बहुत बदल देता है।

संबंधित लेख

• HttpClient को using ब्लॉक में न लपेटें — C# व्यावसायिक ऐप में व्यावहारिक HTTP संचार (निर्माण पैटर्न, टाइमआउट, पुनःप्रयास)
• Windows पर व्यवहार में पैकेट कैप्चर — pktmon, netsh trace, और Wireshark में से चुनना
• Windows फ़ायरवॉल और व्यावसायिक अनुप्रयोग — इंस्टॉलर से इनबाउंड नियम पंजीकृत करें
• Windows सेवाएँ कैसे बनाएँ और चलाएँ ── Task Scheduler और सेवाओं के बीच चुनाव से BackgroundService को Windows सेवा बनाना
• आरेखों के साथ NTLM और Kerberos — प्रमाणीकरण NTLM पर क्यों गिरता है
• व्यवहार में Windows प्रमाणपत्र स्टोर — उपयोगकर्ता या कंप्यूटर, कौन इस्तेमाल करें?

संबंधित परामर्श क्षेत्र

KomuraSoft LLC कॉर्पोरेट-प्रॉक्सी, प्रमाणीकरण-प्रॉक्सी, और TLS-निरीक्षण वातावरण पर Windows-ऐप संचार परेशानी की जाँच संभालता है — «डेवलपमेंट मशीन पर चलता है पर ग्राहक नेटवर्क पर संचार नहीं कर सकता», «सेवा बनाने के बाद बाहरी API तक नहीं पहुँच सका» — और प्रॉक्सी वातावरण मानकर व्यावसायिक-ऐप संचार डिज़ाइन पर परामर्श (सेटिंग आइटम, टाइमआउट, लॉग डिज़ाइन)। पुनरुत्पादन चरण और लॉग कैसे संग्रहें व्यवस्थित करने से शुरू करना ठीक है।

• Windows ऐप विकास
• बग और कारणों की जाँच
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

ब्राउज़र जुड़ जाता है, पर केवल व्यावसायिक ऐप कॉर्पोरेट प्रॉक्सी पार नहीं कर पाता। क्यों?

ब्राउज़र WinINET की प्रति-उपयोगकर्ता प्रॉक्सी सेटिंग पढ़ता है, पर व्यावसायिक ऐप वही सेटिंग नहीं पढ़ता। Windows सेवा के रूप में, या दूसरे खाते के अधीन चलने वाला ऐप उस खाते से दिखने वाली सेटिंग, WinHTTP की मशीन सेटिंग, या पर्यावरण चर देखता है। पहले चल रहे खाते की पहचान करें, फिर उसी खाते से दिखने वाली प्रॉक्सी सेटिंग netsh winhttp show proxy और उपयोगकर्ता सेटिंग दोनों में जाँचें। यदि उसी मशीन पर उसी खाते से curl.exe आदि से पुनरुत्पादित हो, तो इसे ऐप-विशिष्ट समस्या नहीं, कॉन्फ़िगरेशन परिवारों के बीच बेमेल मानें।

मैंने netsh winhttp set proxy सेट किया, पर ऐप का ट्रैफ़िक नहीं बदला। क्यों?

netsh winhttp जो सेट करता है वह WinHTTP का मशीन डिफ़ॉल्ट है। यह ब्राउज़र या इंटरैक्टिव ऐप जो WinINET पढ़ते हैं, या .NET (Core और बाद) HttpClient जो पर्यावरण चर को प्राथमिकता देता है, को प्रभावित नहीं करता। netsh winhttp set proxy स्थिर सेटिंग भी है; PAC स्वतःकॉन्फ़िगरेशन, स्वचालित पहचान, या प्रॉक्सी प्रमाणीकरण नहीं संभालता। पहले पुष्टि करें कि लक्ष्य ऐप कौन सा HTTP स्टैक इस्तेमाल करता है और किस कॉन्फ़िगरेशन परिवार से प्रॉक्सी रिज़ॉल्व करता है।

.NET ऐप कौन सी प्रॉक्सी सेटिंग पढ़ता है?

.NET Framework डिफ़ॉल्ट रूप से चल रहे खाते की Internet Options (WinINET-समतुल्य) सेटिंग इस्तेमाल करता है, और app.config के system.net/defaultProxy तत्व से ओवरराइड किया जा सकता है। .NET (Core और बाद) पर HttpClient पहले HTTP_PROXY, HTTPS_PROXY और NO_PROXY जैसे पर्यावरण चर पढ़ता है, और यदि परिभाषित नहीं हैं तो Windows उपयोगकर्ता प्रॉक्सी सेटिंग पर गिरता है। दोनों मामलों में स्पष्ट HttpClientHandler.Proxy प्राथमिकता लेता है। डिफ़ॉल्ट रिज़ॉल्यूशन क्रम Framework और Core और बाद के बीच भिन्न है, इसलिए माइग्रेट करते समय प्रॉक्सी व्यवहार फिर जाँचें।

जब 407 Proxy Authentication Required लौटे तो क्या जाँचें?

407 संकेत है कि प्रॉक्सी स्वयं प्रमाणीकरण माँग रहा है; यह गंतव्य-सर्वर प्रमाणीकरण त्रुटि (401) से अलग है। पहले Proxy-Authenticate हेडर से प्रॉक्सी जिस स्कीम की माँग कर रहा है (Negotiate, NTLM, Basic) पुष्टि करें, और .NET में HttpClientHandler.DefaultProxyCredentials या WebProxy.UseDefaultCredentials से साख दें। सेवा खाते के अधीन चलने वाले ऐप में «डिफ़ॉल्ट साख» उसी सेवा खाते की हो जाती हैं, इसलिए विशिष्ट घटना यह है कि इंटरैक्टिव उपयोगकर्ता के लिए काम करे और सेवा बनते ही 407 दे। प्रॉक्सी-साइड लॉग में भी देखें कि उसने किसके रूप में प्रमाणित किया।

TLS-निरीक्षण प्रॉक्सी प्रमाणपत्र त्रुटियाँ पैदा करता है। क्या प्रमाणपत्र सत्यापन बंद करूँ?

बंद करना अनुशंसित नहीं है। TLS-निरीक्षण प्रॉक्सी ट्रैफ़िक डिक्रिप्ट करता है फिर क्लाइंट को अपने CA से पुनःहस्ताक्षरित प्रमाणपत्र दिखाता है, इसलिए यदि वह CA प्रमाणपत्र विश्वसनीय रूट में नहीं है तो सत्यापन विफल होता है। सही समाधान आंतरिक CA प्रमाणपत्र को Windows प्रमाणपत्र स्टोर (आमतौर पर स्थानीय कंप्यूटर के Trusted Root Certification Authorities) में वितरित करना है। कोड में सत्यापन बंद करने का मतलब है कि बाहरी नेटवर्क पर ऐप इस्तेमाल होने पर मैन-इन-द-मिडिल हमला पकड़ा नहीं जा सकता, और कमज़ोरी रहती है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।