خطای ریدایرکت شدن مداوم وردپرس

یکی از خسته‌کننده‌ترین حالت‌هایی که در عیب‌یابی سایت‌های وردپرسی دیده‌ام، حلقهٔ ریدایرکت است. شما آدرسی را در مرورگر وارد می‌کنید، سایت شروع به لود می‌کند، ناگهان صفحه‌ای خالی یا پیام «ERR_TOO_MANY_REDIRECTS» ظاهر می‌شود، و اگر دقت کنید، آدرس مرورگر مدام بین دو یا چند حالت تغییر می‌کند. تلاش می‌کنید سایت را رفرش کنید، اما همان چرخه تکرار می‌شود. سایت نه کاملاً از دسترس خارج است و نه سالم؛ یک وضعیت مبهم که به‌سختی قابل توضیح است. آنچه این وضعیت را آزاردهنده می‌کند، نه خودِ خطا، بلکه تصور غلطی است که کاربر از آن دارد: بیشتر افراد فکر می‌کنند «حلقهٔ ریدایرکت یعنی سرور خراب است»، درحالی‌که در تجربهٔ من، در بیش از نود درصد موارد، ریشه در یک تنظیم کوچک و قابل‌اصلاح است، نه در خرابی سرور.

در این مقاله، همان مسیری را باز می‌کنم که در پروژه‌های واقعی برای تشخیص و رفع حلقهٔ ریدایرکت وردپرس طی می‌کنم. تمرکز من روی تفکیک لایه‌ها، تشخیص دقیق و ارائهٔ راه‌حل‌های مرحله‌به‌مرحله است. اگر با ساختار پایه‌ای وردپرس آشنایی ندارید، پیشنهاد می‌کنم ابتدا وردپرس چیست و چگونه شروع کنیم را بخوانید؛ بقیهٔ این مقاله روی همان بستر سوار می‌شود.

حلقهٔ ریدایرکت دقیقاً چیست؟

حلقهٔ ریدایرکت وضعیتی است که در آن، یک آدرس A شما را به آدرس B می‌فرستد، و آدرس B شما را به آدرس A برمی‌گرداند. نتیجه، یک چرخهٔ بی‌پایان است که مرورگر پس از چند دور، تسلیم می‌شود و پیام ERR_TOO_MANY_REDIRECTS را نشان می‌دهد. این خطا، از نظر فنی یک خطای HTTP نیست؛ یک وضعیت منطقی است. یعنی هیچ‌کدام از سرورها خطا نمی‌دهند، هرکدام فقط به‌درستی وظیفهٔ ریدایرکت خودشان را انجام می‌دهند — اما مجموع رفتارشان یک بن‌بست است.

در وردپرس، حلقهٔ ریدایرکت معمولاً از تداخل سه لایه سرچشمه می‌گیرد: لایهٔ دیتابیس (مقادیر siteurl و home)، لایهٔ وب‌سرور (قوانین .htaccess یا پیکربندی Nginx)، و لایهٔ برنامه (افزونه‌های ریدایرکت یا کدهای سفارشی). هر لایه به‌تنهایی می‌تواند ریدایرکت درست داشته باشد، اما اگر این سه لایه با هم هم‌راستا نباشند، نتیجه یک چرخه می‌شود.

درک این نکته، اولین قدم تشخیص است. کسی که حلقه را فقط به‌عنوان «مشکل سرور» می‌بیند، در مسیر اشتباه گم می‌شود. اما کسی که می‌داند حلقه، نشانهٔ یک ناهم‌راستایی بین لایه‌هاست، می‌تواند از کدام لایه شروع کند و چگونه آن را جدا کند.

حلقهٔ ریدایرکت، پیام «سرور خراب است» نیست؛ پیام «دو لایه، از یک موضوع، دو برداشت متفاوت دارند» است. برای حل، باید هر دو برداشت را کنار هم دید.

چرا این خطا مبهم است؟

سه ویژگی، حلقهٔ ریدایرکت را به یکی از مبهم‌ترین خطاهای وردپرس تبدیل می‌کند:

• سایت در ظاهر سالم است: برخلاف خطای ۵۰۰ یا صفحهٔ سفید، سایت شما درخواست‌ها را می‌گیرد و پاسخ می‌دهد. فقط پاسخ‌ها هیچ‌وقت به مقصد نهایی نمی‌رسند.
• پیام خطا در مرورگر است، نه در سرور: برخلاف بسیاری از خطاها، حلقه در لاگ سرور اغلب به‌عنوان «درخواست‌های موفق» ثبت می‌شود، چون از نگاه سرور، هر ریدایرکت با کد ۳۰x پاسخ داده شده. سرنخ، در سمت مرورگر است نه سرور.
• علت در چند لایه پخش شده: برای دیدن تصویر کامل، باید هم دیتابیس، هم قوانین سرور، هم تنظیمات افزونه‌ها، و هم پیکربندی CDN را با هم نگاه کنید. یک نگاه تک‌لایه‌ای، همیشه گمراه‌کننده است.

