正则符号仅用于~和~*匹配，不可用于=、^~或普通前缀匹配；必须置于修饰符后uri中，需转义特殊字符（如.、$），且匹配顺序自上而下，一旦命中即终止。
正则符号在 Nginx location 中只用于 ~（区分大小写）和 ~*（不区分大小写）这两类匹配，不能用在 =、^~ 或无修饰符的前缀匹配里。写错位置或误用会直接导致匹配失败或被跳过。
常用正则符号及实际写法
这些符号必须放在 ~ 或 ~* 后面的 URI 模式中，且整个模式要能被 Nginx 正确解析：
-
^：匹配 URI 开头。例如
location ~ ^/api/ { ... }只匹配以/api/起始的请求，/v1/api/就不匹配。 -
$：匹配 URI 结尾。例如
location ~* \.(js|css|html)$ { ... }匹配以指定后缀结尾的请求，注意\.是转义点号，否则.会匹配任意单字符。 -
\d、\w、\s：Nginx 支持基本 POSIX 字符类，但不支持 Perl 风格的简写（如
\d在部分旧版本中不可用）。稳妥写法是显式范围：[0-9]、[a-zA-Z0-9_]、[[:space:]]或空格字符本身。 -
|（或）：用括号包裹多个选项，例如
location ~ ^/(user|admin|post)/\d+$ { ... }匹配/user/123、/admin/456等。 -
{n,m}、+、*、?：支持，但需注意语义。例如
/file-?\d+\.txt可匹配/file123.txt和/file-456.txt；/v[1-3]/.*匹配/v1/anything到/v3/xxx。
容易踩坑的写法
正则匹配不是“越复杂越准”，而是“越贴合实际路径越稳”：
- 末尾漏
$：比如~ \.jpg会错误匹配/photo.jpg.bak，应写成~ \.jpg$。 - 未转义特殊字符：URI 中的
.、?、+、(、)等必须加反斜杠，否则按正则含义解释。例如匹配字面量/static/v2.1/，得写~ ^/static/v2\.1/。 - 忽略大小写误用：用
~*时，/IMG/LOGO.PNG和/img/logo.png都能命中，但后端文件名仍需真实存在——Nginx 不改写文件名，只做路由判断。 - 正则顺序影响结果：Nginx 按配置文件从上到下扫描，一旦匹配就停止。所以更具体的正则（如带
^和$的）建议放前面，宽泛的（如~ \..*$）放后面，避免被提前截断。
和前缀匹配（^~）的配合逻辑
^~ 和正则不会同时生效——只要某个 ^~ 匹配成功（比如 location ^~ /images/），Nginx 就不再检查后续所有 ~ 或 ~* 块。这是关键设计：
- 想让图片静态资源走高效前缀匹配，就用
^~ /images/； - 想对某些特定图片做特殊处理（如加水印），再单独加一条
location ~* /images/.*special\.png$，但这条必须写在^~块之前，否则永远进不去。
调试技巧
正则是否生效，不能靠猜，要看实际行为：
- 用
curl -I http://host/xxx查看响应头中的Server或自定义add_header X-Matched-Location "xxx";辅助定位； - 开启 Nginx debug 日志（
error_log /path/to/log debug;），搜索"test location"相关行，能看到每一步匹配过程； - 简单验证可用在线工具（如 regex101.com），但注意选 PCRE 模式，并把 URI 路径（不含协议和域名）作为输入字符串测试。
