Corporate proxy और Windows apps — WinINET, WinHTTP और .NET में proxy resolution सुलझाना

«Browser बाहरी site खोल लेता है, पर केवल business app बाहरी API तक नहीं पहुँचता।» «Development मशीन पर चलता है, पर customer network पर time out होता है।» «हाथ से चलाऊँ तो communication होता है, और Windows service बनाते ही fail हो जाता है।» — जब आप corporate proxy वाले environment में business app चलाते हैं, इस तरह की सलाह सबसे आम में है।

ज़्यादातर मामलों में कारण न proxy-server outage है न ऐप bug। Windows में जिन्हें लोग «proxy settings» कहते हैं उनके कई अलग families हैं, और कौन सी setting कौन पढ़ता है ऐप (उसके HTTP stack) और चल रहे account के अनुसार भिन्न होता है — वही mismatch। Browser जो settings पढ़ता है, service जो पढ़ती है, और .NET HttpClient जो पढ़ता है, प्रत्येक अलग चीज़ हो सकती है। एक बार वह structure सिर में हो, «browser में चलता है, पर…» को अलग करना आश्चर्यजनक रूप से तेज़ हो जाता है।

यह लेख SME के IT staff और Windows app developers के लिए है। यह एक चित्र में तीन proxy-setting families — WinINET, WinHTTP, और environment variables — PAC और WPAD auto-configuration, .NET Framework और .NET (Core और बाद) के बीच proxy resolution का अंतर, authenticating proxy (407), TLS inspection, और practical isolation procedure बाँधता है। HttpClient निर्माण patterns और timeout डिज़ाइन स्वयं «HttpClient को using ब्लॉक में न लपेटें» में हैं, इसलिए यह लेख proxy resolution पर केंद्रित है।

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

• Windows proxy settings एक चीज़ नहीं; कम से कम तीन families हैं। (1) WinINET per-user settings (Settings ऐप का «Proxy» page = पुरानी Internet Options), (2) WinHTTP machine settings (netsh winhttp), और (3) HTTP_PROXY / HTTPS_PROXY environment variables। कौन पढ़ा जाता है ऐप पक्ष पर तय होता है।¹²
• Settings ऐप में जो «Proxy» दिखता है वह WinINET की per-user settings है। Browser और interactive apps उन्हें पढ़ते हैं; Windows services नहीं। Service में WinINET supported नहीं; service उपयोग WinHTTP का काम है।¹³
• «हाथ से चलता है पर service के रूप में नहीं» का सबसे आम कारण चल रहे account का अंतर है। LocalSystem और service account उस per-user proxy को नहीं देख सकते जो admin ने अपनी स्क्रीन पर configure की।³⁴
• netsh winhttp set proxy static setting है; PAC, automatic detection, या proxy authentication नहीं संभालती। अगर machine-wide PAC या WPAD configure करना हो, netsh winhttp set advproxy पक्ष चाहिए।⁴²
• PAC results URL के अनुसार बदलते हैं। PAC फ़ाइल का FindProxyForURL function URL और host लेता है और proxy सूची या सीधा connection (DIRECT) लौटाता है। «वह site चलती है, पर केवल यह API नहीं» PAC शाखा हो सकती है।⁵⁶
• .NET (Core और बाद) पर HttpClient default proxy environment variables → Windows user proxy settings के क्रम में initialize करता है। अगर HTTP_PROXY, HTTPS_PROXY, या ALL_PROXY में कोई defined है, वह OS settings पर प्राथमिकता लेता है, इसलिए «किसी ने environment variable छोड़ दिया» दुर्घटना हो सकती है।⁷
• .NET Framework का default चल रहे account की Internet Options है, और app.config में defaultProxy से override होता है। Configuration-file settings system settings पर प्राथमिकता लेती हैं।⁸⁹
• 407 proxy-authentication error है; 401 (server authentication) से अलग चीज़ है। Scheme में Negotiate, NTLM, और Basic हैं, और .NET में credentials DefaultProxyCredentials या WebProxy.UseDefaultCredentials से देते हैं। ध्यान रखें कि service account के अधीन «default credentials» की content बदल जाती है।¹⁰¹¹¹²
• TLS-inspection proxy केवल internal CA certificate distribution के साथ सेट के रूप में टिकता है। जिन्हें वह नहीं मिला, मशीन और runtime certificate-validation error पाते हैं। ऐप में validation बंद करके नहीं, certificate store में distribute करके हल करें।¹³⁴

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

2. Windows में «proxy settings» के तीन families हैं

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

(1) वह है जिसे लोग सामान्यतः «Windows proxy settings» मानते हैं; सार WinINET configuration है। ऐतिहासिक रूप से यह Internet Explorer की Internet Options है, और default per user संग्रहीत है।⁴

(2) Service जैसे contexts के लिए per-machine default है जहाँ «कोई signed-in user नहीं»। (3) मुख्यतः cross-platform दुनिया से आए tools की परिपाटी है; Windows पर .NET (Core और बाद) और curl आदि भी इसे पढ़ते हैं।⁷

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