تجربه‌ام می‌گوید ترتیب درست تشخیص، تفاوت بین «حل در چند دقیقه» و «چند ساعت سردرگمی» است. این ترتیب را در بخش تشخیص به‌تفصیل می‌آورم.

آناتومی یک حلقهٔ ریدایرکت

برای اینکه بفهمید چطور حلقه شکل می‌گیرد، باید یک مثال سادهٔ فنی را ببینید. فرض کنید:

1. مرورگر آدرس http://example.com/ را درخواست می‌کند.
2. سرور Apache می‌گوید: «همهٔ درخواست‌های HTTP باید به HTTPS ریدایرکت شوند.» پس مرورگر را به https://example.com/ می‌فرستد.
3. مرورگر آدرس https://example.com/ را درخواست می‌کند.
4. این بار، افزونهٔ ریدایرکت یا یک قانون دیگر در .htaccess می‌گوید: «همهٔ درخواست‌های HTTPS باید به http:// ریدایرکت شوند.» — این می‌تواند به‌خاطر یک قانون قدیمی، یک خطای نگارشی، یا یک تعارض پیکربندی باشد.
5. مرورگر دوباره به http://example.com/ برمی‌گردد، و چرخه از سر شروع می‌شود.

این مثال ساده، الگوی تمام حلقه‌های ریدایرکت را نشان می‌دهد: یک لایه می‌گوید «الف به ب»، لایهٔ دیگر می‌گوید «ب به الف». به‌جای تلاش برای کشف کدام لایه مقصر است، باید هر دو لایه را باز کنید و ببینید کدام قانون، در چه سطحی، ریدایرکت متناقض را اعمال می‌کند. این همان چیزی است که در بخش تشخیص گام‌به‌گام باز می‌کنم.

تشخیص نوع حلقه از روی آدرس مرورگر

یکی از کاربردی‌ترین مهارت‌هایی که در پروژه‌های خودم یاد گرفته‌ام، تشخیص نوع حلقه از روی الگوی تغییر آدرس در نوار مرورگر است. جدول زیر، این الگوها را دسته‌بندی می‌کند:

هرچه سریع‌تر این جدول را در ذهن داشته باشید، در پروندهٔ واقعی، زمان کمتری برای حدس‌زدن صرف می‌کنید. در پروژه‌هایی که با این مسئله برخورد داشته‌ام، صرف یک دقیقه نگاه دقیق به الگوی تغییر آدرس، معمولاً جهت‌گیری کلی تشخیص را روشن کرده است.

ده سناریوی رایج که در پروژه‌ها دیده‌ام

در پرونده‌های متعددی که حلقهٔ ریدایرکت را عیب‌یابی کرده‌ام، ده سناریو بیشترین تکرار را داشته‌اند. هر سناریو، نشانه‌ها و مسیر تشخیص خاص خودش را دارد:

1. حلقهٔ HTTPS و HTTP ناشی از تنظیمات ناهماهنگ سرور و دیتابیس.
2. حلقهٔ www و بدون www به‌خاطر قوانین ریدایرکت متناقض.
3. تناقض بین مقادیر siteurl و home در دیتابیس.
4. قوانین متناقض یا تکراری در .htaccess.
5. افزونهٔ ریدایرکت با قوانین ناسازگار با سرور.
6. پیکربندی نادرست CDN در لایهٔ پروکسی.
7. کش کهنه یا نامنطبق که نسخهٔ قدیمی را سرو می‌کند.
8. حلقه در صفحهٔ ورود ناشی از افزونهٔ امنیتی یا کوکی معیوب.
9. کوکی‌های گیرکرده در چند دامنه یا زیردامنه.
10. فایروال ابری یا هاست با قوانین ریدایرکت ناهماهنگ.

در ادامه، این ده سناریو را با نشانه‌ها و مسیر رفع جداگانه باز می‌کنم.

سناریوی اول: حلقهٔ HTTPS و HTTP

شایع‌ترین نوع حلقه، همان تبدیلی است که در آن، بخشی از سایت می‌خواهد همه‌چیز روی HTTPS باشد و بخش دیگر اصرار دارد روی HTTP بماند. این اتفاق، به‌ویژه بعد از نصب گواهی SSL یا بعد از تغییر تنظیمات سرور رخ می‌دهد.

در تجربهٔ من، سه دلیل عمده برای این سناریو وجود دارد. اول، تنظیمات تناقضی در .htaccess که هم قوانین HTTPS را اجبار می‌کند و هم یک بلوک قدیمی ریدایرکت HTTP را نگه داشته. دوم، مقادیر دیتابیس که هنوز روی HTTP هستند اما سرور شما اجباراً HTTPS را اعمال می‌کند. سوم، افزونهٔ امنیتی یا SSL که خودش ریدایرکت اضافه می‌کند و با قوانین سرور تعارض دارد.

