Рекомендуемые сообщения

AWARO    548

Nginx, 301 редирект с http на https протокол
 

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

    server {
        #...
        if ($scheme = http) {
            return 301 https://$server_name$request_uri;
        }
    }

или

    server {
        #...
        listen  server_ip:80;
        server_name  www.site.com;
        rewrite ^ https://www.site.com$request_uri? permanent; 
    }

Nginx, 301 редирект с https на http протокол

Обратный пример конфигурации для редиректа с http на https:

    server {
       listen  443;
       server_name  www.site.com;
       rewrite ^ http://www.site.com$request_uri? permanent; 
    }
     
    server {
        listen  80;
        server_name www.site.com;
        #...
    }

Nginx, 301 редирект с www на без www

Пример 301-го редиректа на основное зеркало без www:

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

или

    server {
        #...
        server_name www.site.com;
        rewrite ^/(.*)$ http://site.com/$1 permanent;
    }

Nginx, 301 редирект с без www на с www

Обратный пример 301-го редиректа на основное зеркало сайта с www:

    server {
        #...
        server_name site.com;
        rewrite ^/(.*)$ http://www.site.com/$1 permanent;
    }
     
    server {
        listen  80;
        server_name www.site.com;
        #...
    }

Nginx, 301 редирект для одной страницы

Если у страницы поменялся URL, то лучше сделать 301 редирект на новый URL:

    server {
        #...
        if ( $request_filename ~ oldpage/ ) {
            rewrite ^ http://www.site.com/newpage/? permanent;
        }
        #...
    }

Nginx, 301 редирект для папки

Аналогичный пример 301-го редиректа для папки:

    server {
        #...
        if ( $request_filename ~ oldfolder/.+ ) {
            rewrite ^(.*) http://www.site.com/newfolder/$1 permanent;
        }
        #...
    }

Nginx, 301 редирект с одного домена на другой

Если вы сменили домен сайт и хотите перенести вес старого домена на новый, то можно сделать 301-й редирект со старого домена на новый:

    server {
        server_name domain.com www.site.com; 
        rewrite ^ $scheme://www.new-site.com;
    }

Nginx, 301 редирект с каждой страницы одного домена на такой же URL адрес другого домена

Если вы планируете изменить свой домен или изменить название предприятия, то перенаправление домена является единственным лучшим решением для сохранения пользователей и перевода их запросов на новый домен:

    server {
        server_name site.com www.site.com; 
        rewrite ^ $scheme://www.new-site.com$request_uri permanent;
    }

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

Часто бывает так что одна и та же страница доступна по двум URL, например /may-best-page и /my-best-page/, если человеку понятно что это одна и та же страница, то поисковые системы понимают это как две разные страницы, соответственно разбивают вес страницы, а также показываются в аналитике (статистике) как 2 разные страницы. Для того, что бы избежать этого вы можете сделать 301 редирект со страниц со слешем в конце URL на без него:

    server {
        #...
        rewrite ^/(.*)/$ /$1 permanent;
        #...
    }

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

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

    server {
        #...
        rewrite ^(.*[^/])$ $1/ permanent;
        #...
    }

Дополнительно

Не забудьте перед использованием примеров сменить site.com на свой домен. После внесения изменений в файл конфигурации nginx для домена необходимо перезапустить nginx:

service nginx reload

или

service nginx restart

или перезапустить с панели

 

 

источник: кодер.укр

 


Для редиректа с site.ru/brand/product на site.ru/product

при переездах и т.д.

добавлять в блок server :

if (!-d $request_filename){
  set $r 1;
}

if (!-f $request_filename){
  set $r 2$r;
}

if ($r = 21){
  rewrite ^/(.*)/(.*)$ $scheme://$host/$2 permanent;
}

это отсюда

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
sitecreator    481

на мой взгляд, очень много кода.

И знатоками nginx не приветствуется использование if без необходимости.  Об этом и на официальном сайте написано.

 

Все делается несколько проще. И без if.

 

Также еще нужно учесть один момент, что в ISPmanager есть ссылка на phpmyadmin.  И она должна работать без конфликтов. Это не всегда учитывается. Дело в том, что ссылка на phpmyadmin формируется таким образом (автоматически в ISPmanager ), что она по идее должна работать при обращении не только по IP сервера (IP/phpmyadmin ), но и по любому адресу вроде сайт.com/phpmyadmin.  Точнее, скорее всего, предполагалось, что будет использоваться только ссылка IP/phpmyadmin (по обычному или SSL протоколу), но из-за особенности конфига phpmyadmin-а на phpmyadmin  будут ссылаться и ссылки вида сайт.com/phpmyadmin.

 

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

 

Это нужно учитывать.

 

Также у вас есть некоторые неточности.  секция server не будет работать без сертификата если вы собрались делать редирект с https.  Браузер просто напросто тормознет на этом моменте (нет сертификата!) и не будет никакого редиректа.

Это также нужно учитывать когда делаете редирект с www на "без www" (и наоборот) используя протокол SSL.

 

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

 