flowchart TB
    accTitle: Windows proxy settings के तीन families
    accDescr: WinINET per-user Settings और Internet Options है, WinHTTP netsh के माध्यम से machine default है, और environment variables process-scope हैं। कौन सा family पढ़ा जाता है settings पक्ष नहीं, ऐप तय करता है
    fam{"कौन सा family?"}
    fam --> wininet["WinINET per-user settings"]
    fam --> winhttp["WinHTTP machine settings"]
    fam --> env["HTTP_PROXY और साथी"]
    wininet -.-> r1["Browser और desktop apps"]
    winhttp -.-> r2["Services और कुछ OS भाग"]
    env -.-> r3[".NET Core+ और curl"]

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

अगर आप Group Policy «Make proxy settings per-machine (rather than per-user)» enable करें, (1) को per-machine कर हर user पर वही settings apply कर सकते हैं। MDM (Intune आदि) से NetworkProxy CSP से per device configure कर सकते हैं।⁴

3. WinINET और WinHTTP — interactive apps के लिए और services के लिए

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

WinINET और WinHTTP दोनों Windows inbox HTTP client stacks हैं, पर अलग उपयोग मानते हैं।

• WinINET: Interactive desktop apps के लिए। User की Internet Options (proxy, cookies, credential cache) स्वतः inherit करता है और आवश्यकता हो तो credential-entry UI भी दिखा सकता है। Service या service-like process में उपयोग supported नहीं।¹
• WinHTTP: Services और server पक्ष के लिए। Service account के अधीन चलना, thread impersonation, और session isolation support करता है; बदले में user की browser settings, cookies, या credentials share नहीं करता। UI भी नहीं दिखाता।³

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

flowchart TB
    accTitle: Interactive apps के लिए WinINET, services के लिए WinHTTP
    accDescr: WinINET signed-in user की Internet Options inherit करता है और service में supported नहीं। WinHTTP बिना UI service account के अधीन चलता है और user की browser settings share नहीं करता
    q{"Interactive desktop ऐप?"}
    q -->|"हाँ"| ie["WinINET"]
    q -->|"Service या service-जैसा"| wh["WinHTTP"]
    ie -.-> ieNote["User की Internet Options पढ़ता है"]
    wh -.-> whNote["Machine settings, कोई UI नहीं"]

चित्र 2: Interactive apps WinINET इस्तेमाल करते हैं। Service WinHTTP इस्तेमाल करती है।

3.2. मूल netsh winhttp संचालन

WinHTTP का machine-default proxy 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 static setting है। न proxy auto-detect, न PAC URL specify करना, न proxy authentication संभालती है।⁴
2. import proxy source=ie उस क्षण की static settings की कॉपी मात्र है; बाद में Internet Options पक्ष के बदलाव नहीं अपनाती। जब PAC या auto-detect सहित per-machine configuration चाहिए, JSON-रूप विस्तृत settings (Proxy, ProxyBypass, AutoconfigUrl, AutoDetect) netsh winhttp set advproxy से configure करें।²

3.3. सबसे आम ख़तरा: Service user की IE settings नहीं पढ़ती

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

1. Developer अपने PC पर उपकरण चलाता है → उसकी per-user proxy settings (1) apply होती है और चलता है
2. Production में उसे LocalSystem के अधीन Windows service (Windows services कैसे बनाएँ और चलाएँ) के रूप में resident छोड़ दिया जाता है
3. LocalSystem से दिखने वाली settings अलग चीज़ है (per-user settings अदृश्य, और WinHTTP machine settings unconfigured = DIRECT) → बाहरी API से सीधा connection आज़माता है और time out होता है

«एक ही मशीन होने पर भी नहीं चलता» नहीं है; एक ही मशीन पर भी, अलग चल रहा account मतलब अलग दिखने वाली proxy settings का सेट। उस process के लिए जो कोई user signed in न हो तब भी communicate करे, सही दृष्टिकोण per-machine settings उस रूप में तैयार करना है जो उस process का HTTP stack वास्तव में पढ़ता है। WinHTTP इस्तेमाल करने वाले native ऐप या Windows component के लिए netsh WinHTTP settings apply होती है।⁴ दूसरी ओर .NET (Core और बाद) पर HttpClient WinHTTP की machine settings नहीं पढ़ता (अध्याय 5 देखें), इसलिए .NET service के लिए system environment variables (HTTPS_PROXY आदि) सेट करें या ऐप settings से HttpClientHandler.Proxy स्पष्ट दें।

दुर्घटना दूसरी दिशा में भी होती है। अगर आप netsh winhttp set proxy से corporate network और बाहर के बीच घूमने वाले laptop में static proxy पका दें, वह proxy कंपनी के बाहर पहुँच से बाहर है और communication पूरी तरह मर जाता है। Machine-static settings को उन servers के साधन के रूप में मानें जिनका network configuration नहीं बदलता।⁴

