विषय-सूची

Claude Code से थोड़ा लंबा काम कराते समय, जवाब के बीचोंबीच अचानक यह दिखाकर वह रुक सकता है।

API Error: Connection lost mid-response. The response above may be incomplete.

इस वाक्य को ज्यों का त्यों खोजने पर जानकारी हैरानी की हद तक कम मिलती है। वजह साफ़ है: यह नाम अपेक्षाकृत नया है। Claude Code की आधिकारिक एरर रेफ़रेंस में यही बात सीधे लिखी हुई है — v2.1.227 से पहले Connection lost mid-response को Connection closed mid-response के रूप में दिखाया जाता था। यानी घटना पहले से मौजूद है और सिर्फ़ दिखने वाला शब्द closed से बदलकर lost हुआ है। इंटरनेट पर पड़ी पुरानी सामग्री पुराने नाम से लिखी है, इसीलिए नए नाम से खोजने वाले को कुछ नहीं मिलता।

यह लेख इसी नाम-परिवर्तन को शुरुआती बिंदु बनाकर (1) संदेश का सटीक अर्थ (2) इसी वक़्त स्क्रीन के सामने क्या करना है (3) अपने आप दोबारा कोशिश क्यों नहीं होती (4) कटी हुई परत की छँटाई (5) एनवायरनमेंट वेरिएबल से समायोजन (6) बहुत मिलते-जुलते दूसरे संदेशों से फ़र्क़ को, सिर्फ़ आधिकारिक दस्तावेज़ और सार्वजनिक Issue के आधार पर व्यवस्थित करता है। जहाँ अनुमान मिलता है, वहाँ हर बार विश्वसनीयता का लेबल लगा है।

निष्कर्ष पहले
(1) अभी
आउटपुट बचा हुआ है

स्क्रीन पर जो आ चुका है वह मिटा नहीं है। आधिकारिक दस्तावेज़ बताता है कि continue लिखकर भेजने पर आख़िरी पूरी हुई ब्लॉक से आगे काम फिर शुरू हो जाता है।

(2) नाम की बात
closed का बदला हुआ नाम

v2.1.227 से पहले यहाँ Connection closed mid-response दिखता था। पुराने नाम से लिखी जानकारी भी ज्यों की त्यों काम आती है।

(3) बार-बार हो तो
परतों की छँटाई करें

अपनी मशीन, बीच का रास्ता या सर्वर — कहाँ टूट रहा है, उसी से अगला कदम तय होता है। ऐसी रिपोर्ट भी हैं जहाँ सादा HTTPS चलता है पर सिर्फ़ Claude Code गिरता है।

1. सबसे पहले क्या करें — स्क्रीन पर आया आउटपुट मिटा नहीं है

इलाज से पहले वह बात साफ़ कर लें जिस पर सबसे ज़्यादा ग़लतफ़हमी होती है। यह संदेश आने पर भी, उससे पहले स्क्रीन पर बह चुका सारा हिस्सा सुरक्षित रहता है। उसे फेंका नहीं जाता।

आधिकारिक एरर रेफ़रेंस उन संदेशों की व्याख्या इस तरह करता है जिनका अंत The response above may be incomplete. (ऊपर वाला जवाब अधूरा हो सकता है) पर होता है — अगर Claude किसी टेक्स्ट ब्लॉक या टूल कॉल को एक बार पूरा कर चुका हो और उसके बाद स्ट्रीमिंग नाकाम हो, तो रिक्वेस्ट दोबारा भेजने पर वही टूल कॉल दो बार चल सकता है; इसलिए Claude Code पूरा हो चुका हिस्सा जस का तस रखता है और पूरे टर्न को फेंकने के बजाय यह टिप्पणी जोड़ देता है।

इसलिए करने को सिर्फ़ तीन कदम हैं।

चरण 1
बचा हुआ आउटपुट पढ़ें

Claude Code पूरी हो चुकी हर ब्लॉक रखता है, पर टर्न ख़त्म होते समय जो आख़िरी ब्लॉक अधूरी थी उसे फेंक देता है। आमतौर पर जो ग़ायब होता है वह आख़िर के कुछ वाक्य या आख़िरी टूल कॉल होता है।

चरण 2
continue लिखकर भेजें

यही आधिकारिक रिकवरी तरीक़ा है। आख़िरी पूरी हुई ब्लॉक से आगे चलवाएँ। निर्देश शुरू से दोबारा न दें — जो काम हो चुका है वह दोबारा चल जाएगा।

चरण 3
साइड-इफ़ेक्ट वाले काम जाँचें

फ़ाइल लिखने या कमांड चलाने के बीच कटा हो, तो कहाँ तक चला यह स्क्रीन का रिकॉर्ड ही तय करता है। git status जैसी कमांड से असली हालत देखकर आगे बढ़ें।

ग़ैर-संवादात्मक सेशन में यह अपने आप आगे बढ़ता है। आधिकारिक रेफ़रेंस के अनुसार, -p से चलाना, Agent SDK और क्लाउड सेशन जैसे ग़ैर-संवादात्मक सेशन में, अगर कटा हुआ जवाब सिर्फ़ टेक्स्ट हो और उसमें कोई टूल कॉल न हो, तो Claude Code ख़ुद Claude से आगे बढ़ने को कहता है — लगातार अधिकतम 3 बार तक। यह टिप्पणी तभी दिखती है जब वे सारे निरंतरण चुक जाएँ। सबएजेंट भी इसी तरह अपने आप आगे बढ़ते हैं।

