المحتويات

عندما تُسند إلى 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) التمييز عن رسائل أخرى شديدة الشبه. وحيثما دخل التخمين وضعتُ في موضعه وسمًا يبيّن درجة التأكد.

الخلاصة أولًا
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 متابعة الرد من تلقاء نفسه — حتى ثلاث مرات متتالية كحد أقصى. ولا تظهر هذه الملاحظة إلا بعد استنفاد تلك المتابعات. والوكلاء الفرعيون يواصلون تلقائيًا بالطريقة نفسها.

2. التعريف الرسمي — الرسائل الأربع للانقطاع في منتصف الرد

أول ما ينبغي إدراكه أن هذه العبارة ملاحظة يضيفها Claude Code من عنده، وليست نصّ استجابة خطأ أعادتها الواجهة البرمجية. ولذلك، رغم أن التجربة واحدة، فإن 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 أن الحاسوب دخل في وضع السكون أثناء الرد. وبعد الاستيقاظ يعتبر الاتصال تالفًا فيتوقف عن القراءة.

صمت لا انقطاع
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 والمقالات الشارحة دفعة واحدة. والحدث واحد، فلا حاجة إلى إعادة تأويل.

تصلح مؤشرًا على الإصدار

إذا ظهرت lost فأنت على نسخة v2.1.227 أو أحدث من Claude Code. وإذا ظهرت closed فهي أقدم من ذلك.

تفيد في كشف البلاغات المكرّرة

الظاهرة الواحدة مُبلَّغ عنها باسمين، فالبحث في البلاغات لا بد أن يشمل الصيغتين معًا وإلا فاتتك بلاغات قائمة.

🟡 لا ذكر لذلك في سجل التغييرات. إعادة التسمية مكتوبة في الوثائق الرسمية فقط، وفي حدود ما تحققتُ منه لا يتضمن بند v2.1.227 في سجل التغييرات الرسمي أي إشارة إلى تغيير الصياغة. ومن وجهة نظر المستخدم يبدو الأمر كأن الكلمة تبدّلت فجأة ذات يوم. فلا تستنتج من تغيّر المعروض أن «خطأً جديدًا مختلفًا قد ظهر».

⚠️ قبل v2.1.222 قد يكون البلاغ نفسه كاذبًا. ينصّ مرجع الأخطاء الرسمي على أن «Claude Code في الإصدارات السابقة لـ v2.1.222 كان يُظهر هذا الإشعار أيضًا حين ينقطع الاتصال أو يتوقف بعد اكتمال الرد، فيُبلّغ عن الدور كخطأ رغم أن الرد كامل». أي أن النسخ القديمة قد تعرض الخطأ وحده بينما وصلت المخرجات كلها. فإذا كان ناتج claude --version أصغر من 2.1.222، فحدِّث قبل أن تبدأ العزل — إذ قد يكون الخطأ الذي تراه غير موجود أصلًا.

4. لماذا لا تُعاد المحاولة تلقائيًا

ليس صحيحًا أن Claude Code لا يفعل شيئًا. فبحسب فقرة «Automatic retries» في المرجع الرسمي، تُعاد المحاولة تلقائيًا على حالات الفشل العابرة حتى عشر مرات بتراجع أسّي. وظهور هذه الرسالة رغم ذلك يعني أن Claude Code حكم بأن هذا موضع لا يجوز فيه إعادة المحاولة.

والفارق يقوم على نقطة واحدة فقط: «هل أنجز Claude شيئًا بالفعل؟»

تُعاد المحاولة
انقطاع قبل اكتمال أي شيء

إذا سقط الاتصال قبل أن يُنهي Claude أي جزء من الرد بما في ذلك التفكير، فإن Claude Code يعيد إرسال الطلب بالتراجع نفسه ويستمر الدور. والأمر كذلك حتى لو كان النص قد بدأ في التدفق.

وإذا انتهى التفكير ولم يبدأ نص ولا استدعاء أداة، فإنه يعيد الإرسال مرتين على الأكثر بفواصل قصيرة، فإن استمر السقوط أنهى الدور برسالة 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 الاتصال المتوقف. وبحسب الوثائق الرسمية كانت هذه العتبة 10 ثوانٍ قبل v2.1.185 بصياغة مختلفة أيضًا.

5. أين ينقطع الاتصال — الطبقات الثلاث

عبارة «الاتصال انقطع» وحدها لا تحدد ما تفعله. ومواضع الانقطاع المحتملة ثلاثة في الأساس، ولكلٍّ منها طريقة تحقّق مختلفة.

