यदि आपकी कंपनी कॉर्पोरेट प्रॉक्सी के माध्यम से आउटगोइंग ट्रैफिक को बंद करती है, तो Cursor और Claude Code जैसे AI सहायक
बस जवाब देना बंद कर देते हैं: ऑटो-कंप्लीशन लटक जाता है, CLI ETIMEDOUT
या SSL certificate problem दिखाता है।
आइए समझते हैं कि HTTPS_PROXY परिवर्तनीयों को सही तरीके से कैसे सेट करें,
प्रमाणीकरण कैसे सेट करें और सामान्य त्रुटियों से कैसे बचें, जिनके कारण डेवलपर्स नेटवर्क सेटिंग्स के डिबगिंग में घंटे बर्बाद करते हैं।
कॉर्पोरेट नेटवर्क में AI सहायक के लिए प्रॉक्सी की आवश्यकता क्यों है
Cursor और Claude Code स्थानीय मॉडल नहीं हैं। वे लगातार बाहरी API से संपर्क करते हैं: Cursor अपने कोड इंडेक्सिंग सर्वरों और मॉडल के API (OpenAI, Anthropic, Google, चुने गए प्रदाता के आधार पर) से संपर्क करता है, जबकि Claude Code — सीधे HTTPS के माध्यम से Anthropic API से। कॉर्पोरेट नेटवर्क में इंटरनेट तक सीधी पहुंच अक्सर फ़ायरवॉल द्वारा बंद होती है, और सभी आउटगोइंग ट्रैफिक को प्रॉक्सी सर्वर (Squid, Zscaler, Blue Coat, Fortinet FortiProxy या आंतरिक कॉर्पोरेट गेटवे) के माध्यम से जाना चाहिए। बिना सही तरीके से सेट किए गए परिवर्तनीयों के, एप्लिकेशन को यह पता नहीं होता है कि ट्रैफिक को प्रॉक्सी के माध्यम से मोड़ना है, और यह सीधे इंटरनेट से संपर्क करने की कोशिश करता है — टाइम-आउट प्राप्त करता है।
एक अलग जटिलता यह है कि Cursor Electron पर आधारित है (यह मूल रूप से Chromium + Node.js है), जबकि Claude Code —
Node.js CLI एप्लिकेशन है। प्रत्येक की प्रॉक्सी सेटिंग्स पढ़ने की अपनी लॉजिक है: Electron आंशिक रूप से सिस्टम सेटिंग्स को विरासत में लेता है
OS की, जबकि Node.js प्रक्रियाएँ सीधे या undici और node-fetch जैसी पुस्तकालयों के माध्यम से HTTP_PROXY/HTTPS_PROXY परिवर्तनीय पढ़ते हैं।
यही भ्रम पैदा करता है: सेटिंग्स लिखी गई हैं, लेकिन उपकरण उन्हें "नहीं देखता"।
HTTP_PROXY, HTTPS_PROXY और NO_PROXY परिवर्तनीय: यह कैसे काम करता है
कंसोल Node.js, Python और Go एप्लिकेशनों के लिए प्रॉक्सी निर्दिष्ट करने का पारंपरिक तरीका परिवर्तनीयों के माध्यम से है। HTTP_PROXY और HTTPS_PROXY के बीच का अंतर मौलिक है: पहला HTTP प्रोटोकॉल के लिए अनुरोधों के लिए उपयोग किया जाता है, दूसरा HTTPS अनुरोधों के लिए (और लगभग सभी AI सहायक का ट्रैफिक वास्तव में HTTPS के माध्यम से जाता है)। दोनों को निर्दिष्ट करना चाहिए, भले ही वास्तविक ट्रैफिक केवल HTTPS हो — कुछ पुस्तकालय शुरू में सेवा HTTP अनुरोध करते हैं।
export HTTP_PROXY="http://proxy.company.local:8080" export HTTPS_PROXY="http://proxy.company.local:8080" export NO_PROXY="localhost,127.0.0.1,.company.local"
ध्यान दें: यहां तक कि HTTPS ट्रैफिक के लिए, प्रॉक्सी के पते में स्कीमा http:// के रूप में निर्दिष्ट किया जाता है,
न कि https:// —
यह प्रॉक्सी सर्वर का पता है, न कि लक्ष्य संसाधन का। HTTP के माध्यम से प्रॉक्सी से कनेक्शन सामान्य है, अंत सर्वर तक एन्क्रिप्शन
फिर भी CONNECT टनलिंग तंत्र के माध्यम से काम करता है।
NO_PROXY
export http_proxy="$HTTP_PROXY" export https_proxy="$HTTPS_PROXY" export no_proxy="$NO_PROXY"
Cursor के लिए प्रॉक्सी सेटअप
Cursor आंशिक रूप से OS की सिस्टम प्रॉक्सी सेटिंग्स का उपयोग करता है (विशेष रूप से macOS और Windows पर), लेकिन कॉर्पोरेट नेटवर्क में स्थिरता के लिए इसे स्पष्ट रूप से परिवर्तनीयों के माध्यम से सेट करना बेहतर है और, यदि आवश्यक हो, एप्लिकेशन की कॉन्फ़िगरेशन फ़ाइल के माध्यम से।
macOS और Linux पर सबसे आसान तरीका है कि आप शेल प्रोफ़ाइल फ़ाइल में परिवर्तनीयों को निर्यात करें, ताकि वे हर बार टर्मिनल के लॉन्च के समय उठाए जाएँ, जिससे Cursor शुरू होता है:
# ~/.zshrc या ~/.bash_profile export HTTP_PROXY="http://user:[email protected]:8080" export HTTPS_PROXY="http://user:[email protected]:8080" export NO_PROXY="localhost,127.0.0.1,*.company.local"
प्रोफ़ाइल फ़ाइल में परिवर्तन करने के बाद, source ~/.zshrc
चलाएँ और Cursor को पूरी तरह से पुनः प्रारंभ करें (सिर्फ विंडो को कम न करें — प्रक्रिया को Activity Monitor या टास्क मैनेजर के माध्यम से समाप्त करें, क्योंकि Electron एप्लिकेशन स्टार्टअप पर वातावरण को कैश करते हैं)।
Windows पर परिवर्तनीयों को सिस्टम पर्यावरण सेटिंग्स के माध्यम से सेट करना अधिक सुविधाजनक है (Control Panel → System → Advanced system settings → Environment variables) या PowerShell के माध्यम से स्थायी रूप से:
[System.Environment]::SetEnvironmentVariable('HTTPS_PROXY','http://user:[email protected]:8080','User')
[System.Environment]::SetEnvironmentVariable('HTTP_PROXY','http://user:[email protected]:8080','User')
[System.Environment]::SetEnvironmentVariable('NO_PROXY','localhost,127.0.0.1','User')
यदि इसके बाद भी Cursor API मॉडल से कनेक्ट नहीं होता है, तो एप्लिकेशन के भीतर प्रॉक्सी सेटिंग्स की जांच करें: Settings → Network (या General) — वहाँ प्रॉक्सी URL का एक अलग फ़ील्ड हो सकता है, जो सिस्टम परिवर्तनीयों को ओवरराइड करता है। कुछ Cursor बिल्ड में "Use system proxy settings" विकल्प को स्पष्ट रूप से सक्षम करना भी आवश्यक है।
Claude Code के लिए प्रॉक्सी सेटअप
Claude Code एक Node.js पर आधारित CLI उपकरण है, जिसे npm/npx के माध्यम से चलाया जाता है, इसलिए यह सीधे टर्मिनल सत्र से परिवर्तनीयों को पढ़ता है, जिसमें इसे कॉल किया गया था। यह सेटअप को सरल बनाता है: शुरू करने से पहले परिवर्तनीयों को निर्यात करना पर्याप्त है।
export HTTPS_PROXY="http://user:[email protected]:8080" export HTTP_PROXY="http://user:[email protected]:8080" claude
यदि आप Claude Code को CI पाइपलाइन का हिस्सा या स्क्रिप्ट से चला रहे हैं, तो लॉन्च कमांड में परिवर्तनीयों को स्पष्ट रूप से पास करें, ताकि ग्लोबल शेल वातावरण पर निर्भरता से बचा जा सके:
HTTPS_PROXY="http://proxy.company.local:8080" \ HTTP_PROXY="http://proxy.company.local:8080" \ claude --print "प्रोजेक्ट में परीक्षण करें"
स्थायी कॉन्फ़िगरेशन के लिए, परिवर्तनीयों को .env
फ़ाइल में प्रोजेक्ट की जड़ में फिक्स करना अधिक सुविधाजनक है और इसे direnv
या अंतर्निहित dotenv समर्थन के माध्यम से उठाया जा सकता है, यदि आपका शेल इसका समर्थन करता है। यह विशेष रूप से सुविधाजनक है जब विभिन्न प्रोजेक्ट्स को
विभिन्न प्रॉक्सी सेटिंग्स की आवश्यकता होती है (उदाहरण के लिए, एक प्रोजेक्ट आंतरिक API के साथ काम करता है, जबकि दूसरा बाहरी सेवाओं के साथ)।
कॉर्पोरेट प्रॉक्सी पर प्रमाणीकरण
अधिकांश कॉर्पोरेट प्रॉक्सी प्रमाणीकरण की आवश्यकता होती है — Basic Auth, Digest या NTLM। Basic Auth के लिए
लॉगिन और पासवर्ड को सीधे प्रॉक्सी के URL में एम्बेड किया जा सकता है, जैसा कि ऊपर दिखाया गया है: http://user:[email protected]:8080.
महत्वपूर्ण बिंदु — यदि पासवर्ड में विशेष वर्ण हैं (@, #, %),
उन्हें URL-कोड करना आवश्यक है, अन्यथा प्रॉक्सी स्ट्रिंग का पार्सर लॉगिन और होस्ट की सीमा पर टूट जाएगा।
# यदि पासवर्ड P@ssw0rd#2024 है, तो विशेष वर्णों को कोड करें: # @ -> %40, # -> %23 export HTTPS_PROXY="http://user:P%40ssw0rd%[email protected]:8080"
NTLM प्रमाणीकरण के साथ अधिक जटिलता है (जो अक्सर Microsoft ISA Server, Forefront TMG या Fortinet के साथ उपयोग किया जाता है) —
Node.js और अधिकांश HTTP क्लाइंट NTLM "बॉक्स से बाहर" का समर्थन नहीं करते हैं। इस मामले में, मानक समाधान —
एक स्थानीय प्रॉक्सी इंटरमीडियरी स्थापित करना है, जो NTLM हैंडशेक को संभालता है, और फिर एप्लिकेशन के लिए "स्वच्छ" HTTP प्रॉक्सी देता है। इसके लिए अक्सर cntlm या px (Python पर स्थानीय NTLM प्रॉक्सी) का उपयोग किया जाता है।
योजना सरल है: Cursor/Claude Code → localhost:3128 (cntlm) → कॉर्पोरेट NTLM प्रॉक्सी → इंटरनेट।
# cntlm (/etc/cntlm.conf) का कॉन्फ़िगरेशन उदाहरण Username your_login Domain COMPANY Password आपका_पासवर्ड_या_हैश Proxy proxy.company.local:8080 Listen 3128 # cntlm शुरू करने के बाद, स्थानीय पते को निर्दिष्ट करें: export HTTPS_PROXY="http://127.0.0.1:3128" export HTTP_PROXY="http://127.0.0.1:3128"
प्रमाणपत्र और MITM: कॉर्पोरेट नेटवर्क में SSL समस्या
यदि कंपनी में Zscaler, Netskope या किसी अन्य SSL निरीक्षण के साथ वेब फ़िल्टर का उत्पाद तैनात है,
तो ट्रैफिक प्रॉक्सी पर डिक्रिप्ट किया जाता है और कॉर्पोरेट रूट CA प्रमाणपत्र द्वारा हस्ताक्षरित होता है। Node.js (और इसका मतलब है कि
Claude Code और Cursor के अधिकांश आंतरिक मॉड्यूल) डिफ़ॉल्ट रूप से केवल अपने अंतर्निहित रूट प्रमाणपत्रों के सेट पर भरोसा करता है
और UNABLE_TO_VERIFY_LEAF_SIGNATURE या
self signed certificate in certificate chain त्रुटि फेंकता है।
समाधान — कॉर्पोरेट CA प्रमाणपत्र को निर्यात करना (आमतौर पर इसे IT विभाग से प्राप्त किया जा सकता है या ब्राउज़र के प्रमाणपत्र भंडार से निकाला जा सकता है) और Node.js को इसके लिए पथ निर्दिष्ट करना NODE_EXTRA_CA_CERTS के माध्यम से:
export NODE_EXTRA_CA_CERTS="/etc/ssl/certs/company-root-ca.pem"
प्रमाणपत्रों की जांच को वैश्विक रूप से NODE_TLS_REJECT_UNAUTHORIZED=0 के माध्यम से बंद करना अत्यधिक अनुशंसित नहीं है —
यह पूरे प्रक्रिया पर MITM हमलों से सुरक्षा को हटा देता है, जिसमें वैध कनेक्शन भी शामिल हैं। इस ध्वज का उपयोग केवल
एक बार के निदान के लिए करें और सुरक्षा को वापस लौटाना सुनिश्चित करें।
सामान्य त्रुटियाँ और उनका समाधान
| त्रुटि | कारण | समाधान |
|---|---|---|
| ETIMEDOUT / ECONNREFUSED | प्रॉक्सी परिवर्तनीय उस सत्र में निर्यात नहीं किए गए हैं, जहां एप्लिकेशन चल रहा है | समान टर्मिनल में echo $HTTPS_PROXY की जांच करें, एप्लिकेशन को पूरी तरह से पुनः प्रारंभ करें |
| 407 Proxy Authentication Required | लॉगिन/पासवर्ड निर्दिष्ट नहीं किए गए हैं या पुरानी हो गई हैं | प्रॉक्सी स्ट्रिंग में क्रेडेंशियल्स को अपडेट करें, पासवर्ड के विशेष वर्णों को URL-कोड करें |
| self signed certificate in certificate chain | कॉर्पोरेट MITM प्रॉक्सी प्रमाणपत्र को बदल देती है | कॉर्पोरेट रूट CA के साथ NODE_EXTRA_CA_CERTS निर्दिष्ट करें |
| प्रॉक्सी टर्मिनल में काम करता है, लेकिन Cursor में नहीं | Cursor उसी टर्मिनल से नहीं चलाया गया है या बिना वातावरण के शॉर्टकट के माध्यम से | Cursor को निर्यात किए गए परिवर्तनीयों के साथ टर्मिनल से कमांड द्वारा चलाएँ, या परिवर्तनीयों को सिस्टम में वैश्विक रूप से लिखें |
| NTLM authentication failed | क्लाइंट NTLM हैंडशेक का समर्थन नहीं करता है | एप्लिकेशन और कॉर्पोरेट प्रॉक्सी के बीच मध्यवर्ती प्रॉक्सी cntlm या px स्थापित करें |
curl के माध्यम से कनेक्शन की जांच
यह समझने से पहले कि Cursor या Claude Code क्यों काम नहीं कर रहा है, सुनिश्चित करें कि प्रॉक्सी वास्तव में उपलब्ध है और सही तरीके से HTTPS ट्रैफिक को प्रॉक्सी करता है। इसके लिए curl का उपयोग करें — यह वही परिवर्तनीय पढ़ता है और बिना भारी एप्लिकेशनों को चलाए समस्या को जल्दी से स्थानीयकृत करने की अनुमति देता है।
# प्रॉक्सी और प्रमाणीकरण की उपलब्धता की जांच curl -v -x "http://user:[email protected]:8080" https://api.anthropic.com # कॉर्पोरेट प्रमाणपत्र को ध्यान में रखते हुए जांच curl -v --cacert /etc/ssl/certs/company-root-ca.pem \ -x "http://user:[email protected]:8080" \ https://api.anthropic.com
यदि curl सफलतापूर्वक प्रतिक्रिया प्राप्त करता है (यहां तक कि 401 या 403 — यह सामान्य है, इसका मतलब है कि TLS हैंडशेक सफल हुआ), और Claude Code फिर भी कनेक्ट नहीं होता है — समस्या नेटवर्क में नहीं है, बल्कि इस बात में है कि प्रक्रिया परिवर्तनीयों को नहीं देखती है। यदि curl भी प्रमाणपत्र त्रुटि या टाइम-आउट के साथ गिरता है — समस्या नेटवर्क या प्रॉक्सी स्तर पर है, और उपकरणों का इसमें कोई हाथ नहीं है।
कब कॉर्पोरेट के बजाय बाहरी प्रॉक्सी की आवश्यकता होती है
कभी-कभी कार्य केवल कॉर्पोरेट नेटवर्क से बाहर जाने तक सीमित नहीं होता है। डेवलपर्स जो भू-निर्भर API के साथ एकीकरण का परीक्षण करते हैं, विभिन्न देशों से सेवा के व्यवहार की जांच करते हैं या प्रदाताओं की मॉडल के लिए दर-सीमा नीतियों को डिबग करते हैं, यह देखते हैं कि कॉर्पोरेट प्रॉक्सी सभी अनुरोधों के लिए एक ही कॉर्पोरेट IP देती है। ऐसे परिदृश्यों में, परीक्षण ट्रैफिक को मुख्य कार्य वातावरण के साथ समानांतर में बाहरी प्रॉक्सी के माध्यम से भेजना सुविधाजनक होता है।
स्थिर दीर्घकालिक परीक्षण सत्रों के लिए, जिनमें IP द्वारा ब्लॉक होने का न्यूनतम जोखिम होता है, रेसिडेंशियल प्रॉक्सी उपयुक्त होती हैं — वे घरेलू प्रदाताओं के वास्तविक IP पते का उपयोग करती हैं और सामान्य उपयोगकर्ता ट्रैफिक की तरह दिखती हैं, जो API के भू-विशिष्ट उत्तरों की जांच करते समय महत्वपूर्ण है। यदि मोबाइल क्लाइंट के व्यवहार को पुन: उत्पन्न करने या नेटवर्क प्रकार के प्रति संवेदनशील परिदृश्यों का परीक्षण करने की आवश्यकता है, तो मोबाइल प्रॉक्सी पर विचार करना चाहिए। और सार्वजनिक API के लिए बड़े पैमाने पर समानांतर परीक्षण अनुरोधों के लिए, जहां गति और ट्रैफिक की लागत महत्वपूर्ण होती है, न कि सामान्य उपयोगकर्ता के रूप में छिपाने के लिए, आमतौर पर डेटा सेंटर प्रॉक्सी पर्याप्त होती है।
महत्वपूर्ण: ऐसा बाहरी प्रॉक्सी ठीक उसी तरह सेट किया जाता है जैसे HTTPS_PROXY/HTTP_PROXY के माध्यम से,
लेकिन परीक्षण वातावरण या अलग टर्मिनल प्रोफ़ाइल के लिए, ताकि इसे कॉर्पोरेट गेटवे के माध्यम से मुख्य कार्य ट्रैफिक के साथ मिश्रित न किया जाए। यदि कॉर्पोरेट नीति यह मांग करती है कि कंपनी का सभी ट्रैफिक केवल आंतरिक प्रॉक्सी के माध्यम से जाए,
तो बाहरी का उपयोग IT/Security के साथ समन्वयित होना चाहिए — कई कंपनियाँ बिना अनुमति के कॉर्पोरेट गेटवे को बायपास करने की अनुमति नहीं देती हैं।
सेटअप चेकलिस्ट
- दोनों परिवर्तनीयों को निर्यात किया गया है:
HTTP_PROXYऔरHTTPS_PROXY(दोनों केस में) -
NO_PROXYमें आंतरिक डोमेन और localhost सूचीबद्ध हैं - पासवर्ड में विशेष वर्ण URL-कोड किए गए हैं
- एप्लिकेशन पूरी तरह से पुनः प्रारंभ किया गया है, न कि केवल विंडो को कम/बढ़ाया गया है
- एप्लिकेशन के समान परिवर्तनीयों के साथ curl अनुरोध की जांच की गई है
- यदि MITM SSL निरीक्षण है — कॉर्पोरेट रूट CA के साथ
NODE_EXTRA_CA_CERTSनिर्दिष्ट किया गया है - यदि प्रॉक्सी NTLM का उपयोग करती है — localhost पर मध्यवर्ती cntlm/px स्थापित किया गया है
- परीक्षण परिदृश्यों के लिए बाहरी प्रॉक्सी को अलग वातावरण प्रोफ़ाइल में रखा गया है
निष्कर्ष
Cursor और Claude Code के साथ कॉर्पोरेट प्रॉक्सी के पीछे अधिकांश समस्याएँ तीन चीजों तक सीमित होती हैं: परिवर्तनीय वातावरण
प्रक्रिया तक नहीं पहुँचती, प्रमाणीकरण गलत सेट किया गया है, या कॉर्पोरेट MITM प्रमाणपत्र को विश्वसनीय में नहीं जोड़ा गया है।
इन तीन बिंदुओं की क्रम से जांच करने से — curl के माध्यम से,
न कि सीधे एप्लिकेशन के माध्यम से — आप डिबगिंग में घंटे बचाते हैं और जल्दी से कारण को स्थानीयकृत करते हैं।
यदि कार्य कॉर्पोरेट नेटवर्क से परे है और आपको विभिन्न क्षेत्रों से या विभिन्न प्रकार के IP से API के व्यवहार का परीक्षण करने की आवश्यकता है, तो हम रेसिडेंशियल प्रॉक्सी का प्रयास करने की सिफारिश करते हैं — वे सामान्य डेटा सेंटर पते की तुलना में स्थिर और बाहरी सेवाओं के लिए कम संदिग्ध ट्रैफिक प्रदान करते हैं।