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

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

1. Что такое ошибка 502 плохой шлюз?

Проще говоря, 502 — это код типа ошибки «плохой шлюз».

2. Причины ошибки 502

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

Первая причина:

DNS-буферизация. Обычная причина этого заключается в том, что вы посетили такой веб-сайт, как Facebook, без включенного VPN. Доступ к нему в это время, естественно, невозможен, но при этом на локальной машине остаётся буфер. Эта ситуация обычно доступна в течение нескольких минут. Вы также можете попробовать запустить ipconfig /flushdns в окне DOS. Эта команда очистит буфер DNS.

Вторая причина:

В вашем браузере включен прокси. Обязательно отключите прокси.

Третья причина:

DNS был взломан. Даже если вы используете внешний DNS, он будет взломан. Некоторые машины могут получить к нему доступ с включенным VPN, но некоторые нет. И устраните причины прокси, брандмауэра и локальной сети. В это время одновременно проверяйте удаленные веб-сайты, такие как Facebook. Недоступная машина обычно имеет странный IP-адрес, который невозможно проверить ниоткуда. Доступ к IP-адресу машины, к которой можно получить доступ, можно получить непосредственно с машины, к которой нет доступа, а также можно выполнить проверку связи. В этом случае мы можем удалить DNS VPN-сервера.

Переключитесь на другой днс. В системе Windows можно в свойствах локального сетевого подключения удалить DNS по умолчанию и выбрать внешний DNS, например Google. или опенднс.

3.502 Неправильный HTTP-цикл

Любой клиент (например, веб-браузер или наш робот CheckUpDown) взаимодействует с вашим веб-сервером, выполняя следующий цикл:

Получите IP-имя IP-адреса вашего веб-сайта (URL-адрес вашего веб-сайта начинается с «http://»). Он ищет (преобразует IP-имя в IP-адрес), предоставленный серверами доменных имен (DNS).

Откройте IP-сокет для подключения к этому IP-адресу. Записывает поток HTTP через этот сокет.

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

Эта ошибка возникает на последнем этапе, когда указанный выше клиент получает код состояния HTTP, который он подтверждает как 502'.

4. Исправлена ​​ошибка 502.

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

Если вы находитесь в сети и видите этот вопрос на каждом веб-сайте, который пытаетесь посетить, есть две возможности.

1) У вашего интернет-провайдера произошел серьезный сбой/перегрузка оборудования.

2) Проблемы с внутренним подключением к Интернету, например, брандмауэр не работает должным образом.

В первом случае вам может помочь только ваш интернет-провайдер. Во втором случае вам предстоит решить любые проблемы, которые мешают вам получить доступ к Интернету.

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

5. Как решить проблему при появлении 502 badgate?

Самый простой метод: CTRL+F5 для принудительного обновления. Лучшее решение, конечно, сделать это на сервере, что вряд ли подойдет каждому. Итак, какие у нас есть решения? Если говорить прямо, то это очень просто, это - рефреш (не обычный рефреш)

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

①Базовое обновление: просто нажмите «Обновить» или используйте горячую клавишу F5. Базовое обновление только повторно извлекает данные с локального жесткого диска в браузер и не отправляет повторный запрос на сервер. Большинство пользователей обновляются таким образом большую часть времени, и это не имеет никакого эффекта, если они сталкиваются с ошибкой 502. 　　

② Обновление с сервера: Если вы снова нажмете на веб-ссылку, которую хотите просмотреть, вы обнаружите, что страницу, на которой все еще отображалось сообщение 502 bad getway, теперь можно снова нормально просматривать! Вы понимаете? Когда вы нажимаете ссылку на веб-страницу, которую хотите просмотреть, данные будут повторно загружены с сервера. Решение состоит в обновлении с сервера: сочетание клавиш Ctrl+F5, которое повторно отправит запрос на сервер. Если сервер может ответить вам нормально, вы сможете увидеть страницу.

Также прилагается:

Причины и решения ошибки Nginx 502 Bad Gateway

Я несколько раз сталкивался с ошибкой Nginx 502 Bad Gateway. Я сделаю запись здесь и возьму на заметку, ха-ха.

Существует множество ситуаций, когда может возникнуть ошибка 502. Давайте поговорим о каждой ситуации ниже.

1. Настройка буфера Fastcgi слишком мала.

В случае возникновения ошибки сначала найдите файл журнала nginx. Каталог — /var/log/nginx. В журнале обнаружена следующая ошибка.

2013/01/17 13:33:47 [error] 15421#0: *16 upstream sent too big header while reading response header from upstream

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

