تشخيص ERR_TOO_MANY_REDIRECTS بعد تفعيل HTTPS في ووردبريس

فعلت الاتصال الآمن ثم ظهر ERR_TOO_MANY_REDIRECTS بدل الموقع؟ غالبا ينتقل المتصفح بين عنوانين يعيدان توجيهه إلى بعضهما. سنوضح كيف تكتشف الحلقة وتراجع مصدر التحويل، بدل الاكتفاء بمسح بيانات المتصفح أو تغيير إعدادات كثيرة معا.

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

كيف نعرف أنها حلقة وليست مشكلة شهادة؟

افتح أدوات المطور أو استخدم فاحص رؤوس HTTP لا يتبع التحويلات تلقائيا. إذا أعاد العنوان الأول Location إلى الثاني، ثم أعاد الثاني إلى الأول، فالمشكلة في قواعد التحويل بين العناوين. أما خطأ الشهادة فيظهر قبل الوصول إلى استجابة HTTP كاملة. سجل البروتوكول والمضيف والمسار في كل قفزة، لأن الحلقة قد تكون بين www وغير www أو بين HTTP وHTTPS أو بين صفحة اللغة والرئيسية.

ترتيب العزل الذي يقلل المخاطرة

1. احتفظ بصورة من إعدادات URL في ووردبريس وقواعد الخادم قبل التغيير.
2. اختر مصدرا واحدا لإجبار HTTPS: الاستضافة أو Cloudflare أو الخادم. لا تبدأ بثلاثة مصادر متزامنة.
3. راجع «عنوان ووردبريس» و«عنوان الموقع» من الإعدادات العامة، وتأكد من البروتوكول والنطاق المقصودين. قد يختلف المسار في بعض التثبيتات، فلا تجعل العنوانين متطابقين بالقوة.
4. افحص وضع SSL في الوكيل. وضع يرسل HTTP إلى الأصل بينما الأصل يجبر HTTPS قد يصنع حلقة.
5. عطل قاعدة تحويل واحدة مؤقتا، ثم اطلب الرابط دون Cache وسجل السلسلة الجديدة.
6. بعد وصول قفزة واحدة إلى 200، أعد تفعيل الكاش وامسحه من طبقة الوكيل والخادم.

أخطاء تجعل التشخيص أصعب

لا تغير home وsiteurl من قاعدة البيانات وwp-config ولوحة التحكم في الوقت نفسه؛ لن تعرف أي قيمة فعالة. لا تحول كل مسار إلى الرئيسية، فهذا يخفي 404 ويخلق إشارات بحث سيئة. ولا تستخدم إضافة SSL لمجرد أن الشهادة موجودة؛ الشهادة والتوجيه وظيفتان مختلفتان. إذا لم تستطع الدخول إلى اللوحة، اطلب من الاستضافة سلسلة التحويلات ورؤوس X-Forwarded-Proto قبل إعطائها صلاحية حذف قواعد عشوائية.

كيف تعرف أن الإصلاح نجح؟

يوثق الاختبار الجديد أدناه أثر التعرف على HTTPS في محاكاة وكيل موثوق. أما الصورة التاريخية فتخص الحلقة المحلية الأقدم. بعد تعديل إعداد موقعك، نفذ الفحوص التالية لتثبت النتيجة لديك.

اختبر الصفحة الرئيسية ومقالا وصفحة الدخول وملف sitemap، ثم تأكد أن كل HTTP ينتقل مرة واحدة إلى HTTPS وأن canonical يستخدم النسخة النهائية. اربط هذا الفحص بخطوات اختبار 301 ثم هدف 200، لأن نجاح التحويل لا يكفي إذا كان الهدف نفسه يعيد تحويلا آخر.

تجربة جديدة: التعرف على HTTPS خلف وكيل موثوق

تاريخ التنفيذ: 5 سبتمبر 2026. مختبر منفصل باستخدام WordPress Playground CLI 3.1.52؛ ووردبريس 7.1؛ PHP 8.3.32؛ قاعدة SQLite. لم تُجر هذه التجربة على استضافة الموقع المنشور.

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

1. حاكينا طلبا داخليا على المنفذ 80 مع HTTPS فارغا وX-Forwarded-Proto=https.
2. بعد تحميل ووردبريس، كانت نتيجة is_ssl() غير آمنة؛ فأعادت قاعدة الاختبار تحويل 301 إلى عنوان HTTPS العام.
3. في العينة الثانية عرّفنا الاتصال الآمن عبر HTTPS=on داخل محاكاة الوكيل الموثوق، وأعدنا شرط التحويل نفسه.
4. أصبحت نتيجة is_ssl() صحيحة، وعادت استجابة محتوى 200 دون ترويسة تحويل.

حدود التجربة: هذه محاكاة لرؤوس وكيل داخل ووردبريس، وليست اتصال TLS حقيقيا أو تغييرا لحساب Cloudflare. تثبت أثر تعرف ووردبريس على البروتوكول؛ ولا تثبت إصلاح حلقات www أو اللغة أو إضافات التحويل.

تطبيق التشخيص على الاستضافة

اطلب من الاستضافة تحديد الجهة التي تنهي اتصال TLS، والبروتوكول الذي يصل إلى الخادم الأصلي، وكيف تُضبط متغيرات HTTPS لووردبريس. عند استخدام Cloudflare، راجع وضع التشفير وشهادة الخادم الأصلي مع الدعم. لا تنسخ شرطا يثق بأي X-Forwarded-Proto يرسله الزائر: يجب أن يزيل الوكيل الرؤوس غير الموثوقة أو يعيد كتابتها، وأن يتعرف الخادم على الوكلاء المسموحين فقط.

بعد تعديل الإعداد الصحيح، افتح عنوان HTTPS النهائي وافحص سلسلة التحويل في تبويب Network. ينبغي أن تصل إلى المحتوى دون عودة إلى عنوان سبق المرور به. اختبر الرئيسية ومقالا وصفحة الدخول؛ وإذا استمرت الحلقة فدوّن كل Location بدلا من تغيير إعدادات أخرى بالتخمين.

simulated_forwarded_proto: https
before_https_recognition: HTTP 301
after_https_recognition: HTTP 200
after_is_ssl: true

المصادر

• السؤال المجتمعي الذي يعرض المشكلة بعد تفعيل SSL.
• WordPress: إدارة HTTPS.
• Cloudflare: أوضاع تشفير الاتصال إلى الخادم الأصلي.