Nginx 502 bad gateway 와 Nginx 504 Gateway Time - out 오류 해결 방법 오류 해결 방법

최근 에 서버 가 다운 되 는 현상 이 비교적 빈번 합 니 다. 퇴근 시간 에 G 가 끊 겼 습 니 다. 502 Bad Gateway Nginx 는 저도 모 르 게 예전 의 504 Gateway Time - out 을 떠 올 리 게 합 니 다. 이들 은 연락 이 있 을 것 입 니 다. 반드시 알 아야 합 니 다.Nginx 504 Gateway Time - out 은 요청 한 게 이 트 웨 이 가 요청 되 지 않 았 다 는 뜻 으로, 쉽게 말 해 실행 가능 한 PHP - CGI 가 요청 되 지 않 았 다 는 뜻 이다.
이 두 가지 문 제 를 해결 하 는 데 는 종합 적 인 사고 가 필요 하 다. 일반적으로 Nginx 502 Bad Gateway 는 pp - fpm. conf 의 설정 과 관련 이 있 고 Nginx 504 Gateway Time - out 은 nginx. conf 의 설정 과 관련 이 있다.
Nginx 504 Gateway 는 이전 글 에 기록 되 어 있 습 니 다. 여 기 는 잠시 무시 하고 502 bad gateway 의 해결 방법 을 직접 말 합 니 다. 가장 중요 한 것 은 pp - fpm. conf 의 설정 입 니 다.pp - fpm. conf 는 두 가지 중요 한 매개 변수 가 있 는데 하 나 는 'max' 입 니 다.children ", 다른 하 나 는" request "입 니 다.terminate_"timeout", 이 두 값 은 계산 해 야 합 니 다.
서버 성능 이 충분 하고 광대 역 자원 이 충분 하 다 면 PHP 스 크 립 트 가 순환 되 지 않 거나 BUG 가 없 으 면 "request" 를 직접 사용 할 수 있 습 니 다.terminate_timeout '을 0 s 로 설정 합 니 다.○ s 는 시간 제한 없 이 PHP - CGI 를 계속 실행 하 라 는 뜻 이다.만약 당신 이 이 점 을 하지 못 한다 면, 즉 당신 의 PHP - CGI 에 어떤 버그 가 나타 날 수 있 거나, 당신 의 광대 역 이 충분 하지 않 거나, 다른 원인 으로 인해 당신 의 PHP - CGI 가 가짜 로 죽 을 수 있다 면, "request" 를 주 는 것 을 권장 합 니 다.terminate_timeout "값 을 부여 합 니 다. 이 값 은 서버 의 성능 에 따라 설정 할 수 있 습 니 다.일반적으로 성능 이 좋 을 수록 설정 할 수 있 습 니 다.
”max_children '이 값 은 또 어떻게 계산 되 었 습 니까?이 값 은 원칙적으로 클 수록 좋 습 니 다. pp - cgi 의 프로 세 스 가 많 으 면 빨리 처리 되 고 줄 을 서 는 요청 이 적 습 니 다.설정 "maxchildren '도 서버 의 성능 에 따라 설정 해 야 합 니 다. phop - cgi 에 소모 되 는 메모리 가 20m 정도 라면, "max"children '을 80, 20m * 80 = 1600 M 으로 설정 한 것 은 피크 에 있 을 때 모든 PHP - CGI 소모 내 에 1600 M 이내 가 존재 하고 유효 메모리 보다 낮 으 면 된다 는 것 이다.
하면, 만약, 만약...children '설정 이 비교적 작 습 니 다. 예 를 들 어 5 - 10 개 를 설정 하면 pp - cgi 는' 피곤 합 니 다 '. 처리 속도 도 느 리 고 기다 리 는 시간 도 길 습 니 다.장시간 처리 요청 을 받 지 못 하면 504 Gateway Time - out 이라는 오류 가 발생 하고, 처리 중인 '피곤 합 니 다' 의 php - cgi 몇 개가 문제 가 발생 하면 502 Bad gateway 라 는 오류 가 발생 합 니 다.
다음은 더욱 상세 한 소개 자료 입 니 다. 일부 Nginx 에서 운영 되 는 사이트 에 서 는 가끔 '502 Bad Gateway' 오류 가 발생 하고 가끔 은 자주 발생 합 니 다.다음은 소 편 이 수집 하고 정리 한 Nginx 502 의 잘못된 조사 방법 입 니 다. 참고 하 시기 바 랍 니 다.
Nginx 502 오 류 는 프 록 시 모드 에서 백 엔 드 서버 에 문제 가 생 겨 발생 한 원인 이 많 습 니 다.이러한 오 류 는 일반적으로 nginx 자체 의 문제 가 아니 므 로 반드시 백 엔 드 에서 원인 을 찾 아야 합 니 다!그러나 nginx 는 이러한 실 수 를 모두 자신 에 게 맡 겼 고 nginx 의 홍보 자 들 로 하여 금 의심 을 받 게 했다. 왜냐하면 단어 적 으로 'bad gateway' 를 이해 하기 때문이다.바로 badnginx 아닌가 요?모 르 는 사람 에 게 보 여주 면 직접 nginx 에 게 책임 을 떠 넘 기 고 nginx 다음 버 전 은 오류 알림 을 약간 우호 적 으로 쓰 기 를 바 랍 니 다. 적어도 현재 의 간단 한 문장 인 502 Bad Gateway 는 아 닙 니 다. 그리고 자신의 이름 을 붙 이 는 것 도 잊 지 않 습 니 다.
Nginx 502 의 트리거 조건 502 오류 가 발생 하 는 가장 일반적인 상황 은 백 엔 드 호스트 가 컴퓨터 에 있 는 것 입 니 다.upstream 설정 에 다음 설정 이 있 습 니 다: proxynext_upstream, 이 설정 은 nginx 가 백 엔 드 호스트 에서 데 이 터 를 가 져 오 는 데 어떤 오류 가 발생 했 을 때 다음 백 엔 드 호스트 로 이동 하 는 지 지정 합 니 다. 안에 적 힌 것 은 502 의 모든 상황 이 발생 하 는 것 입 니 다. 기본 값 은 error timeout 입 니 다.error 는 바로 컴퓨터, 단선 같은 것 입 니 다. timeout 은 읽 기 막 히 고 시간 이 초과 되 어 이해 하기 쉽 습 니 다.나 는 보통 모두 쓴다.

 
  
proxy_next_upstream error timeout invalid_header http_500 http_503;　 
  
 
 

하지만 지금 은 http 를 없 애 야 할 것 같 습 니 다.500 이 항목 입 니 다. http500 지정 한 백 엔 드 가 500 오 류 를 되 돌 릴 때 호스트 를 돌 립 니 다. 백 엔 드 jsp 가 잘못 되면 stacktrace 의 오류 정 보 를 인쇄 할 수 있 었 는데 502 로 대체 되 었 습 니 다.그러나 회사 의 프로그래머 들 은 그렇게 생각 하지 않 습 니 다. 그들 은 nginx 에 오류 가 생 겼 다 고 생각 합 니 다. 저 는 그들 에 게 502 의 원 리 를 설명 할 시간 이 없습니다.
503 오 류 는 보류 할 수 있 습 니 다. 백 엔 드 는 보통 apache resin 이기 때문에 apache 가 다운 되면 error 이지 만 resin 이 다운 되 고 503 에 불과 하기 때문에 보류 할 필요 가 있 습 니 다.
해결 방법
502 문제 에 부 딪 히 면 다음 과 같은 두 단계 로 해결 하 는 것 을 우선적으로 고려 할 수 있다.1. 현재 PHP FastCGI 프로 세 스 수가 충분 한 지 확인 하기:

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

실제 사 용 된 'FastCGI 프로 세 스 수' 가 미리 설 정 된 'FastCGI 프로 세 스 수' 에 가깝다 면 'FastCGI 프로 세 스 수' 가 부족 하고 커 져 야 한 다 는 뜻 이다.
2. 일부 PHP 프로그램의 실행 시간 이 Nginx 의 대기 시간 을 초과 하여 nginx. conf 설정 파일 에서 FastCGI 의 timeout 시간 을 적당 하 게 증가 시 킬 수 있 습 니 다. 예 를 들 어:

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

php. ini 중 memorylimit 설정 을 낮 추 면 오류 가 발생 합 니 다. php. ini 의 memory 를 수 정 했 습 니 다.limit 은 64M 입 니 다. nginx 를 다시 시작 합 니 다. PHP 메모리 가 부족 한 것 을 발 견 했 습 니 다.
만약 이렇게 수정 해도 문 제 를 해결 할 수 없다 면 다음 과 같은 방안 을 참고 할 수 있다.
1. max - children 과 max - requests 한 서버 에서 nginx phop (fpm) xcache 를 실행 하고 있 으 며, 방 문 량 은 하루 평균 300 W pv 정도 입 니 다.
최근 에는 phop 페이지 가 늦게 열 리 고 cpu 사용률 이 갑자기 낮 아 지면 서 시스템 부하 가 갑자기 높 아 졌 다. 네트워크 카드 의 트 래 픽 을 보면 갑자기 낮 아 졌 다 는 것 을 알 수 있다.이런 상황 은 몇 초 만 에 회복 되 었 다.
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 줄 이 넘 는 children 을 닫 고 children 의 로 그 를 엽 니 다.
원래 php - fpm 에 인자 max 가 있 었 습 니 다.requests, 이 매개 변 수 는 children 당 최대 몇 개의 요청 을 처리 하면 닫 히 고 기본 설정 은 500 입 니 다.php 는 요청 을 모든 children 에 게 돌아 가면 서 대량의 데이터 에서 childre 마다 max 에 도달 하기 때 문 입 니 다.requests 가 사용 하 는 시간 이 많 지 않 아서 모든 children 이 기본적으로 같은 시간 에 닫 힙 니 다.
이 기간 에 nginx 는 phop 파일 을 phop - fpm 에 전달 할 수 없 기 때문에 cpu 는 매우 낮 아 집 니 다 (phop 을 처리 하지 않 고 sql 을 실행 하지 않 아 도 됩 니 다). 부하 가 높 아 집 니 다 (children 을 닫 고 켜 고 nginx 는 phop - fpm 를 기다 리 고 있 습 니 다). 네트워크 카드 트 래 픽 도 낮 아 집 니 다 (nginx 는 데이터 전송 을 클 라 이언 트 에 생 성 할 수 없습니다).
문 제 를 해결 하 는 것 은 간단 합 니 다. children 의 수 를 늘 리 고 maxrequests 설정 이 0 이 되 지 않 았 거나 큰 값:
/ usr / local / phop / etc / phop - fpm. conf 를 열 고 다음 두 개의 인 자 를 조정 합 니 다 (서버 의 실제 상황 에 따라 너무 커 도 안 됩 니 다)

 
  
5120 600　　 
  
 
 

그리고 php - fpm 를 다시 시작 합 니 다.
2. 버퍼 용량 크기 증가
nginx 의 error log 를 열 어 보 니 "pstream sent too big header while reading response header from upstream"이러한 오류 알림 입 니 다. 자 료 를 찾 아 보 았 습 니 다. 대 의 는 nginx 버퍼 에 bug 가 있어 서 발생 한 것 입 니 다. 저희 사이트 의 페이지 소모 가 버퍼 를 너무 많이 차지 할 수 있 습 니 다. 외국인 이 쓴 수정 방법 을 참고 하여 버퍼 용량 크기 설정 을 추 가 했 습 니 다. 502 문 제 는 철저히 해결 되 었 습 니 다. 나중에 시스템 관리 자 는 매개 변 수 를 조정 하여 2 개의 설정 매개 변수 만 남 겼 습 니 다. client head buffer, fastcgi.buffer size。
3. request terminate timeout 은 정적 페이지 작업 에서 흔히 볼 수 있 는 것 이 아니 라 post 나 데이터 베 이 스 를 작업 할 때 502 상황 이 발생 한다 면 pp - fpm. conf 설정 중 하 나 를 볼 수 있 습 니 다.
request_terminate_timeout
이 값 은 max execution time 입 니 다. 바로 fast - cgi 의 실행 스 크 립 트 시간 입 니 다.
0s
0 s 는 닫 기 위해 무한 실행 합 니 다. (패션 을 할 때 자세히 보지 않 고 숫자 를 바 꾸 었 습 니 다) 문제 가 해결 되 었 습 니 다. 오래 실행 해도 틀 리 지 않 습 니 다. fastcgi 를 최적화 하면 이 값 5s 를 고 쳐 서 효 과 를 볼 수 있 습 니 다.
php - cgi 프로 세 스 수가 부족 하거나 php 가 오래 실행 되 거나 php - cgi 프로 세 스 가 죽 으 면 502 오류 가 발생 합 니 다.