Подробное описание файла конфигурации nginx.conf

Nginx Файл конфигурации разделён на четыре основных раздела: main (глобальные настройки), server (настройки хоста), upstream (настройки сервера upstream, в основном для обратного прокси-сервера и балансировки нагрузки) и location (настройки после того, как URL-адрес совпадёт с определённым location). Директивы, заданные в main, влияют на настройки во всех остальных разделах; директивы в server в основном используются для указания доменного имени виртуального хоста, IP-адреса и номера порта; директивы upstream раздела используются для настройки ряда внутренних серверов, обратного прокси-сервера и балансировки нагрузки внутренних серверов; раздел location используется для сопоставления местоположений веб-страниц (например, корневой каталог "/", "/images" и т. д.). Связь между ними: server наследует от main, location наследует от server; upstream не наследует и не наследуется другими.
nginx.conf Файл конфигурации
Ниже приведено подробное описание файла конфигурации nginx.conf (следующие параметры конфигурации часто не используются, а приведены лишь в качестве справочного материала для описания параметров конфигурации. См. общее описание версии ниже).

# определяет пользователя и группу пользователей, которых запускает Nginx пользователь www www;

1TP5 Номер процесса Tnginx, обычно равный количеству процессоров
рабочие_процессы 4;

Файл pid процесса #
#pid logs/nginx.pid;

# определяет максимальное количество дескрипторов, которые может открыть процесс:
Режим работы # и лимит подключений
Директива ## определяет максимальное количество файловых дескрипторов, открытых процессом nginx. Теоретическое значение должно быть равно максимальному количеству открытых файлов (ulimit -n), делённому на количество процессов nginx. Однако nginx распределяет запросы неравномерно, поэтому рекомендуется поддерживать это значение в соответствии со значением ulimit -n.
Это связано с тем, что nginx неравномерно распределяет запросы между процессами при планировании. Поэтому, если ввести значение 10240, то при общем количестве одновременных процессов, достигшем 30 000–40 000, число процессов может превысить 10 240, и будет возвращена ошибка 502.
worker_rlimit_nofile 65535;

события {
Модель эталонных событий #, используйте [kqueue | rtsig | epoll | /dev/poll | select | poll]; модель epoll
# — это высокопроизводительная сетевая модель ввода-вывода в ядре Linux версии 2.6 и выше. Linux рекомендует epoll. При работе во FreeBSD используйте модель kqueue.
# Дополнительные примечания:
# похож на Apache. У Nginx разные модели событий для разных операционных систем.
#A) Стандартная модель событий
#Select и poll относятся к стандартной модели событий. Если в текущей системе нет более эффективного метода, nginx выберет select или poll.
#B) Эффективная модель событий
#Kqueue: используется в FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и MacOS X. Использование kqueue в системах MacOS X с двумя процессорами может вызвать панику ядра.
#Epoll: используется в ядре Linux версии 2.6 и более поздних.
# /dev/poll: используется в Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ и Tru64 UNIX 5.1A+.
#Eventport: используется в Solaris 10. Для предотвращения сбоев ядра необходимо установить исправления безопасности.
использовать epoll

# Максимальное количество подключений на процесс (максимальное количество подключений = количество подключений + количество процессов)
# настраивается в соответствии с аппаратным обеспечением и используется совместно с предыдущим рабочим процессом. Он должен быть максимально большим, но не должен нагружать процессор до 100%.
рабочие_соединения 1024;

#keepalive timeout
keepalive_timeout 60;

Размер буфера заголовка запроса клиента #. Его можно настроить в соответствии с размером страницы вашей системы. Как правило, размер заголовка запроса не превышает 1 КБ. Однако, поскольку большинство системных страниц имеют размер более 1 КБ, здесь он задаётся равным размеру страницы.
Размер страницы # можно получить с помощью команды getconf PAGESIZE.
#[root@web001 ~]# getconf PAGESIZE
# Однако существуют случаи, когда client_header_buffer_size превышает 4 КБ, но значение client_header_buffer_size должно быть установлено равным целому числу, кратному «размеру системной подкачки».
client_header_buffer_size 4k;

Параметр # определяет кэш открытых файлов. По умолчанию он отключен. Параметр max определяет количество кэшей, которое рекомендуется согласовывать с количеством открытых файлов. Параметр inactive определяет время, по истечении которого кэш удаляется, если файл не запрашивается.
open_file_cache max=65535 неактивно=60с;

# определяет частоту проверки достоверности кэшированной информации.
# Синтаксис: open_file_cache_valid time Значение по умолчанию: open_file_cache_valid 60 Используется в: http, server, location Эта директива указывает, когда следует проверять действительность кэшированных элементов в open_file_cache.
open_file_cache_valid 80s;

Минимальное количество использований файла в течение периода неактивности, заданного в директиве #open_file_cache. При превышении этого значения дескриптор файла всегда открывается в кэше. Как и в примере выше, если файл не используется ни разу в течение периода неактивности, он будет удалён.
# Синтаксис: open_file_cache_min_uses number Значение по умолчанию: open_file_cache_min_uses 1 Контекст: http, server, location Эта директива определяет минимальное количество файлов, которые могут быть использованы в течение определённого периода времени, когда директива open_file_cache недоступна. При использовании большего значения файловый дескриптор всегда будет открыт в кэше.
open_file_cache_min_uses 1;

# Синтаксис: open_file_cache_errors on | off По умолчанию: open_file_cache_errors off Контекст: http, сервер, местоположение Эта директива указывает, следует ли регистрировать ошибки кэша при поиске файла.
open_file_cache_errors вкл.;
}

