nginx редирект без слеша на со слешем

Примеры редиректов в NGINX

В данной инструкции мы рассмотрим, в большей степени, перенаправления запросов на другие страницы с помощью NGINX. Также мы немного разберем проксирование и перенаправление на другие файлы.

Настройка перенаправлений

Настройки необходимо вносить в файлах конфигураций виртуальных доменов. В Linux на основе RPM (CentOS, Red Hat), как правило, они расположены в директории /etc/nginx/conf.d/. В Linux на основе Deb (Ubuntu, Debian) — в директории /etc/nginx/sites-enabled/. Во FreeBSD все в одном файле — /usr/local/etc/nginx/nginx.conf.

Саму настройку на перенаправление в NGINX можно прописать несколькими способами.

* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:

* где коды могут использоваться любые, но чаще всего — 301, 302, 404.

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

После внесения изменений, необходимо проверить их корректность:

И для их применения перезапустить веб-сервер:

systemctl restart nginx

service nginx restart

* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.

Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.

С 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 для определенных ссылок, например:

/page.html) <
return 301 https://$host$request_uri;
>
>

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

С одного домена на другой

server <
.
server_name domain1.ru;
return 302 http://domain2.ru$request_uri;
>

C домена без www на домен с www

server <
.
server_name domain.ru;
return 301 http://www.$host$request_uri;
>

С www на без www

Все домены, которые обслуживает nginx:

C index.php на / (корень)

Данная настройка позволит перевести все запросы с /index.php на корневой адрес /:

server <
.
if ($request_uri

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

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

server <
listen 80 default_server;
return 302 https://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, необходимо указывать в настройках пути к сертификатам.

С IP-адреса на домен

В данном случае мы переводим все запросы по IP-адресу на конкретный домен:

server <
listen 80;
server_name 192.168.1.15;
return 301 http://site.ru$request_uri;
>

* при отправке http-запроса на сервер 192.168.1.15 по IP-адресу, он будет переведен на домен site.ru.

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

server <
.
server_name domain domain.*;
return 301 https://$host$request_uri;
>

На другой файл

Это скорее не перенаправление, а алиас или rewrite. Позволяет по запросу одного из файлов, отдать другой:

server <
.
location = /robots.txt <
rewrite ^/robots.txt$ /robots2.txt;
>
>

* в данном примере по запросу robots.txt, сервер отдаст содержимое robots2.txt.

Часть url на другой сервер

Перенаправить запрос на другой сервер при обращении по url page1:

server <
.
server_name domain1.ru;
location

* в данном примере для всех запросов, начинающихся на /page1/. будет работать перенаправление на другой домен domain2.ru.

Редирект со слешем

1. Убрать слеш в конце url

2. Добавить слеш в конце url

Удаляем расширение

Для перенаправления запроса, где в URL есть полное название файла скрипта (с расширением) используем конфигурацию:

server <
.
if ($request_uri

* в данном случае все запросы, которые заканчиваются на .php или .html, будут перенаправляться на страницы без данных расширений.

Для примера, запрос http://site-example.ru/page.php будет переведен на http://site-example.ru/page.

На другую страницу

Нам может понадобиться перенаправлять запросы с одной страницы сайта на другую. Приведем примеры, как это сделать с помощью return и rewrite.

а) с помощью rewrite:

server <
.
rewrite ^/page1$ /page2 permanent;
>

б) с помощью return:

server <
.
location = /page1 <
return 301 /page2;
>
>

Удалить часть URL

Иногда нужно удалять часть url. Это можно сделать следующими способами:

server <
.
rewrite /deleted-url/(.*) /$1 permanent;
>

