nginx 502 잘못된 게이트웨이 오류를 해결하는 방법

WBOY
풀어 주다: 2023-05-20 15:16:06
앞으로
4756명이 탐색했습니다.

nginx 502 트리거 조건

 502 오류의 가장 일반적인 발생은 백엔드 호스트가 충돌할 때입니다. 업스트림 구성에는 다음과 같은 구성이 있습니다: Proxy_next_upstream 이 구성은 nginx가 백엔드 호스트에서 데이터를 가져올 때 발생하는 오류의 종류를 지정합니다. 여기에 기록된 내용은 모두입니다. 상황에 따라 502가 표시되며 기본값은 오류 시간 초과입니다. 오류는 충돌, 연결 끊김 등을 의미합니다. 시간 초과는 읽기 차단 시간 초과를 의미하므로 이해하기 쉽습니다. 나는 일반적으로 전체 내용을 작성합니다.

proxy_next_upstream error timeout valid_header http_500 http_503; 그러나 이제 http_500 항목을 제거해야 할 수도 있습니다. http_500은 백엔드가 500 오류를 반환할 때 호스트로 전송하도록 지정합니다. 오류가 발생하면 원래는 여러 스택 추적 오류 메시지가 인쇄되며 이제 502로 대체됩니다. 하지만 회사의 프로그래머들은 그렇게 생각하지 않습니다. 그들은 nginx에 오류가 있다고 생각합니다. 저는 정말로 그들에게 502의 원리를 설명할 시간이 없습니다...

백엔드가 있기 때문에 503 오류가 유지될 수 있습니다. 보통 apache resin입니다. apache가 충돌하면 오류가 나지만, 충돌한 레진은 503에 불과하므로 계속 유지해야 합니다.

Solution

502 문제가 발생하면 다음 두 단계를 우선적으로 수행하여 문제를 해결할 수 있습니다.

1. 현재 PHP fastcgi 프로세스 수가 충분한지 확인하세요.

코드를 복사하세요. 코드는 다음과 같습니다.

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

of fastcgi 프로세스 수'가 실제로 사용됩니다. 이는 기본 "fastcgi 프로세스 수"에 가깝습니다. 그러면 "fastcgi 프로세스 수"가 충분하지 않아 늘려야 한다는 의미입니다.

2. 일부 PHP 프로그램의 실행 시간은 nginx.conf 구성 파일에서 fastcgi의 시간 초과 시간을 적절하게 늘릴 수 있습니다.

코드를 복사하세요.

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

php.ini의 memory_limit를 낮게 설정하면 오류가 발생합니다. php.ini의 memory_limit를 64m으로 수정하고 nginx를 다시 시작한 후 Ok를 찾으세요. PHP에 메모리가 부족하다는 것이 밝혀졌습니다.

 이렇게 수정한 후에도 문제가 해결되지 않으면 다음 해결 방법을 참고하세요.

1.max-children 및 max-requests

  nginx php (fpm) xcache가 서버에서 실행 중입니다. 일 평균 방문량은 약 300만 pv입니다.

 이러한 상황은 최근 자주 발생합니다. PHP 페이지가 매우 느리게 열리고, CPU 사용량이 갑자기 매우 낮은 수준으로 떨어지며, 시스템 부하가 갑자기 매우 높은 수준으로 올라가고, 네트워크 카드의 트래픽을 확인하면 또한 갑자기 매우 낮은 수준으로 떨어지는 것을 발견하게 될 것입니다. 이 상태는 되돌리기 전까지 몇 초 동안만 지속됩니다.

 php-fpm의 로그 파일을 확인하면서 몇 가지 단서를 찾았습니다.

코드 복사 코드는 다음과 같습니다.

sep 30 08:32:23.289973 [공지] fpm_unix_init_main(), 271행: getrlimit(nofile): max:51200, cur:51200 sep 30 08:32:23.290212 [공지] ] fpm_sockets_in it_main( ), 371행: 상속된 소켓 사용 fd=10, “127.0.0.1:9000″ sep 30 08:32:23.290342 [주의] fpm_event_init_main(), 109행: libevent: epoll 사용 sep 30 08:32: 23.296426 [notice] fpm_init(), line 47: fpm is running, pid 30587 

이 문장 앞에는 자식을 닫고 자식을 여는 로그가 1,000줄 이상 있습니다.

