在 nginx 中，`proxy_pass` 配合正则 `location` 实现精准代理的核心在于处理 uri 的传递方式。当 `location` 指令使用 `~`（区分大小写）或 `~*`（不区分大小写）前缀时，nginx 会将匹配到的正则表达式中的捕获组内容附加到 `proxy_pass` 指定的后端地址之后。如果 `proxy_pass` 后面没有以斜杠 `/` 结尾，nginx 会将整个原始请求 uri 传递给后端；如果以斜杠结尾，则只传递正则捕获的部分。因此，要实现精准代理，通常需要在 `proxy_pass` 后加上斜杠，并在正则表达式中使用括号明确需要提取的路径片段。
如何配置 location 以匹配特定路径并转发
要配置一个能匹配特定路径段并转发的规则，可以使用带有捕获组的正则表达式。例如，假设我们需要将所有 `/api/v1/` 开头的请求转发给后端服务，但希望保留后续的路径。我们可以定义一个 `location ~ ^/api/(v[0-9]+)(/.*)$` 的规则。在这个例子中，`^/api/` 是固定前缀，`(v[0-9]+)` 捕获版本号，`(/.*)` 捕获剩余路径。关键在于 `proxy_pass` 的写法。如果写成 `proxy_pass http://backend;`，Nginx 会将完整的 `/api/v1/users` 发给后端，这可能不是我们想要的。如果写成 `proxy_pass http://backend/$2;`，Nginx 会将捕获的第二组内容（即 `/users`）追加到后端地址。这种机制允许我们剥离 URL 的前缀部分，只将业务相关的路径发送给后端应用。
server {
listen 80;
server_name example.com;
# 匹配 /api/ 开头，捕获版本号和剩余路径
location ~ ^/api/(v[0-9]+)(/.*)$ {
# 注意：这里没有以斜杠结尾，且使用了 $2
# 实际上，更常见的做法是直接 proxy_pass 不带变量，或者带斜杠
# 让我们看一个更标准的精准代理示例：
# 场景：将 /app/xxx 转发到后端 /xxx
location ~ ^/app(.*)$ {
proxy_pass http://127.0.0.1:8080$1;
}
}
}
上述代码展示了一个典型的精准代理场景。正则 `^/app(.*)$` 匹配以 `/app` 开头的任何请求，并将 `/app` 之后的所有内容捕获到 `$1` 中。在 `proxy_pass` 指令中，我们使用 `http://127.0.0.1:8080$1`。当用户访问 `/app/users/list` 时，`$1` 的值为 `/users/list`，最终请求被发送到 `http://127.0.0.1:8080/users/list`。这种方式实现了 URL 前缀的剥离，是精准代理的常用手段。需要注意的是，如果 `proxy_pass` 后面直接跟斜杠，如 `proxy_pass http://127.0.0.1:8080/;`，那么 `$1` 将被忽略，Nginx 只会发送 `/` 给后端，这通常不符合精准代理的需求。因此，在使用正则 location 时，务必检查 `proxy_pass` 是否包含变量引用以及是否以斜杠结尾，这两者决定了 URI 的最终形态。
如何处理不同 HTTP 方法的代理差异
在处理正则 location 时，除了 URI 路径，HTTP 方法（GET, POST 等）的透传也是关键。Nginx 默认会原样转发客户端的请求方法给后端服务器，无需额外配置。然而，在某些复杂场景中，可能需要根据请求方法执行不同的代理逻辑。虽然 `proxy_pass` 本身不支持基于方法的分支选择，但可以通过结合 `if` 指令或分离多个 `location` 块来实现。不过，官方文档建议尽量避免在 `location` 中使用 `if`，因为这可能导致不可预期的行为。更稳健的做法是为不同的方法定义独立的正则 location 块，或者在后端应用中处理方法路由。对于大多数标准代理需求，只要确保 `proxy_pass` 正确指向后端，Nginx 会自动处理 HEAD、OPTIONS 等方法的透传。特别需要注意的是，如果使用了 `proxy_method` 指令，它会覆盖原始的请求方法。例如，`proxy_method GET` 会将所有 POST 请求转换为 GET 请求发送给后端。在精准代理场景中，除非有明确的转换需求，否则不应设置此指令，以保持请求语义的一致性。
# 验证不同方法的透传
# 客户端发送 POST /app/data
# Nginx 配置:
location ~ ^/app(.*)$ {
proxy_pass http://127.0.0.1:8080$1;
# 未设置 proxy_method，默认透传 POST
}
# 后端收到:
# Method: POST
# URI: /data
# 如果配置了 proxy_method GET:
location ~ ^/app(.*)$ {
proxy_pass http://127.0.0.1:8080$1;
proxy_method GET;
}
# 后端收到:
# Method: GET
# URI: /data
通过上述代码可以看出，默认情况下 Nginx 会保持请求方法不变。如果需要强制转换方法，可以使用 `proxy_method`。但在精准代理中，通常希望保持原样，以便后端能根据方法执行正确的逻辑（如 POST 创建资源，GET 查询资源）。此外，正则匹配的性能也是一个考量因素。相比前缀匹配（`location /api/`），正则匹配（`location ~ ^/api/`）需要更多的计算资源。因此，只有在必须使用正则表达式进行复杂模式匹配时，才推荐使用正则 location。对于简单的路径前缀代理，优先使用前缀匹配，以获得更好的性能和可维护性。
当正则捕获组为空时会发生什么
当正则表达式中的捕获组未能匹配到任何内容时，对应的变量（如 `$1`, `$2`）将为空字符串。在 `proxy_pass` 中使用这些变量时，空字符串会被直接拼接。例如，如果配置为 `proxy_pass http://backend$1;`，且请求 URI 为 `/app`（假设正则设计为匹配 `/app/...`），而实际请求没有后续路径，`$1` 为空，最终请求可能变为 `http://backend` 或 `http://backend/`，具体取决于 Nginx 的内部处理逻辑和 URI 规范化。这可能导致后端返回 404 或重定向错误。为了避免这种情况，可以在 `location` 块中添加 `try_files` 或使用 `error_page` 来处理异常状态码。另一种做法是调整正则表达式，确保它只匹配有效的路径结构，从而避免捕获组为空的情况。例如，使用 `^/app/([^/]+)$` 而不是 `^/app(.*)$`，可以强制要求 `/app` 后必须有内容。这样，如果请求 `/app`，它将不会匹配该 location，从而落入默认的 location 或其他 fallback 规则中，避免了因空变量导致的意外代理行为。