server <
.
if ($request_uri

* в данном примере из url мы удалим deleted-url/.

Перенаправить запрос в случае обращения к несуществующим файлам

Перевод запросов, если файла не существует

Данное действие не является редиректом, но близко по смыслу — NGINX проверяет наличие файла скрипта, к которому идет обращение, и если его нет, переводит запрос на другой файл. Как правило, это используется для того, чтобы перевести все обращения на файл index.php.

* в данном примере мы скажем веб-серверу все запросы обрабатывать с помощью файла index.php в корневой директории.

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

Проксирование, в отличие от редиректа, не передает инструкции браузеру перейти на другой url — NGINX сам выполняет http-запрос по другому адресу и возвращает готовый ответ. Эта возможность может применяться для внутреннего распределения серверных ресурсов.

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

1. На другой сервер

Пример внутреннего перенаправления http-запроса на другой веб-сервер:

* в данном случае, принимать запросы от браузера и отвечать на них будет NGINX, а сама обработка будет выполняться на сервере с IP-адресом 192.168.0.15 на порту 8080.

Использование NGINX в качестве http-прокси:

* в данном примере запросы на 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 на другой сервер

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

3. На другой сайт

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

* в данном случае мы при обращении к нашему серверу (до доменному имени dmosk.local) будем попадать на сайт https://www.dmosk.ru. Обратите внимание, что в proxy_set_header мы передаем хосту его имя — в противном случае, как правило, другой сервер вернет ошибку. Также мы не указываем proxy_redirect, иначе, nginx будет переводить запросы на реальный сайт (отправлять инструкции браузеру перейти на него), а не тот, что мы используем за http-прокси.

4. На другой сайт по части URL

Если нам нужно настроить проксирование на другой сайт при обращении к определенной странице сайта, настраиваем NGINX так:

* в данном примере, если мы перейдем на страницу www.dmosk.ru/page, то мы попадем на сайт www.site.ru.

5. Редиректы при проксировании

Если при проксировании хост возвращает инструкцию браузеру для выполнения редиректа, обозреватель может сменить адрес сайта. Это особенно не удобно, когда проксирование мы выполняем на другой сайт. Чтобы отловить редиректы и заменить их своими значениями, мы должны воспользоваться опцией proxy_redirect. Рассмотрим ее применение для предыдущего примера, когда мы проксировали запрос на сайт www.dmosk.ru:

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

Немного о 301 и 302

В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.

301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и то же. Таким образом, результаты ранжирования необходимо сохранить для новой страницы.

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

Источник

Nginx, 301 на все случаи жизни

В статье описано несколько примеров 301-го редиректа для Nginx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если у вас есть вопросы или предложения по улучшению кода описанного в статье пишите в комментариях.
Я всегда открыт к конструктивному диалогу

Источник

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

Руководство по настройке перенаправлений с помощью конфигурационных файлов Apache и Nginx

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

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

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

Nginx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Полезные редиректы в nginx

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

Правила нужно прописывать в файле с описанием конфигурации конкретного хоста. У меня установлена панель VestaCP. Все файлы конфигурации расположены по адресу /home/admin/conf/web/ваш_домен.ru.nginx.conf (без ssl); /home/admin/conf/web/ваш_домен.ru.nginx.ssl.conf (с ssl).

Если же Вы устанавливали nginx сами, то путь до директории с настройками для сайтов будет /etc/nginx/site-enabled/ваш_сайт.conf

Саму настройку на перенаправление в NGINX можно прописать двумя способами.

Где коды могут использоваться любые, но чаще всего — 301, 302, 404.

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

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

Или, если вам повезло также как и мне и конфигурационные файлы для ssl и без ssl — разные, то в файле для без ssl можно прописать прямой редирект:

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

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

Убираем слеш в конце

Убираем index.php в конце адреса

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

Чтобы сохранить параметры в адресной строке, нужно задать:

Редирект для конкретной страницы

Обычный редирект в htaccess имеет вид:

В nginx примет вид:

Также, редирект конкретного файла можно сделать так:

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

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

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

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

Сложный анализ ЧПУ

Пример из сети по обработке api-запросов:

Пока не приходилось сталкиваться, но, может быть, кому-то будет полезным!

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

Для этого, в основном конфигурационном файле пишем:

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

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

Редирект на особенную страницу по 404-му статусу

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

По этой логике можно определять любые конструкции, которые вам нужны. Сначала сервер попробует выполнить файл, и, если он не будет найден, он переместится в часть @missing. А второй блок, с @missing, перенаправит на нужную страницу.

Использование вложенных if

В полном виде конструкция проверки примет вид:

Сложное условие и проксирование запросов

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

Пояснения:

Условие RewriteCond обозначает совпадение с которым будет выполнено правило RewriteRule. При этом, используются символы:
. – Точка — это любой символ (но только один!).
^ — Эта метка означает начала строки.
$ — Эта метка означает конец строки.
\ — Эта экранирующий слэш, позволяет считать следующий за ним символ, обычным символом.
() – Этот символ обозначает группировку.
! – Метка отрицания.
+ — Этот символ повторяется от 1 до 65536 раз.
? — Этот символ повторяется 0 или 1 раз.
* — А этот символ повторяется от 0 до 65536 раз.
Флаги определяют дополнительные опции.
R — (redirect) — По умолчанию останавливает процесс преобразования, возвращает результат в браузер клиента, как редирект на данную страницу 302, MOVED TEMPORARY. Например флагу можно указать другой код результата, R=301 и он возвратит редирект клиенту с кодом 301 MOVED PERMANENTLY.
NC — (nocase) — Этот флаг отключает проверку регистра символов.
L — (last) — Флаг останавливает процесс преобразования, текущая ссылка считается окончательной.

Чтобы изменения вступили в силу — не забудьде произвести рестарт nginx. Но для начала — проверьте, что ваша конфигурация в порядке. Для этого выполните команду:

Если выдаст «OK» — делаем смело перезагрузку:

Первый вариант — для устаревших систем Linux или FreeBSD. Второй — для новых систем Linux

Если же показывает ошибку — разбираемся с ней.

Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.

Отличия между 301 и 302 редиректами:

В чем принципиальная разница между ответом с кодом 301 и 302? Для обычного посетителя сайта разницы нет. А вот для поискового робота разница огромная.

301-й редирект говорит о склеивании страниц. Это означает для поисковика то, что старая и новая страницы — это одно и тоже. Таким образом результаты ранжирования необходимо сохранить для новой страницы.

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

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

Если есть вопросы, то пишем в комментариях.

Также можете помочь проекту, заранее всем СПАСИБО.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Правильный redirect 301 для SEO в Nginx

Хочу сегодня рассмотреть тему редиректов в Nginx. Я обычно настраиваю их в лоб. То есть нужен какой-то редирект, я его добавляю. На днях меня попросили СЕО специалисты переработать редиректы одного проекта и сделать так, чтобы для клиента был ровно один 301 редирект, который включает в себя сразу все необходимые преобразования url.

Пример двойного редиректа

Для того, чтобы было понятно, о чем идет речь, приведу пример. Допустим, у вас настроен редирект с http на https и добавление к урлу в конце слеш. То есть вы хотите такое преобразование:

Допустим, у вас сначала был настроен редирект на https подобным образом:

А потом вас попросили добавить редирект всех урлов без слеша на тот же урл только со слешем на конце. Вы идете в секцию c listen 443 и добавляете редирект.

В целом все нормально, редиректы работают. Но если перейти по ссылке http://site.ru/catalog, мы получим 2 301-х редиректа.

На выходе у вас 2 редиректа вместо одного, что плохо для СЕО. Надо по возможности все реализовать в одном. В данном случае напрашивается простое и очевидное решение:

Вроде бы все нормально. Теперь редирект будет автоматически добавлять слеш в конец запроса. Но проблемы начнутся со ссылками на медиа файлы. Например, запрос http://site.ru/catalog/img.png будет превращаться в https://site.ru/catalog/img.png/, что нам совершенно не нужно. Чтобы это исправить, надо сделать так.

Теперь все будет нормально, так как location со статикой указан в виде регулярного выражения. В случае попадания запроса в указанное правило, будет выполнен редирект без слеша. Все остальное попадет в следующий префиксный location /. То же самое можно сделать с помощью if и одного location, но c if работать будет медленнее. Там где можно обходиться без if, лучше его не использовать.

Пример с nginx rewrite

Обращаю внимание на то, что сделано. Я использую rewrite без какого-либо флага на конце, чтобы не прекращать обработку директив. В данном случае просто меняется uri и передается дальше. Если запрос приходит со слешом на конце, мы его обрезаем и отправляем в правило редиректа на https. Если слеша нет, то он сразу на редирект уходит. Теперь все в порядке.

Встроенные редиректы WordPress

Очевидно, что выше описана простая ситуация. На нее достаточно обратить внимание и исправить. Но не всегда бывает так просто. Например, вы сами не настраивали редирект урлов без слеша на урлы со слешом, он вам не нужен. Но, к примеру, WordPress реализует подобный редирект своими средствами. В итоге, при запросе http://site.ru/catalog вы получите такую картину с редиректами.

Сначала nginx сделал редирект на https, так как вы это настроили у него в конфигурации, а потом wordpress на страницу со слешом на конце. В итоге у вас два редиректа, а надо один. Причем, два редиректа получились не по вашей воле. Если не обратите на это внимание, так и будете с ними жить. По факту, все типовые редиректы лучше сразу реализовывать в одном месте в веб сервере.

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

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

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

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

Корректный редирект с одного url на другой

Допустим вы корректно настроили стандартные редиректы в nginx. А потом в какой-то момент у вас поменялась структура сайта, или просто нужно было сделать редиректы для отдельных страниц. К примеру, запрос https://site.ru/main/hello/ перенаправить в https://site.ru/main/. По идее ничего сложного. Добавляем редирект:

Опять два 301-х редиректа. Переделываем на один, не забывая все возможные варианты написания.

Ну и так далее. Думаю, идея ясна. Следует следить за всеми редиректами и стараться всегда оставлять только один.

Заключение

Я прилично заморочился с темой редиректов в nginx. Раньше никогда не обращал на них пристального внимания. Да и у других не видел акцента на этом. В интернете полно готовых вариантов перенаправлений на все случаи жизни, но рассмотрены они в отдельности. А вот так комплексно взглянуть на полный конфиг со всеми нюансами не приходилось.

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

В завершении рекомендую мою статью про настройку nginx. Я там частично рассматриваю и эту тему. А вообще там рассказаны все основные моменты, на которые стоит обращать внимание при работе с nginx.

Источник