Как сделать редирект url-адреса

Содержание:

Как сделать переадресацию 301
Обеспечиваем безопасность сайта
Что такое RivaTuner Statistics Server? Как установить, настроить и пользоваться программой?
Общие правила работы с .htaccess
Один (а не два последовательных!) 301 редирект на без www и с слешем на конце адреса страницы
Другие настройки (CGI, Python, Node.js)
Пример двойного редиректа
Как настроить 301 редирект
Частные случаи
Настраиваем редиректы для SEO
Способ 2. htaccess-редирект
Оптимизируем работу сайта
- 14. Сжимаем компоненты сайта при помощи mod_gzip или mod_deflate
- 15. Усиливаем кэширование
Проксирование

Как сделать переадресацию 301

Существует много способов сделать переадресацию 301, но самый распространенный метод — отредактировать файл .htaccess вашего сайта.

Вы найдете его в корневой папке вашего сайта:

Не видите файл? Это означает одно из двух:

У вас нет файла .htaccess. Создайте его с помощью Блокнота (Notepad в Windows) или TextEdit (Mac). Просто создайте новый документ и сохраните его с расширением .htaccess. Обязательно удалите стандартное расширение файла .txt.
Ваш сайт работает не на веб-сервере Apache. Это скорее технический аспект, но существуют разные типы веб-серверов. Apache, Windows/IIS и Nginx являются наиболее распространенными. Только серверы Apache используют файлы .htaccess. Чтобы проверить, работает ли ваш сайт на Apache, используйте этот инструмент. Убедитесь, что в разделе «История хостинга» (Hosting History), в колонке «Веб-сервер» (Web server) указано «Apache».

Вот некоторые фрагменты кода для добавления распространенных типов переадресаций 301 с помощью файла .htaccess:

ВАЖНО. Эти инструкции предназначены исключительно для веб-серверов Apache. Здесь можно почитать, что делать, если ваш сайт работает на Nginx, а здесь — если ваш сайт работает на Windows/IIS

Перенаправление старой страницы на новую

 Redirect 301 /old-page.html /new-page.html

Используете WordPress? Можно избавиться от необходимости самостоятельно редактировать файл .htaccess, если воспользоваться бесплатным плагином Redirection.

Добавить 301 редирект станет намного проще:

Перенаправление старого домена на новый

 RewriteEngine on
RewriteCond %{HTTP_HOST} ^oldsite.com 
RewriteCond %{HTTP_HOST} ^www.oldsite.com 
RewriteRule ^(.*)$ https://newsite.com/$1

Примечание. Существует несколько способов это сделать. Я ни в коем случае не эксперт в том, что касается серверов Apache и файлов .htaccess. Этот код у меня всегда срабатывал. Но вам следует обязательно протестировать его перед внедрением на своем сайте.

ВАЖНО! Если уже есть в вашем файле .htaccess, не повторяйте его. Просто скопируйте остальную часть кода

Это можно сделать и в Cpanel, если так удобнее.

Перенаправление всего домена с версии без www на версию с www (и наоборот)

Вот вариант для перенаправления с версии без www на версию с www:

 RewriteEngine on
RewriteCond %{HTTP_HOST} ^example.com 
RewriteRule ^(.*)$ http://www.example.com/$1

Вот вариант для перенаправления с версии с www на версию без www:

 RewriteEngine on
RewriteCond %{HTTP_HOST} ^www.example.com 
RewriteRule ^(.*)$ http://example.com/$1

ВАЖНО! Расположение и порядок кода в вашем файле .htaccess также имеет значение. Вы можете столкнуться с нежелательными последствиями, если несколько команд размещены в «неправильном» порядке (например, в случае цепочек переадресаций и т. д.)

Если вы планируете использовать много 301 редиректов в своем файле .htaccess, то вам стоит внимательно все проверить.

Перенаправление всего домена с HTTP на HTTPS

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}

ВАЖНО! Чтобы все правильно работало, на сайте должен быть установлен сертификат SSL. В противном случае вы получите предупреждающее сообщение «Соединение не защищено»

Перенаправление всего домена с версии без www на версию с www и с HTTP на HTTPS

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www. 
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} 
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}

Обеспечиваем безопасность сайта

Настраиваем редирект с http на https

Файл .htaccess предоставляет большие возможности для защиты сайта от вредоносных скриптов, кражи контента, DOS-атак. Также можно защитить доступ к определенным файлам и разделам.

5. Запрещаем загрузку картинок с вашего сайта

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

Осадите воришек при помощи этого кода:

Заменяете «mysite.com» на адрес вашего сайта и создаете изображение с любым сообщением о том, что красть чужие картинки нехорошо, по адресу . Это изображение и будет показано на стороннем ресурсе.

6. Запрещаем доступ

Целым группам нежелательных гостей с определенных IP-адресов, подсетей, а также вредоносным ботам можно запретить доступ на ваш ресурс при помощи следующих директив в .htaccess.

Для нежелательных User Agents (ботов)

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

Частный случай такого запрета — запрет для поисковых роботов. Если вас почему-то не устраивает правило в robots.txt, можно запретить доступ, например, роботу Google при помощи таких директив:

Для подсети

Вписываем маску сети в строку после «deny from».

Спамные IP-адреса можно вычислить в логах сервера или с помощью сервисов статистики. В административной панели WordPress отображаются IP-адреса комментаторов:

К определенному файлу

Вписываем название файла вместо «myfile.html» в примере. Пользователю будет показана ошибка 403 — «доступ запрещен».

Не лишним будет ограничить доступ к самому файлу .htaccess из соображений безопасности, а также рекомендуем после настройки всех правил поставить на файл права доступа 444.

Для сайтов на WordPress важно ограничить доступ к файлу wp-config.php, т.к. в нем содержится информация о базе данных:

Для пользователей, пришедших с определенного сайта

Вы можете заблокировать посетителей с нежелательных ресурсов (например, со взрослым или шокирующим контентом).

7. Защищаем доступ к определенному файлу или папке

Для начала создайте файл .htpasswd, пропишите в нем логины и пароли в формате user:password и разместите в корне сайта. В целях безопасности пароли лучше зашифровать. Это можно сделать при помощи специальных сервисов генерации записей, например, такого. Следующим шагом добавьте директории или файлы в .htaccess:

Защита паролем папки

Вместо «/pub/home/.htpasswd» укажите путь до файла .htpasswd от корня сервера. Рекомендуем проверить доступ после установки кода.

8. Запрещаем выполнение вредоносных скриптов

Следующая группа директив защищает сайт от так называемых «скриптовых инъекций» — инструмента хакерских атак:

Все попытки причинить вред вашему ресурсу будут перенаправлены на страницу ошибки 403 «доступ запрещен».

9. Защищаем сайт от DOS-атак

Один из способов защиты — ограничить максимально допустимый размер запроса (ограничение отсутствует по умолчанию).

Для этого прописываем в .htaccess размер загружаемых файлов в байтах:

В примере указан размер 10 Мбайт. Если вы хотите запретить загрузку файлов, пропишите число меньше 1 Мбайт (1048576 байт).

Также можно изучить возможности директив LimitRequestFields, LimitRequestFieldSize и LimitRequestLine в официальной документации.

Что такое RivaTuner Statistics Server? Как установить, настроить и пользоваться программой?

Обзор лучших сервисов для создания временного email-адреса

Общие правила работы с .htaccess

Всегда делайте резервную копию файла перед внесением изменений, чтобы оперативно «откатить» их.
Вносите изменения пошагово, добавляйте по одному правилу и оценивайте, как оно сработало.
Если размещаете несколько файлов .htaccess в разных каталогах, прописывайте в дочерних только новые директивы, которые актуальны для конкретного каталога, остальные унаследуются от родительского каталога или файла в корневой папке.
Очищайте кэш браузера: Ctrl + F5, в Safari: Ctrl + R, в Mac OS: Cmd + R.
Если возникает ошибка 500, проверьте синтаксис правила (нет ли опечатки). Можно воспользоваться сервисами проверки файла .htaccess онлайн, например таким. Если ошибок не найдено, значит в главном конфигурационном файле такой тип директивы запрещен, придется обратиться за консультацией к программисту и хостинг-провайдеру.
В директивах .htaccess кириллические символы не допускаются. Если необходимо указать адрес кириллического домена (мойсайт.рф), воспользуйтесь любым whois-сервисом, чтобы узнать его написание по методу punycode. Например, адрес «сайт.рф» будет выглядеть как «xn--80aswg.xn--p1ai/$1».
Слишком большое количество директив в .htaccess может снизить работоспособность сайта. Старайтесь использовать файл только в том случае, если другим путем задачу решить нельзя.
Если нет времени подробно изучать особенности директив, воспользуйтесь генератором .htaccess.