# устанавливает HTTP-сервер и использует его функцию обратного прокси-сервера для обеспечения балансировки нагрузки.
http{
Таблица сопоставления расширений и типов файлов #
включить mime.types;

Тип файла по умолчанию #
default_type application/octet-stream;

Кодировка по умолчанию #
кодировка utf-8;

Размер хэш-таблицы имени сервера #
Хеш-таблица, используемая для хранения имён серверов в #, управляется директивами server_names_hash_max_size и server_names_hash_bucket_size. Параметр размера хеш-корзины всегда равен размеру хеш-таблицы и кратен размеру кэша процессора. Это сокращает количество обращений к памяти, позволяя ускорить поиск ключей в хеш-таблице на процессоре. Если размер хеш-корзины равен размеру кэша процессора, то в худшем случае количество обращений к памяти при поиске ключа равно двум. Первый — определение адреса блока хранения, а второй — поиск значения ключа в блоке хранения. Поэтому, если Nginx указывает на необходимость увеличения максимального размера хеш-корзины или размера хеш-корзины, первым делом следует увеличить первый параметр.
server_names_hash_bucket_size 128;

Размер буфера для заголовков клиентских запросов #. Его можно задать на основе размера страницы вашей системы. Обычно заголовок запроса не превышает 1 КБ, но поскольку большинство системных страниц имеют размер больше 1 КБ, он устанавливается равным размеру страницы. Размер страницы можно получить с помощью команды getconf PAGESIZE.
client_header_buffer_size 32k;

Размер буфера заголовка клиентского запроса #. По умолчанию nginx использует буфер client_header_buffer_size для чтения значения заголовка. Если заголовок слишком большой, он будет использовать для его чтения буфер large_client_header_buffers.
large_client_header_buffers 4 64k;

# устанавливает размер файлов, загружаемых через nginx
клиентский_макс_размер_тела 8м;

sendfile включен; # включает режим эффективной передачи файлов. Директива sendfile определяет, должен ли Nginx вызывать функцию sendfile для вывода файлов. Установите значение «on» для обычных приложений. Для приложений с высокой нагрузкой на диск, таких как загрузка данных, установите значение «off», чтобы сбалансировать скорость обработки дискового и сетевого ввода-вывода и снизить нагрузку на систему. Примечание: Если изображения отображаются некорректно, измените значение на «off».
Директива #sendfile определяет, вызывает ли Nginx функцию sendfile (режим нулевого копирования) для вывода файлов. Для общих приложений эта директива должна быть включена. Для приложений с интенсивным дисковым вводом-выводом, таких как загрузки, эту директиву можно отключить, чтобы сбалансировать скорость обработки дискового и сетевого ввода-вывода и сократить время безотказной работы системы.
sendfile включен;

# открывает доступ к списку каталогов, подходящий для загрузки серверов, и закрыт по умолчанию.
автоиндексация включена;

# Этот параметр включает или отключает использование параметра TCP_CORK для socke. Этот параметр применяется только при использовании sendfile.
tcp_nopush вкл;

tcp_nodelay включен;

# длительное время ожидания соединения, в секундах
keepalive_timeout 120;

Параметры, связанные с TP5TFastCGI, предназначены для повышения производительности веб-сайта: снижения потребления ресурсов и увеличения скорости доступа. Следующие параметры не требуют пояснений.
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;

Настройки модуля #gzip
gzip включен; # включает сжатый gzip вывод
gzip_min_length 1k; минимальный размер сжатого файла #
gzip_buffers 4 16k; буфер сжатия #
gzip_http_version 1.0; версия сжатия # (по умолчанию 1.1, используйте 1.0, если фронтенд — Squid 2.5)
gzip_comp_level 2; уровень сжатия #
gzip_types text/plain application/x-javascript text/css application/xml; тип сжатия #, textml уже включен по умолчанию, поэтому нет необходимости писать его ниже. Если вы напишете его, проблем не возникнет, но появится предупреждение.
gzip_vary включен;

# необходимо использовать при ограничении количества IP-подключений.
#limit_zone краулер $binary_remote_addr 10m;

Конфигурация балансировки нагрузки #
вверх по течению piao.jd.com {

Балансировка нагрузки # на уровне восходящего потока, вес — это вес, который можно определить на основе конфигурации машины. Параметр «вес» представляет собой вес. Чем выше вес, тем выше вероятность назначения.
сервер 192.168.80.121:80 вес=3;
сервер 192.168.80.122:80 вес=2;
сервер 192.168.80.123:80 вес=3;

#nginx upstream в настоящее время поддерживает 4 типа распространения
#1, опрос (по умолчанию)
# Каждый запрос назначается отдельному бэкенд-серверу в хронологическом порядке. Если бэкенд-сервер недоступен, он может быть автоматически отключён.
#2, вес
# определяет вероятность опроса. Вес пропорционален коэффициенту доступа и используется при неравномерной производительности внутреннего сервера.
# Например:
#upstream bakend {
# сервер 192.168.0.14 вес=10;
# сервер 192.168.0.15 вес=10;
#}
#2, ip_хэш
# Каждый запрос назначается в соответствии с результатом хэширования IP-адреса доступа, так что каждый посетитель получает доступ к фиксированному внутреннему серверу, что может решить проблему сеанса.
# Например:
#upstream bakend {
# ip_хэш;
# сервер 192.168.0.14:88;
# сервер 192.168.0.15:80;
#}
#3, справедливый (третья сторона)
# распределяет запросы на основе времени ответа внутреннего сервера, причем приоритет отдается запросам с более коротким временем ответа.
#восходящий бэкэнд {
# сервер сервер1;
# сервер сервер2;
# справедливо;
#}
#4, url_hash (сторонний)
# распределяет запросы на основе результата хеширования URL-адреса, к которому был получен доступ, направляя каждый URL-адрес на один и тот же сервер. Это более эффективно, если сервер кэшируется.
Пример #: добавление хеш-выражения в upstream. Другие параметры, такие как вес, не могут быть записаны в серверное выражение. hash_method — используемый алгоритм хеширования.
#восходящий бэкэнд {
# сервер squid1:3128;
# сервер squid2:3128;
# хэш $request_uri;
# hash_method crc32;
#}

#советы:
# восходящий шлюз {# определяет IP-адрес и статус устройства балансировки нагрузки} {
# ip_хэш;
Сервер # 127.0.0.1:9090 отключен;
# сервер 127.0.0.1:8080 вес=2;
# сервер 127.0.0.1:6060;
# сервер 127.0.0.1:7070 резервный;
#}
# Добавить proxy_pass http://bakend/ на сервер, которому необходимо использовать балансировку нагрузки;

# Статус каждого устройства устанавливается следующим образом:
#1.down означает, что сервер перед заказом временно не участвует в загрузке.
#2.weight: Чем больше вес, тем больше вес груза.
#3.max_fails: допустимое количество неудачных запросов по умолчанию — 1. При превышении максимального количества возвращается ошибка, определяемая модулем proxy_next_upstream.
#4.fail_timeout: Время паузы после max_fails сбоев.
#5.backup: Когда все остальные машины, не являющиеся резервными, отключены или заняты, запрашивается резервная машина. Таким образом, нагрузка на эту машину минимальна.

#nginx поддерживает настройку нескольких групп балансировки нагрузки одновременно для использования неиспользуемыми серверами.
#client_body_in_file_only имеет значение On, чтобы записывать данные, отправленные клиентом, в файл для отладки.
#client_body_temp_path задаёт каталог для файла записи. Можно задать до трёх уровней каталогов.
#location соответствует URL. Может перенаправлять или выполнять новую балансировку нагрузки прокси-сервера.
}

Конфигурация виртуального хоста #
сервер {
Порт прослушивания #
слушать 80;

Может быть несколько доменных имен #, разделенных пробелами.
имя_сервера www.jd.com jd.com;
Имя файла записи по умолчанию #
индекс index.html index.htm index.php;
корень /data/www/jd;

# выполняет балансировку нагрузки на ******
местоположение ~ .*.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
включить fastcgi.conf;
}

Настройка времени кэширования изображений #
местоположение ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
{
истекает 10 дн.;
}

#JS и настройки времени кэширования CSS
местоположение ~ .*.(js|css)?$
{
истекает через 1 час;
}

Настройка формата журнала #
#$remote_addr и $http_x_forwarded_for используются для записи IP-адреса клиента;
#$remote_user: используется для записи имени пользователя клиента;
#$time_local: используется для записи времени доступа и часового пояса;
#$request: используется для записи запрошенного URL и протокола http;
#$status: используется для записи статуса запроса; успех — 200,
#$body_bytes_sent: записывает размер тела файла, отправленного клиенту;
#$http_referer: используется для записи ссылки на страницу, с которой произошел визит;
#$http_user_agent: записывает соответствующую информацию клиентского браузера;
# Обычно веб-сервер находится за обратным прокси-сервером, поэтому он не может получить IP-адрес клиента. IP-адрес, полученный через $remote_add, — это IP-адрес обратного прокси-сервера. Обратный прокси-сервер может добавлять информацию x_forwarded_for в HTTP-заголовок пересылаемого запроса, чтобы записать IP-адрес исходного клиента и адрес сервера, из которого был отправлен запрос.
log_format доступ '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';

# определяет журнал доступа этого виртуального хоста
access_log /usr/local/nginx/logs/host.access.log main;
access_log /usr/local/nginx/logs/host.access.404.log log404;

# включает обратный прокси-сервер для «/connect-controller»
местоположение /connect-controller {
proxy_pass http://127.0.0.1:88; # Обратите внимание, что номер порта здесь не может совпадать с номером порта, прослушиваемого виртуальным хостом (то есть портом, прослушиваемым сервером).
proxy_redirect выключен;
proxy_set_header X-Real-IP $remote_addr;

Внутренний веб-сервер # может получить реальный IP-адрес пользователя через X-Forwarded-For.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

# Ниже приведены некоторые конфигурации обратного прокси-сервера, которые являются необязательными.
proxy_set_header Хост $host;

Максимальное количество байтов на файл, которое # позволяет клиенту запросить
клиентский_макс_размер_тела 10м;

Буферный прокси-сервер # буферизует максимальное количество байтов, запрошенных клиентом,
Если задать большее значение, например, 256 КБ, то любое изображение размером менее 256 КБ будет отображаться нормально, независимо от того, используете ли вы Firefox или Internet Explorer. Однако, если вы закомментируете эту директиву и используете значение по умолчанию client_body_buffer_size, которое вдвое превышает размер страницы операционной системы (8 КБ или 16 КБ), возникнут проблемы.
# возвращает внутреннюю ошибку сервера 500 при отправке большого изображения (около 200 КБ) независимо от того, используется ли Firefox 4.0 или IE 8.0.
client_body_buffer_size 128k;

# сообщает nginx о необходимости блокировать коды ответов HTTP 400 и выше.
proxy_intercept_errors вкл.;

# тайм-аут соединения с внутренним сервером_инициирование рукопожатия и ожидание ответа тайм-аут
Тайм-аут соединения Nginx с бэкенд-сервером (тайм-аут соединения через прокси-сервер)
proxy_connect_timeout 90;

Время передачи данных внутреннего сервера (тайм-аут отправки агента)
Время возврата данных бэкэнд-сервера # означает, что бэкэнд-сервер должен передать все данные в течение указанного времени.
proxy_send_timeout 90;

После успешного подключения время ответа внутреннего сервера (тайм-аут приема прокси)
После успешного подключения # время, необходимое для ответа внутреннего сервера, фактически равно времени, необходимому внутреннему серверу для обработки запроса.
proxy_read_timeout 90;

# устанавливает размер буфера для хранения информации о заголовках пользователей на прокси-сервере (nginx)
# задаёт размер буфера для первой части ответа, считываемой с проксируемого сервера. Обычно эта часть ответа содержит небольшой заголовок ответа. По умолчанию это значение равно размеру буфера, указанному в директиве proxy_buffers, но его можно уменьшить.
proxy_buffer_size 4k;

Буфер #proxy_buffers, средний размер веб-страницы составляет менее 32 КБ
Параметр # задаёт количество и размер буферов, используемых для чтения ответов (от проксируемого сервера). Значение по умолчанию также определяет размер страницы, который может составлять 4 КБ или 8 КБ в зависимости от операционной системы.
proxy_buffers 4 32k;

Размер буфера # при высокой нагрузке (proxy_buffers*2)
proxy_busy_buffers_size 64k;

# задает размер данных при записи в proxy_temp_path, чтобы предотвратить слишком длительную блокировку рабочего процесса при передаче файлов.
# задаёт размер папки кэша. Если он больше этого значения, он будет перенесён с вышестоящего сервера.
proxy_temp_file_write_size 64k;
}

Конфигурация обратного прокси-сервера с локальным динамическим и статическим разделением #
# Все страницы JSP обрабатываются Tomcat или Resin
местоположение ~ .(jsp|jspx|do)?$ {
proxy_set_header Хост $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8080;
}
}
}

