nginx安全防控始于请求路径匹配，需严格遵循location四层优先级（=、^~、~/~*、普通前缀），并配合root/alias正确用法、路径遍历防护、正则校验及try_files存在性验证构建完整防线。
请求路径匹配是 Nginx 安全防控的起点，不是单纯路由转发的技术细节，而是第一道访问控制闸门。匹配逻辑一旦出错，后续所有安全措施都可能形同虚设——比如本该限制在 /static/ 下的文件，却因 location 配置不当被绕过，直接暴露系统敏感路径。
理解 location 匹配优先级，避免“看似生效实则失效”
location 的匹配顺序直接影响请求是否落入你预设的安全规则中。Nginx 不按书写顺序执行，而是严格遵循四层优先级：
-
精确匹配（=）：如
location = /healthz，只匹配完全一致的 URI，命中即终止，适合关键探针接口的独立管控； -
前缀最高优（^~）：如
location ^~ /api/，匹配以/api/开头的路径，且不进入正则匹配流程，性能高、行为确定，推荐用于静态资源或 API 前缀； -
正则匹配（~ 或 ~*）：按配置出现顺序逐条尝试，首个成功即停；区分大小写（~）或忽略（~*），适合扩展名过滤（如
~* \.(js|css|png)$）； - 普通前缀（无修饰符）：兜底匹配，但优先级最低，容易被更高优先级规则覆盖，慎用于安全敏感路径。
常见误区：把 location /static 和 location ~ \.js$ 并列写，以为能同时生效。实际上，若请求为 /static/app.js，会先命中 /static（普通前缀），而不会走到 JS 正则——除非你用 ^~ /static/ 明确锁定前缀并阻止后续正则介入。
用 root 与 alias 的差异堵死路径遍历漏洞
路径遍历攻击（如 /files/../../../etc/passwd）之所以得逞，往往源于对 root 和 alias 拼接逻辑的误判：
-
root 指令是“追加”：配置
location /files/ { root /var/www/data; }，请求/files/test.txt→ 实际读取/var/www/data/files/test.txt；但请求/files/../../etc/passwd→ 尝试读取/var/www/data/files/../../etc/passwd，即/var/www/data/../etc/passwd，存在越界风险； -
alias 指令是“替换”：配置
location /files/ { alias /var/www/data/; }，请求/files/test.txt→ 直接映射到/var/www/data/test.txt；但若 URI 中含../，Nginx 默认仍会解析并拼接，/files/../etc/passwd可能变成/var/www/data/../etc/passwd，同样危险。
真正安全的做法是：在 location 块内主动拒绝含 .. 的路径。例如：
location ^~ /static/ {
if ($request_uri ~ "\.\.") {
return 403;
}
alias /var/www/static/;
}
或更稳妥地结合 try_files，只允许访问明确存在的文件：
location ^~ /static/ {
alias /var/www/static/;
try_files $uri =404;
}
用正则 + 内置变量做路径净化与白名单校验
仅靠 location 类型不够，还需对 URI 内容做细粒度校验。Nginx 提供 $uri、$request_uri 等变量，配合正则可实现动态过滤：
- 禁止 URL 中出现编码后的路径穿越字符：
if ($request_uri ~ "(%2e%2e|%2e%2f|\.%2e|\.%2f)") { return 403; }； - 强制静态资源路径只能含字母、数字、下划线、连字符和斜杠：
if ($uri !~ "^/static/[a-zA-Z0-9_\-/\.]+$") { return 403; }； - 对上传目录启用严格白名单，只允许特定后缀：
location ^~ /uploads/ { if ($uri !~ "\.(jpg|jpeg|png|gif)$") { return 403; } }。
注意：if 在 location 内使用是安全的，但在 server 或 http 块顶层应避免，因其可能引发非预期重写行为。
结合 try_files 构建“存在性防御”闭环
try_files 不仅是优化静态服务的工具，更是安全防线的关键一环。它要求 Nginx 必须验证目标文件真实存在，否则拒绝响应，从根源上阻断伪造路径的探测：
- 配置
try_files $uri =404;，意味着任何无法映射到真实文件的请求（包括试图穿越的路径）都会返回 404，而非 403 —— 减少信息泄露； - 搭配
alias使用时，$uri是相对路径，需确保别名目录结构清晰、无冗余符号链接； - 若需返回统一错误页，可用
try_files $uri /404.html;，但注意/404.html本身也应受保护，避免被当作资源目录遍历入口。
这一机制让攻击者无法通过响应码差异判断路径是否存在，大幅增加自动化扫描成本。
