Nginx редирект если нет файла
По данным Datanyze, Nginx — это 32% всего рынка веб-серверов. Он используется на многих известных сайтах, таких как Github, Netflix, CloudFlare, Hulu, Airbnb, WordPress и многих других.
Прокачайте ваш проект, воспользовавшись скидками на VPS-хостинг в Hostinger! Большой выбор планов, как для учебных, так и для крупных коммерческих проектов.
Перенаправления в Nginx
В этом руководстве мы познакомим вас с двумя видами перенаправлений Nginx: постоянными и временными. Не забудьте установить Nginx (англ) на свой VPS.
Постоянный и Временный Nginx Redirect
Временные перенаправления полезны в том случае, если нам нужно временно изменить местоположение страницы с одного места на другое. Чтобы обозначить временное перенаправление страницы, используется код ответа 302 .
Временные перенаправления сообщают пользователям, что сайт временно не доступен, например, когда он закрыт на обслуживание. Ещё один пример временного редиректа, когда вы связываете страницу с неполной информацией с другим пунктом или главной страницей:
В свою очередь, постоянное перенаправление Nginx сообщает веб-браузеру, что он должен постоянно связывать старую страницу или домен с новым местоположением или доменом. Для обозначения постоянного перемещения страницы используется код ответа 301 . Такие перенаправления полезны, когда пользователь хочет изменить имя домена и больше не хочет, чтобы браузер обращался к нему.
Например, если вы хотите изменить домен вашего сайта или создать новую страницу, чтобы заменить старую:
Обратите внимание, что сначала вы должны получить доступ к вашему VPS через SSH. Если у вас возникли проблемы, ознакомьтесь с нашим руководством по PuTTY.
В Nginx большинство перенаправлений могут быть реализованы с помощью встроенной функции перезаписи. Перезапись является функцией по умолчанию, доступной в чистой установке Nginx. С её помощью можно создать оба вида перенаправлений Nginx – как постоянные, так и временные. Для самого простого редиректа вам понадобится минимум два параметра – старый URL и новый URL.
Перенаправление домена в Nginx
Для перенаправления одного домена на другой введите в терминале указанную ниже команду:
Nginx Redirect Определённых Сайтов
Переадресация с www на без www
Важно: это постоянный, или “301 редирект”.
Чтобы увидеть изменения, перезапустите веб-сервер Nginx, используя команду:
Выводы
Nginx – это один из самых мощных и простых в использовании веб-серверов, который позволяет создавать как временные, так и постоянные перенаправления.
Надеемся, что это руководство будет вам полезным. Увидимся в следующем!
Ольга уже около пяти лет работает менеджером в сфере IT. Написание технических заданий и инструкций — одна из её главных обязанностей. Её хобби — узнавать что-то новое и создавать интересные и полезные статьи о современных технологиях, веб-разработке, языках программирования и многом другом.
Хочу сегодня рассмотреть тему редиректов в Nginx. Я обычно настраиваю их в лоб. То есть нужен какой-то редирект, я его добавляю. На днях меня попросили СЕО специалисты переработать редиректы одного проекта и сделать так, чтобы для клиента был ровно один 301 редирект, который включает в себя сразу все необходимые преобразования url.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Пример двойного редиректа
А потом вас попросили добавить редирект всех урлов без слеша на тот же урл только со слешем на конце. Вы идете в секцию c listen 443 и добавляете редирект.
На выходе у вас 2 редиректа вместо одного, что плохо для СЕО. Надо по возможности все реализовать в одном. В данном случае напрашивается простое и очевидное решение:
Теперь все будет нормально, так как location со статикой указан в виде регулярного выражения. В случае попадания запроса в указанное правило, будет выполнен редирект без слеша. Все остальное попадет в следующий префиксный location /. То же самое можно сделать с помощью if и одного location, но c if работать будет медленнее. Там где можно обходиться без if, лучше его не использовать.
Пример с nginx rewrite
Встроенные редиректы WordPress
Все стандартные редиректы в nginx
Рассмотрю типовой пример, когда у нас одновременно присутствуют следующие редиректы:
Наша цель будет реализовать все преобразования url в одном месте и выдать клиенту только один 301-й редирект.
Получилось примерно так. Призываю не копировать бездумно конфиг, а проверить то, что я предлагаю. Хотя я сам внимательно проверил, как мог, но все равно не застрахован от ошибки. На мой взгляд здесь рассмотрены все основные моменты с редиректами. На выходе всегда один 301 редирект, какой бы запрос мы не сделали. При этом все реализовано средствами самого веб сервера, а значит, будет работать максимально быстро.
Корректный редирект с одного url на другой
Опять два 301-х редиректа. Переделываем на один, не забывая все возможные варианты написания.
Ну и так далее. Думаю, идея ясна. Следует следить за всеми редиректами и стараться всегда оставлять только один.
Заключение
Я прилично заморочился с темой редиректов в nginx. Раньше никогда не обращал на них пристального внимания. Да и у других не видел акцента на этом. В интернете полно готовых вариантов перенаправлений на все случаи жизни, но рассмотрены они в отдельности. А вот так комплексно взглянуть на полный конфиг со всеми нюансами не приходилось.
Материал полностью написан и протестирован мной от начала до конца, поэтому призываю не копировать слепо к себе, а проверить. Я могу где-то ошибаться, что в такой важной теме может быть чревато проблемами с индексацией и работой сайта. Так что внимательно все проверяйте, прежде чем внедрять у себя. Ну а замечания все, как обычно, жду в комментариях.
В завершении рекомендую мою статью про настройку nginx. Я там частично рассматриваю и эту тему. А вообще там рассказаны все основные моменты, на которые стоит обращать внимание при работе с nginx.
Рассматриваю на примере конфигурации веб-окружения BitrixVM, т.к. занимаюсь разработкой именно в данной среде, но правила одинаковые для любых систем, поэтому, это не принципиально.
Правила нужно прописывать в файле с описаниемм конфигурации конкретного хоста (для BitrixVM это
/etc/nginx/bx/site_avaliable/bx_ext_domain.conf - для сайта, работающего без ssl;
/etc/nginx/bx/site_avaliable/bx_ext_ssl_domain.conf - при работе по ssl);
Саму настройку на перенаправление в NGINX можно прописать двумя способами.
* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени). ** где флаги могут быть следующие:
Где коды могут использоваться любые, но чаще всего — 301, 302, 404.
Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В сети в примерах используется чаще всего второй вариант.
Или, если вам повезло также как и мне и конфигурационные файлы для ssl и без ssl - разные, то в файле для без ssl можно прописать прямой редирект:
редирект с www на без www
Добавляем слеши в конце
Убираем слеш в конце
Убираем index.php в конце адреса
Если для определенных разделов данный редирект нужно отключить, то в маску добавляем разделы исключения:
Чтобы сохранить параметры в адресной строке, нужно задать:
Редирект для конкретной страницы
Обычный редирект в htaccess имеет вид:
В nginx примет вид:
Также, редирект конкретного файла можно сделать так:
Чтобы удалить из адреса часть строки, можно сделать так:
Редирект с одного домена на другой
Редирект с каждой страницы одного домена на такой же URL адрес другого домена
Редирект домена и всех его поддоменов:
Избавляемся от задвоенных слешей в адресе
По умолчанию в nginx включено воспринимать задвоенные слеши, как один. Для начала нужно отключить данное поведение. Для этого в конфигурационном файле конкретного сайта пишем в начале секции server (после директивы server_name) отключение данного поведения:
Далее в блоке с редиректами прописываем:
Сложный анализ ЧПУ
Пример из сети по обработке api-запросов:
Пока не приходилось сталкиваться, но, может быть, кому-то будет полезным!
Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)
Для этого, в основном конфигурационном файле (для bitrixVM это /etc/nginx/bx/site_available/s1.conf) пишем:
или независимо от протокола:
Редирект на особенную страницу по 404-му статусу
Если страница не найдена - будет выдан 404-й статус и показана соответствующая страница. Но иногда, для случая, когда при отсутствии того или иного файла должен быть выполнен редирект куда-то, можно воспользоваться конструкцией:
По этой логике можно определять любые конструкции, которые вам нужны. Сначала сервер попробует выполнить файл, и, если он не будет найден, он переместится в часть @missing. А второй блок, с @missing, перенаправит на нужную страницу.
Использование вложенных if
Вложенные if в конфигурации nginx запрещены, поскольку это вовсе не языковая конструкция nginx, а обычная директива из модуля rewrite, использование которой в ее же собственном контексте if не предусмотрено. Использование списка условий, разделенных логическими операторами "и" и "или" тоже не предусмотрено. Обычно для эмуляции вложенных условий с использованием директивы if предлагают использовать регулярные выражения. Например, проверить, что имя, указаное в HTTP хедере HOST, соответствует значению localhost, а в URI присутствует аргумент "a" (в этом случае переменная $arg_a будет не пустой), можно так:
К сожалению, условие в директиве if имеет ограничения. По крайней мере, это не выражение, и оно не может быть составлено в виде цепочки выражений, разделенных логическими операторами. Кроме того, в случае сравнения чего-то с регулярным выражением, это что-то может быть только именем переменной, именно поэтому пришлось ввести новую переменную $cond:
В данном примере мы соединили через произвольно выбранный нами разделитель :: три переменных $host, $goodhost и $arg_a и присвоили это значение переменной $cond. А регулярное выражение, с которым мы сопоставляем это значение, проверяет, что его первая часть (до разделителя ::) и вторая часть (до второго разделителя ::) равны, а последняя часть (после второго разделителя) не пуста.
В полном виде конструкция проверки примет вид:
Описание структуры работы с вложенными if взято отсюда .
Сложное условие и проксирование запросов
Если нужно выполнить проксирование запросов с помозью директивы proxy_pass только при соблюдении нескольких условий, то можно воспользоваться следующей конструкцией:
Пояснения:
Условие RewriteCond обозначает совпадение с которым будет выполнено правило RewriteRule. При этом, используются символы:
. – Точка — это любой символ (но только один!).
^ — Эта метка означает начала строки.
$ — Эта метка означает конец строки.
\ — Эта экранирующий слэш, позволяет считать следующий за ним символ, обычным символом.
() – Этот символ обозначает группировку.
! – Метка отрицания.
+ — Этот символ повторяется от 1 до 65536 раз.
? — Этот символ повторяется 0 или 1 раз.
* — А этот символ повторяется от 0 до 65536 раз.
Флаги определяют дополнительные опции.
R — (redirect) — По умолчанию останавливает процесс преобразования, возвращает результат в браузер клиента, как редирект на данную страницу 302, MOVED TEMPORARY. Например флагу можно указать другой код результата, R=301 и он возвратит редирект клиенту с кодом 301 MOVED PERMANENTLY.
NC — (nocase) — Этот флаг отключает проверку регистра символов.
L — (last) — Флаг останавливает процесс преобразования, текущая ссылка считается окончательной.
Чтобы изменения вступили в силу - не забудьде произвести рестарт nginx. Но для начала - проверьте, что ваша конфигурация в порядке. Для этого выполните команду:
Если выдаст "OK" - делаем смело перезагрузку:
Первый вариант - для устаревших систем Linux или FreeBSD. Второй - для новых систем Linux
Если же показывает ошибку - разбираемся с ней.
Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.
Отличия между 301 и 302 редиректами:
В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.
301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и тоже. Таким образом результаты ранжирования необходимо сохранить для новой страницы.
302-о перенаправление просто говорит о том, что нужно перейти по другому адресу. Поисковый робот не сохраняет результат выдачи для новой страницы, индексируя его с нуля.
В данной статье буду собирать все редиректы в nginx которыми пользуюсь:
Если же Вы устанавливали nginx сами, то путь до директории с настройками для сайтов будет /etc/nginx/site-enabled/ваш_сайт.conf
Саму настройку на перенаправление в NGINX можно прописать двумя способами.
Где коды могут использоваться любые, но чаще всего — 301, 302, 404.
Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В сети в примерах используется чаще всего второй вариант.
Или, если вам повезло также как и мне и конфигурационные файлы для ssl и без ssl — разные, то в файле для без ssl можно прописать прямой редирект:
Редирект с www на без www
Добавляем слеши в конце
Убираем слеш в конце
Убираем index.php в конце адреса
Если для определенных разделов данный редирект нужно отключить, то в маску добавляем разделы исключения:
Чтобы сохранить параметры в адресной строке, нужно задать:
Редирект для конкретной страницы
Обычный редирект в htaccess имеет вид:
В nginx примет вид:
Также, редирект конкретного файла можно сделать так:
Чтобы удалить из адреса часть строки, можно сделать так:
Редирект с одного домена на другой
Редирект с каждой страницы одного домена на такой же URL адрес другого домена
Редирект домена и всех его поддоменов:
Сложный анализ ЧПУ
Пример из сети по обработке api-запросов:
Пока не приходилось сталкиваться, но, может быть, кому-то будет полезным!
Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)
Для этого, в основном конфигурационном файле пишем:
или независимо от протокола:
Редирект на особенную страницу по 404-му статусу
Если страница не найдена — будет выдан 404-й статус и показана соответствующая страница. Но иногда, для случая, когда при отсутствии того или иного файла должен быть выполнен редирект куда-то, можно воспользоваться конструкцией:
По этой логике можно определять любые конструкции, которые вам нужны. Сначала сервер попробует выполнить файл, и, если он не будет найден, он переместится в часть @missing. А второй блок, с @missing, перенаправит на нужную страницу.
Использование вложенных if
К сожалению, условие в директиве if имеет ограничения. По крайней мере, это не выражение, и оно не может быть составлено в виде цепочки выражений, разделенных логическими операторами. Кроме того, в случае сравнения чего-то с регулярным выражением, это что-то может быть только именем переменной, именно поэтому пришлось ввести новую переменную $cond:
В данном примере мы соединили через произвольно выбранный нами разделитель :: три переменных $host, $goodhost и $arg_a и присвоили это значение переменной $cond. А регулярное выражение, с которым мы сопоставляем это значение, проверяет, что его первая часть (до разделителя ::) и вторая часть (до второго разделителя ::) равны, а последняя часть (после второго разделителя) не пуста.
В полном виде конструкция проверки примет вид:
Сложное условие и проксирование запросов
Если нужно выполнить проксирование запросов с помощью директивы proxy_pass только при соблюдении нескольких условий, то можно воспользоваться следующей конструкцией:
Пояснения:
Условие RewriteCond обозначает совпадение с которым будет выполнено правило RewriteRule. При этом, используются символы:
. – Точка — это любой символ (но только один!).
^ — Эта метка означает начала строки.
$ — Эта метка означает конец строки.
\ — Эта экранирующий слэш, позволяет считать следующий за ним символ, обычным символом.
() – Этот символ обозначает группировку.
! – Метка отрицания.
+ — Этот символ повторяется от 1 до 65536 раз.
? — Этот символ повторяется 0 или 1 раз.
* — А этот символ повторяется от 0 до 65536 раз.
Флаги определяют дополнительные опции.
R — (redirect) — По умолчанию останавливает процесс преобразования, возвращает результат в браузер клиента, как редирект на данную страницу 302, MOVED TEMPORARY. Например флагу можно указать другой код результата, R=301 и он возвратит редирект клиенту с кодом 301 MOVED PERMANENTLY.
NC — (nocase) — Этот флаг отключает проверку регистра символов.
L — (last) — Флаг останавливает процесс преобразования, текущая ссылка считается окончательной.
Чтобы изменения вступили в силу — не забудьде произвести рестарт nginx. Но для начала — проверьте, что ваша конфигурация в порядке. Для этого выполните команду:
Если выдаст «OK» — делаем смело перезагрузку:
Первый вариант — для устаревших систем Linux или FreeBSD. Второй — для новых систем Linux
Если же показывает ошибку — разбираемся с ней.
Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.
Отличия между 301 и 302 редиректами:
В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.
301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и тоже. Таким образом результаты ранжирования необходимо сохранить для новой страницы.
302-о перенаправление просто говорит о том, что нужно перейти по другому адресу. Поисковый робот не сохраняет результат выдачи для новой страницы, индексируя его с нуля.
P.S. Не забывайте, что внесение любых изменений в конфигурации сервера могут привести к тому, что самостоятельно вы можете и не восстановить. Поэтому не забывайте делать бекапы!
Если есть вопросы, то пишем в комментариях.
Также можете вступить в Телеграм канал, ВК или подписаться на Twitter. Ссылки в шапки страницы.
Заранее всем спасибо.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Читайте также: