Что такое редирект, зачем он нужен и как сделать его

Введение

Что такое перенаправление (Redirects)?

Перенаправление означает, что веб-сайт может перенаправить запрос ресурсов на другой URL/конечную точку. Предположим, что вы отправляете запрос на apple.com, а apple.com может перенаправить вас на другой сайт (new-apple.com), так что вы окажетесь на new-apple.com, даже если исходный запрос был сделан для apple .com. Это называется «перенаправление». Существуют различные типы перенаправлений в HTTP.

Стандартные коды статусов перенаправлений — 3xx

• 300 Multiple Choices множество выбора
• 301 Moved Permanently перемещено навсегда
• 302 Found найдено
• 303 See Other смотреть другое
• 304 Not Modified не изменялось
• 305 Use Proxy использовать прокси
• 307 Temporary Redirect временное перенаправление
• 308 Permanent Redirect постоянное перенаправление

Перенаправление может происходить на стороне сервера (Server-Side) или на стороне клиента (Client-Side).

Server-Side: Запрос на перенаправление отправляется на сервер, затем сервер уведомляет браузер о перенаправлении на URL-адрес, указанный в ответе.

Client-Side: Браузер получает уведомление о перенаправлении на указанный URL-адрес напрямую, без вмешательства сервера.

Что такое Open Redirects?

Open redirect (Открытое перенаправление) это то, что написано в названии: Открытое (Open) перенаправление (Redirects) на любой веб-сайт.

Почему это проблема?

Ну, это плохо с самого начала, подумайте об этом на мгновение, что если apple.com, ДОВЕРЕННЫЙ веб-сайт, позволяет вам перенаправить на любой другой веб-сайт. Тогда злонамеренный пользователь может просто перенаправить apple.com на attacker.com, и люди все время будут думать что они находятся на apple.com, полагая, что ему доверяют, но на самом деле это не так. Поэтому разрешать перенаправления на любой веб-сайт без проверки или без надлежащего уведомления пользователя — это плохо.

Как настроить 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

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

На домен с www

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

3. Поставьте отметку у «Не перенаправлять www»

С HTTP на HTTPS (другой порт)

Пример конфигурации для перенаправления запросов на другой порт — с 80 (http) на 443 (https):

server {
        listen 80;
        server_name domain.ru www.domain.ru;
        return 301 https://$host$request_uri;
}

* в данном примере для всех обращений к сайту domain.ru по 80 порту (http) будет работать редирект на 443 порт (https) с кодом 301 (для склеивания доменов).

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

server {
        listen 80;
        server_name domain.ru www.domain.ru;
        if ($uri !~ /page.html){
                return 301 https://$host$request_uri;
        }
}

* в данном примере запрос на страницу /page.html будет открыт по http.

Разновидности редиректа

Непосредственно в программировании и оптимизации ресурсов чаще всего используются только три ключевых разновидности редиректа. Есть смысл поговорить о них более подробно.

301

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

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

Рекомендую обращать внимание на этот вид редиректа только в тех случаях, когда вы полностью уверены в том, что имеющийся адрес вам больше никогда не пригодится

302

Представляет собой временный редирект. То есть, перенаправление с одного ресурса на другой будет происходить только в течение определённого срока времени. Пользователь попадёт на другую страницу, которая не будет индексироваться. Настройки в таком случае останутся на изначальной странице и никуда не перенесутся. Этот метод используется в случаях, когда требуется оставить прошлый адрес или ссылки, размещённые на нём. Отдельно можно упомянуть его полезность для онлайн-магазинов: когда один товар заканчивается, а вы хотите не потерять позицию соответствующего ему раздела, можно настроить редирект на аналогичные продукты.

Когда вам необходимо перевести сайт на другое доменное имя или масштабно обновить его, применять данный вид редиректа не рекомендуется. Это чревато тем, что поисковик будет отображать сразу два варианта страниц, из-за чего возникнет полное повторение. Также следует не забывать о том, что если Google посчитает, что редирект был использован неправильно, все показатели СЕО будут перенесены на новый адрес, когда как старый полностью исчезнет из выдачи.

307

Он также подразумевает временную смену адреса, однако в отличие от 302 изначальная версия ресурса сохранит свои позиции. Поисковики, в свою очередь, воспринимают его практически так же, как и 302.

Помимо вышеперечисленных существует ещё несколько разновидностей редиректа. О каждой из них можно рассказать вкратце:

1. 300. Подразумевает наличие нескольких адресов, на которые может быть перенаправлен пользователь исходя из того, как настроен его браузер.
2. 303. В данном случае нужный документ был найден, однако для его отображения на сайте нужно будет применить GET.
3. 304. В случае с ним появится информация о том, что сайт никак не был изменён после визита, а браузер загрузит страницу, сохранённую в кэше.
4. 305. Редирект выполняется на прокси-сервере, после чего выполняется перенаправление по вопросу, заданному в поисковике.

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

