Установка и настройка NGINX на хостинге NICHOST (nic.ru). Nginx настройка на хостинге

Установка и настройка NGINX на хостинге NICHOST (nic.ru)

Posted in Хостинг by admin on May 17th, 2008

nginx [engine x] — это HTTP-сервер и почтовый прокси-сервер. (http://sysoev.ru/nginx/). Данная статейка позволяет настроить работу Nginx в качестве front-end для посетителей сайтов. Back-end’ом будет выступать Apache.

Текущая версия скрипта:

Немного автоматизировал установку данного сервера на хостинге от nic.ru

1) Cоздаем папку nginx для первоначальной настройки:

mkdir nginx

2) Скачиваем архив со скриптом формирования nginx.conf:

wget

Распаковываем архив

tar -xf nginx_script.tar.gz

3) Запускаем формирование конфигурационного файла:

./configure firstEnter User name: LOGINEnter User IP: ВАШ_IPEnter User site: domain.ru

Если у Ва на хостинге находить только один сайта то следующий пункт пропускаем.

4) Добавляем сайты в конфигурационный файл:

./configure secondEnter User name: LOGINEnter User IP: ВАШ_IPEnter User site: domain2.ru

И так по каждому сайту.

5) Создаем скрипт запуска nginx:

./configure startEnter User name: LOGIN

6) Теперь необходимо скопировать файл nginx в ~/etc/rc.d/

cp nginx ~/etc/rc.d/

И nginx.conf в ~/etc/:

cp nginx.conf ~/etc/

7) Переводим веб сервер и сайты в ручной режим и меняем порт 80 на 8080 в настройках.

Для сайтов меняем строку в /home/LOGIN/sitename/conf/virtual.conf.manual c

Для веб сервера меняем строчки в файле /home/LOGIN/etc/httpd.conf.manual с:

MaxClients 63 на MaxClients 31

Listen ВАШ_IP:80 на Listen ВАШ_IP:8080

NameVirtualHost ВАШ_IP:8080 на NameVirtualHost ВАШ_IP:80808) Перезапускаем Apache

killall httpd; ~/etc/rc.d/httpd

9) Создаём папку /var/tmp/nginx

Запускаем nginx: ~/etc/rc.d/nginx

Радуемся….

poul.udovenko.net

Настройка Nginx для хостинга | Токарчук Андрей

Настройка nginx для хостинга

// Март 20th, 2011 // Highload, Memcached, PHP, Веб-разработка

В последнее время замечаю большой интерес к nginx, и организации веб-сервера на его основе.UP 20.11.2011Если раньше строили двухзвенную систему (фронтэнд — Nginx, бекэнд — Apache), то сейчас постепенно переходят только на Nginx, полностью отказываясь от Apache. Для таких случаев можно использовать следующий конфиг:

# PHP-FPM (backend) upstream php-fpm { server 127.0.0.1:9000; } # Сервера кэширования upstream memcaches { server 127.0.0.1:11211; } # Конфиг Nginx (frontend) server { # Защита от бага http://forum.nginx.org/read.php?2,154025,154036 server_name_in_redirect off; # Порт, принимаемые HOST и путь к сайту listen 80; server_name site1.ru *.site1.ru site2.ru *.site2.ru; set $www_folder '/home/webuser'; set $root_path '$www_folder/$host/html'; root $root_path; index index.htm index.html index.php; # Запросы непосредственно .php-файлов, например index.php (не кэшируются) location ~ \.php$ { include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME $root_path/$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT $root_path; # этот параметр нужен несмотря на root в секции server fastcgi_pass php-fpm; } # Копия предыдущего для internal переадресации location @phpscripts { include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME $root_path/$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT $root_path; # этот параметр нужен несмотря на root в секции server fastcgi_pass php-fpm; } # Запросы отдельных php-файлов (кэшируются) location /utils { default_type text/html; root $root_path; set $memcached_key 'nginx_$host$uri?$args'; memcached_pass memcaches; error_page 404 502 504 405 = @phpscripts; } # Остальные запросы также идут на PHP-FPM, если $uri не существует (через memcache) location / { default_type text/html; root $root_path; if (!-e $request_filename) { return 404; } error_page 404 502 504 403 405 = @php; } # Веб-приложение location @php { include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME $root_path/index.php; fastcgi_pass php-fpm; } # Переопеределение 502 ошибки error_page 502 = /502.htm; location = /502.htm { root $www_folder; } # Для js, css, swf, ico и т.д. location ~* \.(css|js|swf|ico|png|jpg|gif|jpeg)$ { root $root_path; access_log off; expires 30d; } # Защита от просмотра .htaccess и .htpasswd файлов location ~ /\.ht { deny all; } # Защита от просмотра svn-файлов location ~ /.svn/ { deny all; } # Статус запросы (/status) и пинг(/ping) запросы от системы мониторинга location ~ ^/(status|ping)$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $fastcgi_script_name; allow 127.0.0.1; deny all; } }

Если будут вопросы, пишите в комментах.

Спасибо!

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

tokarchuk.ru

Настройка Nginx · Установка JetCalc на облачном хостинге

По умолчанию скрипт install.sh выполняет установку для локального сервера localhost. Чтобы включить удаленный доступ к серверу, необходимо внести некоторые изменения в конфигурационные файлы веб-сервера Nginx, управляющие системой JetCalc.

Для настройки Nginx необходимо войти на сервер, запустить Midnight Commander, перейти в каталог /etc/nginx/sites-available и открыть для редактирования файл jetcalc.conf. В этом файле необходимо изменить только первые строки, необходимые для замены локального сервера localhost на удаленный сервер mysite.ru и подключения SSL-сертификата, ранее размещенного в каталоге /ssl.

а) исходный вариант файла jetcalc.conf:

server { listen 80; server_name localhost; client_max_body_size 100m; gzip on; ... }

б) отредактированный вариант файла jetcalc.conf:

server { listen 443 ssl default_server; server_name www.mysite.ru mysite.ru; client_max_body_size 100m; ssl on; ssl_certificate ssl/mysity_ru.crt; ssl_certificate_key ssl/mysite_ru.key; gzip on; ... }

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

nginx -s reload

Теперь при вводе в строку браузера адреса https://www.mysite.ru откроется окно входа в JetCalc. Но чтобы всякий раз не вводить перед названием сайта https://, что означает работу по зашифрованному каналу связи, необходимо настроить переадресацию открытого протокола http на протокол httsp. Для этого в ранее настраиваемом файле jetcalc.conf необходимо добавить следующие инструкции:

server { listen 80; server_name www.mysite.ru mysite.ru; return 301 https://www.mysite.ru$request_uri; } server { listen 443 ssl default_server; server_name www.mysite.ru mysite.ru; client_max_body_size 100m; ssl on; ssl_certificate ssl/mysite_ru.crt; ssl_certificate_key ssl/mysite_ru.key; gzip on; ... }

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

nginx -s reload

При вызове команды nginx -s reload может выйти сообщение:

nginx: [emerg] could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32

Для исправления ситуации необходимо в файле /etc/nginx/nginx.conf найти и снять комментарий (удалить символ #) у следующего параметра:

server_names_hash_bucket_size 64;

После сделанных изменений следующая команда должна отработать без ошибок:

nginx -s reload

leossnet.gitbooks.io

Настройка nginx / Хабр

Тема правильной настройки nginx очень велика, и, боюсь, в рамки одной статьи на хабре никак не помещается. В этом тексте я постарался рассказать про общую структуру конфига, более интересные мелочи и частности, возможно, будут позже. :)

Неплохой начальной точкой для настройки nginx является конфиг, который идёт в комплекте с дистрибутивом, но очень многие возможности этого сервера в нём даже не упоминаются. Значительно более подробный пример есть на сайте Игоря Сысоева: sysoev.ru/nginx/docs/example.html. Однако, давайте лучше попробуем собрать с нуля свой конфиг, с бриджем и поэтессами. :) Начнём с общих настроек. Сначала укажем пользователя, от имени которого будет работать nginx (от рута работать плохо, все знают :) )

user nobody; Теперь скажем nginx-у, какое количество рабочих процессов породить. Обычно, хорошим выбором бывает число процессов, равное числу процессорных ядер в вашем сервере, но с этой настройкой имеет смысл поэкспериментировать. Если ожидается высокая нагрузка на жёсткий диск, можно сделать по процессу на каждый физический жёсткий диск, поскольку вся работа будет всё-равно ограничена его производительностью.