flowchart TB
    accTitle: Service user की IE settings क्यों नहीं देखती
    accDescr: Developer चलाते समय per-user WinINET settings पढ़ता है और चलता है। LocalSystem के रूप में वे settings अदृश्य हैं। Native WinHTTP ऐप फिर unconfigured machine settings (DIRECT) अपनाता है। .NET Core+ service फिर भी environment variables या स्पष्ट handler.Proxy इस्तेमाल करती है और netsh winhttp पर नहीं जाती
    dev["User के रूप में हाथ से चलाएँ"] --> ok["WinINET per-user settings apply"]
    svc["LocalSystem के रूप में Windows service"] --> miss["Per-user settings अदृश्य"]
    miss --> stack{"कौन सा HTTP stack?"}
    stack -->|"WinHTTP"| direct["WinHTTP unconfigured = DIRECT"]
    stack -->|".NET Core+"| env["Environment variables या handler.Proxy"]
    direct --> fail["बाहरी API time out"]

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

4. PAC और WPAD — «automatic configuration» वास्तव में क्या है

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

PAC (Proxy Auto-Configuration) फ़ाइल JavaScript (ECMAScript) है जो गणना करती है «इस URL के लिए कौन सी proxy इस्तेमाल करें», और उसमें हमेशा FindProxyForURL(url, host) नाम का function होता है। Function इस्तेमाल होने वाली proxy की सूची लौटाता है, या विशेष return मान (DIRECT) जिसका अर्थ है बिना proxy सीधे जुड़ना ठीक है।⁵

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";
}

दो practical परिणाम निकलते हैं।

• Proxy resolution URL के अनुसार करना पड़ता है। क्योंकि PAC URL (host) के अनुसार अलग proxy या सीधा connection लौटा सकता है, WinHTTP की automatic-proxy सुविधा भी request URL पास कर हर बार पूछने के लिए डिज़ाइन है।⁶ «Browser दूसरी site देख सकता है» प्रमाण नहीं कि समस्या API वही path लेती है।
• DIRECT «बिना proxy जाएँ» का निर्देश है। अगर internal होना चाहिए traffic proxy लॉग में कभी न दिखे, पहले संदेह करें कि PAC ने DIRECT लौटाया (या bypass list से match खाया)।

4.2. WPAD के माध्यम से automatic detection

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

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

flowchart TB
    accTitle: PAC URL के अनुसार proxy resolve करता है, WPAD केवल PAC खोजता है
    accDescr: FindProxyForURL URL और host लेता है और proxy सूची या DIRECT लौटाता है। WPAD केवल DHCP या DNS से PAC खोजता है। PAC evaluate न कर पाने वाला client static proxy या environment variables पर गिरता है
    url["Request URL"] --> pac["FindProxyForURL"]
    pac -->|"Proxy सूची"| via["Proxy से जाएँ"]
    pac -->|"DIRECT"| dir["बिना proxy जुड़ें"]
    wpad["DHCP या DNS से WPAD"] -.-> pac
    nopac["Client PAC evaluate नहीं कर सकता"] -.-> fb["Static settings या environment variables"]

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

4.3. PAC evaluate न कर पाने वाले clients कैसे व्यवहार करते हैं

हर client PAC evaluate नहीं कर सकता।

• netsh winhttp set proxy की static setting PAC evaluate नहीं करती।⁴
• HTTP_PROXY environment-variable शैली इस्तेमाल करने वाले tools आमतौर पर केवल static proxy URL लिख सकते हैं (PAC URL लिखने की जगह नहीं)।⁷
• सीधे WinHTTP इस्तेमाल करने वाले native ऐप के लिए यह session कैसे खोला गया इस पर निर्भर करता है। Windows 8.1 और बाद पर WinHttpOpen से WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY specify कर खोला ऐप WinHTTP को system/user proxy settings (WPAD/PAC सहित) per request स्वतः resolve करने देता है।¹⁵ अगर पुराने WINHTTP_ACCESS_TYPE_DEFAULT_PROXY (8.1 से deprecated) आदि से खोला गया, automatic proxy HTTP stack में एकीकृत नहीं, और ऐप को स्वयं WinHttpGetProxyForUrl बुलाना और परिणाम request पर apply करना पड़ता है। दूसरे शब्दों में, पुरानी implementation पर PAC मौजूद होकर भी unused रह सकता है।⁵

«Browser PAC से सही proxy जाता है, पर business app PAC नहीं पढ़ता और सीधा connection आज़माकर fail होता है» — यह एक और मुख्य mismatch है। PAC-driven network पर PAC न पढ़ सकने वाले client के लिए fallback — static settings या environment variables — तय करना पड़ता है।

5. .NET proxy resolution — Framework और Core और बाद अलग चीज़ें हैं