2. आधिकारिक परिभाषा — बीच में कटने के 4 संदेश

सबसे पहले यह समझ लें कि यह वाक्य Claude Code की अपनी ओर से जोड़ी गई टिप्पणी है, API से लौटे किसी एरर रेस्पॉन्स का पाठ नहीं। इसीलिए बीच में कटने का अनुभव एक जैसा होने पर भी Claude Code कारण के हिसाब से अंत के शब्द बदलता है। आधिकारिक रेफ़रेंस में गिनाए गए चार संदेश ये हैं।

API Error: Server error mid-response. The response above may be incomplete.
API Error: Connection lost mid-response. The response above may be incomplete.
API Error: Your computer went to sleep mid-response. The response above may be incomplete.
API Error: The response stopped arriving. The response above may be incomplete.
इस लेख का विषय
Connection lost mid-response

आधिकारिक व्याख्या एक ही वाक्य की है — कनेक्शन टूट गया। स्ट्रीम ठीक बह रही थी, पर उसे ढो रहा कनेक्शन ही ग़ायब हो गया।

सर्वर की ओर की नाकामी
Server error mid-response

स्ट्रीम के बीच overloaded या 5xx आना। आधिकारिक जानकारी के अनुसार यह संदेश ख़ुद v2.1.199 से आया है; उससे पहले बीच का आउटपुट फेंककर पूरे टर्न को एरर मान लिया जाता था।

अपनी मशीन की वजह
Your computer went to sleep mid-response

जब Claude Code को पता चले कि जवाब के बीच PC स्लीप में चला गया। जागने के बाद वह कनेक्शन को टूटा मानकर पढ़ना बंद कर देता है।

कटाव नहीं, सन्नाटा
The response stopped arriving

कनेक्शन खुला रहने पर भी डेटा आना बंद हो जाए और स्ट्रीम निगरानी टाइमर उसे काट दे। यह कटाव नहीं ठहराव है, इसलिए कारण और इलाज दोनों अलग हैं।

इन चारों में से आपने कौन सा देखा, यह पहले ठीक-ठीक पढ़ लें। बीच में कट जाने का अनुभव चारों में एक जैसा लगता है, पर Claude Code कारण छाँट लेने के बाद ही शब्द चुनता है। अगर lost दिख रहा है तो यह कनेक्शन खो जाने का फ़ैसला है — न सर्वर ने 5xx लौटाया है, न टाइमआउट हुआ है।

3. v2.1.227 में closed से lost नाम बदला गया

यही इस लेख का केंद्र है। आधिकारिक एरर रेफ़रेंस चारों व्याख्याओं के ठीक बाद, एक चेतावनी के रूप में यह वाक्य रखता है।

v2.1.227 से पहले Connection lost mid-response को Connection closed mid-response के रूप में और The response stopped arriving को Response stalled mid-stream के रूप में दिखाया जाता था
— Claude Code की आधिकारिक एरर रेफ़रेंस (हमारा अनुवाद)

यानी दो वाक्य एक साथ बदले गए हैं। दोनों का मेल तालिका में इस तरह बैठता है।

v2.1.227 से पहले का प्रदर्शन अभी का प्रदर्शन अर्थ (आधिकारिक)
Connection closed mid-response Connection lost mid-response कनेक्शन टूट गया
Response stalled mid-stream The response stopped arriving कनेक्शन खुला रहा, डेटा आना बंद हुआ
Connection closed while thinking, before producing a response Connection lost before a response was produced एक भी अक्षर निकलने से पहले कट गया, यानी कोई आंशिक आउटपुट नहीं
Response stalled while thinking, before producing a response The response stalled before a response was produced एक भी अक्षर निकलने से पहले, कनेक्शन खुला रहते हुए रुक गया

ध्यान रखें कि तीसरी पंक्ति इस लेख वाले संदेश से अलग चीज़ है। mid-response का मतलब है कुछ आउटपुट निकल जाने के बाद कटना, और before a response was produced का मतलब है एक भी अक्षर निकले बिना कटना — नाम दोनों का बदला है, पर अर्थ और उसके बाद का बर्ताव अलग है। विस्तार से अगले अध्याय में।

यह नाम-परिवर्तन जान लेने से क्या बदलता है

व्यवहार में इसके तीन फ़ायदे हैं।

पुराने नाम की जानकारी सीधे काम आती है

Connection closed mid-response से खोजने पर GitHub Issue और व्याख्या-लेख एकदम बढ़ जाते हैं। घटना वही है, इसलिए कुछ बदलकर पढ़ने की ज़रूरत नहीं।

वर्शन का अंदाज़ा मिल जाता है

lost दिख रहा है तो वह Claude Code v2.1.227 या उसके बाद का है। उलटे closed दिखे तो वह उससे पुराना है।

Issue की डुप्लिकेट जाँच में काम आता है

