Le but de cette instance nginx est de faire rediriger GitLab et OpenWRT Luci via un proxy inverse. Cela fonctionne déjà pour plusieurs autres sites Web, qui ont tous une URL de base qui semble contrer ce problème.
La configuration nginx appropriée pour l'emplacement d'exemple est;
location /gitlab/ {
proxy_pass http://127.0.0.1:9000/;
proxy_redirect default;
}
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;]
https://127.0.0.1:9000/users/sign_in
Lorsque vous accédez à https://website.com:8080/gitlab/
;
GET /gitlab/ HTTP/1.1
Host: website.com:8080
La réponse revient incorrectement à /users/sign_in
au lieu 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 vers 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 docs 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 à votre proxy_pass
cible.
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 puisque proxy_redirect default;
ordonne à nginx de s'attendre à schéma http par défaut lors de la réécriture des en-têtes Location
dans les réponses en amont, au lieu de https.
Donc, cela a dû être changé explicitement pour 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 a 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 Arch Linux 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.