الطبقة 1
جهازك وخط الاتصال

تبديل شبكة Wi-Fi، وانقطاع لحظي في شبكة الهاتف، والسكون، وإعادة اتصال عميل VPN.

طريقة التحقق: جرّب اتصالًا سلكيًا أو خطًا آخر وانظر هل يتكرر. وإن كان السبب السكون فستظهر صياغة مخصصة له، وبها يتم العزل.

الطبقة 2
المسار: الوسيط والبوابة

وسيط الشركة، وفحص TLS، وبوابات نماذج اللغة، وشبكات VPN. وليس نادرًا أن يعتبر جهازٌ بثًا مفتوحًا لوقت طويل خاملًا فيقطعه.

طريقة التحقق: أزل HTTPS_PROXY وانظر هل يتكرر. وتحقّق من سطر الوسيط عبر /status.

الطبقة 3
جانب الخادم وإعادة استخدام الاتصال

عطل في الخدمة، أو اتصال معاد استخدامه وهو في الحقيقة ميت. وعلامتها أن خط اتصالك سليم ومع ذلك يستمر السقوط.

طريقة التحقق: راجع status.claude.com. وإذا تكرر الأمر نفسه على خطوط متعددة فالمشكلة ليست عندك وحدك.

احتمال رابع يسهل إغفاله: تدوير شهادات mTLS. في بيئات المؤسسات التي تستخدم شهادة عميل، يؤدي استبدال الشهادة والمفتاح إلى أخطاء على مستوى الاتصال مثل إعادة تعيين الاتصال أو فشل مصافحة TLS. وبحسب وثيقة إعدادات الشبكة الرسمية، فإن Claude Code يعيد قراءة الملفين عند أخطاء الاتصال هذه ثم يعيد المحاولة بالزوج الجديد. غير أن إعادة القراءة هذه سلوك v2.1.232 وما بعده، وقبله كان يتمسك بالزوج القديم حتى إعادة التشغيل أو إعادة تطبيق الإعدادات. ويمكنك التأكد بالنظر هل يظهر Stale connection — reloaded rotated mTLS client material في سجل claude --debug.

6. ما تجرّبه الآن — قائمة تحقّق للعزل

الترتيب من أعلى إلى أسفل هو ترتيب الأثر الأكبر بالجهد الأقل. تحقّق بعد كل خطوة هل تتكرر المشكلة.

# ما تفعله الغرض
1أجب بكلمة continueلا تُثبّت الخسارة أولًا. أسرع من الإعادة من البداية وبلا خطر تنفيذ مزدوج
2حدِّث Claude Code إلى أحدث إصدارسلوك الاتصال يتغيّر بتغيّر الإصدار. أصلح v2.1.198 مشكلة «انقطاع شبكي قصير في منتصف الرد يقطع الدور»
3جزّئ الدور الواحدافصل «اقرأ ملفات كثيرة ثم اكتب تقريرًا» إلى قراءة ثم كتابة. تُقلّل بذلك زمن بقاء البثّ مفتوحًا نفسه
4أوقف VPN والوسيط وأعد المحاولةعزل الطبقة 2. إن زال العطل بإيقافهما فاشتبه في قطع الخمول على المسار
5جرّب خط اتصال آخرعزل الطبقتين 1 و3. إن تكرر على خطوط متعددة فالمشكلة ليست عندك وحدك
6راجع إعدادات السكونإن كانت الشاشة تنطفئ في منتصف رد طويل، فقد يتلف الاتصال قبل ظهور الصياغة المخصصة للسكون
7راجع status.claude.comتأكيد الطبقة 3. وعند الخطأ 529 يعرض Claude Code نفسه اسم هذا المضيف على الشاشة
8سجّل بأمر claude --debugيخرج السجل إلى ~/.claude/debug/<session-id>.txt. أرفقه عند تقديم بلاغ
9تأكّد أنك لا تستخدم وسيط SOCKSتنصّ الوثائق الرسمية صراحةً على عدم دعم وسطاء SOCKS. فإن كنت تستخدمه فانتقل إلى مسار آخر
«لكن Claude في المتصفح يعمل بخير» ليست دليلًا يُبنى عليه. فمحادثة claude.ai وواجهة Claude Code في الطرفية تختلفان في طريقة إقامة الاتصال وفي مدة إبقاء الاتصال الواحد مفتوحًا. ومن الوارد جدًا أن تسلم إحداهما وتسقط الأخرى وحدها، وقد أبلغ البلاغ ‎#85979 المذكور لاحقًا عن هذه الحالة بالضبط. فلا تجزم بأن «الحساب سليم إذن المشكلة في الإعدادات».

7. ضبط المؤقتات وإعادة المحاولة بمتغيرات البيئة

يملك Claude Code أربعة مؤقتات مستقلة لقطع البثّ الذي صمت. وهذه هي القائمة كما تسردها وثيقة إعدادات الشبكة الرسمية.

المؤقّت شرط القطع المهلة الافتراضية
First-byte deadline لم تصل بعد الإرسال أي ترويسة استجابة 180 ثانية مع الواجهة المباشرة و300 ثانية فيما عداها، مع ثانية إضافية لكل 32KB من جسم الطلب
Event-level watchdog تعذّر تحليل أي حدث من أحداث الاستجابة 300 ثانية، ويعمل مع كل المزوّدين
Byte-level watchdog لا تصل أي بايتات إطلاقًا، بما فيها نبضات إبقاء SSE حية 180 ثانية مع الواجهة المباشرة و300 ثانية فيما عداها
Body idle timeout لا تصل بايتات لمدة خمس دقائق 5 دقائق، وهي موجّهة للمزوّدين غير الواجهة المباشرة

غير أن نتيجة قطع هذه المؤقتات تكون في الأصل من صياغة جانب «الصمت» — وهي غير رسالة هذا المقال. وسبب إدراجها هنا أن معرفة القيم الافتراضية لازمة للتمييز بين الحالتين، لا أن نقول «ظهرت lost فلنُطِل المؤقتات». أما في بيئة يقع فيها صمت طويل عبر وسيط، فتعديل هذه القيم يغيّر أعراض جانب التوقف.

وأما جانب إعادة المحاولة فيُضبط بالمتغيرات التالية.

متغير البيئة الافتراضي الأثر
CLAUDE_CODE_MAX_RETRIES 10 عدد مرات إعادة المحاولة. والحد الأقصى 15 منذ v2.1.186. ويُنصح في السكربتات بخفضه ليفشل سريعًا
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 رصد 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 وحده. وفي البلاغات العلنية بلاغان بذلا قدرًا كبيرًا من التحقق. وكلاهما مقدَّم إما بالاسم الجديد الوارد في هذا المقال، أو يتضمن صياغة الإصدار الذي سبقه مباشرة.

البلاغ ‎#86473، الإصدار v2.1.229 على Windows 11
HTTPS الخام يمرّ والطرفية وحدها تنقطع

يكتب مقدّم البلاغ أن Connection dropped (ECONNRESET) · Retrying in 17s · attempt 6/10 تظهر ثم تعقبها API Error: Connection lost mid-response.. ويذكر مع ذلك أن طلب POST بحجم 60KB عبر curl، وطلبًا بالحجم نفسه عبر https.request في Node.js الخام، اكتملا كلاهما بنجاح، وأن بثًا طويلًا من نوع SSE من مضيف آخر لم ينقطع.

وبعد فحص MTU وفحص Winsock LSP والتكرار بأدنى إعداد ممكن والتكرار على شبكتين لا صلة بينهما، بقي الأمر بلا حل. والبلاغ ‎#86473 موسوم كمكرّر ومع ذلك ما زال مفتوحًا.

البلاغ ‎#85979، الإصدار v2.1.228 على Windows 11
نسخة المتصفح سليمة على الجهاز نفسه

وهنا تظهر Connection dropped (ECONNRESET) · Retrying in 0s · attempt 4/10. ويكتب مقدّم البلاغ أنه بعد إزالة برنامج الحماية إزالةً كاملة ومعالجة مرشّح VPN والوسيط وIPv6 وإعادة تعيين Winsock، تكرر العطل بالطريقة نفسها على ثلاث شبكات: واي فاي العمل وواي فاي المنزل ومشاركة اتصال الهاتف.

ويعرض مقابلةً مفادها أن محادثة claude.ai تعمل بلا مشكلات على الجهاز نفسه وبالحساب نفسه. والبلاغ ‎#85979 أيضًا ما زال مفتوحًا وموسومًا بالركود.

🟡 عن درجة التأكد في هذا الفصل. البلاغان أعلاه كلاهما رواية فردية، وليسا شرحًا رسميًا من Anthropic للسبب. ففي ‎#85979 يكتب مقدّم البلاغ أن الدعم أخبره بأن «العطل المتعلق بإعادة استخدام اتصال قديم يُفترض أنه أُصلح منذ v2.1.227»، لكن العطل تكرر بعد التحديث — وهذا نقلٌ من مقدّم البلاغ لمراسلاته مع الدعم، لا موقف رسمي منشور. وكذلك فترتا العطل المذكورتان في ‎#86473 هما مما يقول مقدّم البلاغ إن الدعم أبلغه به. فلا تقرأ ذلك على أنه حدث تأكدت شروط تكراره.

ومع ذلك يمكن استخلاص فائدة عملية من البلاغين: «ping يمرّ» و«curl يمرّ» ليسا دليلًا على أن هذا الخطأ لا يقع. فالاتصال الذي يُبقي قناة واحدة مفتوحة عدة دقائق في وضع البثّ تختلف ظروفه عن طلب قصير. وبدل صبّ الوقت في فحص شبكتك، تجزئة الدور أسهل في خفض معدل التكرار.

10. ما هو مؤكد وما لم يتأكد بعد

تجنّبًا للالتباس، أفصل ما يمكن التحقق منه رسميًا عمّا سواه.

✅ ما يمكن التحقق منه رسميًا
  • هذه الصياغة واردة رسميًا في مرجع الأخطاء ومعناها «الاتصال انقطع»
  • قبل v2.1.227 كانت تُعرض باسم Connection closed mid-response، وهي إعادة تسمية للشيء نفسه
  • المخرجات التي وصلت جزئيًا يُحتفظ بها عمدًا، لأن إعادة الإرسال قد تُنفّذ العملية مرتين
  • خطوة الاستئناف هي الرد بكلمة continue
  • الانقطاع قبل ظهور المخرجات تُعاد فيه المحاولة تلقائيًا، حتى عشر مرات بتراجع أسّي
  • الجلسات غير التفاعلية والوكلاء الفرعيون يواصلون من تلقاء أنفسهم، منذ v2.1.246 وv2.1.257 على الترتيب
🟡 مُبلَّغ عنه لكنه غير مؤكد
  • سلامة HTTPS الخام مع سقوط الطرفية وحدها بـ ECONNRESET، بحسب بلاغي ‎#86473 و‎#85979
  • سلامة نسخة المتصفح على الجهاز نفسه والحساب نفسه، بحسب بلاغ ‎#85979
  • احتمال تورّط عطل يتعلق بإعادة استخدام الاتصال، نقلًا عن شرح للدعم أورده مقدّم البلاغ
  • الإشارة إلى وجود عطل في جانب الخادم في تواريخ بعينها، نقلًا عن مقدّم البلاغ كذلك
🔴 غير منشور حتى كتابة المقال
  • شرح رسمي للسبب من Anthropic، إذ لا رد علنيًا على البلاغين أعلاه
  • سبب إعادة التسمية. ولا أثر لذكر تغيير الصياغة في سجل التغييرات
  • البلاغان ‎#86473 و‎#85979 كلاهما ما زال مفتوحًا

وخلاصة الأمر أن العرض والمعنى وخطوة الاستئناف موثّقة رسميًا، أما شرح سبب الانقطاع فلم يصدر بعد. والفعّال يقينًا في هذا الوضع ليس تحديد السبب بل أسلوب عمل يُقلّل الخسارة عند الانقطاع — تجزئة الدور، والتقدّم في العمليات ذات الأثر الجانبي مع التحقق من الحالة، وإبقاء الإصدار حديثًا. وهذه الثلاثة تنفع أيًّا كان السبب.

الأسئلة الشائعة

س1. هل «Connection lost mid-response» و«Connection closed mid-response» خطآن مختلفان؟

هما الشيء نفسه. وكما ينصّ مرجع الأخطاء الرسمي، كان الحدث نفسه يُعرض قبل v2.1.227 باسم Connection closed mid-response. وتغيّر المعروض لا يعني أن نوعًا جديدًا من الأعطال قد ظهر. وما كُتب بالاسم القديم يبقى صالحًا للرجوع إليه كما هو.

س2. هل تضيع المخرجات السابقة؟

لا تضيع. كل كتلة أنهاها Claude تبقى. والذي يُرمى هو الكتلة الأخيرة وحدها إن كانت جارية لحظة انتهاء الدور. وسبب امتناع Claude Code عن إعادة الإرسال وإلحاقه هذه الملاحظة بدلًا من ذلك هو احتمال تنفيذ استدعاء الأداة نفسه مرتين.

س3. بماذا أجيب لأستأنف من حيث توقف؟

أجب بكلمة continue. هذه هي خطوة الاستئناف التي يوجّه إليها مرجع الأخطاء الرسمي، وهي تجعله يواصل من آخر كتلة اكتملت. أما إعادة كتابة التعليمات من البداية فقد تُكرّر عمليات سبق تنفيذها.

س4. هل يُصلح الأمرَ رفعُ عدد مرات إعادة المحاولة؟

لا يُصلحه. فكما في الفصل 4، هذه ملاحظة تخصّ موضعًا يتجنّب فيه Claude Code إعادة المحاولة عمدًا. وCLAUDE_CODE_MAX_RETRIES، الافتراضي 10 وحده الأقصى 15 منذ v2.1.186، ينفع في الفشل من نوع «السقوط قبل ظهور المخرجات». والنافع هنا هو تقصير الدور الواحد.

س5. هل الأمر نفسه مع -p ومع CI، أي التشغيل غير التفاعلي؟

السلوك مختلف. فبحسب المرجع الرسمي، في الجلسات غير التفاعلية، إذا كان الرد المنقطع نصًا خالصًا لا يتضمن استدعاء أداة، يطلب Claude Code المتابعة من تلقاء نفسه حتى ثلاث مرات متتالية. ولا تظهر هذه الملاحظة إلا بعد استنفاد ذلك. وقبل v2.1.246 كان الدور ينتهي عند أول انقطاع. وإذا كنت تستخدم --output-format json فإن هذه الرسالة تدخل في حقل result.

س6. تظهر لي أيضًا في الوكلاء الفرعيين، أي Task.

الوكلاء الفرعيون يواصلون تلقائيًا كذلك. فإن كان الرد المنقطع نصًا خالصًا، يطلب Claude Code من الوكيل الفرعي المتابعة، ولا تصير هذه الملاحظة الرسالة الأخيرة إلا بعد استنفاد المتابعات. وقبل v2.1.257 كانت الملاحظة تظهر عند أول انقطاع.

س7. هل شبكتي هي السبب؟

هذا وارد، لكنه ليس الاحتمال الوحيد. فمقدّم البلاغ ‎#86473 يبيّن أن طلبي POST بالحجم نفسه، أحدهما عبر curl والآخر عبر Node.js الخام، يكتملان كلاهما، ومع ذلك تسقط الطرفية وحدها. فتحقّق أولًا هل يتكرر العطل بعد إيقاف VPN والوسيط، ثم جرّب خطًا آخر. فإن لم يتغيّر شيء في الحالتين، فالمشكلة ليست عندك وحدك.

س8. هل تقلّ إن أطلتُ المهلة؟

بالنسبة إلى هذه الرسالة لا يُنتظر ذلك. لأن الحكم هو أن الاتصال نفسه فُقد، لا أن الوقت نفد. أما إطالة المؤقتات مثل CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS فتنفع مع The response stopped arriving، أي مع العرض الذي يبقى فيه الاتصال حيًّا لكنه يصمت.

س9. كيف أتحقق من الإصدار الذي أستخدمه؟

يمكنك التحقق بأمر claude --version. فإن ظهرت على الشاشة lost فأنت على v2.1.227 أو أحدث، وإن ظهرت closed فأنت على ما قبلها. وسلوك الاتصال يتغيّر بتغيّر الإصدار، وسجل التغييرات الرسمي يذكر أن v2.1.198 أصلح «مشكلة انقطاع شبكي قصير في منتصف الرد يقطع الدور». والتحديث خطوة تستحق أن تُجرَّب أولًا، لكنه ليس ضمانًا للعلاج الجذري — فالبلاغان المذكوران أعلاه كلاهما على إصدارات أحدث من ذلك.

س10. تتكرر كثيرًا على شبكة مؤسستي. ما الإعدادات التي أراجعها؟

تُلخّص وثيقة إعدادات الشبكة الرسمية النقاط الجوهرية، وهي ثلاث: (1) وسطاء SOCKS غير مدعومين فلا تستخدمها، (2) ضع متغيرات الوسيط في كتلة env داخل ~/.claude/settings.json لا في تصدير من الصدفة، لأن بيئة الصدفة لا تصل إلى الوكلاء العاملين في الخلفية، (3) إن كنت تستخدم mTLS فانتبه إلى تدوير الشهادات. ويمكنك التأكد من قراءة الإعدادات عبر سجل claude --debug أو عبر ما يعرضه /status.

مقالات ذات صلة

المصادر الأولية المعتمدة