اگر پس از وارد کردن اطلاعات صحیح دوباره به wp-login.php برمی‌گردید، یا مرورگر ERR_TOO_MANY_REDIRECTS نشان می‌دهد، مشکل معمولاً از ناهماهنگی cookie، دامنه یا تشخیص HTTP/HTTPS است. افزونه امنیتی، cache و reverse proxy نیز می‌توانند همان نشانه را بسازند. پاک کردن cookie یک تست خوب است، اما وقتی چند کاربر هم‌زمان مشکل دارند باید زنجیره redirect سمت سرور را دید.
پاسخ سریع: در پنجره ناشناس تست کنید، redirectهای Network را ثبت کنید، یکسان بودن scheme و host در همه hopها را ببینید و سپس home/siteurl، تنظیمات proxy و cookie را بررسی کنید. HTTPS را خاموش یا validation گواهی را دور نزنید؛ هدف این است که وردپرس و proxy درباره امن بودن درخواست به یک نتیجه برسند.
دو نوع مشکل را از هم جدا کنید
حلقه واقعی HTTP
مرورگر میان دو یا چند URL جابه‌جا می‌شود تا سقف redirect پر شود؛ مثلاً HTTP به HTTPS و سپس برنامه دوباره به HTTP برمی‌گرداند. در DevTools یا ابزار header، statusهای 301/302 و مقدار Location هر hop را ببینید.
بازگشت به فرم پس از login
در این حالت ممکن است redirect محدود باشد اما session معتبر نماند. cookie روی دامنه، path یا secure flag نامناسب تنظیم شده، cache پاسخ شخصی را ذخیره کرده یا یک hook ورود کاربر را خارج کرده است.
از مرورگر شروع کنید
- فقط cookieهای دامنه سایت را پاک کنید.
- افزونه‌های privacy یا password manager را موقتاً در پنجره آزمایشی کنار بگذارید.
- با همان URL canonical وارد شوید؛ میان www و بدون www جابه‌جا نشوید.
- در Network گزینه preserve log را فعال و زنجیره درخواست login را ثبت کنید.
- بررسی کنید پاسخ login واقعاً header مربوط به cookie را می‌فرستد و درخواست بعدی آن را بازمی‌گرداند.
مقدار cookie و nonce داده حساس است؛ screenshot یا HAR را پیش از اشتراک‌گذاری پاک‌سازی کنید.
home و siteurl باید با معماری واقعی هماهنگ باشند
اگر دامنه یا HTTPS تغییر کرده، مقادیر WordPress Address و Site Address ممکن است قدیمی باشند. ثابت‌های WP_HOME و WP_SITEURL در wp-config بر مقدار دیتابیس اولویت می‌گیرند. قبل از تغییر، منبع مؤثر را پیدا کنید؛ تعریف هم‌زمان چند مقدار متناقض مشکل را پیچیده می‌کند.
wp option get home
wp option get siteurlاین فرمان‌ها فقط مقدار را می‌خوانند. تغییر URL در multisite یا انتقال دامنه موضوع گسترده‌تری است و search/replace باید serialization و داده‌های فروشگاهی را رعایت کند.
وردپرس پشت CDN یا Reverse Proxy
ممکن است مرورگر با HTTPS به CDN وصل شود ولی اتصال proxy تا origin با HTTP باشد. اگر headerهای forwarding درست و مورد اعتماد نباشند، وردپرس درخواست را ناامن می‌بیند و redirect متضاد تولید می‌کند. در Nginx معمولاً scheme و host باید به upstream منتقل شوند، اما نام و سیاست header باید با framework و proxyهای زنجیره هماهنگ باشد.
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;این دو خط نمونه بخشی از یک server block هستند، نه پیکربندی کامل قابل کپی. اگر چند proxy وجود دارد، اعتماد کور به header ورودی از اینترنت می‌تواند spoofing ایجاد کند. boundary اعتماد و overwrite شدن header در edge باید روشن باشد.
Cache نباید صفحه ورود را عمومی ذخیره کند
wp-login.php، wp-admin و پاسخ‌های دارای cookie کاربر باید مطابق سیاست cache از ذخیره عمومی خارج شوند. cache افزونه، Nginx FastCGI cache، CDN و browser هر کدام لایه جدا هستند. purge هدفمند انجام دهید و rule را اصلاح کنید؛ خاموش کردن دائمی کل cache فقط نشانه را حذف می‌کند.
افزونه‌های امنیت، عضویت و SSO
تغییر URL ورود، محدودیت IP، captcha، social login و SSO می‌توانند redirect تولید کنند. log افزونه و hook مقصد را بررسی کنید. اگر trace یا زمان تغییر به افزونه مشخصی اشاره دارد، آن را در staging غیرفعال کنید. در production، کنار گذاشتن لایه امنیتی باید کوتاه، کنترل‌شده و همراه محدودیت دسترسی جایگزین باشد.
چرا تغییر فایل .htaccess همیشه جواب نیست؟
در Apache ممکن است rule متناقض عامل loop باشد، اما در Nginx فایل .htaccess خوانده نمی‌شود. redirect ممکن است هم‌زمان در CDN، virtual host، افزونه و وردپرس تعریف شده باشد. یک مالک برای canonical redirect تعیین و ruleهای تکراری حذف شوند.
اشتباه‌های رایج
- خاموش کردن HTTPS برای ورود موقت و ایجاد mixed content یا cookie ناامن.
- تغییر هم‌زمان URL دیتابیس، wp-config، CDN و Nginx.
- پاک کردن همه cacheها بدون ثبت اینکه کدام لایه اثر داشت.
- اعتماد به هر
X-Forwarded-Protoورودی بدون مرز proxy معتبر. - باز کردن wp-admin برای همه IPها جهت دور زدن policy ورود.
یک روند تأیید پس از اصلاح
در پنجره تازه login و logout کنید، صفحه مدیریت را refresh کنید، با یک نقش غیرمدیر نیز آزمایش کنید و canonical URL را در HTTP و HTTPS ببینید. زنجیره redirect باید کوتاه و قابل توضیح باشد. سپس cache، WAF و لاگ خطا را دوباره فعال/بررسی کنید و rule موقت را حذف کنید.
چه زمانی بررسی تخصصی لازم است؟
اگر سایت پشت چند proxy است، SSO دارد یا loop فقط برای بخشی از کاربران رخ می‌دهد، بررسی cookie و header باید در تمام مسیر انجام شود. سرویس رفع مشکل فنی وردپرس برای تحلیل هماهنگ وردپرس، CDN، Nginx و session مناسب است. اگر مشکل شما loop نیست و اصلاً وارد مدیریت نمی‌شوید، ابتدا راهنمای مشکل ورود wp-admin را ببینید.
پرسش‌های متداول
چرا فقط یک کاربر loop می‌بیند؟
cookie قدیمی، extension مرورگر یا وضعیت حساب محتمل‌تر است. مقایسه پنجره ناشناس و کاربر دیگر کمک می‌کند دامنه را محدود کنید.
آیا Cloudflare همیشه مقصر است؟
خیر. mode نامتناسب TLS یا rule edge می‌تواند دخیل باشد، اما زنجیره redirect مشخص می‌کند کدام لایه پاسخ را ساخته است.
آیا تغییر siteurl در دیتابیس کافی است؟
نه همیشه. ثابت wp-config، multisite، proxy و cache ممکن است مقدار مؤثر دیگری بسازند. منبع فعال را ابتدا پیدا کنید.
چرا بعد از پاک کردن cookie موقتاً درست می‌شود؟
ممکن است cookie دامنه یا secure flag ناسازگار دوباره تولید شود. پاسخ login را بررسی کنید تا علت تکرار مشخص شود.