^~ 是Nginx中带优先级的前缀匹配，匹配成功即跳过所有正则规则，提升性能；适用于/static/、/api/v1/等确定性路径，区别于普通前缀匹配，不参与第二阶段正则扫描。
用 ^~ 可以让 Nginx 在匹配到某个前缀路径后立即停止后续正则表达式的检查，避免遍历所有 ~ 或 ~* 规则，从而减少匹配开销、提升请求处理速度。
^~ 的作用机制
^~ 不是正则匹配，而是“带优先级的前缀匹配”。它告诉 Nginx：只要请求 URI 以指定字符串开头，就立刻采用该 location 块，并跳过所有后续的正则匹配（~ 和 ~*）——哪怕配置文件里后面还有更“看起来合适”的正则规则，也不会再执行。
- 匹配过程分两阶段：先找所有普通字符串类 location（含
=、^~、无修饰符），选出最长前缀匹配项； - 如果其中某条用了
^~，Nginx 就直接采纳它，不再进入第二阶段（正则顺序扫描）； - 如果没有
^~，才会按配置顺序逐条检查~/~*，直到第一个命中为止。
典型高性能使用场景
适合静态资源目录、固定 API 前缀等高频、确定性路径，例如：
-
location ^~ /static/ { root /var/www/assets; }—— 所有/static/xxx请求不走正则，直接返回文件； -
location ^~ /api/v1/ { proxy_pass http://backend_v1; }—— 版本化接口前缀，避免被location ~ \.php$或其他泛匹配干扰； -
location ^~ /health { return 200 "OK"; }—— 健康检查端点，零磁盘 I/O，毫秒响应。
和普通前缀匹配（无修饰符）的区别
比如同时存在：
location /static/ { ... }<br>location ~ \.(js|css|png)$ { ... }
当请求 /static/main.js 时，Nginx 会先选中 /static/（最长前缀），但因为没加 ^~，它仍会继续检查后面的正则规则，最终可能落到 ~ \.(js|css|png)$ 上——多一次正则编译与执行。而换成：
location ^~ /static/ { ... }<br>location ~ \.(js|css|png)$ { ... }
同一请求将直接命中 ^~ 分支，跳过正则环节，省掉不必要的计算。
注意事项
-
^~只影响正则匹配阶段，不影响=精确匹配（=优先级更高，始终最先判断）； - 路径末尾斜杠需保持一致：
^~ /static和^~ /static/是两个不同前缀，后者才能匹配/static/css/app.css； - 不能和正则混用：
^~后只能跟普通字符串，不能写^~ /static/.*这类伪正则； - 调试时可用
nginx -t验证语法，用error_log debug查看实际匹配路径（需编译时启用 debug 日志）。