تشخیص: اول از phpMyAdmin، جدول wp_options را باز کنید و مقادیر siteurl و home را ببینید. اگر سایت شما روی HTTPS است، هر دو مقدار باید با https:// شروع شوند. سپس فایل .htaccess را از ریشهٔ سایت باز کنید و به دنبال بلوک‌های RewriteCond %{HTTPS} بگردید. اگر بیش از یک بلوک ریدایرکت HTTPS دارید، احتمال تعارض بالاست. اگر با مدیریت SSL و گواهی آشنا نیستید، رفع خطای SSL در وردپرس نقطهٔ شروع دقیقی است.

رفع: پس از تشخیص، مسیر رفع معمولاً ساده است. اول، مقادیر دیتابیس را با پروتکل نهایی هم‌راستا کنید. دوم، .htaccess را باز کنید و بلوک‌های ریدایرکت تکراری را ادغام یا حذف کنید. سوم، اگر افزونهٔ امنیتی ریدایرکت اضافه می‌کند، تنظیماتش را با قوانین سرور هم‌راستا کنید. پیش از هر تغییر، بکاپ کامل بگیرید — مسیرش در چگونه از سایت وردپرسی بکاپ بگیریم.

سناریوی دوم: حلقهٔ www و بدون www

حلقهٔ بین www.example.com و example.com، زمانی رخ می‌دهد که یک لایه می‌گوید «همه‌چیز باید با www باشد» و لایهٔ دیگر می‌گوید «همه‌چیز باید بدون www باشد». برخلاف باور عمومی، این نوع حلقه بیشتر از خطای سرور، از تناقض تصمیم‌ها می‌آید.

نشانهٔ این سناریو، مشخص است: نوار آدرس مرورگر مدام بین دو نسخهٔ دامنه جابه‌جا می‌شود. اگر با یک بار رفرش سایت، آدرس در نوار مرورگر حرف www را اضافه یا حذف می‌کند، این حلقه را دارید.

تشخیص: سه لایه را بررسی کنید. اول، در .htaccess، قوانین RewriteCond %{HTTP_HOST} را ببینید. اگر بیش از یک قانون برای مدیریت www وجود دارد، احتمال تعارض بالاست. دوم، در دیتابیس، مقادیر siteurl و home را ببینید — آیا با یا بدون www هستند؟ سوم، در تنظیمات CDN یا هاست، آیا لایهٔ دیگری هم این ریدایرکت را اعمال می‌کند؟

رفع: پس از تشخیص، سه لایه را با یک تصمیم واحد هم‌راستا کنید. مثلاً اگر تصمیم گرفتید همه‌چیز با www باشد، هر سه لایه باید به همان سمت ریدایرکت کنند. این کار، نیاز به یک بازبینی دقیق دارد و یک اشتباه کوچک، حلقه را برمی‌گرداند. بنابراین، پیش از اعمال، حتماً در محیط استیجینگ تست کنید.

سناریوی سوم: تناقض siteurl و home

مقادیر siteurl و home در دیتابیس، تعیین می‌کنند وردپرس از چه آدرسی به خودش ارجاع دهد. اگر این دو مقدار با هم یا با آدرس واقعی سایت هم‌راستا نباشند، حلقه‌های عجیب و ناخوشایندی رخ می‌دهد.

مثال کلاسیک: بعد از انتقال سایت از دامنهٔ قدیمی به دامنهٔ جدید، مقادیر دیتابیس به‌روزرسانی نشده و هنوز به دامنهٔ قدیمی اشاره می‌کنند. در این حالت، وردپرس بازدیدکننده را از دامنهٔ جدید به دامنهٔ قدیمی می‌فرستد، سرور دامنهٔ قدیمی او را به دامنهٔ جدید برمی‌گرداند، و حلقه شکل می‌گیرد.

تشخیص: از phpMyAdmin، جدول wp_options را باز کنید و مقدار siteurl و home را با آدرس واقعی سایت مقایسه کنید. اگر تفاوت دارند، مقصر پیدا شده است.

رفع: مقادیر را با یک کوئری ساده اصلاح کنید:

UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'home';

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

هر بار که دامنه یا پروتکل سایت تغییر می‌کند، قبل از هر کار دیگری، سه جای زیر را هم‌راستا کنید: wp_options در دیتابیس، فایل .htaccess در سرور، و تنظیمات CDN. یک نگاه سریع به این سه، از اکثر حلقه‌ها جلوگیری می‌کند.

سناریوی چهارم: قوانین متناقض .htaccess

فایل .htaccess در ریشهٔ سایت، می‌تواند منبع حلقه‌های پیچیده باشد. سه دلیل رایج که در پروژه‌ها دیده‌ام:

• بلوک‌های ریدایرکت تکراری: دو بلوک که هر دو وظیفهٔ ریدایرکت HTTPS یا www را انجام می‌دهند اما با شرط‌های متفاوت. در بعضی شرایط، این دو بلوک با هم تداخل پیدا می‌کنند.
• خطای نگارشی در یک بلوک: یک RewriteRule که به‌اشتباه یک شرط را نقض می‌کند، می‌تواند ریدایرکت معکوس ایجاد کند.
• قوانین افزونه‌ای که حذف ناقص شده‌اند: اگر افزونه‌ای را حذف کرده باشید اما بلوک مربوط به آن در .htaccess باقی مانده باشد، تعارض ایجاد می‌شود.

