为何Nginx会跳过location块？URL重定向问题排查求助

问题场景 #

尝试通过location和return指令实现URL重定向，剥离URL中的/CustomContext前缀，但Nginx始终忽略所有location块，直接返回444。

失效的Nginx配置 #

server {
    listen 8120 ssl; # legacy HTTPS port
    server_name server.domain.com;

    error_log /var/log/nginx/error.log debug;

    location / {
        return 444;
    }

    location ~ "^/CustomContext/(.*)$" {
        return 301 https://custom.domain.com/$1$is_args$args;
    }
    
    return 444;
}

调试日志异常表现 #

从debug日志可以看到，请求进入rewrite phase: 1后直接触发了444返回，完全没有进入location匹配环节：

2025/06/24 11:45:18 [debug] 20#20: *1 http header done
2025/06/24 11:45:18 [debug] 20#20: *1 event timer del: 14: 176555899
2025/06/24 11:45:18 [debug] 20#20: *1 generic phase: 0
2025/06/24 11:45:18 [debug] 20#20: *1 rewrite phase: 1
2025/06/24 11:45:18 [debug] 20#20: *1 http finalize request: 444, "/CustomContext/services/version?" a:1, c:1

可行的替代方案（rewrite指令） #

改用rewrite指令可以正常实现重定向：

server {
    listen 8120 ssl; # legacy HTTPS port
    server_name server.domain.com;

    rewrite ^/CustomContext/(.*)$ https://custom.domain.com/$1$is_args$args permanent;

    return 444;
}

问题根源与修复 #

核心原因 #

server块级别的return 444会在location匹配阶段之前的rewrite处理阶段执行。当请求进入server块后，先执行了末尾的return 444，直接终止请求，根本没走到location匹配的步骤。

修复后的location配置 #

移除server块级的return 444，仅在兜底的location /中保留返回444的逻辑，确保请求先完成location匹配：

server {
    listen 8120 ssl; # legacy HTTPS port
    server_name server.domain.com;

    error_log /var/log/nginx/error.log debug;

    # 正则location优先级高于前缀location，优先匹配
    location ~ "^/CustomContext/(.*)$" {
        return 301 https://custom.domain.com/$1$is_args$args;
    }

    # 兜底匹配所有未命中的请求
    location / {
        return 444;
    }
}

逻辑说明 #

Nginx的location匹配遵循优先级规则：正则表达式location（~开头）的优先级高于普通前缀location。调整配置后，请求会先尝试匹配/CustomContext/的正则location，匹配成功则执行重定向；未匹配到的请求才会进入location /返回444，完全符合预期逻辑。

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