reescrita nginx ou ciclo de redirecionamento interno


13

Estou batendo com a cabeça em uma tabela tentando descobrir o que está causando o ciclo de redirecionamento na minha configuração nginx ao tentar acessar a URL que não existe. A configuração é a seguinte:

server {
        listen       127.0.0.1:8080;
        server_name  .somedomain.com;
    root  /var/www/somedomain.com;

        access_log /var/log/nginx/somedomain.com-access.nginx.log;
    error_log  /var/log/nginx/somedomain.com-error.nginx.log debug;

        location ~* \.php.$ {
        # Proxy all requests with an URI ending with .php*
        # (includes PHP, PHP3, PHP4, PHP5...)
        include /etc/nginx/fastcgi.conf;
        }

        # all other files
        location / {
            root  /var/www/somedomain.com;
        try_files $uri $uri/ ;
        }

    error_page 404 /errors/404.html;
        location /errors/ {
                alias /var/www/errors/;
        }       

        #this loads custom logging configuration which disables favicon error logging
        include /etc/nginx/drop.conf;
}

esse domínio é um site HTML estático simples apenas para alguns fins de teste. Eu esperaria que a diretiva error_page fosse ativada em resposta ao PHP-FPM não conseguir encontrar os arquivos fornecidos, pois tenho fastcgi_intercept_errors; no bloco http e nave error_page configurado, mas acho que a solicitação falha antes mesmo disso em algum lugar nos redirecionamentos internos. Qualquer ajuda seria muito apreciada.


O navegador do cliente está relatando um loop de redirecionamento ou é nginx? Se for o cliente, para qual local os redirecionamentos?
Shane Madden

ambos estão relatando isso. Cliente eventualmente acaba com o URL de /errors//errors//errors//errors//errors/...404.html
milosgajdos

Como é a entrada de log do nginx?
Shane Madden

Respostas:


11

O culpado é: try_files $uri $uri/ ;

http://nginx.org/r/try_files (observe que o último parâmetro é código de retorno ou URI para redirecionamento interno)

Se nenhum dos arquivos foi encontrado, um redirecionamento interno para a uri especificada pelo último parâmetro é feito.


Obrigado. Só tive um desses erros com uma configuração do Roots Trellis LEMP. Aconteceu após a importação de dados do WooCommerce. Nunca tive isso antes. O que você recomendaria nesses casos? Remover o parâmetro $uri/? Veja o parâmetro aqui: github.com/roots/trellis/blob/…
rhand

2

Como outros já declararam, este é o culpado:

    try_files $uri $uri/ ;

Ele cria um loop de redirecionamento, já que o último parâmetro de try_filesdeve apontar para o local se o arquivo não for encontrado. Eu resolvi adicionando um =404, assim:

    try_files $uri $uri/ =404 ;
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.