تشخیص: فایل .htaccess را باز کنید و از بالا به پایین بخوانید. هر بلوک RewriteRule را ببینید — شرطش چیست، مقصدش کدام است؟ اگر بین دو بلوک تناقض دیدید، مقصر پیدا شده. اگر بیش از حد پراکنده یا مبهم است، مسیر ساده‌تر: کل فایل را موقتاً پاک کنید و بگذارید وردپرس نسخهٔ پیش‌فرض را بازسازی کند.

رفع: روش پاک‌سازی و بازسازی که در پروژه‌های خودم زیاد به‌کار می‌برم: فایل .htaccess را به .htaccess.old تغییر نام دهید، سپس از پیشخوان به «تنظیمات ← پیوندهای یکتا» بروید و یک بار بدون تغییر، ذخیره کنید. وردپرس یک .htaccess استاندارد می‌سازد. اگر مشکل حل شد، بلوک‌های سفارشی خودتان را یکی‌یکی از فایل قدیمی بردارید و اضافه کنید. بلوکی که حلقه را برگرداند، مقصر است.

سناریوی پنجم: افزونهٔ ریدایرکت با قوانین ناسازگار

افزونه‌های ریدایرکت، ابزاری قدرتمند هستند اما اگر با دقت پیکربندی نشوند، خودشان می‌توانند منبع حلقه شوند. سه الگوی رایج:

• قانون دوسویه: یک قانون که A به B ریدایرکت می‌کند، و یک قانون دیگر که B به A ریدایرکت می‌کند. معمولاً این اتفاق بعد از مهاجرت دامنه رخ می‌دهد که قوانین قدیمی حذف نشده‌اند.
• ریدایرکت سراسری به یک صفحه: یک قانون که «همه‌چیز به صفحهٔ اصلی» ریدایرکت می‌کند اما به‌اشتباه صفحهٔ اصلی را هم شامل می‌شود.
• قوانین HTTPS که با سرور تعارض دارند: افزونهٔ ریدایرکت یک قانون HTTPS اضافه می‌کند اما سرور شما قانون دیگری دارد که آن را نقض می‌کند.

تشخیص: از پیشخوان، فهرست قوانین افزونهٔ ریدایرکت را باز کنید. هر قانون را ببینید: مبدأ و مقصد چیست؟ آیا حلقه‌ای بین دو قانون دیدید؟ همچنین، افزونه را موقتاً غیرفعال کنید و ببینید حلقه از بین می‌رود یا نه. اگر رفت، مقصر پیدا شده.

رفع: قوانین ناسازگار را حذف یا اصلاح کنید. اگر تعداد قوانین زیاد است، می‌توانید از یک اسکریپت کوچک برای export گرفتن و بررسی ساختاری استفاده کنید. در پروژه‌هایی که با افزونه‌های ریدایرکت کار می‌کنم، همیشه یک نسخهٔ پشتیبان از قوانین نگه می‌دارم تا در صورت خرابی، سریع برگردانم.

سناریوی ششم: پیکربندی نادرست CDN

اگر سایت شما پشت یک CDN است، احتمال دارد لایهٔ پروکسی در ایجاد حلقه نقش داشته باشد. نشانهٔ این سناریو: وقتی سایت را از یک شبکه بدون CDN باز می‌کنید، مشکل وجود ندارد، اما از شبکهٔ عمومی، حلقه رخ می‌دهد.

سه دلیل رایج:

• تنظیمات SSL نادرست بین CDN و سرور مبدأ: اگر CDN بخواهد از HTTPS استفاده کند اما سرور مبدأ ریدایرکت به HTTP کند، حلقه شکل می‌گیرد.
• قوانین ریدایرکت در سطح CDN: بعضی CDNها امکان تعریف ریدایرکت دارند که با سرور مبدأ تعارض پیدا می‌کند.
• پیکربندی دامنهٔ اصلی در CDN: اگر CDN، دامنهٔ شما را به یک دامنهٔ دیگر نگاشت کرده باشد و آن دامنه دوباره شما را به دامنهٔ اصلی برگرداند، حلقه رخ می‌دهد.

تشخیص: از پنل CDN، بخش تنظیمات SSL و ریدایرکت را بررسی کنید. اگر با ابزار curl -I از یک شبکهٔ بدون CDN تست کنید و مشکل نبینید، مقصر CDN است. یک نکتهٔ عملی: در بعضی CDNها، حالت SSL باید روی «Full (Strict)» باشد نه «Flexible» — چون حالت Flexible می‌تواند حلقه ایجاد کند.

