说到location块优先级对rewrite的影响，让我想起上周排查的一个线上故障。当时用户反馈某个API接口一直302重定向，调试时发现两个location块的rewrite规则互相“打架”——明明配置看起来都没问题，但Nginx就是陷入了死循环。这种问题往往是因为我们对location匹配机制理解不够深入。你知道吗？Nginx处理请求时，会先按特定顺序匹配location，再执行其中的rewrite规则，这个过程中location的优先级直接决定了rewrite能否按预期执行。
location匹配的“潜规则”
很多人以为nginx是从上到下按顺序匹配location的，其实不然！它有一套严格的优先级规则：精确匹配（=）最高，接着是前缀匹配（^~），然后是正则匹配（~或~*），最后才是普通前缀匹配。上周我遇到的案例中，就是因为一个带^~的location块“截胡”了本该由正则location处理的请求，导致rewrite完全没机会执行。这种感觉就像在超市排队结账时，突然有人走了快速通道——后面的队伍再长也得等着。
rewrite在location中的“生存法则”
当请求进入某个location后，rewrite规则的执行就完全受制于这个location的匹配类型了。有意思的是，如果请求匹配的是正则location，nginx会继续检查其他正则location，但如果是普通前缀匹配，一旦找到最长的匹配项就会停止搜索。这就解释了为什么有时候调整location顺序似乎没用——因为优先级规则已经决定了哪个location胜出。我建议大家在测试时，可以先用return指令验证location匹配情况，确认无误后再添加rewrite规则。
记得有次我为了一个URL重写问题折腾了半天，最后发现是location = /api 这个精确匹配阻止了请求进入location ~ /api/v1 这个我更期望的区块。这种细节真的需要实际操作才能深刻体会！所以下次配置rewrite时，不妨先画个location优先级关系图，这比盲目试错要高效得多。
评论