nginx 502 bad 고장 원인 및 해결 방법 수집

예 를 들 어 최근 사이트 에 502 오류 가 빈번히 발생 하여 정상적으로 작 동 하지 못 하고 있 습 니 다. 이러한 상황 은 대부분 phop - cgi 가 시간 을 초과 하여 정 보 를 되 돌려 주지 않 거나 프로 세 스 가 경직 되 는 등 상황 으로 인 한 것 입 니 다.우리 의 nginx 는 이미 극치 까지 설정 되 었 는데, 이것 은 이미 오래전 에 수정 을 했 지만, 지금 은 또 나타 나 고 있다.
분석 을 통 해 nginx 의 error 를 log 열기, 발견 "pstream sent too big header while reading response header from "upstream" 과 같은 오류 알림 은 자 료 를 찾 아 보 았 습 니 다. 대 의 는 nginx 버퍼 에 bug 가 있어 서 저희 사이트 의 페이지 소모 가 버퍼 를 너무 많이 차지 할 수 있 습 니 다.외국인 이 쓴 수정 방법 을 참고 하여 버퍼 용량 크기 설정 을 추 가 했 고 502 문 제 를 철저히 해결 했다. 그 후에 시스템 관리자 가 매개 변 수 를 조정 하여 2 개의 설정 매개 변수 만 보류 했다. client head buffer，fastcgi buffer size。
참고: 대
http://www. sudone .com/nginx/nginx_400_bad_request.html
http://blog. rackcorp .com/?p=14
2. 어제 nginx 를 설치 한 후 부하 가 높 을 때 포럼 에 사진 을 올 리 거나 장시간 스 크 립 트 를 실 행 했 을 때 502 가 계속 나 타 났 습 니 다. Bad Gateway ，인터넷 에서 검색 해 보 니 대부분 장 대사의 그 해결 방안 이 었 다. 그의 해결 방안 은?
  1 http 2 { 3 fastcgi_connect_timeout 300; 4 fastcgi_send_timeout 300; 5 fastcgi_read_timeout 300; 6 }
 
fastcgi 의 요청 시간 이 증가 하 였 습 니 다.그러나 저 는 실제 적 으로 이 문 제 를 만 났 습 니 다. 500 까지 설정 하면 나타 날 수 있 습 니 다. 다만 제 가 120 을 설정 할 때 보다 조금 적 습 니 다.나중에 주로 post 나 데이터 베 이 스 를 조작 할 때 이런 상황 이 발생 하고 정적 페이지 는 나타 나 지 않 는 다 는 것 을 발견 했다. 
반복 적 으로 문 제 를 조사 하고 디 버 깅 하 며 CGI 의 프로 세 스 수 를 늘 렸 다.
무기, ip 조회, 핸드폰 번호, proxy, 일기예보, 기차 시간, 신분증 번호, 비행기 편, 신화 사전 조회 등  S6 b4 \) y& c( \! j) ]
256 에다 가 느 려 질 수도 있어.메모리 사용량 이 많아 졌 다.123cha.com1 u& }. p1 [7 b% L/ \0 \
php - fpm. conf 설정 에 또 하나 가 있 습 니 다. 그 때 눈치 채 지 못 했 는 지 본의 아니 게 이 값 을 바 꾸 었 습 니 다.
request_terminate_timeout
이 값 은 max execution time 입 니 다. 바로 fast - cgi 의 실행 스 크 립 트 시간 입 니 다.
0s 123cha.com* S( v, U9 D5 q6 T; i* z6 u- R
0 s 는 닫 기 위해 무한 실행 합 니 다.
문제 가 해결 되 었 으 니 오랫동안 집행 해도 틀 리 지 않 을 것 이다.
fastcgi 최적화 중, 이 값 5s 변경 가능 。효과 좀 봐.
드디어 502 의 오 류 는 nginx 의 문제 가 아니 라 는 것 을 알 게 되 었 습 니 다.
pp - cgi 프로 세 스 수가 부족 하거나 phop 실행 시간 이 길 거나 phop - cgi 프로 세 스 가 죽 으 면 502 오류 가 발생 합 니 다.
셋째,
서버 에서 nginx 가 실행 되 고 있 습 니 다. php(fpm) xcache, 방 문 량 일 평균 300W pv 정도
최근 에 이런 상황 이 자주 발생 한다. pp 페이지 가 느리게 열 리 고 cpu 사용률 이 갑자기 낮 아 졌 습 니 다. 시스템 부하 가 갑자기 높 아 졌 습 니 다. 네트워크 카드 의 트 래 픽 을 보면 갑자기 낮 아 졌 습 니 다. 이런 상황 은 몇 초 만 에 회복 되 었 습 니 다.
php - fpm 로그 파일 검사 에서 단 서 를 발 견 했 습 니 다.
이 몇 마디 앞 에는 1000 여 줄 의 children 닫 기와 children 로그 열기 가 있 습 니 다.
원래 php - fpm 에 인자 가 있 습 니 다. max_requests ，이 매개 변 수 는 모든 children 이 최대 몇 개의 요청 을 처리 하면 닫 힌 다 는 것 을 가리 키 며, 기본 설정 은 500 입 니 다. phop 은 요청 을 모든 children 에 게 문의 하기 때 문 입 니 다. 대 유량 에서 모든 childre 가 max requests 에 도착 하 는 데 걸 리 는 시간 이 많 지 않 기 때문에 모든 children 은 기본적으로 같은 시간 에 닫 힙 니 다.
이 기간 에 nginx 는 phop 파일 을 phop - fpm 에 전달 할 수 없 기 때문에 cpu 는 매우 낮 아 집 니 다. O" ], O  w$ q/ v1 X* D
문 제 를 해결 하 는 것 은 간단 하 다. children 의 수 를 늘 리 고 max_requests 설정 하지 않 음 0 또는 비교적 큰 값, php - fpm 재 부팅
 
넷,
nginx 502 오류 의 원인 이 많은 이 유 는 프 록 시 모드 에서 백 엔 드 서버 에 문제 가 생 겨 서 발생 한 것 입 니 다. 이러한 오 류 는 일반적으로 nginx 자체 의 문제 가 아니 므 로 반드시 백 엔 드 에서 원인 을 찾 아야 합 니 다. 그러나 nginx 는 이러한 오 류 를 모두 자신 에 게 맡 겼 습 니 다. nginx 의 홍보 자 들 로 하여 금 의심 을 받 게 합 니 다. 왜냐하면 단어 적 으로 이해 하면 bad 입 니 다. gateway? bad 아니 야. nginx 요? 모 르 는 사람 에 게 보 여주 면 직접 nginx 에 게 책임 을 떠 넘 길 것 입 니 다. nginx 다음 버 전 은 오류 알림 을 조금 우호 적 으로 쓰 기 를 바 랍 니 다. 적어도 지금 간단 한 문장 502 는 아 닙 니 다. Bad 게 이 트 웨 이, 그리고 자신의 이름 을 동봉 하 는 것 도 잊 지 않 는 다.
502 오류 의 가장 일반적인 상황 은 백 엔 드 호스트 가 컴퓨터 에 있 는 것 입 니 다. 물론 있 습 니 다. upstream 설정 에 이러한 설정 이 있 습 니 다. proxy next upstream. 이 설정 은 nginx 가 백 엔 드 호스트 에서 데 이 터 를 가 져 오 는 데 어떤 오류 가 발생 했 을 때 다음 백 엔 드 호스트 로 넘 어 갈 지 지정 합 니 다. 안에 적 힌 것 은 502 의 모든 상황 이 발생 할 것 입 니 다. 기본 값 은 error 입 니 다. timeout, error 는 바로 컴퓨터, 단선 과 같은 것 입 니 다. timeout 은 막 힌 시간 을 읽 고 이해 하기 쉽 습 니 다. 저 는 보통 다 적 습 니 다.
proxy_next_upstream error timeout invalid_header http_500 http_503;
하지만 이 제 는 http 500 을 제거 해 야 할 것 같 습 니 다. http 500 지정 백 엔 드 가 500 오 류 를 되 돌 릴 때 호스트 를 돌 립 니 다. 백 엔 드 jsp 가 잘못 되면 stacktrace 의 오류 정 보 를 인쇄 했 는데 502 로 대체 되 었 습 니 다. 그러나 회사 의 프로그래머 들 은 nginx 에 오류 가 발생 했다 고 생각 하지 않 습 니 다. 저 는 그들 에 게 502 의 원 리 를 설명 할 시간 이 없습니다.
invalid header 나 도 도대체 무엇 을 가리 키 는 지 제대로 알 아내 지 못 했 어. 나 도 먼저 빼 고 싶 어.
503 오 류 는 유지 할 수 있 습 니 다. 백 엔 드 는 보통 apache 이기 때 문 입 니 다. resin, apache 가 다운 되면 error 이지 만 resin 이 다운 되 는 것 은 503 에 불과 하기 때문에 보류 할 필요 가 있 습 니 다.
 
어제 어떤 친구 가 나 에 게 웹 서버 를 Nginx 로 바 꾸 라 고 물 었 다. 0.6.31  + PHP 4.4.7 (FastCGI) 이후 에 가끔 방문 하면 '502' 가 나온다. Bad Gateway '오류, 어떻게 해결 합 니까?
다음 두 단계 로 해결 하 겠 습 니 다. 마지막 으로 두 번 째 단계 에서 FastCGI 의 timeout 시간 을 300 으로 늘 리 고 문 제 를 해결 하 겠 습 니 다.
PS: 천둥 치 는 웹 서버, 16G 메모리 가 부 럽 습 니 다.
1. 현재 PHP 보기 FastCGI 프로 세 스 수가 충분 한 지 여부:
netstat -anpo | grep "php-cgi" | wc -l
실제 사 용 된 'FastCGI 프로 세 스 수' 가 미리 설 정 된 'FastCGI 프로 세 스 수' 에 가깝다 면 'FastCGI 프로 세 스 수' 가 부족 하고 커 져 야 한 다 는 뜻 이다.
2. 일부 PHP 프로그램의 실행 시간 이 Nginx 의 대기 시간 을 초과 하여 nginx. conf 설정 파일 에서 FastCGI 의 timeout 시간 을 적당 하 게 증가 시 킬 수 있 습 니 다. 예 를 들 어:
  01 ...... 02 http 03 { 04 ...... 05 fastcgi_connect_timeout 300; 06 fastcgi_send_timeout 300; 07 fastcgi_read_timeout 300; 08 ...... 09 } 10 ......
 
상세 한 해결 방법 은 볼 수 있다.