برای رفع خطای ERR_TOO_MANY_REDIRECTS در وردپرس، ابتدا زنجیره انتقال را ثبت کنید و ببینید کدام دو نشانی یا دو لایه درخواست را به یکدیگر برمی‌گردانند. سپس تنظیم HTTPS در CDN، نشانی‌های وردپرس و قانون ریدایرکت همان لایه را هماهنگ کنید. پاک کردن کوکی ممکن است مشکل یک مرورگر را برطرف کند، اما تعارض تنظیمات سرور را اصلاح نمی‌کند.
این راهنما برای زمانی است که صفحه اصلی، پیشخوان یا یکی از مسیرهای سایت با پیام «تغییر مسیر بیش از حد» باز نمی‌شود. هدف، پیدا کردن یک تغییر مشخص و قابل بازگشت است؛ بدون حذف یک‌جای قوانین، خاموش کردن حفاظت سایت یا دست‌کاری تصادفی پایگاه داده.
خطای ERR_TOO_MANY_REDIRECTS دقیقاً چه می‌گوید؟
مرورگر یک پاسخ انتقال می‌گیرد، مقصد را باز می‌کند و دوباره به انتقال دیگری می‌رسد؛ این روند آن‌قدر ادامه پیدا می‌کند که مرورگر متوقف می‌شود. ممکن است نشانی بین HTTP و HTTPS، بین دامنه با www و بدون آن، یا بین صفحه ورود و حساب کاربری جابه‌جا شود. تعداد زیاد انتقال لزوماً چرخه نیست؛ تکرار یک مقصد در زنجیره، سرنخ روشن‌تری است.
نمونه فرضی: CDN درخواست بازدیدکننده را روی HTTPS می‌پذیرد، ولی آن را با HTTP به مبدأ می‌فرستد. مبدأ هم هر درخواست HTTP را به HTTPS منتقل می‌کند. درخواست تازه باز به همان وضعیت می‌رسد. در این نمونه، محتوای نوشته و قالب سایت مسئله اصلی نیست؛ روش ارتباط دو لایه باید اصلاح شود.
۱. پیش از تغییر، مسیر خراب و آخرین تغییر را ثبت کنید
نشانی کامل، ساعت همراه منطقه زمانی، وضعیت ورود و آخرین تغییر در SSL، CDN، افزونه یا انتقال هاست را یادداشت کنید. صفحه اصلی، یک نوشته عمومی و صفحه ورود را جدا بررسی کنید. اگر فقط کاربر واردشده خطا دارد، مسئله می‌تواند با نشست و قانون ورود مرتبط باشد؛ اگر همه صفحات عمومی درگیرند، تنظیم مشترک دامنه یا HTTPS اولویت دارد.
یک پنجره خصوصی باز کنید. اگر آنجا مشکل تکرار نشد، داده‌های همان دامنه را در مرورگر معمولی بررسی کنید؛ پاک‌سازی کل مرورگر لازم نیست. اگر خطا در چند مرورگر ادامه داشت، به بررسی سمت سایت بروید. از فایل تنظیماتی که قرار است تغییر کند نسخه قابل بازیابی بگیرید و دسترسی مدیریت فایل هاست را باز نگه دارید.
۲. زنجیره انتقال را ببینید؛ فقط آخرین صفحه را نگاه نکنید
در ابزار توسعه مرورگر، بخش Network را باز کنید، ثبت درخواست‌ها را هنگام جابه‌جایی صفحه حفظ کنید و نشانی عمومی مشکل‌دار را دوباره باز کنید. وضعیت پاسخ و هدر Location هر مرحله را بخوانید. داده‌های ورود و کوکی‌ها را در گزارش عمومی منتشر نکنید. برای یک صفحه عمومی، نمونه زیر با curl هدرهای مراحل را نشان می‌دهد و بدنه را کنار می‌گذارد:
curl -sS -L --max-redirs 10 -D - -o /dev/null https://example.com/در PowerShell ویندوز از curl.exe استفاده کنید و /dev/null را با NUL جایگزین کنید.
دامنه نمونه را جایگزین کنید. سقف ده انتقال برای محدود کردن همین آزمون است، نه راه‌حل سایت. اگر فرمان به سقف رسید، ترتیب Locationها را مقایسه کنید. این درخواست از نوع GET است؛ نتیجه آن را به فرم پرداخت یا درخواست POST تعمیم ندهید. برای عملیات ثبت‌کننده داده، آزمون کنترل‌شده همان مسیر لازم است.
| نشانه در زنجیره | آزمون بعدی | قدم متناسب |
|---|---|---|
| رفت‌وبرگشت HTTP و HTTPS | مقایسه روش ارتباط CDN تا مبدأ با قوانین HTTPS | هماهنگ کردن TLS و حذف تعارض همان قانون |
| رفت‌وبرگشت www و بدون www | مقایسه دامنه نهایی در وردپرس، پنل هاست و CDN | انتخاب مقصد واحد و اصلاح قانون مخالف |
| چرخه فقط در ورود | مقایسه پنجره خصوصی و قوانین ورود یا عضویت | بررسی نشست و مؤلفه مرتبط در محیط آزمایشی |
| چرخه فقط در یک مسیر | بررسی قانون همان URL و انتقال‌های قدیمی | اصلاح مقصد یا شرط همان قاعده |
| شروع پس از انتقال هاست | بررسی نشانی وردپرس و تنظیم پراکسی مقصد | اصلاح تنظیم باقی‌مانده از میزبان قبلی |
۳. HTTPS در CDN و مبدأ را با هم هماهنگ کنید
در Cloudflare دو ارتباط وجود دارد: مرورگر تا Cloudflare و Cloudflare تا مبدأ. در حالت Flexible، ارتباط دوم HTTP است؛ بنابراین اجبار HTTPS در مبدأ می‌تواند چرخه بسازد. طبق راهنمای رسمی حلقه‌های انتقال Cloudflare، این تعارض یکی از علت‌های شناخته‌شده است. ابتدا گواهی و HTTPS مبدأ را بررسی کنید، سپس حالت رمزنگاری متناسب را انتخاب کنید.
برای ارتباط رمزنگاری‌شده با اعتبارسنجی گواهی مبدأ، Full (strict) به گواهی معتبر و سازگار با نام میزبان نیاز دارد. صرف عوض کردن گزینه بدون آماده بودن مبدأ ممکن است خطای دیگری ایجاد کند. وضعیت اعتبار، تاریخ انقضا و نام دامنه گواهی را با میزبان کنترل کنید. راهنمای رمزنگاری کامل ارتباط در Cloudflare ترتیب آماده‌سازی را توضیح می‌دهد.
قوانین Always Use HTTPS، Redirect Rules و انتقال‌های پنل هاست را کنار هم فهرست کنید. برای یک هدف، چند قانون مخالف باقی نگذارید. اگر یکی از قوانین HTTPS را به HTTP برمی‌گرداند، علت وجود آن را مشخص و همان قاعده را اصلاح کنید. خاموش کردن کامل CDN یا تغییر عمومی DNS نقطه شروع ضروری این بررسی نیست.
۴. نشانی وردپرس را با ساختار واقعی نصب تطبیق دهید
در پیشخوان، تنظیمات عمومی شامل «نشانی وردپرس» و «نشانی سایت» است. اولی محل فایل‌های هسته و دومی نشانی عمومی سایت را مشخص می‌کند. در نصب معمول ریشه، اغلب یکسان‌اند؛ ولی نصب هسته در زیرپوشه می‌تواند به تفاوت درست و عمدی نیاز داشته باشد. دو مقدار را بدون شناخت ساختار نصب یکسان نکنید.
اگر مقادیر در wp-config.php با WP_HOME و WP_SITEURL تعریف شده‌اند، تغییر فیلد پیشخوان ممکن است تنظیم مؤثر را عوض نکند. تعریف تکراری اضافه نکنید. مدیر فنی باید مقدار موجود را با مقصد نهایی دامنه مقایسه کند. نمونه زیر فقط شکل تنظیم را نشان می‌دهد و نسخه آماده برای همه نصب‌ها نیست:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );برای نصب شبکه‌ای یا هسته داخل زیرپوشه، تصمیم باید بر اساس معماری همان سایت باشد. مستندات تغییر نشانی و مهاجرت وردپرس تفاوت این مقادیر را توضیح می‌دهد. برای رفع چرخه، جایگزینی سراسری متن در دیتابیس را بی‌دلیل اجرا نکنید؛ مسئله ممکن است صرفاً یک قانون در CDN باشد.
۵. در سرور پراکسی، تشخیص HTTPS را بررسی کنید
ممکن است TLS در پراکسی پایان یابد و وردپرس اتصال داخلی را HTTP ببیند. در این وضعیت، اجبار HTTPS مدیریت می‌تواند تکرار شود. مدیر VPS باید مشخص کند کدام پراکسی هدر پروتکل را تولید می‌کند و وب‌سرور چگونه آن را به PHP می‌رساند. راهنمای HTTPS وردپرس این حالت را جداگانه مطرح می‌کند.
به هر هدر X-Forwarded-Proto که از اینترنت می‌آید اعتماد نکنید. پراکسی مورد اعتماد باید هدر را درست بازنویسی کند و مسیر مستقیم مبدأ نیز کنترل‌شده باشد. کپی کردن شرط تشخیص HTTPS در wp-config.php بدون بررسی مرز اعتماد، راه‌حل عمومی مناسبی نیست. در هاست اشتراکی، این بخش را با شواهد زنجیره به میزبان ارجاع دهید.
۶. قوانین وب‌سرور و افزونه مرتبط را محدود بررسی کنید
در Apache، قانون دامنه، HTTPS و مسیر ممکن است در VirtualHost یا .htaccess قرار داشته باشد. از نسخه قبلی فایل و راهنمای بازنویسی و انتقال در Apache برای بررسی همان شرط استفاده کنید. حذف کامل .htaccess می‌تواند قوانین حفاظتی و مسیرهای سایت را هم از بین ببرد.
در Nginx، ویرایش .htaccess اثری ندارد؛ قانون انتقال در تنظیم سرور بررسی می‌شود. پیش از بارگذاری تنظیم جدید، مدیر باید آزمون صحت پیکربندی را انجام دهد. مستندات rewrite و return در Nginx محل و ترتیب اجرای قواعد را مشخص می‌کند. تغییر فایل تولیدشده کنترل‌پنل باید از روش پشتیبانی‌شده همان پنل انجام شود.
اگر شواهد به افزونه انتقال، عضویت یا اجبار SSL اشاره دارد، تنظیم همان مؤلفه را در محیط آزمایشی مقایسه کنید. همه افزونه‌ها را هم‌زمان خاموش نکنید. مالک هاست لینوکس می‌تواند تنظیمات قابل دسترس پنل را بررسی و بقیه را به میزبان بسپارد؛ در VPS، بررسی قواعد و لاگ‌ها بخشی از مدیریت سرور است.
چه زمانی رفع خطا تأیید می‌شود؟
چهار ورودی HTTP و HTTPS با www و بدون آن را برای دامنه‌ای که واقعاً پشتیبانی می‌کنید بررسی کنید. مقصد باید نسخه نهایی تعیین‌شده باشد و دوباره به نشانی قبلی برنگردد. صفحه عمومی، ورود، خروج و مسیر مشکل‌دار را جدا آزمایش کنید. سپس کش همان مسیرهای تغییرکرده را به‌صورت هدفمند تازه کنید و دوباره پاسخ جدید بگیرید.
برای پیگیری، URL، زنجیره قبل و بعد، تغییر انجام‌شده و زمان آزمون را نگه دارید. یک زنجیره کوتاه که به صفحه درست می‌رسد با چرخه تفاوت دارد؛ راهنمای انتقال‌های HTTP در MDN تفاوت انواع انتقال را توضیح می‌دهد. نتیجه یک صفحه به معنی سالم بودن تمام عملیات فروشگاه نیست.
پرسش‌های رایج
آیا پاک کردن کوکی برای همه کافی است؟
خیر. اگر مسئله فقط نشست قدیمی همان مرورگر باشد مفید است. وقتی زنجیره در درخواست عمومی و مرورگر تازه هم تکرار می‌شود، تنظیم سایت یا زیرساخت باید اصلاح شود.
آیا افزایش سقف انتقال مرورگر راه‌حل است؟
خیر. چرخه همچنان ادامه دارد. مقصد و شرط متناقض را پیدا کنید؛ بالا بردن سقف فقط زمان رسیدن به خطا را تغییر می‌دهد.
آیا باید HTTPS را خاموش کنیم؟
برای رفع این خطا معمولاً باید تنظیمات HTTPS هماهنگ شوند. ارتباط امن و اعتبار گواهی را بررسی کنید و فقط قانون متناقض را اصلاح کنید، به‌ویژه برای ورود و پرداخت.
اگر پیشخوان باز نمی‌شود چه اطلاعاتی به پشتیبانی بدهیم؟
دامنه، URL نمونه، ساعت، آخرین تغییر و ترتیب Locationها کافی است تا بررسی شروع شود. رمز، کوکی نشست و هدر احراز هویت را در تیکت یا تصویر عمومی قرار ندهید.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.