301 редирект nginx – Nginx как сделать перенаправление для определенных uri, возвращающих 404? — Хабр Q&A | Дропшиппинг

Содержание

Nginx редиректы с примерами

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.devreadwrite.com;
    rewrite ^ https://www.devreadwrite.com$request_uri? permanent;
}

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

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

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

server {
    listen  80;
    server_name www.devreadwrite.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.devreadwrite.com;
    rewrite ^/(.*)$ http://devreadwrite.com/$1 permanent;
}

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

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

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

server {
    listen  80;
    server_name www.devreadvrite.com;
    #...
}

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

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

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

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

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

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

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

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

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

Nginx, 301 редирект с каждой страницы одного домена на такой же URL адрес другого домена
Если вы планируете изменить свой домен или изменить название предприятия, то перенаправление домена является единственным лучшим решением для сохранения пользователей и перевода их запросов на новый домен.

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

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

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

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

#Убрать / на конце страницы

location ~ .+/$ {
rewrite (.+)/$ $1 permanent;
}

####Редиректы со страниц с index.php

if ($request_uri ~* "^(.*/)index\.php$") {
        return 301 $1;
    }

####Редиректы со страниц //

merge_slashes off;
# replace merge_slashes' behavior with "redirect_slashes"
location ~* "//" {
	rewrite ^(.*)//(.*)$ $1/$2;
	rewrite ^ $uri permanent;
}

Настройка редиректа в Apache и Nginx

HTTP-перенаправление (или URL редирект) — Это переадресация одного домена или адреса на другой. Существует множество вариантов применения перенаправления.

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

Для перенаправления трафика Nginx использует несколько инструментов.

Nginx

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

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

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

server {  
     listen  80;
     server_name  www.domain.ru;
     rewrite ^ http://domain.ru$request_uri? permanent; 
}

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

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

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

service nginx restart

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

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

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

server {  
     listen  80;
     server_name  domain.ru;
     rewrite ^ http://www.domain.ru$request_uri? permanent; 
}

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

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

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

service nginx restart

Редирект 301 с https на http

Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для https(443 порт), вторая для http(80 порт).

Секция server для открытия по https(443 порт) и настройки редиректа:

server {  
   listen  443;
   server_name  www.domain.ru;
   rewrite ^ http://www.domain.ru$request_uri? permanent; 
}

Секция server, для открытия по http(80 порт), где находятся основные настройки домена.

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

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

service nginx restart

Редирект 301 с http на https

Для Nginx нужно создать две секции server в конфигурационный файл, одна для http(80 порт), вторая для https(443 порт).

Для нового домена в конфигурациоонм файле nginx
Секция server, для открытия по http(80 порт) и настройки перенаправления:

server {  
    listen  IP сервера:80;
    server_name  www.domain.ru;
    rewrite ^ https://www.domain.ru$request_uri? permanent; 
}

Секция server, для открытия по https(443 порт), где находятся основные настройки домена.

server {  
    listen  IP сервера:443;
    server_name www.domain.ru;
.....
}

Для существующего домена в конф. файле nginx

Если вы вносите изменения в существующую секцию конф. файла nginx делайте это так: Из основной секции домена удалите строку вида

     listen  IP сервера:80;

И создайте новую секцию server такого вида:

server {  
    listen  IP сервера:80;
    server_name  www.domain.ru;
    rewrite ^ https://www.domain.ru$request_uri? permanent; 
}

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

service nginx restart

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

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

или

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

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

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

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

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

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

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

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

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

Убрать / на конце страницы

location ~ .+/$ {  
rewrite (.+)/$ $1 permanent;  
}

Редиректы со страниц с index.php

if ($request_uri ~* "^(.*/)index\.php$") {  
        return 301 $1;
    }

Редиректы со страниц //

merge_slashes off;  
# replace merge_slashes' behavior with "redirect_slashes"
location ~* "//" {  
    rewrite ^(.*)//(.*)$ $1/$2;
    rewrite ^ $uri permanent;
}

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

service nginx restart

Как правильно настроить 301 редирект в Nginx при редизайне сайта? — Хабр Q&A

Задача
Есть старый сайт — mysite.ru (главное зеркало), другие зеркала:
а) mysite.com — физически сайта на домене нет, нужен для «закрытия» домена в зоне .com;
б) версии с www.
В результате редизайна и косяка в продакшн попал новый сайт — new.mysite.ru
Требуется склеить старый и новый сайты.
Структуру старого сайта не сохраняем. То есть изменяться будет только server_name

