ERR_TOO_MANY_REDIRECTS: خطأ حلقة إعادة التوجيه في SSL وحلّه

ما هو ERR_TOO_MANY_REDIRECTS؟

ERR_TOO_MANY_REDIRECTS خطأ يظهر عندما يدخل المتصفح في حلقة إعادة توجيه لا نهائية لصفحة ما. يضع المتصفح حدًا أقصى فيقطع الحلقة بعد 20 عملية إعادة توجيه في العادة، ثم يعرض هذا الخطأ.

هذا الخطأ شائع جدًا بعد تثبيت SSL، لأن إعادة التوجيه من HTTP إلى HTTPS قد تتحول إلى حلقة لا نهائية إذا لم تُضبط المراحل بين الخادم و CDN والتطبيق ضبطًا صحيحًا.

السيناريو المعتاد لحلقة إعادة التوجيه

يزور المستخدم العنوان http://example.com :

1. الخادم: يعيد التوجيه من HTTP إلى HTTPS، أي إلى https://example.com
2. CDN/Proxy: يمرّر الطلب إلى الخادم الأصلي (origin) عبر HTTP بدلًا من HTTPS
3. الخادم: يعيد التوجيه من HTTP إلى HTTPS، أي إلى https://example.com
4. ... حلقة لا نهائية

السبب 1: وضع SSL في Cloudflare غير صحيح

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

الحل

• اضبط وضع SSL في Cloudflare على "Full" أو "Full (Strict)"
• Full: تكفي أي شهادة SSL على الخادم الأصلي (بما فيها الموقّعة ذاتيًا self-signed)
• Full (Strict): يلزم وجود شهادة SSL صالحة على الخادم الأصلي (الخيار الموصى به)

غيّر وضع SSL من المسار: Cloudflare Dashboard → SSL/TLS → Overview.

السبب 2: قواعد متعارضة في Nginx/Apache

قد يحدث تعارض إذا وُجدت قواعد إعادة توجيه في كتلة الخادم وفي ملف .htaccess معًا.

حل Nginx

# خطأ: حلقة داخل كتلة server نفسها
server {
    listen 443 ssl;
    server_name example.com;
    # هذه القاعدة تُنفَّذ حتى عند الاتصال عبر HTTPS!
    if ($scheme = "http") {
        return 301 https://$host$request_uri;
    }
}

# صحيح: كتل server منفصلة
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    # ... إعدادات SSL
}

حل Apache

# خطأ: قاعدة تُحدث حلقة
RewriteEngine On
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# صحيح: أُضيف التحقق من HTTPS
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# أو: التحقق من X-Forwarded-Proto (خلف proxy/CDN)
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

السبب 3: مشكلة عنوان الموقع في WordPress

إذا كان "Site URL" و"WordPress URL" في WordPress مضبوطين على HTTP، فإن WordPress يعيد التوجيه من تلقاء نفسه إلى HTTP.

الحل

# أضِف السطرين التاليين إلى ملف wp-config.php
define('WP_HOME', 'https://www.example.com');
define('WP_SITEURL', 'https://www.example.com');

# أو حدِّث القيم في قاعدة البيانات
UPDATE wp_options SET option_value = 'https://www.example.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://www.example.com' WHERE option_name = 'home';

السبب 4: Load Balancer أو Reverse Proxy

عندما ينهي موازن الحمل اتصال SSL (SSL termination) ويمرر الطلب إلى الخادم الخلفي (backend) عبر HTTP، يظن الخادم الخلفي أن الاتصال ليس عبر HTTPS فيعيد التوجيه.

الحل

# Nginx: تحقّق من الترويسة القادمة من الـ proxy
set $redirect_https 0;
if ($scheme = "http") { set $redirect_https 1; }
if ($http_x_forwarded_proto = "https") { set $redirect_https 0; }
if ($redirect_https = 1) { return 301 https://$host$request_uri; }

# Apache: التحقق من X-Forwarded-Proto
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

تتبّع الأخطاء: عرض سلسلة إعادة التوجيه

# تتبّع سلسلة إعادة التوجيه باستخدام curl
curl -vL http://example.com 2>&1 | grep -i "location:"

# أو استخدم موقع httpstatus.io (أداة ويب)
# يعرض إعادة التوجيه ورموز HTTP في كل خطوة

الخلاصة

ينشأ خطأ ERR_TOO_MANY_REDIRECTS غالبًا من عدم التوافق بين وضع SSL في CDN/proxy وقواعد إعادة التوجيه على الخادم. إذا كنت تستخدم Cloudflare فالحل هو وضع SSL "Full (Strict)"، وإلا فالحل هو التحقق من ترويسة X-Forwarded-Proto . وبتتبّع سلسلة إعادة التوجيه بأمر curl يمكنك تحديد الخطوة المسببة للمشكلة بسرعة.