Разбираем все виды редиректов (html, js, php, htaccess)

301 редирект. Популярные шаблоны

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

Options +FollowSymLinks
RewriteEngine On
RewriteBase /

Склейка домена (префикс www)

www.example.com и example.com в глазах поискового работа — абсолютно разные сайты, каждый со своими показателями. Для того чтобы не распылять вес, склеиваем эти адреса

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

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

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

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

Зачастую главная страница вашего сайта доступна по нескольким адресам: example.com/ и example.com/index.php или example.com/index.html. Для склейки таких дублей, используем следующий шаблон:

Склейка индексной страницы с корнем сайта

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

Склейка поддомена и папки

Иногда возникает необходимость сделать 301 редирект с поддомена на папку сайта. Например у вас есть страница category.example.com/page/ и вам нужно склеить ее с дублирующей страницей example.com/category/page/. Прописывем в файле .htaccess поддомена:

Редирект с поддомена на папку основного домена

RewriteCond %{HTTP_HOST} ^category\.example\.com 
RewriteCond %{HTTP_HOST} ^category\.example\.com
RewriteRule ^(.*)$ http: //example .com /category/ $1 

При необходимости наоборот перенаправить с папки на поддомен:

Редирект с папки основного домена на поддомен

RewriteCond %{HTTP_HOST} ^example\.com$ 
RewriteRule ^category\/(.*)$ http: //category .example.com/$1 

Редирект с одних расширений файлов на другие

Если вам необходимо сменить расширение файла в адресе (например page.html на page.php) или убрать его совсем:

RewriteRule ^(.*)\.html$ $1.php 

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

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

RewriteCond %{HTTP_HOST} ^oldsite\.com
RewriteRule ^(.*)$ http: //newsite .com/$1 

Все страницы домена oldsite.com будут перенаправлены на соответствующие страницы newsite.com.

301 Редирект динамических страниц

При модернизации динамического сайта и создании ЧПУ-адресов часто возникает необходимость перенаправить старые страницы с параметрами ID на новые с ЧПУ. Например, чтобы переадресовать страницу вида http://example.com/page.php?id=13 на новую страницу http://example.com/new-url/, используется следующая конструкция:

RewriteCond %{QUERY_STRING} ^ id =13$
RewriteRule ^ /page .php$ http: //example .com /new-url/ 

Добавляем слеш в конце адреса

Если у вас на сайте реализованы ЧПУ адреса тем или иным способом, то вероятно ваши ссылки могут работать либо со «/» на конце адреса либо без него одинаково. Добавим однозначности и добавим слеш ко всем адресам.

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

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

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

VertrigoServ — локальная площадка для разработки сайтовНастраиваем под себя Sublime Text 3Потерянные заказы в Opencart (ocStore). Вылавливаем баги системы.Блог возвращается в выдачу YandexЗа что я не люблю Битрикс или CMS от маркетологовИнструменты организации и приведения в порядок кода CSS

HTML Redirect: Useful Tips

• If you don’t define a new URL address for the redirect, HTML page will simply reload itself after the time specified. It can be useful when you need to refresh dynamic content.
• We’d advise you to avoid delays shorter than 3 seconds, as that makes it virtually impossible for the user to click the Back button on their browser.
• Be careful not to overuse HTML meta redirects: if your website has a ton of them, the search engines may think it contains spam and remove it from their index.
• You can also create redirects with PHP, JavaScript, Ruby on Rails, and Python Flask, as well as in the Apache, Nginx, and Lighttpd web servers.

Несколько примеров совмещения 2-х редиректов в один

Для избежания последовательных редиректов можно использовать совмещенные варианты.

301 редирект с www на без www и со слешем в конце URL

Комбинируем и

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 

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

301 редирект с без www на с www и со слешем в конце URL

Комбинируем и

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

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

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

301 редирект с без www на с www и без слеша в конце URL

Комбинируем и

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

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

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

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

301 редирект с www на без www и без слеша в конце URL

Комбинируем и

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 

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} ^(.*)$
RewriteRule ^(.*)\/$ http://%1/$1 

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

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

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

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

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

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

Какие проблемы могут возникнуть при переходе на HTTPS

Проблем при переходе на HTTPS немного. Первая причина не убраны со страницы все исходящие и внутренние ссылки с протоколом HTTP. Далее редиректы, неправильно прописанные в htaccess. Не знание специфики WordPress, что и где нужно менять. Что делать в таких ситуациях:

1. Проверить всё ли правильно сделано, в админке и в файле htaccess
2. Если всё хорошо, то проверить работу во всех браузерах, хром, опера, мозилла и т.д. Возможно проблема в неисправном браузере либо в расширениях, которые не дают сработать редиректу.
3. Возможны неправильные настройки сервера или SSL — сертификата, с этой проблемой скорее всего придется обратиться в поддержку хостинга. Если ошибка не на их стороне, то к поставщикам сертификата.

Если удобнее учится по видео, то смотрите наш обучающий ролик.

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

Сервисы

Существуют службы, которые могут выполнять перенаправление 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-адреса, выбранный им самим, с любой страницы, которая использует ресурсы веб-сервера.

Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)

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

server {
        listen 80 default_server;
        return 302 https://welcome.domain.ru$request_uri;
}

или независимо от протокола:

server {
        listen 80 default_server;
        return 302 $scheme://welcome.domain.ru$request_uri;
}
server {
        listen 443 default_server;
        return 302 $scheme://welcome.domain.ru$request_uri;
        ssl on;
        ssl_certificate /etc/nginx/ssl/cert.pem;
        ssl_certificate_key /etc/nginx/ssl/cert.key;
}

* $scheme позволяет перевести запрос на тот же протокол (http или https), по которому он был инициирован.
* если nginx должен слушать и обрабатывать запросы по https, необходимо указывать в настройках пути к сертификатам.

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

Настраиваем редиректы для 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» на старый и новый домен соответственно.

Нежелательные перенаправления

1. Двойное перенаправление возникает, когда целевая страница сама есть перенаправление. Обычно они получаются при переименовании, поскольку старое название страницы само становится перенаправлением. Двойные перенаправления не работают, и их следует исправлять, чтобы они всегда вели на статьи. В нашем разделе бо́льшую часть работы по их исправлению берут на себя боты.
2. Перенаправления не работают в пространстве категорий, для переименования категории см. описание шаблона {{Переименовать категорию}}.
3. В общем случае не следует создавать перенаправления от более общего понятия к более узкому. Например, не следует делать перенаправление с названия семейства животных на статью об одном из видов этого животного, даже если в статье о семействе нет полезной информации. Примером может служить ошибка при перенаправлении пчела → медоносная пчела. В таких случаях можно воспользоваться шаблоном временного перенаправления или же оставить общую статью без перенаправлений.
4. В любом случае понятие, с названия которого осуществляется перенаправление, должно быть упомянуто и объяснено в статье, на которую это перенаправление указывает.
5. Не следует создавать перенаправления вида «термин» → «термин (значения)», за исключением случаев, когда статья о явно основном и явно значимом значении этого термина ещё не создана (в этом случае такое перенаправление может быть создано как временное).
6. Следует избегать создания перенаправлений, содержащих сразу два или более альтернативных названий, например: «МГУ (Московский государственный университет)» → «Московский государственный университет», «Вольво (Volvo)» → «Вольво». Вместо этого для каждого из альтернативных названий нужно создать отдельный редирект, например, «МГУ» → «Московский государственный университет», «Вольво» → «Volvo».
7. Перенаправления на служебные страницы не работают, а потому должны быть заменены на мягкие перенаправления.

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

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

301

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

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

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

302

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

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

307

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

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

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

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

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

Имеет ли смысл получать МВУ

Понятие и назначение безопасного режима

