nginx proxy_pass réécriture de l'emplacement de l'en-tête de réponse

Le but de cette instance nginx est de faire rediriger GitLab et OpenWRT Luci via un proxy inverse. Il fonctionne déjà pour plusieurs autres sites Web, qui ont tous une URL de base qui semble contrer ce problème.

• GitLab dans cet exemple se trouve sur le serveur local au port 9000.
• Le site Web nginx se trouve sur le port 8080.
• OpenWRT a exactement le même problème, mais avec / cgi-bin / luci /

La configuration nginx appropriée pour l'emplacement d'exemple est;

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

• Notez que les résultats sont les mêmes avec et sans barre oblique de fin.

Certaines options de configuration du proxy d'en-tête sont appliquées à cet emplacement.

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

• À la place, l'hôte #proxy_set_header redirige le navigateur vers https://127.0.0.1:9000/users/sign_in

Lorsque vous naviguez vers https://website.com:8080/gitlab/;

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

La réponse revient incorrectement au /users/sign_inlieu de/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

La navigation manuelle sur https: // site Web: 8080 / gitlab / users / sign_in charge la page, mais aucun actif car ils tombent jusqu'au même problème que ci-dessus.

En lisant les documents nginx , cela suggère que le comportement du proxy par défaut devrait gérer ce scénario, bien qu'il semble échouer.

Les journaux ne semblent pas montrer grand-chose.

Quelles mesures supplémentaires devraient être prises pour aider à diagnostiquer pourquoi cela pourrait se produire?

Ajoutez une barre oblique de fin à votre proxy_passcible.

Mise à jour: l'OP n'a pas précisé que le vhost acceptait https. Comme le schéma est transmis au serveur principal avec des en-têtes supplémentaires, un problème se produit, car il proxy_redirect default;ordonne à nginx d'attendre le schéma http par défaut lors de la réécriture des en- Locationtêtes dans les réponses en amont, au lieu de https.

Donc, cela a dû être changé explicitement en une forme plus générique (la barre oblique de fin est toujours nécessaire):

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

Ce que @XavierLucas dit est correct, le support doit gérer les liens. La documentation de gitlab contient un guide sous le titre Installer GitLab sous une URL relative . J'ai rencontré ce problème récemment lors de la configuration d'un serveur Linux arch avec gitlab et nginx installés et cela a résolu mon problème en recompilant tous les actifs pour avoir le chemin relatif correct.