Nginx что это за ошибка

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.

Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.

Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных удалось выяснить, какие ошибки в конфигурациях встречаются чаще всего. Эта статья прольёт свет на следующие неправильные настройки Nginx:

Отсутствует корневой каталог
Небезопасное использование переменных
Чтение необработанного ответа сервера
merge_slashes отключены

Отсутствует корневой каталог

server < root /etc/nginx; location /hello.txt < try_files $uri $uri/ =404; proxy_pass http://127.0.0.1:8080/; >>

Root-директива указывает корневую папку для Nginx. В приведённом выше примере корневая папка /etc/nginx , что означает, что мы можем получить доступ к файлам в этой папке. В приведенной выше конфигурации нет места для / (location / <. >) , только для /hello.txt . Из-за этого root-директива будет установлена глобально, а это означает, что запросы к / перенаправят вас на локальный путь /etc/nginx .

Такой простой запрос, как GET /nginx.conf , откроет содержимое файла конфигурации Nginx, хранящегося в /etc/nginx/nginx.conf. Если корень установлен в /etc , запрос GET на /nginx/nginx.conf покажет файл конфигурации. В некоторых случаях можно получить доступ к другим файлам конфигурации, журналам доступа и даже зашифрованным учётным данным для базовой аутентификации HTTP.

Из почти 50 000 файлов конфигурации Nginx, которые мы проанализировали, наиболее распространёнными корневыми путями были следующие:

Потерявшийся слеш

server < listen 80 default_server; server_name _; location /static < alias /usr/share/nginx/static/; >location /api < proxy_pass http://apiserver/v1/; >>

При неправильной настройке off-by-slash можно перейти на один шаг вверх по пути из-за отсутствующей косой черты. Orange Tsai поделился информацией об этом в своём выступлении на Blackhat «Нарушение логики парсера!». Он показал, как отсутствие завершающей косой черты в location директиве в сочетании с alias директивой позволяет читать исходный код веб-приложения. Менее известно то, что это также работает с другими директивами, такими как proxy_pass . Давайте разберёмся, что происходит и почему это работает.

location /api < proxy_pass http://apiserver/v1/; >

Если на Nginx запущена следующая конфигурация, доступная на сервере, можно предположить, что доступны только пути в http://apiserver/v1/ .

http://server/api/user -> http://apiserver/v1//user

Когда запрашивается http://server/api/user , Nginx сначала нормализует URL. Затем он проверяет, соответствует ли префикс /api URL-адресу, что он и делает в данном случае. Затем префикс удаляется из URL-адреса, поэтому остаётся путь /user. Затем этот путь добавляется к URL-адресу proxy_pass , в результате чего получается конечный URL-адрес http://apiserver/v1//user .

Обратите внимание, что в URL-адресе есть двойная косая черта, поскольку директива местоположения не заканчивается косой чертой, а путь URL-адреса proxy_pass заканчивается косой чертой. Большинство веб-серверов нормализуют http://apiserver/v1//user до http://apiserver/v1/user , что означает, что даже с этой неправильной конфигурацией всё будет работать так, как ожидалось, и это может остаться незамеченным.

Эта неправильная конфигурация может быть использована путём запроса http://server/api../ , из-за чего Nginx запросит URL-адрес http://apiserver/v1/../ , который нормализован до http://apiserver/ . Уровень вреда от такой ошибки определяется тем, чего можно достичь, если использовать эту неправильную конфигурацию. Например, это может привести к тому, что статус сервера Apache будет отображаться с URL-адресом http://server/api../server-status , или он может сделать доступными пути, которые не должны быть общедоступными.

Одним из признаков того, что сервер Nginx имеет неправильную конфигурацию, является возврат сервером одинакового же ответа при удалении косой черты в URL-адресе. То есть, если http://server/api/user и http://server/apiuser возвращают один и тот же ответ, сервер может быть уязвимым. Он позволяет отправлять следующие запросы:

http://server/api/user -> http://apiserver/v1//user http://server/apiuser -> http://apiserver/v1/user

Небезопасное использование переменных

Некоторые фреймворки, скрипты и конфигурации Nginx небезопасно используют переменные, хранящиеся в Nginx. Это может привести к таким проблемам, как XSS, обход HttpOnly-защиты, раскрытие информации и в некоторых случаях даже RCE.