php-fpm에는 각 하위 항목이 닫히기 전에 처리할 수 있는 최대 요청 수를 지정하는 max_requests 매개변수가 있는 것으로 나타났습니다. 기본 설정은 500입니다. PHP는 각 하위 항목에 대한 요청을 폴링하기 때문에 트래픽이 많은 경우 각 하위 항목은 max_requests에 도달하는 데 거의 동일한 시간이 걸리며 이로 인해 기본적으로 모든 하위 항목이 동시에 닫힙니다.

 이 기간 동안 nginx는 처리를 위해 PHP 파일을 php-fpm으로 전송할 수 없으므로 CPU가 매우 낮은 수준으로 떨어지며(SQL 실행은 고사하고 PHP를 처리할 필요도 없음) 부하가 매우 높아집니다. 높은 수준(자식 닫기 및 열기, nginx php-fpm 대기 중), 네트워크 카드 트래픽도 매우 낮은 수준으로 떨어졌습니다(nginx는 클라이언트에 전송할 데이터를 생성할 수 없음)

 문제에 대한 해결책은 매우 간단합니다. 자식 수를 늘리고 max_requests를 0보다 작거나 상대적으로 큰 값으로 설정합니다:

/usr/local/php/etc/php-fpm.conf를 열고 다음 두 매개변수를 늘립니다(실제 상황에 따라). 서버가 너무 크면 작동하지 않음)

코드 복사 코드는 다음과 같습니다.


600 

그런 다음 php-fpm을 다시 시작하세요.

2. 버퍼 용량 늘리기

nginx 오류 로그를 열고 "업스트림에서 응답 헤더를 읽는 동안 pstream이 너무 큰 헤더를 보냈습니다."와 같은 오류 메시지를 찾습니다. 정보를 확인한 결과, 우리 웹사이트의 페이지 소비 버퍼가 너무 클 수 있다는 일반적인 생각이 들었습니다. 외국인이 작성한 수정 방법을 참고하면 버퍼 용량 설정이 늘어나고 502 문제가 완전히 해결됩니다. 나중에 시스템 관리자는 매개변수를 조정하고 클라이언트 헤드 버퍼와 fastcgi 버퍼 크기라는 두 가지 설정 매개변수만 유지했습니다.

3.request_terminate_timeout

 502가 정적 페이지 작업에서 일반적이지 않고 주로 일부 게시물이나 데이터베이스 작업 중에 발생하는 경우 php-fpm.conf 설정 중 하나를 확인할 수 있습니다:

request_terminate_timeout

이 값은 max_execution_time이 빠른 실행 스크립트 시간입니다. -cgi.

0s

0s가 닫혀 있으므로 무기한으로 계속 실행됩니다. (설치시 주의깊게 보지 않고 번호를 바꿨습니다.) 문제가 해결되어 오랫동안 실행에 오류가 없을 것입니다. fastcgi를 최적화할 때 이 값을 5초 동안 변경하여 효과를 확인할 수도 있습니다.

php-cgi 프로세스 수가 부족하거나, php 실행 시간이 길거나, php-cgi 프로세스가 종료되면 502 오류가 발생합니다.

nginx 502 잘못된 게이트웨이 오류 해결 방법 2

오늘 vps를 다시 시작한 후 vps에서 자주 nginx 502 잘못된 게이트웨이 오류가 발생하여 매우 짜증났습니다. 좀 헷갈리네요. 지난 이틀 동안 1290번의 방문자가 아무런 문제 없이 발생했습니다. 이번에는 왜 502 불량 게이트웨이가 나타났나요? 우울하다! ! ! 오랫동안 검색한 결과, 관련 답변을 많이 찾았습니다. 수정 후에는 이러한 오류가 다시 발생하지 않기를 바랍니다. 아아, 너무 오랫동안 인터넷에서 답을 찾아다녔으니, 다음번에 다시 구글에 갈 일이 없도록 유용한 내용은 당연히 기록해두어야지~

lnmp 원클릭을 사용했으니까 설치 패키지에 문제가 있으면 먼저 공식 포럼을 검색해 봤습니다. 이런 공식 고정 게시물이 있습니다.

lnmp 원클릭 설치 패키지 공식:

첫 번째 이유: 현재 lnmp 원클릭 설치 패키지의 가장 일반적인 문제는 502 잘못된 게이트웨이입니다. 대부분의 경우 그 이유는 PHP를 설치하기 전에 일부 lib 패키지가 스크립트가 설치되지 않아 PHP가 성공적으로 컴파일 및 설치되지 않을 수 있습니다.
해결책: lnmp 원클릭 설치 패키지의 스크립트에 따라 수동으로 설치하여 오류의 원인을 확인할 수 있습니다.

