301 редиректы с примерами

Редиректы

Редирект на .html

Пример, редирект с c site.ru/blog на site.ru/blog.html.

RewriteCond %{REQUEST_URI} (.*/[^/.]+)($|\?)
RewriteRule .* %1.html 
RewriteRule ^(.*)/$ /$1.html 

Редирект на страницу без слеша в конце адреса

Пример, редирект с c site.ru/blog/ на site.ru/blog.

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/$ /$1 

Редирект на страницу со слешем в конце адреса

RewriteCond %{REQUEST_URI} (.*/[^/.]+)($|\?)
RewriteRule .* %1/ 

Редирект на страницу без index.php в адресе

RewriteRule ^index.php/(.*)$ http://mysite.ru/$1 

Редирект на страницу без index.php в конце адреса

RewriteCond %{THE_REQUEST} ^{3,9}\ /index\.php\ HTTP/
RewriteRule ^index\.php$ http://site.ru/ 

Редирект с www на без www

RewriteCond %{HTTP_HOST} ^www\.site\.ru$ 
RewriteRule ^(.*)$ http://site.ru/$1 

Редирект без www на www

RewriteCond %{HTTP_HOST} ^site.ru$ 
RewriteRule ^(.*)$ http://www.site.ru/$1 

Склейка доменов

Пример, у вас несколько доменов, но посетитель должен переправляться на один.

RewriteCond %{HTTP_HOST} !^site.ru$
RewriteRule ^(.*) http://site.ru/$1 

Редирект со старых статических url на новые

Пример редирект со страницы http://site.com.ru/id=21.

RewriteCond %{QUERY_STRING} ^id=21$
RewriteRule ^/page.php$ http://site.ru/news.html 

Защита от хотлинка

Если вы хотите запретить вставку изображений с сайта по прямой ссылке.

Вместо site.ru укажите адрес сайта, jpg|jpeg|png|gif — расширение запрещенных изображений, images.jpg – изображение которое будет показываться, если картинка находится не в корне сайта, укажите полный путь.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?site.ru 
RewriteRule \.(jpg|jpeg|png|gif)$ images.jpg 

Защита от брутофорса

Разрешаем доступ к директории administrator только по протоколу HTTP, что отсеет некоторых ботов. Для каждой CMS нужно указать свой адрес, например wp-login, wp-admin и так далее.

RewriteCond %{REQUEST_URI} ^/administrator\.php$
RewriteCond %{THE_REQUEST} HTTP/1\.0
RewriteRule ^(.*)$ - 

Бытует легенда, что происхождения названия сервера Апач происходит не от названия индейского племени. Когда сервер был еще в самом начале пути, группа энтузиастов небольшие дополнения к коду, патчи (англ – patch), и «a patchy server» превратилось в Апач, а знаменитое перо на логотипе появилось позже.

В материале перечислены наиболее часто используемые примеры, а большинство возможностей даже не упомянуто, как модуль mod_rewrite, предоставляющий множество возможностей.

Статья писалась эпизодическими «набегами», так что если увидите ошибку, поправьте.

Мой аккаунт на Marketplace — https://timeweb.com/ru/community/marketplace/bashkov-vladislav, обращайтесь

Конфигурация Apache

Перед тем, как сделать редирект с https на http, добавьте следующее правило перенаправления в файл конфигурации Apache (если у вас есть доступ к нему), либо в файл .htaccess, расположенный в корневом каталоге вашего сайта:

RewriteEngine On
RewriteCond %{HTTPS} off 
RewriteCond %{HTTP_HOST} ^www. 
RewriteCond %{HTTP_HOST} ^(?:www.)?(.+)$ 
RewriteRule ^ https://%1%{REQUEST_URI} 

Если вместо example.com вы хотите использовать по умолчанию URL www.example.com, то просто измените третью и пятую строки:

RewriteEngine On
RewriteCond %{HTTPS} off 
RewriteCond %{HTTP_HOST} !^www. 
RewriteCond %{HTTP_HOST} ^(?:www.)?(.+)$ 
RewriteRule ^ https://www.%1%{REQUEST_URI} 

Как перейти на HTTPS

Выбор времени перехода

Для начала нужно выбрать время перехода. Переход на новый протокол может обрушить позиции сайта в выдаче на некоторое время, так что лучше не переводить сайт на HTTPS в период, когда им активнее всего пользуются. Пусть это будет, когда у сайта «не сезон», и он пользуется наименьшим спросом.