.NET ऐप कौन सी proxy settings पढ़ता है .NET Framework और .NET (Core और बाद) के बीच default भिन्न है। दोनों मिलाएँ तो आप .NET 8 ऐप को Framework-युग ज्ञान से जाँचेंगे और चूकेंगे।

5.1. .NET Framework — Default Internet Options, defaultProxy से override

.NET Framework पर HttpWebRequest और उस पर बैठा HttpClient स्पष्ट Proxy न दें तो default proxy इस्तेमाल करते हैं। Default proxy system Internet settings (चल रहे account की WinINET settings) और configuration फ़ाइल के संयोजन से तय होती है, और configuration-file settings प्राथमिकता लेती हैं।⁸

इस default को app.config (या machine.config) के system.net/defaultProxy element से नियंत्रित कर सकते हैं।⁹

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

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

5.2. .NET (Core और बाद) — पहले environment variables, फिर OS user settings

.NET (Core और बाद) पर HttpClient की static property HttpClient.DefaultProxy है। जब तक handler स्पष्ट proxy न दे, हर HttpClient instance उसे इस्तेमाल करता है। Windows पर initialize नियम है «environment variables पढ़ें, और अगर defined नहीं हैं तो user proxy settings पढ़ें»।⁷

इस्तेमाल environment variables ये हैं।⁷

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

• अगर HTTP_PROXY, HTTPS_PROXY, या ALL_PROXY में कोई defined है, वह OS-पक्ष proxy settings पर प्राथमिकता लेता है। केवल NO_PROXY define करने से environment variables से proxy configure नहीं होती, और Windows पर OS user proxy settings चलती रहती है। पुराने प्रयोग के बाद HTTPS_PROXY system environment variable छोड़ना, या CI/CD template का inject करना, जैसी «अदृश्य settings» दुर्घटनाओं का प्रजनन स्थल हैं।
• NO_PROXY wildcard (*) support नहीं करता। Subdomain मिलाने के लिए अग्रणी बिंदु लगाएँ (.example.com www.example.com से match खाता है पर example.com स्वयं से नहीं)।⁷
• Non-Windows (Linux container आदि) पर अगर environment variables undefined हैं तो बिना proxy initialize होता है। उसी ऐप का default व्यवहार Windows और Linux के बीच बदलना container-migration समय पुष्टि करने योग्य है।⁷

5.3. स्पष्ट specification — HttpClientHandler.Proxy और UseProxy

किसी भी runtime पर सर्वोच्च प्राथमिकता handler पर स्पष्ट specification है। HttpClientHandler.Proxy specify करना OS settings और configuration फ़ाइल पर प्राथमिकता लेता है, और UseProxy = false कोई proxy नहीं इस्तेमाल करता।¹⁴

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);

जब स्पष्ट specification न हो और OS settings अपनाई जाए, local destinations का automatic bypass नियम रखता है। बिना बिंदु का flat नाम, loopback address, मशीन के अपने domain suffix से match खाने वाला destination आदि «local» माने जा सकते हैं।¹⁴ «IP address specify करूँ तो व्यवहार बदलता है» या «FQDN इस्तेमाल करने पर अचानक proxy से जाने लगा» जैसी घटनाएँ इसी निर्णय से हो सकती हैं।

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

flowchart TB
    accTitle: Framework बनाम Core और बाद में default proxy resolution
    accDescr: स्पष्ट HttpClientHandler.Proxy हमेशा जीतता है। Framework फिर app.config defaultProxy और चल रहे account की Internet Options इस्तेमाल करता है। Core और बाद HttpClient.DefaultProxy assignment, फिर environment variables, फिर Windows user proxy settings
    expl["स्पष्ट handler.Proxy"] --> done["वह proxy इस्तेमाल होती है"]
    noexpl["कोई स्पष्ट Proxy नहीं"] --> fw{"कौन सा runtime?"}
    fw -->|"Framework"| cfg["app.config defaultProxy"]
    cfg --> ie["चल रहे account की Internet Options"]
    fw -->|"Core और बाद"| dp["HttpClient.DefaultProxy"]
    dp --> ev["HTTP_PROXY और साथी"]
    ev --> user["Windows user proxy settings"]

चित्र 5: स्पष्ट specification हमेशा जीतता है। Default path runtime के अनुसार भिन्न है।

6. Authenticating proxy — 407 proxy की authentication error है

6.1. 407 को 401 से न मिलाएँ

जब आप authentication माँगने वाले proxy से गुज़रने का प्रयास करें, proxy status code 407 (Proxy Authentication Required) और उपलब्ध schemes सूचीबद्ध करता Proxy-Authenticate header लौटाता है। वह destination server की authentication माँग (401 और WWW-Authenticate) से अलग चीज़ है; credentials किसे दें और उन्हें कहाँ configure करें दोनों भिन्न हैं।¹⁰

