Nginx 설정 명령 의 실행 순서 (10)

운행  post-rewrite  단계 다음  preaccess  단계단계  access  단계 전에 실행, 고명 preaccess.
 
    표준 모듈  ngx_limit_req  화해시키다  ngx_limit_zone  이 단 계 를 실행 하면 전 자 는 요청 한 방문 빈 도 를 제어 할 수 있 고 후 자 는 방문 의 병행 도 를 제한 할 수 있다.여기 서 우 리 는 단지 그것들 과 만 났 을 뿐, 뒤에 이 두 모듈 을 전문 적 으로 접 할 기회 가 있 을 것 이다.
 
    앞에서 반복 적 으로 언급 한 표준 모듈  ngx_realip  사실 이 단계 에서 도 처리 절 차 를 등록 했다.어떤 독자 들 은 '왜 일 까? 이미 있 는 게 아니 야.  post-read  "단계 등록 처리 절차 가 있 습 니까?" 우 리 는 다음 과 같은 예 를 통 해 답 을 밝 혀 도 됩 니 다.

    server {
        listen 8080;
 
        location /test {
            set_real_ip_from 127.0.0.1;
            real_ip_header X-Real-IP;
 
            echo "from: $remote_addr";
        }
    }

먼저 본 예 에 비해 이 예 의 가장 중요 한 차 이 는  ngx_realip  설정 명령  location  설정 블록 중.앞에서 저희 가 소 개 했 잖 아 요. Nginx 매 칭.  location  에서 발생 하 다,...  find-config  단계  find-config  훨씬 늦다  post-read 단계 에서 실행 되 기 때문에  post-read  단계, 현재 요청 은 아무것도 없습니다.  location  서로 관련되다.이 예 에서 ngx_realip 설정 명령 이 모두 적 혀 있 습 니 다.  location  설정 블록 중  post-read  단계, ngx_realip 모듈 의 처리 프로그램 은 사용 가능 한 설정 정 보 를 보지 못 하면 원본 주소 의 변경 작업 을 수행 하지 않 습 니 다.
 
    이 어 려 운 문 제 를 해결 하기 위해 ngx_realip 모듈  preaccess  단계 에 처리 프로그램 을 등록 해 야 실행 할 수 있 습 니 다 location 블록 에 있 는 설정 명령 어 입 니 다.바로 이 때문에 위의 이 사례 의 운행 결 과 는 직관 적 인 기대 에 부합 되 었 다.

    $ curl -H 'X-Real-IP: 1.2.3.4' localhost:8080/test
    from: 1.2.3.4

불 행 히 도, ngx_realip 모듈 의 이 해결 방안 에는 아직도 구멍 이 존재 합 니 다. 예 를 들 어 다음 과 같은 예 가 있 습 니 다.

    server {
        listen 8080;
 
        location /test {
            set_real_ip_from 127.0.0.1;
            real_ip_header X-Real-IP;
 
            set $addr $remote_addr;
            echo "from: $addr";
        }
    }

여기  rewrite  단계 장  $remote_addr  사용자 변수 에 저 장 된 값  $addr  중, 그리고 출력.... 때문에  rewrite 단계 가 먼저  preaccess  단계 실행  ngx_realip  모듈 이 아직 없습니다.  preaccess  원본 주 소 를 단계 적 으로 바 꿀 때 최초의 원본 주 소 는 이미 있 습 니 다.  rewrite  단계 가 읽 혔 습 니 다.상례 의 실제 요구 결 과 는 우리 의 결론 을 증명 했다.

    $ curl -H 'X-Real-IP: 1.2.3.4' localhost:8080/test
    from: 127.0.0.1

출력 한 주 소 는 확실히 고 쳐 쓰 지 않 았 다.Nginx 의 "디버그 로그" 는 이 점 을 더 확인 할 수 있 습 니 다.

    $ grep -E 'http script (var|set)|realip' logs/error.log
    [debug] 32488#0: *1 http script var: "127.0.0.1"
    [debug] 32488#0: *1 http script set $addr
    [debug] 32488#0: *1 realip: "1.2.3.4"
    [debug] 32488#0: *1 realip: 0100007F FFFFFFFF 0100007F
    [debug] 32488#0: *1 http script var: "127.0.0.1"

그 중 첫 번 째 줄 디 버 깅 정보

    [debug] 32488#0: *1 http script var: "127.0.0.1"

예.  set  구문 읽 기  $remote_addr  변수정보 문자열  "127.0.0.1"  바로  $remote_addr  그때 읽 은 값.
 
    두 번 째 줄 디 버 깅 정보

    [debug] 32488#0: *1 http script set $addr

변 수 를 표시 합 니 다.  $addr  할당 작업 을 진행 하 였 습 니 다.
 
    뒤의 두 줄 정보

    [debug] 32488#0: *1 realip: "1.2.3.4"
    [debug] 32488#0: *1 realip: 0100007F FFFFFFFF 0100007F

예.  ngx_realip  모듈  preaccess  현재 요청 한 원본 주 소 를 단계 적 으로 바 꿉 니 다.우 리 는 고 친 후의 새로운 주 소 는 확실히 기대 하 는 것 을 보 았 다 1.2.3.4. 그러나 이 조작 이 발생 한 것 은 분명 하 다.  $addr  변수 할당 후 너무 늦 었 습 니 다.
 
    마지막 줄 정보

    [debug] 32488#0: *1 http script var: "127.0.0.1"

... 뿐  echo  설정 명령 이 출력 할 때 변 수 를 읽 습 니 다.  $addr  때때로 발생 하 는 것 을 우 리 는 그것 의 값 이 쓰기 전의 원본 주 소 를 바 꾸 는 것 을 보 았 다.
 
    이곳 을 보면 어떤 독자 들 은 '만약 에  ngx_realip  모듈 부재  preaccess  단계 등록 처리 프로그램, 재 rewrite 단계 등록, 그럼 상례 로 일 할 수 있 지 않 습 니까?... 때문에  ngx_rewrite  모듈 의 처리 프로그램 도 마찬가지 로 등록 되 어 있다.  rewrite  단계  (2)  특히 이런 상황 에서 서로 다른 모듈 간 의 집행 순 서 는 일반적으로 불확실 하기 때문에  ngx_realip  이 가능 하 다, ~ 할 수 있다,...  set  문장 뒤에 집행 하 다.
 
    가능 한 한  server  설정 블록 에 설정  ngx_realip  이런 모듈 은 위 에서 소개 한 이런 까다 로 운 예외 상황 을 피한다.
 
    운행  preaccess  단계 다음은 우리 의 또 다른 오 랜 친구, access 단계앞에서 우 리 는 이미 표준 모듈 ngx_access, 제3자 모듈 을 알 았 다.  ngx_auth_request  그리고 제3자 모듈  ngx_lua  의  access_by_lua  명령 은 이 단계 에서 실행 된다.
 
     access  단계  post-access  단계이 단계 의 이름 에서 우 리 는 그것 이 바짝 따 르 고 있다 는 것 을 한눈 에 알 수 있다.  access  단계 뒤에 실 행 했 습 니 다.이 단계 도...  post-rewrite  단계 가 유사 합 니 다. Nginx 모듈 등록 처리 프로그램 을 지원 하지 않 고 Nginx 핵심 에서 스스로 처리 작업 을 수행 합 니 다.post-access  단계  access  단계 실현 기준  ngx_http_core  모듈 에서 제공 하 는 설정 명령  satisfy  의 기능.
 
    여러 Nginx 모듈 에 등록  access  단계 의 처리 절차, satisfy 설정 명령 은 서로 간 의 협력 방식 을 제어 하 는 데 사용 할 수 있 습 니 다.예 를 들 어 모듈 A 와 B 가 모두 있 습 니 다.  access  단계 에 액세스 제어 와 관련 된 처리 프로그램 이 등록 되 어 있 으 면 두 가지 협력 방식 이 있다. 하 나 는 모듈 A 와 모듈 B 가 모두 검증 을 통과 해 야 통과 하 는 것 이 고, 다른 하 나 는 모듈 A 와 모듈 B 가 그 중 하 나 를 통과 하면 통과 하 는 것 이다.협력  all  방식  any  방식.기본적으로 Nginx 는  all  방식다음은 하나의 예 이다.

    location /test {
        satisfy all;
 
        deny all;
        access_by_lua 'ngx.exit(ngx.OK)';
 
        echo something important;
    }

여기  /test  인터페이스 에 동시에 설정 되 어 있 습 니 다.  ngx_access  모듈 과  ngx_lua  모듈  access  단 계 는 이 두 모듈 이 함께 검사 작업 을 한다.그 속  deny all  양보 하 다  ngx_access  모듈 의 처리 프로그램 은 항상 현재 요청 을 거부 합 니 다. 문장 access_by_lua 'ngx.exit(ngx.OK)' 항상 접근 을 허용 합 니 다.우리 가 통과 할 때  satisfy  명령 어 설정  all  방식 시 필요 access 단계 의 모든 모듈 은 검증 을 통 과 했 지만 불행 하 게 도 여기 는  ngx_access  모듈 은 항상 접근 을 거부 하기 때문에 모든 요청 이 거 부 됩 니 다.

    $ curl localhost:8080/test
    <html>
    <head><title>403 Forbidden</title></head>
    <body bgcolor="white">
    <center><h1>403 Forbidden</h1></center>
    <hr><center>nginx</center>
    </body>
    </html>

세심 한 독 자 는 Nginx 오류 로그 파일 에서 다음 줄 과 같은 오류 정 보 를 볼 수 있 습 니 다.

    [error] 6549\#0: *1 access forbidden by rule

그러나 우리 가 상례 중의  satisfy all  구문 변경  satisfy any ，

    location /test {
        satisfy any;
 
        deny all;
        access_by_lua 'ngx.exit(ngx.OK)';
 
        echo something important;
    }

결 과 는 완전히 다르다.

    $ curl localhost:8080/test
    something important

요청 이 오히려 최종 검증 을 통과 했다 는 것 이다.이것 은  any  방식 상 access 단 계 는 하나의 모듈 이 검증 을 통과 하면 요청 이 전체적으로 검증 을 통과 했다 고 생각 하고 상례 에서 ngx_lua 모듈 러  access_by_lua  문 구 는 항상 검증 을 통과 할 것 이다.
 
    설정 중 입 니 다.  satisfy any  하 다  access  단계 의 모든 모듈 의 처리 프로그램 이 접근 을 거부 할 때 모든 요청 이 거 부 됩 니 다. 예 를 들 어:

    location /test {
        satisfy any;
 
        deny all;
        access_by_lua 'ngx.exit(ngx.HTTP_FORBIDDEN)';
 
        echo something important;
    }

이 때 방문  /test  인 터 페 이 스 를 받 을 수 있 습 니 다.  403 Forbidden  오류 페이지.여기, post-access 단계 참여  access  단계 각 모듈 처리 프로그램의 '또는 관계' 의 실현.
 
    특히 위의 이 몇 가지 예 가 필요 하 다.  ngx_lua  0.5.0rc 19 이상 버 전;이전 버 전 은 안 돼 요.  satisfy any  배치 문 같이 작 동 했 어 요.