worker_processes 2; Уточним, куда писать логи ошибок. Потом, для отдельных виртуальных серверов, этот параметр можно переопределить, так что в этот лог будут сыпаться только «глобальные» ошибки, например, связанные со стартом сервера.

error_log /spool/logs/nginx/nginx.error_log notice; # уровень уведомлений "notice", конечно, можно менять Теперь идёт очень интересная секция «events». В ней можно задать максимальное количество соединений, которые одновременно будет обрабатывать один процесс-воркер, и метод, который будет использоваться для получения асинхронных уведомлений о событиях в ОС. Конечно же, можно выбрать только те методы, которые доступны на вашей ОС и были включены при компиляции.

Эти параметры могут оказать значительное влияние на производительность вашего сервера. Их надо подбирать индивидуально, в зависимости от ОС и железа. Я могу привести только несколько общих правил.

Модули работы с событиями: — select и poll обычно медленнее и довольно сильно нагружают процессор, зато доступны практически везде, и работают практически всегда; — kqueue и epoll — более эффективны, но доступны только во FreeBSD и Linux 2.6, соответственно; — rtsig — довольно эффективный метод, и поддерживается даже очень старыми линуксами, но может вызывать проблемы при большом числе подключений; — /dev/poll — насколько мне известно, работает в несколько более экзотических системах, типа соляриса, и в нём довольно эффективен;

Параметр worker_connections: — Общее максимальное количество обслуживаемых клиентов будет равно worker_processes * worker_connections; — Иногда могут сработать в положительную сторону даже самые экстремальные значения, вроде 128 процессов, по 128 коннектов на процесс, или 1 процесса, но с параметром worker_connections=16384. В последнем случае, впрочем, скорее всего понадобится тюнить ОС.