एक ही परिघटना दो नामों से दर्ज है, इसलिए issue खोजते समय दोनों वाक्यों से देखे बिना पुरानी रिपोर्ट छूट जाएगी।

🟡 CHANGELOG में इसका ज़िक्र नहीं है। यह नाम-परिवर्तन सिर्फ़ आधिकारिक दस्तावेज़ में लिखा है; लेखक ने जितना जाँचा, उसमें आधिकारिक CHANGELOG की v2.1.227 वाली प्रविष्टि में शब्द बदलने का कोई उल्लेख नहीं है। उपयोगकर्ता की नज़र में तो एक दिन अचानक शब्द बदल गया, बस इतना दिखता है। प्रदर्शन बदल जाने भर से यह न मान लें कि कोई नया एरर आ गया है।

⚠️ v2.1.222 से पहले तो यह ख़बर ही ग़लत हो सकती है। आधिकारिक एरर रेफ़रेंस साफ़ लिखता है कि v2.1.222 से पहले का Claude Code, जवाब पूरा हो जाने के बाद कनेक्शन टूटने या ठहरने पर भी यही सूचना दिखाता था और पूरे जवाब वाले टर्न को एरर बताकर रिपोर्ट करता था। यानी पुराने वर्शन में आउटपुट पूरा पहुँच चुका होने पर भी सिर्फ़ एरर का संदेश दिख जाता है। claude --version 2.1.222 से छोटा हो, तो छँटाई शुरू करने से पहले अपडेट कर लें — जो एरर दिख रहा है वह शायद असल में है ही नहीं।

4. अपने आप दोबारा कोशिश क्यों नहीं होती

ऐसा नहीं है कि Claude Code कुछ करता ही नहीं। आधिकारिक रेफ़रेंस के Automatic retries खंड के अनुसार, अस्थायी नाकामियों पर एक्सपोनेंशियल बैकऑफ़ के साथ अधिकतम 10 बार अपने आप दोबारा कोशिश होती है। इसके बावजूद यह संदेश दिखने का मतलब है कि Claude Code ने तय किया कि यहाँ दोबारा कोशिश नहीं करनी चाहिए।

फ़ैसला सिर्फ़ एक बात पर टिका है: क्या Claude पहले ही कुछ पूरा कर चुका था।

दोबारा कोशिश होती है
जब कुछ भी पूरा नहीं हुआ था, तब का कटाव

सोच समेत जवाब का कोई भी हिस्सा Claude के पूरा करने से पहले कनेक्शन गिरे, तो Claude Code उसी बैकऑफ़ के साथ रिक्वेस्ट दोबारा भेजता है और टर्न चलता रहता है। टेक्स्ट बहना शुरू हो चुका हो तब भी यही होता है।

सोच ख़त्म हो चुकी हो पर न टेक्स्ट शुरू हुआ हो न टूल कॉल, तो छोटे अंतराल पर अधिकतम 2 बार ही दोबारा भेजा जाता है; फिर भी गिरता रहे तो Connection lost before a response was produced के साथ टर्न ख़त्म हो जाता है।

दोबारा कोशिश नहीं होती ← यही लेख
ब्लॉक पूरी होने के बाद का कटाव

कोई एक टेक्स्ट ब्लॉक या टूल कॉल पूरा कर लेने (या सोच के बाद शुरू कर देने) के बाद कटे, तो Claude Code रिक्वेस्ट दोबारा नहीं भेजता। वजह यह है कि वही टूल कॉल दो बार चल सकता है।

उसके बदले वह पूरा हो चुका हिस्सा रखता है, पूरी हो चुकी टूल कॉल को चलाता है और उसके नतीजे से टर्न आगे बढ़ाता है। उसी के साथ यह टिप्पणी दिखाता है।

यह डिज़ाइन असुविधाजनक लगता है, पर दरअसल सुरक्षा की ओर झुका हुआ है। अगर अपने आप दोबारा भेजा जाता, तो फ़ाइल बदलना या कमांड चलाना जैसे साइड-इफ़ेक्ट वाले काम हर कटाव पर दो बार चल सकते थे। इसीलिए आधिकारिक सलाह दोबारा भेजने की नहीं, continue की है — पूरा हो चुका काम दोबारा न कराने का यही अकेला रास्ता है।

रीट्राई के दौरान स्क्रीन पर क्या दिखता है

दोबारा कोशिश चलते समय स्पिनर के बग़ल में Retrying in Ns · attempt x/y की उलटी गिनती दिखती है। लेबल शुरू में API error होता है, पर v2.1.198 से तीसरी कोशिश से आगे वह ठोस कारण में बदल जाता है (CLAUDE_CODE_MAX_RETRIES 3 से कम हो तो आख़िरी कोशिश पर बदलता है)।

इसके अलावा, रिक्वेस्ट ज़िंदा रहते हुए 20 सेकंड तक डेटा न आए, तो नाकामी से पहले ही Waiting for API response · will retry in … · check your network नाम का बैनर दिखता है। इसका अर्थ है कि अभी नाकामी हुई ही नहीं, और उलटी गिनती उस क्षण तक की है जब Claude Code ठहरे हुए कनेक्शन को काट देगा। आधिकारिक जानकारी के अनुसार यह सीमा v2.1.185 से पहले 10 सेकंड थी और शब्द भी अलग थे।

