خطای Too Many Redirects در وردپرس؛ حلقهٔ ریدایرکت را رفع کنیم

وقتی مرورگر پیام Too Many Redirects یا «این صفحه درست هدایت نمی‌شود» را نشان می‌دهد، معمولاً سایت میان دو آدرس رفت‌وبرگشت می‌کند. مثلاً مرورگر به نسخهٔ امن HTTPS می‌رود، اما سرور دوباره او را به HTTP می‌فرستد؛ بعد قانون دیگری دوباره HTTPS را درخواست می‌کند. پاک‌کردن کوکی شاید خطا را برای یک نفر پنهان کند، ولی علت اصلی را حل نمی‌کند. در این راهنما مسیر رفت‌وبرگشت را پیدا می‌کنیم و فقط همان تنظیم ناسازگار را اصلاح می‌کنیم.

آدرس را یک بار با http:// و یک بار با https:// باز کنید. همچنین نسخهٔ www و بدون www را جدا امتحان کنید. اگر یکی باز می‌شود و دیگری خطا می‌دهد، دامنه‌ای که خطا دارد سرنخ خوبی است. از یک پنجرهٔ خصوصی هم استفاده کنید تا کوکی قدیمی مرورگر نتیجه را عوض نکند؛ با این حال، پنجرهٔ خصوصی جای بررسی سرور را نمی‌گیرد.

اگر به خط فرمان دسترسی دارید، در لینوکس یا macOS این دستور را اجرا کنید:

به‌جای example.com دامنهٔ خود را بگذارید. در ویندوز دستور را با curl.exe اجرا کنید تا PowerShell آن را با دستور دیگری اشتباه نگیرد. خط‌های Location: مقصد هر پرش را نشان می‌دهند. اگر مقصدها یکی‌درمیان HTTP و HTTPS هستند، احتمالاً تنظیم SSL با قانون تغییر آدرس تداخل دارد. اگر فقط www و بدون www جابه‌جا می‌شوند، دو قانون برای انتخاب نشانی اصلی با هم اختلاف دارند.

در Cloudflare وارد بخش SSL/TLS → Overview شوید و حالت رمزگذاری را ببینید. حالت Flexible ارتباط مرورگر تا Cloudflare را امن می‌کند، اما ارتباط Cloudflare تا سرور اصلی را با HTTP می‌فرستد. اگر وردپرس یا سرور اصلی خودش HTTP را به HTTPS تغییر دهد، دو طرف کار یکدیگر را خنثی می‌کنند و حلقه ساخته می‌شود.

راه حل پایدار این است که ابتدا روی سرور اصلی گواهی معتبر نصب و تمدید آن را فعال کنید، سپس حالت Cloudflare را روی Full (strict) بگذارید. این حالت، گواهی سرور اصلی را هم بررسی می‌کند. اگر گواهی روی سرور آماده نیست، فقط برای ناپدیدکردن پیام، Full (strict) را فعال نکنید؛ ابتدا گواهی را نصب کنید یا با پشتیبانی میزبان هماهنگ شوید. راهنمای حالت Flexible در Cloudflare علت حلقه در این حالت را توضیح می‌دهد.

ریدایرکت ممکن است در افزونهٔ وردپرس، فایل .htaccess، تنظیم وب‌سرور یا Cloudflare تعریف شده باشد. فعال‌بودن چند قانون به‌خودی‌خود همیشه اشکال نیست، اما قانون‌هایی که مقصد متفاوت دارند حلقه می‌سازند. در پیشخوان وردپرس، نشانی تنظیمات → عمومی را بخوانید. هر دو فیلد «نشانی وردپرس» و «نشانی سایت» باید با نشانی اصلی انتخاب‌شده، مثلاً https://example.com، هماهنگ باشند.

اگر پیشخوان باز نمی‌شود، فایل wp-config.php را فقط بخوانید و دنبال ثابت‌های WP_HOME و WP_SITEURL بگردید. اگر وجود دارند، ممکن است مقدارشان نشانی دیگری را تحمیل کند. فایل را قبل از هر ویرایش دانلود کنید. نشانی را در چند جا حدس‌وار عوض نکنید و کد تازه‌ای از اینترنت در آن نچسبانید؛ یک کاراکتر اشتباه می‌تواند سایت را از دسترس خارج کند. در سایت‌های پشت پراکسی، تشخیص HTTPS باید از تنظیم معتبر همان پراکسی پیروی کند، نه اینکه یک افزونه را با چند قانون تازه دور بزنیم.

اگر مشکل پس از روشن‌کردن افزونهٔ SSL یا ریدایرکت شروع شده است، نام افزونه و زمان تغییر را یادداشت کنید. در صورت دسترسی به پیشخوان، همان افزونه را موقتاً غیرفعال کنید و دوباره یک نشانی را آزمایش کنید. اگر پیشخوان در دسترس نیست، تغییر نام پوشهٔ یک افزونه از File Manager فقط وقتی مناسب است که بدانید همان افزونه مسئول ریدایرکت است و نسخهٔ پشتیبان دارید؛ پوشهٔ plugins را یک‌جا تغییر نام ندهید، چون همهٔ افزونه‌ها از کار می‌افتند.

پس از اصلاح قانون، کش افزونه و Cloudflare را پاک کنید، اما تغییرهای زیادی را هم‌زمان اعمال نکنید. اگر با پاک‌شدن کش خطا موقتاً ناپدید شد و دوباره برگشت، احتمالاً هنوز یک قانون متناقض وجود دارد. برای مقایسه، همان دستور curl را دوباره بزنید و فهرست Location: قبلی و جدید را کنار هم بگذارید.

نسخهٔ اصلی سایت را مشخص کنید؛ مثلاً فقط https://example.com. سپس HTTP، HTTPS، www و بدون www را امتحان کنید. انتظار داریم هر نسخهٔ فرعی با یک یا چند پرش مشخص به همان نشانی اصلی برسد و بعد صفحه باز شود؛ نه اینکه مسیر میان دو نشانی تکرار شود. صفحهٔ ورود وردپرس و یک مقاله را هم باز کنید تا فقط صفحهٔ خانه سالم نباشد.

اگر بعد از این مراحل هنوز خطا دارید، خروجی دستور curl، زمان شروع مشکل، آخرین تغییر و نام افزونهٔ SSL را به میزبان بدهید. این اطلاعات نشان می‌دهد درخواست بین مرورگر، Cloudflare و وب‌سرور کجا برمی‌گردد. مقالهٔ فعال‌کردن HTTPS و SSL در هاست دربارهٔ گواهی است؛ وقتی گواهی درست است ولی صفحه باز هم دور می‌زند، همین تفکیک لایه‌ها راه عیب‌یابی را کوتاه می‌کند.

یک نکتهٔ مهم این است که هشدار HSTS مرورگر می‌تواند آدرس HTTP را پیش از فرستادن درخواست به HTTPS تبدیل کند، اما به‌تنهایی ثابت نمی‌کند سرور در حلقه افتاده است. اگر curl مسیر کوتاه و درستی نشان می‌دهد ولی فقط یک مرورگر خطا دارد، دامنه را در مرورگر و شبکهٔ دیگری امتحان کنید. اگر پاسخ‌های سرور هم تکرار می‌شوند، مشکل از تنظیم مرورگر جدا شده و باید همان لایهٔ ریدایرکت را اصلاح کنید.