events { worker_connections 2048; use kqueue; # У нас BSD :) } Следующая секция — самая большая, и содержит самое интересное. Это описание виртуальных серверов, и некоторых параметров, общих для них всех. Я опущу стандартные настройки, которые есть в каждом конфиге, типа путей к логам.

http { # Весь код ниже будет внутри этой секции %) # ... } Внутри этой секции могут находиться несколько довольно интересных параметров.

Системный вызов sendfile появился в Linux относительно недавно. Он позволяет отправить данные в сеть, минуя этап их копирования в адресное пространство приложения. Во многих случаях это существенно повышает производительность сервера, так что параметр sendfile лучше всегда включать.

sendfile on; Параметр keepalive_timeout отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Обдумайте, как именно на вашем сайте посылаются запросы, и исправьте этот параметр. Для сайтов, активно использующих AJAX, соединение лучше держать подольше, для статических страничек, которые пользователи будут долго читать, соединение лучше разрывать пораньше. Учтите, что поддерживая неактивное keepalive-соединение, вы занимаете коннекшн, который мог бы использоваться по-другому. :)

keepalive_timeout 15; Отдельно стоит выделить настройки проксирования nginx. Чаще всего, nginx используется именно как сервер-прокси, соответственно они имеют довольно большое значение. В частности, размер буфера для проксируемых запросов имеет смысл устанавливать не менее, чем ожидаемый размер ответа от сервера-бэкенда. При медленных (или, наоборот, очень быстрых) бэкендах, имеет смысл изменить таймауты ожидания ответа от бэкенда. Помните, чем больше эти таймауты, тем дольше будут ждать ответа ваши пользователе, при тормозах бэкенда.

proxy_buffers 8 64k; proxy_intercept_errors on; proxy_connect_timeout 1s; proxy_read_timeout 3s; proxy_send_timeout 3s; Небольшой трюк. В случае, если nginx обслуживает более чем один виртуальный хост, имеет смысл создать «виртуальный хост по-умолчанию», который будет обрабатывать запросы в тех случаях, когда сервер не сможет найти другой альтернативы по заголовку Host в запросе клиента.

# default virtual host server { listen 80 default; server_name localhost; deny all; } Далее может следовать одна (или несколько) секций «server». В каждой из них описывается виртуальный хост (чаще всего, name-based). Для владельцев множества сайтов на одном хостинге, или для хостеров здесь может быть что-то, типа директивы

include /spool/users/nginx/*.conf; Остальные, скорее всего опишут свой виртуальный хост прямо в основном конфиге.

server { listen 80;

# Обратите внимание, в директиве server_name можно указать несколько имён одновременно. server_name myserver.ru myserver.com; access_log /spool/logs/nginx/myserver.access_log timed; error_log /spool/logs/nginx/myserver.error_log warn; # ... Установим кодировку для отдачи по-умолчанию.

charset utf-8; И скажем, что мы не хотим принимать от клиентов запросы, длиной более чем 1 мегабайт.

client_max_body_size 1m; Включим для сервера SSI и попросим для SSI-переменных резервировать не более 1 килобайта.

ssi on; ssi_value_length 1024; И, наконец, опишем два локейшна, один из которых будет вести на бэкенд, к апачу, запущенному на порту 9999, а второй отдавать статические картинки с локальной файловой системы. Для двух локейшнов это малоосмысленно, но для большего их числа имеет смысл также сразу определить переменную, в которой будет храниться корневой каталог сервера, и потом использовать её в описаниях локаций.

set $www_root "/data/myserver/root";

location / { proxy_pass 127.0.0.1:9999; proxy_set_header X-Real-IP $remote_addr; proxy_intercept_errors off; proxy_read_timeout 5s; # Обратите внимание, здесь мы переопределили глобальную настройку, заданную выше proxy_send_timeout 3s; # ... Отдельный блок в корневом локейшне посвящён компрессии получаемого результата в gzip. Это позволит вам, и вашим пользователям сэкономить на трафике. Nginx можно указать, какие типы файлов (или, в нашем случае, ответов от бэкенда) стоит сжимать, и каким должен быть минимальный размер файла для того, чтобы использовать сжатие.

# ... gzip on; gzip_min_length 1024; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain application/xml; }

location /i/ { root $www_root/static/; } } Всем спасибо за внимание. И, сорри, что пост получился довольно длинным.

habr.com

Руководство для начинающих

В этом руководстве даётся начальное введение в nginx и описываются некоторые простые задачи, которые могут быть решены с его помощью. Предполагается, что nginx уже установлен на компьютере читателя. Если нет, см. Установка nginx. В этом руководстве описывается, как запустить и остановить nginx и перезагрузить его конфигурацию, объясняется, как устроен конфигурационный файл, и описывается, как настроить nginx для раздачи статического содержимого, как настроить прокси-сервер на nginx, и как связать nginx с приложением FastCGI.

У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).

Как работают nginx и его модули, определяется в конфигурационном файле. По умолчанию, конфигурационный файл называется nginx.conf и расположен в каталоге /usr/local/nginx/conf, /etc/nginx или /usr/local/etc/nginx.

Запуск, остановка, перезагрузка конфигурации

Чтобы запустить nginx, нужно выполнить исполняемый файл. Когда nginx запущен, им можно управлять, вызывая исполняемый файл с параметром -s. Используйте следующий синтаксис:

nginx -s сигнал

Где сигнал может быть одним из нижеследующих:

stop — быстрое завершение
quit — плавное завершение
reload — перезагрузка конфигурационного файла
reopen — переоткрытие лог-файлов

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

nginx -s quit Команда должна быть выполнена под тем же пользователем, под которым был запущен nginx.

Изменения, сделанные в конфигурационном файле, не будут применены, пока команда перезагрузить конфигурацию не будет вручную отправлена nginx’у или он не будет перезапущен. Для перезагрузки конфигурации выполните:

nginx -s reload

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

Посылать сигналы процессам nginx можно также средствами Unix, такими как утилита kill. В этом случае сигнал отправляется напрямую процессу с данным ID. ID главного процесса nginx записывается по умолчанию в файл nginx.pid в каталоге /usr/local/nginx/logs или /var/run. Например, если ID главного процесса равен 1628, для отправки сигнала QUIT, который приведёт к плавному завершению nginx, нужно выполнить:

kill -s QUIT 1628

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

ps -ax | grep nginx

Дополнительную информацию об отправке сигналов процессам nginx можно найти в Управление nginx.

Структура конфигурационного файла

nginx состоит из модулей, которые настраиваются директивами, указанными в конфигурационном файле. Директивы делятся на простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и оканчивается точкой с запятой (;). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ({ и }). Если у блочной директивы внутри фигурных скобок можно задавать другие директивы, то она называется контекстом (примеры: events, http, server и location).

Директивы, помещённые в конфигурационном файле вне любого контекста, считаются находящимися в контексте main. Директивы events и http располагаются в контексте main, server — в http, а location — в server.

Часть строки после символа # считается комментарием.

Раздача статического содержимого

Одна из важных задач конфигурации nginx — раздача файлов, таких как изображения или статические HTML-страницы. Рассмотрим пример, в котором в зависимости от запроса файлы будут раздаваться из разных локальных каталогов: /data/www, который содержит HTML-файлы, и /data/images, содержащий файлы с изображениями. Для этого потребуется отредактировать конфигурационный файл и настроить блок server внутри блока http с двумя блоками location.

Во-первых, создайте каталог /data/www и положите в него файл index.html с любым текстовым содержанием, а также создайте каталог /data/images и положите в него несколько файлов с изображениями.

Далее, откройте конфигурационный файл. Конфигурационный файл по умолчанию уже включает в себя несколько примеров блока server, большей частью закомментированных. Для нашей текущей задачи лучше закомментировать все такие блоки и добавить новый блок server:

http { server { } }

В общем случае конфигурационный файл может содержать несколько блоков server, различаемых по портам, на которых они слушают, и по имени сервера. Определив, какой server будет обрабатывать запрос, nginx сравнивает URI, указанный в заголовке запроса, с параметрами директив location, определённых внутри блока server.

В блок server добавьте блок location следующего вида:

location / { root /data/www; }

Этот блок location задаёт “/” в качестве префикса, который сравнивается с URI из запроса. Для подходящих запросов добавлением URI к пути, указанному в директиве root, то есть, в данном случае, к /data/www, получается путь к запрашиваемому файлу в локальной файловой системе. Если есть совпадение с несколькими блоками location, nginx выбирает блок с самым длинным префиксом. В блоке location выше указан самый короткий префикс, длины один, и поэтому этот блок будет использован, только если не будет совпадения ни с одним из остальных блоков location.

Далее, добавьте второй блок location:

location /images/ { root /data; }

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

Итоговая конфигурация блока server должна выглядеть следующим образом:

server { location / { root /data/www; } location /images/ { root /data; } }

Это уже работающая конфигурация сервера, слушающего на стандартном порту 80 и доступного на локальном компьютере по адресу http://localhost/. В ответ на запросы, URI которых начинаются с /images/, сервер будет отправлять файлы из каталога /data/images. Например, на запрос http://localhost/images/example.png nginx отправит в ответ файл /data/images/example.png. Если же этот файл не существует, nginx отправит ответ, указывающий на ошибку 404. Запросы, URI которых не начинаются на /images/, будут отображены на каталог /data/www. Например, в результате запроса http://localhost/some/example.html в ответ будет отправлен файл /data/www/some/example.html.

Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал reload главному процессу nginx, выполнив:

nginx -s reload В случае если что-то работает не как ожидалось, можно попытаться выяснить причину с помощью файлов access.log и error.log из каталога /usr/local/nginx/logs или /var/log/nginx.

Настройка простого прокси-сервера

Одним из частых применений nginx является использование его в качестве прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их на проксируемые сервера, получает ответы от них и отправляет их клиенту.

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

Во-первых, создайте проксируемый сервер, добавив ещё один блок server в конфигурационный файл nginx со следующим содержимым:

server { listen 8080; root /data/up1; location / { } }

Это будет простой сервер, слушающий на порту 8080 (ранее директива listen не указывалась, потому что использовался стандартный порт 80) и отображающий все запросы на каталог /data/up1 в локальной файловой системе. Создайте этот каталог и положите в него файл index.html. Обратите внимание, что директива root помещена в контекст server. Такая директива root будет использована, когда директива location, выбранная для выполнения запроса, не содержит собственной директивы root.

Далее, используйте конфигурацию сервера из предыдущего раздела и видоизмените её, превратив в конфигурацию прокси-сервера. В первый блок location добавьте директиву proxy_pass, указав протокол, имя и порт проксируемого сервера в качестве параметра (в нашем случае это http://localhost:8080):

server { location / { proxy_pass http://localhost:8080; } location /images/ { root /data; } }

Мы изменим второй блок location, который на данный момент отображает запросы с префиксом /images/ на файлы из каталога /data/images так, чтобы он подходил для запросов изображений с типичными расширениями файлов. Изменённый блок location выглядит следующим образом:

location ~ \.(gif|jpg|png)$ { root /data/images; }

Параметром является регулярное выражение, дающее совпадение со всеми URI, оканчивающимися на .gif, .jpg или .png. Регулярному выражению должен предшествовать символ ~. Соответствующие запросы будут отображены на каталог /data/images.

Когда nginx выбирает блок location, который будет обслуживать запрос, то вначале он проверяет директивы location, задающие префиксы, запоминая location с самым длинным подходящим префиксом, а затем проверяет регулярные выражения. Если есть совпадение с регулярным выражением, nginx выбирает соответствующий location, в противном случае берётся запомненный ранее location.

Итоговая конфигурация прокси-сервера выглядит следующим образом:

server { location / { proxy_pass http://localhost:8080/; } location ~ \.(gif|jpg|png)$ { root /data/images; } }

Этот сервер будет фильтровать запросы, оканчивающиеся на .gif, .jpg или .png, и отображать их на каталог /data/images (добавлением URI к параметру директивы root) и перенаправлять все остальные запросы на проксируемый сервер, сконфигурированный выше.

Чтобы применить новую конфигурацию, отправьте сигнал reload nginx’у, как описывалось в предыдущих разделах.

Существует множество других директив для дальнейшей настройки прокси-соединения.

Настройка проксирования FastCGI

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

Базовая конфигурация nginx для работы с проксируемым FastCGI-сервером включает в себя использование директивы fastcgi_pass вместо директивы proxy_pass, и директив fastcgi_param для настройки параметров, передаваемых FastCGI-серверу. Представьте, что FastCGI-сервер доступен по адресу localhost:9000. Взяв за основу конфигурацию прокси-сервера из предыдущего раздела, замените директиву proxy_pass на директиву fastcgi_pass и измените параметр на localhost:9000. В PHP параметр SCRIPT_FILENAME используется для определения имени скрипта, а в параметре QUERY_STRING передаются параметры запроса. Получится следующая конфигурация:

server { location / { fastcgi_pass localhost:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; } location ~ \.(gif|jpg|png)$ { root /data/images; } }

Таким образом будет настроен сервер, который будет перенаправлять все запросы, кроме запросов статических изображений, на проксируемый сервер, работающий по адресу localhost:9000, по протоколу FastCGI.

nginx.org

Настройка редиректа с помощью Nginx на VPS

Чтобы сделать редирект с помощью nginx, необходимо изменить файл конфигурации nginx.conf.

Если у вас настроены виртуальные хосты, файл конфигурации для каждого хоста нужно редактировать отдельно.

Редирект добавляется в секцию server в конфигурационном файле. Пример редиректа на https: Редиректы на nginx

Редирект с http на https-протокол

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

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

Редирект с https на http-протокол

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

server { #... server_name yourdomain.ru www.yourdomain.ru; return 301 http://$server_name$request_uri; #... }

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

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

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

server { #... if ($host ~* ^[^.]+\.[^.]+$) { rewrite ^(.*)$ $scheme://www.$host$1 permanent; } #... }

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

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

server { #... if ( $request_filename ~ oldpage.html/ ) { rewrite ^ newpage.html permanent;} #... }

Где oldpage.html — имя страницы с которой будет происходить редирект, а newpage.html имя страницы, на которую будет осуществляться редирект.

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

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

Где oldfolder — имя старой папки, а newfolder — имя новой папки

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

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

server { #... rewrite ^ $scheme://www.new-yourdomain.ru; #... }

Где www.new-yourdomain.ru — домен, куда будет осуществляться редирект.

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

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

Редирект на страницу со слешем в конце URL

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

Перезагрузите Nginx

После внесения изменений в файл конфигурации для домена необходимо перезапустить nginx. Для перезапуска выполните следующую команду: service nginx restart

Проверить корректность конфигурационного файла можно с помощью команды: nginx -t

www.reg.ru