5. कटाव कहाँ हो रहा है — तीन परतें

सिर्फ़ इतना सुनकर कि कनेक्शन टूट गया, अगला कदम तय नहीं होता। टूटने की जगहें मोटे तौर पर तीन हैं और हर एक की जाँच का तरीक़ा अलग है।

परत 1
अपना डिवाइस और लाइन

Wi-Fi का बदलना, मोबाइल लाइन का पल भर टूटना, स्लीप, VPN क्लाइंट का दोबारा जुड़ना।

जाँच कैसे करें: तार वाले या किसी दूसरे कनेक्शन पर भी वही दोहराता है क्या। स्लीप वजह हो तो उसके लिए अलग वाक्य दिखता है, इसलिए वहीं छँटाई हो जाती है।

परत 2
रास्ता (प्रॉक्सी, गेटवे)

कॉर्पोरेट प्रॉक्सी, TLS निरीक्षण, LLM गेटवे, VPN। लंबे समय तक खुली पड़ी स्ट्रीम को निष्क्रिय मानकर काट देने वाले उपकरण आम हैं।

जाँच कैसे करें: HTTPS_PROXY हटाकर देखें कि वही दोहराता है क्या। /status से प्रॉक्सी वाली पंक्ति देखें।

परत 3
सर्वर की ओर और कनेक्शन का दोबारा इस्तेमाल

सेवा की ओर की गड़बड़ी, या दोबारा इस्तेमाल हो रहा कनेक्शन दरअसल मरा हुआ होना। अपनी लाइन दुरुस्त होने पर भी गिरते रहना इसकी पहचान है।

जाँच कैसे करें: status.claude.com देखें। कई अलग लाइनों पर एक जैसा दोहराए तो मामला सिर्फ़ आपकी मशीन का नहीं है।

आसानी से छूट जाने वाली चौथी संभावना — mTLS सर्टिफ़िकेट रोटेशन। कॉर्पोरेट माहौल में क्लाइंट सर्टिफ़िकेट इस्तेमाल हो रहा हो, तो सर्टिफ़िकेट और की बदलने पर कनेक्शन स्तर के एरर (कनेक्शन रीसेट या TLS हैंडशेक की नाकामी) होते हैं। आधिकारिक नेटवर्क कॉन्फ़िगरेशन दस्तावेज़ के अनुसार, Claude Code ऐसे कनेक्शन एरर पर दोनों फ़ाइलें दोबारा पढ़कर नई जोड़ी से रीट्राई करता है। पर यह दोबारा पढ़ना v2.1.232 से का बर्ताव है; उससे पहले रीस्टार्ट या सेटिंग दोबारा लागू होने तक पुरानी जोड़ी बनी रहती थी। claude --debug के लॉग में Stale connection — reloaded rotated mTLS client material दिखता है या नहीं, इससे पुष्टि हो जाती है।

6. अभी क्या आज़माएँ — छाँटने की चेकलिस्ट

ऊपर से नीचे, जिसका असर बड़ा और मेहनत कम उसी क्रम में रखा गया है। हर एक आज़माने के बाद देखें कि वही दोहराता है या नहीं।

