#Суть неисправности и признаки
Пользователь вводит правильные данные на wp-login.php, нажимает «Войти», но вместо панели управления снова появляется форма авторизации. Иногда адрес меняется между HTTP/HTTPS или вариантами с www, а иногда вход мгновенно сбрасывается без сообщения об ошибке. Проблема чаще связана с cookie авторизации, URL и прокси, но также возможны сбои расширений входа и серверной сессии. Нельзя делать вывод, что пароль неверный, если форма возвращается без сообщения и журнал сообщает успешную проверку учётных данных.
#Почему возникает проблема
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Браузер не сохраняет cookie для сайтаCookie блокируются настройкой браузера, расширением или конфликтом домена/схемы. | В приватном окне вход проходит либо после отправки формы cookie не сохраняется. | Проверить cookie и адрес сайта без общего отключения защиты браузера. |
| Неправильные home/siteurl, HTTPS за проксиПри входе WordPress и обратный прокси по-разному определяют HTTPS или основной домен. | В цепочке редиректов меняется host или протокол, возможен повторный /wp-login.php. | Сверить адреса и доверенные настройки прокси. |
| Плагин входа/кеширует страницу авторизацииСистема безопасности или кеширования вмешивается в обработку входа. | После обновления плагина проблема появилась; на тестовой копии без него исчезает. | Изолировать конкретное дополнение, не выключая защиту рабочей площадки. |
| Проблемы доступности файлов/базыPHP не может прочитать конфигурацию либо записать данные, необходимые для авторизации. | Журналы PHP и сервера содержат ошибки, вход нестабилен и для других пользователей. | Исправить подтверждённый сбой хостинга. |
#Пошаговая диагностика и устранение
- Проверьте URL и сохраните данные для диагностикиОткройте сайт вручную через полный HTTPS-адрес, например https://example.com/wp-login.php с заменой домена. Введите пароль один раз и посмотрите, что появилось: «неверный пароль» или молчаливое возвращение на форму. Запишите точный конечный адрес и время. Не отправляйте пароль, ссылки сброса, cookie или код двухфакторной авторизации в поддержку.
- Проверьте вход в приватном окнеОткройте новое окно «Инкогнито» в Chrome/Edge либо приватное окно Firefox и введите адрес нужного домена без перехода со старых закладок. Войдите под своей учётной записью. Если вход работает, причина вероятнее связана с данными обычного профиля или расширением браузера. В обычном окне удалите данные только нужного домена через значок настроек сайта в адресной строке или настройки приватности браузера; не очищайте весь браузер без необходимости.
- Проверьте разрешение cookie и блокировщикиВ обычном браузере откройте сведения о сайте слева от адреса → параметры сайта, найдите разрешения на хранение данных/cookie, которые отличаются по версии браузера. Проверьте, не блокирует ли расширение безопасности cookie именно этого домена. Не выключайте глобальную защиту и не допускайте сторонние cookie для всех сайтов: WordPress обычно использует собственные cookie на своём домене.
- Найдите цепочку редиректов при отправке формыНажмите F12 → «Сеть», включите Preserve log, затем выполните вход с тестовой учётной записью и найдите запрос к wp-login.php. Сравните Request URL и заголовки Location последующих ответов. Если HTTPS сменяется на HTTP либо домен с www на домен без www, проверьте конфигурацию WordPress и прокси. Секретный заголовок Set-Cookie никуда не пересылайте: достаточно отметить, присутствует ли он и какой домен указан.
- Сверьте URL установки в конфигурацииЕсли админка недоступна, через файловый менеджер панели откройте wp-config.php только для чтения и найдите WP_HOME и WP_SITEURL. При наличии WP-CLI под пользователем сайта прочитайте
wp option get homeиwp option get siteurl. Если значения не совпадают с фактическим HTTPS-доменом, сначала проверьте DNS и правильность прокси. Перед изменением в файле и базе сохраните их копии; в многосайтовом WordPress способ иной. - Проверьте прокси и кеши без отключения безопасностиВ панели CDN или веб-сервера убедитесь, что страницы wp-login.php и wp-admin не выдаются из общего публичного кеша. Проверьте, что прокси верно передаёт исходный протокол HTTPS и что на сервере нет взаимоисключающих перенаправлений. Не добавляйте произвольные заголовки в wp-config.php по совету с форума: у хостинга могут быть свои настройки доверенных прокси.
- Изолируйте дополнение авторизации на тестовой копииСоздайте копию сайта или используйте тестовую среду, затем по одному временно выключайте недавно обновлённые плагины входа и кеширования через меню «Плагины» → «Установленные». После каждой проверки сделайте новый вход в приватном окне. Если нужный плагин найден, верните исходное состояние и ищите совместимую версию или точную настройку. На рабочем сайте без согласования не выключайте двухфакторную защиту, ограничение попыток и брандмауэр.
- Проверьте вход после исправления и восстановите настройкиОткройте приватное окно и войдите с основного HTTPS-домена. Должна открыться /wp-admin/, а после обновления страницы вход сохраняется. Затем выйдите штатной кнопкой в меню пользователя и убедитесь, что сеанс завершился. Если цикл продолжается, передайте хостингу обезличенную цепочку редиректов, версии WordPress/PHP и ошибки журнала. Все временные изменения на копии верните; пароль в диагностических материалах не записывайте.
- Для владельца сайта в терминале SSH из каталога WordPress, если установлен WP-CLILinux · Терминал (Bash)КомандаДля владельца сайта в терминале SSH из каталога WordPress, если установлен WP-CLI. Только чтение параметров; не запускайте с sudo и не изменяйте URL до проверки домена и резервной копии.
wp option get homewp option get siteurl
#Как проверить результат и что делать, если не помогло
Исправление подтверждено, когда вход сохраняется в течение обычной работы в панели и не сбрасывается при обновлении /wp-admin/. Если браузер сразу удаляет cookie, проверьте его политику и сторонние расширения; если cookie есть, но вход сбрасывается только за прокси, проверьте исходную схему HTTPS и связанные домены. Не предлагайте сброс пароля, если проверка учётных данных уже успешна.