Estou tentando direcionar todo o tráfego HTTPS para o servidor Nginx, onde ele lidará com todas as solicitações como solicitações HTTP para todos os servidores internos. Até agora, consigo fazer com que o modelo abaixo funcione para a maioria dos meus servidores.
server {
listen 443 default ssl;
ssl_certificate /etc/letencrypt/live/somesite.com/fullchain.pem;
ssl_certificate_key /etc/letencrypt/live/somesite.com/privkey.pem;
server_name somesite.com;
location ^~ /Service {
proxy_pass http://192.168.1.2;
}
location / {
proxy_pass http://192.168.1.3;
}
}
No entanto, estou restrito a sempre ter que combinar https://somesite.com/Service com http://192.168.1.2/Service para que o acima funcione.
Não posso ter https://somesite.com/Service para trabalhar com http://192.168.1.2/Hello .
Ou que não posso direcionar isso para outra porta como https://somesite.com/Service com http://192.168.1.2:3000 .
Por exemplo, quando alterei o acima para isso:
location /Service/ {
proxy_pass http://192.168.1.2:80/;
}
location / {
proxy_pass http://192.168.1.3;
}
Usando a seguinte configuração de registro:
log_format upstreamlog '[$time_local] $remote_addr - $remote_user - $server_name to: $upstream_addr: $request upstream_response_time $upstream_response_time msec $msec request_time $request_time';
access_log /var/log/nginx/access.log upstreamlog;
Este é o log que obtive:
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.2:80: GET /Service/ HTTP/1.1 upstream_response_time 0.004 msec 1611309388.445 request_time 0.004
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.2:80: GET /Service/js/default.cache.a331c8c3.js HTTP/1.1 upstream_response_time 0.000 msec 1611309388.547 request_time 0.002
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.2:80: GET /Service/favicon.ico HTTP/1.1 upstream_response_time 0.012 msec 1611309388.757 request_time 0.012
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.3:80: GET /api/v1/oauth.json?_=1611309389573 HTTP/1.1 upstream_response_time 0.016 msec 1611309388.771 request_time 0.017
Pode-se ver no log que as três primeiras buscas estão corretas. A quarta está errada. Nenhum outro pedido foi feito depois. Depois de rastrear um pouco mais, percebo que o 192.168.1.2 já tem um servidor Nginx rodando e processando páginas PHP usando FastCGI. Não sei se isso faz diferença ou não.
Então, tentei usar a reescrita em combinação com o que tenho acima, mas encontrei uma página não encontrada. Presumo que não parece funcionar para HTTPS, talvez? Assim, isso me levou a fazer a pergunta de como configurar o Nginx para reverter o proxy com reescrita de URL e HTTPS externamente.
Veja a documentação do NGINX , o primeiro exemplo é exatamente o que você está fazendo e está bem explicado:
se você configurar um
locationbloco com um caminho1 e umproxy_passcom um caminho2, você terminará com toda a "árvore de caminhos" sendo realocada de caminho1 para caminho2:se você acessar
https://example.net/some/path/blah, ele fará um proxy parahttp://www.example.com/link/blah.A próxima ressalva é o que exatamente seu servidor de origem retorna. Pode emitir algum HTML, algum JS, algum CSS, e todos eles podem conter links HTTP(S); alguns deles são relativos , mas alguns não são. A consideração muito importante é que uma
proxy_passdiretiva não instrui o Nginx a reescrever quaisquer links dentro de dados proxy. Se houver caminhos não relativos, eles permanecerão como estavam e o cliente os interpretará como instruções para ir "fora" do prefixo proxy.Como vemos em seu arquivo de log, o servidor web retorna algum código Javascript na solicitação 2:
Esse código provavelmente contém alguns caminhos não relativos, ou seja, tem um caminho começando com
/api/. O cliente então faz um pedido de acordo com esse caminho, que está fora da árvore proxy (que é apenas/Service/por enquanto), vemos na linha 4:O Nginx, de acordo com sua configuração, proxies corretamente essa solicitação em outro lugar (ela é capturada com
location /regra).Existem várias maneiras de contornar isso. Se você tiver apenas alguns prefixos usados ​​com caminhos não relativos e nada mais estiver usando-os, você pode apenas fazer proxy deles à medida que são retornados:
Outra forma é instalar um filtro no Nginx usando um
ngx_http_sub_module, o que alteraria o conteúdo servido , atualizando todos os URIs para a nova base.Por favor, tenha em mente que não pode haver uma maneira completamente à prova de balas de fazer isso. Os links podem aparecer não apenas em arquivos HTML, CSS e JS baseados em texto, mas também em arquivos binários proprietários. E não sabemos a priori quais links eles podem conter para proximá-los preventivamente. No passado recente, um Adobe Flash foi um exemplo desse formato binário. Ninguém sabe o que será inventado no futuro para expor o mesmo problema.
Você está tentando usar proxy e reescrever. Eles precisam ser feitos em lugares separados embora. O proxy vai passar o mesmo caminho que recebe para o servidor de origem. Se você quiser reescrever para outro local, faça isso em seu servidor de origem para que ele saiba reescrever solicitações de /service para /hello. Caso contrário, você receberá um 404 porque o servidor de origem não terá ideia do que fazer com a solicitação de /service.