Je me tape la tête contre une table en essayant de comprendre ce qui cause le cycle de redirection dans ma configuration nginx lorsque j'essaie d'accéder à une URL qui n'existe pas La configuration se présente comme suit:
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;
}
ce domaine est un simple site HTML STATIQUE, uniquement à des fins de test. Je m'attendrais à ce que la directive error_page se déclenche en réponse au fait que PHP-FPM ne soit pas en mesure de trouver les fichiers donnés car j'ai fastcgi_intercept_errors; dans le bloc http et la nef error_page mis en place, mais je suppose que la demande échoue avant même quelque part sur les redirections internes. Toute aide serait très appréciée.
Réponses:
Le coupable est:
try_files $uri $uri/ ;
http://nginx.org/r/try_files (notez que le dernier paramètre est le code retour ou l'URI vers la redirection interne)
la source
$uri/
? Voir le paramètre ici: github.com/roots/trellis/blob/…Comme d'autres l'ont dit, c'est le coupable:
Il crée une boucle de redirection, car le dernier paramètre de
try_files
doit pointer vers l'emplacement si le fichier n'est pas trouvé. Je l'ai résolu en ajoutant un=404
, comme ceci:la source