Nginx带查询字符串访问/schedule/ajax.php返回no matches found问题

1. Shell层面错误排查 #

你看到的no matches found报错优先是Shell解析问题：如果你使用的是zsh、fish等支持通配符扩展的Shell，URL中的?会被识别为通配符尝试匹配本地文件，匹配失败就会抛出该错误，请求根本没有发往Nginx。
临时验证方法：给URL加引号即可：

curl -I "http://example.com/schedule/ajax.php?m=item"

如果加引号后请求可以正常发出，说明是Shell问题，zsh环境下长期解决可以在Shell配置中添加setopt nonomatch避免通配符误解析。

2. Nginx配置存在的核心逻辑问题 #

排除Shell问题后如果请求仍然异常，是你的Nginx匹配规则优先级和处理逻辑有问题：

• Nginx的规则匹配逻辑中，正则location的优先级高于普通前缀location，你写的location /schedule/ajax.php是普通前缀匹配，而/schedule/块内存在location ~* ^.+\.php$的正则匹配规则，所以所有/schedule下带.php后缀的请求都会命中这个正则，根本不会走到你专门写的ajax.php前缀匹配块中。
• 命中正则规则后，执行try_files /dev/null @php，如果你的ajax.php实际存在，这一步会直接返回404，因为try_files第一个参数找/dev/null肯定不存在，无法正常向后传递请求。

修复方案 #

给ajax.php的location块添加^~修饰符，让它的优先级高于正则匹配，同时指定正确的处理逻辑：

# 加^~让该前缀匹配优先级高于后续的正则匹配
location ^~ /schedule/ajax.php {
    add_header X-debug-message-ajax "a: $args q:$query_string" always;
    # 直接交由PHP处理即可
    try_files $uri @php;
}

调整后/schedule/ajax.php的请求会优先命中这个块，不会被下面的.php正则拦截，就能正常处理带查询字符串的请求了。

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