Nginx try_files 指令的工作方式很奇怪答案

【问题标题】：Nginx try_files directive works weirdNginx try_files 指令的工作方式很奇怪
【发布时间】：2017-07-12 20:48:45
【问题描述】：

花了几个小时试图找出问题所在，但没有找到。

这是我想要实现的目标：

当用户请求 js 文件时，我想检查共享内存中是否存在 uglified 副本，如果存在则提供它。如果没有 uglified 副本，我想提供常规文件。

这是我的位置：

location ~/require/[a-z0-9]+/(.*) {
   try_files /dev/shm/uglified/$1 /public/javascripts/$1;
}

如您所见，如果用户请求文件/require/fe45be18b99f9099efbc98a71f67924aef72d58a/app/require-config.js

我们应该检查文件/dev/shm/uglified/app/require-config.js是否存在，如果存在则提供它。
如果文件 app/require-config.js 未在 1 中提供，则从 /public/javascripts/ 位置提供文件。

嗯，它看起来很简单，但行不通。所有文件都存在 - 在 dev/shm 和 public 位置。

但是：

永远不会提供来自 dev/shm 文件夹的文件，无论此位置在 try_files 指令中是第一个还是第二个。
仅提供来自 public 位置的文件，并且如果它在 try_files 指令中位于第二位。

例如try_files /dev/shm/uglified/$1 /public/javascripts/$1; 有效

try_files /public/javascripts/$1 /dev/shm/uglified/$1; 不起作用，虽然我只是在指令中更改了位置。

谁能告知为什么 /dev/shm 中的文件从未被拾取以及为什么 try_files 指令中的位置顺序很重要？

【问题讨论】：

try_files 需要 URI 作为参数，而不是路径名。路径名是从文档根目录构造的（由root 指令指定）。也许您可以将共享内存映射或符号链接到文档根目录。
谢谢！您的评论对寻找解决方案很有帮助

标签： nginx

【解决方案1】：

感谢@Richard Smith 的评论，我想出了如何让它发挥作用：

#that's the basic location, where we just redirect request to /dev/shm/ location
location ~/require/[a-z0-9]+/(.*) {
    echo_location /dev/shm/uglified/$1;
}

#that's location to serve files from shared memory
location ~ ^/dev/shm/uglified/(.*) {

    #set the root
    root /dev/shm/uglified/;

    #try file in this file, if it does not exist, redirect to public location
    try_files /$1 /public/javascripts/$1;

}

【讨论】：