Como remover o caminho com um proxy_pass nginx

Esta é provavelmente a maneira mais eficiente de fazer o que você deseja, sem o uso de expressões regulares:

location = /en {
    return 302 /en/;
}
location /en/ {
    proxy_pass http://luscious/;  # note the trailing slash here, it matters!
}

Eu gostaria de abordar uma resposta mais recente baseada em regex que vem crescendo em popularidade.

location ~ ^/en(/?)(.*)$ {  # OOPS!
  proxy_pass http://luscious/$2$is_args$args;  # OOPS!
}

A solução pode parecer mais fofa à primeira vista, mas está errada por vários motivos.

• O regex acima corresponderia a um uri de solicitação de /enjoy, redirecionando-o para /joyupstream. Isso é realmente pretendido?

• Uma solicitação de /ennão resultará em nenhum redirecionamento, servindo diretamente a /partir do upstream (quase como se uma solicitação de /en/fosse feita em vez disso, mas não exatamente). Se você usar URIs relativos dentro de sua página raiz upstream (caso contrário, por que você não teria o /en/prefixo ali mesmo dentro dos URIs upstream?), por exemplo src="style.css"(que pode fazer referência a um idioma específico url("menu.png"), por exemplo), o navegador solicitará que como /style.cssem vez de /en/style.css. (Ou mesmo se você usar URIs absolutos em todos os lugares, e se alguém fizer referência a um recurso semi-opcional obscuro relativamente?) Ops, de repente o site pode não funcionar, mas apenas às vezes ou em casos extremos.

• De acordo com meu conselho anterior em outra pergunta já mencionada pela própria resposta do OP , o uso de expressões regulares impede que a proxy_redirectdiretiva tenha o valor padrão de default, reduzindo-o para off. Isso significa que, se o upstream responder Location: http://127.0.0.1:8080/en/dir/quando uma solicitação /en/dirfor feita, é isso que o cliente verá, o que obviamente não funcionará corretamente. (O que teria sido especialmente irônico para uma /ensolicitação que solicita o uso de regex em primeiro lugar, mas essa implementação específica sofre de outro problema, como já mencionado acima.) Além disso, se você já estiver usando oupstreamdiretiva, pode ficar ainda mais feio se você tentar usar um personalizado, especialmente se você tiver mais de um servidor upstream - como você tem um separado proxy_redirectpara cada um deles? Você também pode usar expressões regulares dentro proxy_redirectde , talvez até para corresponder a qualquer host, mas e se você decidir fornecer um redirecionamento entre domínios no futuro?

Para tentar resolver alguns dos pontos acima com um único local baseado em regex, poderíamos fazer o seguinte (observe que proxy_passtambém tivemos que descartar a referência a um servidor de uma upstreamdiretiva baseada em regex, para tornar proxy_redirectmais simples):

location ~ ^/en/?((?<=/).*)?$ {
  location = /en { return 302 /en/; }
  proxy_pass http://127.0.0.1:8080/$1$is_args$args;
  proxy_redirect http://127.0.0.1:8080/ /en/;
}

Então, se você me perguntar, a solução original com os dois locais irmãos de nível superior ainda seria uma ideia melhor do que se afundar em uma toca de coelho seguindo a rota regex.

Então, encontrei a resposta no stackoverflow :

upstream luscious {
 server lixxxx.members.linode.com:9001;
}

server {
  root /var/www/example.com/current/public/;
  server_name example.com;

  location ~ ^/en(/?)(.*) {
    proxy_pass http://luscious/$2;
  }
}

Basicamente: passando um regex para o local e passando o backref para o URL proxy_pass.

Contabilidade para documentos Nginx

Para passar uma solicitação para um servidor proxy HTTP, a diretiva proxy_pass é especificada dentro de um local. Por exemplo:

location /some/path/ {
    proxy_pass http://www.example.com/link/;
}

Esta configuração de exemplo resulta na transmissão de todas as solicitações processadas neste local para o servidor proxy no endereço especificado. Este endereço pode ser especificado como um nome de domínio ou um endereço IP. O endereço também pode incluir uma porta:

location ~ \.php {
    proxy_pass http://127.0.0.1:8000;
}

Observe que no primeiro exemplo acima, o endereço do servidor proxy é seguido por um URI, /link/. Se o URI for especificado junto com o endereço, ele substituirá a parte do URI de solicitação que corresponde ao parâmetro de localização. Por exemplo, aqui a solicitação com o /some/path/page.html URI será enviada por proxy para http://www.example.com/link/page.html . Se o endereço for especificado sem um URI, ou não for possível determinar a parte do URI a ser substituída, o URI de solicitação completo é passado (possivelmente modificado).

Eu brinquei com a solução aceita acima, mas descobri que estava causando redirecionamentos desonestos para todos os ativos CSS e JS. No final, encontrei inspiração na forma como as configurações do LinuxServer SWAG Nginx são feitas. Você pode encontrá-los aqui . Dê uma olhada pihole.subfolder.conf.sample.

Dessa forma, minha solução fica assim:

location /en {
    return 302 $scheme://$host/en/;
}

location ^~ /en/ {
    set $upstream_app lixxxx.members.linode.com;
    set $upstream_port 9001;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    rewrite /en(.*) $1 break;
}