هل يستمر فشل الرفع؟ إصلاح أخطاء نقل الملفات الشائعة

الرفع الفاشل يقع في الغالب في إحدى خمس فئات: عدم استقرار الشبكة (انقطاع Wi-Fi أو إعادة توجيه ISP)، أو استنفاد ذاكرة المتصفح (Chrome يقتل تبويباً عند 2 جيجابايت من RAM)، أو تقييد معدل الخدمة أو الحصة، أو ملف مصدر تالف، أو برنامج مكافحة فيروسات أو جدار حماية يحجب الطلبات الصادرة. ابدأ بالتحقق من تبويب Network في DevTools للكود الحقيقي للحالة HTTP في الطلب الفاشل. 413 تعني "الحمولة أكبر من المسموح". 502 أو 503 تعني الخدمة. "ERR_CONNECTION_RESET" تعني شبكتك. لكل منها إصلاح مختلف.

اقرأ الخطأ الفعلي، لا الرسالة العامة

معظم واجهات الرفع تُظهر "فشل الرفع" وتنتهي عند ذلك. هذا عديم الفائدة. افتح DevTools في المتصفح (F12 أو Cmd+Option+I)، وانتقل إلى تبويب Network، وراقب الطلب الفاشل. كود الحالة يُخبرك أين المشكلة: 400-499 تعني جانبك (413 أكبر من المسموح، 401 مصادقة، 403 ممنوع)، 500-599 تعني جانبهم (502 بوابة سيئة، 503 تباطأ، 504 انتهت المهلة). أخطاء الاتصال مثل ERR_CONNECTION_RESET أو net::ERR_NETWORK_CHANGED تعني أن اتصال TCP مات منتصف النقل.

التقط لقطة شاشة للطلب الفاشل ورأسيات الاستجابة قبل إغلاق أي شيء. إذا تصعّدت الأمر إلى الدعم، تلك الرأسيات عادةً تُحدد المشكلة.

انقطاع Wi-Fi: القاتل الصامت

رقاقات Wi-Fi في الحواسيب المحمولة تتجوّل أحياناً بين نقاط الوصول وبين النطاقات (2.4 جيجاهرتز و5 جيجاهرتز). كل تجوّل يُوقف اتصال TCP لجزء من الثانية، مما يقتل رفعاً ذا تدفق واحد. خدمات الرفع التي تُطبّق الرفع المجزأ القابل للاستئناف (المبنية على tus.io، وS3 multipart) تصمد أمام هذا؛ رفعات POST الواحدة لا تصمد.

إن استطعت التوصيل بالكابل، افعل. Ethernet لا يتجوّل. إذا تعذّر عليك ذلك، على الأقل ابقَ في الغرفة ذاتها وأوقف "Auto-switch SSID" أو توجيه نطاق الشبكة المتكاملة أثناء الرفع. شغّل ping مستمراً إلى 1.1.1.1 في طرفية أخرى وراقب الانقطاعات؛ تلك الانقطاعات هي حيث تموت رفعاتك.

أعطال المتصفح وطرد التبويب

Chrome يقتل التبويبات حين تتجاوز عتبة الذاكرة، عادةً نحو 2 إلى 4 جيجابايت لكل تبويب تبعاً لـ RAM المتاحة. رفع ملف 10 جيجابايت عبر متصفح يُخزّن الكل في الذاكرة (تطبيق سيء) سيتعطل. الرفع عبر متصفح يُدفق الأجزاء (تطبيق جيد يستخدم slice() في File API) يستهلك بضع مئات من الميجابايتات بصرف النظر عن حجم الملف.

إذا كان متصفحك يتعطل باستمرار على الرفعات الكبيرة، جرّب Firefox الذي تاريخياً يتعامل مع رفعات File API الكبيرة بضغط ذاكرة أقل من Chromium. تأكد أن الخدمة تستخدم الرفع المجزأ؛ إذا كان ملف 5 جيجابايت يُحمَّل في Blob واحد قبل POST، ذاك هو مشكلة التصميم.

أغلق كل تبويب آخر. أعِد تشغيل المتصفح قبل البدء. أوقف الإضافات (أحياناً يُدخل حاجبو الإعلانات وإضافات الخصوصية ومديرو كلمات المرور في تدفقات الرفع ويكسرونها).

جدران الحماية المؤسسية والخوادم الوسيطة

غالباً تُشغّل الشبكات المؤسسية فحص عميق للحزم، أو تشكيل حركة المرور، أو خوادم وسيطة تُدخل شهادات. الأعراض: الرفعات تنجح للملفات الصغيرة لكن تفشل عند حجم بعينه (كثيراً ما يكون 100 ميجابايت أو 1 جيجابايت)، أو الخطأ يقرأ "SSL handshake failed" أو "certificate verification failed".

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

