nginx error_페이지 상세 설명

error_page 명령 해석
nginx 명령 errorpage 의 역할 은 오류 가 발생 했 을 때 미리 정 의 된 uri 를 표시 하 는 것 입 니 다. 예 를 들 어:

error_page 502 503     /50x.html;

이렇게 하면 실제 적 으로 내부 전환 (internal redirect) 이 생 겼 고 방문 이 502, 503 이 나타 날 때 50x. html 의 내용 을 되 돌려 줄 수 있 습 니 다.
동시에 우 리 는 이런 상황 에서 의 귀환 상 태 를 스스로 정의 할 수 있 습 니까? 예 를 들 어:

error_page 502 503 =200 /50x.html;

이렇게 하면 사용자 가 502, 503 을 방문 할 때 사용자 에 게 되 돌아 오 는 상 태 는 200 이 고 내용 은 50x. html 이다.
errorpage 뒤에 정적 인 내용 이 아 닌 경우, 예 를 들 어 proxyed server 나 FastCGI / uwsgi / SSCGI server 가 처리 하면 server 가 돌아 온 상태 (200, 302, 401 또는 404) 도 사용자 에 게 돌아 갈 수 있 습 니 다.

error_page 404 = /404.php;

named location 을 설정 하고 안에서 대응 하 는 처 리 를 할 수도 있 습 니 다.

500 502 503 504 @jump_to_error;
location @jump_to_error {    
    ...
}

또한 클 라 이언 트 로 하여 금 302, 301 등 방향 을 바 꾸 는 방식 으로 오류 페이지 를 처리 할 수 있 고 기본 상태 코드 는 302 이다.

error_page 403      http://example.com/forbidden.html;
error_page 404 =301 http://example.com/notfound.html;

또한 error page 는 한 번 의 요청 에 한 번 만 응답 할 수 있 습 니 다. 대응 하 는 nginx 는 이 옵션 을 제어 할 수 있 는 다른 설정 이 있 습 니 다. recursive error pages 는 기본적으로 false 입 니 다. error page 가 한 번 의 요청 에서 여러 번 실행 할 수 있 는 지 를 제어 하 는 역할 을 합 니 다.
더 자세 한 정 보 는 nginx 공식 문 서 를 참고 할 수 있 습 니 다: error page 공식 문서 recursive error pages 공식 문서
인 스 턴 스 사용
error page 를 사용 하여 웹 사이트 강등 서 비 스 를 진행 합 니 다.
다음은 error page 를 이용 하여 자주 사용 하 는 강등 방안 을 소개 합 니 다. nginx 기반 웹 사이트 의 경우 사용자 의 방문 이 너무 많 으 면 nginx 가 50x 오류 로 돌아 갈 수 있 습 니 다. 그러면 사용자 가 오류 페이지 를 볼 수 있 습 니 다. 매우 우호 적 이지 않 습 니 다. 정적 인 사이트 라면 이러한 오류 가 발생 했 을 때 정적 화 된 페이지 를 보 게 됩 니 다.사용자 에 게 되 돌아 가 는 것 도 극단 적 인 상황 에서 비교적 적합 한 강등 방안 입 니 다. 저 희 는 정기 적 으로 curl 페이지 에 가서 정적 인 html 페이지 를 만 든 다음 오류 가 발생 했 을 때 nginx lua 를 사용 하여 정적 페이지 를 가 져 와 사용자 에 게 되 돌려 줍 니 다.
예제 설정 은 다음 과 같 습 니 다.

server {
    ...
    location @jump_to_error {
        lua_code_cache on;
        content_by_lua_file /project_home/lua/error.lua;
    }
    error_page 500 502 503 504 @jump_to_error;
}

질문
error page 처 리 를 거 친 후에 사용자 에 게 되 돌아 오 는 상태 코드 가 대응 하 는 5xx 인 것 을 관찰 하 였 습 니 다. 이 때 페이지 는 gzip 에 의 해 되 지 않 고 대응 하 는 설정 을 다음 과 같이 바 꾸 었 습 니 다.

error_page 500 502 503 504 =200 @jump_to_error;

이렇게 하면 페이지 는 gzip 에 의 해 이 루어 집 니 다. 그러나 이렇게 하면 access log 에서 대응 하 는 반환 코드 가 원래 의 5xx 가 아니 라 200 이라는 것 을 볼 수 있 기 때문에 우리 가 오 류 를 찾 는 데 불리 합 니 다. 이런 잘못된 상황 에서 포 지 셔 닝 문제 가 더욱 중요 합 니 다. gzip 이 없 는 것 은 큰 영향 을 미 치지 않 기 때문에 마지막 으로 우 리 는 이런 방식 을 사용 하지 않 고 원래 의 방식 을 변 하지 않 는 다 고 평가 합 니 다. 마지막 으로 조사 연 구 를 통 해 다음 과 같이 하 겠 습 니 다.어떤 nginx 가 이렇게 처리 되 는 지, nginx 의 원본 코드 에 해당 하 는 처리 가 있 는 것 을 보 았 습 니 다. 코드 는 다음 과 같 습 니 다: nginx / src / http / modules / ngx http gzip filter module. c

static ngx_int_t
ngx_http_gzip_header_filter(ngx_http_request_t *r) 
{
    ... 
    conf = ngx_http_get_module_loc_conf(r, ngx_http_gzip_filter_module);
    if (!conf->enable
        || (r->headers_out.status != NGX_HTTP_OK
        && r->headers_out.status != NGX_HTTP_FORBIDDEN
        && r->headers_out.status != NGX_HTTP_NOT_FOUND)
        || (r->headers_out.content_encoding
        && r->headers_out.content_encoding->value.len)
        || (r->headers_out.content_length_n != -1
        && r->headers_out.content_length_n < conf->min_length)
        || ngx_http_test_content_type(r, &conf->types) == NULL
        || r->header_only)
    {   
        return ngx_http_next_header_filter(r);
    }   
    ... 
}

코드 에서 돌아 오 는 header 안의 status 가 200, 403 또는 404 인지 직접 판단 할 수 있 습 니 다. 그렇지 않 으 면 gzip filter 모듈 을 건 너 뛰 십시오.
왜 nginx 가 이렇게 처리 해 야 하 는 지 파 보 았 습 니 다. nginx 의 mailing list 에서 어떤 사람 이 질문 하 는 것 을 보 았 습 니 다. nginx 개발 팀 은 해답 을 주 었 습 니 다. 밤 을 들 었 습 니 다. 예 를 들 어 서버 원인 으로 인해 메모리 배분 이 이상 하여 사용자 에 게 500 을 되 돌 릴 때 내부 저장 을 분배 하여 gzip 을 진행 하 는 것 이 적당 하지 않 습 니 다. 관심 이 있 는 학생 들 은 자세히 볼 수 있 습 니 다. 링크: nginx 개발 팀error page 에 대해 gzip 의 해답 을 하지 않 습 니 다.