nginx proxy_pass przepisanie lokalizacji nagłówka odpowiedzi


11

Celem tego wystąpienia nginx jest skłonienie GitLab i OpenWRT Luci do przekierowania poprzez odwrotne proxy. Działa już na kilku innych stronach internetowych, z których wszystkie mają podstawowy adres URL, który wydaje się przeciwdziałać temu problemowi.

  • GitLab w tym przykładzie znajduje się na lokalnym serwerze na porcie 9000.
  • Witryna nginx znajduje się na porcie 8080.
  • OpenWRT ma dokładnie ten sam problem, ale z / cgi-bin / luci /

Odpowiednia konfiguracja nginx dla przykładowej lokalizacji to;

location /gitlab/ {
    proxy_pass http://127.0.0.1:9000/;
    proxy_redirect default;
}
  • Pamiętaj, że wyniki są takie same z ukośnikiem końcowym i bez niego.

W tej lokalizacji są stosowane opcje konfiguracji proxy nagłówka.

# Timeout if the real server is dead
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

# Basic Proxy Config
proxy_set_header    Host $host:$server_port;
proxy_set_header    Origin $scheme://$host:$server_port;    
proxy_set_header    Connection $http_connection;
proxy_set_header    Cookie $http_cookie;
proxy_set_header    Upgrade $http_upgrade;
proxy_set_header    X-Forwarded-Protocol $scheme;
proxy_set_header    X-Scheme $scheme;
proxy_set_header    X-Real-IP $remote_addr;
proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header    X-Forwarded-Ssl on;
proxy_set_header    X-Frame-Options SAMEORIGIN;

# Advanced Proxy Config
send_timeout            5m;
proxy_read_timeout      300;
proxy_send_timeout      300;
proxy_connect_timeout   300;

proxy_buffers 32 4k;
proxy_buffer_size           4k;
proxy_busy_buffers_size     64k;
proxy_temp_file_write_size  64k;

proxy_http_version 1.1;
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;]
  • Komentowanie #proxy_set_header Host zamiast tego przekierowuje przeglądarkę do https://127.0.0.1:9000/users/sign_in

Podczas przeglądania do https://website.com:8080/gitlab/;

GET /gitlab/ HTTP/1.1
Host: website.com:8080

Odpowiedź niepoprawnie wraca do /users/sign_inzamiast/gitlab/users/sign_in

HTTP/1.1 302 Found
Cache-Control: no-cache
Connection: keep-alive
Content-Type: text/html; charset=utf-8
Location: https://website.com:8080/users/sign_in

Przeglądanie ręczne do https: // website: 8080 / gitlab / users / sign_in ładuje stronę, ale żadnych zasobów, ponieważ spadają aż do tego samego problemu, jak powyżej.

GitLab Asset Fail

Czytając dokumenty nginx , sugeruje, że domyślne zachowanie proxy powinno obsługiwać ten scenariusz, choć wydaje się, że zawodzi.

Dzienniki wydają się niewiele pokazywać.

Jakie dodatkowe kroki należy podjąć, aby zdiagnozować, dlaczego tak się dzieje?

Odpowiedzi:


3

Dodaj końcowy ukośnik do proxy_passcelu.

Aktualizacja: OP nie sprecyzował, że vhost akceptuje https. Ponieważ schemat jest przekazywany do serwera zaplecza z dodatkowymi nagłówkami, wówczas pojawia się problem, ponieważ proxy_redirect default;nginx nakazuje domyślnie oczekiwać schematu http podczas przepisywania Locationnagłówków w odpowiedziach poprzedzających, zamiast https.

Tak więc musieliśmy to wyraźnie zmienić na bardziej ogólną formę (ukośnik końcowy jest nadal konieczny):

location /gitlab/ {
    proxy_pass http://127.0.0.1:9000/;
    proxy_redirect $scheme://$host:$server_port/ /gitlab/;
}

Cześć Xavier, dzięki za odpowiedź. Nie ma tam szczęścia. To jedna z rzeczy, które próbowałem (dopasowanie do dokumentów proxy_pass), ale bez zmian :(
— Jake Edwards

Dodałem informacje o proxy_set_header, który był w innym konf. Usunięcie linii hosta zmienia rzeczy - przekierowuje do 127.0.0.1:9000/users/sign_in
— Jake Edwards

Ok, więc problemem jest scheme(https) proxy_redirect default zachowanie, które oczekuje http. Pozostaw konfigurację taką, jaka była przed komentowaniem nagłówka Hosta i zmień proxy_redirectzawartość na $scheme://$host:$server_port/ /gitlab/;. Upewnij się, że nie trafiasz na buforowane nagłówki przeglądarki (użyj narzędzi cli lub prywatnej nawigacji) podczas testowania.
— Xavier Lucas

Okej, fajnie, więc teraz prowadzi do właściwego adresu URL (przynajmniej GitLab robi to, OpenWRT wciąż idzie do / cgi-bin / luci - jednak pojedynczo). Nie mam jednak żadnych zasobów / obrazów / etc -: 8080 / asset / application-5ec1aeb4604cbfbeff836f956308b0ed.js zamiast: 8080 / gitlab / asset / application-5ec1aeb4604cbfbeff836f956308b0ed.js
— Jake Edwards

1
@ShadowXVII Linki do zasobów są generowane przez twoją aplikację, musisz ją tam zmienić. Nginx przepisuje tylko przekierowania wysłane przez twoją aplikację, a nie zawartość strony.
— Xavier Lucas

0

To, co @XavierLucas mówi, jest poprawne, wspierane powinny obsługiwać linki. Dokumentacja gitlab zawiera przewodnik pod nagłówkiem Zainstaluj GitLab pod względnym adresem URL . Ostatnio natknąłem się na ten problem podczas konfigurowania arch-serwera Linux z zainstalowanymi gitlab i nginx, co rozwiązało mój problem poprzez rekompilację wszystkich zasobów w celu uzyskania właściwej ścieżki względnej.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.