Sorry, you have been blocked
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
What can I do to resolve this?
You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.
Cloudflare Ray ID: 7a7464fedfd677ad • Your IP: Click to reveal 88.135.219.175 • Performance & security by Cloudflare
Устранение неполадок установки и настройки Nginx
Nginx – это свободный и открытый веб-сервер, который используется для обслуживания сайтов и приложений любой сложности. Nginx известен своим низким воздействием на память, высокой масштабируемостью и модульной, управляемой событиями архитектурой, которая может обеспечить надежную и предсказуемую производительность. Nginx работает не только как веб-сервер, но и как балансировщик нагрузки, кэширующий HTTP-сервер и обратный прокси-сервер.
Конечно, сначала может быть сложно запомнить все команды и рекомендации по управлению сервером Nginx. Это руководство предназначено для тех, кто работает с Nginx. Оно охватывает некоторые основные команды управления сервисами, а также советы по диагностике и решению некоторых распространенных проблем.
Каждый раздел может использоваться независимо от других, поэтому вы можете пропустить разделы, которые вам не нужны. Все условные значения в командах выделены красным; вместо этих значений вы можете подставить свои данные.
Каждый раздел предлагает ссылки на другие руководства, с которыми можно проконсультироваться.
Примечание: Предполагается, что вы работаете с версией Nginx, установленной из репозитория по умолчанию в Debian-подобном дистрибутиве. Некоторые из команд и директив, описанных в этом руководстве, отсутствуют в других дистрибутивах или в версиях Nginx, установленных из других источников.
Установка Nginx
Обновите индекс пакетов, а затем установите Nginx:
sudo apt-get update
sudo apt-get install nginx
Проверка состояния Nginx
Чтобы проверить состояние веб-сервера на текущей машине, введите:
sudo systemctl status nginx
Автозагрузка Nginx
По умолчанию сервис Nginx запускается автоматически. Если вы хотите изменить это поведение, введите:
sudo systemctl disable nginx
Чтобы снова добавить Nginx в автозагрузку, введите:
sudo systemctl enable nginx
Управление сервисом Nginx
Чтобы остановить сервер Nginx, введите следующую команду:
sudo systemctl stop nginx
Чтобы запустить сервер Nginx, введите:
sudo systemctl start nginx
Чтобы остановить сервис и запустить его снова, введите:
sudo systemctl restart nginx
Если вы изменили конфигурацию, вы можете перезагрузить Nginx в текущей сессии. Введите следующую команду:
sudo systemctl reload nginx
Создание корневого каталога для статического контента
При создании сайтов на Nginx разработчики часто используют виртуальные хосты (или блоки server) – это хосты, которые обслуживают отдельные сайты или домены. Для этого нужно создать document root, каталог верхнего уровня, который Nginx проверяет при обслуживании контента.
Команды в приведенном ниже блоке создадут новый корневой каталог, передадут права на него пользователю sudo и изменят права доступа к каждому подкаталогу в подкаталога в /var/www/.
sudo mkdir -p /var/www/example.com/html
sudo chown -R $USER:$USER /var/www/example.com/html
find /var/www -type d -exec chmod 775 <> \;
В данном случае корневой каталог предлагает глобальные права на чтение и исполнение. Чтобы выбрать другие права доступа, замените 775 и укажите требуемые права.
Помните, что права доступа должны меняться в соответствии с ситуацией.
Создание корневого каталога для динамических файлов
Если ваш сайт использует динамические модули типа PHP-FPM, вам может понадобиться передать права на некоторые файлы группе www-data. Если группе нужно право на запись в каталоге, передайте группе права собственности на каталог.
Предложенные ниже команды создают новый document root, передают его группе www-data и изменяют права на каждый подкаталог в /var/www.
sudo mkdir -p /var/www/example.com/html
sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www -type d -exec chmod 775 <> \;
Включение и отключение конфигурационных файлов
Чтобы включить виртуальный хост, нужно создать симлинк из каталога sites-available в каталог sites-enabled, который Nginx читает во время запуска.
Для этого введите комнаду:
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
После этого нужно перезагрузить Nginx, чтобы настройки обновились.
Устранение неполадок с хэш-таблицей
Nginx использует хэш-таблицы, чтобы быстро обрабатывать статические данные (имена серверов, MIME-типы). Если вы добавили несколько имен серверов, есть вероятность, что заданного размера хэша имени сервера будет не хватать, и при внесении изменений вы увидите ошибку server_names_hash_bucket_size. Ее можно устранить, отредактировав одно значение в файле /etc/nginx/nginx.conf.
Откройте этот файл:
sudo nano /etc/nginx/nginx.conf
Найдите в файле директиву server_names_hash_bucket_size. Удалите символ #, чтобы раскомментировать строку, и увеличьте значение директивы:
http <
. . .
server_names_hash_bucket_size 64 ;
. . .
>
Это увеличит размер хэш-таблиц имен серверов Nginx и позволит сервису обрабатывать все имена серверов, которые вы добавили. Сохраните и закройте файл, а затем перезапустите Nginx, чтобы обновить настройки.
Тестирование конфигурации
Каждый раз, когда вы вносите изменения в конфигурационные файлы Nginx, обязательно выполните следующую команду, чтобы проверить наличие синтаксических ошибок:
Если в конфигурации есть ошибки, вывод команды укажет, где именно они обнаружены. Если же в конфигурационных файлах нет синтаксических ошибок, вы увидите примерно такой вывод:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Если ошибок нет, вы можете перезагрузить сервис:
sudo systemctl restart nginx
Важные файлы и каталоги Nginx
Контент
Каталог /var/www/html хранит весь контент сайта (это корневой каталог сайта). Вы можете изменить стандартные настройки Nginx и указать другие каталоги в var/www.
Конфигурация сервера
- /etc/nginx/: конфигурационный каталог Nginx (здесь хранятся все конфигурационные файлы веб-сервера).
- /etc/nginx/nginx.conf: главный конфигурационный файл веб-сервера, в котором находятся все глобальные параметры.
- /etc/nginx/sites-available/default: виртуальный хост Nginx по умолчанию. Другие виртуальные хосты также должны храниться в каталоге sites-available (но они не будут работать без симлинка в sites-enabled).
- /etc/nginx/sites-enabled/: здесь хранятся файлы включенных виртуальных хостов. При запуске или перезагрузке Nginx читает конфигурационные файлы и ссылки в этом каталоге, чтобы собрать полную конфигурацию.
- /var/log/nginx/access.log: это лог, который регистрирует все запросы Nginx (если в конфигурации веб-сервера не сказано другого).
- /var/log/nginx/error.log: это лог ошибок.
Чтобы получить доступ к логам systemd процесса Nginx, запустите эту команду:
sudo journalctl -u nginx
Заключение
Данный мануал перечислил общие процедуры по поддержке сервера Nginx. Чтобы узнать больше о работе с Nginx, ознакомьтесь со следующими руководствами:
NGINX
NGINX — программное обеспечение, написанное для UNIX-систем. Основное назначение — самостоятельный HTTP-сервер, или, как его используют чаще, фронтенд для высоконагруженных проектов. Возможно использование NGINX как почтового SMTP/IMAP/POP3-сервера, а также обратного TCP прокси-сервера.
Как используется и работает nginx
NGINX является широко используемым продуктом в мире IT, по популярности уступая лишь Apache.
Как правило, его используют либо как самостоятельный HTTP-сервер, используя в бекенде PHP-FPM, либо в связке с Apache, где NGINX используется во фронтэнде как кеширующий сервер, принимая на себя основную нагрузку, отдавая статику из кеша, обрабатывая и отфильтровывая входящие запросы от клиента и отправляя их дальше к Apache. Apache работает в бекэнде, работая уже с динамической составляющей проекта, собирая страницу для передачи её в кеш NGINX и запрашивающему её клиенту. Это если в общих чертах, чтобы понимать суть работы, так-то внутри всё сложнее.
Как проверить, установлен ли NGINX
Пишете в консоль SSH следующую команду, она покажет версию NGINX
Если видите что-то навроде
nginx version: nginx/1.10.3
Значит, всё в порядке, установлен NGINX версии 1.10.3 . Если нет, установим его.
Как установить NGINX
Если вы сидите не под root , предваряйте команды apt-get префиксом sudo , например sudo apt-get install nginx
- Обновляем порты (не обязательно)
- Установка NGINX
- Проверим, установлен ли NGINX
Команда должна показать версию сервера, что-то подобное:
nginx version: nginx/1.10.3
Где расположен nginx
Во FreeBSD NGINX располагается в /usr/local/etc/nginx .
В Ubuntu, Debian NGINX располагается тут: /etc/nginx . В ней располагается конфигурационный файл nginx.conf — основной конфигурационный файл nginx.
Чтобы добраться до него, выполняем команду в консоли
По умолчанию, файлы конфигураций конкретных сайтов располагаются в /etc/nginx/sites-enabled/
или в /etc/nginx/vhosts/
Как правильно составить правила nginx.conf
Идём изучать мануалы на официальный сайт.
Пример рабочей конфигурации NGINX в роли кеширующего проксирующего сервера с Apache в бекенде
Строка include /etc/nginx/vhosts/*; указывает на поддиректорию vhosts , в которой содержатся файлы конфигураций конкретно под каждый домен.
Пример того, что может содержаться там — example.com.conf
Ниже пример для Apache в бекенде:
А вот вариант для PHP-FPM:
NGINX WordPress Multisite
Ниже конфигурация под WordPress Multisite с сайтами в поддиректориях:
Как заблокировать по IP в NGINX
Блокировать можно с помощью директив allow и deny.
Правила обработки таковы, что поиск идёт сверху вниз. Если IP совпадает с одним из правил, поиск прекращается.
Таким образом, вы можете как забанить все IP, кроме своих, так и заблокировать определённый IP:
Приведу пример конфигурации, как можно закрыть доступ к панели администратора WordPress по IP:
Ещё один неплохой вариант. Правда, по умолчанию определяются только статичные IP. А чтобы разрешить подсеть, придётся использовать дополнительный модуль GEO:
Как в NGINX указать размер и время
- Байты указываются без суффикса. Пример:
- Килобайты указываются с суффиксом k или K . Пример:
- Мегабайты указываются с суффиксом m или M . Пример:
- Гигабайты указываются с суффиксом g или G . Пример:
Время задаётся в следующих суффиксах:
- ms — миллисекунды
- s — секунды
- m — минуты
- h — часы
- d — дни
- w — недели
- M — месяцы, 30 дней
- Y — годы, 365 дней
В одном значении можно комбинировать различные единицы, указывая их в порядке от более к менее значащим, и по желанию отделяя их пробелами. Например, 1h 30m задаёт то же время, что и 90m или 5400s . Значение без суффикса задаёт секунды.
Рекомендуется всегда указывать суффикс
Некоторые интервалы времени можно задать лишь с точностью до секунд.
Настройка отладки в NGINX
В целях отладки настройки NGINX вы можете писать данные в логи, но я советую воспользоваться директивой add_header. С её помощью вы можете выводить различные данные в http headers.
Пример, как можно определить, в каком location обрабатывается правило:
Теперь, если проверить, какие заголовки отдаёт статичный файл, например https://sheensay.ru/wp-content/uploads/2015/06/nginx.png , то вы увидите среди них и наш X-debug-message
Отладочная информация NGINX в заголовках HTTP headers
Вместо статичной строки можно выводить данные различных переменных, что очень удобно для правильной настройки сервера и поиска узких мест.
Добавление модулей NGINX в Linux (Debian/CentOS/Ubuntu)
Функционал NGINX возможно расширить с помощью модулей. С их списком и возможным функционалом можно ознакомиться на официальном сайте http://nginx.org/ru/docs/. Также, существуют интересные сторонние модули, например, модуль NGINX для защиты от DDoS
Приведу пример установки модуля ngx_headers_more.
Все команды выполняются в консоли, используйте Putty или Far Manager с NetBox/WinSCP. Установка будет происходить под Debian
В результате увидите что-то навроде
Установим дополнительные пакеты.
Если выходит ошибка aptitude: команда не найдена , нужно предварительно установить aptitude:
—add-module=
Эта проблема решается установкой libpcre++-dev :
Эта проблема решается так:
В результате должны увидеть модуль на месте
Основные ошибки nginx и их устранение
502 Bad Gateway
Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.
Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в /etc/php-fpm.d/www.conf прописаны правильные права
504 Gateway Time-out
Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если Apache, с которым NGINX работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения:
Тут мы выставили ожидание таймаута в 800 секунд.
Upstream timed out (110: Connection timed out) while reading response header from upstream
Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута
800 секунд на ожидание ответа от бекенда.
Это лишь временные меры, так как при увеличении нагрузки на сайт ошибка снова станет появляться. Устраните узкие места, оптимизируйте работу скриптов php
413 Request Entity Too Large
Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку
и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до 100Mb
Также, можно отключить проверку размера тела ответа полностью значением ноль:
Следует помнить, зачем ввели это ограничение: если любой пользователь может загружать файлы на неподготовленный сайт, можно сравнительно легко провести DDOS-атаку на него, перегружая входной поток большими файлами.
После каждого внесённого изменения в конфигурационный файл необходимо перезагружать nginx
304 Not Modified не устанавливается
Если возникает проблема с правильным отображением ответного заголовка сервера 304 Not Modified , то проблема, скорее всего, в пунктах:
- В секции server конкретного сайта включен ssi on (Подробнее в документации). По умолчанию, ssi отключен, но некоторые хостеры и ISPManager любят его прописывать в дефолтную конфигурацию сайта включенным. Его нужно обязательно отключить, закомментировав или удалив эту строку; установить в before , то есть на уровне http или конкретного server прописать: if_modified_since before;

- Консоли разработчика браузера ( F12 ) в разделе Network (Cеть) (не забываем перезагружать страницу);
- Или сторонних сервисов, например last-modified.com.
Client intended to send too large body
Решается с помощью увеличения параметра client_max_body_size
Как перезагрузить nginx
Для перезагрузки NGINX используйте restart или reload .
Команда в консоли:
Эти команды остановят и перезапустят сервер NGINX.
Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:
Проверить правильность конфигурации можно командой
В чём разница между reload и restart
Как происходит перезагрузка в NGINX:
- Команда посылается серверу
- Сервер анализирует конфигурационный файл
- Если конфигурация не содержит ошибок, новые процессы открываются с новой конфигурацией сервера, а старые плавно прекращают свою работу
- Если конфигурация содержит ошибки, то при использовании
- restart процесс перезагрузки сервера прерывается, сервер не запускается
- reload сервер откатывается назад к старой конфигурации, работа продолжается
Короче говоря, restart обрывает работу резко, reload делает это плавно.
Restart рекомендуется использовать, только когда внесены глобальные изменения, например, заменено ядро сервера, либо нужно увидеть результат внесённых изменений прямо здесь и сейчас. В остальных случаях используйте reload.Ещё лучше, если вы будете предварительно проверять правильность конфигурации командой nginx -t , например:
Как вместо 404 ошибки делать 301 редирект на главную
Как в NGINX сделать редирект на мобильную версию сайта
Данный код вставляется на уровне server в самое начало файла (не обязательно в самое начало, но главное, чтобы перед определением обработчика скриптов php, иначе редирект может не сработать).
Как в NGINX включить поддержку WebP
Чтобы включить поддержку WebP, нужно прописать в секции http :
Теперь, в секции server можно использовать:
Полезные материалы и ссылки
Настройка NGINX под WP Super Cache
Конвертер правил .htaccess (Apache) в NGINX
Весьма полезный сервис, который поможет cконвертировать правила из .htaccess в NGINX . Результат, возможно, придётся донастроить вручную, но, в целом, он весьма удобен в применении.
Вот как описывают сервис сами авторы:Сервис предназначен для перевода конфигурационного файла Apache .htaccess в инструкции конфигурационного файла nginx.
В первую очередь, сервис задумывался как переводчик инструкций mod_rewrite с htaccess на nginx. Однако, он позволяет переводить другие инструкции, которые можно и резонно перевести из Apache в nginx.
Инструкции, не относящиеся к настройке сервера (например, php_value), игнорируются.
Переводчик не проверяет правильность входящего конфига, в том числе регулярные выражения и логические ошибки.
Результат перевода следует обязательно проверить вручную, а затем разместить в секции server <> конфигурационного файла nginx.
Замечания и предложения по улучшению ждем, как обычно, на [email protected] 😉
Как узнать установлен ли NGINX на сервере
Чтобы узнать какой веб-сервер установлен у вашем хостинге, нужно посмотреть заголовки HTTP-запроса. Это можно сделать с помощью различных сервисов.
Bertal
Сервис bertal.ru предназначен для просмотра HTTP-заголовков любых веб-файлов (.html, .php, .asp, .gif, .jpg, .css и др.), кроме того, имеется возможность просматривать html-код интернет-страниц, размер которых не превышает 4 МБ. Соединение с удаленными серверами возможно по протоколам http, https и ftp.
Для проверки http-заголовка введите данные в необходимые поля формы (при необходимости воспользуйтесь расширенным режимом). Если ввести только URL сайта, то результат будет отображаться примерно как на скриншоте ниже.

Запрос данных происходит методом:
- HEAD — если запрашивается только HTTP-заголовок (функция «Показать HTML-код страницы» не используется)
- GET — если запрашивается HTTP-заголовок и тело ответа, при этом поле «POST» не заполнено (используется функция «Показать HTML-код страницы»)
- POST — если запрашивается HTTP-заголовок и тело ответа, при этом заполнено поле «POST» (используется функция «Показать HTML-код страницы» и заполнено поле «POST»)
DomainTools
Есть еще очень крутой сервис DomainTools whois.domaintools.com

Разумеется, существует много альтернативных инструментов. Здесь показан как пример решения данного вопроса.
Ну, допустим вы хотите самостоятельно установить SSL-сертификат на свой виртуальный сервер. Вы же должны точно знать какую инструкцию искать, так как команды очевидно будут разными. Зачем задавать подобные вопросы саппорту, если это можно узнать самому?