Jak mogę mieć tę samą regułę dla dwóch lokalizacji w konfiguracji NGINX?

Jak mogę mieć tę samą regułę dla dwóch lokalizacji w konfiguracji NGINX?

Wypróbowałem następujące

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

ale przeładowanie nginx zwróciło ten błąd:

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

Próbować

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

Sposób ~użycia wyrażenia regularnego dla adresu URL. Te ^środki, by sprawdzić od pierwszego znaku. Spowoduje to wyszukanie, po którym /nastąpi jedna z lokalizacji, a następnie inna /.

Inną opcją jest powtórzenie reguł w dwóch lokalizacjach prefiksów przy użyciu dołączonego pliku. Ponieważ lokalizacje prefiksów są niezależne od pozycji w konfiguracji, ich użycie może zaoszczędzić trochę zamieszania podczas późniejszego dodawania innych lokalizacji wyrażeń regularnych. Unikanie lokalizacji wyrażeń regularnych, gdy możesz, pomoże w płynnym skalowaniu konfiguracji.

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

Oto przykład 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
";

Zarówno wyrażenie regularne, jak i dołączone pliki są dobrymi metodami i często ich używam. Ale inną alternatywą jest użycie „nazwanej lokalizacji”, co jest przydatne w wielu sytuacjach - szczególnie tych bardziej skomplikowanych. Oficjalny „Jeśli jest zła” strona pokazuje zasadniczo następującą jako dobry sposób do robienia rzeczy:

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

Te różne podejścia mają zalety i wady. Dużą zaletą wyrażenia regularnego jest to, że możesz przechwytywać części dopasowania i używać ich do modyfikowania odpowiedzi. Oczywiście podobne wyniki można zwykle osiągnąć innymi podejściami, ustawiając zmienną w oryginalnym bloku lub używając map. Wadą podejścia wyrażeń regularnych jest to, że może stać się nieporęczne, jeśli chcesz dopasować różne lokalizacje, a niski priorytet wyrażenia regularnego może po prostu nie pasować do tego, jak chcesz dopasować lokalizacje - nie wspominając o widocznym wpływie na wydajność w niektórych przypadkach z wyrażeń regularnych.

Główną zaletą dołączania plików (o ile wiem) jest to, że jest trochę bardziej elastyczne w kwestii tego, co można dołączyć - na przykład nie musi to być pełny blok lokalizacji. Ale jest też subiektywnie nieco bardziej zagmatwany niż nazwane lokalizacje.

Pamiętaj również, że istnieje powiązane rozwiązanie, którego możesz użyć w podobnych sytuacjach: lokalizacje zagnieżdżone. Chodzi o to, aby zacząć od bardzo ogólnej lokalizacji, zastosować pewną konfigurację wspólną dla kilku możliwych dopasowań, a następnie utworzyć oddzielne zagnieżdżone lokalizacje dla różnych typów ścieżek, które chcesz dopasować. Na przykład może być przydatne zrobienie czegoś takiego:

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

To krótkie, ale skuteczne i sprawdzone podejście:

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

Można więc łatwo mieć wiele wzorców z prostą składnią potoku wskazującą na ten sam blok / reguły lokalizacji.