nginx proxy_pass reescrita do local do cabeçalho de resposta


11

O objetivo desta instância nginx é fazer com que o GitLab e o OpenWRT Luci sejam redirecionados por meio de um proxy reverso. Ele já está funcionando para vários outros sites, todos com um URL base que parece contrariar esse problema.

  • O GitLab neste exemplo está no servidor local na porta 9000.
  • O site nginx está na porta 8080.
  • O OpenWRT tem exatamente o mesmo problema, mas com / cgi-bin / luci /

A configuração nginx relevante para o local do exemplo é;

location /gitlab/ {
    proxy_pass http://127.0.0.1:9000/;
    proxy_redirect default;
}
  • Observe que os resultados são os mesmos com e sem uma barra final.

Existem algumas opções de configuração de proxy de cabeçalho sendo aplicadas a esse local.

# 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;]
  • Comentar o host #proxy_set_header, em vez disso, redireciona o navegador para https://127.0.0.1:9000/users/sign_in

Ao navegar para https://website.com:8080/gitlab/;

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

A resposta retorna incorretamente para em /users/sign_invez 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

A navegação manual para https: // website: 8080 / gitlab / users / sign_in carrega a página, mas não há ativos, pois eles caem até o mesmo problema acima.

Falha no ativo do GitLab

Lendo os documentos nginx , sugere que o comportamento padrão do proxy deve lidar com esse cenário, embora pareça falhar.

Os logs não parecem mostrar muito.

Que etapas adicionais devem ser tomadas para ajudar a diagnosticar por que isso pode estar acontecendo?

Respostas:


3

Adicione uma barra final ao seu proxy_passalvo.

Atualização: o OP não precisou o vhost estava aceitando https. Como o esquema é encaminhado para o servidor back-end com cabeçalhos adicionais, ocorre um problema, pois proxy_redirect default;ordena ao nginx que espere o esquema http por padrão ao reescrever Locationcabeçalhos nas respostas upstream, em vez de https.

Portanto, isso teve que ser alterado explicitamente para uma forma mais genérica (a barra final ainda é necessária):

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

Oi Xavier, obrigado pela resposta. Sem sorte lá. Isso é uma das coisas que eu ser julgados (correspondentes a documentação proxy_pass), mas nenhuma mudança :(
Jake Edwards

Eu adicionei informações sobre o proxy_set_header que estava em outra conf. Removendo a linha anfitrião muda as coisas - redirecionamentos para 127.0.0.1:9000/users/sign_in
Jake Edwards

Ok, então o problema é o scheme(https) com proxy_redirect default comportamento que espera http. Deixe a configuração como estava antes de comentar o cabeçalho Host e altere o proxy_redirectconteúdo para $scheme://$host:$server_port/ /gitlab/;. Certifique-se de não atingir os cabeçalhos em cache do navegador (use ferramentas CLI ou navegação privada) ao testar.
Xavier Lucas

Ok, legal, agora ele segue para a URL correta (pelo menos o GitLab, o OpenWRT ainda vai para / cgi-bin / luci - um de cada vez). Não tem nenhum assets / images / etc no entanto -: 8080 / activos / aplicação-5ec1aeb4604cbfbeff836f956308b0ed.js em vez de: 8080 / gitlab / assets / application-5ec1aeb4604cbfbeff836f956308b0ed.js
Jake Edwards

1
Os links do @ShadowXVII Assets são gerados pelo seu aplicativo, você deve alterá-lo lá. O Nginx reescreverá apenas os redirecionamentos emitidos pelo seu aplicativo, não o conteúdo da página.
Xavier Lucas

0

O que o @XavierLucas diz estar correto, o backup deve lidar com os links. A documentação do gitlab tem um guia sob o título Instalar o GitLab em uma URL relativa . Encontrei esse problema recentemente ao configurar um servidor arch linux com o gitlab e o nginx instalados e isso resolveu o meu problema recompilando todos os ativos para ter o caminho relativo correto.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.