«وارد wp-admin نمی‌شوم» یک نشانه واحد نیست. ممکن است وردپرس رمز را نپذیرد، فرم دوباره نمایش داده شود، پاسخ 403 بگیرید، صفحه سفید ببینید یا اصلاً /wp-admin به دامنه دیگری برود. راه‌حل درست از تفکیک همین رفتارها شروع می‌شود؛ تعویض رمز برای خطای 403 یا پاک کردن cache برای fatal PHP کمکی نمی‌کند.
پاسخ سریع: متن و status خطا را ثبت کنید، ورود را در پنجره ناشناس امتحان کنید، URL و HTTPS را کنترل کنید، سپس بر اساس نشانه سراغ cookie، حساب کاربری، افزونه امنیتی، PHP یا دیتابیس بروید. پیش از تغییر مستقیم دیتابیس یا فایل‌ها backup بگیرید و هیچ‌گاه رمز یا لینک بازیابی را برای فرد ناشناس ارسال نکنید.
کدام سناریو را می‌بینید؟
| رفتار | بررسی نخست |
|---|---|
| «رمز نادرست» | نام کاربری، ایمیل و بازیابی رمز |
| بازگشت بی‌پیام به فرم | cookie، URL، HTTPS و cache |
| 403 یا Access Denied | WAF، افزونه امنیتی، permission و IP policy |
| Critical Error یا صفحه سفید | PHP log، افزونه و قالب |
| Too many redirects | scheme، proxy، site URL و cookie domain |
| کاربر وجود ندارد یا دسترسی کم است | رکورد کاربر و role/capability |
آزمون‌های کم‌ریسک مرورگر
- URL دقیق
/wp-login.phpرا مستقیم باز کنید. - در پنجره private وارد شوید تا اثر cookie و extension کمتر شود.
- cookieهای همان دامنه را پاک کنید، نه تمام داده‌های مرورگر.
- در DevTools بخش Network، status و مقصد redirect را ببینید.
- اگر چند دامنه یا www دارید، مطمئن شوید فرم و مقصد روی دامنه canonical هستند.
غیرفعال کردن کامل امنیت مرورگر یا پذیرفتن گواهی نامعتبر راه‌حل نیست. اختلاف ساعت شدید دستگاه نیز می‌تواند token یا session بعضی لایه‌ها را مختل کند، ولی باید با شواهد بررسی شود.
اگر نام کاربری یا رمز پذیرفته نمی‌شود
از «رمزتان را گم کرده‌اید؟» استفاده کنید و پوشه Spam را ببینید. مشخص نکردن اینکه ایمیل ارسال نشده یا حساب پیدا نشده، تشخیص را عقب می‌اندازد. اگر ایمیل سایت کار نمی‌کند ولی دسترسی SSH دارید، WP-CLI می‌تواند کاربران را فهرست کند؛ خروجی شامل داده شخصی است و نباید عمومی شود:
wp user list --fields=ID,user_login,user_email,rolesتغییر رمز با WP-CLI ممکن است، اما دستور حاوی رمز می‌تواند در history بماند. یک رمز موقت قوی را با روش امن تعیین و پس از ورود تعویض کنید. ایجاد مدیر تازه فقط برای دور زدن علت، بدون audit و حذف بعدی، ریسک دسترسی باقی‌مانده دارد.
403، 401 یا مسدود شدن IP
اگر وب‌سرور یا WAF قبل از وردپرس درخواست را رد کند، تغییر کاربر وردپرس بی‌اثر است. لاگ Nginx/Apache، CDN و افزونه امنیتی را با timestamp و IP بررسی کنید. محدودیت IP مدیریت اگر عمدی است، باید از مسیر امن و با whitelist دقیق اصلاح شود؛ WAF را برای کل سایت خاموش نکنید. همچنین مالکیت و permission فایل wp-login.php و ruleهای location را کنترل کنید.
خطای PHP هنگام ورود
فرم ورود hookهای افزونه امنیتی، عضویت، کپچا و SSO را اجرا می‌کند. اگر صفحه عمومی سالم اما login خطای 500 می‌دهد، لاگ PHP همان درخواست ارزش بیشتری از تست تصاویر یا page cache دارد. افزونه‌ای را که trace مشخص کرده موقتاً غیرفعال و نتیجه را در staging بازتولید کنید. راهنمای رفع Critical Error وردپرس شیوه ثبت امن debug.log را توضیح می‌دهد.
نقش‌ها و capabilityها
ممکن است login موفق باشد اما کاربر به dashboard دسترسی نداشته باشد. در این حالت role، multisite، افزونه عضویت و تغییرات capability بررسی شوند. ویرایش serialized data در دیتابیس با search/replace متنی خطرناک است. از API وردپرس یا WP-CLI سازگار استفاده کنید و قبل از تغییر، مقدار فعلی را نگه دارید.
Multisite و آدرس مدیریت شبکه
در WordPress Multisite، عضو بودن در یک سایت با Super Admin بودن یکسان نیست. کاربر ممکن است احراز هویت شود اما به dashboard سایتی که عضو آن نیست هدایت نشود. دامنه اصلی شبکه، domain mapping، cookie domain و مسیر /wp-admin/network/ را جداگانه بررسی کنید. افزودن capability به‌صورت دستی برای دور زدن مدل دسترسی می‌تواند مرز سایت‌ها را خراب کند.
اگر احتمال رخداد امنیتی وجود دارد
تغییر ناخواسته ایمیل مدیر، ایجاد حساب ناشناس، redirect به دامنه غریبه یا فایل‌های PHP تازه، مسئله را از «فراموشی رمز» فراتر می‌برد. قبل از پاک‌سازی، log وب‌سرور، audit trail، فهرست کاربران و نمونه فایل مشکوک را حفظ کنید. رمزهای مدیر، هاست، دیتابیس و کلیدهای API باید از یک دستگاه مطمئن rotate شوند و نشست‌های قبلی با تغییر salt یا ابزار معتبر باطل شوند.
فقط حذف حساب ناشناس کافی نیست؛ مسیر ورود مهاجم، persistence احتمالی و یکپارچگی core، plugin و theme باید بررسی شود. restore نیز باید از backup مربوط به پیش از آلودگی باشد و سپس آسیب‌پذیری ورودی اصلاح شود.
اشتباه‌های رایج
- خاموش کردن دائمی افزونه امنیتی یا WAF.
- ساخت چند حساب administrator و فراموش کردن حذف آن‌ها.
- ارسال رمز، cookie یا لینک reset در پیام عمومی.
- تغییر
siteurlوhomeبدون شناخت proxy و دامنه canonical. - ویرایش مستقیم دیتابیس بدون backup و توجه به prefix جدول.
بعد از بازیابی دسترسی
حساب‌های مدیر، نشست‌های فعال، تغییرات اخیر و لاگ امنیتی را مرور کنید. رمز موقت را عوض، احراز هویت دومرحله‌ای را در صورت سازگاری فعال و علت اصلی را مستند کنید. اگر مشکل از ایمیل reset بوده، تحویل SMTP و DNS ایمیل نیز باید جداگانه اصلاح شود.
چه زمانی کمک تخصصی مناسب است؟
اگر حساب مدیر تغییر کرده، نشانه دستکاری امنیتی وجود دارد، چند لایه SSO/CDN درگیرند یا تغییر دیتابیس لازم است، آزمون پراکنده می‌تواند شواهد را از بین ببرد. رفع مشکل فنی وردپرس امکان بررسی هماهنگ کاربر، cookie، PHP، WAF و دیتابیس را فراهم می‌کند. برای حلقه redirect مشخص، راهنمای Redirect Loop ورود وردپرس را دنبال کنید.
پرسش‌های متداول
آیا تغییر نام پوشه افزونه امنیتی امن است؟
به‌عنوان آزمون کوتاه با دسترسی کنترل‌شده ممکن است، اما حفاظت را کاهش می‌دهد. ابتدا log و امکان whitelist را بررسی و پس از آزمون وضعیت را بازگردانید.
چرا reset password ایمیل نمی‌شود؟
ممکن است ایمیل حساب اشتباه، ارسال WordPress/PHP mail ناموفق یا تحویل SMTP مشکل داشته باشد. log ارسال و mailbox را جداگانه بررسی کنید.
آیا phpMyAdmin تنها راه بازیابی مدیر است؟
خیر. WP-CLI و Recovery Mode اغلب کنترل‌شده‌ترند. ویرایش مستقیم دیتابیس آخرین گزینه و نیازمند backup است.