Решение:
Размещаем все файлы нового сайта в папке старого сайта. Имеем два идентичных сайта. Для склейки делаем 301 редирект с нового сайта на старый.
Нашла рекомендацию https://toster.ru/q/443666(дана более года назад) — создаём отдельный блок server под каждый домен/поддомен (см. ниже).
1. Рекомендация актуальна? В документации по Nginx версии с www и без обычно расположены в одном блоке server, а тут всё по разным блокам разложено. Порядок блоков server в данном случае имеет значение?

2. Это и есть постраничный редирект? Читала, что для реализации такого редиректа нужно составить список редиректов (с какой страницы одного сайта на какую страницу другого сайта идёт переадресация). Как это реализуется и в каких случаях?
3. Если бы домены были с разными протоколами (http/https), нужно было бы это учитывать или не имеет значения (при редиректе указан явно протокол цели)?

Вариант «Все домены в одном блоке»
server {
listen 443 ssl;
root /somepath;
server_name mysite.ru www.mysite.ru mysite.com www.mysite.com new.mysite.ru www.new.mysite.ru;
index index.html;

error_page 404 /ErrorPages/404.html;
try_files $uri $uri/ =404;
}

server {
listen 80;
server_name mysite.ru www.mysite.ru mysite.com www.mysite.com new.mysite.ru www.new.mysite.ru;
return 301 https://$server_name$request_uri;

}

Вариант «по рекомендации»
server {
server_name new.mysite.ru;
return 301 https://mysite.ru$request_uri;
}

server {
server_name www.new.mysite.ru;
return 301 https://mysite.ru$request_uri;
}

server {
server_name mysite.com;
return 301 https://mysite.ru$request_uri;
}

server {
server_name www.mysite.com;
return 301 https://mysite.ru$request_uri;
}

server {
server_name www.mysite.ru;
return 301 https://mysite.ru$request_uri;
}

server {
listen 443 ssl;
root /somepath;
server_name mysite.ru;
index index.html;

error_page 404 /ErrorPages/404.html;
try_files $uri $uri/ =404;
}

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

Nginx redirect (на https, с www на без www, 301 редирект)

В Nginx версий до 0.9.1 переадресация (301 редирект) может задаваться следующим образом:

server {

listen 80;
server_name example.com;

rewrite ^ http://example-site.com$request_uri;
}

В современных версиях веб-сервера, согласно официальной документации в Nginx redirect нужно настраивать используя return с указанием кода HTTP ответа (301 или 302)

server {
listen 80;
server_name example.com;
return 301 http://$host$request_uri;
}

В примере приведен пример настройки переадресации все запросов к страницам одного сайта на страницы другого сайта.

server {
listen 80;
server_name www.example.com;
return 301 http://example.com$request_uri;
}

Nginx редирект на https

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

или

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

В последнем случае редирект будет отрабатывать для www.example.com и example.com, все запросы будут направляться на имя без www, доступную по https.

Если переадресация нужна только для example.com без www, то www.example.com можно указать в качестве server_name в отдельной специально созданной секции конфигурационного файла

server {
listen 80;
server_name www.example.com;
…
}

Также часто возникает необходимость переадресовывать запросы ко всем доменам в конфигах на один, сделать это можно задав две секции server и директиву default_server, под которую будут попадать все имена сайтов кроме заданных непосредственно (example.com и www.example.com в примере).

server {
listen 80;
server_name example.com www.example.com;
…
}

server {
listen 80 default_server;
server_name _;
return 301 http://example.com$request_uri;
}

Если на сервере используется конфигурация Nginx + Apache, Nginx + Unicorn или подобная редирект всегда настраивается для того пакета, который первым обрабатывает запрос принимая его непосредственно от пользователя

netstat -nltp | grep 80

Для большинства конфигураций в выводе будет именно рассматриваемый веб-сервер — если это так, переадресацию нужно настраивать для него.

Nginx редирект с любого набора сайта на https://www.site.ru с кодами 200, 301? — Хабр Q&A

С кодом 200 — это не редирект.
Редирект обычно с кодом 301, 302.

При «перманентном» редиректе сначала у Вас страница отдает код 301 и указывает новый адрес. А потом уже новая страница открывается и, если все нормально, то отдает код 200.