flowchart TB
    accTitle: 407 proxy है, 401 destination server है
    accDescr: 407 और Proxy-Authenticate proxy से आते हैं। 401 और WWW-Authenticate destination server से आते हैं। Credentials और configure स्थान भिन्न हैं
    req["Outbound request"] --> who{"कौन authentication माँगता है?"}
    who -->|"Proxy"| e407["407 + Proxy-Authenticate"]
    who -->|"Destination"| e401["401 + WWW-Authenticate"]
    e407 -.-> cred["DefaultProxyCredentials"]

चित्र 6: 407 proxy authentication है। 401 server authentication है।

Scheme में Basic है, जो username और password यथावत् भेजता है, और Negotiate (Kerberos/NTLM) जैसे challenge/response schemes हैं। Challenge/response schemes में password स्वयं network पर नहीं जाता, और authentication कई आदान-प्रदान में पूरा होता है।¹⁰ कौन सी scheme पर «गिरता» है इसका mechanism «आरेखों के साथ NTLM और Kerberos» में विस्तार से है।

6.2. .NET में credentials कैसे दें

जब OS settings से आने वाला default proxy इस्तेमाल करना हो और केवल authentication पार करना हो, HttpClientHandler.DefaultProxyCredentials इस्तेमाल करें। ये वे credentials हैं जो उस default proxy को भेजी जाती हैं जब UseProxy = true और Proxy = null (= system-default proxy)।¹¹

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);

जब proxy स्पष्ट specify करें, credentials WebProxy पक्ष पर रखें। कई client परिदृश्यों में recommendation व्यक्तिगत username और password के बजाय signed-in user की default credentials इस्तेमाल करने की है, और WebProxy.UseDefaultCredentials = true वही है।¹²

6.3. Service-account 407 समस्या

यहाँ भी चल रहा account मायने रखता है। «Default credentials» का अर्थ है उस process को चलाने वाले account की credentials। Interactive user के रूप में चलाएँ तो proxy authentication उस user के रूप में है; LocalSystem service के रूप में चलाएँ तो computer account के रूप में।

• अगर proxy Active Directory से users को authenticate कर रहा है, computer account या local account authenticate नहीं कर सकता, और ऐप service बनते ही 407 जारी रहता है
• उलटा, कुछ environments में services के लिए proxy पक्ष पर authentication exemption है (source IP या account से)

इसलिए 407 जाँच «ऐप की settings» पर अकेले बंद नहीं होती; यह infrastructure पक्ष की डिज़ाइन जाँच के साथ सेट है: क्या proxy चल रहे account को authenticate कर सकता है। Service बनने वाले ऐप के लिए डिज़ाइन समय तय करें: domain service account (gMSA आदि) के अधीन चलाएँ, proxy पक्ष पर authentication exemption दें, या authentication न माँगने वाला internal relay proxy खड़ा करें।

HTTP_PROXY=http://user:pass@proxy:8080 जैसा environment variable में credentials embed करने की शैली भी है⁷, पर तब स्पष्ट पाठ password environment variable (= process जानकारी) में खुला है, इसलिए स्थायी संचालन के लिए recommended नहीं।

7. HTTPS और proxy — CONNECT tunnel और TLS inspection

7.1. HTTPS proxy से «tunnel» के रूप में जाता है

HTTPS के लिए proxy इस्तेमाल करें तो client पहले proxy को CONNECT destination-host:443 request भेजता है, और proxy TCP tunnel खोलता है। सफलता पर proxy 200 लौटाता है, और उसके बाद client और destination server उस tunnel के भीतर TLS handshake करते हैं। अगर tunnel न खुले, proxy 407 (authentication आवश्यक), 502, आदि लौटाता है।¹⁶

इस model में proxy tunnel की content (encrypted HTTPS) नहीं पढ़ सकता। Proxy लॉग में destination host name और connection सफल हुआ या नहीं रह जाता है; URL path दिखाई नहीं देता — यही «pass-through» proxy का व्यवहार है।

flowchart TB
    accTitle: Proxy से HTTPS CONNECT tunnel है
    accDescr: Client proxy को CONNECT भेजता है, proxy TCP tunnel खोलकर 200 लौटाता है, फिर client और destination tunnel के भीतर TLS handshake करते हैं। Proxy लॉग host देखता है, URL path नहीं
    cli["Client"] -->|"CONNECT host:443"| px["Proxy"]
    px -->|"200 और TCP tunnel"| dest["Destination"]
    dest -->|"Tunnel के भीतर TLS"| cli
    px -.-> log["लॉग: केवल host और सफलता"]

चित्र 7: Pass-through proxy host देखता है, encrypted path नहीं।

7.2. TLS-inspection proxy और certificate errors

दूसरी ओर security-product proxy में TLS-inspection (SSL decryption, break and inspect) प्रकार है जो TLS terminate करता है, content जाँचता है, और forward करने से पहले re-encrypt करता है। इस योजना में client को दिखाया server certificate वास्तविक नहीं; proxy के अपने CA से re-signed certificate से बदला जाता है।¹³

इसलिए यह configuration टिके यह आधार है कि «proxy का CA certificate हर client के Trusted Root में distribute हो»। जिसे वह नहीं मिला, या जो runtime Windows certificate store नहीं देखता (अपने trust store वाले tools), certificate-validation error पाते हैं। .NET में यह आमतौर पर AuthenticationException लपेटे HttpRequestException के रूप में सतह पर आता है («the remote certificate is invalid» तरह का संदेश)।

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

• Internal CA certificate local computer के «Trusted Root Certification Authorities» store में distribute करें। User store और computer store का विभाजन «व्यवहार में Windows certificate store» में है।
• Code में certificate validation बंद न करें। ServerCertificateCustomValidationCallback से हमेशा true लौटाने वाला workaround बाहरी network पर जाते ही man-in-the-middle न पकड़ सकने वाला कमज़ोर ऐप बन जाता है।
• Certificate-pinned traffic पहले स्थान पर inspect नहीं हो सकता। कुछ Windows components जैसे विशिष्ट Microsoft certificates validate करने वाले connections proxy certificate बदलते ही fail होते हैं, और exemption के अलावा कोई workaround नहीं।⁴ Microsoft 365 जैसे SaaS के destination traffic के लिए Microsoft स्वयं network-layer decryption और inspection से exemption की recommendation करता है।¹³

«हर internal site दिखती है, पर केवल विशेष cloud service ऐप में certificate error देती है» लक्षण पहले TLS-inspection exemption list और pinning के संयोजन का संदेह कराए।

flowchart TB
    accTitle: TLS-inspection proxy certificate re-sign करता है
    accDescr: Proxy TLS terminate करता है, content जाँचता है, और अपने CA से re-signed certificate दिखाता है। Validation तभी टिकता है जब वह CA Trusted Root में हो। Code में validation बंद न करें
    real["वास्तविक server certificate"] --> px["TLS-inspection proxy"]
    px --> fake["Proxy CA से re-signed"]
    fake --> client["Client validation"]
    client -->|"CA Trusted Root में"| ok["सफल"]
    client -->|"CA अनुपस्थित"| err["Certificate error"]
    err -.-> fix["CA store में distribute करें"]

चित्र 8: Inspection केवल internal CA distribute करने के साथ सेट के रूप में काम करता है।

8. Isolation procedure — अपराधी पहचानने के पाँच चरण

«जुड़ नहीं सकता» को इस क्रम में यंत्रवत जाँचें।

(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'

कुछ practical सुझाव।

• (1) के reproduction परीक्षण में जागरूक रहें कि उपकरण कौन सा setting family पढ़ता है। Windows-inbox curl.exe -x http://proxy:8080 से proxy स्पष्ट specify कर सकता है, और TLS validation के लिए सामान्यतः OS certificate store (Schannel) इस्तेमाल करता है। Windows PowerShell 5.1 का Invoke-WebRequest .NET Framework पक्ष (default Internet Options) अपनाता है; PowerShell 7 .NET पक्ष (पहले environment variables) अपनाता है। «curl चलता है पर ऐप नहीं» स्वयं configuration families के बीच mismatch का संकेत है।
• अगर (3) का लक्ष्य service है, service के समान account के अधीन (1) और (2) फिर जाँचें। Admin के अपने session में जाँच LocalSystem जो देखता है उसका प्रमाण नहीं।
• (4) के error वर्गीकरण में 407 के लिए अध्याय 6 (authentication) पहला उम्मीदवार लें, certificate error के लिए अध्याय 7 (TLS inspection), और timeout के लिए «proxy तक पहुँचा ही नहीं» (path, name resolution, firewall)। कारण proxy के बजाय Windows Firewall inbound rules हो उस pattern को «Windows Firewall और business applications» cover करता है।
• अगर (5) तक पहुँचें और proxy लॉग में अभी भी कोई निशान न हो, traffic proxy तक कभी नहीं पहुँचा। PAC का DIRECT निर्णय, bypass list, या बचा environment variable संदेह करें, और आवश्यकता हो तो packet capture से वास्तविक destination पुष्टि करें («Windows पर practically packet capture — pktmon, netsh trace, और Wireshark में से चुनना»)।

flowchart TB
    accTitle: Proxy failure अलग करने के पाँच चरण
    accDescr: उसी account के अधीन reproduce करें, settings के तीन families संग्रहें, चल रहे account की पहचान करें, error वर्गीकृत करें, फिर proxy लॉग जाँचें
    s1["curl से reproduce करें"] --> s2["तीन families संग्रहें"]
    s2 --> s3["Account पहचानें"]
    s3 --> s4["Error वर्गीकृत करें"]
    s4 --> s5["Proxy लॉग जाँचें"]
    s4 -.-> e407["407: Authentication"]
    s4 -.-> ecert["Certificate error: inspection"]
    s4 -.-> eto["Timeout: कभी नहीं पहुँचा"]

चित्र 9: पाँच चरण क्रम से चलें। Error वर्ग अगला अध्याय चुनता है।

9. डिज़ाइन recommendation — ऐप ऐसा बनाएँ जिस पर «proxy configure कर सकें»

जाँच procedure पलटें तो वह ऐप पक्ष की डिज़ाइन guide बन जाती है। Corporate proxy वाले environment में पहुँचाने वाले Windows ऐप के लिए निम्नलिखित recommended है।

1. ऐप settings से proxy configure करने योग्य बनाएँ। Default «OS settings अपनाएँ» है। ज़्यादातर environments में default काफ़ी है; केवल असाधारण environments — PAC पढ़ा नहीं जा सकता, service के रूप में चलता है, विशेष proxy configuration — में settings फ़ाइल से proxy URL, bypass list, और «proxy इस्तेमाल न करें» specify संभव बनाएँ। धारा 5.3 का HttpClientHandler.Proxy / UseProxy implementation बिंदु है।¹⁴
2. लिखें कि internal destinations (API, database, license server आदि) proxy exception के रूप में कैसे व्यवहारित होते हैं। Deployment procedure में लिख सकें उस रूप में रखें कि वे PAC DIRECT, bypass list, या NO_PROXY से छूटे हैं। NO_PROXY match नियम (कोई wildcard नहीं, अग्रणी बिंदु का अर्थ) व्यापक रूप से गलत समझे जाते हैं, इसलिए उदाहरण लगाएँ।⁷
3. Proxy से गुज़रने की धारणा पर timeout और retry डिज़ाइन करें। अगर proxy down हो या authentication पर अटका हो, लंबी default timeout पर प्रतीक्षा करने वाली implementation UI और संचालन दोनों जमा देती है। छोटा connect timeout अलग करें, और retry idempotent requests तक सीमित करें (डिज़ाइन विवरण «HttpClient को using ब्लॉक में न लपेटें» में)।
4. लॉग करें «कौन सी proxy इस्तेमाल हुई»। ऐप स्वयं failure जाँच का पहला प्रश्न उत्तर दे सके।

(4) जैसा लॉग अगर केवल resolution परिणाम record करे तो पहले से प्रभावी है। बिंदु यह है कि path उस setting (handler) से व्युत्पन्न करें जिससे आपने वास्तव में client configure किया। अगर सीधे HttpClient.DefaultProxy लॉग करें, जब handler स्पष्ट Proxy दे या UseProxy = false सेट करे तो वास्तविक path से असहमत मान record होगा।

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);

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

flowchart TB
    accTitle: Proxy configure करने योग्य बनाएँ और path लॉग करें
    accDescr: Default OS settings अपनाना है, ऐप settings से स्पष्ट proxy URL या bypass या बिना-proxy allow करें, और वास्तव में इस्तेमाल path चल रहे account के साथ लॉग करें
    def["Default: OS settings अपनाएँ"] --> exc{"असाधारण environment?"}
    exc -->|"PAC unread / service / विशेष"| cfg["URL, bypass, या बिना proxy सेट करें"]
    exc -->|"सामान्य मामला"| os["OS default इस्तेमाल करें"]
    cfg --> log["Path और account लॉग करें"]
    os --> log

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

10. सारांश

• Windows proxy settings तीन families में बँटती है — WinINET per-user settings, WinHTTP machine settings, और environment variables — और कौन पढ़ा जाता है ऐप (उसके HTTP stack) और चल रहे account से तय होता है।
• WinINET interactive apps के लिए है और service में उपयोग supported नहीं; service उपयोग WinHTTP का काम है (netsh winhttp)। «हाथ से चलता है पर service के रूप में नहीं» के लिए पहले चल रहे account का अंतर संदेह करें।
• netsh winhttp set proxy static setting है और PAC, automatic detection, या authentication नहीं संभालती। PAC-driven network पर PAC न पढ़ सकने वाले client का व्यवहार तय करना पड़ता है।
• PAC का FindProxyForURL URL के अनुसार proxy या DIRECT लौटाता है। WPAD केवल उस network पर काम करता है जहाँ DHCP/DNS व्यवस्था है।
• .NET Framework का default चल रहे account की Internet Options है (defaultProxy से override); .NET (Core और बाद) environment variables फिर user proxy settings है। स्पष्ट specification (HttpClientHandler.Proxy) हमेशा सर्वोच्च प्राथमिकता है।
• 407 proxy-authentication error है; service account के अधीन चलने वाले ऐप में विशिष्ट कारण यह है कि «default credentials» अलग व्यक्ति बन जाती हैं।
• TLS-inspection proxy internal CA certificate distribution मानता है, और certificate error का सही उत्तर validation बंद करना नहीं, store में distribution है। Pinned traffic exemption चाहता है।
• «Reproduce करें → तीन families की settings संग्रहें → चल रहा account पहचानें → error वर्गीकृत करें → proxy लॉग» क्रम में यंत्रवत अलग करें। ऐप पक्ष पर «proxy configure कर सके, और इस्तेमाल path लॉग करे» डिज़ाइन सबसे अच्छा निवारण है।

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

