حل مشكلة كثرة التحويلات في ووردبريس بعد HTTPS او النقل

خطأ كثرة التحويلات يعني ان المتصفح ينتقل من عنوان الى عنوان ثاني، ثم ترسله قاعدة اخرى للاول او لنفسه، ويظل الدوران مستمرا لحد ما يوقفه المتصفح. قد يظهر الرمز التالي:

ERR_TOO_MANY_REDIRECTS

المشكلة مش بطء تحميل، والصفحة غالبا ما وصلت لمرحلة عرض محتوى ووردبريس. السبب ممكن يكون عنوان HTTP وHTTPS غير متطابق، قاعدتين تحويل متعارضتين، اضافة، كاش، او وضع تشفير غير مناسب بين Cloudflare والخادم الاصلي.

كيف صنعنا حلقة تحويل حقيقية؟

نفذنا التجربة على ووردبريس 7.1 مع PHP 8.3.30 وMySQL 8.4.3. فعلنا اضافة مؤقتة على نسخة المختبر تجعل الصفحة الرئيسية ترسل تحويل 302 الى عنوان الصفحة الرئيسية نفسه.

عند فحص اول استجابة وجدنا 302 Found، وكانت قيمة Location هي نفس الرابط المطلوب. ظهر ايضا رأس X-Redirect-By: WordPress، وهذا دليل مفيد في تجربتنا ان التحويل خرج من طبقة ووردبريس.

سمحنا للفاحص باتباع خمسة تحويلات. كل استجابة رجعت 302 الى العنوان نفسه، ولم نصل الى صفحة نهائية. متصفح Edge أوقف الحلقة وعرض شاشة كثرة التحويلات.

عطلنا الاضافة المؤقتة، ثم طلبنا الرابط نفسه. انتهت حلقة 302 وعادت الصفحة بحالة 200.

فيديو توثيق التجربة الفعلية

هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.

ابدأ بنافذة خاصة، لكن لا تعتبر الكوكيز السبب دائما

افتح الموقع في نافذة خاصة ومن شبكة او جهاز آخر اذا توفر. اذا اشتغل هناك فقط، امسح كوكيز نطاقك بدل حذف كل بيانات المتصفح. قد تتعلق حلقة تسجيل الدخول بجلسة قديمة او كوكيز مرتبطة بنطاق او HTTPS مختلف.

اذا فشل الموقع في النافذة الخاصة وعلى اكثر من جهاز، فمسح الكوكيز مش حل للمشكلة الاساسية. انتقل لتتبع التحويلات نفسها.

حدد اول تحويل خاطئ

افتح ادوات المطور ثم تبويب الشبكة، وفعل حفظ السجل، وبعدها اطلب الصفحة. راقب عمود الحالة والعنوان الموجود في رأس Location. اكتب سلسلة مختصرة مثل:

http://example.com
https://example.com
http://example.com

هذه السلسلة تقول ان جهة ترفع الطلب الى HTTPS وجهة ثانية ترجعه الى HTTP. اما اذا كان الرابط نفسه يعيد نفسه بحالة 301 او 302، فابحث عن قاعدة على نفس المسار مثل التي صنعناها في المختبر.

وجود X-Redirect-By: WordPress يرجح ان ووردبريس او اضافة استخدمت دالة التحويل، لكنه مش ضمانا كاملا. غياب الرأس لا يثبت ان ووردبريس بريء، لان بعض الاضافات والخوادم لا تضيفه.

راجع عنواني ووردبريس والموقع

من الاعدادات العامة، لازم يكون عنوان ووردبريس وعنوان الموقع متوافقين مع النطاق والبروتوكول الذي يراه الزائر. واحد على HTTP والثاني على HTTPS، او واحد يحتوي www والثاني لا، ممكن يدخل مع قواعد الخادم في حلقة.

اذا ما قدرت تدخل لوحة التحكم، يمكن لمسؤول الموقع تثبيت القيمتين مؤقتا في wp-config.php:

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

استبدل النطاق بموقعك الحقيقي، ولا تضف الشرطة الاخيرة. هذا لا يغير القيم المحفوظة في قاعدة البيانات؛ هو يتجاوزها اثناء التشغيل. يوضح توثيق wp-config.php الرسمي وظيفة القيمتين، كما توضح صفحة الاعدادات العامة الفرق بين عنوان ملفات ووردبريس والعنوان الذي يكتبه الزائر.