# क्या करें मक़सद
1continue लिखकर भेजेंपहले नुक़सान को पक्का न होने दें। शुरू से दोहराने की तुलना में तेज़ है और दो बार चलने का ख़तरा भी नहीं
2Claude Code को नए वर्शन पर अपडेट करेंकनेक्शन से जुड़ा बर्ताव वर्शन के साथ बदलता है। v2.1.198 में जवाब के बीच छोटी नेटवर्क रुकावट से टर्न टूट जाने की समस्या ठीक की गई है
3एक टर्न को छोटे हिस्सों में बाँटेंढेर सारी फ़ाइलें पढ़कर रिपोर्ट लिखना, इसे पढ़ने और लिखने में बाँट दें। स्ट्रीम के खुले रहने का समय ही घटाएँ
4VPN और प्रॉक्सी हटाकर दोहराकर देखेंपरत 2 की छँटाई। हटाने पर ठीक हो जाए तो रास्ते की निष्क्रियता-आधारित कटाई पर शक करें
5किसी दूसरी लाइन पर दोहराकर देखेंपरत 1 और परत 3 की छँटाई। कई लाइनों पर एक जैसा हो तो मामला सिर्फ़ आपकी मशीन का नहीं
6स्लीप सेटिंग दोबारा देखेंलंबे जवाब के बीच स्क्रीन बुझ जाने वाले माहौल में, अलग वाक्य दिखने से पहले ही कनेक्शन टूट सकता है
7status.claude.com देखेंपरत 3 की पुष्टि। 529 आने पर Claude Code ख़ुद यह होस्टनाम स्क्रीन पर दिखाता है
8claude --debug से रिकॉर्ड लेंलॉग ~/.claude/debug/<session-id>.txt में बनता है। रिपोर्ट करते समय उसे साथ लगाएँ
9जाँचें कि कहीं SOCKS प्रॉक्सी तो इस्तेमाल नहीं हो रहीआधिकारिक दस्तावेज़ साफ़ लिखता है कि SOCKS प्रॉक्सी समर्थित नहीं है। इस्तेमाल हो रही हो तो दूसरा रास्ता चुनें
ब्राउज़र वाला Claude तो ठीक चलता है, यह कोई सबूत नहीं है। claude.ai की चैट और Claude Code का CLI, कनेक्शन बनाने के तरीक़े में भी अलग हैं और एक कनेक्शन कितनी देर खुला रहता है इसमें भी। एक ठीक रहे और दूसरा ही गिरे, यह पूरी तरह मुमकिन है (आगे बताया गया Issue #85979 ठीक यही हाल दर्ज करता है)। अकाउंट ठीक है इसलिए दिक़्क़त सेटिंग की है, ऐसा मान लेना ठीक नहीं।

7. टाइमर और रीट्राई को एनवायरनमेंट वेरिएबल से समायोजित करना

जवाब के चुप पड़ जाने पर स्ट्रीम काट देने के लिए Claude Code के पास चार अलग-अलग टाइमर हैं। आधिकारिक नेटवर्क कॉन्फ़िगरेशन दस्तावेज़ में दी गई सूची इस तरह है।

टाइमर काटने की शर्त डिफ़ॉल्ट टाइमआउट
First-byte deadline भेजने के बाद एक भी रेस्पॉन्स हेडर न आना सीधे API पर 180 सेकंड, बाक़ी पर 300 सेकंड (रिक्वेस्ट बॉडी के हर 32KB पर 1 सेकंड और जुड़ता है)
Event-level watchdog रेस्पॉन्स की एक भी इवेंट पार्स न हो पाना 300 सेकंड (हर प्रोवाइडर पर चलता है)
Byte-level watchdog SSE की कीप-अलाइव ping समेत एक भी बाइट न आना सीधे API पर 180 सेकंड, बाक़ी पर 300 सेकंड
Body idle timeout 5 मिनट तक कोई बाइट न आना 5 मिनट (सीधे API के अलावा वाले प्रोवाइडर के लिए)

ध्यान रहे, इन टाइमरों के काटने का नतीजा आमतौर पर सन्नाटे वाला वाक्य होता है — इस लेख वाले संदेश से अलग। इसे यहाँ इसलिए रखा है कि दोनों में फ़र्क़ करने के लिए डिफ़ॉल्ट मान पता होने चाहिए, इसलिए नहीं कि lost दिखे तो टाइमर बढ़ा दिया जाए। प्रॉक्सी के पार लंबी चुप्पी वाले माहौल में इन मानों को बदलने से ठहराव वाले लक्षण बदलते हैं।

रीट्राई की ओर इन वेरिएबल से समायोजित की जा सकती है।

एनवायरनमेंट वेरिएबल डिफ़ॉल्ट असर
CLAUDE_CODE_MAX_RETRIES 10 दोबारा कोशिशों की संख्या। v2.1.186 से ऊपरी सीमा 15 है। स्क्रिप्ट में इसे घटाकर जल्दी फेल कराना सुझाया जाता है
CLAUDE_CODE_RETRY_WATCHDOG सेट नहीं CI जैसे बिना निगरानी वाले सेशन के लिए। 1 करने पर 429 और 529 पर अनंत बार दोबारा कोशिश होती है, और v2.1.199 से कटाव समेत अस्थायी एरर की डिफ़ॉल्ट संख्या 300 कर देता है
API_TIMEOUT_MS 600000 प्रति रिक्वेस्ट टाइमआउट (मिलीसेकंड में, यानी 10 मिनट)। धीमी लाइन या प्रॉक्सी पर इसे बढ़ाएँ
CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS सेट नहीं सिर्फ़ बाइट निगरानी का टाइमआउट। 10 सेकंड से 30 मिनट के बीच सीमित रहता है
CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS सेट नहीं पहली बाइट तक की समय-सीमा सीधे तय करता है। v2.1.242 से उपलब्ध है
⚠️ रीट्राई की संख्या बढ़ाने से यह संदेश कम नहीं होता। अध्याय 4 में बताए अनुसार, यह टिप्पणी उस मौक़े पर आती है जब Claude Code जानबूझकर दोबारा कोशिश टाल रहा होता है। CLAUDE_CODE_MAX_RETRIES बढ़ाने का असर आउटपुट निकलने से पहले गिरने वाली नाकामी पर होता है, बीच में कटे हुए हिस्से पर नहीं। असर एक टर्न को छोटा करने से होता है।

8. मिलते-जुलते संदेशों से फ़र्क़ कैसे करें

पाठक के लिए शायद यही हिस्सा सबसे काम का है। बीच में रुक जाने का अनुभव एक जैसा होने पर भी, Claude Code जो वाक्य दिखाता है वह अलग होता है, और कारण तथा इलाज भी अलग। इस साइट के पुराने लेखों से मेल बिठाते हुए सब एक जगह रखा है।

स्क्रीन पर दिखने वाला वाक्य क्या हो रहा है क्या पढ़ें
Connection lost mid-response कुछ आउटपुट निकल जाने के बाद कनेक्शन खो गया यही लेख
Connection closed mid-response उसी घटना का पुराना नाम (v2.1.227 से पहले) पुराने नाम के दौर की रिपोर्टें समेटता closed वाला लेख
The response stopped arriving
पुराना: Response stalled mid-stream		 कनेक्शन ज़िंदा है पर सन्नाटा छा गया और टाइमर ने काट दिया stalled वाला लेख (दोहराव वाले लूप से बनने वाली कड़ी पर ध्यान दें)
Server error mid-response स्ट्रीम के बीच सर्वर की ओर 5xx या overloaded 529 और 500 वाला लेख
Your computer went to sleep mid-response जवाब के दौरान PC स्लीप में चला गया, यह Claude Code ने पकड़ा पावर और स्लीप सेटिंग दोबारा देखें (इसी लेख का अध्याय 6)
Connection lost before a response was produced एक भी अक्षर निकले बिना कट गया (कोई आंशिक आउटपुट नहीं) दोबारा कोशिश का मामला। इसी लेख का अध्याय 4
Unable to connect या SSL सर्टिफ़िकेट एरर मूल रूप से कनेक्शन बन ही नहीं रहा नेटवर्क और प्रॉक्सी वाला लेख
जवाब में court या invoke टैग दिखना यह संचार का नहीं, टूल कॉल न चलने का मामला है court टैग वाला लेख

सबसे बड़ा विभाजन यह है कि स्क्रीन पर जवाब निकला या नहीं। एक भी अक्षर न निकला हो, तो शक की बारी कनेक्शन और सेटिंग (प्रॉक्सी, सर्टिफ़िकेट, फ़ायरवॉल) की है। कुछ हिस्सा निकल चुका हो, तो वही इस बात का सबूत है कि कनेक्शन बना था; ऐसे में सेटिंग छेड़ने के बजाय इस लेख वाली छँटाई पर बढ़ना सही है।

दूसरा विभाजन: कटाव या सन्नाटा

कनेक्शन खो गया, या खुला रहते हुए चुप पड़ गया — इस पर अगला कदम एकदम उलटा हो जाता है।

कटाव (lost) हो तो

रास्ते और कनेक्शन के दोबारा इस्तेमाल पर शक करें। टाइमआउट का मान बढ़ाने का कोई मतलब नहीं — समय ख़त्म नहीं हुआ, कनेक्शन ही नहीं रहा।

सन्नाटा (stopped arriving) हो तो

अब टाइमर की बारी है। CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS जैसे मानों को बदलने की गुंजाइश है, और मॉडल के लंबे समय तक चुप रहने की स्थिति पर भी शक करें।

9. असल रिपोर्ट — ECONNRESET का न रुकना

सबसे परेशान करने वाला पैटर्न यह है कि अपनी लाइन पूरी तरह दुरुस्त होने पर भी सिर्फ़ Claude Code गिरता रहता है। सार्वजनिक Issue में ऐसी दो रिपोर्टें हैं जिनमें जाँच की मेहनत काफ़ी ज़्यादा है। दोनों या तो इस लेख वाले नए नाम से दर्ज हैं, या उससे ठीक पहले के वर्शन का वाक्य लिए हुए हैं।

Issue #86473 (v2.1.229 / Windows 11)
सादा HTTPS चलता है पर सिर्फ़ CLI कटता है

रिपोर्ट करने वाला लिखता है कि Connection dropped (ECONNRESET) · Retrying in 17s · attempt 6/10 के बाद API Error: Connection lost mid-response. दिखता है। साथ ही, curl से किया 60KB का POST और सादे Node.js के https.request से उतने ही आकार का POST, दोनों ठीक-ठाक पूरे हुए, और दूसरे होस्ट से लंबी SSE भी नहीं टूटी।

MTU की जाँच, Winsock LSP की जाँच, न्यूनतम सेटअप पर दोहराव और दो असंबद्ध नेटवर्क पर दोहराव तक कर लेने के बाद भी मामला अनसुलझा है। Issue #86473 डुप्लिकेट का निशान लगने के बावजूद खुला पड़ा है।

Issue #85979 (v2.1.228 / Windows 11)
उसी डिवाइस पर ब्राउज़र वाला संस्करण ठीक चलता है

यहाँ Connection dropped (ECONNRESET) · Retrying in 0s · attempt 4/10 दिखता है। रिपोर्ट करने वाला लिखता है कि सिक्योरिटी सॉफ़्टवेयर को पूरी तरह हटाने, VPN फ़िल्टर, प्रॉक्सी तथा IPv6 और Winsock रीसेट तक सब आज़मा लेने के बाद भी, तीन नेटवर्क (दफ़्तर का Wi-Fi, घर का Wi-Fi और फ़ोन की टेदरिंग) पर एक जैसा दोहराव हुआ।

उसी डिवाइस और उसी अकाउंट पर claude.ai की चैट बिना दिक़्क़त चलती है, यह तुलना भी दी गई है। Issue #85979 भी खुला (stale) पड़ा है।

🟡 इस अध्याय की विश्वसनीयता के बारे में। ऊपर की दोनों व्यक्तिगत रिपोर्टें हैं, Anthropic की ओर से कारण की आधिकारिक व्याख्या नहीं। #85979 में रिपोर्ट करने वाला लिखता है कि सपोर्ट ने उसे बताया कि पुराने कनेक्शन दोबारा इस्तेमाल करने से जुड़ी गड़बड़ी v2.1.227 से ठीक हो चुकी होनी चाहिए, फिर भी अपडेट के बाद वही दोहराया — यह रिपोर्ट करने वाले द्वारा सपोर्ट से हुई बातचीत का हवाला है, कोई सार्वजनिक आधिकारिक बयान नहीं। इसी तरह, #86473 में जिन दो गड़बड़ी-अवधियों का ज़िक्र है, वे भी रिपोर्ट करने वाले को सपोर्ट से बताई गई बातें हैं। इन्हें पक्की दोहराव-शर्तों वाली घटना मानकर न पढ़ें।

फिर भी इन दोनों से एक काम की बात निकलती है। ping चल जाना या curl चल जाना, इस एरर के न होने का सबूत नहीं है। स्ट्रीमिंग में एक ही कनेक्शन को कई मिनट खुला रखने वाला संचार, छोटी रिक्वेस्ट से अलग शर्तों में चलता है। अपने नेटवर्क की जाँच में समय लगाने के बजाय टर्न को छोटे हिस्सों में बाँटने से दोहराव की दर ज़्यादा आसानी से घटती है।

10. क्या पक्का है और क्या नहीं

ग़लतफ़हमी से बचने के लिए, जो आधिकारिक रूप से जाँचा जा सकता है और जो नहीं, दोनों अलग-अलग रखे हैं।

✅ आधिकारिक रूप से पुष्ट
  • यह वाक्य आधिकारिक एरर रेफ़रेंस में औपचारिक रूप से दर्ज है और इसका अर्थ है कनेक्शन टूट गया
  • v2.1.227 से पहले Connection closed mid-response दिखाया जाता था (उसी चीज़ का नया नाम)
  • बीच तक बह चुका आउटपुट जानबूझकर रखा जाता है (दोबारा भेजने पर दो बार चलने का ख़तरा होता है)
  • रिकवरी का तरीक़ा है continue लिखकर भेजना
  • आउटपुट निकलने से पहले का कटाव अपने आप दोबारा आज़माया जाता है (अधिकतम 10 बार, एक्सपोनेंशियल बैकऑफ़)
  • ग़ैर-संवादात्मक सेशन और सबएजेंट ख़ुद आगे बढ़ते हैं (क्रमशः v2.1.246 और v2.1.257 से)
🟡 रिपोर्ट है, पर पुष्ट नहीं
  • सादा HTTPS दुरुस्त होने पर भी सिर्फ़ CLI का ECONNRESET से गिरना (#86473 और #85979 की रिपोर्ट)
  • उसी डिवाइस और उसी अकाउंट पर ब्राउज़र वाला संस्करण ठीक चलने की तुलना (#85979 की रिपोर्ट)
  • कनेक्शन दोबारा इस्तेमाल करने से जुड़ी गड़बड़ी की भूमिका होने की संभावना (रिपोर्टकर्ता द्वारा उद्धृत सपोर्ट की बात)
  • किसी ख़ास तारीख़ और समय पर सर्वर की ओर गड़बड़ी होने का ज़िक्र (यह भी रिपोर्टकर्ता के ज़रिए)
🔴 लेख लिखे जाने तक अप्रकाशित
  • Anthropic की ओर से कारण की आधिकारिक व्याख्या (ऊपर की दोनों Issue पर कोई सार्वजनिक जवाब नहीं)
  • नाम बदलने की वजह। CHANGELOG में शब्द बदलने का उल्लेख नहीं मिलता
  • #86473 और #85979 दोनों खुले पड़े हैं

कुल मिलाकर, लक्षण, अर्थ और रिकवरी का तरीक़ा आधिकारिक रूप से दर्ज है, पर कटाव क्यों होता है इसकी आधिकारिक व्याख्या अभी नहीं आई है। ऐसे में कारण खोजने से ज़्यादा पक्का असर कट जाने पर भी नुक़सान कम से कम रखने वाले तरीक़े का होता है — टर्न को छोटे हिस्सों में बाँटना, साइड-इफ़ेक्ट वाले काम हालत जाँचते हुए आगे बढ़ाना, और वर्शन नया रखना। ये तीनों, कारण चाहे जो हो, असर करते हैं।

FAQ

Q1. क्या Connection lost mid-response और Connection closed mid-response अलग-अलग एरर हैं?

दोनों एक ही हैं। आधिकारिक एरर रेफ़रेंस साफ़ लिखता है कि v2.1.227 से पहले यही घटना Connection closed mid-response के रूप में दिखती थी। प्रदर्शन बदल जाने का यह मतलब नहीं कि कोई नई तरह की गड़बड़ी हो गई। पुराने नाम से लिखी जानकारी भी ज्यों की त्यों देखी जा सकती है।

Q2. क्या उससे पहले का आउटपुट मिट जाता है?

नहीं मिटता। Claude ने जो ब्लॉक पूरी कर लीं वे सब बची रहती हैं। सिर्फ़ वह आख़िरी ब्लॉक फेंकी जाती है जो टर्न ख़त्म होते समय अधूरी थी। Claude Code जानबूझकर दोबारा न भेजकर यह टिप्पणी इसलिए लगाता है, क्योंकि दोबारा भेजने पर वही टूल कॉल दो बार चल सकती है।

Q3. आगे से शुरू करने के लिए क्या लिखकर भेजें?

continue लिखकर भेजें। आधिकारिक एरर रेफ़रेंस यही रिकवरी तरीक़ा बताता है, जो आख़िरी पूरी हुई ब्लॉक से आगे चलवाता है। निर्देश शुरू से दोबारा देने पर पहले से हो चुके काम दोहराए जा सकते हैं।

Q4. क्या रीट्राई की संख्या बढ़ाने से यह ठीक हो जाएगा?

नहीं होगा। अध्याय 4 में बताए अनुसार, यह उस मौक़े की टिप्पणी है जब Claude Code जानबूझकर दोबारा कोशिश टाल रहा होता है। CLAUDE_CODE_MAX_RETRIES (डिफ़ॉल्ट 10, v2.1.186 से ऊपरी सीमा 15) का असर आउटपुट निकलने से पहले गिरने वाली नाकामी पर होता है। असर एक टर्न को छोटा करने से होता है।

Q5. क्या -p या CI यानी ग़ैर-संवादात्मक चलाने पर भी यही होता है?

बर्ताव अलग है। आधिकारिक रेफ़रेंस के अनुसार, ग़ैर-संवादात्मक सेशन में अगर कटा हुआ जवाब सिर्फ़ टेक्स्ट हो और उसमें टूल कॉल न हो, तो Claude Code ख़ुद आगे बढ़ने को कहता है — लगातार अधिकतम 3 बार तक। यह टिप्पणी वे सब चुक जाने के बाद दिखती है। v2.1.246 से पहले पहले ही कटाव पर टर्न ख़त्म हो जाता था। --output-format json इस्तेमाल कर रहे हों, तो यह संदेश result फ़ील्ड में आता है।

Q6. सबएजेंट (Task) में भी यह दिखता है।

सबएजेंट भी इसी तरह अपने आप आगे बढ़ते हैं। कटा हुआ जवाब सिर्फ़ टेक्स्ट हो, तो Claude Code सबएजेंट से आगे बढ़ने को कहता है, और निरंतरण चुक जाने पर ही यह टिप्पणी आख़िरी संदेश बनती है। v2.1.257 से पहले पहले ही कटाव पर टिप्पणी दिखा दी जाती थी।

Q7. क्या मेरा नेटवर्क ख़राब है?

यह संभव है, पर बात सिर्फ़ इतनी ही हो, ज़रूरी नहीं। Issue #86473 की रिपोर्ट में दिखाया गया है कि curl और सादे Node.js से किए गए उतने ही आकार के POST दोनों पूरे हो जाते हैं, फिर भी सिर्फ़ CLI गिरता है। पहले VPN और प्रॉक्सी हटाकर देखें कि वही दोहराता है क्या, फिर किसी दूसरी लाइन पर आज़माएँ। दोनों में कोई फ़र्क़ न पड़े, तो मामला सिर्फ़ आपकी मशीन का नहीं है, यह तय किया जा सकता है।

Q8. क्या टाइमआउट बढ़ाने से यह घटेगा?

इस संदेश के मामले में ऐसी उम्मीद नहीं रखनी चाहिए। यह फ़ैसला समय ख़त्म होने का नहीं, कनेक्शन ही खो जाने का है। टाइमर (CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS वगैरह) बढ़ाने का असर The response stopped arriving पर होता है, यानी उस लक्षण पर जहाँ कनेक्शन ज़िंदा रहते हुए सन्नाटा छा जाता है।

Q9. कौन सा वर्शन चल रहा है, यह कैसे देखें?

claude --version से देखा जा सकता है। स्क्रीन पर lost दिख रहा हो तो वह v2.1.227 या उसके बाद का है, और closed दिखे तो उससे पहले का। कनेक्शन से जुड़ा बर्ताव वर्शन के साथ बदलता रहा है, और आधिकारिक CHANGELOG में v2.1.198 पर जवाब के बीच छोटी नेटवर्क रुकावट से टर्न टूट जाने की समस्या ठीक की गई है। अपडेट सबसे पहले आज़माने लायक कदम है, पर पूरा इलाज होने की गारंटी नहीं — ऊपर बताई गई दोनों Issue उससे नए वर्शन की रिपोर्टें हैं।

Q10. कॉर्पोरेट नेटवर्क पर बार-बार होता है। कौन सी सेटिंग देखें?

आधिकारिक नेटवर्क कॉन्फ़िगरेशन दस्तावेज़ में मुख्य बातें हैं। पहली, SOCKS प्रॉक्सी समर्थित नहीं है, इसलिए उसे इस्तेमाल न करें। दूसरी, प्रॉक्सी वेरिएबल शेल के export के बजाय ~/.claude/settings.json के env ब्लॉक में रखें, क्योंकि बैकग्राउंड में चलने वाले एजेंट तक शेल का माहौल नहीं पहुँचता। तीसरी, mTLS इस्तेमाल कर रहे हों तो सर्टिफ़िकेट रोटेशन का ध्यान रखें। सेटिंग पढ़ी गई या नहीं, यह claude --debug के लॉग या /status के प्रदर्शन से जाँचा जा सकता है।

संबंधित लेख

काम में लिए गए प्राथमिक स्रोत