فعلت الاتصال الآمن ثم ظهر ERR_TOO_MANY_REDIRECTS بدل الموقع؟ غالبا ينتقل المتصفح بين عنوانين يعيدان توجيهه إلى بعضهما. سنوضح كيف تكتشف الحلقة وتراجع مصدر التحويل، بدل الاكتفاء بمسح بيانات المتصفح أو تغيير إعدادات كثيرة معا.
HTTPS هو الاتصال المشفر بين المتصفح والموقع. وقد تفرضه الاستضافة أو إضافة أو خدمة وسيطة مثل Cloudflare. المشكلة ليست في وجود هذه الخدمات معا بحد ذاته، بل في قواعد متعارضة: جهة ترسل الزائر إلى عنوان، وأخرى تعيده إلى العنوان السابق.
كيف نعرف أنها حلقة وليست مشكلة شهادة؟
افتح أدوات المطور أو استخدم فاحص رؤوس HTTP لا يتبع التحويلات تلقائيا. إذا أعاد العنوان الأول Location إلى الثاني، ثم أعاد الثاني إلى الأول، فالمشكلة في قواعد التحويل بين العناوين. أما خطأ الشهادة فيظهر قبل الوصول إلى استجابة HTTP كاملة. سجل البروتوكول والمضيف والمسار في كل قفزة، لأن الحلقة قد تكون بين www وغير www أو بين HTTP وHTTPS أو بين صفحة اللغة والرئيسية.
ترتيب العزل الذي يقلل المخاطرة
- احتفظ بصورة من إعدادات URL في ووردبريس وقواعد الخادم قبل التغيير.
- اختر مصدرا واحدا لإجبار HTTPS: الاستضافة أو Cloudflare أو الخادم. لا تبدأ بثلاثة مصادر متزامنة.
- راجع «عنوان ووردبريس» و«عنوان الموقع» من الإعدادات العامة، وتأكد من البروتوكول والنطاق المقصودين. قد يختلف المسار في بعض التثبيتات، فلا تجعل العنوانين متطابقين بالقوة.
- افحص وضع SSL في الوكيل. وضع يرسل HTTP إلى الأصل بينما الأصل يجبر HTTPS قد يصنع حلقة.
- عطل قاعدة تحويل واحدة مؤقتا، ثم اطلب الرابط دون Cache وسجل السلسلة الجديدة.
- بعد وصول قفزة واحدة إلى 200، أعد تفعيل الكاش وامسحه من طبقة الوكيل والخادم.
أخطاء تجعل التشخيص أصعب
لا تغير home وsiteurl من قاعدة البيانات وwp-config ولوحة التحكم في الوقت نفسه؛ لن تعرف أي قيمة فعالة. لا تحول كل مسار إلى الرئيسية، فهذا يخفي 404 ويخلق إشارات بحث سيئة. ولا تستخدم إضافة SSL لمجرد أن الشهادة موجودة؛ الشهادة والتوجيه وظيفتان مختلفتان. إذا لم تستطع الدخول إلى اللوحة، اطلب من الاستضافة سلسلة التحويلات ورؤوس X-Forwarded-Proto قبل إعطائها صلاحية حذف قواعد عشوائية.
كيف تعرف أن الإصلاح نجح؟
تجربتنا أعادت إنشاء الحلقة وأثبتت أن الطلب يتوقف بسبب كثرة التحويلات؛ لم تكن اختبارا لإصلاح إعداد Cloudflare أو شهادة على استضافة حقيقية. بعد تعديل إعداد موقعك، نفذ الفحوص التالية لتثبت النتيجة لديك.
اختبر الصفحة الرئيسية ومقالا وصفحة الدخول وملف sitemap، ثم تأكد أن كل HTTP ينتقل مرة واحدة إلى HTTPS وأن canonical يستخدم النسخة النهائية. اربط هذا الفحص بخطوات اختبار 301 ثم هدف 200، لأن نجاح التحويل لا يكفي إذا كان الهدف نفسه يعيد تحويلا آخر.
تفاصيل التجربة ونتيجتها
تاريخ التجربة: 19 أغسطس 2026؛ ووردبريس: 7.0.4؛ PHP: 8.3.30؛ مكان التنفيذ وأدواته: خادما PHP محليان على 8787 و8790.
أنشأنا المسارين loop-a وloop-b؛ كل واحد يعيد 302 إلى الآخر. سمح WordPress HTTP API بأربع تحويلات ثم أعاد http_request_failed مع الرسالة Too many redirects.
ما الذي تثبته هذه البطاقة؟
هذه بطاقة اختبار محلي مستقل مسجل بتاريخ 19 أغسطس 2026، وليست قياسا جديدا للموقع المنشور. سمحنا بأربع تحويلات فقط ثم طلبنا الرابط عبر WordPress HTTP API.
التجربة كشفت حلقة مصنوعة ولم تصلح إعداد HTTPS على استضافة حية. بعد معالجة السبب الحقيقي، تحقق من انتهاء السلسلة بصفحة سليمة وعدم عودة الحلقة.
