it-swarm-ko.com

nginx 오류 "업스트림에서 응답 헤더를 읽는 동안 recv () 실패 (104 : 피어에 의한 연결 재설정)"

클라이언트에 "502 Bad Gateway"오류가 간헐적으로 반환되기 시작한 2013 년 10 월 3 일 오전 10시 50 분까지 정상적으로 작동하는 서버가 있습니다.

브라우저 요청 5 개 중 약 4 개는 성공하지만 502 개 중 약 5 개 중 1 개는 실패합니다.

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;
}
47
Nigel Alderton

내 웹 서버가 나에게 말하면 항상 신뢰합니다 : 502 Bad Gateway

  • fastcgi/nginx-프로세스의 가동 시간은 무엇입니까?
  • 네트워크 연결을 모니터링합니까?
  • 그날 방문자 수 변경을 확인/거부 할 수 있습니까?

무슨 뜻이에요:

  • nginx는 fastcgi-process에 액세스 할 수 없습니다. 느리게하거나 전혀 해당하지 않습니다. 잘못된 게이트웨이는 다음을 의미합니다. 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/서버를 다시 시작하십시오
  • 액세스 로그를 확인하십시오
  • 디버그 로그 활성화
22

나는이 주제가 오래되었다는 것을 알고 있지만 여전히 계속 팝업되어 웹에서 답을 찾고 다음 세 가지 가능성을 생각해 냈습니다.

  1. 프로그래밍 오류로 인해 php-fpm이 segfaulting되어 nginx와의 연결이 끊어 질 수 있습니다. 이것은 일반적으로 적어도 몇 개의 로그 및/또는 코어 덤프를 남겨두고 더 분석 할 수 있습니다.
  2. 어떤 이유로 PHP 세션 파일을 쓸 수 없습니다 (보통 : session.save_path = "/var/lib/php/sessions"). 이는 잘못된 권한, 나쁜 소유권, 나쁜 사용자/그룹 또는 해당 디렉토리의 inode 부족 (또는 전체 디스크)과 같은 난해한/불분명 한 문제 일 수 있습니다. 이것은 일반적으로 not 많은 코어 덤프를 남겨두고 PHP 오류 로그에 아무것도 표시하지 않습니다).
  3. 더 까다로운 디버깅 : 확장 기능이 잘못 작동하거나 (종종 내부 제한에 부딪 히거나 항상 발생하지 않는 버그), segfaulting 및 php-fpm 프로세스 중단-nginx와의 연결 종료 . 일반적인 범인은 APC, memcache/d 등입니다 (제 경우에는 New Relic 확장명). 따라서 오류가 사라질 때까지 각 확장을 끄는 것이 좋습니다.
13
Gwyneth Llewelyn

이것을 얻는 것도 계속했다. 사용하는 경우 opcache 메모리 제한을 늘려서 해결하십시오 (APC의 교체). 캐시가 가득 찰 때마다 PHP-FPM이 연결을 끊은 것 같습니다. 이것이 shgnInc의 답변이 짧은 시간 동안 문제를 해결하는 이유이기도합니다.

/etc/php5/fpm/php.ini (또는 배포판에서 동등) 및 memory_consumption 사이트에서 필요한 수준으로. opcache 비활성화해도 작동 할 수 있습니다.

[opcache]
opcache.memory_consumption = 196 
8
Manuel Riel

Github 에서이 자식을 고려할 수 있습니다 : https://Gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

비슷한 상황이 발생했습니다. 업스트림 서버에 대한 오류 로그를 확인할 때 일부 ulimit 오류를보고했기 때문에 업스트림 및 nginx 상자 모두에서 1000000으로 늘리고 모든 것이 잘 작동했습니다.

2
AMG Anonymous

같은 문제가 발생하면 php-fpm 서비스를 다시 시작하면 해결됩니다.

Sudo service php5-fpm restart

또는 때때로이 문제는 많은 요청 때문에 발생합니다. 기본적으로 php5-fpm의 pm.max_requests는 100 이하일 수 있습니다.

이 문제를 해결하려면 사이트 요청에 따라 값을 늘리십시오 (예 : 500).

그리고 당신은 서비스를 다시 시작해야

2
shgnInc

필자의 경우 xdebug 확장을 비활성화하면 도움이되었습니다.

2
Vasiliy

나를 위해 그것은 서버에서 메모리가 부족하고 php-fpm이 OOM 킬러에 의해 살해되었습니다. 해결책은 서버 메모리 양을 늘리는 것이 었습니다.

1

저에게는 php-fpm이 max_children 한도 문제의 풀에 대한 php-fpm 로그가 올바른 방향으로 나를 가리 켰습니다.

1
bruchowski

방금 비슷한 문제가있었습니다.

포트 9000에서 php-fpm에 연결합니다 (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 개월 전에 서버를 업데이트하여 costom 구성을 기본값으로 덮어 썼습니다. 이제 php-fpm을 다시 시작하면이 오류가 지연되었습니다.

1
Fabian Thommen

PHP-FPM 프로세스가 할당 된 메모리 제한을 초과하는 경우에도이 문제가 발생할 수 있습니다. 이 경우 NGINX와 PHP-FPM 간의 연결이 끊어지고 NGINX는 502 Bad Gateway를 반환합니다. PHP-FPM 프로세스 메모리 한계는 memory_limit 변수에 의해 제어됩니다. PHP-FPM 구성 파일에서 php_admin_value[memory_limit]로 설정할 수 있습니다.

메모리 제한은 스크립트 당 단위로 적용됩니다. n PHP-FPM 프로세스에서 총 메모리 사용량은 최대 memory_limit * n입니다. 머신에 충분한 메모리 헤드 룸이 있는지 확인하십시오!

0
Francis