Nginx Rewrite对常规扩展名失效问题求助

这个问题其实是Nginx的location匹配优先级机制在搞鬼，我来帮你拆解清楚：

核心原因：正则location的优先级高于前缀location #

你配置的location /playernew是普通前缀匹配（不带任何修饰符），而Nginx默认配置里通常会包含针对常见静态资源或脚本的正则匹配location（比如location ~* \.css$、location ~ \.php$这类）。

Nginx的location匹配优先级规则是：

• ^~修饰的前缀匹配 > 正则匹配（~或~*） > 普通前缀匹配 > 通用匹配/

当你访问带.css、.php这类常规扩展名的URL时，请求会先被这些高优先级的正则location匹配到，直接进入对应的处理逻辑，完全不会走到你写的location /playernew块里——这就是为什么日志里看不到任何记录，规则仿佛不存在。

而.csss、.phpp这类非常规扩展名，默认配置里没有对应的正则location，所以请求会匹配到你的普通前缀location /playernew，规则自然就生效了。

解决方案：提升你的前缀location优先级 #

最简单的解决方法是给你的location /playernew加上^~修饰符，让它的优先级高于所有正则location：

location ^~ /playernew {
    error_log /home/heyka/rewrite-error.log debug;
    # 简化掉if，直接用rewrite原生正则匹配更高效
    rewrite ^/playernew/[A-Za-z0-9_-]+/(.+)$ /playernew/$1 break;
}

补充：为什么建议去掉if？ #

Nginx里的if指令有不少坑（官方文档也不推荐滥用），直接用rewrite的原生正则匹配，逻辑更清晰，性能也更好，完全可以替代你原来的if+rewrite组合。

验证思路 #

你可以检查一下你的Nginx主配置或站点配置文件，大概率能找到类似下面的正则location块，这些就是抢占了匹配优先级的"元凶"：

# 静态资源匹配示例
location ~* \.(css|js|png|jpg|gif)$ {
    root /path/to/static;
    expires 30d;
}

# PHP脚本匹配示例
location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    # 其他PHP相关配置
}

当你加上^~后，所有以/playernew开头的请求都会优先进入你的location块，不管扩展名是什么，rewrite规则就能正常生效了。

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