विषय-सूची
- 1. यह एरर असल में क्या बता रहा है
- 2. हर संदेश का मतलब (v2.1.227 से लागू शब्दावली)
- 3. प्रॉक्सी सेटअप (HTTPS_PROXY)
- 4. TLS और कॉर्पोरेट CA सर्टिफिकेट (सबसे ज़रूरी, सुरक्षित ढंग से)
- 4-1. OAuth error: SSL certificate error (CERT_HAS_EXPIRED)
- 5. फ़ायरवॉल में अनुमत डोमेन
- 6. डायग्नोस्टिक वर्कफ़्लो
- 7. मिलते-जुलते एरर से फ़र्क पहचानना
- सारांश
- FAQ
क्या आप किसी कॉर्पोरेट मशीन पर या VPN के ज़रिये Claude Code इस्तेमाल करने की कोशिश कर रहे हैं, और यह इन जैसे एरर के साथ कनेक्ट ही नहीं हो रहा?
# What you see now (examples)
Can't reach the API server — check your internet or DNS (ENOTFOUND)
Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)
Unable to connect to API. Check your internet connection
Unable to connect to Anthropic services
fetch failed
# What older versions showed
Unable to connect to API (ECONNREFUSED)
Unable to connect to API: SSL certificate verification failed.
Check your proxy or corporate SSL certificatesसंदेश के शब्द वर्ज़न पर निर्भर करते हैं। v2.1.227 से, जो संदेश पहले सिर्फ़ एक कोड जोड़ देते थे, जैसे Unable to connect to API (ECONNREFUSED), वे अब विफलता का प्रकार पहले बताते हैं, जैसे Connection refused — या Can't reach the API server — (मिलान तालिका §2 में)। आप चाहे जो भी शब्द देखें, समस्या क्या है और उसे कैसे ठीक करना है, दोनों एक ही हैं।
ये नेटवर्क एरर हैं, जिनका मतलब है कि "Claude Code, Anthropic के सर्वर (api.anthropic.com) तक पहुँच ही नहीं पा रहा।" ये न तो ऑथेंटिकेशन (401/403) हैं, न सर्वर ओवरलोड (529/500), और न ही रेट लिमिट (429) — रिक्वेस्ट सर्वर तक पहुँची ही नहीं। सामान्य कारण होते हैं कॉर्पोरेट प्रॉक्सी, TLS इंस्पेक्शन (सर्टिफिकेट), और फ़ायरवॉल, जिसकी वजह से यह एंटरप्राइज़ नेटवर्क पर ख़ास तौर पर आम है। यह लेख प्रॉक्सी सेटअप, कॉर्पोरेट CA सर्टिफिकेट, अनुमति देने योग्य डोमेन, और डायग्नोस्टिक स्टेप्स को कवर करता है — आधिकारिक जानकारी के आधार पर।
शुरू में ही मुख्य बातें। (1) प्रॉक्सी के पीछे हों तो HTTPS_PROXY सेट करें। (2) TLS इंस्पेक्शन (Zscaler आदि) से आने वाले सर्टिफिकेट एरर के लिए NODE_EXTRA_CA_CERTS को कॉर्पोरेट CA पर सेट करें — और कभी भी NODE_TLS_REJECT_UNAUTHORIZED=0 से वेरिफ़िकेशन बंद न करें (इससे सारा ट्रैफ़िक इंटरसेप्शन के सामने उजागर हो जाता है)। (3) शुरुआत curl -I https://api.anthropic.com चलाकर करें ताकि पता चले "क्या यह पहुँच भी पा रहा है?" — यही ट्रायाज की जड़ है।
यह सर्वर तक पहुँचता ही नहीं
— कहाँ रुकता है, उसी से तय होता है इलाज
HTTPS_PROXYNODE_EXTRA_CA_CERTS
सबसे पहले curl -I https://api.anthropic.com चलाकर देखें कि यह पहुँच पा रहा है या नहीं।
एक बार पता चल जाए कि कहाँ रुक रहा है (प्रॉक्सी / TLS / फ़ायरवॉल), तो लगाने वाली सेटिंग तय हो जाती है।
1. यह एरर असल में क्या बता रहा है
Unable to connect to API, fetch failed, ECONNREFUSED / ETIMEDOUT (v2.1.227 से Connection refused — जैसे शब्दों में; §2 देखें) का मतलब है "रिक्वेस्ट Anthropic के सर्वर तक पहुँची ही नहीं" = यह TCP/TLS/DNS में कहीं फ़ेल हो गई। यही दूसरे एरर से इसका निर्णायक फ़र्क है: ऑथेंटिकेशन (401/403), सर्वर (529/500), और रेट (429) — ये सब सर्वर तक पहुँचने के बाद आने वाले रिस्पॉन्स हैं, जबकि नेटवर्क एरर का मतलब है यह वहाँ तक पहुँचा ही नहीं।
एंटरप्राइज़ नेटवर्क पर सामान्य ब्लॉकर तीन परतों में बँटते हैं। (1) प्रॉक्सी — आप सीधे बाहर नहीं जा सकते और कॉर्पोरेट प्रॉक्सी से होकर जाना ज़रूरी है, जो कॉन्फ़िगर नहीं है। (2) TLS इंस्पेक्शन (सर्टिफिकेट) — Zscaler जैसा इंस्पेक्शन प्रॉक्सी सर्टिफिकेट बदल देता है, इसलिए आपको कॉर्पोरेट रूट CA पर भरोसा करना होगा। (3) फ़ायरवॉल — ज़रूरी डोमेन अनुमत नहीं हैं। सबसे पहला काम है curl -I https://api.anthropic.com से यह पुष्टि करना कि "क्या यह पहुँच पा रहा है?" — यह एक जाँच ही "नेटवर्क समस्या" को "बाकी सब" से अलग कर देती है।
जहाँ रुकता है = वहीं की सेटिंग लगानी है
ECONNREFUSED/ETIMEDOUT/fetch failed. कॉर्पोरेट प्रॉक्सी से होकर जाना ज़रूरी → HTTPS_PROXY सेट करें।SSL certificate verification failed/self-signed → कॉर्पोरेट CA को NODE_EXTRA_CA_CERTS में रखें। वेरिफ़िकेशन कभी बंद न करें।Could not resolve host/ENOTFOUND. DNS डाउन, पुराना VPN, या Docker ट्रैफ़िक को इंटरसेप्ट कर रहा हो।
अगर curl -I https://api.anthropic.com सफल हो जाए, तो समस्या Claude Code और नेटवर्क के बीच तक सिमट जाती है।
2. हर संदेश का मतलब (v2.1.227 से लागू शब्दावली)
आधिकारिक एरर रेफ़रेंस के अनुसार, इस समूह के संदेशों का मतलब है कि API से TCP कनेक्शन विफल हो गया या पूरा ही नहीं हुआ। आम एरर कोड के लिए संदेश विफलता का प्रकार शब्दों में बताता है और कोड को कोष्ठक में रखता है। अभी यह दिखता है:
Unable to connect to API. Check your internet connection
Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)
Can't reach the API server — check your internet or DNS (ENOTFOUND)
No internet route — check your connection or VPN (EHOSTUNREACH)
Couldn't connect through your proxy (ERR_PROXY_TUNNEL) — the proxy refused the tunnel: check its credentials and that it allows this host
Connection dropped (ECONNRESET)
fetch failed
Request timed out. Check your internet connection and proxy settingsv2.1.227 से पहले, ये सभी कोड वाले संदेश Unable to connect to API के बाद कोड के रूप में दिखते थे (उदाहरण के लिए, Unable to connect to API (ECONNREFUSED))। जिन कोड को Claude Code नहीं पहचानता, वे अब भी इसी रूप में दिखते हैं। साथ ही, एक ही संदेश के साथ अलग-अलग कोड आ सकते हैं: Connection refused के साथ ConnectionRefused या ECONNREFUSED, और Can't reach the API server के साथ ENOTFOUND या FailedToOpenSocket दिख सकता है।
| संदेश की शुरुआत | संदेश क्या बताता है | पहले क्या जाँचें |
|---|---|---|
Connection refused — | कनेक्शन अस्वीकार हुआ; हो सकता है कोई फ़ायरवॉल या प्रॉक्सी उसे रोक रहा हो | अनुमति सूची (§5) और HTTPS_PROXY (§3) |
Can't reach the API server — | API सर्वर तक पहुँच नहीं हो रही; इंटरनेट कनेक्शन या DNS पर शक करें | DNS और VPN; WSL में /etc/resolv.conf (§6) |
No internet route — | गंतव्य तक कोई रूट नहीं है | आपकी लाइन और VPN कनेक्शन की स्थिति |
Couldn't connect through your proxy | प्रॉक्सी ने टनल बनाने से मना कर दिया | प्रॉक्सी के क्रेडेंशियल, और क्या वह गंतव्य होस्ट को अनुमति देता है |
Connection dropped | कनेक्शन रीसेट हो गया (ECONNRESET) | प्रॉक्सी और नेटवर्क की स्थिरता |
संदेश जो भी हो, अस्थायी विफलताओं पर अपने-आप दोबारा कोशिश होती है, इसलिए स्क्रीन पर दिखने तक दोबारा कोशिशें पूरी हो चुकी होती हैं। अगर यह बार-बार आता है, तो कारण आपके स्थानीय नेटवर्क में है। आधिकारिक रेफ़रेंस आम कारणों में इंटरनेट तक पहुँच न होना, api.anthropic.com को रोकने वाला VPN, या ज़रूरी कॉर्पोरेट प्रॉक्सी का कॉन्फ़िगर न होना गिनाता है। समाधान §3–§6 में हैं।
Unable to connect to Anthropic services (पहली बार सेटअप)
पहली बार चलाने के सेटअप में, साइन-इन का चरण दिखाने से पहले Claude Code जाँचता है कि वह api.anthropic.com और platform.claude.com तक पहुँच सकता है या नहीं। इनमें से कोई भी जाँच विफल होने पर वह कारण दिखाकर बंद हो जाता है। आधिकारिक उदाहरण:
Unable to connect to Anthropic services
Failed to connect to api.anthropic.com: ECONNREFUSED
Connection to api.anthropic.com timed out after 10 seconds
A proxy is configured via HTTPS_PROXY. Check that it allows connections to the host above.यह जाँच उसी प्रॉक्सी कॉन्फ़िगरेशन से होकर जाती है जिससे API रिक्वेस्ट जाती हैं, और हर प्रयास को 10 सेकंड मिलते हैं। अगर विफल प्रयास किसी प्रॉक्सी से होकर गया था, तो संदेश में उस एनवायरनमेंट वेरिएबल का नाम दिखता है जिससे वह प्रॉक्सी सेट किया गया है (जैसे HTTPS_PROXY)। क्या करें:
- जाँचें कि बताया गया वेरिएबल सही प्रॉक्सी की ओर इशारा करता है, और अपनी नेटवर्क टीम से कहें कि उसके ज़रिये संदेश में दिए होस्ट तक HTTPS कनेक्शन की अनुमति दे (अनुमति सूची §5 में)
- उसी शेल में §6 वाली
curlपहुँच-जाँच चलाएँ - अगर
https://से शुरू होने वाले प्रॉक्सी URL के पीछे यहChecking connectivity...पर अटका रहता है, तो यह v2.1.222 से पहले का बग हो सकता है (जाँच API रिक्वेस्ट से अलग रास्ते से जाती थी और उसमें टाइमआउट नहीं था)। अपडेट करें - अगर आपका संगठन क्लाउड गेटवे (Claude apps gateway) से साइन-इन करता है और पहली बार चलाने पर यह एरर आता है, तो v2.1.247 या उसके बाद के वर्ज़न पर अपडेट करें
अगर आपका नेटवर्क खुला है और विफलता बनी रहती है, तो आधिकारिक रेफ़रेंस बताता है कि हो सकता है Claude Code आपके देश या क्षेत्र में उपलब्ध न हो। समर्थित देशों और क्षेत्रों की सूची देखें।
Streaming response ended before any complete data was received
Streaming response ended before any complete data was received. Retrying without streaming. If this keeps happening, check any proxy or gateway between Claude Code and your model provider.इस चेतावनी का मतलब "रिक्वेस्ट पहुँची नहीं" नहीं, बल्कि "बीच के किसी उपकरण ने रिस्पॉन्स बदल दिया" है। आपके मॉडल प्रदाता का स्ट्रीमिंग रिस्पॉन्स बिना कोई उपयोगी डेटा दिए खत्म हो गया, इसलिए Claude Code ने टर्न पूरा करने के लिए रिक्वेस्ट को बिना स्ट्रीमिंग के दोबारा भेजा। हर प्रभावित रिक्वेस्ट दो बार भेजी जाती है: खाली स्ट्रीमिंग प्रयास और दोबारा भेजना। आधिकारिक रेफ़रेंस के अनुसार, आम कारण कोई प्रॉक्सी या गेटवे है जो रास्ते में स्ट्रीमिंग रिस्पॉन्स की बॉडी को खपा लेता है या बदल देता है, और समाधान है Claude Code और आपके मॉडल प्रदाता के बीच के हर प्रॉक्सी या गेटवे को ऐसे कॉन्फ़िगर करना कि वह स्ट्रीमिंग रिस्पॉन्स की बॉडी और हेडर बिना बदले आगे भेजे। यह चेतावनी हर सेशन में एक बार और सिर्फ़ इंटरैक्टिव सेशन में दिखती है। v2.1.239 से पहले, Claude Code चुपचाप बिना स्ट्रीमिंग के दोबारा कोशिश करता था।
3. प्रॉक्सी सेटअप (HTTPS_PROXY)
जब कॉर्पोरेट प्रॉक्सी से होकर जाना ज़रूरी हो, तो मानक प्रॉक्सी एनवायरनमेंट वेरिएबल्स सेट करें। Claude Code इनका सम्मान करता है।
# Recommended: HTTPS proxy
export HTTPS_PROXY=http://proxy.example.com:8080
# If HTTPS isn't available, HTTP_PROXY
export HTTP_PROXY=http://proxy.example.com:8080
# Destinations that bypass the proxy (space- or comma-separated)
export NO_PROXY="localhost,127.0.0.1,.internal.example.com"
# Authenticating proxy (avoid hardcoding passwords)
export HTTPS_PROXY=http://username:password@proxy.example.com:8080ध्यान देने योग्य बातें: SOCKS प्रॉक्सी समर्थित नहीं हैं। NTLM / Kerberos प्रॉक्सी के लिए आधिकारिक सिफ़ारिश यह है कि बीच में एक LLM gateway खड़ा करें और ANTHROPIC_BASE_URL को उसी पर सेट करें। ये वेरिएबल्स settings.json के env ब्लॉक में भी रखे जा सकते हैं।
Claude के अलावा अन्य मॉडलों (DeepSeek, GLM, Kimi आदि) के गेटवे पर ANTHROPIC_BASE_URL को इंगित करने की सेटिंग, लागत और सावधानियाँ Claude Code में DeepSeek, GLM और Kimi का उपयोग कैसे करें में समझाई गई हैं।
4. TLS और कॉर्पोरेट CA सर्टिफिकेट (सबसे ज़रूरी, सुरक्षित ढंग से)
एंटरप्राइज़ में सबसे आम ब्लॉकर एक सर्टिफिकेट एरर होता है, जो किसी TLS इंस्पेक्शन प्रॉक्सी (Zscaler, Netskope, Palo Alto आदि) द्वारा सर्टिफिकेट बदलने से होता है। आम संदेश हैं unable to get local issuer certificate और SELF_SIGNED_CERT_IN_CHAIN।
v2.1.273 से, Claude Code के अपने संदेशों में एरर कोड और समाधान दोनों होते हैं। सेशन के दौरान API रिक्वेस्ट यह दिखाती हैं:
Unable to connect to API: SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config
Unable to connect to API: Self-signed certificate detected (SELF_SIGNED_CERT_IN_CHAIN). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config/login के दौरान और स्टार्टअप की कनेक्टिविटी जाँच में, यही विफलता एक अलग संदेश देती है:
SSL certificate error (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run `claude doctor` for details.v2.1.273 से पहले, ऊपर के दोनों संदेश Check your proxy or corporate SSL certificates पर खत्म होते थे, उनमें न कोड होता था, न NODE_EXTRA_CA_CERTS का सुझाव (लेख की शुरुआत वाला पुराना आउटपुट)। साथ ही, v2.1.199 से सर्टिफिकेट वैलिडेशन की विफलता पर दोबारा कोशिश नहीं होती, इसलिए एरर पहली ही कोशिश में दिखता है (पुराने वर्ज़न पहले कुछ मिनट दोबारा कोशिश करते थे)। हैंडशेक टाइमआउट जैसी अस्थायी TLS स्थितियों पर अब भी दोबारा कोशिश होती है।
पृष्ठभूमि के तौर पर, हाल के Claude Code अपने बंडल किए हुए CA सेट और OS ट्रस्ट स्टोर — दोनों पर भरोसा करते हैं। इसलिए अगर कॉर्पोरेट रूट CA, OS के सर्टिफिकेट स्टोर में है, तो अक्सर बिना किसी अतिरिक्त कॉन्फ़िग के काम कर जाता है (व्यवहार वर्शन के हिसाब से बदलता है, इसलिए नवीनतम की पुष्टि करें)। अगर यह OS स्टोर में नहीं है, तो IT से मिले CA बंडल (PEM) पर NODE_EXTRA_CA_CERTS को सेट करें:
# The correct, secure way: trust the corporate CA
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem
# If the proxy requires a client certificate (mTLS)
export CLAUDE_CODE_CLIENT_CERT=/path/to/client-cert.pem
export CLAUDE_CODE_CLIENT_KEY=/path/to/client-key.pem⚠️ ऐसा न करें: TLS वेरिफ़िकेशन बंद करना
NODE_TLS_REJECT_UNAUTHORIZED=0 से सर्टिफिकेट वेरिफ़िकेशन बंद करना देखने में "ठीक" कर देता है, पर ऐसा कभी न करें। इससे पूरी प्रोसेस के लिए TLS वेरिफ़िकेशन बंद हो जाता है, जिससे api.anthropic.com समेत सारा ट्रैफ़िक मैन-इन-द-मिडल अटैक (छिपकर सुनना/छेड़छाड़) के सामने उजागर हो जाता है। इससे क्रेडेंशियल और कोड लीक होने का जोखिम है। सही उत्तर हमेशा यही है कि "NODE_EXTRA_CA_CERTS के ज़रिये कॉर्पोरेट CA पर ठीक से भरोसा किया जाए।"
अगर आपको इंस्टॉल के समय (बाइनरी मौजूद होने से पहले) सर्टिफिकेट एरर मिले, तो CA को curl को पास करें: curl --cacert /path/to/corporate-ca.pem -fsSL https://claude.ai/install.sh | bash।
OAuth error: SSL certificate error (CERT_HAS_EXPIRED)
साइन-इन के बीच (/login के OAuth चरण में) नीचे वाला संदेश आकर सब रुक सकता है। यह वही शब्दशः पाठ है जो यूज़र्स ने GitHub issues में रिपोर्ट किया:
OAuth error: SSL certificate error (CERT_HAS_EXPIRED). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run /doctor for details.यह संदेश आधिकारिक एरर सूची में नहीं है। आधिकारिक SSL certificate errors सेक्शन सिर्फ़ UNABLE_TO_GET_ISSUER_CERT_LOCALLY और SELF_SIGNED_CERT_IN_CHAIN कोड दिखाता है; एक्सपायर्ड सर्टिफिकेट का ज़िक्र सिर्फ़ ऑटोमैटिक रीट्राई वाले हिस्से में, सर्टिफिकेट वेरिफ़िकेशन फ़ेल होने के एक उदाहरण के तौर पर, चलते-चलते आता है। ऊपर का पाठ GitHub issues #71708 और #71727 (दोनों जून 2026) में यूज़र्स की रिपोर्ट से है।
CERT_HAS_EXPIRED का मतलब: यह Node.js की TLS लेयर द्वारा लौटाए जाने वाले सर्टिफिकेट एरर कोड में से एक है, और Node.js का आधिकारिक डॉक्यूमेंटेशन इसे "Certificate has expired" (सर्टिफिकेट की वैधता ख़त्म हो चुकी है) बताता है। यानी सर्वर से मिले सर्टिफिकेट की जाँच हुई और उसे समय-सीमा पार माना गया। यह समय-सीमा आपके अपने कंप्यूटर की घड़ी से मिलाकर जाँची जाती है।
रिपोर्ट्स में क्या है: दोनों issues के रिपोर्टर्स ने लिखा कि वे कोई प्रॉक्सी या VPN इस्तेमाल नहीं कर रहे थे, और curl उसी होस्ट तक बिना दिक़्क़त पहुँच गया (#71708 के रिपोर्टर ने यह भी जाँचा कि घड़ी सही थी)। यानी यह एरर उन सेटअप में भी आता है जिन पर संदेश का अपना सुझाव (कॉर्पोरेट प्रॉक्सी, TLS इंस्पेक्शन) लागू नहीं होता। रिपोर्टर्स को Claude Code के साथ आने वाले रनटाइम पर शक था, और कई कमेंट्स में लिखा है कि पुराने वर्ज़न पर लौटने से ठीक हो गया। लेकिन किसी भी issue में Anthropic का जवाब नहीं है, और दोनों निष्क्रिय रहने के बाद बंद कर दिए गए। कारण की आधिकारिक पुष्टि नहीं हुई है। 30 सितंबर 2026 तक आधिकारिक CHANGELOG में भी ऐसी कोई एंट्री नहीं है जो कहे कि यह लक्षण ठीक कर दिया गया।
इस क्रम में जाँचें:
- कंप्यूटर की घड़ी: क्या तारीख़, समय और टाइम ज़ोन सही हैं? घड़ी बहुत आगे-पीछे हो तो वैध सर्टिफिकेट भी एक्सपायर्ड माना जा सकता है।
- कंपनी के प्रॉक्सी का सर्टिफिकेट: अगर ट्रैफ़िक TLS इंस्पेक्शन करने वाले प्रॉक्सी या सिक्योरिटी प्रोडक्ट से गुज़रता है, तो IT से पूछें कि वह जो सर्टिफिकेट डालता है (कॉर्पोरेट CA समेत) कहीं एक्सपायर तो नहीं हो गया।
NODE_EXTRA_CA_CERTS: अगर कॉर्पोरेट CA पर भरोसा कराना ज़रूरी है, तो आधिकारिक नेटवर्क कॉन्फ़िगरेशन पेज के मुताबिक़ IT से मिले CA बंडल कोNODE_EXTRA_CA_CERTSमें दें (ऊपर के चरण)। यह लोड हुआ या नहीं, यहclaude --debugलॉग मेंCA certs: Appended extra certificates from NODE_EXTRA_CA_CERTSवाली लाइन से पता चलता है।- फिर भी आए तो: अगर घड़ी सही है, प्रॉक्सी नहीं है और
curl -I https://platform.claude.comचल जाता है, तो हो सकता है आपकी स्थिति ऊपर की GitHub रिपोर्ट्स जैसी ही हो। Claude Code अपडेट करें, फिर issues और changelog देखें। एक कमेंट में लिखा है किNODE_TLS_REJECT_UNAUTHORIZED=0से चल गया, पर ऊपर के बॉक्स में बताए अनुसार यह वेरिफ़िकेशन पूरी तरह बंद कर देता है, इसलिए इसे इस्तेमाल न करें।
5. फ़ायरवॉल में अनुमत डोमेन
अगर आपका फ़ायरवॉल गंतव्यों को सीमित करता है, तो इन मुख्य डोमेन को HTTPS (443) पर अनुमति दें (आधिकारिक नेटवर्क आवश्यकताओं के अनुसार; अगर आप MCP कनेक्टर, प्लगइन आदि इस्तेमाल करते हैं, तो आधिकारिक सूची के दूसरे होस्ट भी चाहिए)।
| डोमेन | किसलिए |
|---|---|
api.anthropic.com | Claude API रिक्वेस्ट (आवश्यक) |
claude.ai | claude.ai अकाउंट ऑथेंटिकेशन |
claude.com | claude.ai अकाउंट से साइन-इन पर ब्राउज़र में खुलने वाला पेज (claude.ai पर रीडायरेक्ट करता है) |
platform.claude.com | Console अकाउंट ऑथेंटिकेशन; claude.ai अकाउंट भी टोकन जारी करने और रिन्यू करने के लिए इसी का उपयोग करते हैं (पहली बार सेटअप की कनेक्टिविटी जाँच में शामिल) |
downloads.claude.ai | इंस्टॉलर, ऑटो-अपडेट, प्लगइन |
raw.githubusercontent.com | /release-notes का चेंजलॉग |
ऑपरेशनल टेलीमेट्री और एरर रिपोर्ट के होस्ट (http-intake.logs.us5.datadoghq.com और browser-intake-us5-datadoghq.com) वैकल्पिक हैं, और CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC दोनों को बंद कर देता है (इन्हें आवश्यक अनुमति सूची में शामिल करना ज़रूरी नहीं)। अगर आप npm से इंस्टॉल करते हैं, तो downloads.claude.ai के इंस्टॉलर और ऑटो-अपडेट वाले उपयोग की ज़रूरत नहीं पड़ती, लेकिन पैकेज रजिस्ट्री registry.npmjs.org चाहिए। सटीक डोमेन और IP रेंज में बदलाव हो सकता है, इसलिए नवीनतम जानकारी आधिकारिक नेटवर्क-कॉन्फ़िग पेज पर देखें।
6. डायग्नोस्टिक वर्कफ़्लो
जब कनेक्ट न हो, तो ऊपर से नीचे की ओर चलें। पहला curl ही दिशा तय कर देता है।
ऊपर से नीचे की ओर अलग करें
curl -I https://api.anthropic.com (Windows: curl.exe) से पहुँच की जाँच करें। अगर यह पास हो जाए, तो समस्या आपके अपने सिरे पर है।/doctor (या अगर चालू न हो तो claude doctor) चलाएँ और प्रॉक्सी एनवायरनमेंट वेरिएबल्स जाँचें।NODE_EXTRA_CA_CERTS लगाएँ; प्रॉक्सी सेट नहीं → HTTPS_PROXY लगाएँ।curl पास हो जाए पर Claude Code फ़ेल हो, तो DNS (WSL resolv.conf), पुराने VPN, या Docker द्वारा ट्रैफ़िक इंटरसेप्ट करने का शक करें।
नियम: "पहले पहुँच जाँचें (curl), फिर जिस परत पर रुके उसकी सेटिंग लगाएँ।"
सर्टिफिकेट को NODE_EXTRA_CA_CERTS से संभालें। वेरिफ़िकेशन कभी बंद न करें।
7. मिलते-जुलते एरर से फ़र्क पहचानना
"यह रुक गया" का मतलब नेटवर्क से इतर भी हो सकता है। बड़ा बँटवारा यही है: "क्या यह सर्वर तक पहुँचा?"
| लक्षण | असल में यह क्या है | मुख्य उपाय |
|---|---|---|
| Unable to connect / Connection refused / Can't reach the API server / fetch failed / सर्टिफिकेट एरर | यह लेख = नेटवर्क (सर्वर तक पहुँचा ही नहीं) | HTTPS_PROXY / NODE_EXTRA_CA_CERTS / फ़ायरवॉल अनुमति |
| 401 / 403 / Invalid API key | ऑथेंटिकेशन (पहुँचा, पर क्रेडेंशियल की समस्या) | ऑथ / लॉगिन एरर |
| 529 / 500 | सर्वर-साइड (पहुँचा, पर ओवरलोडेड / आंतरिक एरर) | 529/500 एरर |
| 429 Request rejected | रेट लिमिट (पहुँचा, पर बहुत अधिक ट्रैफ़िक) | गति घटाएँ, इंतज़ार करें |
| Connection lost mid-response (v2.1.227 से पहले: Connection closed mid-response) | स्ट्रीम के बीच कटना (जुड़ गया, जवाब आना शुरू हुआ, फिर कनेक्शन बंद हो गया) | जवाब बीच में कट जाने वाली एरर (पुराने शब्दों वाला लेख) |
याद रखने का तरीका: नेटवर्क एरर का मतलब है "यह सर्वर तक पहुँचा ही नहीं" (TCP/TLS/DNS), और HTTPS_PROXY या NODE_EXTRA_CA_CERTS केवल इसी परत पर मदद करते हैं। इसके उलट, 401/403, 529/500, और 429 "पहुँचने के बाद के रिस्पॉन्स" हैं, इसलिए प्रॉक्सी या CA में फेरबदल से ये ठीक नहीं होंगे। curl सफल होता है या नहीं — यही दोनों को अलग करने का सबसे बढ़िया संकेत है। अन्य आम एरर के लिए एरर राउंडअप देखें।
सारांश
Claude Code के नेटवर्क/प्रॉक्सी एरर (Unable to connect / fetch failed / SSL certificate verification failed आदि) का मतलब है रिक्वेस्ट सर्वर तक पहुँची ही नहीं = एक TCP/TLS/DNS विफलता। ये ऑथेंटिकेशन (401/403), सर्वर (529/500), और रेट (429) से अलग हैं, और सामान्य दोषी होते हैं एंटरप्राइज़ की प्रॉक्सी, TLS इंस्पेक्शन, और फ़ायरवॉल। v2.1.227 से ये ऐसे शब्दों में दिखते हैं जो पहले विफलता का प्रकार बताते हैं, जैसे Connection refused — या Can't reach the API server —, और पहली बार का सेटअप Unable to connect to Anthropic services के साथ बंद हो जाता है।
उपाय: (1) प्रॉक्सी के पीछे हों तो HTTPS_PROXY सेट करें (SOCKS असमर्थित; NTLM/Kerberos एक gateway के ज़रिये), (2) सर्टिफिकेट एरर के लिए कॉर्पोरेट CA को NODE_EXTRA_CA_CERTS में रखें — कभी NODE_TLS_REJECT_UNAUTHORIZED=0 नहीं, (3) फ़ायरवॉल में api.anthropic.com आदि को अनुमति दें। डायग्नोसिस इस तरह करें: पहले curl -I https://api.anthropic.com से पहुँच जाँचें -> /doctor और प्रॉक्सी जाँच -> सर्टिफिकेट/प्रॉक्सी सेटिंग -> पुष्टि के लिए सीधा कनेक्शन -> DNS/VPN/Docker। मुख्य बात यह है कि "क्या यह सर्वर तक पहुँचा?" से नेटवर्क को ऑथ/सर्वर/रेट से अलग करें। संबंधित: ऑथ / लॉगिन एरर, 529/500 एरर, Claude Code एरर राउंडअप।
FAQ
Q. मेरे कंपनी PC पर "Unable to connect to API" आता है और कनेक्ट नहीं हो पाता।
A. आम तौर पर आपको किसी कॉर्पोरेट प्रॉक्सी से होकर जाना ज़रूरी होता है जो कॉन्फ़िगर नहीं है। पहले curl -I https://api.anthropic.com से पहुँच जाँचें; अगर यह फ़ेल हो, तो export HTTPS_PROXY=http://proxy.example.com:8080 जैसी प्रॉक्सी सेट करें (ऑथेंटिकेटिंग प्रॉक्सी के लिए user:password@ जोड़ें)। ध्यान दें कि SOCKS असमर्थित है, और NTLM/Kerberos प्रॉक्सी के लिए आधिकारिक सिफ़ारिश एक LLM gateway से होकर जाने की है।
Q. क्या "Can't reach the API server" और "Connection refused" पुराने "Unable to connect to API" से अलग एरर हैं?
A. ये उसी समूह के हैं; v2.1.227 में सिर्फ़ शब्द बदले हैं। पहले संदेश सिर्फ़ एक कोड जोड़ देता था, जैसे Unable to connect to API (ECONNREFUSED); अब वह विफलता का प्रकार पहले बताता है, जैसे Connection refused — a firewall or proxy may be blocking it (ConnectionRefused) या Can't reach the API server — check your internet or DNS (ENOTFOUND)। कोष्ठक में दिया कोड कारण का संकेत देता है, इसलिए क्या जाँचना है, यह §2 की तालिका में देखें।
Q. पहली बार चलाने पर "Unable to connect to Anthropic services" आता है और प्रोग्राम बंद हो जाता है।
A. यह उस चरण में विफल हुआ है जो साइन-इन से पहले api.anthropic.com और platform.claude.com से कनेक्टिविटी जाँचता है। अगर संदेश में किसी प्रॉक्सी वेरिएबल का नाम है (जैसे HTTPS_PROXY), तो अपनी नेटवर्क टीम से उसकी वैल्यू की पुष्टि करें और जाँचें कि संदेश में दिए होस्ट से कनेक्शन की अनुमति है। आप curl -I https://api.anthropic.com से पहुँच भी जाँच सकते हैं। अगर नेटवर्क खुला है और समस्या बनी रहती है, तो आधिकारिक रेफ़रेंस बताता है कि हो सकता है Claude Code आपके देश या क्षेत्र में उपलब्ध न हो; इसे समर्थित देशों की आधिकारिक सूची में जाँचा जा सकता है।
Q. मुझे "SSL certificate verification failed" मिलता है।
A. यह आम तौर पर एक कॉर्पोरेट TLS इंस्पेक्शन प्रॉक्सी (जैसे Zscaler) द्वारा सर्टिफिकेट बदलने से होता है। IT से कॉर्पोरेट रूट CA (PEM) लें और export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem सेट करें। अगर कॉर्पोरेट CA पहले से OS के सर्टिफिकेट स्टोर में है, तो शायद बिना किसी कॉन्फ़िग के काम कर जाए। कभी भी NODE_TLS_REJECT_UNAUTHORIZED=0 से वेरिफ़िकेशन बंद न करें — इससे सारा ट्रैफ़िक इंटरसेप्शन के सामने उजागर हो जाता है।
Q. NODE_TLS_REJECT_UNAUTHORIZED=0 सेट करने से ठीक हो गया। क्या यह ठीक है?
A. नहीं — इसे अभी वापस करें। यह पूरी प्रोसेस के लिए TLS सर्टिफिकेट वेरिफ़िकेशन बंद कर देता है, जिससे api.anthropic.com समेत सारा ट्रैफ़िक मैन-इन-द-मिडल अटैक (छिपकर सुनना/छेड़छाड़) के सामने रक्षाहीन रह जाता है। यह एक गंभीर सुरक्षा जोखिम है जो क्रेडेंशियल और सोर्स कोड लीक कर सकता है। एकमात्र सही उपाय यही है कि NODE_EXTRA_CA_CERTS के ज़रिये कॉर्पोरेट CA पर ठीक से भरोसा किया जाए।
Q. मुझे फ़ायरवॉल में किन डोमेन को अनुमति देनी चाहिए?
A. HTTPS (443) पर, कम से कम api.anthropic.com (API), claude.ai, claude.com और platform.claude.com (ऑथ), downloads.claude.ai (इंस्टॉलर/अपडेट), और raw.githubusercontent.com (चेंजलॉग) को अनुमति दें। ऑपरेशनल टेलीमेट्री और एरर रिपोर्टिंग (Datadog) वैकल्पिक हैं। सटीक डोमेन/IP में बदलाव हो सकता है, इसलिए नवीनतम जानकारी आधिकारिक नेटवर्क-कॉन्फ़िग पेज पर देखें।
Q. curl काम करता है, पर सिर्फ़ Claude Code कनेक्ट नहीं होता।
A. कारण अक्सर Claude Code और OS के बीच होता है। आम मामले: एक WSL /etc/resolv.conf जो किसी मृत DNS की ओर इशारा करता है, पुराने VPN के अवशेष (जैसे पुराने macOS utun इंटरफ़ेस), या Docker जैसा कोई रेज़िडेंट टूल जो ट्रैफ़िक इंटरसेप्ट कर रहा हो। VPN बंद करके सीधा कनेक्शन आज़माएँ, रेज़िडेंट टूल बंद करें, और DNS की समीक्षा करें — इसी क्रम में। ध्यान दें कि अस्थायी 5xx एरर 10 बार तक अपने-आप रिट्राई होते हैं, इसलिए अगर curl सफल होने के बावजूद आपको एरर दिखे, तो रिट्राई पहले ही ख़त्म हो चुके हैं।