두 번째 이유:

php.ini에서 eaccelerator 구성 항목은 zend 최적화 구성 이전에 배치되어야 합니다. 그렇지 않으면 502 잘못된 게이트웨이가 발생할 수도 있습니다.

세 번째 이유:

설치 및 사용 중에 나타남 502 문제 이는 일반적으로 기본 php-cgi 프로세스가 5이기 때문에 발생합니다. 502는 phpcgi 프로세스가 부족하여 발생할 수 있습니다. max_children 값을 적절하게 늘리려면 /usr/local/php/etc/php-fpm.conf를 수정해야 합니다.

네 번째 이유:

php 실행 시간 초과, /usr/local/php/etc/php.ini를 수정하여 max_execution_time을 300으로 변경

다섯 번째 이유:

mysql 로그 등 디스크 공간이 부족하여 많은 공간을 차지

6번째 이유:

php-cgi 프로세스가 실행 중인지 확인하세요

일부 네티즌들은 또 다른 해결책을 제시했습니다:

nginx 502 잘못된 게이트웨이는 요청한 php-cgi가 실행되었음을 의미하지만 어떤 이유로 인해 (보통 리소스를 읽는 문제) 실행이 완료되지 않아 php-cgi 프로세스가 종료되는 것입니다. 일반적으로 nginx 502 불량 게이트웨이는 php-fpm.conf 설정과 관련이 있습니다.

php-fpm.conf에는 두 개의 중요한 매개변수가 있습니다. 하나는 max_children이고 다른 하나는 request_terminate_timeout이지만 이 값은 보편적이지 않으며 직접 계산해야 합니다.
설치 및 사용 중 502 문제가 발생합니다. 일반적으로 기본 php-cgi 프로세스가 5개이기 때문입니다. phpcgi 프로세스가 부족하여 발생할 수 있습니다. /usr/local/php/etc/php-fpm을 수정해야 합니다. max_children 값이 적절하게 증가합니다.

계산 방법은 다음과 같습니다.

서버 성능이 좋고 광대역 리소스가 충분하며 PHP 스크립트에 루프나 버그가 없으면 request_terminate_timeout을 0으로 직접 설정할 수 있습니다. 0의 의미는 php-cgi가 시간 제한 없이 계속 실행되도록 하는 것입니다. 그리고 이를 수행할 수 없는 경우, 즉 php-cgi에 버그가 있거나 대역폭이 충분하지 않거나 기타 이유로 인해 php-cgi가 정지되는 경우 값을 할당하는 것이 좋습니다. request_terminate_timeout으로 이 값은 서버 성능에 따라 설정될 수 있습니다. 일반적으로 성능이 좋을수록 20분에서 30분 사이에서 더 높게 설정할 수 있습니다.
max_children의 값은 어떻게 계산되나요? 원칙적으로 값이 클수록 좋습니다. php-cgi 프로세스가 많을수록 처리 속도가 빨라지고 대기 중인 요청이 줄어듭니다. max_children 설정도 서버 성능에 따라 설정해야 합니다. 일반적으로 서버에서 각 php-cgi가 소비하는 메모리는 일반적인 상황에서 약 20m입니다.

공식 답변에 따라 관련 가능성을 확인하였고, 네티즌들의 답변을 종합하여 다음과 같은 해결방안을 생각해냈습니다.

1. php fastcgi의 프로세스 수 확인(max_children 값)

코드: netstat -anpo | grep "php-cgi" | wc -l

5(5가 표시되는 경우)

2. process

Code :top
fastcgi 프로세스 수를 관찰하세요. 사용된 프로세스 수가 5개 이상인 경우에는 이를 늘려야 함을 의미합니다(머신의 실제 상황에 따라 다름)

3. /usr/local/php/etc/php-fpm.conf 관련 설정 조정

10
60s
max_children은 최대 10개의 프로세스를 가질 수 있으며 프로세스당 메모리는 20MB, 최대 200MB입니다.
request_terminate_timeout의 실행 시간은 60초, 즉 1분입니다.

위 내용은 nginx 502 잘못된 게이트웨이 오류를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

관련 라벨:
원천:yisu.com
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