SCRIPT_NAME

С такой конфигурацией, как эта:

 location ~ \.php$

основная проблема будет заключаться в том, что Nginx отправит интерпретатору PHP любой URL-адрес, заканчивающийся на .php, даже если файл не существует на диске. Это распространённая ошибка во многих конфигурациях Nginx, и об этом говорится в документе «Ловушки и распространенные ошибки», созданном Nginx.

XSS возможен, если PHP-скрипт попытается определить базовый URL на основе SCRIPT_NAME ;

 GET /index.php//index.php SCRIPT_NAME = /index.php//index.php

Использование $uri может привести к CRLF-инъекции

Другая неправильная конфигурация, связанная с переменными Nginx, заключается в использовании $uri или $document_uri вместо $request_uri .

$ur i и $document_uri содержат нормализованный URI, тогда как нормализация в Nginx включает URL-декодирование URI. В блоге Volema рассказывалось, что $uri обычно используется при создании перенаправлений в конфигурации Nginx, что приводит к внедрению CRLF.

Пример уязвимой конфигурации Nginx:

location / < return 302 https://example.com$uri; >

Символами новой строки для HTTP-запросов являются \r (возврат каретки) и \n (перевод строки). URL-кодирование символов новой строки приводит к следующему представлению символов %0d%0a . Когда эти символы включены в запрос типа http://localhost/%0d%0aDetectify:%20clrf на сервер с неправильной конфигурацией, сервер ответит новым заголовком с именем Detectify , поскольку переменная $uri содержит новые URL-декодированные строчные символы.

HTTP/1.1 302 Moved Temporarily Server: nginx/1.19.3 Content-Type: text/html Content-Length: 145 Connection: keep-alive Location: https://example.com/ Detectify: clrf

Произвольные переменные

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

Одним из способов проверки является установка значения заголовка referer:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

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

Чтение необработанного ответа сервера

С proxy_pass Nginx есть возможность перехватывать ошибки и заголовки HTTP, созданные бэкендом (серверной частью). Это очень полезно, если вы хотите скрыть внутренние сообщения об ошибках и заголовки, чтобы они обрабатывались Nginx. Nginx автоматически предоставит страницу пользовательской ошибки, если серверная часть ответит ей. А что происходит, когда Nginx не понимает, что это HTTP-ответ?

Если клиент отправляет недопустимый HTTP-запрос в Nginx, этот запрос будет перенаправлен на серверную часть как есть, и она ответит своим необработанным содержимым. Тогда Nginx не распознает недопустимый HTTP-ответ и просто отправит его клиенту. Представьте себе приложение uWSGI, подобное этому:

def application(environ, start_response): start_response('500 Error', [('Content-Type', 'text/html'),('Secret-Header','secret-info')]) return [b"Secret info, should not be visible!"]

И со следующими директивами в Nginx:

http < error_page 500 /html/error.html; proxy_intercept_errors on; proxy_hide_header Secret-Header; >

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

proxy_hide_header почти не требует пояснений; он скроет любой указанный HTTP-заголовок от клиента.

Если мы отправим обычный GET-запрос, Nginx вернёт:

HTTP/1.1 500 Internal Server Error Server: nginx/1.10.3 Content-Type: text/html Content-Length: 34 Connection: close

Но если мы отправим неверный HTTP-запрос, например:

GET /? XTTP/1.1 Host: 127.0.0.1 Connection: close

То получим такой ответ:

XTTP/1.1 500 Error Content-Type: text/html Secret-Header: secret-info Secret info, should not be visible!

merge_slashes отключены

Для директивы merge_slashes по умолчанию установлено значение «on», что является механизмом сжатия двух или более слешей в один, поэтому /// станет / . Если Nginx используется в качестве обратного прокси и проксируемое приложение уязвимо для включения локального файла, использование дополнительных слешей в запросе может оставить место для его использования. Об этом подробно рассказывают Дэнни Робинсон и Ротем Бар.

Мы нашли 33 Nginx-файла, в которых для параметра merge_slashes установлено значение «off».

Попробуйте сами

Мы создали репозиторий GitHub, где вы можете использовать Docker для настройки своего собственного уязвимого тестового сервера Nginx с некоторыми ошибками конфигурации, обсуждаемыми в этой статье, и попробуйте найти их самостоятельно!

