nginx 구성에서 If 문을 구현하는 방법 (그리고 왜 '사악한가?)?

Nginx의 IF 문은 제한되어 있으며 공식적으로 "Is Is Evil"이라고 불리는 함정이 있습니다. 기본 사용법은 특정 사용자 에이전트 방지 또는 도메인 이름 리디렉션과 같은 서버 또는 위치 블록의 조건에 따라 지침을 실행하는 것입니다. 그러나 문제는 다음과 같습니다. 1. proxy_pass와 같은 일부 지침은 IF에서 비정상적으로 행동합니다. 2. 실행 순서는 코드 순서보다는 우선 순위에 따라 달라지며 논리는 기대를 충족시키지 못할 수 있습니다. 3. 다중 조건이 독립적으로 판단되는 경우, 이는 반품에 의해 무시되는 등의 충돌 또는 덮기 작업으로 이어질 수 있습니다. 권장되는 대안은지도 모듈, 다층 위치 일치 또는 복잡한 논리를 백엔드에 처리하여 프로세스에 적용하는 것입니다. 요약하면, 간단한 판단에 적합한 경우 숨겨진 위험을 방지하기 위해 복잡한 시나리오를 피해야합니다.

Nginx의 구성 언어는 기존 프로그래밍 언어와 같은 완전한 제어 구조를 지원하지 않습니다. 예를 들어, if 문의 사용은 매우 제한적입니다. 그러나 구성 중에는 조건부 판단을하기 위해 여전히 사용할 수 if 공식 문서는 " 악한 경우 "를 명확하게 나타냅니다. 그럼 어떻게 사용 하는가? 왜 "악"이라고 불리는가?

먼저 Nginx에서 사용하는 if 을 살펴 보겠습니다.

기본 구문 및 사용 시나리오

NGINX의 if 명령어는 server 또는 location 블록에서만 사용할 수 있으며 특정 조건에 따라 특정 작업을 수행하는 데 사용됩니다. 기본 형태는 다음과 같습니다.

 if (조건) {
    # 몇 가지 지침 실행}

일반적인 사용 시나리오에는 다음이 포함됩니다.

• 사용자 요청 헤더 (예 : 호스트, 사용자 에이전트)에 따라 점프
• URL을 다시 작성하거나 특정 상태 코드를 반환하십시오
• 특정 불법 요청을 차단하십시오

예를 들어, 사용자 에이전트에 대한 액세스를 차단하려고합니다.

 if ($ http_user_agent ~* "curl") {
    반환 403;
}

또는 간단한 도메인 이름 점프를 구현하십시오.

 if ($ host = 'example.com') {
    ^ https : //www.example.com$ request_uri를 다시 작성합니까? 영구적인;
}

매우 편리 해 보이지만 문제는 여기에 있습니다.

"악"이라고 불리는 이유는 무엇입니까?

실용적 if , 그것은 커뮤니티에서 "악"이라고 불리는 몇 가지 "구덩이"가 있습니다.

1. 모든 지침을 사용할 수있는 것은 아닙니다

모든 NGINX 지침을 if 블록에 배치 할 수있는 것은 아닙니다. 일부 지침의 행동은 예측할 수 없게되며 심지어 전혀 효과가 없습니다. 예를 들어, set 사용할 수 있지만 proxy_pass 문제가 발생하기 쉽습니다.

2. 실행 명령은 직관적이지 않습니다

NGINX는 코드 순서의 if 블록에서 명령을 실행하지 않지만 내부 명령 우선 순위를 기반으로합니다. 이것은 당신이 쓰는 논리가 예상대로 작동하지 않을 수 있음을 의미합니다.

3. 상태가 덮어 쓰거나 상충 될 수 있습니다

판단을 여러 번 if 판단에 따라 "다른"관계가 없으며, 각각은 독립적 인 판단을하고 실행하려고 시도합니다. 이로 인해 여러 작업이 중복되어 예상치 못한 결과가 발생할 수 있습니다.

예를 들어:

 if ($ uri ~ "/Old-Path") {
    ^ /New-Path Break를 다시 작성합니다.
}

if ($ args ~ "id = 123") {
    반환 403;
}

두 조건이 모두 충족되면 다시 쓰기 및 반환이 트리거되고 결국 반환은 실행되며 이전 재 작성은 무시됩니다. 그러나 당신은 그것이 경로를 먼저 다시 작성하고 매개 변수를 판단 할 것이라고 생각할 수도 있습니다 ...

더 권장되는 관행

이러한 문제를 피하기 위해 NGINX 공무원은 특히 복잡한 논리 또는 중요한 흐름 제어가 관련된 if 를 피할 것을 권장합니다. 다음 대안을 고려할 수 있습니다.

• map 모듈을 사용하여 가변 매핑을 수행하십시오 (보다 효율적이고 안정적)
• 다층 location 일치를 통해 유사한 논리를 구현하십시오
• 처리를위한 백엔드 응용 프로그램에 복잡한 판단을 남기십시오 (예 : PHP, Node.js)

예를 들어, map 사용하여 사용자 에이전트 필터링을 구현하십시오.

 지도 $ http_user_agent $ block_ua {
    기본 0;
    ~* 컬 1;
    ~* libwww-perl 1;
}

서버 {
    if ($ block_ua) {
        반환 403;
    }
}

이것은 논리를 분리하고 if 남용의 위험을 줄일 수 있습니다.

요약합시다

Nginx의 if 문을 사용할 수 있지만 실제로 많은 제한과 함정이 있습니다. 간단한 판단은 여전히 그것에 대처할 수 있지만 일단 논리가 복잡해지면 함정에 들어가기가 쉽습니다. 사용해야한다면 몇 가지 원칙을 기억하십시오.

• proxy_pass 와 같은 민감한 지침을 사용하고 if 에서 rewrite 하지 마십시오.
• 너무 많은 조건을 둥지하지 마십시오
• map 나 location 로 해결할 수있는 문제 if

기본적으로 그게 다야. 잘 사용하면 구성을 단순화 할 수 있지만 사용되지 않으면 구성을 "시한 폭탄"으로 전환합니다.

위 내용은 nginx 구성에서 If 문을 구현하는 방법 (그리고 왜 '사악한가?)?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!