Вот пример, как http://site.ru/что_угодно и http://www.site.ru/что_угодно перенаправить с кодом 301 на https://www.site.ru/что_угодно
Для https://site.ru делается аналогично. (Прописывается конфиг в отдельном блоке «server».)

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

		location / {		
			rewrite ^(.*)$ https://www.site.ru$1 permanent;
		}	
	}

Если Вам не нужно сохранять путь после домена при редиректе, то можно воспользоваться еще более короткой конструкцией

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

Я не понимаю, зачем Вам 307 редирект. И тем более не понимаю, зачем делать двойной редирект 307=>301=> итп. В этом нет никакого смысла, в том числе SEO. И если кто-то так сделал, в том числе и крупный ресурс, то это не означает, что нужно это копировать. Двойной редирект только увеличивает время отклика страницы.
В целях SEO используется 301 редирект. Поисковики отлично с ним работают и «склеивают» адреса.

Ниже описание 307 редиректа из википедии. Для Вашего примера такой редирект разве нужен?

307 Temporary Redirect — запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

Вы пишите:

Браузер запоминает, что используется https:// и в случае захода на сайте по незащищенному соединению, он осуществляет внутренний переход с кодом 307 на https://.

На самом деле браузер запоминает не это. Некоторые браузеры запоминают 301 редирект. Это означает, что если страница «A» ссылается на страницу «B» через 301 редирект, то при повторном наборе в браузере адреса «A», браузер сразу грузит адрес «B» без предварительного обращения к «A». То, что в Вашем примере «A» и «B» имеют один и тот же разный адрес, который отличается только протоколом http/https, — это лишь частный случай. Браузеры могли бы точно также запомнить редирект _http//site1.eu/page1 на _https//site2.biz/page2

Редирект с http на https Nginx

Как и большая часть сайтов интернета, которые следуют современным тенденциям losst.ru использует безопасный протокол связи https. Многим сайтам при переходе на https необходимо, чтобы весь трафик, который приходит на порт http автоматически перенаправлялся на https.

Это необходимо из соображений SEO оптимизации, а также безопасности пользователей, чтобы никто не мог разорвать защищенное соединение. В этой статье мы рассмотрим как настроить редирект с http на https Nginx.

Редирект с http на https Nginx

Я предполагаю, что вы будете использовать постоянное перенаправление с кодом статуса 301. Это означает перемещение на постоянной основе. Такой метод используется чтобы сообщить поисковым системам или браузеру, что текущая ссылка была обновлена, и ее стоит обновить в своей базе, например, закладок браузера.

В конфигурационном файле Nginx должно быть две секции server, для сайта на https и сайта http. В секции http вы просто перенаправляете все запросы на https c помощью инструкции return, а во второй секции уже все обрабатываете. Например, первая секция:

