المحتويات
- 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 طريقة تعامله مع انقطاع الاتصال. فبتتبّع سجل التغييرات الرسمي تجد خمسة إصلاحات منفصلة تتعلق بالاتصال وإعادة المحاولة ابتداءً من 2.1.179. يعتمد هذا المقال حصريًا على مرجع الأخطاء الرسمي وسجل التغييرات الرسمي وبلاغات مدعومة بالتقاط حزم الشبكة، ويتناول (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 بما وصل ويضيف هذه الملاحظة بدلًا من إلغاء الدور بالكامل.
أما نهاية العبارة فهي اسم السبب. يذكر المرجع ثلاث صيغ.
الشرح الرسمي سطر واحد: انقطع الاتصال. كان التدفق يعمل، لكن الاتصال الحامل له أُغلق.
رسميًا: توقّف التدفق عن إرسال البيانات. الاتصال ما زال حيًّا لكنه صمت. ليس قطعًا بل توقّفًا.
تحميل زائد أو خطأ 5xx في منتصف التدفق. وبحسب التوثيق تتطلب هذه الصيغة الإصدار v2.1.199 أو أحدث؛ وقبله كانت المخرجات الجزئية تُلغى ويُعدّ الدور كله خطأً.
الثلاثة في سطر واحد. Connection closed تعني أن الوصلة قُطعت؛ وResponse stalled تعني أنها صمتت؛ وServer error تعني أن الخادم تعثّر. تبدو كلها «توقفًا في المنتصف»، لكن كلًّا منها وقع في نقطة مختلفة من عملية النقل.
ويوضّح المرجع سلوكًا آخر يستحق المعرفة. إذا وقع الفشل نفسه قبل ظهور أي مخرجات مرئية، فإن Claude Code يعيد المحاولة بدلًا من إنهاء الدور. بعبارة أخرى: كونك ترى هذه الرسالة يعني أن المخرجات كانت قد ظهرت بالفعل، فإعادة الإرسال قد تُكرّر الآثار الجانبية، ولذلك امتنع Claude Code عمدًا عن إعادة المحاولة تلقائيًا. ظهور الخطأ لا يعني أن شيئًا لم يُجرَّب.
2. أول ما ينبغي فعله — لم يضِع شيء
قبل أن تُعيد إرسال التعليمات نفسها في عجالة، امضِ بهذا الترتيب.
كما يقول التوثيق، لم يضِع شيء. الناقص على الأرجح هو الجُمل الأخيرة فقط أو آخر استدعاء لأداة.
continueخطوة الاستعادة التي يسمّيها مرجع الأخطاء الرسمي. دع Claude يواصل من حيث توقّف بدل البدء من جديد.
إذا انقطع أثناء تعديل ملفات أو تنفيذ أوامر، فقد يكون جزء منها نُفّذ فعلًا. اطّلع على الحالة الحقيقية عبر git status قبل المتابعة.
إن ظهر عدة مرات في جلسة واحدة، تحقّق من الإصدار قبل أي شيء آخر. فهذا الجانب خضع لإصلاحات متكرّرة.
لا تتجاوز الخطوة ٣. فحين يقول التوثيق إن إعادة الإرسال «قد تنفّذ الاستدعاءات نفسها للأدوات مرتين»، فالوجه الآخر أن بعض الأدوات ربما نُفِّذ فعلًا لحظة الانقطاع. وإذا حدث ذلك في منتصف كتابة ملفات أو إنشاء التزام أو نشر، فإن النظر أولًا إلى الحالة الحقيقية هو أقصر طريق للتعافي.
3. لماذا ينقطع — الطبقات الثلاث التي يُغلق فيها الاتصال
عبارة «انقطع الاتصال» وحدها لا تكفي للتصرّف، لذا نفصل المواضع التي قد ينشأ منها الإغلاق. تنقسم البلاغات إلى ثلاث طبقات.
تذبذب Wi-Fi، أو تبديل خلية في شبكة الجوال، أو الاستيقاظ من السكون. بل إن سجل التغييرات الرسمي يتضمّن إصلاحًا لـ«فشل طلبات التدفق بعد استيقاظ الجهاز» (2.1.186)، فهذه الطبقة واقعية.
ما ينفع: وصلة سلكية أو مستقرة، ومنع الجهاز من السكون أثناء المهام الطويلة.
ينص توثيق أخطاء Claude API الرسمي على أن بعض الشبكات تقطع الاتصالات الخاملة بعد مدة متغيرة، ويوصي بضبط TCP keep-alive. وبروكسيات الشركات وشبكات VPN ميّالة إلى هذا السلوك تحديدًا.
ما ينفع: تجاوز البروكسي/VPN مؤقتًا ومعرفة إن كان الخطأ يتكرّر.
توجد أدلة على مستوى الحزم تُظهر إغلاق الاتصال من جهة الخادم أثناء تدفّق الرد (القسم التالي). ولا يمنع ذلك أي ضبط محلي.
ما ينفع: سلوك إعادة المحاولة في العميل — ولهذا السبب يفيد التحديث.
وبالفعل، يصف صاحب البلاغ #69415 على GitHub ([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. أي أن الادعاء هو أن الخطأ يقع حتى بعد استبعاد الطبقتين ١ و٢. ويحمل البلاغ الوسوم area:networking وplatform:vscode وplatform:wsl.
ويكتب صاحب البلاغ نفسه أن مساعدي ذكاء اصطناعي آخرين (GitHub Copilot وCursor وغيرهما) يُنهون المهمة ذاتها على الجهاز نفسه والشبكة نفسها. غير أن هذه مقارنة أجراها مستخدم، وليست تحديدًا للسبب من Anthropic، ويجدر الإبقاء على هذا التمييز.
وثمة بلاغ آخر بظروف مختلفة بوضوح. فالبلاغ #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، ويصف بدء محادثة جديدة تمامًا كحل مؤقت. أما البلاغ #69517 (في Claude Cowork، 19 يونيو 2026، macOS، 2.1.183) فقد أُغلق باعتباره مكرّرًا.
4. ما كشفته حزم الشبكة: إغلاق يبدأ من الخادم
أعمق تحقيق مباشر في هذا الصنف من الأخطاء هو البلاغ #67766 (أُنشئ في 12 يونيو 2026، وما زال مفتوحًا). فقد التقط صاحبه حزم الشبكة في بيئته وقارن بين عشر حالات.
المصدر: التقاط الحزم وسجلات الجلسات التي نشرها صاحب البلاغ #67766 على GitHub. وهي قياسات مستخدم واحد، لا نتائج تحقّقت منها Anthropic.
التفصيل الأهم تقنيًا هو أن الإغلاق كان انتقائيًا. فبحسب البلاغ، ظلّت الاتصالات الأخرى إلى الوجهة نفسها حيّة خلال الحادثة، والاتصال الذي أُغلق هو تحديدًا الاتصال المملوك للعملية التي كانت تنفّذ الطلب. أما اتصالات عمليتَي claude الأخريَين العاملتين في الوقت نفسه فلم تُمسّ. ولو كانت الوصلة قد سقطت لسقط الجميع معها، وهذا لم يحدث.
ولاحظ المُبلِّغ أيضًا أن أربعًا من الحالات العشر شهدت دفعات من الإغلاق تصيب عدة اتصالات من المجمّع دفعةً واحدة، وأن ثلاثًا وقعت عند الثانية :54 من دقائق متقاربة (01:19:54 و01:20:54 و01:22:54 بالتوقيت العالمي) — وهو ما يقرأه كمؤشر على شيء يعمل بدورة مدتها 60 ثانية.
🟡 ما درجة الثقة في هذا القسم؟
الرسالة الظاهرة في البلاغ #67766 هي «API Error: The socket connection was closed unexpectedly»، وهي صياغة مختلفة عن رسالة هذا المقال. لذا لا يمكن الجزم بأنهما العطل نفسه. ومع ذلك، فهي حتى اليوم الدليل العلني الوحيد على مستوى الحزم بشأن الظاهرة نفسها من حيث الطبقة — أي إغلاق اتصال أثناء تدفّق الرد — ما يجعلها جديرة بالاعتماد كفرضية عمل. ويُضاف أن Anthropic لم تنشر أي تفسير بشأن ذلك البلاغ حتى تاريخ الكتابة.
5. تحقّق من إصدارك — الجدول الزمني للإصلاحات
هذا هو الجزء الأكثر فائدة عمليًا. فبتتبّع سجل تغييرات Claude Code الرسمي يتبيّن أن التعامل مع انقطاع الاتصال في منتصف التدفق تحسّن مرارًا. وكل بند أدناه موجود فعلًا في السجل.
صارت الردود الجزئية محفوظة عند انقطاع الاتصال في منتصف التدفق. قبل ذلك كان يظهر خطأ خام، وقد تتجمّد مؤشرات الانتظار عند «running tool».
تغيّر تنبيه التوقّف إلى «Waiting for API response · will retry in …»، وصار ينطلق بعد 20 ثانية من الصمت بدل 10، فلم تعد التذبذبات القصيرة تُطلق تحذيرًا.
أُصلح إسقاط الدور بسبب انقطاعات شبكة قصيرة في منتصف الرد. فالأخطاء العابرة مثل ECONNRESET تُعاد محاولتها الآن مع تراجع تدريجي بدل أن تفشل.
أُصلح إلغاء الردود المتدفقة عندما يصل خطأ تحميل زائد أو خطأ خادم في منتصف التدفق. صار الجزء المستلَم يُحفظ مع ملاحظة بأن الرد غير مكتمل — ومن هنا جاءت صيغة 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، فالتحديث أجدى من التشخيص. وآخر بند في سجل التغييرات وقت الكتابة هو 2.1.220، وهو يتضمّن كل الإصلاحات أعلاه.
ومع ذلك لا يمكن القول إن التحديث سيُنهيه حتمًا. فسجل التغييرات لا يتضمّن أي بند يذكر «Connection closed» نفسها؛ وكل ما سبق تحسينات في معالجة اتصال مجاورة. اعتبر التحديث الخطوة الأولى الأعلى مردودًا، لا علاجًا مثبتًا.
6. الظروف التي ترفع الاحتمال
تتكرّر هذه العوامل عبر البلاغات.
قراءة عدة ملفات كبيرة وإنتاج تقرير مُهيكل — أي شيء يبقي التدفق مفتوحًا مدة طويلة (#69415).
وردت بلاغات بأن التكرار يرتفع بعد تشغيل تلخيص السياق (#69336). فبعد التلخيص تميل الطلبات إلى الكِبَر.
في قياسات #67766 كانت الاتصالات المغلقة تحمل أجسام طلبات بحجم 1 إلى 2.5 ميغابايت. وللمقارنة، الحد الرسمي لطلب Messages API هو 32 ميغابايت.
بروكسيات الشركات وVPN والاتصالات العابرة للحدود. وهي الطبقة التي يصفها التوثيق الرسمي عند الحديث عن شبكات تقطع الاتصالات الخاملة.
أصلح البند 2.1.186 في سجل التغييرات فشل طلبات التدفق بعد استيقاظ الجهاز. لا تدع الجهاز ينام أثناء المهام الطويلة.
في #67766 وقعت 87 حادثة من أصل 171 بعد أقل من خمس ثوانٍ من الاستدعاء السابق — نمط لا يُفسَّر بالقطع عند الخمول وحده.
7. الحل الآن — قائمة تحقّق للمستخدم
امضِ في القائمة من الأعلى؛ الأقل كلفةً أولًا.
| # | ما تفعله | الهدف |
|---|---|---|
| 1 | الرد بـ continue | خطوة الاستعادة الموثّقة. تستفيد مما وصل بدل البدء من الصفر. |
| 2 | تشغيل claude --version والتحديث إن كان الإصدار قديمًا | يمنحك تحسين إعادة المحاولة في 2.1.198 وإصلاح المجمّع في 2.1.214. افعل هذا أولًا. |
| 3 | فحص الآثار الجانبية (git status وما شابه) | معرفة ما إذا كانت أدوات قد نُفِّذت جزئيًا قبل الانقطاع. يمنع التنفيذ المزدوج. |
| 4 | تقسيم المهمة | الردود الأقصر تعني وقت تعرّض أقل. جزّئ «اقرأ كل الملفات واكتب التقرير» إلى مراحل. |
| 5 | تجاوز البروكسي/VPN مؤقتًا وإعادة الاختبار | يعزل الطبقة ٢. فإن توقّف الخطأ، فالمسار هو السبب. |
| 6 | تعطيل السكون وتوفير الطاقة، واستخدام وصلة سلكية | يعزل الطبقة ١ — خصوصًا على حاسوب محمول يشغّل مهامًا طويلة. |
| 7 | التجربة في جلسة جديدة تمامًا | الحل المؤقت المذكور في #69336. ينفع أحيانًا حين يتكرّر الخطأ مباشرة بعد التلخيص. |
| 8 | إن تكرّر، أبلِغ مع التفاصيل | كما ينصح توثيق الـ API الرسمي، أرفِق request_id (المعرّف الذي يبدأ بـ req_) ليتسارع البحث. |
ما يجب ألّا تفعله. تعطيل التحقّق من TLS (مثل NODE_TLS_REJECT_UNAUTHORIZED=0) لأن «الاتصال يسقط» يعالج عرضًا مختلفًا تمامًا ويُفرّط بأمان اتصالاتك كلها. أخطاء الشهادات خطأ آخر وعلاجه مختلف.
8. للمطورين — الوقاية على مستوى API/SDK
إذا كنت تواجه الصنف نفسه من الانقطاع عبر Claude Agent SDK أو عبر تكامل خاص بك مع الـ API، فإن توثيق أخطاء Claude API الرسمي يقدّم إرشادات تصميم محدّدة.
يوصي التوثيق باستخدام Messages API المتدفقة أو Message Batches API للطلبات الطويلة، لا سيما ما يتجاوز 10 دقائق. وإرسال max_tokens كبيرة بلا تدفّق هو أكثر الأشكال عرضةً للانقطاع.
ينص التوثيق على أن ضبط TCP keep-alive يقلّل أثر مهلات الخمول إن كنت تكتب تكاملًا مباشرًا. وحِزم SDK الرسمية تضبطه أصلًا. تحقّق من ذلك إن كتبت عميل HTTP خاصًا بك.
تعيد حزم SDK الرسمية محاولة الإخفاقات العابرة — أخطاء الاتصال وحدود المعدل و5xx — مرتين افتراضيًا بتراجع أسّي، مع احترام ترويسة retry-after. ويمكن تغيير ذلك أو تعطيله بخيار في العميل.
المزلق الذي يذكره التوثيق صراحةً: مع SSE قد يقع خطأ بعد أن يكون الـ API قد أعاد 200، فلا يمرّ عبر المسار المعتاد لأخطاء HTTP. عالِج أحداث الخطأ داخل التدفق على حدة.
سلك Claude Code نفسه هذا الاتجاه في 2.1.179 و2.1.199. فـالاحتفاظ بالكتل المستلَمة وطلب البقية أقل كلفة — في الرموز وفي الآثار الجانبية — من إلغاء كل شيء وإعادة الإرسال.
في 2.1.214 صار Claude Code يعطّل مجمّع keep-alive بعد خطأ «اتصال قديم» كي تفتح إعادة المحاولة مقبسًا جديدًا. يستحق الأمر التحقّق مما إذا كانت إعادة محاولتك تلتقط الاتصال الميت نفسه.
أما أحمال العمل التي لا تريد أن تفترض فيها اتصالًا متصلًا دون انقطاع — والمعالجة الدفعية المثال الأوضح — فالمسار الموصى به رسميًا هو Message Batches API مع استطلاع النتائج. وهذا يزيل مخاطر الشبكة بنيويًا بدل تخفيفها.
9. كيف تميّزه عن الأخطاء المشابهة
أخطاء النقل في Claude Code متشابهة في مظهرها. وأسرع طريقة للفصل بينها هي حسب المدى الذي بلغه الطلب.
| الرسالة | أين توقّف | الإجراء الأساسي |
|---|---|---|
| Connection closed mid-response (هذا المقال) | اتصل وبدأ التدفق ثم انقطع | continue / التحديث / عزل المسار |
| Response stalled mid-stream | الاتصال حيّ لكنه صامت | مُعالَج في مقال منفصل (انتبه للتسلسل مع حلقة التكرار) |
| Server error mid-response | خطأ 5xx أو تحميل زائد في منتصف التدفق | الانتظار ثم إعادة المحاولة. انظر مقال 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)
- عدم إخفاق مساعدي ذكاء اصطناعي آخرين في الظروف نفسها (مقارنة مُبلِّغ #69415)
- تفسير رسمي للسبب من Anthropic (لا ردّ علني في #69415 ولا #69336 ولا #67766)
- بند إصلاح يذكر «Connection closed» (هذه العبارة غير موجودة في سجل التغييرات)
- البلاغات #69415 و#69336 و#67766 ما زالت مفتوحة جميعًا
باختصار: العَرَض والعلاج موثّقان رسميًا، لكن لم يُنشر تفسير رسمي لسبب الانقطاع. وفي هذا الوضع تتفوّق العادات التشغيلية على مطاردة السبب الجذري: أبقِ الأدوار قصيرة، وتحقّق من الحالة أثناء تنفيذ العمليات ذات الآثار الجانبية، وابقَ على إصدار حديث.
الأسئلة الشائعة
Q1. عند ظهور «Connection closed mid-response»، هل تضيع المخرجات السابقة؟
لا. فكما يوضّح مرجع الأخطاء الرسمي صراحةً، كل ما وصل يبقى محفوظًا. ويضيف Claude Code هذه الملاحظة عمدًا بدل إعادة الإرسال، لأن الإعادة قد تنفّذ الاستدعاءات نفسها للأدوات مرتين. والناقص على الأرجح هو الجُمل الأخيرة فقط أو آخر استدعاء لأداة.
Q2. بماذا أرد لأستأنف من حيث توقّف؟
ردّ بكلمة continue. هذه هي خطوة الاستعادة التي يسمّيها مرجع الأخطاء الرسمي. أما إعادة إرسال التعليمات الأصلية فتخاطر بتكرار عمليات نُفِّذت بالفعل.
Q3. هل تضيع الرموز (tokens) هدرًا؟
ما تولّد حتى لحظة الانقطاع قد استُهلك. ويذكر صاحب البلاغ #69336 أن الرموز المستهلكة لا تُسترد. ولهذا تحديدًا فإن استخدام continue بدل البدء من جديد مهم من ناحية الكلفة كما من ناحية الوقت.
Q4. هل هذا هو نفسه «Response stalled mid-stream»؟
لا. فبحسب التعريفات الرسمية، Connection closed تعني «انقطع الاتصال»، وResponse stalled تعني «توقّف التدفق عن إرسال البيانات» — قطعٌ مقابل صمت. يتشابهان على الشاشة، لكن صيغة stalled وردت مقترنةً بحلقة تكرار في النموذج، وعلاجها مختلف. راجع مقال Response stalled mid-stream.
Q5. هل شبكتي هي المسؤولة؟
ربما، لكن ليس بالضرورة. فصاحب البلاغ #69415 واجهه على اتصال مباشر بلا بروكسي ولا جدار حماية، وتشير حزم البلاغ #67766 إلى أن الإغلاق بدأ من جهة الخادم. تجاوز أي بروكسي أو VPN أولًا وتحقّق من التكرار؛ فإن لم يتغيّر شيء، فالمشكلة ليست محلية بحتة.
Q6. هل يحلّ تحديث Claude Code المشكلة؟
هو أعلى الإجراءات مردودًا لتجرّبه أولًا. يُظهر سجل التغييرات الرسمي أن 2.1.198 أصلح «إسقاط الدور بسبب انقطاعات شبكة قصيرة في منتصف الرد»، وأن 2.1.214 غيّر مجمّع keep-alive ليُعطَّل بعد خطأ «اتصال قديم» فتفتح إعادة المحاولة مقبسًا جديدًا. وتجمّع البلاغات (2.1.173 إلى 2.1.183) أقدم من ذلك كله. لكن بما أن أي بند في السجل لا يذكر «Connection closed» بذاته، فإن التحديث تحسّن مرجّح لا علاج مضمون.
Q7. يتكرّر باستمرار في المهام الطويلة. هل من حل بديل؟
تقسيم المهمة ليكون كل رد أقصر هو الخيار الأوثق. فالأعمال الدفعية من نوع «اقرأ كل الملفات الكبيرة واكتب التقرير» تُبقي التدفق مفتوحًا طويلًا؛ وفصل القراءة عن الكتابة يقلّص هذه النافذة ويخفض احتمال مصادفة انقطاع. كما يفيد البلاغ #69336 بأن بدء محادثة جديدة ساعد مؤقتًا.
Q8. كمطوّر، كيف أمنع ذلك في تطبيقي؟
إرشادات توثيق Claude API الرسمي واضحة: (1) استخدم التدفق دائمًا للردود الطويلة، وفكّر في Batches API لما يتجاوز 10 دقائق؛ (2) اضبط TCP keep-alive (حِزم SDK الرسمية تفعل ذلك أصلًا)؛ (3) مع SSE قد تصل الأخطاء بعد 200، فعالِج أحداث الخطأ داخل التدفق على حدة؛ (4) عند الانقطاع، احتفظ بما استلمته واطلب البقية. وأرفِق request_id عند مراسلة الدعم.
Q9. يظهر لي الخطأ نفسه في Claude Cowork وAgent SDK.
الرسالة نفسها وردت هناك أيضًا. فالبلاغ #69517 يرصده في Claude Cowork (وأُغلق باعتباره مكرّرًا)، والبلاغ #69336 عبر Claude Agent SDK مستضاف ذاتيًا. إنه سلوك الطبقة التي تتعامل مع الردود المتدفقة، فالنهج واحد: الاستئناف بدل إعادة البدء، والبقاء على إصدار حديث، وتصميم إعادة المحاولة جيدًا.
مقالات ذات صلة
- خطأ Response stalled mid-stream وحلقة «court» في Claude Code: الأسباب والحل
- أخطاء الاتصال والشبكة في Claude Code: إعداد البروكسي (proxy) وشهادات TLS
- أخطاء خادم Claude Code «529 Overloaded» و«500»: الأسباب والحلول
- خطأ Claude Code «Prompt is too long»: أسباب وحلول خطأ نافذة السياق
- أخطاء Claude Code الشائعة وحلولها — المرجع الكامل