Я искал решения в Интернете и увидел на зарубежных сайтах метод увеличения буферной зоны, который полностью решил проблему Nginx 502 Bad Gateway. Вот как:

http {
    ...
    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32k;
    ...
}

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

2. Настройка буфера прокси слишком мала. Если вы используете обратный прокси-сервер nginx, если заголовок слишком велик и превышает значение по умолчанию 1 КБ, будет запущен вышеуказанный восходящий поток. sent too big header (Грубо говоря, nginx отправляет внешние запросы на обработку на серверную часть. Если заголовок, возвращаемый серверной частью, слишком велик, nginx не может его обработать, в результате чего выводится ошибка 502.

server {
        listen       80;
        server_name  *.lxy.me;
 
        location / {
 
###############Добавьте эти 3 строки
            proxy_buffer_size 64k;
            proxy_buffers   32 32k;
            proxy_busy_buffers_size 128k;
###############Добавьте эти 3 строки
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP       $remote_addr;
            proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
............
}

3. По умолчанию установлено слишком малое количество процессов php-cgi.

502 проблемы возникают во время установки и использования. Обычно это связано с тем, что процесс php-cgi по умолчанию равен 5. Это может быть вызвано недостаточным количеством процессов phpcgi. Вам необходимо изменить /usr/local/php/etc/php-fpm.conf на. включите их. Значение max_children увеличивается соответствующим образом. Также возможно, что значения max_requests недостаточно. Следует отметить, что эти два элемента конфигурации занимают большой объем памяти. Установите их в соответствии с конфигурацией сервера. В противном случае это может иметь противоположный эффект.

4. Тайм-аут выполнения PHP

Тайм-аут выполнения PHP, измените /usr/local/php/etc/php.ini и измените max_execution_time на 300.

5. Тайм-аут ожидания nginx

Время выполнения некоторых программ PHP превышает время ожидания Nginx. Вы можете соответствующим образом увеличить время ожидания FastCGI в файле конфигурации nginx.conf.

http  {
  fastcgi_connect_timeout 300;
  fastcgi_send_timeout 300;
  fastcgi_read_timeout 300;
  ......
  }

nginx 502 bad gateway

Некоторые веб-сайты, работающие на Nginx, иногда сталкиваются с ошибками «502 Bad Gateway», иногда даже часто. Ниже приведены некоторые методы устранения ошибок Nginx 502, собранные редактором для справки:

Существует множество причин ошибок Nginx 502, которые вызваны проблемами с серверным сервером в режиме прокси. Эти ошибки, как правило, не являются проблемами самого nginx. Вы должны найти причину в серверной части! Но nginx взял на себя все эти ошибки, что действительно поставило под сомнение промоутеров nginx. Ведь в буквальном смысле плохой шлюз? Разве это не просто плохой nginx? Если это увидят люди, которые не понимают, они напрямую переложат ответственность на nginx. Я надеюсь, что в следующей версии nginx сообщение об ошибке станет немного более дружелюбным, по крайней мере, теперь это не будет простой 502 Bad Gateway. Кроме того, не забудьте указать свое знаменитое имя.

Условия срабатывания Nginx 502

Чаще всего ошибки 502 возникают при сбое внутреннего хоста. В конфигурации upstream есть такая конфигурация: proxy_next_upstream. Эта конфигурация определяет, с какими ошибками сталкивается nginx при получении данных с внутреннего хоста. Все, что в ней написано, — это. 502 с. В зависимости от ситуации по умолчанию используется тайм-аут ошибки. Ошибка относится к сбоям, отключениям и т. д. Тайм-аут означает тайм-аут блокировки чтения, который легче понять. Я обычно пишу полностью:

proxy_next_upstream error timeout invalid_header http_500 http_503;

Но теперь мне, возможно, придется удалить элемент http_500. http_500 указывает, что, когда серверная часть возвращает ошибку 500, она будет перенаправлена ​​на хост. Если серверная часть jsp выдает ошибку, будет напечатано множество сообщений об ошибках stacktrace, но сейчас. они заменены на 502. Но программисты компании так не считают. Они считают, что в nginx есть ошибка. У меня действительно нет времени объяснять им принцип 502...

Ошибку 503 можно сохранить, поскольку бэкэнд обычно представляет собой смолу apache. Если происходит сбой apache, это ошибка, но если происходит сбой смолы, это только 503, поэтому ее все равно необходимо сохранить.

Решение

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

1. Проверьте, достаточно ли текущего количества процессов PHP FastCGI:

netstat -anpo | grep "php-cgi" | wc -l

Если фактическое количество используемых процессов FastCGI близко к значению по умолчанию «Количество процессов FastCGI».,Так,Пояснение: «Количества процессов FastCGI» недостаточно.,Необходимо увеличить。

2、Время выполнения некоторых программ PHP превышает время ожидания Nginx. Вы можете соответствующим образом увеличить время ожидания FastCGI в файле конфигурации nginx.conf., например:

http  {
  fastcgi_connect_timeout 300;
  fastcgi_send_timeout 300;
  fastcgi_read_timeout 300;
  ......
  }
  ......

Если в php.ini установлен низкий предел памяти, произойдет ошибка. Я изменил предел памяти в php.ini на 64 МБ, перезапустил nginx и обнаружил, что все в порядке. Оказалось, что PHP не хватает памяти.

Если эта модификация по-прежнему не может решить проблему, вы можете обратиться к следующим решениям:

один、макс-детиимакс-запросы

nginx php (fpm) xcache работает на сервере, средний ежедневный объем посещений составляет около 300 Вт pv.

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

Проверка файлов журналов php-fpm обнаружила некоторые подсказки.

Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200  Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10, “127.0.0.1:9000″  Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll  Sep 30 08:32:23.296426 [NOTICE] fpm_init(), line 47: fpm is running, pid 30587

Перед этими предложениями находится более 1000 строк журналов закрытия и открытия детей.

Оказывается, в php-fpm есть параметр max_requests, который определяет максимальное количество запросов, которые каждый дочерний элемент может обработать перед закрытием. Значение по умолчанию — 500. Поскольку PHP опрашивает запросы к каждому дочернему элементу, при интенсивном трафике каждому дочернему элементу требуется примерно одинаковое количество времени, чтобы достичь max_requests, что приводит к закрытию всех дочерних элементов практически одновременно.

В этот период nginx не может передать php-файл на обработку в php-fpm, поэтому загрузка процессора упадет до очень низкого уровня (не нужно обрабатывать php, не говоря уже о выполнении sql), а нагрузка поднимется до очень высокого уровня. (закрытие и открытие дочерних элементов, nginx ожидает php -fpm), трафик сетевой карты также упал до очень низкого уровня (nginx не может генерировать данные и передавать их клиенту)

Решение проблемы простое: увеличьте количество дочерних элементов и установите max_requests равным 0 или большему значению:

Откройте /usr/local/php/etc/php-fpm.conf и настройте следующие два параметра (в соответствии с реальной ситуацией на сервере, слишком большие значения не подойдут)

<value name="max_children">5120</value>  <value name="max_requests">600</value>

Затем перезапустите php-fpm.

2. Увеличение емкости буфера

　　Будет ли ошибка nginx Журнал открыт и "pstream sent too big header while reading response header from сообщение об ошибке «вверх по течению». проверки информации общее мнение заключается в том, что в буфере nginx есть ошибка. Буфер, занимаемый потреблением страниц нашего сайта, может быть слишком большой Обратитесь к редакции, написанной иностранцами. Модифицированный метод увеличивает настройку емкости буфера, и проблема 502 полностью решена. Позже системный администратор скорректировал параметры и оставил только два параметра настройки: клиент head buffer,fastcgi buffer size。

три、request_terminate_timeout

Если ошибка 502 возникает в основном во время некоторых операций публикации или базы данных, а не обычно при операциях со статическим страницами, вы можете проверить одну из настроек php-fpm.conf:

request_terminate_timeout

Это значение — max_execution_time, которое представляет собой время выполнения сценария fast-cgi.

0s

0s означает закрыто, что означает, что выполнение продолжается бесконечно. (номер менял не внимательно при установке) Проблема решена и выполнение еще долго будет без ошибок. При оптимизации fastcgi вы также можете изменить это значение на 5 секунд, чтобы увидеть эффект.

Если количества процессов php-cgi недостаточно, время выполнения php велико или процесс php-cgi умирает, возникнет ошибка 502.

Заявление об авторских правах: Содержание этой статьи добровольно предоставлено пользователями Интернета, а мнения, выраженные в этой статье, представляют собой только точку зрения автора. Данный сайт лишь предоставляет услуги по хранению информации, не имеет никаких прав собственности и не несет соответствующей юридической ответственности. Если вы обнаружите на этом сайте какое-либо подозрительное нарушение авторских прав/незаконный контент, отправьте электронное письмо, чтобы сообщить. После проверки этот сайт будет немедленно удален.

Издатель: Лидер стека программистов полного стека, укажите источник для перепечатки: https://javaforall.cn/194212.html Исходная ссылка: https://javaforall.cn