رفع: پس از تشخیص، تنظیمات CDN را با سرور مبدأ هم‌راستا کنید. اگر تنظیمات پیچیده است، به‌طور موقت CDN را در حالت «DNS Only» بگذارید تا ترافیک مستقیم به سرور برود و ببینید حلقه از بین می‌رود یا نه. اگر رفت، مسئله در تنظیمات CDN است.

سناریوی هفتم: کش کهنه یا نامنطبق

گاهی حلقه‌ای که می‌بینید، واقعی نیست؛ یک کش کهنه است که نسخهٔ قدیمی یک ریدایرکت را سرو می‌کند. یعنی قوانین سرور یا افزونه را اصلاح کرده‌اید، اما مرورگر شما یا CDN، نسخهٔ قدیمی را همچنان پاسخ می‌دهد.

نشانهٔ این سناریو: در پنجرهٔ ناشناس یا از یک دستگاه دیگر، حلقه وجود ندارد؛ اما در مرورگر عادی شما، همچنان ادامه دارد. این تجربه را در پروژه‌های خودم چندین بار داشته‌ام.

تشخیص: سایت را در پنجرهٔ ناشناس باز کنید. اگر حلقه نبود، مسئله در کش مرورگر شماست. اگر همچنان بود، کش CDN یا کش سرور را پاک کنید و مجدداً تست کنید. برای پاک‌کردن کش افزونه‌ای، از پیشخوان به تنظیمات افزونهٔ کش بروید و «Clear All Cache» را بزنید. اگر از CDN استفاده می‌کنید، در پنل آن هم گزینهٔ Purge Cache را اجرا کنید.

رفع: بعد از پاک‌سازی کش، سایت را در چند مرورگر و از چند شبکهٔ مختلف تست کنید. اگر در همه‌جا حلقه رفع شده، مسئله فقط کش بوده. اگر همچنان ادامه دارد، باید سراغ لایه‌های دیگر بروید.

سناریوی هشتم: حلقه در صفحهٔ ورود

یکی از سناریوهای خاص و آزاردهنده، حلقه‌ای است که فقط در صفحهٔ ورود به پیشخوان رخ می‌دهد. یعنی سایت شما برای بازدیدکننده عادی کاملاً سالم است، اما شما نمی‌توانید وارد پیشخوان شوید و مدام به صفحهٔ ورود برگردانده می‌شوید.

این نوع حلقه، معمولاً به یکی از سه دلیل رخ می‌دهد: افزونهٔ امنیتی با سیاست سخت‌گیرانه، کوکی‌های معیوب در دامنه‌های چندگانه، یا تنظیمات HTTPS که در صفحهٔ ورود اعمال نمی‌شود. اگر با این نوع حلقه دست‌به‌گریبان هستید، رفع خطای ورود به پنل مدیریت وردپرس مقالهٔ دقیق‌تری است که به تفصیل به این سناریو پرداخته.

رفع: اگر با این نوع حلقه روبه‌رو شدید، اول افزونه‌های امنیتی را موقتاً غیرفعال کنید. سپس کوکی‌های سایت را در مرورگر پاک کنید. اگر حلقه رفع شد، تنظیمات افزونهٔ امنیتی را بازبینی کنید.

سناریوی نهم: کوکی‌ها و دامنه‌های متعدد

اگر سایت شما روی چند دامنه (مثلاً example.com، www.example.com و یک دامنهٔ قدیمی که هنوز فعال است) کار می‌کند، کوکی‌ها می‌توانند منبع حلقه شوند. به‌خصوص اگر کوکی‌ها در یک دامنه تنظیم شده باشند اما درخواست در دامنهٔ دیگر انجام شود.

تشخیص: در DevTools مرورگر، به بخش Application و سپس Cookies بروید. ببینید کوکی‌های wordpress_logged_in_* در کدام دامنه تنظیم شده‌اند. اگر دامنه با دامنهٔ فعلی سایت مطابقت ندارد، این می‌تواند نشانهٔ حلقه باشد.

رفع: از طریق phpMyAdmin، جدول wp_options را باز کنید و به دنبال ردیف siteurl و home بگردید. مقادیر این دو، باید دقیقاً با دامنهٔ فعلی سایت مطابقت داشته باشند. اگر دامنهٔ قدیمی در کوکی‌ها گیر کرده، مرورگر شما کوکی‌های قدیمی را نگه داشته. پاک‌کردن کوکی‌های آن دامنه در مرورگر، این مسئله را حل می‌کند.

سناریوی دهم: فایروال ابری یا هاست

در بعضی موارد، فایروال ابری (مثل Cloudflare) یا فایروال هاست (مثل Imunify360 یا ConfigServer) خودش منبع حلقه است. نشانهٔ این سناریو: سایت برای بازدیدکننده عادی کار می‌کند، اما برای IP شما (یا در یک بازهٔ زمانی خاص) حلقه ایجاد می‌شود.

سه دلیل رایج:

• قوانین ریدایرکت در فایروال: بعضی فایروال‌ها برای بازدیدکنندهٔ مشکوک، یک ریدایرکت به صفحهٔ چالش (challenge) اضافه می‌کنند. اگر این صفحه خودش ریدایرکت معکوس داشته باشد، حلقه رخ می‌دهد.
• مسدودسازی IP شما: اگر IP شما در فهرست مسدود باشد، فایروال شما را به یک صفحهٔ دیگر می‌فرستد که با آدرس سایت تعارض دارد.
• تنظیمات Rate Limit: اگر بازهٔ محدودسازی روی IP شما فعال شده باشد، فایروال ممکن است شما را دچار حلقه کند.

تشخیص: در پنل فایروال، بخش Security Logs یا Events را ببینید. اگر ریدایرکت‌های ناشی از فایروال می‌بینید، مقصر پیدا شده. یک نکتهٔ عملی: بعضی فایروال‌ها، در لاگ خود پیام واضحی نمی‌دهند و باید از راه‌های جانبی (مثل تست از IP دیگر) مقصر را پیدا کنید.

رفع: اگر مقصر فایروال است، IP خودتان را در فهرست مجاز قرار دهید یا سیاست‌های سخت‌گیرانه را تعدیل کنید. اگر مقصر هاست است، با پشتیبانی تماس بگیرید و توضیح دهید که حلقه را در چه شرایطی تجربه می‌کنید.

روش گام‌به‌گام تشخیص

ترتیبی که در پروژه‌های خودم طی می‌کنم، از سریع‌ترین به دقیق‌ترین است:

1. الگوی تغییر آدرس را در مرورگر ببینید. چه چیزی به چه چیزی ریدایرکت می‌شود؟ این نگاه اول، نیمی از تشخیص را روشن می‌کند.
2. در پنجرهٔ ناشناس تست کنید. اگر در حالت ناشناس کار می‌کند، مسئله در کش یا کوکی مرورگر شماست.
3. مقادیر siteurl و home را در دیتابیس چک کنید. این ساده‌ترین لایه است و در بسیاری از موارد، مقصر همین‌جاست.
4. فایل .htaccess را باز کنید. بلوک‌های ریدایرکت را یکی‌یکی ببینید. اگر تعارضی هست، حذف یا ادغام کنید.
5. افزونه‌های ریدایرکت را موقتاً غیرفعال کنید. اگر حلقه رفع شد، فهرست قوانین را بازبینی کنید.
6. تنظیمات CDN را چک کنید. اگر سایت پشت CDN است، حالت SSL و قوانین ریدایرکت را بررسی کنید.
7. کش را پاک کنید. هم کش مرورگر، هم کش افزونه، هم کش CDN.

این ترتیب، از ارزان به گران پیش می‌رود و در پروژه‌های واقعی، بیش از نود درصد پرونده‌ها تا گام چهارم حل می‌شوند. اگر تا گام آخر رسیدید و مسئله همچنان باقی است، معمولاً مشکل در لایهٔ CDN یا فایروال است و نیاز به کمک پشتیبانی آن سرویس دارید.

ابزارهای مفید برای شکار حلقه

سه ابزار که در پروژه‌های خودم زیاد استفاده می‌کنم و در تشخیص حلقه نقش کلیدی داشته‌اند:

یک — curl با گزینهٔ -I: این ابزار، سربرگ پاسخ هر درخواست را نشان می‌دهد. با یک دستور ساده، می‌توانید زنجیرهٔ ریدایرکت‌ها را ببینید:

curl -I -L --max-redirs 10 https://yourdomain.com

گزینهٔ -L ریدایرکت‌ها را دنبال می‌کند و --max-redirs 10 جلوی حلقهٔ بی‌پایان را می‌گیرد. در خروجی، هر ریدایرکت با کد ۳۰x و مقصدش دیده می‌شود. این یک تصویر فنی از کل زنجیره است که از دید مرورگر پنهان می‌ماند.

دو — ابزارهای آنلاین بررسی ریدایرکت: سرویس‌هایی مثل redirect-checker.org یا similar، زنجیرهٔ ریدایرکت شما را از دید یک سرور دیگر نمایش می‌دهند. این ابزارها، در تشخیص حلقه‌های سمت CDN یا DNS، بسیار مفید هستند.

سه — DevTools مرورگر: در سربرگ Network، گزینهٔ «Preserve log» را فعال کنید و سایت را باز کنید. هر درخواست با کد وضعیتش نمایش داده می‌شود. زنجیرهٔ ریدایرکت‌ها را می‌توانید یکی‌یکی ببینید. این ابزار، برای دیدن کوکی‌ها و هدرهای ارسالی، بهترین گزینه است.

رفع نهایی و راستی‌آزمایی

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

