Comportamento estranho com nginx try_files. O que há de errado na minha configuração?

Question

os: debian stable (squeeze) nginx: squeeze-backports 1.2.1-2 ~ bpo60 + 1

try_files apenas se comportam de maneira estranha para mim.

isso funciona como esperado, $ uri é tentado localmente se não for encontrado - > a localização @static é usada

try_files  $uri $uri/ @static;

apenas adicionando a = 404 ao final leva a um 404. ele ainda não funcionará se eu acessar um arquivo existente localizado em $ uri ou @static, e só servir um 404 se nada for encontrado no @static localização?

try_files  $uri $uri/ @static =404;

colocando o = 404 antes que o @static o faça funcionar novamente. porque? se o arquivo não estiver localizado no $ uri ou $ uri / location, mas no @static ele deve levar a 404, porque = 404 é antes do @static (para meu entendimento). Se eu colocar o acesso um arquivo que está localizado em $ uri é servido corretamente de nginx (não acertar o backend @static ou o = 404)

try_files  $uri $uri/ =404 @static ;

estou bastante confuso

edit: meu objetivo seria: testar se o arquivo é localmente, então verificar todos os servidores upstream para o arquivo e se não encontrado nesses locais retornar um 404

config:

upstream domain.com_upstream
{
    server yyy.yyy.yyy.yyy:8000 weight=10 max_fails=3 fail_timeout=3s;
    server zzz.zzz.zzz.zzz:8020 weight=10 max_fails=3 fail_timeout=3s;
}

server 
{
    server_name         www.domain.com;

    listen              xxx.xxx.xxx.xxx:80;

    location @static
    {
        proxy_ignore_client_abort off;
        proxy_intercept_errors    on;
        proxy_next_upstream       http_404 error timeout invalid_header;

        proxy_pass                  http://domain.com_upstream;
        proxy_redirect              off;
        proxy_set_header            Host                $host;
        proxy_set_header            X-Real-IP           $remote_addr;
        proxy_set_header            X-Forwarded-For     $proxy_add_x_forwarded_for;
        client_max_body_size        10m;
        client_body_buffer_size     128k;

        proxy_connect_timeout       10;
        proxy_send_timeout          120;
        proxy_read_timeout          120;

        proxy_buffers 8 16k;
        proxy_buffer_size 32k;
    }

    location ~ ^/test 
    { 
        root /var/www/test;
        try_files $uri @static =404; # exchange with upper try_file examples...
    }

    *** snip ***
}

    

Answer 1

Você entendeu mal os parâmetros try_files . Citação de docs :

If none of the files were found, an internal redirect to the uri specified by the last parameter is made.

Somente o último parâmetro é um URI de fallback (ou um local nomeado ou um código), todos os outros parâmetros são arquivos a serem testados. Ou seja,

try_files /file1 /file2 /file3 ... @fallback;

irá verificar os arquivos sob a raiz do documento (/ file1, / file2, / file3 e assim por diante), e se nada for encontrado, o nginx fará um redirecionamento interno para um @fallback.

O try_files ... @static =404; não faz muito sentido, pois testará um arquivo chamado @static na raiz do documento e provavelmente não é o que você deseja. O try_files ... =404 @static; também não faz sentido, pois ele testará um arquivo chamado =404 .

Veja aqui os documentos: link .

    

Answer 2

para conclusão (resposta de kolbyjack @ irc #nginx):

kolbyjack : Você só recebe um substituto. Qualquer que seja o @static ou o = 404 é o primeiro é testado quanto à existência como um arquivo. que irá falhar, e o nginx passa para o fallback

c33s : não sei se entendi, se eu definir várias opções try_file elas não são testados da esquerda para a direita?

kolbyjack : Certo, mas todos, exceto o último, são testados como arquivos no disco. Então try_files $ uri @static = 404; olha para $ document_root $ uri, então $ document_root @ static, e se nenhum desses existir, então é um problema 404. try_files $ uri = 404 @static procura $ document_root $ uri, então $ document_root = 404, e se nenhum dos existem, redireciona internamente para @static

c33s : portanto, se @static não é um local no sistema de arquivos local, ele só faz sentido como última opção?

kolbyjack : correto Tudo menos o último argumento deve ser coisas que você quer testar para existir no disco

c33s : você quer responder no serverfault para obter o representante? se não, eu copiaria sua resposta para serverfault e responderia a minha pergunta ...

kolbyjack : Vá em frente, estou muito ocupado