ERR_TOO_MANY_REDIRECTS في ووردبريس وCloudflare: حلقة التحويل وحلّها

تشير رسالة «ERR_TOO_MANY_REDIRECTS» (أو «الصفحة تعيد التوجيه بطريقة غير صحيحة») إلى أن المتصفح وقع في حلقة تحويل دائرية لا نهاية لها (Redirect Loop)؛ حيث يوجهه الخادم من الرابط A إلى الرابط B، ثم تقوم الصفحة B بإعادته إلى A، أو يُحوّل الرابط من HTTP إلى HTTPS المشفر ليعيده الخادم مجدداً إلى HTTP. عند حدوث ذلك، يتدخل المتصفح تلقائياً بعد نحو 20 محاولة تحويل ويوقف العملية حمايةً لموارد جهازك.

في مواقع ووردبريس المربوطة بشبكة Cloudflare، يعود هذا الخطأ غالباً إلى سببين رئيسيين: تضارب وضع التشفير (Flexible SSL) في كلاود فلير مع إعدادات ووردبريس، أو عدم تطابق روابط الموقع في قاعدة البيانات، يليهما تضارب ملف .htaccess أو كاش المتصفح العنيد.

الخطوة الأولى: كشف مسار حلقة التحويل عبر الطرفية#

بدلاً من التخمين، يمكنك رؤية كل قفزة تحويل يقوم بها خادمك بالمليمتر عبر تنفيذ أمر curl مع الخيارين -I و -L:

curl -IL https://example.com

إذا رأيت تكراراً مستمراً لرموز HTTP/2 301 أو 302 بين نفس الرابطين مراراً وتكراراً، فأنت أمام حلقة تحويل صريحة. افحص الأسباب التالية بالترتيب لحلها فوراً:

السبب 1: تضارب وضع التشفير Flexible في Cloudflare (الأكثر شيوعاً)#

إذا قمت بتفعيل Cloudflare لموقعك مؤخراً، أو قمت بتثبيت شهادة SSL مجانية في ووردبريس وبدأت رسالة الخطأ بالظهور فوراً، فهذا هو السبب الأرجح.

لماذا تحدث هذه الحلقة؟#

• عند اختيار وضع Flexible SSL في Cloudflare، يقوم المتصفح بالاتصال بكلاود فلير عبر اتصال مشفر وآمن (HTTPS).
• لكن كلاود فلير تقوم بعد ذلك بجلب صفحات موقعك من خادم الاستضافة الفعلي عبر اتصال غير مشفر (HTTP على المنفذ 80).
• عندما يستقبل ووردبريس الطلب عبر المنفذ 80 غير المشفر، يلاحظ أن الموقع يجب أن يفتح بـ HTTPS، فيرسل أمر تحويل فوري (301 Redirect) إلى https://example.com.
• تستقبل كلاود فلير أمر التحويل، وتعيد طلبه من سيرفرك مجدداً عبر HTTP... وتستمر هذه الدائرة المفرغة دون توقف!

الحل الجذري:#

1. سجل الدخول إلى حسابك في Cloudflare وافتح موقعك.
2. من القائمة الجانبية، انتقل إلى SSL/TLS.
3. غيّر وضع التشفير من Flexible إلى Full أو Full (strict).
4. انتظر دقيقتين، ثم افتح نافذة تصفح متخفٍ في متصفحك وجرب فتح الموقع. ستجد أن حلقة التحويل قد اختفت تماماً وعاد الموقع للعمل.

السبب 2: تفاوت روابط الموقع (Site URL و Home URL)#

يحتاج ووردبريس إلى مطابقة تامة بين رابطين أساسيين مسجلين في إعداداته: عنوان ووردبريس (WordPress Address) وعنوان الموقع (Site Address). إذا كان أحدهما يبدأ بـ http:// والآخر بـ https://، أو كان أحدهما يحتوي على البادئة www والآخر بدونها، فسيحاول كل رابط تحويل الزائر إلى الآخر باستمرار.

الحل السريع عبر ملف wp-config.php (دون الحاجة للدخول للوحة التحكم):#

بما أنك لا تستطيع فتح لوحة تحكم ووردبريس بسبب الخطأ، يمكنك فرض الرابط الصحيح برمجياً في ثوانٍ:

1. اتصل بسيرفرك عبر SSH أو افتح مدير الملفات (File Manager) في الاستضافة.
2. افتح ملف wp-config.php الموجود في المجلد الرئيسي للموقع.
3. أضف السطرين التاليين فوق السطر الشهير /* That's all, stop editing! Happy publishing. */ مباشرة:

   define( 'WP_HOME', 'https://example.com' );
   define( 'WP_SITEURL', 'https://example.com' );

   (استبدل example.com بنطاقك الفعلي، وتأكد من كتابة https بدقة وتحديد ما إذا كنت تريد www أم لا).
4. احفظ الملف. يؤدي هذا الإجراء إلى تجاوز أي قيم خاطئة في قاعدة البيانات فوراً.

السبب 3: أخطاء التحويل في ملف .htaccess (خوادم Apache و LiteSpeed)#

قد تحتوي ملفات .htaccess على قواعد إعادة توجيه قديمة أو متضاربة خلفتها إضافات تحويل الروابط أو إضافات الأمان.

الحل:#

1. افتح مدير الملفات في استضافتك وأظهر الملفات المخفية (Show Hidden Files).
2. ابحث عن ملف .htaccess في مجلد public_html وقم بإعادة تسميته كنسخة احتياطية إلى .htaccess.bak.
3. أنشئ ملفاً جديداً باسم .htaccess، وضع بداخله كود ووردبريس الافتراضي والنظيف تماماً:

   # BEGIN WordPress
   RewriteEngine On
   RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
   RewriteBase /
   RewriteRule ^index\.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /index.php [L]
   # END WordPress

4. احفظ الملف واختبر موقعك مجدداً.

السبب 4: تضارب إضافات الـ SSL وإعادة التوجيه#

تستخدم بعض المواقع إضافات لإجبار التحويل إلى HTTPS (مثل إضافة Really Simple SSL أو إضافات Redirection). إذا تم تفعيل التحويل من لوحة الاستضافة ومن الإضافة ومن كلاود فلير في آن واحد، تتضارب التوجيهات وتنشأ الحلقة.

الحل بتعطيل الإضافات المشبوهة مؤقتاً:#

للتأكد مما إذا كانت إحدى الإضافات هي السبب دون حذف أي بيانات:

# الانتقال لمجلد الإضافات عبر الطرفية
cd /var/www/example.com/public_html/wp-content/plugins

# تعطيل إضافة SSL بتغيير اسم مجلدها
mv really-simple-ssl really-simple-ssl.bak

إذا فتح الموقع فوراً بعد هذه الخطوة، فالإضافة هي المسببة للمشكلة. يمكنك حينها حذفها والاعتماد على توجيه HTTPS الطبيعي من خادم الويب أو Cloudflare دون الحاجة لإضافات تبطئ ووردبريس.

السبب 5: كاش المتصفح العنيد (301 Permanent Cache)#

تعتبر تحويلات 301 Moved Permanently تحويلات دائمة؛ يقوم متصفح مثل Google Chrome بحفظها في ذاكرته الداخلية العميقة. لذلك، حتى بعد أن تصلح المشكلة على الخادم بنجاح، قد يستمر متصفحك في إظهار شاشة الخطأ القديمة من ذاكرته!

خطوات التأكد والتطهير:#

• جرّب التصفح المتخفي دائماً: افتح نافذة Incognito أو متصفحاً مختلفاً لم تفتحه من قبل لاختبار النتيجة الحقيقية.
• مسح كاش المتصفح: في كروم، اضغط Ctrl + Shift + Delete واختر مسح Cached images and files.
• تفريغ كاش Cloudflare: ادخل للوحة Cloudflare -> اذهب إلى Caching -> واضغط Purge Everything لضمان عدم تقديم نسخ كاش محولة من خوادم الحافة.

كيف تتأكد أن موقعك استقر تماماً؟#

بعد تطبيق الحلول، نفذ أمر الفحص النهائي في الطرفية:

curl -I https://example.com

يجب أن ترى استجابة نظيفة ومباشرة برمز النجاح:

HTTP/2 200
content-type: text/html; charset=UTF-8

أو قفزة تحويل شرعية واحدة فقط (مثلاً من http إلى https) تنتهي مباشرة بالرمز 200 دون تكرار.

جدول التشخيص السريع#

المصادر#

• دليل استكشاف أخطاء حلقة التحويل Too Many Redirects من وثائق Cloudflare الرسمية
• التوثيق الرسمي لووردبريس لتعديل وتثبيت روابط الموقع Site URL
• المعيار التقني RFC 9110 لرموز إعادة التوجيه في بروتوكول HTTP