------------------

В принципе можно считать нормальным, что когда из ISPmanager вы переходите по ссылке:

 

http://***.***.***.***/phpmyadmin/

то попадаете на

httpS://site.com/phpmyadmin/

 

Если у вас сайт единственный (и он с SSL) или он самый верхний получается в конфиге NGINX, то так и будет.

Если сайтов нет, то тогда доступ будет только по IP.

 

Но можно настроить так, что будет работать всегда http://***.***.***.***/phpmyadmin/

Кстати, в последних версиях ISPmanager отказались от ссылки httpS://***.***.***.***/phpmyadmin/

т. к. возникали проблемы с доступом.

 

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

 

 

 

 

Изменено пользователем sitecreator

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
AWARO    548
10 минут назад, sitecreator сказал:

 

т.к. группа по теме snippets
Давайте сюда в одно место выкладывать все рабочие конфиги и т.д.
смысл тут спорить и развивать что так что не так простынями?
Если вы видите неточности ( а там расписано по конкретным задачам) то это не ко мне а там по ссылке с источника - все вопросы к нему.
Артём создал эту группу для конкретных решений думаю и я пытаюсь помочь как то - обьеденить нормально в одном месте чтоб не бегать не искать.

у меня например нифига ни одно из этих решений не работает,
найду рабочий конфиг буду благодарен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
AWARO    548
18 минут назад, sitecreator сказал:

 

конфиги у каждого сайта свои
апача нет
 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
sitecreator    481

Как правило, если сайт использует протокол https, то

 

ссылки вида

 

http://site.com

http://www.site.com

https://www.site.com

 

должны вести на https://site.com

(если именно это является главным зеркалом вашего сайта)

 

т. е. делаем редирект  301 c www (оба протокола) на "без www" (https)

 

Тогда конфиг сайта может быть таким  (вместо звездочек IP сайта):


 

server {
    server_name site.com www.site.com;
    listen *.*.*.*:80;
    return 301 https://site.com$request_uri;

}
server {
    server_name www.site.com;
    listen *.*.*.*:443;
    return 301 https://site.com$request_uri;
    
    ssl on;
    ssl_certificate "..............crtca";
    ssl_certificate_key ".............key";
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    add_header Strict-Transport-Security "max-age=31536000;";
}    
server {
    server_name site.com;
    listen *.*.*.*:443;
    ssl on;
    ssl_certificate "..............crtca";
    ssl_certificate_key ".............key";
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    add_header Strict-Transport-Security "max-age=31536000;";
    ........

    ........

}

 

Изменено пользователем sitecreator

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
sitecreator    481
25 минут назад, AWARO сказал:

у меня например нифига ни одно из этих решений не работает,

 

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

вся остальная информация заключена в третьем блоке server.

 

Для нормальных редиректов нужно именно три блока server.

Ниже распишу еще разные хитрости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
sitecreator    481

Может возникнуть ситуация когда нужно получить доступ к статистике Яндекса по сайту без https,  особенно если вы переходили на https и вам нужно сравнение информации (от Яндекса) как было "ДО" и "ПОСЛЕ".

 

Тогда вышеприведенный конфиг не позволит Яндексу прочитать свой ключ по адресу http  (без S),  а Яндекс может попросить такой ключ, т. е. подтвердить ваши права. И это не смотря на то, что права на сайт с https  у вас уже есть.

 

Тогда нужно сделать модификацию в первом блоке server

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

 