اذا لم تكن متأكدا من مكان تثبيت الملفات، لا تجعل القيمتين متطابقتين بالقوة. بعض المواقع تضع ملفات ووردبريس داخل مجلد فرعي بينما تعرض الموقع من الجذر.

افصل طبقات التحويل بدل تعديلها كلها معا

قد يتم التحويل في اربع طبقات: Cloudflare او CDN، اعداد الخادم، ملف .htaccess او Nginx، ثم ووردبريس واضافاته. غير طبقة واحدة واختبر السلسلة من جديد. اذا عدلت كل شيء مرة واحدة، لن تعرف السبب وقد تنشئ حلقة ثانية.

1. عطل مؤقتا قاعدة التحويل التي أضفتها اخيرا في الاضافة او CDN.
2. اذا بدأ الخطأ بعد تفعيل اضافة SSL او تحويل، غير اسم مجلد هذه الاضافة من مدير الملفات فقط، ثم اختبر.
3. راجع قواعد HTTP الى HTTPS وwww في الخادم، واحتفظ بنسخة قبل تعديل .htaccess.
4. امسح كاش الخادم وCDN بعد تصحيح القاعدة، ثم اختبر نافذة خاصة.

لا تعطل مجلد الاضافات كله كاول خطوة. قد توقف الحماية او المتجر بدون حاجة. ابدأ بالاضافة المرتبطة بالتحويل او SSL، واستفد من وقت ظهور المشكلة وسجل التغييرات.

حالة Cloudflare مع HTTPS

في وضع Flexible يستقبل Cloudflare طلب الزائر عبر HTTPS لكنه يتصل بالخادم الاصلي عبر HTTP. اذا كان الخادم يجبر كل HTTP على HTTPS، يعيد الخادم الطلب الى HTTPS، ثم يرجع Cloudflare للاصل عبر HTTP، وتبدأ الحلقة.

يوضح دليل Cloudflare الرسمي لخطأ كثرة التحويلات هذا التعارض. الحل المعتاد هو استخدام Full او Full Strict عندما يكون على الخادم الاصلي شهادة صالحة ومهيأة، او ازالة قاعدة HTTPS المتعارضة. لا تغير وضع التشفير قبل التأكد من شهادة الخادم، لان الاختيار الخطأ قد يستبدل حلقة التحويل بخطأ شهادة.

اذا الحلقة تظهر في wp-admin فقط

نجاح الواجهة وفشل لوحة التحكم بعد تسجيل الدخول يوجهنا اكثر الى الكوكيز، عنوان الادارة، اضافة حماية، او كاش يطبق على wp-admin. تأكد ان CDN والاستضافة يستثنيان صفحة الدخول ولوحة التحكم من كاش الصفحات.

راقب هل الحلقة بين wp-login.php وwp-admin، او ان wp-admin يعيد نفسه. هذا التفصيل اهم من عبارة المتصفح العامة، وبيساعد الدعم يعرف اين يبحث.

كيف تمنع رجوعها؟

• حدد نسخة اساسية واحدة للنطاق: HTTPS مع www او بدونها.
• خلي طبقة واضحة مسؤولة عن التحويل، ولا تكرر القاعدة في CDN والخادم والاضافة بدون حاجة.
• اختبر تغيير SSL والنطاق على نسخة تجريبية قبل الموقع المباشر.
• سجل قواعد التحويل وسبب كل قاعدة حتى لا تتعارض مع قاعدة جديدة.
• بعد النقل، افحص الصفحة الرئيسية وتسجيل الدخول ومسار مقال وملف صورة.

الخلاصة من المختبر

قاعدة واحدة أعادت الصفحة الى نفسها صنعت حلقة 302 مؤكدة، والمتصفح أوقفها بخطأ ERR_TOO_MANY_REDIRECTS. ازالة القاعدة أعادت نفس الرابط الى 200. لذلك الحل مش “امسح الكوكيز” دائما؛ الحل هو معرفة من يرسل اول Location خاطئ، ثم تصحيح الطبقة المسؤولة.

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