Вывод

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

Вторая часть будет позднее.

Что ещё интересного есть в блоге Cloud4Y

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

nginx
безопасность
конфигурация
администрирование

Отзывы и обзоры хостинга

Selectel.ru
Bitweb.ru
FASTVPS
HOSTLIFE
Hoster.ru
Colobridge.net
Beget.com
Simplecloud.ru
FASTVPS
VDS.selectel.ru

Ошибка 502 Bad Gateway nginx. Как исправить

Эта статья поможет разобраться, почему на сайтах время от времени появляется ошибка 502 Bad Gateway nginx (HTTP Error 502) и как эту проблему решить.

Если вы посетитель

Если вы не можете попасть на сайт из-за ошибки 502, сделать можно не так много:

Перезагрузить страницу, сбросив кеш (Ctrl+Shift+R, Ctrl+F5 или Shift+F5). К сожалению, это помогает не так часто, как хотелось бы.
Зайти попозже. Через минуту, через полчаса, ночью или рано утром. Скорее всего сервер перегружен. Исправить это вы не сможете, этим должен заняться администратор сайта. Если сайт для вас важный, и у вас есть время, напишите администратору письмо. Чем больше обращений, тем вероятнее, что на проблему обратят внимание и серьезно ей займутся.

Если вы администратор сайта

Если эта ошибка возникает, значит HTTP-запросы от посетителей к вашему сайту идут через так называемый «шлюз», программу-посредник. Например, если на хостинге перед веб-сервером Apache стоит веб-сервер nginx, то nginx будет шлюзом.

502-ая ошибка означает, что запрос от клиента прошел nginx, попал к Apache, и Apache не смог запрос обработать, о чем сообщил nginx’у. В результате nginx отдает клиенту ошибку.

Если PHP работает в режиме FastCGI, то любой веб-сервер перед ним будет шлюзом.

Почему Apache не смог обработать запрос? Как это исправить?

Скорее всего, если сайт раньше работал, а теперь не открывается, дело не в ошибках конфигурации среды. Причина может быть в нехватке ресурсов сервера, и, следовательно, в невозможности обслужить всех клиентов. В частности, проблема может быть в нехватке оперативной памяти. Или вы можете упираться в какое-то ограничение, например, на количество процессов. Иногда Apache или ваше приложение могут периодически падать/перезапускаться, в эти моменты фронт-серверу тоже ничего не остаётся, кроме как отдавать ошибку 502. Такое может случиться и на VPS, и на shared-хостинге.

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

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

Если у вас VPS

Если PHP работает через FastCGI, то на сервере может не хватать php-cgi процессов в моменты, когда на сайте много посетителей, пришел прожорливый бот, кто-то скачивает ваш сайт целиком или идёт DoS-атака. Веб-серверу нужно бы запустить дополнительные процессы, но памяти под них уже нет. Значит, нужно добавить памяти либо оптимизировать расход доступной

Запустите команду top. Посмотрите, есть ли свободная память и запущен ли Apache.
Посмотрите логи Apache и nginx (ошибки 502 попадают в него). Есть паразитная активность? Если есть, баньте по ip, настраивайте Fail2ban, подключайте защиту от DdoS.
Если получилось ограничить количество запросов к серверу, перезапустите Apache.
Если в логах всё нормально, но мало свободной памяти, и есть возможность ее оперативно добавить, попробуйте это сделать. Сейчас у многих провайдеров это делается в биллинге буквально за пару минут.
Если же команда top показывает, что свободная память есть, возможно, дело в установленных лимитах на количество php-cgi процессов. Нужно смотреть конфигурационные файлы Apache (httpd.conf), особенно секцию модуля, отвечающего за FastCGI (mod_fascgi или mod_fastcgid), и увеличивать лимиты.

Если дело в нехватке памяти, то в логах будут ошибки OOM (out of memory). Когда ОС очень нужна память, то ядро может попытаться освободить её при помощи механизма OOM killer, просто убивая активные процессы. Например, здесь пришлось пожертвовать Апачем:
Out of memory: kill process 1718 (apache2) score 56789 or a child
Killed process 22504 (apache2)

Другой случай — когда, Apache периодически падает/перезапускается независимо от текущей нагрузки на сайт. В error.log может быть написано:

[core:notice] [pid 5795] AH00052: child pid 5858 exit signal Segmentation fault (11)
[mpm_prefork:notice] [pid 5795] AH00169: caught SIGTERM, shutting down

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

Смотрите также

Ошибка 504 Gateway Timeout (time out) nginx. Как исправить
В какой лог пишутся 502-ые ошибки?
Ошибка 502 каждые 15 минут
Как настроить VPS?
Как настроить мониторинг ошибок 500, 502, 503, 504?

Самые распространенные ошибки синтаксиса Nginx

Nginx — это популярный веб-сервер, на котором размещаются многие крупные сайты. При настройке веб-сервера Nginx обычно создается domain block с деталями конфигурации, чтобы сайт мог обрабатывать входящие запросы. Часто при настройке Nginx в файле конфигурации допускают ошибки. Мы разберем самые распространенные синтаксические ошибки, а также подумаем, как их проверить и как исправить.

Примеры в этом мануале были протестированы на сервере Ubuntu, но они будут работать на большинстве установок Nginx, так как они в основном связаны со стандартным файлом конфигурации. Каталоги и пути могут немного отличаться.

Проверка лога ошибок Nginx

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

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

sudo cat /var/log/nginx/error.log

В этом мануале позже будет рассказано, как разобрать и понять сообщения об ошибках Nginx.

Проверка файла конфигурации на наличие ошибок

Давайте посмотрим на пример domain block в Nginx с разными ошибками в файле конфигурации. Эти ошибки сделаны намеренно, чтобы показать вам, как их можно исправить. Чтобы проверить, есть ли в настройке какие-либо синтаксические ошибки, запустите следующую команду:

Если ошибок нет, вывод будет следующим:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

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

Выявление структурных синтаксических ошибок

Одна из распространенных ошибок при работе с Nginx – отсутствие необходимых символов или неправильная структура синтаксиса. Конфигурационный файл Nginx ориентирован на директивы, и эти директивы должны быть объявлены определенным образом. В противном случае конфигурационный файл будет структурно некорректным.

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

Если директива структурирована неправильно, Nginx не сможет распознать ее, что может привести к следующим ошибкам.

Ошибка Invalid parameter

Файл конфигурации Nginx очень требователен к структуре и синтаксису. Одна из самых частых проблем с синтаксисом связана с точкой с запятой. Например, рассмотрим такое сообщение об ошибке:

[emerg] invalid parameter "root" in /etc/nginx/sites-enabled/your_domain:5 nginx: configuration file /etc/nginx/nginx.conf test failed

Прежде чем решать эту проблему, нужно понять сообщение об ошибке Nginx. В нем есть подсказки, которые помогают определить причину ошибки. В этом случае [emerg] означает “ emergency ” — это связано с нестабильностью системы. Значит, Nginx столкнулся с проблемой, которая не позволяет ему работать.

Это сообщение об ошибке дополнительно указывает место, где обнаружена ошибка. Имейте в виду, что в настройках Nginx у вас будет свой файл конфигурации, связанный симликом с /etc/nginx/nginx.conf. Если вы следовали мануалу Установка Nginx в Ubuntu 20.04, то в пункте 5 вы видели, как это делается. Указана точная строка в конфигурационном файле с ошибкой: /etc/nginx/sites-enabled/your_domain:5. Также в этом файле есть invalid parameter “root”.

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

sudo nano /etc/nginx/sites-available/your_domain

Примечание: Все конфигурационные файлы можно найти в каталоге /etc/nginx/.

Внутри файла найдите строку 5, на которую ссылается сообщение об ошибке:

server  listen 80; listen [::]:80; root /var/www/your_domain/html index index.html index.htm index.nginx-debian.html; server_name your_domain www.your_domain; location /  try_files $uri $uri/ =404; > >

Ошибка может быть не совсем очевидна. Напоминаем, из сообщения об ошибке следует, что проблема заключается в invalid parameter. Параметры — это аргументы, которые предоставляются директивам Nginx. В этом сценарии /var/www/your_domain/html – и есть это недействительный параметр. Он не работает потому, что в синтаксической структуре отсутствует символ, в данном случае – точка с запятой в конце строки.

