Как правильно сделать 301 redirect на https?

Question

[Дмитрий S]

Здравствуйте, подскажите как правильно сделать 301 редирект
С
site.ru
www.site.ru
https://site.ru
НА
https://www.site.ru

Answer 1

[Игорь Воротнёв]

Редиректы надо делать на сервере. Какой у вас сервер? Nginx, Apache?
Для апача

RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

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

UPDATE: Поскольку оказалось что у вас таки Nginx, вот конфиг для него:

# http to https
server {
       listen         80;
       listen         [::]:80;
       server_name    example.com www.example.com;
       return         301 https://www.example.com$request_uri;
}
# non-www to www via https
server {
        listen 443 ssl;
        listen [::]:443 ssl;
        ssl_certificate /etc/ssl/certs/*.domain.pem;
        ssl_certificate_key /etc/ssl/private/*.domain.pem;
        server_name example.com;
        return 301 https://www.example.com$request_uri;
}
# Main configuration
server {
        listen 443 ssl http2 default_server; # http2 нужен если вы хотите использовать HTTP/2, иначе не нужно
        listen [::]:443 ssl http2 default_server; # http2 нужен если вы хотите использовать HTTP/2, иначе не нужно
        server_name www.example.com;
        ssl_certificate /etc/ssl/certs/*.domain.pem;
        ssl_certificate_key /etc/ssl/private/*.domain.pem;
        # Остальная конфигурация
        ...
    
}

Comments

[Дмитрий S]

а через .HTACCESS нет?

[Игорь Воротнёв]

Дмитрий S: через .htaccess это и есть на уровне сервера, и это файл веб-сервера Apache. У вас он?

[Дмитрий S]

Вроде да)

[Дмитрий S]

RewriteCond %{HTTP_HOST} !localhost
RewriteCond %{HTTP_HOST} !^(.+)\.(.+)\.(.+)
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]

но не совсем работает как надо, www.site.ru - переводит на https://site.ru без www. А нужно с www

[Дмитрий S]

www.site.ru
site.ru

с протоколом http

переводит на https только без www

[Игорь Воротнёв]

Дмитрий S: Уточните)) А ответ для апача
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

[Дмитрий S]

Спасибо проверим

[Игорь Воротнёв]

Дмитрий S: Отредактируйте вопрос, уберите метку PHP и добавьте метку Apache

[Игорь Воротнёв]

Дмитрий S: И программный код метку уберите) она тоже лишняя

[Дмитрий S]

Игорь Воротнёв: Игорь у нас nginx

[Gennick's Macleo]

Если честно, то не понятно для чего нужна средняя "конструкция"?

[Игорь Воротнёв]

Gennick's Macleo, переводить все запросы example.com на www.example.com

[Gennick's Macleo]

Игорь Воротнёв, первый блок и без второго прекрасно переадресовывает на www:

return 301 https://www.example.com$request_uri;

Поэтому, ваш пример конфига нагромождён. Всё намного изящнее.

[Игорь Воротнёв]

Gennick's Macleo, первый блок работает с протоколом http на 80м порту, второй - https на 443м. Каким образом первый блок переадресует https://example.com, который через 80й порт не проходит, от слова совсем?

[Gennick's Macleo]

Игорь Воротнёв,

server {
   listen 80;
   listen [::]:80;
   server_name example.com www.example.com;
   return 301 https://www.example.com$request_uri;
}
server {
   listen 443 ssl http2;
   listen [::]:443 ssl http2;
   server_name www.example.com;
   root /var/www/example.com;
   location / {
      index index.php;
      try_files $uri $uri/ /index.php?$args;
   }
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
   ssl_certificate /../fullchain.pem;
   ssl_certificate_key /.../privkey.pem;
   ssl_dhparam /.../ssl-dhparams.pem;
...
}

[Игорь Воротнёв]

Gennick's Macleo, а где редиректы non-www на www?

[Gennick's Macleo]

Игорь Воротнёв, 301

[Игорь Воротнёв]

Gennick's Macleo,
ну я вижу, что вы коммент подредактировали (в первом блоке example.com отстутствовал у вас пару минут назад), но все же, мы по кругу возвращаемся к моему предыдущему комментарию:

первый блок работает с протоколом http на 80м порту, второй - https на 443м. Каким образом первый блок переадресует httpS://example.com, который через 80й порт не проходит, от слова совсем?

Я специально для вас выделял жирным - не увидели. Сделаю отдельный акцент - нужно переадресовывать также non-www HTTPS домен на www HTTPS домен. Первый ваш блок обрабатывает только HTTP (www и non-www). Второй ваш блок обрабатывает только www HTTPS домен. В вашем конфиге запросы на non-www HTTPS куда-то в пустоту проваливаются, их никто не слушает. Именно этот кейс закрывает дополнительный блок, который есть в моем конфиге. Именно тот блок, который вам почему-то не понравился.

[Gennick's Macleo]

Игорь Воротнёв,

ну я вижу, что вы коммент подредактировали (в первом блоке example.com отстутствовал у вас пару минут назад), но все же, мы по кругу возвращаемся к моему предыдущему комментарию

- Я привык чекать конф через -t, поэтому написанное на белом листе от руки не сразу видно. Добавлял ipv6 и т.д., хотя к сути вопроса это отношения не имеет, хотел приблизить конф к вашему для читабельности.

[Gennick's Macleo]

Игорь Воротнёв,

В вашем конфиге запросы на non-www HTTPS куда-то в пустоту проваливаются, их никто не слушает.

- Ok. Тогда так (-single):

server {
   listen 80;
   listen [::]:80;
   server_name example.com www.example.com;
   return 301 https://www.example.com$request_uri;
   listen 443 ssl http2;
   listen [::]:443 ssl http2;
   server_name www.example.com;
   root /var/www/example.com;
   location / {
      index index.php;
      try_files $uri $uri/ /index.php?$args;
   }
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
   ssl_certificate /../fullchain.pem;
   ssl_certificate_key /.../privkey.pem;
   ssl_dhparam /.../ssl-dhparams.pem;
...
}

При данном конфиге получим это:

console:~# curl -i https://example.com
HTTP/2 301
location: https://www.example.com/

console:~# curl -i example.com
HTTP/2 301
location: https://www.example.com/

console:~# curl -i www.example.com
HTTP/2 301
location: https://www.example.com/

[Игорь Воротнёв]

Gennick's Macleo, все через -t чекают, это естественно. Дело в другом - вы изначально упустили одно из главных условий задачи - редиректы с non-www на www. Ну да ладно, я же тоже что-то забываю сразу написать и добавляю позже. Это не было упреком, просто обратил внимание что код изменился.

Что касается конфига выше – так а в чем все-таки его преимущество? То, что все в одном блоке server, который тяжелее воспринимается теперь? А если, например, надо сделать чтобы запросы на 80й (www и non-www) писались в один лог, на non-www 443й в другой, а уже конечные обрабатываемые без редиректов запросы на 443й www - в третий конфиг? А если есть старые урлы (привет, SEO) на, например, non-www https, которых на новом сайте www https нету, и нужны конкретные точечные редиректы?

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

У любой оптимизации должен быть смысл и реальная польза. Если нет и того, ни другого, то это антипаттерн. В данной ситуации мне это напоминает использование "шибко умных" конструкций типа IF без фигурных скобок и в одну строчку, или более экстремальных вариантов типа легендарного:

array_key_exists($word, $wordsFound) ? $wordsFound[$word] += count($matches) : $wordsFound[$word] = count($matches);

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

ЗЫ: И все равно из вашего последнего конфига я не вижу, каким образом non-www https домен (https://example.com) обрабатывается. Либо конфиг неполный, либо Nginx с относительно недавних пор стал умнее и сам догадывает (что вряд ли). На 443м порту слушается конкретно server_name www.example.com, non-www на 443м вообще нигде не слушается. Поэтому я не понимаю как он может работать. По идее он вообще не должен никак отвечать и curl -i https://example.com должен ответить Could not resolve host.

[Gennick's Macleo]

Игорь Воротнёв,
Да, действительно, кому как, тут уже дело во вкусе. Мне сложнее работать с тремя блоками, чем с одним. Поддерживать код "одной строкой" - дебажить не удобно, но при условии, если ты знаешь, что делаешь и это работает, то минимизация это плюс, все к этому стремятся, т.к. время - самая большая ценность в наши дни огромного потока информации, даже сейчас я пишу во время деплоя cloud hub, пока есть пару минут. По поводу non-www - всё работает и никуда ничего не пропадает, ответа типа not resolve при таком конфиге вы не получите. В крайнем случае можно указать в hostname сервера данные для id хоста. Мы становимся умнее, а только после нас код.