В Windows 7 присутствуют диагностические режимы запуска операционной системы для решения тех или иных проблем. Один из них – безопасный или Safe mode (ещё называется режимом устранения сбоев) предназначен для выявления и устранения неполадок в Win 7, работе драйверов и аппаратных компонентов компьютера. В безопасном режиме запускается минимально возможный перечень процессов, служб и драйверов, необходимых для обеспечения работы операционной системы и основных аппаратных компонентов. Благодаря функционированию с ограниченными возможностями быстрее выявляются проблемы, ведь прикладное программное обеспечение не активно.

С 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.

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

Вывести модель видеокарты в PowerShell

Для тех немногих, кто пользуется таким инструментом как PowerShell – тоже найдется способ распознавания модели видеокарты. Как всегда, от имени администратора запускаем Windows PowerShell и вводим одну единственную команду:

Get-WmiObject Win32_VideoController | Format-List Name

Узнать ID оборудования тоже можно — для этого следует ввести команду:

Get-WmiObject Win32_VideoController | Format-List PNPDeviceID

Если вдруг потребуется узнать версию установленного драйвера – для этого тоже есть своя команда:

Get-WmiObject Win32_VideoController | Format-List DriverVersion

Ну а все интересующие параметры можно узнать с помощью команды:

Get-WmiObject Win32_VideoController | Format-List *

Все стандартные редиректы в nginx

Рассмотрю типовой пример, когда у нас одновременно присутствуют следующие редиректы:

1. С http на https.
2. С www на без www для обоих протоколов.
3. Без слеша на конце на урл со слешем.

Наша цель будет реализовать все преобразования url в одном месте и выдать клиенту только один 301-й редирект.

server {
    listen 443 ssl http2;
    server_name site.ru;
    root /web/sites/site.ru/www/;
    index index.php index.html index.htm;
    access_log /web/sites/site.ru/log/access.log main;
    error_log /web/sites/site.ru/log/error.log;

    ssl_certificate		/etc/letsencrypt/live/site.ru/fullchain.pem;
    ssl_certificate_key		/etc/letsencrypt/live/site.ru/privkey.pem;

    location / {
	rewrite ^(*)$ $1/ permanent;
	try_files $uri/ /index.php?$args;
	}

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
	access_log off;
	expires max;
	}

    location ~* ^/(\.ht|xmlrpc\.php)$ {
	return 404;
	}

    location ~ \.php$ {
	try_files  $uri =404;
	fastcgi_pass   unix:/var/run/php-fpm/php7-fpm.sock;
	fastcgi_index index.php;
	fastcgi_param DOCUMENT_ROOT /web/sites/site.ru/www/;
	fastcgi_param SCRIPT_FILENAME /web/sites/site.ru/www$fastcgi_script_name;
	fastcgi_param PATH_TRANSLATED /web/sites/site.ru/www$fastcgi_script_name;
	include fastcgi_params;
	fastcgi_param QUERY_STRING $query_string;
	fastcgi_param REQUEST_METHOD $request_method;
	fastcgi_param CONTENT_TYPE $content_type;
	fastcgi_param CONTENT_LENGTH $content_length;
	fastcgi_param HTTPS on;
	fastcgi_intercept_errors on;
	}

    location = /favicon.ico {
	log_not_found off;
	access_log off;
	}

    location = /robots.txt {
	allow all;
	log_not_found off;
	access_log off;
	}
}

server {
    listen 443 ssl http2;
    server_name www.site.ru;

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

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 / {
	rewrite ^/(.*)/$ /$1;
	return 301 https://site.ru$uri/;
    }
}

Получилось примерно так. Призываю не копировать бездумно конфиг, а проверить то, что я предлагаю. Хотя я сам внимательно проверил, как мог, но все равно не застрахован от ошибки. На мой взгляд здесь рассмотрены все основные моменты с редиректами. На выходе всегда один 301 редирект, какой бы запрос мы не сделали. При этом все реализовано средствами самого веб сервера, а значит, будет работать максимально быстро.