Замена мас-адреса на windows 10

Один (а не два последовательных!) 301 редирект на без www и с слешем на конце адреса страницы

RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !\/$
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)$ http://%1/$1/

RewriteCond %{REQUEST_URI} !\?
RewriteCond %{REQUEST_URI} !\&
RewriteCond %{REQUEST_URI} !\=
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_URI} !$
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)$ http://%1/$1

Другие настройки (CGI, Python, Node.js)

Инструкция по настройке сервисов находится в соответствующем разделе .

Директивы SSI (Server Side Includes) по умолчанию обрабатываются в файлах с расширением .shtml (например, index.shtml). Чтобы SSI обрабатывались и в других файлах, необходимо в файле .htaccess указать типы этих файлов:

Вместо «.ssi .html» укажите расширения файлов, в которых должны обрабатываться директивы SSI. Использовать в одном и том же файле PHP и SSI одновременно не рекомендуется.

Для выполнения скриптов CGI в какой-либо папке необходимо настроить веб-сервер соответствующим образом с помощью файла .htaccess. В папке, в которой должны выполняться скрипты CGI, создайте файл .htaccess вида:

Вместо «.cgi .pl» укажите список расширений, которые должны обрабатываться как скрипты. С помощью Файлового менеджера или FTP-клиента установите файлам скриптов права на выполнение (755).

Проектам на языке Python необходим файл .htaccess с таким содержанием:

Чтобы обрабатывать скрипты Node.js, укажите в .htaccess следующие директивы:

Замените example.com на основное имя вашего сайта, а login на логин вашего аккаунта.

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

Пример двойного редиректа

Для того, чтобы было понятно, о чем идет речь, приведу пример. Допустим, у вас настроен и добавление к урлу в конце слеш. То есть вы хотите такое преобразование:

http://site.ru/catalog -> https://site.ru/catalog

Допустим, у вас сначала был настроен редирект на https подобным образом:

server {
 listen 80;
 root   /var/www/site.ru/public;

 location / {
  return 301 https://site.ru$request_uri;
 }
}

А потом вас попросили добавить редирект всех урлов без слеша на тот же урл только со слешем на конце. Вы идете в секцию c listen 443 и добавляете редирект.

server {
 listen 443 http2;
...................
 location / {
  rewrite ^(*)$ $1/ permanent;
...................
}

# curl -I -L http://site.ru/catalog

HTTP/1.1 301 Moved Permanently
Server: nginx
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://site.ru/catalog

HTTP/2 301 
server: nginx
content-type: text/html
content-length: 162
location: https://site.ru/catalog/

HTTP/2 200 
server: nginx
content-type: text/html; charset=utf-8
vary: Accept-Encoding

На выходе у вас 2 редиректа вместо одного, что плохо для СЕО. Надо по возможности все реализовать в одном. В данном случае напрашивается простое и очевидное решение:

server {
 listen 80;
 server_name site.ru www.site.ru;
 root   /var/www/site.ru/public;

 location / {
  return 301 https://site.ru$request_uri/;
 }
}

Вроде бы все нормально. Теперь редирект будет автоматически добавлять слеш в конец запроса. Но проблемы начнутся со ссылками на медиа файлы. Например, запрос http://site.ru/catalog/img.png будет превращаться в https://site.ru/catalog/img.png, что нам совершенно не нужно. Чтобы это исправить, надо сделать так.

server {
 listen 80;
 server_name site.ru www.site.ru;

 location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
  return 301 https://site.ru$request_uri;
 }

 location / {
  return 301 https://site.ru$request_uri/;
 }
}

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

Как настроить 301 редирект

Джон Мюллер предупреждает, что Google может не проиндексировать конечную страницу, если не соблюсти все правила. Нужно использовать канонический тег, внутренние ссылки и при необходимости тег hreflang для конечной страницы, а не той, с которой вы перенаправляете пользователя. Иначе Google получит неправильные сигналы и может не проиндексировать конечную страницу.

Настроить переадресацию можно через панель управления вашим хостингом или вручную средствами HTML, PHP, JavaScript.

В настройках конкретного хостинга обычно подробно описано, как сделать редирект через панель управления. Для разных CMS есть специальные плагины для редиректов. Разберем способы для настройки вручную на примере редиректа на сайт с www или без него.

Редирект для Nginx

