حل ERR_CONNECTION_RESET و PR_CONNECT_RESET_ERROR خطوة بخطوة
محتوى الدليل
يعني ERR_CONNECTION_RESET أن المتصفح بدأ الاتصال بالموقع، لكن الاتصال أُغلق فجأة قبل وصول الصفحة. في Firefox قد ترى PR_CONNECT_RESET_ERROR، وفي Edge أو Chrome قد تظهر عبارة “the connection was reset”. الاسم مختلف، لكن التشخيص واحد: هل الانقطاع من المتصفح، الشبكة، DNS، SSL، الجدار الناري، CDN، أم خادم الاستضافة نفسه؟
هذا الدليل يرتب الفحص من الأسهل إلى الأعمق. سنبدأ بخطوات الزائر لأنها سريعة ولا تغيّر الموقع، ثم ننتقل إلى الدومين وSSL والحماية والاستضافة. الهدف ليس حذف الكاش عشوائياً أو تعطيل كل شيء، بل تحديد الطبقة التي تقطع الطلب وإصلاحها بدون خلق مشكلة جديدة.
ماذا يعني ERR_CONNECTION_RESET فعلياً؟
تحميل أي صفحة يمر عبر DNS، ثم اتصال TCP، ثم تفاوض TLS في حالة HTTPS، ثم طلب HTTP، ثم رد الخادم. خطأ reset يعني غالباً أن طرفاً من هذه الأطراف أغلق الاتصال بالقوة قبل اكتمال السلسلة. المتصفح يعرض العرض النهائي فقط، ولذلك قد يظهر الخطأ نفسه بسبب راوتر، VPN، مضاد فيروسات، شهادة SSL، قاعدة حماية، أو ضغط زائد على الخادم.
أول دليل هو نطاق المشكلة. إذا تعطلت كل المواقع فالجهاز أو الراوتر أو DNS أو VPN أو مزود الإنترنت هو الاحتمال الأقوى. إذا تعطل موقع واحد عند الجميع فراجع الاستضافة وSSL وDNS والجدار الناري. وإذا تعطل موقع واحد عندك فقط، فابدأ بالمتصفح والإضافات والبروكسي والأدوات الأمنية واحتمال حظر عنوان IP الخاص بك.
- متصفح واحد: افحص الإضافات والكوكيز والكاش وإعدادات البروكسي داخل ذلك المتصفح.
- جهاز واحد: راجع DNS المحلي وVPN ومضاد الفيروسات وإعدادات الشبكة.
- شبكة واحدة: أعد تشغيل الراوتر وجرّب DNS مختلفاً أو اتصال الهاتف.
- موقع واحد: راجع SSL وCDN والجدار الناري وسجلات الاستضافة وآخر تعديل.
- كل الزوار: تعامل معها كحادثة خادم وافحص الحمل والسجلات والتوقف أولاً.
إصلاحات المتصفح قبل لمس الخادم
افتح الصفحة في نافذة خاصة، ثم جرّب متصفحاً آخر. إذا اشتغلت الصفحة، فالسبب غالباً حالة المتصفح أو إضافة معينة. عطّل إضافات الإعلانات والخصوصية والحماية والتنزيل والبروكسي مؤقتاً، ثم أعد تفعيلها واحدةً واحدة. لا تبدأ بتغيير إعدادات الموقع قبل أن تتأكد أن الخطأ ليس محلياً.
احذف بيانات الموقع المتأثر فقط: الكوكيز والكاش الخاصان بالنطاق. حذف كل بيانات المتصفح قد يضيّع عليك أدلة مفيدة. أعد التحميل بقوة، وتأكد أن وقت الجهاز صحيح، لأن الوقت الخاطئ يربك التحقق من الشهادات وقد يحوّل مشكلة HTTPS إلى خطأ reset.
إذا ظهر PR_CONNECT_RESET_ERROR في Firefox، انتبه إلى فحص HTTPS بواسطة مضاد الفيروسات أو فلتر الشركة. بعض الأدوات تفك تشفير الاتصال محلياً عبر شهادة خاصة، وإذا تعطلت هذه الشهادة يرفض Firefox الاتصال. اختبر تعطيل فحص HTTPS لمدة قصيرة فقط، ثم أصلح الشهادة أو السياسة ولا تترك الحماية مغلقة.
فحص الشبكة وDNS وVPN والبروكسي
إذا تكرر الخطأ في مواقع كثيرة، أعد تشغيل الجهاز والراوتر. بعد ذلك جرّب نفس الرابط من اتصال الهاتف. إذا عمل عبر الهاتف ولم يعمل عبر Wi-Fi، فالمشكلة غالباً داخل شبكتك. امسح DNS المحلي، وجرّب Resolver موثوقاً، وتأكد أن إعدادات البروكسي ليست مفعلة بلا قصد.
قد يسبب VPN المشكلة إذا كان عنوان الخروج محظوراً أو إذا كانت الحزمة تتساقط داخل النفق. جرّب فصل VPN أو تغيير الدولة. في شبكات الشركات، قد يمنع الجدار الناري نطاقات أو منافذ أو أنماط طلبات معينة. اسأل عن أي حظر جديد قبل أن تغيّر إعدادات الموقع الحي.
- DNS: امسح الكاش وتأكد أن الدومين يشير إلى الخادم الصحيح.
- VPN: افصل النفق أو جرّب منطقة أخرى إذا كان الموقع محظوراً جغرافياً.
- Proxy: أزل أي بروكسي مجهول وتأكد أن الاكتشاف التلقائي مطلوب فعلاً.
- Router: افحص فلاتر الأمان والرقابة الأبوية والقوائم السوداء.
- Hotspot: استخدم بيانات الهاتف للفصل بين مشكلة الشبكة ومشكلة الاستضافة.
أسباب SSL وHTTPS التي تقطع الاتصال
كثير من أخطاء reset تظهر أثناء تفاوض TLS. قد تكون الشهادة منتهية، أو ناقصة السلسلة، أو صادرة لاسم مختلف، أو أن CDN يستخدم وضع SSL غير متوافق مع الخادم الأصلي. كذلك قد تتصارع تحويلات HTTPS بين لوحة الاستضافة وCDN وملف .htaccess وإضافة ووردبريس.
افحص الشهادة على الاسم الكامل، بما في ذلك www والنطاقات الفرعية. إذا نقلت الموقع حديثاً، فقد يذهب بعض الزوار إلى الخادم القديم بسبب DNS cache، وهناك قد لا تطابق الشهادة الدومين. لذلك قد يعمل الموقع عند شخص ويتعطل عند آخر. لا تعتبر هذا سحراً رقمياً؛ غالباً هو DNS أو SSL في مرحلة انتقالية.
في ووردبريس، اجعل تحويل HTTPS في مكان واحد واضح. إذا استخدمت CDN، اختبر الوصول إلى الخادم الأصلي، ثم اضبط SSL mode وقواعد الجدار الناري قبل إعادة CDN. ويمكنك مراجعة دليل تسريع ووردبريس وإدارة الكاش لفهم أثر الكاش والتحويلات المتعددة.
مشاكل الجدار الناري وCDN وإضافات الحماية
قد يقطع الجدار الناري الاتصال عندما يعتبر الطلب مشبوهاً. هذا مفيد أثناء الهجمات، لكنه قد يخطئ بعد تحديث إضافة أو إضافة نموذج أو تغيير REST API أو دخول مدير من شبكة جديدة. راجع سجلات الحماية لمعرفة القاعدة، عنوان IP، الدولة، المسار، أو User-Agent الذي تسبب في الحظر.
لا تعطل كل طبقات الحماية دفعة واحدة. اختبر طبقة واحدة، ثم أعدها. إذا اختفى الخطأ عند إيقاف قاعدة CDN، عدّل تلك القاعدة بدل ترك الموقع مفتوحاً. وإذا ارتبط الخطأ بإضافة ووردبريس، حدّثها أو اسمح بالمسار المحدد. يساعدك دليل صلاحيات مستخدمي ووردبريس على إبقاء الوصول محدوداً أثناء التشخيص.
- سجلات القواعد: ابحث عن الحظر في وقت حدوث الخطأ نفسه.
- استثناء دقيق: اسمح بالمسار المطلوب فقط، لا بكل الموقع.
- Rate limit: تأكد أن الزوار الشرعيين لا يظهرون كعنوان IP واحد خلف بروكسي.
- CDN SSL: وحّد إعدادات HTTPS بين الطرف الخارجي والخادم الأصلي.
- تحديثات الإضافات: راجع آخر تغيير أمني إذا بدأ الخطأ فجأة.
تشخيص الاستضافة والخادم
إذا ظهر الخطأ عند كل الشبكات لموقعك فقط، انتقل إلى الخادم. راجع سجلات الويب وPHP، واستخدام الموارد، وآخر نشر. قد يتسبب حد العمال، انهيار PHP، ضغط قاعدة البيانات، أو نقص الذاكرة في إغلاق الاتصال قبل رجوع خطأ HTTP واضح. أحياناً يرى الزائر reset بينما السجل يوضح السبب الحقيقي.
في بيئة cPanel، افحص Bandwidth وDisk وInodes وإصدار PHP وسجل الأخطاء. إذا رأيت قفزات في الموارد قبل الخطأ، فإما تحتاج تحسين التطبيق أو خطة أوسع. تمنح VavaHost أدوات cPanel وSSL والسجلات ونطاقاً فرعياً مستضافاً مجاناً للاختبار قبل ربط الدومين الحقيقي. ويمكنك مراجعة باقات VavaHost لاختيار موارد تناسب ووردبريس والترافيك والإضافات.
خلاصة عملية
- ابدأ محلياً: اختبر نافذة خاصة ومتصفحاً آخر وVPN وDNS وشبكة ثانية.
- حدّد النطاق: هل المشكلة في جهاز، شبكة، متصفح، أم موقع كامل؟
- افحص HTTPS: راجع الشهادات والتحويلات ووضع SSL في CDN.
- اقرأ السجلات: لا تخمّن قبل مراجعة CDN والجدار الناري وPHP والخادم.
- أصلح بدقة: لا تعطل كل الحماية ولا تمسح كل الكاش بلا دليل.
- خطط للسعة: قلل حمل ووردبريس واختر استضافة تناسب الاستخدام الحقيقي.
حل ERR_CONNECTION_RESET وعبارة “the connection was reset” وPR_CONNECT_RESET_ERROR يصبح سهلاً عندما تتبع مسار الطلب طبقةً طبقة. ابدأ بالمتصفح، ثم DNS وHTTPS، ثم الحماية، ثم سجلات الاستضافة، وستصل إلى سبب واضح بدل مطاردة احتمالات عشوائية.