NGINX try_files +别名指令

Ale*_*tin 30 nginx

我正在尝试使用php代码向站点的/ blog子目录提供请求,该代码位于文档根目录之外的文件夹中.这是我的主机配置:

server {
    server_name  local.test.ru;
    root   /home/alex/www/test2;

    location /blog {
        alias   /home/alex/www/test1;
        try_files $uri $uri/ /index.php$is_args$args;

        location ~ \.php$ {
            fastcgi_split_path_info ^(/blog)(/.*)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            include fastcgi_params;
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

我得到的请求就像

wget -O - http://local.test.ru/blog/nonExisting

只是来自/ home/alex/www/test2 /文件夹的index.php文件的代码.

但是,这个配置:

server {
    server_name  local.test.ru;
    root   /home/alex/www/test2;

    location /blog {
        alias   /home/alex/www/test1;
        try_files $uri $uri/ /blog$is_args$args;
        index index.php;

        location ~ \.php$ {
            fastcgi_split_path_info ^(/blog)(/.*)$;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
            include fastcgi_params;
        }
    }
}
Run Code Online (Sandbox Code Playgroud)

从/ home/alex/www/test2 /给我index.html文件.请给我一个线索 - 为什么?我怎样才能强制NGINX处理/home/alex/www/test1/index.php呢?

Mot*_*tin 28

我们无法通过在位置块中指定root来使其工作.我们的解决方案是使用别名.请注意,必须在try_files指令中重复两次位置的路径,然后在.php配置块中重复:

server {
    server_name localhost;
    root /app/frontend/www;

    location /backend/ {

        alias /app/backend/www/;

        # serve static files direct + allow friendly urls
        # Note: The seemingly weird syntax is due to a long-standing bug in nginx: https://trac.nginx.org/nginx/ticket/97
        try_files $uri $uri/ /backend//backend/index.php?$args;

        location ~ /backend/.+\.php$ {
            include fastcgi_params;
            fastcgi_buffers 256 4k;
            fastcgi_param SCRIPT_FILENAME $request_filename;
            fastcgi_param HTTPS $proxied_https;
            fastcgi_pass phpfiles;
        }

    } # / location

}
Run Code Online (Sandbox Code Playgroud)

来源:nginx的/ conf.d/app.confDebian的PHP-nginx的堆泊坞窗堆栈项目

  • "请注意,有必要在try_files指令中重复两次位置的路径".....?!看起来很错,但实际上有效!谢谢,绝不会想到这一点! (4认同)
  • 谢谢老兄,在看到你的帖子之前我本来想杀人的。这个bug花了我几乎整个下午的时间才找到解决方案。 (3认同)
  • 我现在可以吻你了 (2认同)
  • @DylanHunt nginx中有一个错误,它需要在这里重复两次location指令.为什么?不知道 (2认同)

Fle*_*der 22

这是nginx中一个长期存在的错误.但是你可以root再次使用该指令来解决.有点黑客,但至少它有效.

server {
    index       index.php;
    root        /home/alex/www/test2;
    server_name local.test.ru;

    location /blog {
        root      /home/alex/www/test1;
        try_files $uri $uri/ /blog$is_args$args;
    }
}
Run Code Online (Sandbox Code Playgroud)

  • 也不敢相信这个bug在5年后仍然开启! (12认同)
  • 简单地用`root`替换'alias`是行不通的.在OP的情况下,`http:// localhost/blog`将在`/ home/alex/www/test1`中搜索,而在这里它将在`/ home/alex/www/test1/blog`中查找.虽然`/ blog/nonExisting`在这两种情况下都可能失败,但`/ blog`在之前的状态下不会起作用. (11认同)
  • 也不敢相信这个bug在3年后仍然开启! (11认同)
  • 也不敢相信这个bug在6年后仍然开启! (11认同)
  • 也不敢相信这个bug在4年后仍然开启! (10认同)
  • 也不敢相信8年后这个bug仍然存在! (8认同)
  • 不敢相信这个bug在2年后仍然开放! (5认同)
  • 2018年3月.6年 (5认同)
  • 也不能相信这个虫子在9000年后仍然开放! (4认同)
  • 也不敢相信这个错误仍然存​​在......等等,这还是一个东西吗? (4认同)
  • 保持传统活力!也不敢相信这个bug在9年后仍然存在! (4认同)
  • 来吧,10年了! (4认同)
  • 我错过了什么,但是这张票是在2012年创建的.那你怎么算6年?:) (3认同)
  • 也不敢相信这个bug在11年后仍然被打开! (3认同)
  • 我还有这个问题,2017年10月 (2认同)
  • 也不能相信这个错误在6年零6个月后仍然打开! (2认同)

Mel*_*fer 8

还有另一种解决方法可以提供更大的灵活性。它由proxy_pass指向127.0.0.1 的指令和另一个server块组成。

在您的情况下,它应如下所示:

upstream blog.fake {
    server 127.0.0.1;
}
server {
    server_name local.test.ru;
    root /home/alex/www/test2;
    index index.html;

    location /blog {
        proxy_pass http://blog.fake/;
    }
}
server {
    server_name blog.fake;
    root /home/alex/www/test1;

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php(/|$) {
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTPS off;
    }
}
Run Code Online (Sandbox Code Playgroud)

  • 优雅的解决方案 (2认同)
  • 到目前为止,这是最好的选择! (2认同)
  • 我真的很喜欢这个解决方案,它可以很容易地理解正在发生的事情,并且不需要复杂的嵌套。 (2认同)
  • 这值得更多的认可 (2认同)
  • 这个解决方案很棒,但它还需要使用“fastcgi_param REQUEST_URI /blog$request_uri;”将“/blog”部分重新添加到“REQUEST_URI”中,以便对 PHP 完全透明。 (2认同)