Общий файл конфигурации Nginx (здесь представлена конфигурация nginx.conf для nginx 1.14.2 в системе Windows)
Следующий файл nginx.conf просто реализует пример nginx как обратного прокси-сервера на внешнем интерфейсе, обрабатывающего статические файлы, такие как js и png, и пересылающего динамические запросы, такие как jsp, на другие серверы (подробное объяснение соответствующих параметров конфигурации см. в пояснении выше):
рабочие_процессы 1;

#error_log logs/error.log;
#error_log logs/error.log уведомление;
#error_log logs/error.log информация;

#pid logs/nginx.pid;

события {
рабочие_соединения 1024;
}

http {
включить mime.types;
default_type application/octet-stream;

#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';

access_log журналы/access.log main;
error_log logs/ssl.error.log крит;

sendfile включен;
#tcp_nopush вкл;

#keepalive_timeout 0;
keepalive_timeout 65;

#gzip включен;

сервер {
слушай 8088;
имя_сервера localhost;

кодировка utf-8;

#access_log logs/host.access.log main;

Настройки файла записи #
расположение / {
root D:/vueWork/dentalFactory/dist; каталог файлов записи #
index index.html index.htm; # имя файла записи по умолчанию
}

Конфигурация обратного прокси-сервера Tomcat #
местоположение /название местоположения/ {
proxy_pass http://192.168.1.10:8080; # http://127.0.0.1:8080/имя сервиса (имя проекта)/
#proxy_set_header Хост $host;
proxy_set_header Host $host:$server_port; //Примечание: если номер порта текущего проекта не равен 8080, эта конфигурация обязательна, в противном случае бэкэнд не сможет получить правильный номер порта
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Конфигурация статического прокси-ресурса # (обычно настройка не требуется, вот пример настройки ресурсов изображения)
#location /images/ {
# корень D:/A-studySpace/nginxDemo;
#}

#Здесь вы можете настроить страницу 404
#error_page 404 /404.html;

# Это местоположение конфигурации страницы, соответствующее статусу запроса.
страница_ошибки 500 502 503 504 /50x.html;
местоположение = /50x.html {
корневой html;
}

Конфигурация обратного прокси-сервера # PHP
# передает все запросы PHP-страниц в PHP-FPM для обработки
#расположение ~ \.php$ {
# корневой html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; #fastcgi_param имеет много параметров конфигурации, поэтому при необходимости настройте их.
# включает fastcgi_params;
#}

}

# — другой виртуальный хост, использующий комбинацию конфигураций на основе IP-адреса, имени и порта
#
#сервер {
# слушает 8000;
# слушай имя_пользователя:8080;
# имя_сервера somename псевдоним другой.псевдоним;

Местоположение # / {
# корневой html;
# индекс index.html index.htm;
# }
#}

HTTPS-сервер #
#
#сервер {
# прослушивает 443 ssl;
# имя_сервера localhost;

# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;

# ssl_session_cache общий:SSL:1m;
# ssl_session_timeout 5m;

# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers включен;

Местоположение # / {
# корневой html;
# индекс index.html index.htm;
# }
#}

}

счет