☰

nginx 重写或内部重定向循环

tag-icon • tag-icon nginx
nginx 重写或内部重定向循环

我绞尽脑汁想找出是什么导致了我的 nginx 配置中的重定向循环，当我尝试访问不存在的 URL 时，配置如下：

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;
}

此域名是一个简单的静态 HTML 网站，仅用于一些测试目的。我期望 error_page 指令能够响应 PHP-FPM 无法找到给定文件的情况，因为我已在 http 块中启用 fastcgi_intercept_errors；并且已设置 nave error_page，但我猜想请求甚至在此之前在内部重定向的某个地方就失败了。任何帮助都将不胜感激。

答案1

罪魁祸首是：try_files $uri $uri/ ;

http://nginx.org/r/try_files（请注意，最后一个参数是返回代码或内部重定向的 URI）

如果没有找到任何文件，则进行内部重定向到最后一个参数指定的 uri。

答案2

正如其他人所说，罪魁祸首是：

    try_files $uri $uri/ ;

它创建了一个重定向循环，因为 的最后一个参数try_files应该指向文件未找到时的位置。我通过添加 解决了这个问题=404，如下所示：

    try_files $uri $uri/ =404 ;

相关内容