^= 修饰符表示精确匹配且最高优先级，要求uri与路径逐字节完全相等（忽略定义中末尾/），匹配后立即执行不比较其他location。
Nginx 中 location 使用 ^= 修饰符，表示“精确匹配且最高优先级”，它会跳过其他所有匹配规则（包括更长的前缀匹配和正则匹配），只要请求路径与指定字符串**完全一致**，就立即选用该块，不再比较后续 location。
^= 的核心行为
^= 不是正则表达式，也不是“以…开头”，而是一个特殊标记：它要求 URI 必须与后面紧跟的字符串**逐字节完全相等**（忽略末尾可选的 /，但仅限于 location 块中定义的字符串末尾是否带 /；实际请求 URI 的结尾斜杠仍需严格对应）。
- 匹配成功后，Nginx 直接执行该
location块，不检查任何其他location - 优先级高于
=（普通精确匹配）、^~（非正则前缀匹配）、普通前缀匹配，也高于所有~/~*正则匹配 - 它只作用于完整路径（不含 query string），例如
/api不匹配/api?x=1，但匹配请求GET /api HTTP/1.1
正确写法与常见误区
语法格式为：location ^= /path { ... }。注意：
- 必须紧挨着
^=写路径，中间不能有空格：location ^= /login✅，location ^= /login❌（空格导致解析失败） - 路径区分大小写，
^= /Login不匹配/login - 不支持变量或通配符，只能是静态字符串
- 若同时存在
^= /和= /，^= /会胜出；但通常没必要这样写，因为= /已足够高效
典型使用场景
适用于需要对某个关键路径做绝对隔离、零干扰处理的情况：
- 健康检查端点：
location ^= /healthz { return 200 "ok"; }，确保不被其他泛匹配规则（如location / { proxy_pass ...; }）意外覆盖 - 静态入口文件强制处理：
location ^= /index.html { add_header Cache-Control "no-store"; } - 敏感管理路径拦截：
location ^= /admin/login { auth_request /auth; }，避免被location /admin { ... }的宽松配置绕过
对比其他精确匹配方式
别把 ^= 和 = 混淆：
-
= /foo是精确匹配，优先级高，但低于^= /foo -
^= /foo在匹配逻辑上更“激进”——它不参与常规的最长前缀比对流程，而是直接插队判定 - 实践中
=已满足绝大多数精确需求；只有在极少数需要压制所有其他潜在匹配（包括看似更具体的前缀块）时，才用^=