Для серверов под Nginx нужно использовать файл nginx.config, добавьте код в секцию server. Если вы настроили виртуальные хосты, для каждого хоста нужно редактировать файлы отдельно.

С домена с www на домен без www

server {#...
    if($host~ * www\.(.*)) {
        set $host_without_www $1;
        rewrite ^ (.*) $ http: //$host_without_www$1 permanent;
    }#...
}

С домена без www на домен с www

server {#...
    if($host~ * ^  + \. + $) {
        rewrite ^ (.*) $ $scheme: //www.$host$1 permanent;
    }#...
}

После изменения nginx.config перезапустите nginx с помощью команды «service nginx restart». Проверить, все ли корректно заполнено, можно через команду «nginx -t».

Редирект для Apache

Если вы используете Apache, вам нужен файл .htaccess. Для доступа есть несколько вариантов:

Используйте FTP и включите отображение скрытых файлов. Найдите .htaccess в каталоге public_html в папке с названием домена.
Откройте панель управления хостингом, включите отображение скрытых файлов и найдите его через Диспетчер файлов.

Скачайте .htaccess, добавьте код редиректа и загрузите файл заново. Если файла .htaccess нет, его нужно создать.

На домен без www

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.site\.ru$ 
RewriteRule ^(.*)$ <a href="https://site.ru/https://site.ru/$1" class="redactor-autoparser-object">https://site.ru/https://site.ru/$1</a>

На домен с www

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^site.ru
RewriteRule (.*) <a href="http://www.site.ru/http://www.site.ru/$1" class="redactor-autoparser-object">http://www.site.ru/http://www.site.ru/$1</a>

Редирект через PHP

Действует на уровне сервера. Лучше использовать другой способ, потому что этот работает медленно. Через PHP перенаправление настраивают для сайтов, где редирект нужен на многих, но не на всех страницах.

Файл index.php расположен в корневой папке. Скачайте его и добавьте код или отредактируйте прямо в диспетчере файлов в панели управления хостингом.

На домен без www

<!--?php
header("Location: http://site.ru/", true, 301);
exit();
?-->

На домен с www

<!--?php
header("Location: http://www.site.ru/", true, 301);
exit();
?-->

Редирект через HTML

Редирект через HTML-код медленнее, он работает на стороне браузера. Код нужно добавить между тегами и страницы, с которой нужно перенаправить. В параметре content=»» указывают задержку по времени.

На домен без www

<meta http-equiv="refresh" content="0; url=http://site.ru/">

На домен с www

<meta http-equiv="refresh" content="0; url=http://www.site.ru/">

Редирект через JavaScript

Редирект настраивают и с помощью JavaScript, он работает на стороне браузера, как и HTML. Это медленный способ и не сработает, если у пользователя в браузере отключен JavaScript. Его обычно настраивают для редиректов с задержкой, если такое требуется.

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

На домен без www

<script type="text/javascript">
    window.location.replace("http://site.ru/");
</script>

Для задержки:

На домен с www

<pre><script>
    window.location.replace("http://www.site.ru/");
</script></pre>

Через cPanel

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

На домен без www

В списке выберите нужный домен.
В поле «Перенаправляет на» пропишите его с префиксом http://.
Поставьте отметку у «Перенаправлять только с www»

На домен с www

В списке выберите нужный домен.
В поле «Перенаправляет на» пропишите его с префиксом http://www.
Поставьте отметку у «Не перенаправлять www»

Частные случаи

Двойное перенаправление

Двойное перенаправление — перенаправление А, установленное для перехода на перенаправление Б. Возникает, в случае если страница, на которую по задумке автора должно переводить перенаправление А, оказалась переименована. Иногда создаётся умышленно в целях вандализма (т. н. дятлинга).

Для поиска двойных перенаправлений необходимо использовать одноимённую служебную страницу. Их можно исправлять вручную или с помощью скрипта RedirectManagement.

Разорванное перенаправление

Разорванное перенаправление — перенаправление, ведущее на несуществующую (как правило, удалённую) страницу.

Отмечается на одноимённой служебной странице. Исправляется путём удаления вручную или с помощью скрипта RedirectManagement.

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

Взаимное перенаправление

Взаимное перенаправление — перенаправление А, ведущее на перенаправление Б, который возвращает читателя к перенаправлению А.

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

Рекурсивное перенаправление

Рекурси́вное перенаправление, или реку́рсия, — перенаправление, перенаправляющее само на себя.

Иногда создаётся участниками как шутка или для вандализма, практического применения не имеет.

Мягкое перенаправление

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

См. ]

Эта информация расположена в ]

Читайте ]

и т. п.

Как правило, мягкие перенаправления возникают из-за неопытности автора. Случаи, когда их создание оказывается следствием умышленной политики конкретного проекта, крайне редки. Причиной такого может являться разве что желание администрации увеличить число статей на вики (злокачественный ), поскольку стандартные перенаправления в счётчике не учитываются.

Иногда к мягким перенаправлениям относят также обособленные ссылки внутри содержательной статьи — например, в графе «Возможно, вы имели в виду» в преамбуле.

Настраиваем редиректы для SEO

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

При настройке 301 редиректов помните о двух правилах:

Избегайте нескольких последовательных перенаправлений — они увеличивают нагрузку на сервер и снижают скорость работы сайта.
Располагайте редиректы от частных к глобальным. Например, сначала переадресация с одной страницы на другую, затем общий редирект на страницы со слешем. Это правило работает не в 100% случаев, поэтому с размещением директив нужно экспериментировать.

1. Настраиваем постраничные 301 редиректы

Это потребуется в следующих случаях:

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

Просто удалить страницу — плохая идея, лучше не отдавать роботу ошибку 404, а перенаправить его на другой URL. В этом случае есть шанс не потерять позиции сайта в выдаче и целевой трафик. Настроить 301 редирект с одной страницы на другую можно при помощи директивы простого перенаправления:

— адрес страницы от корня, без протокола и домена. Например, .
— полный адрес страницы перенаправления, включая протокол и домен. Например, .

2. Избавляемся от дублей

Каждая страница сайта должна быть доступна только по одному адресу. Для этого должны быть настроены:

редирект на страницы со слешем в конце URL или наоборот;
главное зеркало — основной адрес сайта в поиске.

Сделать это можно при помощи модуля . В его составе используются специальные команды — директивы сложного перенаправления. Первой командой всегда идет включение преобразования URL:

Переадресация на слеш или наоборот

Настроить ли переадресацию на страницы со слешем или без, в каждом случае нужно решать индивидуально. Если у сайта уже накоплена история в поиске, анализируйте, каких страниц в индексе больше. Для новых сайтов обычно настраивают редирект на слеш. Проверить, не настроена ли переадресация по умолчанию, просто: удалите/добавьте слеш в конце URL. Если страница перезагрузится с новым адресом — мы имеем дубли, требуется настройка. Если URL подменяется — все в порядке. Проверять лучше несколько уровней вложенности.

Код 301 редиректа на страницы без слеша:

3. Настраиваем главное зеркало

Для начала нужно определиться, какой адрес будет являться основным для поиска. SSL-сертификат давно уже мастхэв. Просто установите его и добавьте правило в .htaccess. Не забудьте также прописать его в robots.txt.

Редирект на HTTPS

Определять, с «www» или без будет главное зеркало, можно несколькими способами:

добавить сайт в Яндекс.Вебмастер в двух вариантах, в консоли отобразится информация, какой URL поисковик считает главным зеркалом;
проанализировать выдачу и посмотреть, каких страниц сайта больше в индексе;
для нового ресурса не имеет значения, с «www» или без будет адрес, выбор за вами.

После того как выбор сделан, воспользуйтесь одним из двух вариантов кода.

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

4. Перенаправляем с одного домена на другой

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

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

или

Не забудьте поменять в коде «mysite1» и «mysite2» на старый и новый домен соответственно.

Способ 2. htaccess-редирект

Этот редирект делается простым помещением файла .htaccess в папку где нужно сделать редирект.

Например, редирект любого url (из папки где .htaccess) на нужный адрес, вот содержимое .htaccess:

RewriteEngine On
RewriteRule (.*) //leonov-do.ru/

Возможны более сложные редиректы, но такой вариант по своей сути — такой же как и header-редирект (если указывается внешний URL). Возможны вариант переадресации файла — вместо (.*) указать к примеру имя go — будет редиректить адрес go и т.п. Можно указать в одном файле несколько строчек RewriteRule подряд с разными правилами — тогда не нужно писать каждый раз RewriteEngine On.

Оптимизируем работу сайта

Скорость загрузки сайта — один из факторов ранжирования в поисковых системах. Увеличить ее можно в том числе с помощью директив в .htaccess.

14. Сжимаем компоненты сайта при помощи mod_gzip или mod_deflate