server {
    server_name site.com www.site.com;
    listen *.*.*.*:80;
	if ($request_uri != "/yandex_ваш_ключ.html") {return 301 https://site.com$request_uri;}
	# ниже путь к корневой папке вашего сата (там и ключ яндекса)
	set $root_path ......;  
	root $root_path;
}
server {
    server_name www.site.com;
    listen *.*.*.*:443;
    return 301 https://site.com$request_uri;
    
    ssl on;
    ssl_certificate "..............crtca";
    ssl_certificate_key ".............key";
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    add_header Strict-Transport-Security "max-age=31536000;";
}    
server {
    server_name site.com;
    listen *.*.*.*:443;
    ssl on;
    ssl_certificate "..............crtca";
    ssl_certificate_key ".............key";
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    add_header Strict-Transport-Security "max-age=31536000;";
    ........

    ........

}

 

Изменено пользователем sitecreator

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
AWARO    548

..

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
sitecreator    481

обязательно проверяйте конфиг:

 

nginx -t

 

а далее перезагрузка nginx

 

systemctl reload nginx.service

 

 

Теперь еще тонкость. ОЧЕНЬ ВАЖНО если у вас настроено автоматическое продление (генерация) сертификата.

Важно чтобы не только был правильный конфиг с точки зрения самой nginx,  но и с точки зрения ISPmanager-а, который проверяет сам конфиг на ошибки по своим алгоритмам.

 

Так уж случилось, что ISPmanager несовершенен и находит ошибки в совершенно верном конфиге nginx.  Такое иногда случается.  В таком случае когда настанет час Х  (авто-генерация сертификата),  то должен автоматически переписаться конфиг с новыми данными сертификата.

Но если исправный конфиг (по версии самого nginx)  не проходит проверку на синтаксис в ISPmanager,  то вас ждет неприятность.

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

 

 

Некоторые продвинутые хостинг-провайдеры знают об этой проблеме.  Из пользователей мало кто знает.

Поэтому обязательно делайте проверку средствами ISPmanager вашего конфига.

 

Если получается так, что ваш рабочий конфиг не проходит проверку через ISPmanager, но он вам нужен, то разбейте конфиг на две части: основную (которую будет проверять ISPmanager)  и дополнительную с "ошибками " (по версии ISPmanager,  но без ошибок по версии nginx).

 

В основную автоматически ISPmanager  будет вносить изменения когда нужно сменить сертификат. Он проверять будет только ее.

А дополнительную часть нужно уже инклюдить к основной. 

 

Об этой тонкости мало кто знает. Даже гуру порой...

Изменено пользователем sitecreator

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти


  • Похожий контент

    • От hegst
      Проблема заключается в том, что после перехода на https сертификат безопасности показывает незащищенное соединение из-за картинок которые работают по не защищенному протоколу http.
      Вопрос, как исправить ибо в ручную править (удалять и добавлять ) картинки очень долго так как много страниц.
    • От AlexBr
      ocStore 2.1.0.2.1 
      В SeoPro выставлен слеш в окончании ЧПУ, но редирект происходит на этот слеш 302-м редиректом. Мне же нужен 301-й редирект
      Найденный ответ в похожем вопросе но для ocStore 2.0.2
      https://opencartforum.com/topic/54195-resheno-303-redirekt-seopro-i-chpu/
      Но в  ocStore 2.1.0.2.1 в этом файле нет ни каких "303 See Other" и 303.
      По-этому вопрос знающим. Будет ли достаточно прописать 
      $this->response->redirect($seo,301); чтоб не испортить чего-либо?
    • От AlexBr
      Приветствую.
      Старый магазин имел ссылки с окончанием .html. Новый же окончательно переехал на ссылки без .html. Так же, в новом магазине не все ссылки со слешем в конце и нужно привести всё к одному виду со слешем в конце ссылки - 
      http://site.com.ua/345-nametovar/  http://site.com.ua/category/ ... Подскажите какой редирект нужно вставить в htaccess?
      Магазин на OcStore 2.1.0.2.1 и в данный момент используется стандартный htaccess. Включён seopro.
      Буду признателен за помощь!
    • От sobwoofer
      извините если баян, но решения так и не нашел.
      Нужно редиректить только определенную категорию, например с
      site.com/category/OLD_subcategory/product1
      site.com/category/OLD_subcategory/product2
      на
      с site.com/category/NEW_subcategory/product1
      с site.com/category/NEW_subcategory/product2
      ________ в вышеприведенном случае должна изменятся только субкатегория, все остальное остается то что ввел пользователь site.com/(.*)/subcategory/(.*)
      или с
      site.com/OLD_category/subcategory/product1
      site.com/OLD_category/subcategory/product2
      на
      с site.com/NEW_category/subcategory/product1
      с site.com/NEW_category/subcategory/product2
      ________в вышеприведенном случае должна изменятся только категория, все остальное остается то что ввел пользователь site.com/category/(.*)/(.*)
      или с
      site.com/OLD_category/OLD_subcategory/product1
      site.com/OLD_category/OLD_subcategory/product2
      на
      с site.com/NEW_category/NEW_subcategory/product1
      с site.com/NEW_category/NEW_subcategory/product2
      ________в вышеприведенном случае должна изменятся только категория и субкатегория, все остальное остается то что ввел пользователь site.com/category/subcategory/(.*)
      С опыта использования регулярок понимаю что нужно групировать ссылку по частям типа  ^(.*)/(.*)/(.*)?$
      потом уже слживать части используя переменные типа $1, $2, $3
      Но в случае с опенкартом там какая то морока с _route_= и единственный хоть как то работоспособный код получился таким:
       
      RewriteCond %{QUERY_STRING} ^_route_=category/OLD_subcategory/.*$ RewriteRule ^(/?)/(.*)?$ http ://site.com/category/NEW_category/? [R=301,L] (без пробела после http)   Разгруппировать ссылку даже способом RewriteRule ^(.*)/(.*)?$ не получилось не могу понять как тут все вообще происходит, очень много времени потратил на это, не далось. надеюсь на ваш совет спасибо
       
      p.s htaccess под спойлером
    • От Stamas
      Доброго времени, комрады! 
       
      Заметил в Яндекс Вебмастер, что основная карта сайта XML http://parcel.com.ua/index.php?route=feed/google_sitemap редиректит с помощью 301-го редиректа на http://parcel.com.ua/ru/index.php?route=feed/google_sitemap.
      Подскажи, пожалуйста, в чем может быть проблема и как ее решить.   Подскажите, пожалуйста, в чем может быть проблема и как ее решить?
  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу