Nginx中try_files与if块配合触发404错误求助

问题根源 #

出现404的核心原因是Nginx变量$request_uri与$uri的差异，以及if指令对location处理上下文的干扰：

• $request_uri是客户端发送的原始请求URI，保留了未解码的百分号编码格式（比如你配置里的/jp/%e8%a9%90%e6%ac%ba%e5%b8/）；
• $uri是Nginx内部解码后的请求路径，和服务器文件系统中的实际路径完全一致。

当if条件用$request_uri匹配编码后的字符串时，进入if块会生成新的内部处理上下文，此时try_files会尝试查找编码格式的路径，但服务器上的实际文件路径是解码后的，自然找不到对应文件，返回404。而非编码的URL（如/jp/example/）编码和解码后内容一致，所以能正常匹配到文件。

解决方法 #

方法1：改用解码后的$uri做匹配

把if条件里的$request_uri替换为$uri，同时将匹配值改成解码后的实际路径：

if ($uri = '/jp/駐車/') {
    add_header X-Header-Custom "test";
}

这种方式既保证条件匹配准确，又不会干扰try_files对实际文件路径的查找逻辑。

方法2：用正则匹配编码URI（备选，不推荐）

如果必须保留编码格式的匹配，可改用正则表达式匹配$request_uri，同时确保try_files的路径解析不受影响：

if ($request_uri ~* '^/jp/%e8%a9%90%e6%ac%ba%e5%b8/$') {
    add_header X-Header-Custom "test";
}

但这种方式维护成本高，编码格式的大小写、转义规则都可能导致匹配失效，不如方法1可靠。

优化建议：用map替代if（推荐）

Nginx官方文档提示if指令存在逻辑陷阱，尽量避免在location块中使用。如果场景允许，推荐用map指令来设置自定义header：

map $uri $custom_header {
    '/jp/駐車/' "test";
}

server {
    # ...其他配置
    location / {
        try_files $request_uri $request_uri/index.html =404;
        add_header X-Header-Custom $custom_header;
    }
}

这种方式更贴合Nginx的运行逻辑，彻底避免if带来的上下文干扰问题。

内容的提问来源于stack exchange，提问作者Doraemon