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
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, что он должен использовать эти страницы всякий раз, когда возникают соответствующие ошибки. Откройте тот файл 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
Ситуация второго решения после модификации, нам нужно перезагрузить конфигурацию 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;
}