Подготовка сайта к переходу

Если сайт предварительно не подготовить, могут возникнуть технические проблемы или время всей операции затянется. Как подготовить сайт к переходу на HTTPS:

1. Если на внутренних ссылках есть указание на протокол, уберите его. Это нужно, чтобы не возникло ошибок при индексации. К примеру, если раньше ссылка выглядела как «http://site.ru/text/», приведите ее в форму «//site.ru/text/».
2. То же самое нужно сделать со внешними ссылками, привести их url в относительный вид. Иначе могут появиться сбои при функционировании сайта.
3. Адреса медиаконтента тоже нужно перевести в относительные ссылки. Если объекты базируются на вашем сайте, то этого достаточно. Если некоторые медиа подгружаются со сторонних ресурсов, то проверьте, поддерживают ли они HTTPS. Не поддерживают — заменяйте, они не будут работать на вашем сайте после смены протокола. Это можно сделать быстрее, если исправить протокол на относительный сразу в базе данных для всех ссылок.
4. Ссылки в rel=»canonical» и rel=»alternate» также замените на относительные.
5. Проверьте, что сторонние сервисы, которые вы используете на сайте, поддерживают HTTPS. Популярные обычно поддерживают этот протокол, к примеру Яндекс.Метрика, Директ, Google Analytics, но другие стоит проверить.

Заложите на подготовку срок с запасом, потому что на эти преобразования может понадобиться долгое время, особенно если у вас большой сайт.

Переадресация с http на https

При переезде сайта с http на https (установка SSL-сертификата) потребуется код, который не требует дополнительных модификаций:

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP:X-HTTPS} !1

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1

Второй метод осуществляет перенос с http://domain.ru на https://domain.ru:

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP:X-HTTPS} !1

RewriteCond %{HTTP_HOST} ^domain\.ru$

RewriteRule ^(.*)$ https://domain.ru/$1

Третий способ выполняет аналогичную функцию, но отключает перенаправление для robots.txt:

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP:X-HTTPS} !1

RewriteCond %{REQUEST_URI} !robots.txt

RewriteRule ^(.*)$ https://domain.ru/$1

В 4-й версии конечным пунктом для пользователя станет https://www.domain.ru:

RewriteEngine On

RewriteBase /

RewriteCond %{HTTP:X-HTTPS} !1

RewriteCond %{HTTP_HOST} ^domain\.ru$

RewriteRule ^(.*)$ https://www.domain.ru/$1

Позволяет сделать форвардинг с http://www.poddomen.domain.ru на https://poddomen.domain.ru:

Options +FollowSymLinks

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.poddomen\.domain\.ru$

RewriteRule ^(.*)$ https://poddomen.domain.ru/$1

RewriteBase /

RewriteCond %{HTTP:X-HTTPS} !1

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1

Последняя версия, дающая возможность сделать связь между http://poddomen.domain.ru на https://www.poddomen.domain.ru:

Options +FollowSymLinks

RewriteEngine On

RewriteCond %{HTTP_HOST} ^poddomen\.domain\.ru$

RewriteRule ^(.*)$ https://www.poddomain.domain.ru/$1

RewriteBase /

RewriteCond %{HTTP:X-HTTPS} !1

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1

Яндекс

Следующий шаг – известить о тех изменениях, которые вы произвели, поискового бота Яндекса.

1. Новый сайт необходимо добавить в форму «Переобход страниц» (addurl): http://webmaster.yandex.ru/addurl.xml

Либо добавить сайт отдельно в список своих сайтов в Яндекс.Вебмастере: https://webmaster.yandex.ru/sites/add/

2. И рассказать о переезде своего сайта в Яндекс.Вебмастере в разделе «Настройка индексирования» -> «Переезд сайта»: https://webmaster.yandex.ru/site/index-setup/mirrors/

Далее нужно понимать, что на индексирование и процесс склейки зеркал потребуется время, которое может варьироваться от одного до трех месяцев. По сути, вы должны заметить, что HTTP-сайт пропал из выдачи, в то время как сайт, работающий по протоколу HTTPS, наоборот, попадет в нее. При этом в это время оба сайта должны работать параллельно.

Покупка и установка SSL-сертификата

Для работы SSL-протокола необходим SSL-сертификат, для этого нужно его купить и установить.

Какой SSL-сертификат выбрать

