رفع خطای Too Many Redirects در وردپرس؛ عیب‌یابی HTTPS، Cloudflare و Reverse Proxy

اگر وردپرس با خطای ERR_TOO_MANY_REDIRECTS باز نمی‌شود، اول هیچ Redirect جدیدی اضافه نکنید. این خطا یعنی مرورگر بین دو یا چند URL گیر افتاده؛ در سایت‌های وردپرسی معمولاً یکی از لایه‌های WordPress، وب‌سرور، Reverse Proxy یا CDN درخواست را دوباره به آدرس قبلی برمی‌گرداند. مسیر درست عیب‌یابی این است: ابتدا حلقه را با curl پیدا کنید، بعد فقط همان لایه‌ای را که Scheme یا Host را اشتباه تشخیص می‌دهد اصلاح کنید و در پایان تعداد Redirectها را دوباره تست کنید.

خلاصه سریع رفع Too Many Redirects وردپرس

1. با curl -IL ببینید Location بین کدام URLها تکرار می‌شود.
2. مقادیر home و siteurl وردپرس را بررسی کنید؛ HTTP/HTTPS و www/non-www باید با معماری واقعی سایت هماهنگ باشند.
3. اگر Cloudflare دارید، حالت SSL/TLS را با Origin هماهنگ کنید. ترکیب Flexible با اجبار HTTP→HTTPS روی Origin می‌تواند حلقه بسازد.
4. اگر وردپرس پشت Reverse Proxy است، هدر X-Forwarded-Proto را درست ارسال کنید و WordPress را طوری تنظیم کنید که HTTPS را پشت Proxy تشخیص دهد.
5. Redirectهای تکراری در افزونه، NGINX/Apache و CDN را حذف کنید؛ یک لایه باید مالک Redirect اصلی HTTP→HTTPS باشد.
6. Cache را پاک کنید و دوباره با curl و صفحه ورود وردپرس Verify بگیرید.

پیش‌نیاز و سناریوی واقعی

فرض کنید سایت example.com پشت Cloudflare یا یک Reverse Proxy قرار دارد. مرورگر با HTTPS به Proxy وصل می‌شود، اما Proxy درخواست را با HTTP به Origin می‌فرستد. اگر Origin یا WordPress تصور کند کاربر با HTTP آمده و دوباره او را به HTTPS بفرستد، در بعضی پیکربندی‌ها Proxy همان چرخه را تکرار می‌کند.

قبل از تغییر، از wp-config.php و تنظیمات وب‌سرور نسخه پشتیبان بگیرید. اگر WP-CLI دارید، مقادیر فعلی URL را نیز ذخیره کنید:

wp option get home
wp option get siteurl

مرحله ۱: حلقه Redirect را با curl پیدا کنید

ابتدا سه تست زیر را اجرا کنید:

curl -I http://example.com
curl -I https://example.com
curl -IL --max-redirs 10 https://example.com

در حالت سالم معمولاً درخواست HTTP یک 301 یا 308 به HTTPS می‌دهد و سپس زنجیره به پاسخ نهایی مثل 200 می‌رسد. در Redirect Loop، هدر Location بارها بین دو Scheme یا دو Host تکرار می‌شود؛ مثلاً:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

HTTP/2 301
Location: http://example.com/

برای دیدن فقط Status و Location:

curl -sS -D - -o /dev/null https://example.com/ | grep -iE 'HTTP/|location:'

اگر Loop بین www و بدون www است، همان ابتدا قواعد Host را بررسی کنید. اگر بین HTTP و HTTPS می‌چرخد، تمرکز اصلی روی SSL mode، Proxy header و اجبار HTTPS باشد.

مرحله ۲: home و siteurl وردپرس را بررسی کنید

با WP-CLI:

wp option get home
wp option get siteurl

اگر معماری نهایی شما HTTPS است، هر دو معمولاً باید URL نهایی را نشان دهند. فقط در صورتی که مقدار فعلی واقعاً اشتباه است آن را اصلاح کنید:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

نکته: تغییر تصادفی URLها می‌تواند دسترسی به wp-admin را سخت‌تر کند. خروجی قبل از تغییر را نگه دارید تا Rollback دقیق داشته باشید.

اگر هدفتان صرفاً تنظیم Redirect استاندارد HTTP به HTTPS است، راهنمای ریدایرکت HTTP به HTTPS را هم ببینید؛ مسئله این مقاله اما پیدا کردن و شکستن Loop است، نه صرفاً ساخت Redirect.

مرحله ۳: Cloudflare Flexible را با Redirect اجباری Origin ترکیب نکنید

طبق مستند رسمی Cloudflare، در حالت Flexible ارتباط Cloudflare تا Origin با HTTP انجام می‌شود. اگر Origin تمام HTTPها را دوباره به HTTPS بفرستد، امکان Redirect Loop وجود دارد.

اگر روی Origin گواهی معتبر دارید، معمولاً معماری امن‌تر این است که SSL/TLS mode را روی Full (strict) قرار دهید و مطمئن شوید Origin روی HTTPS واقعاً پاسخ می‌دهد. قبل از تغییر، Certificate و Virtual Host پورت 443 را Verify کنید.

هم‌زمان Redirect Ruleها و گزینه Always Use HTTPS را بازبینی کنید. اگر Edge، افزونه وردپرس و Origin هر سه Redirect مشابه می‌سازند، قواعد را ساده کنید تا فقط یک مسیر اصلی وجود داشته باشد.

برای آشنایی با نوع گواهی‌ها و تفاوت آن‌ها، مقاله معرفی SSL و انواع DV، OV و EV مکمل این بخش است.

مرحله ۴: X-Forwarded-Proto را در Reverse Proxy درست ارسال کنید

