Столкнулся при переносе сайтов на wordpress с одного хостинга на другой с неожиданной проблемой. Ошибка не информативная и совсем не очевидно, как ее решать. В итоге победил и разобрался в проблеме. Решением ошибки и комментариями к ней хочу поделиться с вами.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Содержание:
Введение
Я выполнял перенос сайтов с обычного хостинга с внешним ip адресом. Сайты работали на https. Их нужно было перенести на другой хостинг, который организован немного не стандартно. Запросы сначала приходят на сервер с nginx, работающим в режиме proxy_pass. Дальше запросы по протоколу http уходят на другой сервер, где работают уже непосредственно сами сайты. На втором сервере (бэкенд) стояла связка nginx + php-fpm.
В целом, в такой связке нет ничего необычного. Я ее повсеместно применяю там, где это имеет смысл. Это повышает удобство управления большим количеством сайтов и серверов, плюс в целом безопаснее схема. Многие зловреды, даже если пролезают на сайты, не понимают, как правильно работать в таком окружении. В общем случае проблем не возникает при настройке.
Сайт выполнил переадресацию слишком много раз.
С WordPress получился нюанс. Если просто взять сайт и перенести его на такую схему - ничего не заработает. Первая ошибка, с которой столкнетесь, будет с бесконечным редиректом.
Сайт выполнил переадресацию слишком много раз.
Я немного удивился ошибке, но после того, как пораскинул мозгами, понял, в чем ее причина. Помог мне в этом один из заголовков главной страницы сайта во время редиректа - x-redirect-by: WordPress.
Запрос приходит на внешний сервер по https, дальше он его перенаправляет на бэкенд по http, где работает wordpress. У него в настройках указано, что он живет по адресу с https и он на него редиректит сам. Запрос опять возвращается на proxy и так по кругу.
Я решил эту проблему следующим образом. На прокси добавил еще один заголовок.
location / { proxy_pass http://10.20.50.3:80; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto https; }
А в сам wordpress в файл wp-config.php, который лежит в корне сайта, добавил следующие строки.
if($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https'){ $_SERVER['HTTPS'] = 'on'; $_SERVER['SERVER_PORT'] = 443; }
После этого бесконечный редирект прекратился и сайт заработал. Я думал, что на этом все. Оказалось - нет. Возникла еще одна ошибка.
Извините, вам не разрешено просматривать эту страницу
При входе в админку получал вот такое сообщение.
Для того, чтобы исключить вероятность, что с сайтом что-то случилось, я перенес еще один сайт. У него увидел эту же ошибку. Тут я крепко призадумался и начал активно искать через поиск решение. Ошибка популярная и методов ее решения предлагают очень много. Мне не помогало ничего. Я перепробовал кучу всевозможных настроек, которые предлагали в различных статьях.
Начал искать в англоязычном интернете статьи на тему настройки такой же связки с внешним прокси на nginx и сайтом wordpress. В целом, там тоже люди сталкивались с различными ошибками и кто как их решал. Мне в итоге помогло вот что.
Указанные выше параметры из wp-config.php изначально я добавил в самый конец файла. После того, как я их перенес выше, сразу же после настроек подключения к базе, ошибка с подключением к админке: "Извините, вам не разрешено просматривать эту страницу" исчезла. Все заработало как и должно работать. Я их перенес вот сюда.
Надеюсь, кому-то помогут мои решения. Я как-то неожиданно долго провозился с этим вопросом, хотя обычно перенос сайта на wordpress это дело 10-15 минут:
- Делаешь дамп базы, кладешь его сразу же в корень сайта.
- На новом сервере по rsync через ssh забираешь все файлы сайта.
- Разворачиваешь БД из дампа, не забываешь удалить его.
Дальше остается только конфиги подготовить:
- Nginx
- Php-fpm
- Logrotate
Ну и на самой proxy:
- Nginx
- Certbot
- Logrotate
- Fail2ban
Перечислил, чтобы самому потом не забыть :)
Заключение
И еще совет, если будете проксировать запросы в wordpress, поставьте таймауты ожидания ответа от бэкенда в nginx побольше, так как во время обновления плагинов или самого движка wordpress бэкенд может очень долго не отвечать. Я имею ввиду вот эти значения.
proxy_connect_timeout 180; proxy_send_timeout 180; proxy_read_timeout 180;
Если они будут слишком маленькие, то обновление будет слетать с ошибками, потому разбираться с последствиями придется.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Благодарю, Помогли!
У меня эта же проблема возникла из за префикса БД "ЗАГЛАВНЫМИ БУКВАМИ"
При экспорте БД префикс таблиц перевелся автоматом в маленькие буквы, а в таблице usermeta остались несколько ЗАГЛАВНЫХ.
Получилось я как бы залогинился но не полностью )))
Исправил все на маленькие и вошел нормально.
Благодарю, помогли.
Спасибо тебе, добрый человек. Чуть кукушечкой не тронулся, и конфги по пять раз перепроверил, и пробовал поставить на http, а потом переключить на https. А самое главное, четкой инфы кроме твоей стать не нашел, чтоб без лишнего хлама. Спасибо ещё раз.
Спасибо!
Спасибо автору! Очень долго бился с этими ошибками
Мне помог перенос строк из конца файла в указанное место, после данных для подключения к базе.
Автору большое спасибо! Мне помогло исправить аналогичные ошибки
Спасибо большое! Ваш опыт пригодился!
Реально интересно. Напишите мануал по размещению сайтов wordpress за внешним проксирующим nginx плиз
В планы поставил статью, так что она точно будет. А вот когда - не знаю. Как со временем свободным будет получше. Пока нет возможности писать большие содержательные статьи.
Интересно, спасибо. )
Сам сталкивался с подобным, но до wp-config.php тогда так и не успел добраться.
Как вы и просили, пишу в комментарии о том, что мне интересно узнать полную схему размещения сайтов wordpress за внешним проксирующим nginx и зачем все это нужно.
Привет,
а я вот так фиксил
https://dimetrius.net/linux/web-servers/ssl-mezhdu-frontendom-i-bekendom-cherez-neskolko-proksi-serverov.html
особенность в том что это универсальное решение без правок кода скриптов.
Спасибо за ссылку. Это реально правильное решение. Я знал, что это можно сконфигурировать на сервере через настройки $fastcgi_https, но не знал как именно. А много времени тратить не хотелось. Эта настройка ключевая при конфигурации с https и проксировании запросов на бэкенды.
Не помогло это. По факту все равно приходится в разных сайтах по-разному решать этот вопрос. Я немного разобрался в предложенной схеме и не понял ее смысла. Можно было просто принудительно в параметрах fastcgi установить значение:
fastcgi_param HTTPS on;
и не городить огород с map. По факту сейчас все равно все сайты работают по https.