Обычно они покупаются у поставщиков, цена установки SSL-сертификата может быть разной, но есть бесплатные варианты. Бесплатно сертификат найти сложно и небезопасно, тем более обычно они действуют ограниченный период. Советуем выбрать поставщика и приобрести сертификат, так надежнее. Бывает, что их дарят при регистрации домена.

Переходим на страницу заказа SSL-сертификатов и выбираем нужный тип:

1.DV-сертификат (Domain Validated) — самый простой, подходит для физических лиц и юридических лиц, выдается на один домен одному владельцу. Сертификат защищает информацию, но не гарантирует, что владельцу можно доверять.

Для установки потребуется проверка принадлежности домена. Такой сертификат можно установить на личный блог, небольшой сайт-визитку.

Визуально у сайта появится замочек в адресной строке.

Сайт с сертификатом безопасности

2. OV-сертификат (Organization Validation) — сертификат для коммерческих и некоммерческих организаций, юридических лиц. Для выдачи нужна проверка существования юрлица или ИП и проверка принадлежности домена.

Этот сертификат подходит порталам, магазинам, компаниям, предоставляющим услуги..

Визуально такая форма будет выглядеть как DV-сертификат.

Сайт с сертификатом безопасности

2.EV-сертификат (Extended Validation) — домен с расширенной проверкой, подходит только для юридических лиц. Потребуется проверка принадлежности домена и другие данные о юрлице: свидетельство о гос регистрации, зарегистрированное название и другие данные.

Этот сертификат обычно заказывают банки и крупные организации.

Визуальное отличие в том, что кроме замочка в адресной строке появится зеленое поле с названием фирмы. Такая форма выглядит надежнее.

Сайт с сертификатом и дополнительной формой

Дополнительно сертификаты могут иметь опции: Wildcard, то есть поддержку поддоменов сайта, SAN — поддерживать несколько доменов на одном сервере, IDN (Internationalized Domain Names) — поддержку кириллических доменов.

Первый вариант сертификата бюджетнее и его проще получить. После того, как мы подобрали нужный вид сертификата, заказываем его, а после выпуска скачиваем готовый файл. При заказе при генерации CSR-запроса вам выдадут файл ключа, сохраните его, он понадобится для установки.

После покупки нужно установить SSL на хостинг, если вы покупали сертификат у своего хостера, это будет чуть проще.

Сертификат обычно покупается как домен или хостинг: на год-два, а потом продлевается.

Как установить SSL-сертификат

После покупки у вас должен быть файл сертификата, файл ключа и два файла цепочки сертификатов.

1.Войдите в личный кабинет хостинга вашего сайта.

2.Найдите раздел SSL.

3. Загрузите эти файлы в соответствующие поля.

На сайтах, где можно купить файл, обычно есть подробная инструкция как установить SSL-сертификат.

Загрузка сертификата на reg.ru

4. Проверьте, доступен ли сайт по по HTTP-протоколу и по HTTPS. Он должен быть доступен по обоим.

5. Проверьте корректность установки сертификата на сайте: страницы сайта корректно открываются по URL с учётом нового протокола, а конфигурация SSL корректно установлена. Проверить правильность конфигурации SSL-сертификата можно на сервисе
PR-CY: вставьте адрес сайта в строку и нажмите проверку. Если установка прошла корректно, появится примерно это:

Результаты проверки SSL

Проверить настройку также можно с помощью
Ssllabs, сервис проведет анализ конфигурации SSL. Вводите адрес сайта и нажимаете проверку, если все в порядке, появится такой результат:

Успешный результат проверки

Если сервисы покажут некорректную настройку, они определят проблемы и дадут рекомендации по их устранению.

Рекомендуем также проверить отображение сайта через разные браузеры, а также на мобильных устройствах на разных операционных системах.

SSL-сертификат установлен, но выдыхать рано – нужно провести еще некоторые манипуляции в коде сайта и его настройках.

HTTPS-согласования и редиректы

Одна из самых распространенных ошибок при настройке HTTPS-редиректов — это предположение, что вам не нужен сертификат SSL при переадресации клиента с одного домена на другой.

Если посмотреть на поток запросов, то видно, что обмен сертификатами SSL и согласование шифрования выполняются на первом этапе

Обратите внимание, что на этом этапе сервер ничего не знает, какая страница нужна клиенту: клиент и сервер решают, как взаимодействовать друг с другом

После завершения первого этапа, когда клиент и сервер нашли общий язык (протокол шифрования), они могут начать взаимодействовать друг с другом, используя зашифрованное соединение. В этот момент клиент отправляет HTTP-запрос на сервер, а сервер отправляет HTTP-ответ, содержащий редирект.

