Страница пользовательского плохого шлюза с Nginx

Ответ 1

Он похож на настройку пользовательских 404 страниц. Вот что у меня есть.

#site-wide error pages
error_page 404 /404.html;
error_page 500 502 503 504 /500.html;

Ответ 2

Существует три части, которые должны быть на месте, чтобы ваша пользовательская страница ошибки отображалась вместо общей ошибки "Bad Gateway".

• Вы должны создать html файл с именем "500.html" и поместить его в корневой каталог. В случае Rails, работающего позади Nginx, это означает, что он помещается в public/500.html.

• У вас должна быть строка в вашем файле конфигурации, которая указывает хотя бы 502 ошибки на эту страницу 500.html следующим образом:

  error_page 502 /500.html;
  

• У вас должен быть блок местоположения для /500.html в вашем файле конфигурации. Если ваш корень уже определен, этот блок может быть пустым. Но блок должен существовать, тем не менее.

  location /500.html{
  }
  

Ответ 3

Да возможно

Введите это в свой терминал

cd /etc/nginx

sudo nano nginx.conf

и под http добавить эти строки

    error_page 500 Path_to_your_custom_error_page;
    error_page 503 Path_to_your_custom_error_page;
    error_page 504 Path_to_your_custom_error_page;

Теперь перезапустите nginx, набрав следующую команду:

sudo service nginx restart

Bingo теперь вы можете увидеть собственное сообщение об ошибке при ошибке шлюза

Ответ 4

используя debian (на самом деле 9.3), я сделал следующие шаги:

• создать /var/www/html/502.html с содержанием для страницы ошибки 502

• редактировать /etc/nginx/sites-enabled/mywebsite.conf

так это выглядит примерно так:

server {
    listen 80; listen [::]:80;
    server_name www.mywebsite.com;

    error_page 502 /502.html;
    location /502.html {
        root /var/www/html;
    }
}

• затем перезапустил nginx, используя service nginx restart

Ответ 5

Вопрос не говорит, но это довольно распространенная проблема, когда API находится за nginx, проходящим через прокси, поэтому в этом случае вы хотите, чтобы ответом был JSON, а не HTML.

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

error_page 502 503 $scheme://$server_name/500.json;

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

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

Ответ 6

Хотя ответ @Larsenal технически корректен для минимальной конфигурации, существуют общие конфигурации, которые не позволяют ему работать. Ответ @Jack Desert затрагивает этот вопрос, но не дает полного объяснения того, зачем это нужно.

Предположим, у нас есть эта конфигурация (упрощенно из @Jack).

error_page 502 504 /my-error-page.html;

То, что это говорит, в случае внутренней ошибки 502 или 504, переписать исходный URI как /my-error-page.html.

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

Поскольку распространенным методом создания обратного прокси-сервера в nginx является настройка блока location / {, это расположение соответствует /my-error-page.html, и поэтому nginx пытается использовать прокси-сервер для обслуживания файла ошибок. Так как в общем случае используется статический файл в случае, если сервер не работает, обслуживание этой страницы ошибки из серверной части, скорее всего, также приведет к сбою, и по умолчанию nginx будет обслуживать свою собственную страницу внутренней ошибки, которую мы пытались заменить в первой части. место.

Таким образом, общее решение, которое предлагает @Jack Desert, состоит в том, чтобы включить еще один блок location, который будет соответствовать URL-адресу /my-error-page.html перед блоком location /. Обратите внимание, что порядок расположения блоков в конфигурации nginx не влияет; Существует очень специфический набор правил для выбора приоритета блоков местоположения на основе URL. Этот блок местоположения должен иметь все необходимое для обслуживания этого файла, как и любой другой статический файл, который может обслуживать nginx. Это означает, что где-то необходима директива root и что /my-error-page.html будет загружен относительно этого (root может быть установлен практически на любом уровне конфигурации nginx).