server { server_name losst.ru www.losst.ru; charset off; index index.php; ssi on; return 301 https://$host:443$request_uri; set $root_path /var/www/losst/data/www/losst.ru; root $root_path; listen :80 default_server; ... }

Вторая секция уже с обработкой SSL слушает запросы на 443 порту:

server { server_name losst.ru www.losst.ru; ssl on; ssl_certificate "/var/www/losst/losst.ru_le2.crtca"; ssl_certificate_key "/var/www/losst/losst.ru_le2.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;"; charset off; index index.php; set $root_path /var/www/losst/data/www/losst.ru;

 root $root_path;
listen :443 default_server;
...
}

Собственно, синтаксис тут очень прост, инструкция return позволяет возвращать необходимые коды ответа сервера. Здесь же мы возвращаем код 301, постоянный редирект, а также URL, на который собираемся перенаправить пользователя. Кроме директивы return, можно использовать инструкцию rewrite, с помощью нее выполняются точно те же действия:

rewrite ^/(.*)$ https://losst.com/$1 permanent;

Это обычный синтаксис регулярных выражений. В первом аргументе мы выделяем группу строки запроса, а во второй указываем правильный домен. Ее можно добавить вместо return 301. Также можно использовать такую конструкцию без отдельного блока server:

if ($host ~* ^(losst\.ru|www\.losst\.ru)$ ){ rewrite ^/(.*)$ https://losst.ru/$1 permanent; }

Теперь осталось протестировать то, что получилось. Сохраните файл и проверьте конфигурацию nginx:

sudo nginx -t

Затем, если все хорошо, перезапустите Nginx:

sudo systemctl restart nginx

Далее можно проверить какой ответ сервера вы получите с помощью curl:

curl -I losst.ru

Или позволим утилите проследовать полный путь по перенаправлению:

curl ILa losst.ru

Выводы

Настроить редирект на https nginx достаточно просто, фактически, все выполняется добавлением одной строки в конфигурационный файл, все остальное — дополнительные параметры. Редирект с https на http nginx будет выполняться так же. Только нужно будет изменить несколько букв в параметрах retrun. Не забывайте проверять правильно ли настроены редиректы с www и на https, это играет очень важную роль для SEO. Надеюсь, эта информация была полезной для вас.

Полезные сниппеты для Nginx конфигов / Habr

Доброго времени суток, уважаемые хабравчане! В Elasticweb мы негласно ратуем за Nginx и, наверное, мы одни из немногих хостингов, которые не поддерживают Apache и .htaccess соответственно. В связи с этим, большое количество обращений в тех. поддержку связано с оказанием помощи в написании конфигурационного файла для Nginx. Поэтому мы решили собрать коллекцию полезных сниппетов и коллекцию готовых Nging конфигов для наиболее популярных CMS/CMF/Фреймворков на PHP.

Готовые конфиги:

Команды Nginx

Основные команды для выполнения базовых операций во время работы Nginx.

nginx -V — проверить версию Nginx, его скомпилированные параметры конфигурации и установленные модули.
nginx -t — протестировать конфигурационный файл и проверить его расположение.
nginx -s reload — перезапустить конфигурационный файл без перезагрузки Nginx.

Location блок на PHP

Простой шаблон для быстрой и легкой установки PHP, FPM или CGI на ваш сайт.

location ~ \.php$ {
  try_files $uri =404;
  client_max_body_size 64m;
  client_body_buffer_size 128k;
  include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_pass unix:/path/to/php.sock;
}

Rewrite и Redirection

Force www

Корректный способ определить удаленный сервер по домену без www и перенаправить его c www:

server {
    listen 80;
    server_name example.org;
    return 301 $scheme://www.example.org$request_uri;
}

server {
    listen 80;
    server_name www.example.org;
    ...
}

Также работает для HTTPS.

Force no-www

Корректный способ определить удаленный сервер по домену c www и перенаправить его без www:

server {
    listen 80;
    server_name example.org;
}

server {
    listen 80;
    server_name www.example.org;
    return 301 $scheme://example.org$request_uri;
}

Force HTTPS

Способ для переадресации с HTTP на HTTPS:

server {
    listen 80;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;

    # let the browsers know that we only accept HTTPS
    add_header Strict-Transport-Security max-age=2592000;

    ...
}

Force Trailing Slash

Данная строка добавляет слэш / в конце каждого URL, только в том случаее если в URL нет точки или параметров. Тоесть после example.com/index.php или example.com/do?some=123 слэш не поставится.

rewrite ^([^.\?]*[^/])$ $1/ permanent;

Редирект на страницу

server {
    location = /oldpage.html {
        return 301 http://example.org/newpage.html;
    }
}

Редирект на сайт

server {
    server_name old-site.com
    return 301 $scheme://new-site.com$request_uri;
}

Редирект на определенный путь в URI

location /old-site {
    rewrite ^/old-site/(.*) http://example.org/new-site/$1 permanent;
}

Производительность

Кэширование

Навсегда разрешить браузерам кэшировать статические содержимое. Nginx установит оба заголовка: Expires и Cache-Control.

location /static {
    root /data;
    expires max;
}

Запретить кэширование браузерам (например для отслеживания запросов) можно следующим образом:

location = /empty.gif {
    empty_gif;
    expires -1;
}

Gzip сжатие

gzip  on;
gzip_buffers 16 8k;
gzip_comp_level 6;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
gzip_types
    text/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xml
    text/javascript application/javascript application/x-javascript
    text/x-json application/json application/x-web-app-manifest+json
    text/css text/plain text/x-component
    font/opentype application/x-font-ttf application/vnd.ms-fontobject
    image/x-icon;
gzip_disable  "msie6";

Кэш файлов

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

open_file_cache max=1000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

SSL кэш

Подключение SSL кэширования позволит возобновлять SSL сессии и сократить время к следующим обращениям к SSL/TLS протоколу.

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

Поддержка Upstream

Активация кеширования c использованием Upstream подключений:

upstream backend {
    server 127.0.0.1:8080;
    keepalive 32;
}

server {
    ...
    location /api/ {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

Мониторинг

По умолчанию Stub Status модуль не собирается, его сборку необходимо разрешить с помощью конфигурационного параметра —with-http_stub_status_module и активировать с помощью:

location /status {
    stub_status on;
    access_log off;
}

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

Более информативный статус от Nginx можно получить с помощью Luameter, который несколько сложнее в установке и требует наличия Nginx Lua модуля. Это предоставит следующие метрики по различным конфигурационным группам в формате JSON:

Общее количество запросов/ответов.
Общее количество ответов сгруппирированных по статус кодам: 1xx, 2xx, 3xx, 4xx, 5xx.
Общее количество байт принятых/отправленных клиенту.
Промежуточные отрезки времени для оценки минимума, максимума, медианы, задержек и тд.
Среднестатистическое количество запросов для простоты мониторинга и составления прогнозов по нагрузке.
И прочее…

Пример дашборда от Luameter.

Также для сбора статистики отлично подходит ngxtop.

Безопасность

Активация базовой аунтификации

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

имя:пароль

Затем установить найтройки для server/location блока, который необходимо защитить:

auth_basic "This is Protected";
auth_basic_user_file /path/to/password-file;

Открыть только локальный доступ

location /local {
    allow 127.0.0.1;
    deny all;
    ...
}

Защита SSL настроек

Отключить SSLv3, если он включен по умолчанию. Это предотвратит POODLE SSL Attack.

Шифры, которые наилучшим образом обеспечат защиту. Mozilla Server Side TLS and Nginx.

# don’t use SSLv3 ref: POODLE CVE-2014-356 - http://nginx.com/blog/nginx-poodle-ssl/
ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;  

# Ciphers set to best allow protection from Beast, while providing forwarding secrecy, as defined by Mozilla (Intermediate Set) - https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers  on;

Прочее

Подзапросы после завершения

Бывают ситуации, когда вам необходимо передать запрос на другой бэкэнд в дополнении или после его обработки . Первый случай — отслеживать количество завершенных загрузок путем вызова API, после того как пользователь скачал файл. Второй случай -отслеживать запрос, к которому вы бы хотели вернуться как можно быстрее (возможно с пустым .gif) и сделать соответствующие записи в фоновом режиме. post_action, который позволяет вам определить подзапрос и будет отклонен по окончанию текущего запроса — является лучшим решением для обоих вариантов.

location = /empty.gif {
    empty_gif;
    expires -1;
    post_action @track; 
}

location @track {
    internal;
    proxy_pass http://tracking-backend;
}

Распределение ресурсов между источниками

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

location ~* .(eot|ttf|woff) { 
    add_header Access-Control-Allow-Origin *; 
}

Источники

Большое спасибо всем за внимание!

Nginx редиректы с примерами

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

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

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

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

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

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

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

#Убрать / на конце страницы

####Редиректы со страниц с index.php

####Редиректы со страниц //

Настройка редиректа в Apache и Nginx

Nginx

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

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

Редирект 301 с https на http

Редирект 301 с http на https

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

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

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

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

Редиректы со страниц с index.php

Редиректы со страниц //

Как правильно настроить 301 редирект в Nginx при редизайне сайта? — Хабр Q&A

Nginx redirect (на https, с www на без www, 301 редирект)

Nginx редирект на https

Nginx редирект с любого набора сайта на https://www.site.ru с кодами 200, 301? — Хабр Q&A

Редирект с http на https Nginx

Редирект с http на https Nginx

Выводы

Полезные сниппеты для Nginx конфигов / Habr

Готовые конфиги:

Команды Nginx

Location блок на PHP

Rewrite и Redirection

Force www

Force no-www

Force HTTPS

Force Trailing Slash

Редирект на страницу

Редирект на сайт

Редирект на определенный путь в URI

Производительность

Кэширование

Gzip сжатие

Кэш файлов

SSL кэш

Поддержка Upstream

Мониторинг

Безопасность

Активация базовой аунтификации

Открыть только локальный доступ

Защита SSL настроек

Прочее

Подзапросы после завершения

Распределение ресурсов между источниками

Источники

Добавить комментарий Отменить ответ