Не забывайте, что редирект — это HTTP-ответ с кодом 301 (иногда 302 или 307):

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Mon, 01 Aug 2016 14:41:25 GMT
Location: https://dnsimple.com/

Перед тем, как сделать редирект с HTTPS на HTTP, помните, что, если нужно создать редирект для всего домена, то необходим валидный сертификат SSL для перенаправляемого домена. Для согласования шифрования требуется сертификат SSL, и происходит оно до того, как запрос был обработан, а ответ о редиректе возвращен клиенту.

Если бы все происходило иначе, то редирект бы обрабатывался перед проверкой сертификата SSL. Тогда клиент и сервер были бы вынуждены общаться с помощью обычного HTTP-соединения, которое не шифруется.

Если нужно перенаправить клиента с любой страницы домена https://www.example.com на другую, необходим установленный на сервере валидный сертификат SSL, который распространяется на весь домен www.example.com.

Например, чтобы перенаправить клиента с https://www.example.com на https://example.com, необходимо иметь сертификат, который распространяется на оба или два отдельных сертификата (для каждого хоста соответственно).

HTTPS – что это

Протоколы передачи данных используются, когда эти самые данные передаются через интернет. От сайта к пользователю, от пользователя к сайту, от сервера к другому серверу и т. д. Различные протоколы используются повсеместно, и каждый из них обладает своими особенностями, которые могут напрямую влиять на качество передаваемых данных.

HTTP и HTTPS всегда можно видеть в начале ссылок. Сама модель ссылки подразумевает, что в самом начале всегда указывается протокол передачи данных. Если вы введете http, сайт откроется по этому протоколу. Если https, браузер попытается открыть его по защищенному каналу, однако это не всегда сработает.

Только в тех случаях, когда у домена есть специальный SSL-сертификат. Об этом я расскажу чуть позже, сейчас же мы чуть подробнее остановимся на понятии защищенного соединения.

Обычное HTTP-соединение очень уязвимо для различного рода перехватов, хакерских атак, подмены и кражи данных. То есть если вы будете работать с сайтом, используя этот вид протокола, то есть вероятность, что при обмене данными вы получите их недостоверную копию. Также у вас есть риск потерять ту информацию, которую вы передавали на сайт. В процессе обмена данными может вмешаться третье лицо и получить копию той информации, которую вы передали сайту.

Говоря простыми словами, если вы введете свой пароль, данные от банковской карты, личную информацию или что-то еще на сайте, который работает на HTTP-протоколе, то все это может быть похищено третьими лицами. С помощью определенных манипуляций они смогут вмешаться в процесс обмена информацией между вами и веб-ресурсами, после чего сделать все, что им захочется.

Речь идет не только о простом похищении информации. В некоторых случаях хакерские атаки могут наносить куда больший ущерб. Например, хакеры могут заразить вирусами ваши устройства и вывести их из строя. То же касается серверов и хранилищ личной информации пользователей.

Чтобы вам было понятнее, я приведу простой пример. Представьте, что есть некий банк, сайты и серверы которого работают на простом HTTP-протоколе без использования защиты, антивирусного ПО или брандмауэра. Такой банк сразу попадает в поле зрения злоумышленников, и это значит, что есть риск взлома и потери всех средств на счетах.

На этих счетах хранятся деньги не только банка, но и простых клиентов, которые обратились в эту организацию по самым разным причинам. Кто-то хотел положить свой капитал под процент, другие просто взяли кредит и сейчас выплачивают его, третьи пользуются исключительно дебетовой картой и расплачиваются ей в магазинах.

В один момент злоумышленники взламывают банк, и все эти люди в одночасье теряют все средства. Банк не сможет выплатить им деньги, потому что у него самого их не осталось.

То есть одна простая уязвимость может привести к самой настоящей катастрофе. Даже такая мелочь, как протокол передачи данных, может влиять на очень многие вещи. То же касается и других сфер. Простой HTTP-протокол подвергает риску веб-ресурсы, которые его используют. Защищенный вариант помогает избежать всех этих проблем.

Что такое редирект и когда он нужен

Неактуальный сайт или страницу программисты называют донором, а ту, на которую перенаправляют, — акцептором. В нашем случае http://nic.ru/ — сайт-донор, а https://nic.ru/ — сайт-акцептор.

В каких случаях нужен редирект

• Для адаптации. Самый популярный редирект — перенаправление пользователя с десктопной версии сайта на мобильную.
• При ренейминге. В случаях, когда вы изменили название бренда и перешли на сайт с новым доменным именем.
• При переходе на безопасный протокол соединения. Чтобы обезопасить себя и своих клиентов, меняете протокол http на https.
• Для перенаправления с неактуальных страниц/сайтов. Например, товара больше нет в продаже или вы больше не оказываете какую-то услугу и хотите перенаправить пользователя на страницу с похожим товаром или услугой.
• При сайтах или страницах-дублях. Схожий контент на нескольких ресурсах ухудшает ранжирование, а если сайты или страницы идентичны, поисковые системы вовсе исключат эти страницы из поиска. Чтобы не создавать дубли и не рисковать ранжированием, настраивают постоянный или временный редирект.
• При частых запросах с www, если ваш сайт без www. На вас могут сослаться и так, и так, но для поисковых систем это разные сайты, поэтому настраиваете редирект на один из вариантов.
• При переходе на новый движок сайта. У каждой CMS свои правила генерации URL. Если адрес не будет совпадать со старым, без редиректа не обойтись — иначе клиенты не смогут вас найти. 

Это не все возможные поводы для редиректа. Они возникают в зависимости от того, какие проблемы нужно решить перенаправлением. 

Какие бывают редиректы

Есть четыре основных вида редиректа — 301, 302, 303, 307. Поисковые системы сами определяют его по коду состояния http. 

301 — постоянный редирект

Он означает, что ресурс навсегда перемещён на новый адрес. Сайт-донор пропадает из поиска, авторитет и показатели посещаемости передаются сайту-акцептору, который и будет индексироваться. 

302 — временный редирект со статусом «Найдено»

Поисковые системы расценивают страницу как временно несуществующую и перенаправляют пользователя на нужную. Все настройки и показатели останутся по старому адресу, индексироваться новый сайт тоже не будет. Такое перенаправление пригодится, например, когда нужно будет обновить сайт.

303 и 307 — аналоги 302 редиректа

303 редирект обозначает «смотрите другой ресурс», его применяют, когда вы не перенесли контент на другой адрес, но у вас есть подходящий под перенаправление другой сайт или страница. Для этого редиректа браузер использует метод GET.

Статус 307 редиректа — временное перенаправление. То есть запрашиваемая страница в данный момент находится по другому адресу. В отличие от 302 изначальная версия ресурса сохранит свои позиции.

Вам не обязательно запоминать, какой редирект что обозначает. Эти цифры при настройке вам не пригодятся. Достаточно понимать, какое решение подойдёт именно в вашей ситуации — временное или постоянное — и написать код, подходящий под нужный редирект. 

13 популярных ошибок при переходе сайта на https

Пишу самые популярные моменты, которые знаю из своего опыта или опыта коллег:

1. Сделать 302 редирект вместо 301 для склейки версий http с https;
2. Сделать редирект всех внутренних страниц на главную;
3. Допустить цикличные редиректы;
4. Забыл, что твой сайт без www, но склеить с https://www.site.ru;
5. Забыл прописать новый путь для sitemap.xml;
6. Пропустил этап с заменой абсолютных ссылок;
7. Не изменил урлы в скриптах и медиа-контенте;
8. В карте сайта указаны урлы на версию с http;
9. Описался при наборе домена при получении сертификата;
10. Может сломаться 1С, если забыли обновить данные;
11. Сайт интегрирован с различными API и вы забыли изменить адреса;
12. Косяки с rel=”canonical” на старые страницы;
13. Не очистил кэш и начал сам себе выдумывать проблемы.

А с какими косяками вы сталкивались?

HTTPS и редиректы

Рассмотрим пример. Допустим, что у нас есть сайт dnsimple.com. Его канонический URL-адрес — https://dnsimple.com. Тем не менее, существует четыре различных способа, с помощью которых можно подключиться к сайту, и нужно обеспечить, чтобы при любом из них пользователь перенаправлялся на https://dnsimple.com:

Исходный способ	Тип
http://dnsimple.com	HTTP + no-www
https://dnsimple.com	HTTPS + no-www
http://www.dnsimple.com	HTTP + www
https://www.dnsimple.com	HTTPS + www

