NGINX 설정에서 두 위치에 대해 동일한 규칙을 어떻게 가질 수 있습니까?


153

NGINX 설정에서 두 위치에 대해 동일한 규칙을 어떻게 가질 수 있습니까?

나는 다음을 시도했다

server {
  location /first/location/ | /second/location/ {
  ..
  ..
  }
}

그러나 nginx reload는이 오류를 던졌습니다.

nginx: [emerg] invalid number of arguments in "location" directive**

답변:


239

시험

location ~ ^/(first/location|second/location)/ {
  ...
}

~수단은 URL에 대한 정규 표현식을 사용합니다. ^첫 문자부터 확인 하는 수단. 이것은 /위치와 위치를 차례로 찾습니다 /.


37
참고 :이 문제가 자주 발생하는 경우 (예 : 천 단위) 정규식 일치로 인해 성능이 저하됩니다. 또한 매칭 순서는 실질적으로 다르다. 많은 "작은"경우에는 원하는대로 동작하지만이 점을 알고 있어야합니다. 개인적으로 Nginx "location"이 정규식 규칙에 의존하는 대신 여러 "="조건을 지원하기를 원합니다.
Bernard

7
IMHO, 이것은 더 효율적이어야합니다 : location ~ (patternOne | patternTwo) {...}
Stamster

2
이 솔루션은 저에게 효과적이지 않았습니다. 그러나 @stamster의 의견은 그렇지 않았다. 나는 달리고있다nginx/1.13.2
TJ Biddle

1
당신이 필요로하는 경우 proxy_pass작업에,이 대답을 참조하십시오 stackoverflow.com/a/46625656/1246870
avs099

1
원본 URL이 슬래시없이 끝나면 나에게 적합하지 않습니다.
대부

88

다른 옵션은 포함 된 파일을 사용하여 두 접두사 위치에서 규칙을 반복하는 것입니다. 접두사 위치는 구성에서 위치에 독립적이므로 나중에 다른 정규식 위치를 추가 할 때 접두사 위치를 사용하면 혼동을 줄일 수 있습니다. 정규식 위치를 피하면 구성을 원활하게 확장하는 데 도움이됩니다.

server {
    location /first/location/ {
        include shared.conf;
    }
    location /second/location/ {
        include shared.conf;
    }
}

다음은 샘플 shared.conf입니다.

default_type text/plain;
return 200 "http_user_agent:    $http_user_agent
remote_addr:    $remote_addr
remote_port:    $remote_port
scheme:     $scheme
nginx_version:  $nginx_version
";

shared.conf예와 위치 를 추가 할 수 있습니까?
Дмитрий Кулешов

5
예제 shared.conf 파일을 추가했습니다. shared.conf의 절대 경로를 사용하거나 nginx 디렉토리에 넣을 수 있습니다. 이 경우 몇 개의 지시문 만 포함됩니다.
Cole Tierney

40

정규식과 포함 파일 모두 좋은 방법이며 자주 사용합니다. 그러나 또 다른 대안은 "명명 된 위치"를 사용하는 것인데,이 방법은 많은 상황, 특히 더 복잡한 상황에서 유용한 접근 방식입니다. 공식 페이지 "만약 악의는" 일을 할 수있는 좋은 방법으로 다음과 같은 본질적으로 보여줍니다 :

error_page 418 = @common_location;
location /first/location/ {
    return 418;
}
location /second/location/ {
    return 418;
}
location @common_location {
    # The common configuration...
}

이러한 다양한 접근 방식에는 장단점이 있습니다. 정규 표현식의 가장 큰 장점은 일치하는 부분을 캡처하여 응답을 수정할 수 있다는 것입니다. 물론 원래 블록에서 변수를 설정하거나을 사용하여 다른 방법으로 비슷한 결과를 얻을 수 있습니다 map. 정규식 접근 방식의 단점은 다양한 위치를 일치시키려는 경우 다루기 어려워 질 수 있으며 정규식낮은 우선 순위는 위치를 일치시키는 방법에 맞지 않을 수 있다는 것입니다. 분명히 성능에 영향을 미친다는 것은 말할 것도 없습니다. 어떤 경우에는 정규식에서.

파일을 포함시킬 때 얻을 수있는 가장 큰 장점은 정확히 포함 할 수있는 부분에 대해 좀 더 융통성이 있다는 것입니다. 예를 들어 전체 위치 블록 일 필요는 없습니다. 그러나 이름이 지정된 위치보다 주관적으로 조금 복잡합니다.

또한 유사한 상황에서 사용할 수있는 관련 솔루션이 있습니다. 중첩 된 위치. 아이디어는 매우 일반적인 위치에서 시작하여 가능한 여러 일치 항목에 공통적 인 구성을 적용한 다음 일치하려는 여러 유형의 경로에 대해 별도의 중첩 된 위치를 갖는 것입니다. 예를 들어, 다음과 같은 작업을 수행하는 것이 유용 할 수 있습니다.

location /specialpages/ {
    # some config
    location /specialpages/static/ {
        try_files $uri $uri/ =404;
    }
    location /specialpages/dynamic/ {
        proxy_pass http://127.0.0.1;
    }
}

7

이것은 짧지 만 효율적이며 입증 된 접근 방식입니다.

location ~ (patternOne|patternTwo){ #rules etc. }

따라서 동일한 위치 블록 / 규칙을 가리키는 간단한 파이프 구문으로 여러 패턴을 쉽게 가질 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.