वह ऐप किसके account के अधीन चल रहा है, और proxy settings के तीन families में से कौन पढ़ता है?

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

संबंधित लेख

• HttpClient को using ब्लॉक में न लपेटें — C# business apps में practical HTTP communication (निर्माण patterns, timeout, retry)
• Windows पर practically packet capture — pktmon, netsh trace, और Wireshark में से चुनना
• Windows Firewall और business applications — installer से inbound rules register करें
• Windows services कैसे बनाएँ और चलाएँ ── Task Scheduler और services के बीच चुनाव से BackgroundService को Windows service बनाना
• आरेखों के साथ NTLM और Kerberos — authentication NTLM पर क्यों गिरता है
• Practically Windows certificate store — user या computer, कौन इस्तेमाल करें?

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

KomuraSoft LLC corporate-proxy, authenticating-proxy, और TLS-inspection environments पर Windows-ऐप communication परेशानी की जाँच संभालता है — «development मशीन पर चलता है पर customer network पर communicate नहीं कर सकता», «service बनाने के बाद बाहरी API तक नहीं पहुँच सका» — और proxy environment मानकर business-ऐप communication डिज़ाइन पर परामर्श (settings आइटम, timeout, लॉग डिज़ाइन)। Reproduction चरण और लॉग कैसे संग्रहें व्यवस्थित करने से शुरू करना ठीक है।

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

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

Browser जुड़ जाता है, पर केवल business app corporate proxy पार नहीं कर पाता। क्यों?

Browser WinINET की per-user proxy settings पढ़ता है, पर business app वही settings नहीं पढ़ता। Windows service के रूप में, या दूसरे account के अधीन चलने वाला ऐप उस account से दिखने वाली settings, WinHTTP की machine settings, या environment variables देखता है। पहले चल रहे account की पहचान करें, फिर उसी account से दिखने वाली proxy settings netsh winhttp show proxy और user settings दोनों में जाँचें। अगर उसी मशीन पर उसी account से curl.exe आदि से reproduce हो, तो इसे ऐप-विशिष्ट समस्या नहीं, configuration families के बीच mismatch मानें।

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

netsh winhttp जो सेट करता है वह WinHTTP का machine default है। यह browser या interactive ऐप जो WinINET पढ़ते हैं, या .NET (Core और बाद) HttpClient जो environment variables को प्राथमिकता देता है, को प्रभावित नहीं करता। netsh winhttp set proxy static setting भी है; PAC auto-configuration, automatic detection, या proxy authentication नहीं संभालता। पहले पुष्टि करें कि target ऐप कौन सा HTTP stack इस्तेमाल करता है और किस configuration family से proxy resolve करता है।

.NET ऐप कौन सी proxy settings पढ़ता है?

.NET Framework default रूप से चल रहे account की Internet Options (WinINET-equivalent) settings इस्तेमाल करता है, और app.config के system.net/defaultProxy element से override किया जा सकता है। .NET (Core और बाद) पर HttpClient पहले HTTP_PROXY, HTTPS_PROXY और NO_PROXY जैसे environment variables पढ़ता है, और अगर defined नहीं हैं तो Windows user proxy settings पर गिरता है। दोनों मामलों में स्पष्ट HttpClientHandler.Proxy प्राथमिकता लेता है। Default resolution क्रम Framework और Core और बाद के बीच भिन्न है, इसलिए migrate करते समय proxy व्यवहार फिर जाँचें।

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

407 संकेत है कि proxy स्वयं authentication माँग रहा है; यह destination-server authentication error (401) से अलग है। पहले Proxy-Authenticate header से proxy जिस scheme की माँग कर रहा है (Negotiate, NTLM, Basic) पुष्टि करें, और .NET में HttpClientHandler.DefaultProxyCredentials या WebProxy.UseDefaultCredentials से credentials दें। Service account के अधीन चलने वाले ऐप में «default credentials» उसी service account की हो जाती हैं, इसलिए विशिष्ट घटना यह है कि interactive user के लिए काम करे और service बनते ही 407 दे। Proxy-side लॉग में भी देखें कि उसने किसके रूप में authenticate किया।

TLS-inspection proxy certificate errors पैदा करता है। क्या certificate validation बंद करूँ?

बंद करना recommended नहीं है। TLS-inspection proxy traffic decrypt करता है फिर client को अपने CA से re-signed certificate दिखाता है, इसलिए अगर वह CA certificate Trusted Root में नहीं है तो validation fail होता है। सही समाधान internal CA certificate को Windows certificate store (आमतौर पर local computer के Trusted Root Certification Authorities) में distribute करना है। Code में validation बंद करने का मतलब है कि बाहरी network पर ऐप इस्तेमाल होने पर man-in-the-middle attack पकड़ा नहीं जा सकता, और कमज़ोरी रहती है।

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

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

Go Komura

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

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