Ошибки 50x nginx - Решение и исправление самых разных ошибок на TopOshibok.ru

How can I use or configure proxy_pass in NGINX in order to display my react application when someone visits my website?

Below you can read the configuration I am using, but it is not working as I expect and redirecting to website.com:3000.

# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    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  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
    
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  dummyReactSite.com;
        #root         /usr/share/nginx/html;
    
    include /etc/nginx/default.d/*.conf;

        location / {
    proxy_pass http://127.0.0.1:3000/; 
        }


        error_page 404 /404.html;
        location = /404.html {
        }

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
        }
    }
}

Источник

7 июня, 2022 12:03 пп
938 views
| Комментариев нет

LEMP Stack, Ubuntu

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

Требования

Виртуальный сервер с пользователем sudo (мы используем сервер Ubuntu 22.04, настроенный по этому мануалу).
Предварительно установленный веб-сервер Nginx (инструкции по установке вы найдете здесь).

Создание пользовательской страницы об ошибке

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

Поместите пользовательские страницы ошибок в каталог /usr/share/nginx/html, корневой каталог Nginx по умолчанию. Там мы создадим страницу для ошибки 404 под названием custom_404.html и для общих ошибок уровня 500 под названием custom_50x.html.

Примечание: Дальнейшие строки можно использовать, если вы тренируетесь на наших страницах. В противном случае не забудьте указать свои данные.

Сначала создайте HTML-файл для своей пользовательской страницы 404 с помощью nano или другого текстового редактора:

sudo nano /usr/share/nginx/html/custom_404.html

Вставьте туда код, который определяет пользовательскую страницу:

<h1 style='color:red'>Error 404: Not found :-(</h1>
<p>I have no idea where that file is, sorry. Are you sure you typed in the correct URL?</p>

Сохраните и закройте файл.

Теперь создайте файл HTML для страницы 500:

sudo nano /usr/share/nginx/html/custom_50x.html

Вставьте в файл следующее:

<h1>Oops! Something went wrong...</h1>
<p>We seem to be having some technical difficulties. Hang tight.</p>

Сохраните и закройте файл.

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

Настройка Nginx для поддержки пользовательских страниц

Итак, пора сообщить Nginx, что он должен использовать эти страницы всякий раз, когда возникают соответствующие ошибки. Откройте тот файл server-блока в каталоге /etc/nginx/sites-enabled, который вы хотите настроить. Здесь мы используем стандартный файл по имени default. Если вы настраиваете свои собственные страницы, пожалуйста, убедитесь, что используете правильный файл:

sudo nano /etc/nginx/sites-enabled/default

Теперь нужно направить Nginx на соответствующие страницы.

Настройка пользовательской страницы 404

Используйте директиву error_page, чтобы при возникновении ошибки 404 (когда запрошенный файл не найден) обслуживалась созданная вами пользовательская страница. Создайте location-блок для вашего файла, где вы сможете установить его правильное расположение в файловой системе и указать, что файл доступен только через внутренние перенаправления Nginx (не запрашиваемые клиентами напрямую):

server {
    listen 80 default_server;



    . . .

    error_page 404 /custom_404.html;
    location = /custom_404.html {
        root /usr/share/nginx/html;
        internal;
    }
}

Обычно устанавливать root в новом блоке location не нужно, так как он совпадает с root в блоке server. Однако здесь мы явно указываем, что страницы ошибок нужно обслуживать, даже если вы перемещаете свой обычный веб-контент и связанный с ним root в другое место.

Настройка страницы ошибок 50х

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

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

Отредактируйте файл /etc/nginx/sites-enabled/default следующим образом:

server {
    listen 80 default_server;


    . . .

    error_page 404 /custom_404.html;
    location = /custom_404.html {
        root /usr/share/nginx/html;
        internal;
    }

    error_page 500 502 503 504 /custom_50x.html;
    location = /custom_50x.html {
        root /usr/share/nginx/html;
        internal;
    }

    location /testing {
        fastcgi_pass unix:/does/not/exist;
    }
}

Сохраните и закройте файл, когда закончите.

Перезапуск Nginx и тестирование

Чтобы проверить синтаксис ваших файлов, введите:

sudo nginx -t

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

sudo systemctl restart nginx

Теперь, если вы перейдете на домен или IP-адрес вашего сервера и запросите несуществующий файл, вы должны увидеть настроенную вами страницу 404:

http://server_domain_or_IP/thiswillerror

Перейдите в расположение вашего FastCGI и вы получите ошибку 502 Bad Gateway, что является ошибкой уровня 50х:

http://server_domain_or_IP/testing

Вернитесь в конфигурационный файл и удалите фиктивный FastCGI.

Заключение

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

Tags: NGINX, Ubuntu 22.04

Источник

Перейти к содержимому

Предположим у нас есть сервер А проксирующий картинки с бекенд сервера Б. При этом мы не знаем, существует ли картинка на сервере Б. Перехватить ошибку 404, которую вернет Б и отдать дефолтную картинку можно так:

    location /img/ {
        proxy_pass http://192.168.1.100/img/;
        proxy_redirect     off;
        proxy_set_header   Host             192.168.1.100;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_intercept_errors on;
        error_page 404 = @img404;
    }

    location @img404 {
        try_files $uri /images/default.png;
    }

Дело в том, что директива proxy_intercept_errors отключена по умолчанию в прокси модуле и чтобы заработал перехват, её нужно включить. Ну а далее, при помощи директивы error_page мы можем перехватывать не только 404 ошибки, а например 50x ошибки бекенд сервера и делать любую дальнейшую логику с запросами. Например, перенаправлять их на альтернативный сервер, обеспечивая тем самым бесперебойную работу сайтов и т.п.

Источник

7 июня, 2022 12:03 пп
706 views
| Комментариев нет

LEMP Stack, Ubuntu

Требования

Виртуальный сервер с пользователем sudo (мы используем сервер Ubuntu 22.04, настроенный по этому мануалу).
Предварительно установленный веб-сервер Nginx (инструкции по установке вы найдете здесь).

Создание пользовательской страницы об ошибке

sudo nano /usr/share/nginx/html/custom_404.html

Вставьте туда код, который определяет пользовательскую страницу:

<h1 style='color:red'>Error 404: Not found :-(</h1>
<p>I have no idea where that file is, sorry. Are you sure you typed in the correct URL?</p>

Сохраните и закройте файл.

Теперь создайте файл HTML для страницы 500:

sudo nano /usr/share/nginx/html/custom_50x.html

Вставьте в файл следующее:

<h1>Oops! Something went wrong...</h1>
<p>We seem to be having some technical difficulties. Hang tight.</p>

Сохраните и закройте файл.

sudo nano /etc/nginx/sites-enabled/default

Теперь нужно направить Nginx на соответствующие страницы.

Настройка пользовательской страницы 404

server {
    listen 80 default_server;



    . . .

    error_page 404 /custom_404.html;
    location = /custom_404.html {
        root /usr/share/nginx/html;
        internal;
    }
}

Настройка страницы ошибок 50х

Отредактируйте файл /etc/nginx/sites-enabled/default следующим образом:

server {
    listen 80 default_server;


    . . .

    error_page 404 /custom_404.html;
    location = /custom_404.html {
        root /usr/share/nginx/html;
        internal;
    }

    error_page 500 502 503 504 /custom_50x.html;
    location = /custom_50x.html {
        root /usr/share/nginx/html;
        internal;
    }

    location /testing {
        fastcgi_pass unix:/does/not/exist;
    }
}

Сохраните и закройте файл, когда закончите.

Перезапуск Nginx и тестирование

Чтобы проверить синтаксис ваших файлов, введите:

sudo nginx -t

sudo systemctl restart nginx

http://server_domain_or_IP/thiswillerror

Перейдите в расположение вашего FastCGI и вы получите ошибку 502 Bad Gateway, что является ошибкой уровня 50х:

http://server_domain_or_IP/testing

Вернитесь в конфигурационный файл и удалите фиктивный FastCGI.

Заключение

Tags: NGINX, Ubuntu 22.04

Источник

Ситуация второго решения после модификации, нам нужно перезагрузить конфигурацию PHP-FPM и Nginx, а затем проверьте его. После этого я не нашел, что «Time-Out 504 ворота» неверно, эффект все еще хорош!

1、request_time

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

Первый байт принимает запрос пользователей к времени передаваемых данных ответа, то есть время данных запроса приема, время отклика программы и время данных о возвращении.

2、upstream_response_time

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

Это означает, что соединение из Nginx к задней части (PHP-CGI) начинает принимать данные, а затем выключить соединение.

Как видно из приведенного выше описания, $ request_time определенно больше, чем значение $ upstream_response_time_time, особенно при использовании пост-режима, поскольку nginx будет кэшировать корпус запроса, а затем отправлять данные вместе на задний план. Поэтому, если пользовательская сеть плохая, или если данные являются большими, $ request_time будет намного больше, чем $ upstream_response_time.

Поэтому, если вы используете представление NGINX AccessLog, какие интерфейсы в программе PHP медленнее, не забудьте добавить $ upstream_response_time в log_format, поэтому не забудьте присоединиться к $ upstream_response_time

location ~* \.php {
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_pass unix:/tmp/php-cgi.sock;
fastcgi_param SCRIPT_FILENAME «/home/bc/g.baicheng.com/public/index.php»;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

}

Источник