Сжатие файлов, с одной стороны, увеличивает скорость загрузки сайта, но с другой — больше нагружает сервер. В .htaccess можно включить сжатие при помощи двух модулей — mod_zip и mod_deflate. Они практически идентичны по качеству сжатия.

Синтаксис модуля Gzip более гибкий и он умеет работать с масками:

В mod_deflate вы перечисляете типы файлов, которые нужно сжать:

15. Усиливаем кэширование

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

В примере срок жизни кэша ограничен одной неделей («1 week»), вы можете указать свой срок в месяцах (month), годах (year), часах (hours) и т.д.

Другой вариант кода:

Для кэширования доступны следующие типы файлов:

image/x-icon;
image/jpeg;
image/png;
image/gif;
application/x-shockwave-flash;
text/css;
text/javascript;
application/javascript;
application/x-javascript;
text/html;
application/xhtml+xml.

Проксирование

Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой url — NGINX сам выполняет http-запрос по другому адресу и возвращает готовый ответ. Эта возможность может применяться для внутреннего распределения серверных ресурсов.

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

1. На другой сервер

Пример внутреннего перенаправления http-запроса на другой веб-сервер:

…
location / {
            proxy_pass $scheme://192.168.0.15:8080/;
            proxy_redirect     off;
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
}

* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.

Использование NGINX в качестве http-прокси:

server {
…
server_name site1.ru www.site1.ru;
location / {
proxy_pass http://192.168.1.21/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
server {
…
server_name site2.ru www.site2.ru;
location / {
proxy_pass http://192.168.1.22/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

* в данном примере запросы на site1.ru будут перекинуты на сервер 192.168.1.21, а запросы на site2.ru — 192.168.1.22.

HTTP proxy с авторизацией (если удаленный веб-сервер требует аутентификации):

server {
…
location / {
proxy_pass http://10.10.10.10/page/;
proxy_set_header Authorization «Basic dGVzdDp0ZXN0»;
…
}
}

* где 10.10.10.10/page — страница, на которую будут перекинуты запросы; dGVzdDp0ZXN0 — логин:пароль test:test, закодированные в формате base64.

2. Часть url на другой сервер

Выше мы рассмотрели пример перенаправления запроса по части веб-адреса. По схожему сценарию мы можем делать проксирование:

server {
  …
  location ~ ^/page1/(.*)$ {
   proxy_pass $scheme://10.10.10.10/$1;
  }
}

* и так, в данном примере при обращении по адресу site.ru/page1/<что-то еще>, nginx сделает внутренний запрос на сервер 10.10.10.10 по адресу 10.10.10.10/<что-то еще> и вернет готовый ответ.

3. На другой сайт

Мы можем сделать так, что при переходе по одному адресу у нас будет открываться совершенно другой сайт:

server {
…
location / {
proxy_pass https://www.dmosk.ru;
proxy_set_header Host www.dmosk.ru;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

* в данном случае мы при обращении к нашему серверу будем попадать на сайт https://www.dmosk.ru

Обратите внимание, что в proxy_set_header мы передаем хосту его имя — в противном случае, как правило, другой сервер вернет ошибку. Также мы не указываем proxy_redirect, иначе, nginx будет переводить запросы на реальный сайт (отправлять инструкции браузеру перейти на него), а не тот, что мы используем за http-прокси

4. Редиректы при проксировании

Если при проксировании хост возвращает инструкцию браузеру для выполнения редиректа, обозреватель может сменить адрес сайта. Это особенно не удобно, когда проксирование мы выполняем на другой сайт. Чтобы отловить редиректы и заменить их своими значениями, мы должны воспользоваться опцией proxy_redirect. Рассмотрим ее применение для предыдущего примера, когда мы проксировали запрос на сайт www.dmosk.ru:

server {
listen 80;
server_name dmosk.local www.dmosk.local;
location / {
proxy_pass https://www.dmosk.ru;
proxy_set_header Host www.dmosk.ru;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_redirect https://www.dmosk.ru/url1 http://dmosk.local/url2;
proxy_redirect https://www.dmosk.ru/ http://dmosk.local/;
}
}

* в конкретном случае мы проксируем запросы http://dmosk.local на сайт www.dmosk.ru, но если он вернет инструкцию для редиректа https://www.dmosk.ru/url1, в браузере он должен быть заменен на http://dmosk.local/url2. А также любое перенаправление для https://www.dmosk.ru/ будет заменено на http://dmosk.local/.