أجهزة Zscaler وCisco Umbrella وPalo Alto من الجناة الشائعين. كثيراً ما تفحص الملفات فوق عتبة حجم وتنتهي مهلتها على التدفقات الكبيرة.

فحص مكافحة الفيروسات للتدفق الصادر

يمكن لـ Windows Defender وBitdefender وNorton وKaspersky فحص حركة HTTPS الصادرة باعتراض TLS. على الرفعات الكبيرة، يمكن أن يُبطّئ الفحص نفسه الإنتاجية 40 إلى 60%، وعلى بعض الإصدارات يُدخل مهلات تقتل الاتصال.

عطّل الحماية الويب الفورية مؤقتاً (لا برنامج مكافحة الفيروسات كاملاً، فقط مكوّن فحص HTTPS) وأعِد المحاولة. إذا نجح الرفع، أضف نطاق خدمة النقل إلى قائمة استثناءات مكافحة الفيروسات. لا تترك حماية الويب معطّلة بشكل دائم.

حدود معدل جانب الخادم

إذا كنت تحصل على استجابات 429 أو 503، الخدمة تُقيّد معدلك. الأسباب المحتملة: تُشغّل أجزاءً متوازية كثيرة جداً (تراجع إلى 4 عمال من 8)، أو وصلت إلى حصة يومية للخطة المجانية (WeTransfer المجانية تحد بـ 2 جيجابايت لكل نقل لكن لها حدود حجم يومية ضمنية)، أو أنت على IP مشترك تم الإبلاغ عنه (شائع على Wi-Fi الفنادق والمقاهي التي جرى إساءة استخدامها).

انتظر 15 دقيقة وأعِد المحاولة. أو بدّل الشبكات. أو بدّل الخدمات.

الملف المصدر التالف

نادراً، الملف نفسه هو المشكلة. تلف نظام الملفات (قطاع سيء على محرك خارجي، أو نسخ متقطع) ينتج ملفاً يُقرأ جيداً للـ MB الأوائل ويُعيد أخطاء I/O بعدها. يتوقف الرفع عند نسبة مئوية ثابتة في كل إعادة محاولة.

اختبر بنسخ الملف إلى قرص محلي مختلف أولاً. إذا فشلت النسخة عند النسبة المئوية ذاتها، هو المصدر. شغّل chkdsk على Windows أو diskutil verifyDisk على macOS على المحرك المصدر. للملفات الحيوية، استرد من نسخة معروفة جيدة قبل محاولة الرفع مجدداً.

أخطاء التاريخ والوقت وشهادات TLS

إذا كانت ساعة نظامك خاطئة بأكثر من بضع دقائق، يفشل التحقق من شهادة TLS وتُخطئ الرفعات بـ "certificate not yet valid" أو ما شابهها. تُزامن أجهزة Mac وWindows عادةً عبر NTP تلقائياً، لكن بعد نوم طويل أو بطارية لوحة أم فارغة، تنحرف الساعات.

أجبر على مزامنة NTP: sntp -sS time.apple.com على macOS، أو Settings > Time & language > Date & time > Sync now على Windows.

شبكات VPN التي تفشل بصمت

بعض عملاء VPN (خاصةً المجانيين) تقطع اتصالات TCP الطويلة بعد 5 إلى 10 دقائق لأن رموز جلستهم تُجدَّد. رفع 2 جيجابايت يستغرق 20 دقيقة يموت عند تجديد الرمز بصمت. إما تحوّل إلى VPN مدفوع بتعامل أفضل مع الجلسة (Mullvad وProtonVPN وIVPN)، أو افصل VPN أثناء الرفع إذا كانت الخدمة مشفّرة TLS من طرف إلى طرف أصلاً.

الخدمات المشفّرة شاملاً تعني أنك لا تحتاج الـ VPN للسرية أثناء النقل نفسه. HexaTransfer مثلاً تُشفّر بـ AES-256-GCM من جانب العميل قبل مغادرة الملف متصفحك، فإضافة تشفير VPN فوق ذلك تدابير وقاية مضاعفة لا ضرورة مطلقة.

جرّب خدمة تُعيد المحاولة للأجزاء تلقائياً

إذا أصلحت المشاكل المحلية الواضحة ولا تزال الرفعات تفشل، ربما الخدمة نفسها لا تتعامل مع الانقطاعات جيداً. الخدمة ذات إعادة المحاولة التلقائية لكل جزء وحالة الجلسة القابلة للاستئناف تستمر في العمل خلال التقلبات (تجوّل Wi-Fi، أو إعادة توجيه ISP قصيرة) التي تقتل مُرفِعات التدفق الواحد. HexaTransfer تُشغّل الرفع المجزأ المتوازي مع إعادة المحاولة لكل جزء وتصمد أمام معظم الأحداث الشبكية القصيرة دون أي تدخل يدوي.

جرّبها على hexatransfer.com — مجاني، بدون حساب، حتى 10 جيجابايت.