اگر NGINX جلوی WordPress یا جلوی وب‌سرور Backend است، Proxy باید Scheme اصلی کاربر را منتقل کند. نمونه پایه:

location / {
    proxy_pass http://wordpress_backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_redirect off;
}

بعد از تغییر NGINX ابتدا Syntax را تست و سپس Reload کنید:

sudo nginx -t
sudo systemctl reload nginx

خروجی مورد انتظار از nginx -t باید موفق بودن تست Configuration را نشان دهد. اگر تست Fail شد، Reload نکنید و فایل را به نسخه قبلی برگردانید.

مرحله ۵: WordPress باید HTTPS پشت Proxy را تشخیص دهد

مستند رسمی WordPress توضیح می‌دهد که SSL termination روی Reverse Proxy می‌تواند در صورت تشخیص اشتباه HTTPS باعث حلقه بی‌نهایت شود. فقط وقتی Proxy مورد اعتماد شما هدر را تنظیم می‌کند، می‌توانید در wp-config.php قبل از خط پایان تنظیمات وردپرس Scheme را تشخیص دهید:

if (
    isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) &&
    strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false
) {
    $_SERVER['HTTPS'] = 'on';
}

اگر SSL برای بخش مدیریت نیز کاملاً آماده است:

define( 'FORCE_SSL_ADMIN', true );

هشدار امنیتی: به X-Forwarded-Proto فقط وقتی اعتماد کنید که درخواست‌ها واقعاً از Proxy/CDN کنترل‌شده وارد می‌شوند. اگر Origin مستقیماً از اینترنت قابل دسترس است و هدرهای Client بدون کنترل پذیرفته می‌شوند، ابتدا Trust boundary را اصلاح کنید.

مرحله ۶: Redirectهای تکراری NGINX، Apache و افزونه‌ها را حذف کنید

یکی از خطاهای متداول این است که افزونه Redirect، فایل .htaccess، تنظیم NGINX و CDN هم‌زمان HTTP را به HTTPS یا www را به non-www می‌فرستند. یک Redirect ساده به‌تنهایی مشکلی ندارد؛ مشکل زمانی ایجاد می‌شود که دو لایه مقصد یکدیگر را معکوس کنند.

برای عیب‌یابی موقت:

• Redirect plugin را موقتاً غیرفعال کنید.
• قواعد سفارشی HTTPS/www را در وب‌سرور مرور کنید.
• Redirect Ruleهای Cloudflare را بررسی کنید.
• پس از هر تغییر فقط یک متغیر را تست کنید؛ چند تغییر هم‌زمان تشخیص علت را سخت می‌کند.

مرحله ۷: Cache را پاک و نتیجه را Verify کنید

بعد از اصلاح، Cache مربوط به CDN، Page Cache و در صورت نیاز مرورگر را پاک کنید. سپس:

curl -I http://example.com
curl -I https://example.com
curl -IL --max-redirs 5 https://example.com/wp-login.php

معیار PASS:

• HTTP حداکثر با Redirect مشخص به URL نهایی HTTPS می‌رود.
• URL نهایی دیگر بین HTTP/HTTPS یا www/non-www رفت‌وبرگشت ندارد.
• wp-login.php و wp-admin بدون ERR_TOO_MANY_REDIRECTS باز می‌شوند.
• Cloudflare و Origin هر دو روی Scheme نهایی توافق دارند.

خطاهای رایج که باعث برگشت مشکل می‌شوند

• Cloudflare Flexible + اجبار HTTPS روی Origin: یکی از کلاسیک‌ترین Loopها.
• home و siteurl ناسازگار: یکی HTTP و دیگری HTTPS یا Host متفاوت.
• X-Forwarded-Proto ارسال می‌شود اما WordPress آن را نمی‌شناسد: Backend درخواست را HTTP تصور می‌کند.
• Redirect در چند لایه: افزونه، NGINX/Apache و CDN با قواعد متناقض.
• فعال‌سازی زودهنگام HSTS: Rollback را دشوار می‌کند؛ HSTS را بعد از اطمینان از پایداری HTTPS فعال کنید.

Rollback و Recovery

اگر بعد از تغییر دسترسی بدتر شد، تغییرات را به ترتیب معکوس برگردانید:

1. نسخه پشتیبان wp-config.php یا Config وب‌سرور را Restore کنید.
2. مقادیر قبلی home و siteurl را که در ابتدای کار ذخیره کرده بودید بازگردانید.
3. آخرین Redirect Rule اضافه‌شده را غیرفعال کنید.
4. اگر SSL mode Cloudflare را تغییر داده‌اید، فقط به آخرین حالت سالم و مستند برگردید؛ حالت ناامن را به‌عنوان راه‌حل دائمی نگه ندارید.
5. دوباره با curl -IL --max-redirs 10 زنجیره را مشاهده کنید.

جمع‌بندی

برای رفع ERR_TOO_MANY_REDIRECTS در WordPress، مهم‌ترین کار پیدا کردن نقطه‌ای است که Redirect به مسیر قبلی برمی‌گردد. با curl Loop را اثبات کنید، URLهای وردپرس را هماهنگ نگه دارید، Cloudflare SSL mode را با Origin تطبیق دهید و در Reverse Proxy هدر X-Forwarded-Proto را درست منتقل و در WordPress تشخیص دهید. سپس فقط یک لایه را مسئول Redirect اصلی کنید و نتیجه را دوباره Verify بگیرید.

اگر مشکل از محدودیت یا پیکربندی محیط میزبانی است و به هاست سازگار با WordPress نیاز دارید، صفحه پلن‌های هاست وان‌سرور جزئیات سرویس‌ها را نشان می‌دهد.