bizarro 404 no nginx

Question

Eu tenho um bloco de localização para / que passa todos os caminhos virtuais para index.php conforme instruído na página de armadilhas do nginx. Eu tenho usado essa configuração há algum tempo, mas recentemente eu notei que alguns URLs com - no segmento de caminho retornam 404 em nginx, o que significa que eles nunca alcançam o script php. Não tenho certeza se está relacionado ao - no URL ou não. algumas rotas trabalham com ele, outras não.

funciona: /profiles/recently-added

retorna 404: %código% /explore/puerto-rico

bloco de servidores:

server {
    listen 80;
    server_name example.com;
    root /usr/share/nginx/hosts/www/;

    location ~ \.(php)$ {
        # commented out next 3 lines to see if that was the problem, but alas it made no change
        # try_files $uri = 404;
        # location ~ \..*/.*\.php$ {return 404;}
        # fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_keep_conn on;
        fastcgi_pass unix:/var/run/hhvm/hhvm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }

    location ~* .(png|gif|jpg|jpeg|ico|css|js)$ {
        include /etc/nginx/mime.types;
        expires 365d;
    }

    location / {
        include /etc/nginx/mime.types;
        index index.php;
        try_files $request_uri $request_uri/ /index.php?$query_string;
    }

}

Estou lutando para entender o que fiz de errado aqui. Eu fiz esta pergunta uma vez antes, e não foi bem recebida. A versão nginx é da ramificação da linha principal, versão /puerto-rico

    

Answer 1

Regex de localização incorreta

O problema é este regex de localização:

location ~* .(png|gif|jpg|jpeg|ico|css|js)$ {
            ^

O período aqui não significa apenas um período - significa qualquer caractere . Assim, corresponde a rico de puerto-rico . Para corresponder a um período real, ele precisa ser evitado:

location ~* \.(png|gif|jpg|jpeg|ico|css|js)$ {

Identificando problemas sem adivinhar

Usar o log de depuração removerá o mistério desses problemas. Aplicado à configuração da questão (algumas linhas omitidas por brevidade):

...
2016/06/08 12:38:58 [debug] 7056#7056: *133 http process request line
2016/06/08 12:38:58 [debug] 7056#7056: *133 http request line: "GET /puerto-rico HTTP/1.1"
2016/06/08 12:38:58 [debug] 7056#7056: *133 http uri: "/puerto-rico"
2016/06/08 12:38:58 [debug] 7056#7056: *133 http args: ""
2016/06/08 12:38:58 [debug] 7056#7056: *133 http exten: ""
2016/06/08 12:38:58 [debug] 7056#7056: *133 posix_memalign: 000000000229E060:4096 @16
2016/06/08 12:38:58 [debug] 7056#7056: *133 http process request header line
2016/06/08 12:38:58 [debug] 7056#7056: *133 http header: "User-Agent: curl/7.26.0"
2016/06/08 12:38:58 [debug] 7056#7056: *133 http header: "Accept: */*"
2016/06/08 12:38:58 [debug] 7056#7056: *133 http header: "Host: example.com"
2016/06/08 12:38:58 [debug] 7056#7056: *133 http header done
2016/06/08 12:38:58 [debug] 7056#7056: *133 event timer del: 7: 1465389598899
2016/06/08 12:38:58 [debug] 7056#7056: *133 generic phase: 0
2016/06/08 12:38:58 [debug] 7056#7056: *133 rewrite phase: 1
2016/06/08 12:38:58 [debug] 7056#7056: *133 test location: "/"
2016/06/08 12:38:58 [debug] 7056#7056: *133 test location: ~ "\.(php)$"
2016/06/08 12:38:58 [debug] 7056#7056: *133 test location: ~ ".(png|gif|jpg|jpeg|ico|css|js)$"
2016/06/08 12:38:58 [debug] 7056#7056: *133 using configuration ".(png|gif|jpg|jpeg|ico|css|js)$"
...
2016/06/08 12:38:58 [debug] 7056#7056: *133 http filename: "/var/www/puerto-rico"
2016/06/08 12:38:58 [debug] 7056#7056: *133 add cleanup: 0000000002301A48
2016/06/08 12:38:58 [error] 7056#7056: *133 open() "/var/www/puerto-rico" failed (2: No such file or directory), client: 127.0.0.1, server: example.com, request: "GET /puerto-rico HTTP/1.1", host: "example.com"
2016/06/08 12:38:58 [debug] 7056#7056: *133 http finalize request: 404, "/puerto-rico?" a:1, c:1
2016/06/08 12:38:58 [debug] 7056#7056: *133 http special response: 404, "/puerto-rico?"
2016/06/08 12:38:58 [debug] 7056#7056: *133 http set discard body
2016/06/08 12:38:58 [debug] 7056#7056: *133 xslt filter header
2016/06/08 12:38:58 [debug] 7056#7056: *133 HTTP/1.1 404 Not Found
Server: nginx/1.8.0
Date: Wed, 08 Jun 2016 12:38:58 GMT
Content-Type: text/html
Content-Length: 168
Connection: keep-alive

Mostra o que o nginx estava fazendo com a solicitação. Esta linha:

using configuration ".(png|gif|jpg|jpeg|ico|css|js)$"

É a evidência conclusiva de que a solicitação correspondeu a um bloco de localização que você não esperava, e colocaria em foco a única regra que está no escopo da solicitação.

    

Answer 2

Claramente, o problema não está relacionado ao nginx. Olhe para o problema no lado hhvm, especialmente com a existência de index.php onde eles deveriam ser para trabalhar em caminhos para URI

index index.php;

Talvez queira reescrever os URLs. Note que .htaccess não funciona - é um recurso do apache. Para nginx: link