Настройка htaccess редиректов HTTP на HTTPS часто является причиной путаницы. Не всегда понятно, как правильно обрабатывать через HTTPS редиректы с WWW на не-WWW (или наоборот), и почему для этого нужен сертификат SSL / TLS. Чтобы правильно настроить эти перенаправления, необходимо понять основные принципы обработки запросов HTTPS.

Далее мы рассмотрим, в каком порядке устанавливается соединение по протоколу HTTPS, как происходит обработка HTTP-запросов и настройка редиректов с поддержкой HTTPS.

3.Другие примеры с htaccess

3.1. Запретить IP-адрес и браузер

Запретим открывать сайт для пользователя с браузера IE с IP-адресом 172.111.222.55

RewriteCond %{HTTP_USER_AGENT} MSIE
RewriteCond %{REMOTE_ADDR} ^172\.111\.222\.55$
RewriteRule ^.*$ - 

Запретим для всех файл disable_file.html:

<Files disable_file.html>
deny from all
</Files>

3.3. Разрешить доступ с одного ip

Доступ будет разрешен только с одного ip-адреса 172.111.222.55

order deny,allow
deny from all
allow from 172.111.222.55

3.4. Запретить доступ с разных ip

Запретить доступ к сайту с нескольких ip-адреса 172.112.222.55, 172.113.222.55, 172.114.*.*

<Limit GET POST PUT>
order deny,allow
deny from all
deny from 172.112.222.55
deny from 172.113.222.55
deny 172.114.*.*
</LIMIT>

3.5. Редирект в URL с больших символов на маленькие

Все большие буквы в адресе URL будут переведены на маленькие.

RewriteRule  - 
RewriteRule ! - 

RewriteRule ^(*)A(.*)$ $1a$2
RewriteRule ^(*)B(.*)$ $1b$2
RewriteRule ^(*)C(.*)$ $1c$2
RewriteRule ^(*)D(.*)$ $1d$2
RewriteRule ^(*)E(.*)$ $1e$2
RewriteRule ^(*)F(.*)$ $1f$2
RewriteRule ^(*)G(.*)$ $1g$2
RewriteRule ^(*)H(.*)$ $1h$2
RewriteRule ^(*)I(.*)$ $1i$2
RewriteRule ^(*)J(.*)$ $1j$2
RewriteRule ^(*)K(.*)$ $1k$2
RewriteRule ^(*)L(.*)$ $1l$2
RewriteRule ^(*)M(.*)$ $1m$2
RewriteRule ^(*)N(.*)$ $1n$2
RewriteRule ^(*)O(.*)$ $1o$2
RewriteRule ^(*)P(.*)$ $1p$2
RewriteRule ^(*)Q(.*)$ $1q$2
RewriteRule ^(*)R(.*)$ $1r$2
RewriteRule ^(*)S(.*)$ $1s$2
RewriteRule ^(*)T(.*)$ $1t$2
RewriteRule ^(*)U(.*)$ $1u$2
RewriteRule ^(*)V(.*)$ $1v$2
RewriteRule ^(*)W(.*)$ $1w$2
RewriteRule ^(*)X(.*)$ $1x$2
RewriteRule ^(*)Y(.*)$ $1y$2
RewriteRule ^(*)Z(.*)$ $1z$2

RewriteRule  - 

RewriteCond %{ENV:HASCAPS} TRUE
RewriteRule ^/?(.*) /$1 

Перенаправить HTTP на HTTPS для каждого сайта

Обычно, когда сертификат SSL установлен в домене, у вас будет два серверных блока для этого домена. Первый для HTTP-версии сайта на порту 80, а второй для версии HTTPS на порту 443.

Чтобы перенаправить отдельный веб-сайт на HTTPS, откройте файл конфигурации домена и внесите следующие изменения:

Давайте разберем код построчно:

• — серверный блок будет прослушивать входящие соединения на порту 80 для указанного домена.
• — указывает доменные имена серверного блока. Убедитесь, что вы заменили его на свое доменное имя.
• — Перенаправить трафик на HTTPS-версию сайта. Переменная — это полный исходный URI запроса, включая аргументы.

Обычно вы также можете перенаправить HTTPS-версию сайта с www на не-www или наоборот. Рекомендуемый способ выполнить перенаправление — создать отдельный серверный блок для версий с www и без www.

Например, чтобы перенаправить HTTPS-запросы www на не-www, вы должны использовать следующую конфигурацию:

Каждый раз, когда вы вносите изменения в файлы конфигурации, вам необходимо перезапустить или перезагрузить службу Nginx, чтобы изменения вступили в силу: