Odwrotny serwer proxy Nginx + przepisywanie adresów URL

Nginx działa na porcie 80 i używam go do odwracania adresów URL proxy ze ścieżką /foodo portu w 3200ten sposób:

location /foo {
                proxy_pass http://localhost:3200;
                proxy_redirect     off;
                proxy_set_header   Host $host;
}

Działa to dobrze, ale mam aplikację na porcie 3200, dla której nie chcę, /fooaby wysyłano inicjał . To znaczy - kiedy uzyskuję dostęp http://localhost/foo/bar, chcę być tylko /barścieżką otrzymaną przez aplikację. Próbowałem więc dodać tę linię do powyższego bloku lokalizacji:

rewrite ^(.*)foo(.*)$ http://localhost:3200/$2 permanent;

Powoduje to przekierowanie 302 (zmiana adresu URL), ale chcę 301. Co powinienem zrobić?

Każde przekierowanie do localhost nie ma sensu ze zdalnego systemu (np. Przeglądarki internetowej klienta). Tak więc flagi przepisywania na stałe (301) lub przekierowania (302) nie są w twoim przypadku przydatne.

Spróbuj wykonać następującą konfigurację przy użyciu przezroczystej reguły przepisywania:

location  /foo {
  rewrite /foo/(.*) /$1  break;
  proxy_pass         http://localhost:3200;
  proxy_redirect     off;
  proxy_set_header   Host $host;
}

Służy curl -ido testowania przepisywania. Bardzo subtelna zmiana reguły może spowodować, że nginx wykona przekierowanie.

Proste dopasowanie prefiksu lokalizacji działa w tym przypadku bez użycia reguły przepisywania, o ile podasz identyfikator URI w dyrektywie proxy_pass:

location /foo {
  proxy_pass http://localhost:3200/;
}

Zwróć uwagę na dodatkowe /na końcu proxy_passdyrektywy. NGINX usunie dopasowany prefiks /fooi przekaże resztę do serwera zaplecza pod adresem URI /. W związku z tym http://myserver:80/foo/barwyśle ​​wiadomość do zaplecza o http://localhost:3200/bar.

Z dokumentów NGINX na proxy_pass :

Jeśli dyrektywa proxy_pass jest określona za pomocą identyfikatora URI, wówczas po przesłaniu żądania do serwera część znormalizowanego identyfikatora URI żądania pasującego do lokalizacji jest zastępowana identyfikatorem URI określonym w dyrektywie:

Absolutnie najbardziej poprawny sposób i najlepsza praktyka są zwykle następujące:

location /foo/ {
    proxy_pass http://localhost:3200/; # note the trailing slash!
}

• Zwróć uwagę na ogromne znaczenie końcowego ukośnikaproxy_pass , który automatycznie zmienia $urizmienną tak, aby /foo/przedni koniec był zgodny z /backendem. Nie ma potrzeby wyraźnej rewritedyrektywy.

• Dodatkowo należy zauważyć, że The spływu /wlocation jest bardzo ważne, a także - bez niego, istnieje ryzyko konieczności dziwnie wyglądający adres URL na swojej stronie w pewnym momencie (np obróbki /fooenoprócz /foo/en).

  Dodatkowo, zakończenie /w locationz proxy_passzapewnia również pewne specjalne postępowanie , zgodnie z dokumentacją locationdyrektywy, aby skutecznie powodować również domniemane location = /foo {return 301 /foo/;}.

  Tak więc, definiując za locationpomocą ukośnika końcowego, jak powyżej, nie tylko upewniasz się, że takie URL-e bez sufiksu /fooennie będą prawidłowe, ale także, że /fooukośnik bez końcowego ukośnika będzie nadal działał.

Dokumentacja referencyjna:

• http://nginx.org/r/location
• http://nginx.org/r/proxy_pass

próbować

location /foo {
    proxy_pass http://localhost:3200/;
    ....

lub

location ^~ /foo {
    proxy_pass http://localhost:3200/;
    ....

@Terabuck Przepraszamy za brak odpowiedzi.

Nie powinieneś używać localhost, ponieważ zależy to od faktu, że aplikacja działa na serwerze z plikiem hosts. host lokalny jest tylko domyślnym tłumaczeniem na 127.0.0.1. Nic nie wskazuje, że musisz mieć te pliki hostów. Po prostu jest to bardzo powszechne.

Posiadanie interfejsu sprzężenia zwrotnego jest kolejną powszechną rzeczą, na której można polegać, ale nadal jesteś zależny od interfejsu sprzężenia zwrotnego na stosie sieciowym. Rzadko zdarza się, aby nie mieć tych dwóch. Jeśli kiedykolwiek będziesz się tym martwić. Przynajmniej na unix / linux masz opcję gniazd. To wyeliminuje konieczność, aby stos sieciowy osiągnął hosta lokalnego. Zachowaj ostrożność przy takim podejściu, ponieważ istnieje kilka czynników, które pojawią się w systemie operacyjnym hosta. Takich jak liczba otwartych plików itp.