विषय-सूची
- 1. यह मैसेज असल में क्या कह रहा है — आधिकारिक परिभाषा
- 2. सबसे पहले क्या करें — कुछ भी खोया नहीं है
- 3. कनेक्शन क्यों टूटता है — बंद होने की तीन परतें
- 4. पैकेट कैप्चर ने क्या दिखाया: सर्वर की ओर से बंद होना
- 5. अपना वर्शन देखें — फिक्स की टाइमलाइन
- 6. किन हालात में ज़्यादा होता है
- 7. अभी ठीक करें — यूज़र चेकलिस्ट
- 8. डेवलपर्स के लिए — API/SDK में रोकथाम
- 9. मिलती-जुलती एरर से फ़र्क कैसे करें
- 10. आधिकारिक स्थिति और जो अब तक तय नहीं है
- अक्सर पूछे जाने वाले सवाल
आप Claude Code में काम कर रहे हैं और जवाब के बीचोंबीच सब कुछ इस लाइन पर रुक जाता है:
API Error: Connection closed mid-response. The response above may be incomplete.
यह लंबी रिपोर्ट लिखते वक़्त आ सकता है, कई फ़ाइलें पढ़ते वक़्त आ सकता है, या नया सेशन शुरू करने के तुरंत बाद भी। समय हर बार अलग होता है और भरोसेमंद तरीक़े से दोहराया नहीं जा सकता। यह आपके प्रॉम्प्ट की गलती नहीं है — यह ट्रांसपोर्ट लेयर की घटना है: स्ट्रीमिंग जवाब को ले जा रहा कनेक्शन तब बंद हो गया जब जवाब अभी आ ही रहा था।
और एक तथ्य किसी भी अटकल से ज़्यादा मायने रखता है। इस एरर की ज़्यादातर सार्वजनिक रिपोर्ट उन वर्शनों की हैं जो Claude Code द्वारा टूटे कनेक्शन की हैंडलिंग बदलने से पहले आए थे। आधिकारिक changelog देखें तो 2.1.179 के बाद से कनेक्शन और रीट्राई से जुड़े पाँच अलग-अलग फिक्स मिलते हैं। यह लेख सिर्फ़ आधिकारिक एरर रेफ़रेंस, आधिकारिक changelog और पैकेट कैप्चर से समर्थित असली Issues पर आधारित है, और इनमें से हर बिंदु समेटता है: (1) मैसेज का सटीक अर्थ, (2) अभी क्या करें, (3) कनेक्शन असल में कहाँ बंद हो रहा है, (4) वर्शनों के बीच क्या बदला, (5) डेवलपर के तौर पर बचाव कैसे करें।
जो हिस्सा आ चुका है वह पूरा सुरक्षित है। आगे बढ़ने का आधिकारिक तरीक़ा है continue लिखना।
2.1.198 ने छोटे नेटवर्क ड्रॉप से पूरा टर्न गिरना रोका, और 2.1.214 ने रीट्राई को मरे हुए कनेक्शन का दोबारा इस्तेमाल करने से रोका।
आपकी मशीन, रास्ता (प्रॉक्सी/VPN), या सर्वर की तरफ़ — हर एक का इलाज अलग है। सर्वर की ओर से कनेक्शन बंद होने की रिपोर्ट भी हैं।
1. यह मैसेज असल में क्या कह रहा है — आधिकारिक परिभाषा
पहली बात: यह टेक्स्ट Claude Code ख़ुद लिखता है, यह API से लौटा हुआ एरर रिस्पॉन्स नहीं है। Claude Code का आधिकारिक एरर रेफ़रेंस "The response above may be incomplete." पर ख़त्म होने वाले पूरे परिवार को यूँ समझाता है: जब स्ट्रीमिंग जवाब तब फेल होता है जब Claude पहले ही दिखने वाला आउटपुट दे चुका है, तो रिक्वेस्ट दोबारा भेजने पर वही टूल कॉल दो बार चल सकते हैं — इसलिए Claude Code जो आ चुका है उसे रखता है और पूरा टर्न फेंकने के बजाय यह नोट जोड़ देता है।
और वाक्य का अंत ही कारण का नाम है। रेफ़रेंस तीन रूप गिनाता है।
आधिकारिक व्याख्या एक पंक्ति की है: कनेक्शन टूट गया। स्ट्रीम चल रही थी, पर उसे ले जाने वाला कनेक्शन बंद हो गया।
आधिकारिक तौर पर: स्ट्रीम ने डेटा भेजना बंद कर दिया। कनेक्शन ज़िंदा है पर चुप हो गया। टूटना नहीं, थम जाना।
स्ट्रीम के बीच overloaded या 5xx एरर। दस्तावेज़ के अनुसार यह रूप v2.1.199 या उसके बाद ही दिखता है; उससे पहले आंशिक आउटपुट फेंक दिया जाता था और पूरा टर्न एरर माना जाता था।
तीनों एक पंक्ति में। Connection closed यानी लिंक कट गया; Response stalled यानी वह चुप हो गया; Server error यानी सर्वर गिर गया। दिखने में तीनों "बीच में रुक गया" लगते हैं, पर हर एक ट्रांसपोर्ट के अलग बिंदु पर हुआ है।
रेफ़रेंस एक और ज़रूरी व्यवहार भी साफ़ करता है। अगर वही विफलता किसी भी दिखने वाले आउटपुट से पहले होती है, तो Claude Code टर्न ख़त्म करने के बजाय रिक्वेस्ट दोबारा भेजता है। यानी आप यह मैसेज देख रहे हैं तो इसका मतलब है कि आउटपुट पहले ही आ चुका था — दोबारा भेजने से साइड इफ़ेक्ट दोहरा सकते थे, इसलिए Claude Code ने जानबूझकर ऑटो-रीट्राई नहीं किया। एरर दिखने का मतलब यह नहीं कि कुछ आज़माया ही नहीं गया।
2. सबसे पहले क्या करें — कुछ भी खोया नहीं है
घबराकर वही निर्देश दोबारा भेजने से पहले इस क्रम में जाँचें।
दस्तावेज़ के अनुसार कुछ भी खोया नहीं है। जो छूटा है वह अमूमन आख़िरी कुछ वाक्य या आख़िरी टूल कॉल भर है।
continue लिखेंआधिकारिक एरर रेफ़रेंस में बताया गया रिकवरी स्टेप। शुरू से नहीं, जहाँ रुका वहीं से आगे बढ़वाएँ।
अगर फ़ाइल एडिट या कमांड चलने के बीच टूटा है तो कुछ हिस्सा पहले ही चल चुका हो सकता है। आगे बढ़ने से पहले git status से असली स्थिति देखें।
एक ही सेशन में कई बार आए तो सबसे पहले वर्शन जाँचें। इस हिस्से में लगातार फिक्स आते रहे हैं।
STEP 3 को हल्के में न लें। दस्तावेज़ जब कहता है कि दोबारा भेजने से "वही टूल कॉल दो बार चल सकते हैं", तो इसका दूसरा पहलू यह है कि टूटने के वक़्त कुछ टूल शायद चल ही चुके थे। अगर यह फ़ाइल लिखने, कमिट करने या डिप्लॉय करने के बीच हुआ है तो पहले असली स्थिति देखना ही सबसे छोटा रास्ता है।
3. कनेक्शन क्यों टूटता है — बंद होने की तीन परतें
सिर्फ़ "कनेक्शन टूट गया" से कुछ किया नहीं जा सकता, इसलिए बंद होने की संभावित जगहों को अलग-अलग देखें। रिपोर्टें मोटे तौर पर तीन परतों में बँटती हैं।
Wi-Fi का पल भर टूटना, मोबाइल नेटवर्क का बदलना, स्लीप से जागना। आधिकारिक changelog में "मशीन के जागने के बाद स्ट्रीमिंग रिक्वेस्ट फेल होना" का फिक्स भी है (2.1.186) — यानी यह परत असली है।
क्या काम आता है: वायर्ड या स्थिर लिंक; लंबे काम के दौरान मशीन को सोने न दें।
Claude API का आधिकारिक एरर दस्तावेज़ साफ़ लिखता है कि कुछ नेटवर्क अनिश्चित समय बाद आइडल कनेक्शन काट देते हैं, और TCP keep-alive सेट करने की सलाह देता है। कॉरपोरेट प्रॉक्सी और VPN में यही प्रवृत्ति आम है।
क्या काम आता है: प्रॉक्सी/VPN कुछ देर हटाकर देखें कि दोहराव होता है या नहीं।
पैकेट स्तर के प्रमाण हैं कि स्ट्रीम चलते हुए कनेक्शन सर्वर की तरफ़ से बंद किया गया (अगला भाग)। ऐसे में स्थानीय स्तर पर कुछ भी ठीक करके इसे रोका नहीं जा सकता।
क्या काम आता है: क्लाइंट की रीट्राई डिज़ाइन — इसीलिए अपडेट करना असर करता है।
दरअसल, GitHub Issue #69415 ([BUG] API Error: Connection closed mid-response ==> frequent enough to make Claude Code unusable for any task, 18 जून 2026 को दर्ज, लेख लिखे जाने तक खुला) के रिपोर्टर का माहौल है: Windows 11 / WSL2, कॉरपोरेट फ़ायरवॉल और प्रॉक्सी के बिना सीधा कनेक्शन, Claude Code 2.1.181। यानी दावा यह है कि परत 1 और 2 हटाने के बाद भी यह होता है। Issue पर area:networking, platform:vscode और platform:wsl लेबल लगे हैं।
वही रिपोर्टर लिखता है कि उसी मशीन और उसी नेटवर्क पर दूसरे AI असिस्टेंट (GitHub Copilot, Cursor वग़ैरह) यही काम पूरा कर लेते हैं। पर यह एक यूज़र की तुलना है, Anthropic द्वारा कारण का निर्धारण नहीं — यह फ़र्क़ बनाए रखना ज़रूरी है।
एक और रिपोर्ट के हालात साफ़ तौर पर अलग हैं। Issue #69336 (occurs immediately in new context window, 18 जून 2026 को दर्ज और खुला, Claude Code 2.1.173, Debian 13, ख़ुद होस्ट किया गया Claude Agent SDK) बताता है कि कॉन्टेक्स्ट सारांश (compact) चलने के बाद आवृत्ति बढ़ जाती है। इस पर area:agent-sdk, area:api और platform:linux लेबल हैं, और बिल्कुल नई बातचीत शुरू करना अस्थायी उपाय बताया गया है। Issue #69517 (Claude Cowork में, 19 जून 2026, macOS, 2.1.183) को डुप्लिकेट मानकर बंद कर दिया गया।
4. पैकेट कैप्चर ने क्या दिखाया: सर्वर की ओर से बंद होना
इस श्रेणी की एरर पर सबसे गहरी प्रत्यक्ष जाँच Issue #67766 है (12 जून 2026 को दर्ज, अब भी खुला)। रिपोर्टर ने अपने माहौल में पैकेट कैप्चर किए और दस घटनाओं का मिलान किया।
स्रोत: GitHub Issue #67766 के रिपोर्टर द्वारा प्रकाशित पैकेट कैप्चर और सेशन रिकॉर्ड। ये एक ही यूज़र के माहौल के माप हैं, Anthropic द्वारा सत्यापित नतीजे नहीं।
तकनीकी रूप से सबसे अहम बात यह है कि बंद होना चुनिंदा था। रिपोर्ट के अनुसार उसी गंतव्य के दूसरे कनेक्शन उस दौरान ज़िंदा बने रहे, और बंद हुआ केवल वह कनेक्शन जो रिक्वेस्ट चला रही प्रक्रिया के पास था। साथ चल रही दो अन्य claude प्रक्रियाओं के कनेक्शन अछूते रहे। लिंक गिरता तो सब साथ जाते; ऐसा नहीं हुआ।
रिपोर्टर ने यह भी देखा कि दस में से चार घटनाओं में पूल के कई कनेक्शनों पर एक साथ FIN का झुंड आया, और तीन घटनाएँ आसपास के मिनटों की :54 सेकंड पर हुईं (01:19:54 / 01:20:54 / 01:22:54 UTC) — जिसे वह 60 सेकंड के चक्र में चलने वाली किसी प्रक्रिया का संकेत मानते हैं।
🟡 इस भाग पर कितना भरोसा करें
Issue #67766 में स्क्रीन पर "API Error: The socket connection was closed unexpectedly" दिखता है, जो इस लेख के मैसेज से अलग शब्दावली है। इसलिए यह कहना कि दोनों एक ही बग हैं, ठीक नहीं। फिर भी, "स्ट्रीम चलते हुए कनेक्शन बंद होना" — इसी परत की परिघटना पर आज उपलब्ध यही एकमात्र सार्वजनिक पैकेट-स्तरीय प्रमाण है, इसलिए कार्यशील परिकल्पना के तौर पर इसका मोल है। यह भी जोड़ लें कि Anthropic ने इस रिपोर्ट पर कोई स्पष्टीकरण प्रकाशित नहीं किया है।
5. अपना वर्शन देखें — फिक्स की टाइमलाइन
व्यावहारिक रूप से यह लेख का सबसे उपयोगी हिस्सा है। Claude Code का आधिकारिक changelog देखें तो पता चलता है कि स्ट्रीम के बीच कनेक्शन टूटने की हैंडलिंग लगातार सुधरी है। नीचे की हर प्रविष्टि सचमुच changelog में दर्ज है।
स्ट्रीम के बीच कनेक्शन टूटने पर आंशिक जवाब अब सुरक्षित रहते हैं। इससे पहले कच्ची एरर दिखती थी और स्पिनर "running tool" पर अटक जाता था।
स्टॉल का संकेत बदलकर "Waiting for API response · will retry in …" हुआ, और अब 10 के बजाय 20 सेकंड की चुप्पी पर आता है, इसलिए छोटे उतार-चढ़ाव पर चेतावनी नहीं आती।
जवाब के बीच छोटे नेटवर्क ड्रॉप से पूरा टर्न रद्द होने की समस्या ठीक की गई। ECONNRESET जैसी अस्थायी एरर अब फेल होने के बजाय बैकऑफ़ के साथ दोबारा आज़माई जाती हैं।
स्ट्रीम के बीच overloaded/सर्वर एरर आने पर स्ट्रीमिंग जवाब फेंक देने की समस्या ठीक की गई। अब आंशिक हिस्सा "अधूरा जवाब" नोट के साथ रखा जाता है — Server error mid-response वहीं से आता है।
पुराने कनेक्शन की एरर के बाद keep-alive कनेक्शन पूल अब निष्क्रिय हो जाता है, ताकि रीट्राई नया सॉकेट खोले। यह सीधे उसी ढाँचे पर बात करता है जिसकी ओर #67766 ने इशारा किया — दोबारा इस्तेमाल हो रहे कनेक्शन का बंद होना।
अब इस टाइमलाइन को ऊपर दी गई रिपोर्टों के वर्शनों के साथ मिलाकर देखिए।
| रिपोर्ट | तब का वर्शन | जो फिक्स तब लागू नहीं थे |
|---|---|---|
| #69336 | 2.1.173 | 2.1.179 / 198 / 199 / 214 — सभी |
| #69415 | 2.1.181 | 2.1.198 / 199 / 214 (यानी रीट्राई सुधार और पूल फिक्स) |
| #69517 | 2.1.183 | 2.1.198 / 199 / 214 |
तीनों ही 2.1.198 से पुराने हैं — वही वर्शन जो अस्थायी ड्रॉप को रीट्राई से सोख लेता है। इसलिए सबसे पहले अपना वर्शन देखिए।
claude --versionअगर यह 2.1.198 से कम है तो जाँच-पड़ताल से पहले अपडेट करना ज़्यादा तेज़ रास्ता है। लेख लिखे जाने तक changelog का नवीनतम वर्शन 2.1.220 है, जिसमें ऊपर के सभी फिक्स शामिल हैं।
फिर भी "अपडेट करने से यह ज़रूर ख़त्म हो जाएगा" नहीं कहा जा सकता। changelog में "Connection closed" को नाम लेकर बताने वाली कोई प्रविष्टि नहीं है; ऊपर सब आसपास की कनेक्शन हैंडलिंग के सुधार हैं। अपडेट को सबसे ज़्यादा फ़ायदेमंद पहला क़दम मानें, सिद्ध इलाज नहीं।
6. किन हालात में ज़्यादा होता है
रिपोर्टों में ये कारक बार-बार दिखते हैं।
कई बड़ी फ़ाइलें पढ़कर संरचित रिपोर्ट बनाना — यानी वह सब जो स्ट्रीम को देर तक खुला रखे (#69415)।
कॉन्टेक्स्ट सारांश चलने के बाद आवृत्ति बढ़ने की रिपोर्ट है (#69336)। सारांश के बाद रिक्वेस्ट अमूमन बड़ी हो जाती हैं।
#67766 के मापों में बंद हुए कनेक्शन 1 से 2.5 MB की रिक्वेस्ट बॉडी ले जा रहे थे। तुलना के लिए, Messages API की आधिकारिक सीमा 32 MB है।
कॉरपोरेट प्रॉक्सी, VPN, लंबी दूरी के लिंक। आधिकारिक दस्तावेज़ जब आइडल कनेक्शन काटने वाले नेटवर्क की बात करता है तो यही परत है।
changelog 2.1.186 में मशीन जागने के बाद स्ट्रीमिंग रिक्वेस्ट फेल होने का फिक्स है। लंबे काम में मशीन को सोने न दें।
#67766 में 171 में से 87 घटनाएँ पिछली कॉल के पाँच सेकंड के भीतर हुईं — इसे अकेले आइडल टाइमआउट से नहीं समझाया जा सकता।
7. अभी ठीक करें — यूज़र चेकलिस्ट
ऊपर से नीचे चलें; सबसे कम मेहनत वाला क़दम पहले।
| क्रम | क्या करें | किसलिए |
|---|---|---|
| 1 | continue लिखें | आधिकारिक रिकवरी स्टेप। शुरू से करने के बजाय जो आ चुका है उसका इस्तेमाल करता है। |
| 2 | claude --version चलाएँ, पुराना हो तो अपडेट करें | 2.1.198 का रीट्राई सुधार और 2.1.214 का पूल फिक्स मिल जाता है। यह सबसे पहले करें। |
| 3 | साइड इफ़ेक्ट जाँचें (git status वग़ैरह) | देखें कि टूटने से पहले कोई टूल आंशिक रूप से चल तो नहीं गया। दोहरे निष्पादन से बचाता है। |
| 4 | काम को टुकड़ों में बाँटें | छोटे जवाब यानी कम समय जोखिम में। "सारी फ़ाइलें पढ़कर रिपोर्ट लिखो" को चरणों में बाँटें। |
| 5 | प्रॉक्सी/VPN कुछ देर हटाकर दोबारा जाँचें | परत 2 अलग करता है। हटाने पर बंद हो जाए तो रास्ता ही कारण है। |
| 6 | स्लीप और पावर सेविंग बंद करें, वायर्ड कनेक्शन लें | परत 1 अलग करता है — ख़ासकर लैपटॉप पर लंबे काम में। |
| 7 | बिल्कुल नए सेशन में आज़माएँ | #69336 में बताया गया अस्थायी उपाय। सारांश के तुरंत बाद बार-बार होने पर कभी-कभी काम करता है। |
| 8 | दोहराव हो तो जानकारी सहित रिपोर्ट करें | आधिकारिक API दस्तावेज़ की सलाह अनुसार request_id (req_ से शुरू होने वाला पहचानकर्ता) साथ दें, जाँच तेज़ होगी। |
जो नहीं करना है। "कनेक्शन बार-बार टूटता है" कहकर TLS सत्यापन बंद करना (NODE_TLS_REJECT_UNAUTHORIZED=0 वग़ैरह) बिल्कुल अलग लक्षण का इलाज है और आपके पूरे ट्रैफ़िक की सुरक्षा गँवा देता है। सर्टिफ़िकेट एरर दूसरी एरर है और उसका उपाय भी अलग है।
8. डेवलपर्स के लिए — API/SDK में रोकथाम
अगर आप Claude Agent SDK या अपने ख़ुद के API इंटीग्रेशन में इसी तरह के टूटने से जूझ रहे हैं तो Claude API का आधिकारिक एरर दस्तावेज़ ठोस डिज़ाइन दिशानिर्देश देता है।
दस्तावेज़ लंबी रिक्वेस्ट के लिए, ख़ासकर 10 मिनट से ऊपर, स्ट्रीमिंग Messages API या Message Batches API की सलाह देता है। बड़े max_tokens को बिना स्ट्रीमिंग भेजना सबसे जल्दी कटने वाला रूप है।
दस्तावेज़ कहता है कि सीधा इंटीग्रेशन लिखने पर TCP keep-alive सेट करने से आइडल टाइमआउट का असर घटता है। आधिकारिक SDK यह पहले से करते हैं। अपना HTTP क्लाइंट लिखा हो तो ज़रूर जाँचें।
आधिकारिक SDK अस्थायी विफलताओं — कनेक्शन एरर, रेट लिमिट, 5xx — को डिफ़ॉल्ट रूप से दो बार एक्सपोनेंशियल बैकऑफ़ के साथ दोहराते हैं और retry-after हेडर का सम्मान करते हैं। क्लाइंट विकल्प से इसे बदला या बंद किया जा सकता है।
दस्तावेज़ में साफ़ बताया गया जाल: SSE में API के 200 लौटाने के बाद भी एरर हो सकती है, इसलिए वह सामान्य HTTP एरर रास्ते से नहीं गुज़रती। स्ट्रीम के भीतर आने वाले एरर इवेंट अलग से संभालें।
Claude Code ने ख़ुद 2.1.179 और 2.1.199 में यही दिशा ली। मिले हुए ब्लॉक रखकर बाक़ी माँगना — टोकन और साइड इफ़ेक्ट दोनों में — सब कुछ फेंककर दोबारा भेजने से सस्ता है।
Claude Code ने 2.1.214 में पुराने कनेक्शन की एरर के बाद keep-alive पूल निष्क्रिय करना शुरू किया ताकि रीट्राई नया सॉकेट खोले। जाँचने लायक़ है कि आपकी रीट्राई वही मरा हुआ कनेक्शन तो नहीं पकड़ रही।
जिन वर्कलोड में आप निर्बाध कनेक्शन मान ही नहीं लेना चाहते — बैच प्रोसेसिंग साफ़ उदाहरण है — वहाँ आधिकारिक सुझाव Message Batches API है, जिसमें नतीजे पोलिंग से लिए जाते हैं। इससे नेटवर्क का जोखिम ढाँचे से ही हट जाता है, केवल कम नहीं होता।
9. मिलती-जुलती एरर से फ़र्क कैसे करें
Claude Code की कम्युनिकेशन एरर दिखने में बहुत मिलती-जुलती हैं। सबसे तेज़ तरीक़ा है "रिक्वेस्ट कहाँ तक पहुँची" के आधार पर छाँटना।
| मैसेज | कहाँ रुका | मुख्य उपाय |
|---|---|---|
| Connection closed mid-response (यह लेख) | जुड़ गया और जवाब आना शुरू होने के बाद कट गया | continue / अपडेट / रास्ते की जाँच |
| Response stalled mid-stream | कनेक्शन ज़िंदा पर चुप | अलग लेख में (दोहराव लूप से जुड़ी शृंखला का ध्यान रखें) |
| Server error mid-response | स्ट्रीम के बीच 5xx या overloaded | रुककर दोबारा कोशिश। देखें 529/500 वाला लेख |
| Unable to connect / SSL certificate verification failed | जुड़ा ही नहीं | प्रॉक्सी, कॉरपोरेट CA, फ़ायरवॉल। देखें कनेक्शन एरर वाला लेख |
| Prompt is too long | भेजने से पहले ही अस्वीकृत (नेटवर्क ठीक है) | कॉन्टेक्स्ट घटाएँ। देखें समर्पित लेख |
सबसे बड़ा बँटवारा बस इतना है कि स्क्रीन पर कोई जवाब आया या नहीं। अगर एक अक्षर भी नहीं आया तो कनेक्शन पर ही शक करें — सेटिंग और रास्ता। और अगर कुछ आकर रुक गया तो यही सबूत है कि कनेक्शन बना था; इसलिए सेटिंग छेड़ने के बजाय इस लेख की जाँच-प्रक्रिया पर बढ़ें।
10. आधिकारिक स्थिति और जो अब तक तय नहीं है
ग़लतफ़हमी से बचने के लिए, आधिकारिक रूप से क्या पुष्ट है और क्या नहीं — अलग-अलग।
- यह मैसेज आधिकारिक एरर रेफ़रेंस में औपचारिक रूप से दर्ज है और इसका अर्थ है "कनेक्शन टूट गया"
- जो आउटपुट आ चुका है वह सुरक्षित रखा जाता है — यह जानबूझकर बनाया गया व्यवहार है
- रिकवरी स्टेप है
continueलिखना - दिखने वाले आउटपुट से पहले की विफलताएँ अपने आप दोबारा आज़माई जाती हैं
- कनेक्शन हैंडलिंग के फिक्स 2.1.179 / 198 / 199 / 214 में आए
- सर्वर का स्ट्रीम के बीच FIN भेजना (#67766 में मापा गया — पर अलग मैसेज के साथ)
- 60 सेकंड के सफ़ाई चक्र की भूमिका (रिपोर्टर का अपना अनुमान)
- compact के तुरंत बाद बढ़ोतरी (#69336)
- उन्हीं हालात में दूसरे AI असिस्टेंट का फेल न होना (#69415 रिपोर्टर की तुलना)
- Anthropic की ओर से कारण की आधिकारिक व्याख्या (#69415, #69336, #67766 — किसी पर सार्वजनिक जवाब नहीं)
- "Connection closed" को नाम लेकर बताने वाली फिक्स प्रविष्टि (यह स्ट्रिंग changelog में नहीं है)
- #69415, #69336 और #67766 — तीनों अब भी खुले हैं
सार यह कि लक्षण और उपाय आधिकारिक रूप से दर्ज हैं, पर "क्यों टूटता है" की आधिकारिक व्याख्या अब तक नहीं आई। ऐसे में कारण खोजने से ज़्यादा भरोसेमंद है व्यवहार बदलना: टर्न छोटे रखें, साइड इफ़ेक्ट वाले काम में स्थिति जाँचते हुए बढ़ें, और वर्शन नया रखें।
अक्सर पूछे जाने वाले सवाल
Q1. "Connection closed mid-response" आने पर अब तक का आउटपुट मिट जाता है क्या?
नहीं। जैसा आधिकारिक एरर रेफ़रेंस साफ़ लिखता है, जो आ चुका है वह वैसे ही बना रहता है। Claude Code दोबारा भेजने के बजाय जानबूझकर यह नोट जोड़ता है, क्योंकि दोबारा भेजने पर वही टूल कॉल दो बार चल सकते हैं। छूटा हुआ हिस्सा अमूमन आख़िरी कुछ वाक्य या आख़िरी टूल कॉल भर होता है।
Q2. जहाँ रुका वहीं से आगे बढ़ाने के लिए क्या लिखें?
continue लिखें। यही आधिकारिक एरर रेफ़रेंस में बताया गया रिकवरी स्टेप है। मूल निर्देश दोबारा देने पर पहले से चल चुके काम दोहराए जाने का ख़तरा रहता है।
Q3. क्या टोकन बर्बाद हो जाते हैं?
टूटने तक जो बना, वह ख़र्च हो चुका है। Issue #69336 के रिपोर्टर ने भी लिखा है कि ख़र्च हुए टोकन वापस नहीं मिलते। इसीलिए शुरू से करने के बजाय continue से आगे बढ़ाना लागत के लिहाज़ से भी अहम है।
Q4. क्या यह "Response stalled mid-stream" जैसा ही है?
नहीं। आधिकारिक परिभाषाओं के अनुसार Connection closed का अर्थ है "कनेक्शन टूट गया" और Response stalled का अर्थ है "स्ट्रीम ने डेटा भेजना बंद कर दिया" — कटना बनाम चुप हो जाना। स्क्रीन पर दोनों मिलते-जुलते दिखते हैं, पर stalled वाले रूप की रिपोर्ट मॉडल के दोहराव लूप के साथ जुड़ी मिली है और उसका उपाय भी अलग है। देखें Response stalled mid-stream वाला लेख।
Q5. क्या गड़बड़ मेरे नेटवर्क में है?
हो सकती है, पर ज़रूरी नहीं। Issue #69415 के रिपोर्टर को यह बिना प्रॉक्सी और बिना फ़ायरवॉल वाले सीधे कनेक्शन पर हुआ, और Issue #67766 के पैकेट कैप्चर बताते हैं कि बंद करना सर्वर की ओर से शुरू हुआ। पहले प्रॉक्सी/VPN हटाकर देखें कि दोहराव होता है या नहीं; कुछ न बदले तो यह सिर्फ़ आपके सिरे की समस्या नहीं है।
Q6. क्या Claude Code अपडेट करने से ठीक हो जाएगा?
सबसे पहले आज़माने लायक़ और सबसे ज़्यादा फ़ायदेमंद क़दम यही है। आधिकारिक changelog में 2.1.198 ने "जवाब के बीच छोटे नेटवर्क ड्रॉप से टर्न रद्द होना" ठीक किया, और 2.1.214 ने keep-alive पूल को बदलकर ऐसा किया कि पुराने कनेक्शन की एरर के बाद वह निष्क्रिय हो और रीट्राई नया सॉकेट खोले। रिपोर्टों का जमावड़ा (2.1.173–2.1.183) इनसे पुराना है। पर चूँकि changelog में "Connection closed" को नाम लेकर बताने वाली कोई प्रविष्टि नहीं है, इसलिए अपडेट सुधार की संभावना है, इलाज की गारंटी नहीं।
Q7. लंबे कामों में बार-बार होता है। कोई उपाय?
काम बाँटकर हर जवाब को छोटा रखना सबसे भरोसेमंद तरीक़ा है। "सारी बड़ी फ़ाइलें पढ़कर रिपोर्ट लिखो" जैसे एकमुश्त काम स्ट्रीम को देर तक खुला रखते हैं; पढ़ने और लिखने को अलग करने भर से वह खिड़की छोटी हो जाती है और टूटने से टकराने की संभावना घट जाती है। Issue #69336 में यह भी बताया गया है कि नई बातचीत शुरू करने से अस्थायी राहत मिली।
Q8. डेवलपर के तौर पर अपने ऐप में इसे कैसे रोकूँ?
Claude API के आधिकारिक दस्तावेज़ के दिशानिर्देश स्पष्ट हैं: (1) लंबे जवाब हमेशा स्ट्रीमिंग से, 10 मिनट से ऊपर के लिए Batches API पर भी विचार करें; (2) TCP keep-alive सेट करें (आधिकारिक SDK पहले से करते हैं); (3) SSE में 200 के बाद भी एरर आ सकती है, इसलिए स्ट्रीम के भीतर के एरर इवेंट अलग से संभालें; (4) टूटने पर मिला हुआ हिस्सा रखकर बाक़ी माँगें। सपोर्ट से संपर्क करते समय request_id साथ दें।
Q9. Claude Cowork और Agent SDK में भी यही एरर आती है।
वही मैसेज वहाँ भी रिपोर्ट हुआ है। Issue #69517 Claude Cowork की रिपोर्ट है (डुप्लिकेट मानकर बंद), और #69336 ख़ुद होस्ट किए गए Claude Agent SDK के ज़रिए। यह स्ट्रीमिंग जवाब संभालने वाली परत का साझा व्यवहार है, इसलिए तरीक़ा वही रहता है: शुरू से नहीं, जहाँ रुका वहीं से आगे बढ़ाएँ; वर्शन नया रखें; और रीट्राई ठीक से डिज़ाइन करें।
संबंधित लेख
- Claude Code: «court» अनंत लूप और «Response stalled mid-stream» के कारण और उपाय
- Claude Code के network / proxy / TLS सर्टिफ़िकेट error कैसे ठीक करें
- Claude Code 529 Overloaded / 500 एरर: कारण और उपाय
- Claude Code "Prompt is too long" एरर: कारण और तुरंत उपाय
- Claude Code के आम एरर और फिक्स — पूरा रेफरेंस
