nginx proxy_pass schreibt den Speicherort des Antwortheaders neu

Das Ziel dieser Nginx-Instanz ist es, GitLab und OpenWRT Luci dazu zu bringen, über einen Reverse-Proxy umzuleiten. Es funktioniert bereits für mehrere andere Websites, die alle eine Basis-URL haben, die diesem Problem entgegenzuwirken scheint.

• GitLab befindet sich in diesem Beispiel auf dem lokalen Server an Port 9000.
• Die Nginx-Website befindet sich auf Port 8080.
• OpenWRT hat genau das gleiche Problem, jedoch mit / cgi-bin / luci /

Die relevante Nginx-Konfiguration für den Beispielspeicherort lautet:

location /gitlab/ {
    proxy_pass http://127.0.0.1:9000/;
    proxy_redirect default;
}

• Beachten Sie, dass die Ergebnisse mit und ohne abschließenden Schrägstrich identisch sind.

Es gibt einige Konfigurationsoptionen für den Header-Proxy, die auf diesen Speicherort angewendet werden.

# 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;]

• Wenn Sie #proxy_set_header Host auskommentieren, wird der Browser stattdessen umgeleitet https://127.0.0.1:9000/users/sign_in

Beim Surfen zu https://website.com:8080/gitlab/;

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

Die Antwort geht fälschlicherweise auf /users/sign_instatt zurück/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

Durch manuelles Surfen auf https: // website: 8080 / gitlab / users / sign_in wird die Seite geladen , es werden jedoch keine Assets angezeigt , da sie bis zum gleichen Problem wie oben fallen.

Beim Lesen von Nginx-Dokumenten wird vorgeschlagen , dass das Standard-Proxy-Verhalten dieses Szenario behandeln sollte, obwohl es anscheinend fehlschlägt.

Die Protokolle scheinen nicht viel zu zeigen.

Welche zusätzlichen Schritte sollten unternommen werden, um zu diagnostizieren, warum dies möglicherweise geschieht?

Fügen Sie Ihrem proxy_passZiel einen abschließenden Schrägstrich hinzu .

Update: Das OP hat nicht genau angegeben, was der vhost akzeptiert hat https. Wenn das Schema mit zusätzlichen Headern an den Back-End-Server weitergeleitet wird, tritt ein Problem auf, da proxy_redirect default;nginx beim Umschreiben von Headern in Upstream-Antworten anstelle von https standardmäßig das http-Schema erwartet Location.

Dies musste also explizit in eine allgemeinere Form geändert werden (der abschließende Schrägstrich ist immer noch erforderlich):

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

Was @XavierLucas sagt, ist richtig, dass der Backed die Links handhaben sollte. Die gitlab-Dokumentation enthält eine Anleitung unter der Überschrift GitLab unter einer relativen URL installieren . Ich bin kürzlich auf dieses Problem gestoßen, als ich einen Arch-Linux-Server mit installiertem Gitlab und Nginx eingerichtet habe. Dadurch wurde mein Problem behoben, indem alle Assets neu kompiliert wurden, um den richtigen relativen Pfad zu erhalten.