Многие строки в этом файле также заканчиваются точкой с запятой. Точка с запятой должна стоять в конце каждой строки, которая содержит директиву. В этом примере у нас присутствует директива root, которая указывает на root каталог, который будет использоваться при поиске файла. Наличие root необходимо для того, чтобы Nginx мог найти определенный URL. Разберем важность директив в следующем разделе.

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

… root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; …

После исправления сохраните и закройте файл.

Чтобы убедиться, что синтаксическая ошибка исправлена, выполните команду sudo nginx -t.

Неправильно поставленные фигурные скобки

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

nginx: [emerg] unexpected ">" in /etc/nginx/sites-enabled/your_domain:15 nginx: configuration file /etc/nginx/nginx.conf test failed

Сообщение об ошибке указывает на строку 15, в которой содержится лишняя фигурная скобка в том же файле конфигурации, что и раньше. Откройте этот файл через текстовый редактор:

server  listen 80; listen [::]:80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; server_name your_domain www.your_domain; location /  try_files $uri $uri/ =404; >

Внизу файла вы найдете фигурную скобку >. Сначала суть проблемы может быть непонятна, поскольку фигурная скобка вроде бы присутствует на своем месте. Однако при детальном разборе оказывается, что после этой фигурной скобки не хватает еще одной скобки. Правильное количество фигурных скобок в файле конфигурации Nginx очень важно, поскольку они указывают на открытие и закрытие определенного блока. Фигурная скобка в конце файла является закрывающей скобкой для следующего вложенного блока location:

… location /  try_files $uri $uri/ =404; > …

Если просмотреть файл конфигурации еще дальше, то окажется, что в server block также отсутствует закрывающая фигурная скобка. Server block в Nginx важен, поскольку он предоставляет детали конфигурации, необходимые Nginx для определения того, какой виртуальный сервер будет обрабатывать получаемые запросы. Важно отметить, что location blocks вложены в server block, поскольку он имеет приоритет при обработке входящих запросов. Учитывая все это, для завершения server block в конце файла нужно добавить закрывающую фигурную скобку. Теперь содержимое этого файла будет выглядеть следующим образом:

server  listen 80; listen [::]:80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; server_name your_domain www.your_domain; location /  try_files $uri $uri/ =404; > >

После редактирования не забудьте сохранить и закрыть файл. Чтобы убедиться, что синтаксическая ошибка устранена, запустите sudo nginx -t.

Ошибка invalid host

Эта ошибка возникает из-за неверно сформированного параметра, заданного в директиве. Если завершение строк точкой с запятой и закрытие каждой фигурной скобки относится к общей структуре конфигурационного файла, то параметры – это пользовательские данные, которые могут варьироваться в зависимости от потребностей установки.

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

[emerg] invalid host in "[::]80" of the "listen" directive in /etc/nginx/sites-enabled/your_domain:3 nginx: configuration file /etc/nginx/nginx.conf test failed

Сообщение объясняет, что установленная директива порта 80 недействительна. Сообщение об ошибке дополнительно указывает место обнаружения ошибки и точную строку в файле конфигурации: /etc/nginx/sites-enabled/your_domain:3. Обладая информацией о том, где найти ошибку, можно открыть файл в текстовом редакторе. Найдите строку 3, на которую ссылается сообщение:

server  listen 80; listen [::]80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; server_name your_domain www.your_domain; location /  try_files $uri $uri/ =404; > >

Два двоеточия в скобках представляют собой обозначение IPv6 или 0.0.0.0; без дополнительного двоеточия после скобки он не сможет привязаться к порту 80. В результате директива listen не будет работать, поскольку без двоеточия неясно, какой порт должен прослушивать сервер.

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

server  listen 80; listen [::]:80; …

После обновления этой строки обязательно сохраните и закройте файл и убедитесь, что синтаксическая ошибка исправлена, выполнив команду sudo nginx -t.

В целом, при получении подобных синтаксических ошибок, связанных с параметрами, точками с запятой ; или фигурными скобками < >, рекомендуем обратить особое внимание на точное местоположение и детали в сообщении [emerg].

Выявление неправильных директив – ключевые слова в конфигурационном файле Nginx

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

Ошибка unknown directive

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

nginx: [emerg] unknown directive "serve_name" in /etc/nginx/sites-enabled/your_domain:8 nginx: configuration file /etc/nginx/nginx.conf test failed

Эта ошибка указывает на unknown directive “serve_name” в строке 8 файла конфигурации. Откройте файл с помощью текстового редактора:

server  listen 80; listen [::]:80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; serve_name your_domain www.your_domain; location /  try_files $uri $uri/ =404; > >

В данном примере ошибка — это неправильно написанное слово “server” в имени директивы server_name. В нем пропущена буква “r” и по этой причине директива не распознается. Это серьезная ошибка, поскольку в директиве server_name хранятся конкретные названия серверов, к которым будет обращаться server block при получении запроса. Без корректной работы этой директивы запрос не будет выполнен. Казалось бы, незначительная опечатка, но она нарушает синтаксис и вызывает ошибку. Обновите фрагмент кода в файле конфигурации следующим образом:

… server_name your_domain www.your_domain; …

Сохраните и закройте файл. Проверьте его с помощью команды sudo nginx -t.

Ошибка directive is not allowed here

Теперь предположим, что возникла ошибка с той же директивой, но на этот раз сообщение выглядит так:

nginx: [emerg] "server" directive is not allowed here in /etc/nginx/sites-enabled/your_domain:8 nginx: configuration file /etc/nginx/nginx.conf test failed

Ошибка возникает в том же месте, что и предыдущая, причина проблемы подробно описана в этом сообщении. Поэтому важно понимать, на что указывает сообщение об ошибке. Эта ошибка указывает, что directive is not allowed here. Откройте файл конфигурации в текстовом редакторе:

server  listen 80; listen [::]:80; root /var/www/your_domain/html; index index.html index.htm index.nginx-debian.html; server name your_domain www.your_domain; location /  try_files $uri $uri/ =404; > >

Здесь слово “server” написано правильно, но теперь тут отсутствует символ подчеркивания. Поэтому server воспринимается как дубликат, что недопустимо, о чем и говорит сообщение об ошибке. Это связано с различием между простыми и блочными директивами, о котором мы говорили ранее.

Эта ошибка связана с тем, что без подчеркивания server name читается просто как server и таким образом конфликтует с первой директивой server block в начале файла. Это сложная синтаксическая ошибка, которая может возникнуть из-за иерархической структуры Nginx в файле конфигурации среди блочных директив и вложенных простых директив. Исправить эту ошибку можно, добавив знак подчеркивания:

… server_name your_domain www.your_domain; …

После внесения исправлений сохраните и закройте файл. Затем проверьте правильность синтаксиса с помощью команды sudo nginx -t. Если в файле конфигурации нет ошибок, должно появиться сообщение syntax is ok.

Примечание: В конфигурационных файлах Nginx есть определенная гибкость в отношении интервалов или разделения строк, что не приведет к возникновению ошибок. Однако все, что явно связано с директивами, приведет к ошибке, поскольку для правильной работы необходимы точная формулировка или синтаксическая структура.

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

Здесь вы узнали о самых распространенных синтаксических ошибках, которые могут возникнуть с определенными директивами в файле конфигурации веб-сервера. Важно отметить, что все эти примеры представлены в среде терминала. Вы также можете использовать редактор кода, например Visual Studio Code , который может проверять и выделять ошибки в коде, не отправляя многочисленных уведомлений, что позволит исправить их все сразу или даже избежать их на ранней стадии.

Подводим итоги

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

Что значит ошибка 502

Код ошибки 502 Bad Gateway в переводе с английского «плохой шлюз».

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

Например, внутри сервера часто используется связка Nginx + Apache. Веб-сервер Nginx получает запрос от пользователя и передает его на обработку Apache, если веб-сервер Apache по какой-то причине будет недоступен, то Nginx выдаст пользователю ошибку 502.

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

Страница ошибки 502

Сам клиент не сможет исправить данную ошибку, сделать это сможет только администратор сервера.

Как исправить ошибку 502 Bad Gateway:

Проверить плагины — некоторые из них могут нарушать работу сервера
Проверить логи сервера, возможно проблема возникла из-за обновлений. Также в логах отображаются DDos-атаки
Настроить оборудование арендованного сервера
Увеличить мощность сервера арендованного сервера
Оптимизировать работу сайтов, что снизит нагрузку на сервер.

На нашем сайте Вы можете купить хостинг в России.

МИР Visa MasterCard СБП QIWI Wallet Безналичный платеж