Благодарю вас за внимание, всего хорошего!

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

Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой 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/.

The Syntax for HTML Redirect Code

The HTML redirect is also known as the meta refresh redirect, or simply HTML meta redirect. It allows you to choose whether you need an immediate or a delayed redirect. If you specify the delay time in seconds, the user will see the old page for exactly that long.

To make a page in HTML redirect to another page, you should follow this syntax:

Example Copy

As you can see, it requires two parameters:

• represents the delay before the browser redirects the user to a different page. Define it in seconds, or enter a 0 if you need an immediate HTML redirect.
• represents the URL address you need to redirect your user to after the delay.

In the example below, you can see the HTML redirect code that takes the user to BitDegree’s website with a delay of five seconds:

Example Copy

Just like all meta tags, the HTML redirect code should be placed in the <head> section of the document. This way, the browser receives certain instructions that stay invisible to the user.

Pros

• Simplistic design (no unnecessary information)
• High-quality courses (even the free ones)
• Variety of features

Main Features

• Nanodegree programs
• Suitable for enterprises
• Paid certificates of completion

100% FREE Pros

• Professional service
• Flexible timetables
• A variety of features to choose from

Main Features

• Professional certificates of completion
• University-level courses
• Multiple Online degree programs

100% FREE Pros

• Great user experience
• Offers quality content
• Very transparent with their pricing

Main Features

• Free certificates of completion
• Focused on data science skills
• Flexible learning timetable

100% FREE

Переадресация на https через htaccess

Если ваш сайт уже проиндексирован то перед настройкой редиректа вам нужно произвести склейку зеркал, а потом уже настраивать редирект. Это поможет минимизировать потери трафика и позиций . О том как это сделать написано тут.

Для того, что бы настроить редирект с http на https, вам нужно, при помощи программы Notepad++, в корне вашего сайта открыть файл .htaccess, и далее, в самом начале этого файла, прописать один из нескольких вариантов перенаправления.

Как пользоваться Notepad++ и настроить для него FTP-подключение я рассказывала в одной из прошлых статей, с которой вы можете ознакомиться по этой ссылке:

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

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

Межпространственные перенаправления

В общем случае, перенаправления между разными пространствами имён нежелательны. Их необходимость, если она неочевидна, рекомендуется обосновывать на странице перенаправления, дописав текст объяснения в конец страницы; в противном случае они могут быть удалены. Это объяснение не будет отображено при работе перенаправления, однако люди, открывшие страницу с целью разобраться в причинах её создания или для её удаления, заметят и прочтут его. Следующие случаи являются консенсусными исключениями:

1. Допустимы шорткаты из пространств имён «Википедия» и «Обсуждение Википедии» на страницы других пространств, если они являются общеузнаваемыми или имеют большое число ссылок (в частности, из описаний правок). Примеры: ВП:ЗАЯ, ВП:WPCHECK.
2. Допустимы перенаправления, необходимые для работы расширений MediaWiki или сторонних инструментов, а также перенаправления с имён, распространённых в большинстве других языковых проектов. Хорошим примером являлся WP:AWB до того момента, как «WP» не стал алиасом для «Википедия».
3. Перенаправления со страниц участников на их страницы обсуждения являются распространённой консенсусной практикой.
4. Допустимы перенаправления со страниц обсуждения модулей на страницы обсуждения шаблонов, если модуль написан для работы единственного шаблона, а также со страниц обсуждения MediaWiki на страницы обсуждения соответствующих документаций.
5. В силу размытости понятий, допустимы перенаправления между пространствами имён «Википедия» и «Справка».
6. Подстраницы активных участников могут являться межпространственными перенаправлениями, если это необходимо для облегчения навигации.

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

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

Путь хранения файлов сессий

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

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

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

1. Избегайте нескольких последовательных перенаправлений — они увеличивают нагрузку на сервер и снижают скорость работы сайта.
2. Располагайте редиректы от частных к глобальным. Например, сначала переадресация с одной страницы на другую, затем общий редирект на страницы со слешем. Это правило работает не в 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» на старый и новый домен соответственно.

Переадресация с 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

Правила Redirect

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

Redirect или RedirectPermanent

Главный недостаток данных правил заключается в том, что для каждого адреса необходимо прописывать новое правило. Если необходимо сделать несколько редиректов, то каждый новый редирект пишется с новой строки.

Если нужно сделать несколько редиректов, то каждый новый редирект нужно написать с новой строки.

или

Для перенаправления всех запросов на другой сайт вы можете использовать следующую конструкцию:

или

RedirectMatch

Этот редирект отличается тем, что в нем можно использовать регулярное выражение. Например, при переносе сайта с Windows на Linux, необходимо сменить все ссылки с *.php на *.aspx:

RedirectMatch /(.*)\.aspx$ /$1.php

RewriteRule

Для работы данного модуля убедитесь в том, что включена опция FollowSymLinks, эту функцию нужно прописать в конфигурационном файле Apache или в файле .htaccess как указано ниже.

Рассмотрим самые распространённые варианты её использования.

Редирект с одного сайта на другой

Или более понятный синтаксис

Вы можете использовать любой.

Перенаправление домена с http на https

Nginx

Модуль ngx_http_rewrite_module, необходимый для настройки перенаправлений, он устанавливается автоматически вместе с Nginx.

Редирект 301 с www.domain.com на domain.com

Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для домена с www, вторая для домена без www:

Секция server для редиректа:

Секция server, где находятся основные настройки домена:

server {
     listen  80;
     server_name domain.com;
.....
}

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

service nginx restart

Редирект 301 с domain.com на www.domain.com

Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для домена без www, вторая для домена с www.

Секция server для редиректа:

Секция server, где находятся основные настройки домена.

server {
     listen  80;
     server_name www.domain.com;
.....
}

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

service nginx restart

Видеоматериал

Сервисы

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

Сервисы перенаправления URL

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

История

Первые службы перенаправления использовали домены верхнего уровня (TLD), такие как « .to » (Тонга), « .at » (Австрия) и « .is » (Исландия). Их целью было сделать запоминающиеся URL-адреса. Первым распространенным сервисом перенаправления был V3.com, который на пике своего развития в 2000 году насчитывал 4 миллиона пользователей. Успех V3.com был обусловлен наличием большого количества коротких запоминающихся доменов, включая «r.im», «go.to», «i». .am «,» come.to «и» start.at «. V3.com был приобретен FortuneCity.com, большой компанией, предоставляющей бесплатный веб-хостинг, в начале 1999 года. Поскольку цена продажи доменов верхнего уровня начала падать с 70 долларов в год до менее чем 10 долларов, использование услуг перенаправления снизилось. С запуском TinyURL в 2002 году родился новый вид сервиса перенаправления, а именно сокращение URL . Их целью было сделать длинные URL-адреса короткими, чтобы иметь возможность размещать их на интернет-форумах. С 2006 года, когда в чрезвычайно популярной службе Twitter было установлено ограничение в 140 символов , эти службы с короткими URL-адресами активно использовались.

Маскировка реферера

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

Вот упрощенный пример такого сервиса, написанный на PHP .

<?php
$url = htmlspecialchars($_GET'url']);
header('Refresh: 0; url=https://' . $url);
?>
<!-- Fallback using meta refresh. -->
<html>
 <head>
  <title>Redirecting...</title>
  <meta http-equiv="refresh" content="0;url=https://<?= $url; ?>">
 </head>
 <body>
 Attempting to redirect to <a href="https://<?= $url; ?>">https://<?= $url; ?></a>.
 </body>
</html>

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

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

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

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

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

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

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

Объяснение

Допустим, есть «хорошо известный» веб-сайт — https://example.com/. И давайте предположим, что есть ссылка, как

Эта ссылка на страницу регистрации, после регистрации вы будете перенаправлены на https://example.com/login, который указан в URL-адресе в GET параметре redirectUrl.

Что произойдет, если мы изменим example.com/login на attacker.com?

Посещая этот URL, если после регистрации мы будем перенаправлены на attacker.com, это означает, что у нас есть открытая уязвимость перенаправления. Это классический открытый редирект и часто используется для фишинга.

Почему это происходит?

Это происходит из-за недостаточной проверки перенаправления в серверной части, что означает, что сервер неправильно проверяет, находится ли URL-адрес перенаправления в своем белом списке или нет. Вот несколько примеров уязвимого кода

PHP (Server-Side)

Здесь код php слепо захватывает URL-адрес из параметра redirect_url и перенаправляет на этот URL-адрес, используя HTTP-заголовок Location.

Javascript (Client-Side)

Мы можем назначить строку URL для location.href объекта . Это приведет к перенаправлению. Если там нет проверок, значит, это уязвимость.

HTML (Client-Side)

Метатеги HTML могут обновлять сайт с заданным URL-адресом в качестве содержимого (content), а также вы можете указать время задержки перед обновлением.

• Посетите каждую конечную точку цели, чтобы найти параметры «redirect».
• Просмотрите истории прокси. Обязательно используйте фильтры.
• Простой перебор (Bruteforcing) тоже может помочь найти уязвимость
• Вы можете раскрыть многие конечные точки, просто прочитав код JavaScript.
• Google — твой друг, поищите в поисковике, пример запроса: 
• Изучите и проанализируйте целевое приложении на наличие потребности перенаправления , например, перенаправление на панель мониторинга после входа в систему или что-то в этом роде.