HTTP의 499 상태 코드와 nginx의 499 오류에 대한 비교 설명

로그 기록의 HTTP 상태 코드에 499 오류가 나타나는 경우가 많습니다. 제가 겪은 상황 중 하나는 nginx가 절대 열 수 없는 백엔드로 전환되는 것입니다. 그게 바로 로그 상태 기록이 499이고 바이트 수입니다. 0입니다.

웹사이트 시스템이 다운됐다고 신고하는 유저들이 늘 있기 마련인데, 온라인 제품이 오랫동안 수정되지 않았기 때문에 프론트엔드 프로그램의 문제는 기본적으로 배제할 수 있으니, 이라는 인터페이스가 필요하다고 생각했습니다. Get 방식이 불안정해서 물어보니 관계자분이 문제가 없다고 하더군요.. 확실한 증거를 얻기 위해 관련자에게 nginx 서버의 로그파일(awstats log)을 물어본 결과, 그 내용을 확인했습니다. 로그에 오류 코드 499의 오류가 많이 있었으며 이는 전체 로그 파일의 약 1%를 차지하며 전체 오류 보고서의 약 70%만을 차지합니다(모든 오류 보고서는 아래 그림 참조). 모든 오류 보고의 총계는 1%를 초과하며 이는 여전히 매우 큰 금액입니다.

499 오류가 무엇인가요? NGINX 소스 코드의 정의를 살펴보겠습니다.

ngx_string(ngx_http_error_495_page), /* 495, https 인증서 오류 */

ngx_string(ngx_http_error_496_page), /* 496, https 인증서 없음 */

ngx_string( ngx_http_error_497_page), / * 497, http에서 https로 */

ngx_string (ngx_http_error_404_page),/ * 498, 취소됨 */

Ngx_null_String,/ * 499, 클라이언트가 연결을 닫았습니다 */

499는 "클라이언트가 연결을 닫았습니다"에 해당합니다 ". 이는 서버 측 처리 시간이 너무 길고 클라이언트가 "참을성이 없기" 때문일 가능성이 높습니다.

Nginx 499 오류에 대한 원인 및 해결 방법

Nginx의 access.log를 열고 마지막 제출에 HTTP1.1 499 0이 나타나는지 확인합니다. Baidu에서 nginx 499 오류를 검색하면 결과에 모두 클라이언트 연결이 끊어졌다고 표시됩니다.

하지만 테스트 후 포트 + IP를 사용하여 백엔드 서버에 직접 액세스하면 이 문제가 발생하지 않기 때문에 이는 분명히 클라이언트 문제가 아닙니다. 나중에 nginx를 테스트할 때 게시물이 두 번 제출되는 것을 발견했습니다. 너무 빨리, 499가 나타날 것입니다. nginx는 안전하지 않은 연결이라고 생각하고 클라이언트의 연결을 적극적으로 거부했습니다.

그러나 관련 문제를 검색해도 해결책을 찾을 수 없었습니다. 영어 포럼에 있는 이 오류에 대한 해결책:

proxy_ignore_client_abort on;

이것이 안전한지 모르겠습니다.

이는 매개 변수 Proxy_ignore_client_abort on;

을 구성한다는 의미입니다. 이는 프록시 서버가 적극적으로 종료해서는 안 된다는 의미입니다. 클라이언트 연결.

이 구성으로 nginx를 다시 시작하면 문제가 실제로 해결됩니다. 보안이 조금 부족한 점은 있지만 항상 서버를 찾을 수 없는 것보다는 훨씬 낫습니다.

또 다른 이유는 나중에 테스트한 결과 클라이언트가 실제로 연결을 종료했거나 연결 시간이 초과되었다는 사실을 발견했기 때문입니다. 아무리 시간 초과를 설정해도 PHP 프로세스가 충분하지 않은 것으로 나타났습니다. PHP 프로세스 수 문제를 개선하고 기본 테스트 환경이 5개만 열리는 문제를 해결했습니다.

위 내용은 HTTP의 499 상태 코드와 nginx의 499 오류에 대한 비교 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!