1. تست در چند مرورگر و از چند شبکه: سایت را در Chrome، Firefox و Safari (یا Edge) باز کنید و از دو شبکهٔ متفاوت (مثلاً وای‌فای و اینترنت موبایل) تست کنید. اگر در همه‌جا سالم بود، مسئله رفع شده.
2. تست با ابزار curl: با curl -I، بررسی کنید که سربرگ‌های پاسخ، یک زنجیرهٔ منطقی را نشان می‌دهند — یعنی ریدایرکت‌ها یا وجود ندارند یا یک مسیر خطی ساده‌اند.
3. پایش ۴۸ ساعته: حداقل دو روز سایت را زیر نظر بگیرید. بعضی حلقه‌ها فقط در بازه‌های زمانی خاص (به‌خاطر کش، سیاست فایروال، یا ترافیک) ظاهر می‌شوند.

یک نکتهٔ ظریف: بعد از رفع حلقه، اگر سایت شما پشت CDN است، کش آن را حتماً پاک کنید. اگر این کار را نکنید، ممکن است کاربران همچنان نسخهٔ قدیمی حلقه را ببینند. همچنین، در هفتهٔ اول بعد از رفع، لاگ سرور را برای خطاهای ۳۰x غیرعادی پایش کنید — اگر حلقه در شرف برگشت است، این پایش زودتر به شما خبر می‌دهد.

اشتباهات رایج در مواجهه با حلقه

یک اشتباه ظریف که در دیدگاه‌ها زیاد می‌بینم: کاربران، بعد از رفع حلقه، از تناقضی که در لایه‌های دیگر باقی مانده غافل می‌شوند. مثلاً حلقه را در .htaccess حل می‌کنند اما مقادیر دیتابیس را هم‌راستا نمی‌کنند. دو هفته بعد، همان حلقه از یک لایهٔ دیگر برمی‌گردد. راه درست: بعد از رفع حلقه، هر سه لایه را یک‌بار دیگر بازبینی کنید و اطمینان حاصل کنید که با هم هم‌راستا هستند.

پیشگیری بلندمدت

پنج عادت که در پروژه‌های خودم، نرخ این خطا را به کمترین حد رسانده:

• پیش از هر تغییر دامنه یا پروتکل، نقشهٔ ریدایرکت‌ها را بنویسید: دقیقاً مشخص کنید کدام آدرس به کدام آدرس ریدایرکت می‌شود و چه لایه‌ای مسئول این ریدایرکت است.
• مقادیر دیتابیس، سرور، و CDN را هم‌راستا نگه دارید: هرگاه یکی تغییر کرد، دو تای دیگر را بازبینی کنید.
• در محیط استیجینگ تست کنید: همهٔ تغییرات مربوط به ریدایرکت را اول در استیجینگ اعمال کنید. اگر با ابزارهای توسعه وردپرس آشنا نیستید، توسعه وردپرس چیست می‌تواند نقطهٔ شروع باشد.
• از یک افزونهٔ ریدایرکت معتبر و ساده استفاده کنید: همان‌طور که در بهترین افزونه‌های امنیتی وردپرس گفتم، سادگی، دوست شماست. افزونه‌ای که قوانین متناقض می‌سازد، بیش از آنکه مفید باشد، دردسر ایجاد می‌کند.
• لاگ ریدایرکت‌ها را ماهانه بازبینی کنید: اگر فهرست قوانین شما بیش از ۲۰ مورد است، احتمال تعارض بالا می‌رود. مرتب‌سازی دوره‌ای، از حلقه‌های آینده جلوگیری می‌کند.

و یک نکتهٔ عملی که در پروژه‌های خودم زیاد به‌کار می‌آید: پیش از هر انتقال دامنه، یک «حالت آزمایشی» روی دامنهٔ جدید راه بیندازید. این کار، از حلقه‌های ناشی از تناقض دامنه جلوگیری می‌کند. راهنمای این کار، بخشی از اصول سئو تکنیکال است که به جنبه‌های فنی مدیریت سایت می‌پردازد.

نگاه مهندسی: حلقه به‌مثابه نشانهٔ ناهم‌راستایی معماری

از منظر کسی که وردپرس را به‌عنوان یک پلتفرم تولیدی می‌بیند، حلقهٔ ریدایرکت یک نشانهٔ سیستمی است، نه یک باگ لحظه‌ای. سه تفکیک در این نگاه، به تشخیص و پیشگیری بلندمدت کمک می‌کند:

یک — حلقه، علامت نبود یک منبع واحد حقیقت (Single Source of Truth) است. در سیستم‌های سالم، هر پرسش باید یک پاسخ مشخص داشته باشد. اگر از سه لایه بپرسید «آدرس اصلی سایت چیست؟» و سه پاسخ متفاوت بگیرید، حلقه اجتناب‌ناپذیر است. راه‌حل معماری این است که یکی از لایه‌ها را به‌عنوان «منبع حقیقت» تعیین کنید — معمولاً دیتابیس وردپرس — و بقیهٔ لایه‌ها از آن پیروی کنند. در معماری‌های مدرن، این مفهوم با نام «Configuration as Code» شناخته می‌شود: همهٔ تنظیمات از یک منبع، به‌صورت خودکار به لایه‌های دیگر منتشر می‌شوند.

دو — حلقه، نشانهٔ نبود مشاهده‌پذیری در لایهٔ ریدایرکت است. اگر لاگی وجود نداشت که بگوید «کدام لایه، این ریدایرکت را اعمال کرد»، تشخیص همیشه به حدس و آزمون‌وخطا تبدیل می‌شود. در پروژه‌های بالغ، من همیشه یک لاگ سبک برای ریدایرکت‌ها فعال می‌کنم — با ثبت زمان، لایهٔ اعمال‌کننده، مبدأ و مقصد. این لاگ، در روزهای بحرانی، تفاوت بین «چند ساعت سردرگمی» و «چند دقیقه تشخیص» است. اگر شما چند سایت وردپرسی مدیریت می‌کنید، اضافه‌کردن این لاگ به هر سایت، یک سرمایه‌گذاری کوچک با بازدهی بلندمدت است.

سه — حلقه، مرز بین معماری مونولیتیک و میکروسرویس را نشان می‌دهد. در وردپرس استاندارد، همه‌چیز — دیتابیس، فایل‌سیستم، برنامه، و بخشی از منطق ریدایرکت — در یک پروسه زندگی می‌کند. این یکپارچگی، سادگی می‌آورد اما حلقه‌های پیچیده را ممکن می‌سازد. در معماری‌های بالغ، معمولاً لایهٔ ریدایرکت از لایهٔ محتوا جدا می‌شود: یک reverse-proxy یا CDN، مسئول ریدایرکت‌های سطح شبکه است؛ وردپرس، مسئول ریدایرکت‌های سطح محتوا. این جداسازی، از حلقه‌های متقابل جلوگیری می‌کند، چون هر لایه فقط یک نقش دارد. برای پروژه‌های پرمعامله یا حساس، این جداسازی ارزش سرمایه‌گذاری دارد — حتی اگر به معنای پیچیدگی عملیاتی بیشتر باشد.

نگاه عمیق‌تر، این واقعیت را آشکار می‌کند که حلقهٔ ریدایرکت، در واقع یک معیار بلوغ است. سایت‌هایی که هر چند ماه با حلقه دست‌به‌گریبان می‌شوند، معمولاً از یک الگوی معماری مشترک رنج می‌برند: تنظیمات پخش‌شده در چند لایه، بدون منبع حقیقت، بدون لاگ، و بدون تست خودکار. سایت‌هایی که این حلقه‌ها را کم‌تر تجربه می‌کنند، معمولاً سه ویژگی دارند: یک منبع حقیقتِ مستند، یک فرآیند استقرارِ مرحله‌ای، و یک لاگ‌گیرِ دائمی. تفاوت این دو دسته، نه در ابزارها، که در نظم معماری است. اگر می‌خواهید از حلقه‌های آینده پیشگیری کنید، اولین قدم ساده‌ای که توصیه می‌کنم: یک فایل کوچک مستندات بسازید که در آن، آدرس اصلی سایت، پروتکل، حالت www، و مسئول هر ریدایرکت در آن ثبت شده باشد. همین یک عادت، در پروژه‌های خودم چندین بار از حلقه‌های آینده جلوگیری کرده است.

سخن پایانی

حلقهٔ ریدایرکت در وردپرس، در ظاهر یک خطای سرور است، اما در واقع نشانهٔ ناهم‌راستایی بین لایه‌های معماری سایت است. بیشتر موارد، در یکی از این سه دسته قرار می‌گیرند: تناقض دیتابیس و سرور، تعارض قوانین ریدایرکت، یا پیکربندی نادرست CDN. تشخیص درست، همیشه با نگاه دقیق به الگوی تغییر آدرس در مرورگر و یک بازبینی لایه‌ای آغاز می‌شود.

تجربه‌ام این است که در این خطا، مانند بسیاری از خطاهای وردپرس، «سرعت اقدام» بیش از «دقت تشخیص» می‌تواند وضعیت را بدتر کند. آرام باشید، هر لایه را جدا کنید، ساده‌ترین احتمال را اول رد کنید، و در صورت لزوم از بکاپ استفاده کنید. این ترتیب آرام، همیشه سریع‌تر از اقدام‌های شتاب‌زده جواب می‌دهد.

اگر این خطا را روی سایت خودتان دیده‌اید و یکی از ده سناریوی این مقاله مقصر بوده، خوشحال می‌شوم در دیدگاه‌ها بخوانم. به‌ویژه اگر سناریوی نادری کشف کرده‌اید — مثلاً یک افزونهٔ خاص با یک رفتار غیرمعمول، یا یک سیاست سروری که کمتر دیده می‌شود — همان جزئیات برای خوانندهٔ بعدی که در همان موقعیت گرفتار است، از هر راهنمای عمومی ارزشمندتر است. اگر هم پس از خواندن این مقاله به این نتیجه رسیدید که زیرساخت فعلی شما سقف این نوع مسائل است، دو مقالهٔ راهنمای انتخاب هاست و تأثیر هاست بر سرعت سایت مسیر بعدی شما هستند. 🔄