помилки nginx "recv () не вдалося (104: скидання з’єднання за допомогою однорангового) під час зчитування заголовка відповіді з висхідної лінії"

У мене є сервер, який працював нормально до 3 жовтня 2013 року о 10:50 ранку, коли він почав періодично повертати клієнту помилки "502 Bad Gateway".

Приблизно 4 із 5 запитів веб-переглядача досягають успіху, але приблизно один із 5-ти не вдається з 502.

Журнал помилок nginx містить багато сотень цих помилок;

2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk  request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"

Однак журнал помилок PHP не містить помилок відповідності.

Чи є спосіб отримати PHP, щоб дати мені більше інформації про те, чому він скидає з'єднання?

Це nginx.conf;

user              www-data;
worker_processes  4;
error_log         /var/log/nginx/error.log;
pid               /var/run/nginx.pid;

events {
   worker_connections  1024;
}

http {
  include          /etc/nginx/mime.types;
  access_log       /var/log/nginx/access.log;

  sendfile               on;
  keepalive_timeout      30;
  tcp_nodelay            on;
  client_max_body_size   100m;

  gzip         on;
  gzip_types   text/plain application/xml text/javascript application/x-javascript text/css;
  gzip_disable "MSIE [1-6]\.(?!.*SV1)";

  include /gvol/sites/*/nginx.conf;

}

І це .confдля цього сайту;

server {

  server_name   www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home;
  root          /gvol/sites/bec/www/;
  index         index.php index.html;

  location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires        2592000;   # 30 days
    log_not_found  off;
  }

  ## Trigger client to download instead of display '.xml' files.
  location ~ \.xml$ {
    add_header Content-disposition "attachment; filename=$1";
  }

   location ~ \.php$ {
      fastcgi_read_timeout  3600;
      include               /etc/nginx/fastcgi_params;
      keepalive_timeout     0;
      fastcgi_param         SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      fastcgi_pass          127.0.0.1:9000;
      fastcgi_index         index.php;
   }
}

## bec-components.co.uk ##
server {
   server_name   bec-components.co.uk;
   rewrite       ^/(.*) http://www.bec-components.co.uk$1 permanent;
}

Я завжди вірю, якщо мої веб-сервери говорять мені: 502 Bad Gateway

• який час роботи вашого fastcgi / nginx - процесу?
• Ви контролюєте мережеві з'єднання?
• чи можете ви підтвердити / заборонити зміну кількості відвідувачів цього дня?

що це означає:

• вам fastcgi-процес не доступний nginx; або повільно, або зовсім не відповідати. поганий шлюз означає: nginx не може fastcgi_pass до визначеного ресурсу 127.0.0.1:9000; в той самий конкретний момент .

• ваші вроджені журнали помилок говорять про все:

.

recv() failed 
    -> nginx failed

(104: Connection reset by peer) while reading response header from upstream, 
    -> no complete answer, or no answer at all
upstream: "fastcgi://127.0.0.1:9000", 
    -> who is he, who failed???

з обмеженого pov, я б запропонував:

• перезапустіть ваш fastcgi_process / сервер
• перевірити свій журнал доступу
• включити налагодження-журнал

Я знаю, що ця тема стара, але вона все ще продовжує з'являтися періодично, тому, шукаючи відповіді в Інтернеті, я придумала такі три можливості:

1. Помилка програмування іноді є segfaulting php-fpm, що в свою чергу означає, що з'єднання з nginx буде розірвано. Зазвичай це залишає принаймні деякі журнали навколо та / або основні відвали, які можна проаналізувати далі.
2. З якоїсь причини PHP не в змозі написати файл сеансу (як правило:) session.save_path = "/var/lib/php/sessions". Це можуть бути погані дозволи, погані права власності, поганий користувач / група чи інші езотеричні / неясні проблеми, як-от вичерпання вкладів у цьому каталозі (або навіть повний диск!). Зазвичай це не залишить безліч основних дампів і, можливо, навіть нічого в журналах помилок PHP.
3. Ще складніше відладжувати: розширення не поводиться (час від часу потрапляє на якусь внутрішню межу чи помилку, яка не спрацьовує весь час); . Звичайними винуватцями є APC, memcache / d тощо (у моєму випадку це було розширення New Relic), тому ідея тут - вимкнути кожне розширення, поки помилка не зникне.

Продовжував отримувати це також. Вирішили це, збільшивши opcacheліміт пам’яті, якщо ви його використовуєте (заміна APC). Здається, PHP-FPM перервав з'єднання, коли кеш занадто заповнений. Це також причина, чому відповідь shgnInc виправляє її на короткий час.

Тож знайдіть файл /etc/php5/fpm/php.ini(або його еквівалент у своєму розповсюдженні) та збільште його memory_consumptionдо будь-якого рівня, який потребує ваш сайт. Відключення opcacheможе також працювати.

[opcache]
opcache.memory_consumption = 196 

Ви можете розглянути цей git на github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Я зіткнувся з подібною ситуацією, коли я перевіряв журнали помилок на своїх серверах, що надходять за течією, вони повідомляють про деяку помилку ulimit, тому я збільшив це до 1000000 (і в верхньому, і в nginx полях), і все працювало нормально

У моєму випадку з тією ж проблемою я просто перезапускаю php-fpmслужбу, щоб вона була вирішена.

sudo service php5-fpm restart

Або іноді ця проблема трапляється через величезну кількість запитів. За замовчуванням pm.max_requestsу php5-fpm можливо 100 або нижче.

Щоб вирішити його, його значення залежить від запитів вашого сайту, наприклад 500.

І після цього вам доведеться перезапустити послугу

У моєму випадку відключення розширення xdebug допомогло.

У мене просто була подібна проблема:

Ви підключаєтесь до php-fpm на Порт 9000. (fastcgi: //127.0.0.1: 9000)

Стандартна конфігурація Ubuntu на моєму сервері:

/etc/php/7.0/fpm/pool.d/www.conf:

listen = /run/php/php7.0-fpm.sock

Ви повинні змінити це на:

listen = 0.0.0.0:9000

У моєму випадку я оновив свій сервер 1 1/2 місяця тому, замінивши свою конфігурацію костюму за замовчуванням. Тепер, перезапустивши php-fpm, ця помилка діяла із запізненням.

Для мене це був сервер, у якого не вистачало пам'яті та php-fpm, вбиваючи вбивцю OOM. Рішенням було збільшити об'єм пам'яті сервера.

Для мене це було тому, що php-fpm досягає max_childrenмежі. Журнал php-fpm для відповідного пулу вказував мені в правильному напрямку

Ця проблема також може виникнути, якщо процес PHP-FPM перевищує встановлений ліміт пам’яті. Коли це відбувається, з'єднання між NGINX та PHP-FPM розривається, і NGINX повертає a 502 Bad Gateway. Ліміт пам'яті процесу PHP-FPM керується memory_limitзмінною. Це можна встановити php_admin_value[memory_limit]у файлі конфігурації PHP-FPM.

Важливо зазначити, що ліміт пам’яті застосовується на основі сценарію . У nпроцесах PHP-FPM загальне використання пам'яті може досягати memory_limit * n. Обов’язково переконайтеся, що на вашій машині достатньо місця для пам'яті!