Nginx Location映射规则总结归纳与最佳实践
Nginx的location指令是配置请求路由的核心机制,其匹配规则直接影响请求的处理流程。下面基于官方文档和实战经验的总结:
一、Location匹配规则与优先级
1. 匹配模式
Nginx支持5种location修饰符,优先级从高到低为:
| 修饰符 | 说明 | 示例 |
|---|---|---|
= | 精确匹配(最高优先级) | location = /logo.png |
^~ | 最长前缀匹配(匹配后停止正则检查) | location ^~ /static/ |
~ | 正则匹配(区分大小写,按配置文件顺序匹配) | location ~ \.php$ |
~* | 正则匹配(不区分大小写) | `location ~* .(jpg |
| 无 | 普通前缀匹配(按最长匹配原则,优先级最低) | location /blog/ |
2. 优先级顺序
Nginx按以下顺序匹配location块:
精确匹配(=)
仅当请求URI与location后的字符串完全匹配时生效。正则匹配(~/~*)
按配置文件中的书写顺序依次匹配,首个匹配的正则生效。最长前缀匹配(^~)
选择匹配URI前缀最长的location块。普通前缀匹配
按最长匹配原则选择,若多个location匹配,选择最先定义的。默认匹配(location /)
兜底处理未匹配其他规则的请求。
3. 匹配示例
假设配置如下:
location = /exact { ... } # 精确匹配
location ^~ /prefix { ... } # 最长前缀匹配
location ~ \.png$ { ... } # 正则匹配(区分大小写)
location /general { ... } # 普通前缀匹配
location / { ... } # 默认匹配- 请求
/exact→ 匹配location = /exact。 - 请求
/prefix/long→ 匹配location ^~ /prefix(^~优先级高于普通前缀)。 - 请求
/image.PNG→ 匹配location ~* \.(jpg|png)$(不区分大小写的正则)。 - 请求
/general/path→ 匹配location /general。
二、Proxy_pass路径处理规则
proxy_pass指令用于将请求转发到后端服务,其路径拼接逻辑与location配置紧密相关。
1. 路径拼接规则
| 场景 | 示例配置 | 请求URI | 转发目标 |
|---|---|---|---|
proxy_pass带/结尾 | location /api/ { proxy_pass http://backend/; } | /api/user | http://backend/user |
proxy_pass不带/ | location /api { proxy_pass http://backend; } | /api/user | http://backend/api/user |
正则location | location ~ ^/app/(.*) { proxy_pass http://app/$1; } | /app/v1/data | http://app/v1/data |
关键规则:
- 带
/:proxy_pass的URL以/结尾时,替换location匹配的部分。 - 不带
/:proxy_pass的URL不带/时,追加location匹配后的完整路径。
2. 路径截取与重写
通过rewrite指令可动态修改转发路径:
location ~* ^/api/v1/ {
rewrite ^/api/v1/(.*) /$1 break; # 截取/api/v1/后的路径
proxy_pass http://backend;
}请求/api/v1/user/123 → 转发到http://backend/user/123。
3. 特殊场景处理
Unix Socket转发:
location /unix/ {
proxy_pass http://unix:/var/run/backend.sock:/;
}避免301重定向:
location /app {
proxy_pass http://backend;
}
# 请求/app(无结尾/)时,Nginx可能自动重定向到/app/
# 使用精确匹配避免:
location = /app {
proxy_pass http://backend;
}三、配置优化与最佳实践
精确匹配优先
将location =块置于配置文件顶部,减少正则匹配开销。
正则匹配顺序
将高频请求的正则规则前置,提升匹配效率。
路径设计一致性
确保location和proxy_pass的URL格式(是否带/)一致,避免路径拼接错误。
监控
使用error_log和access_log跟踪匹配过程,优化配置。
四、完整配置示例
server {
listen 80;
server_name example.com;
# 精确匹配静态文件
location = /favicon.ico {
log_not_found off;
access_log off;
root /var/www/icons;
}
# 最长前缀匹配API请求
location ^~ /api/ {
proxy_pass http://api_server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# 正则匹配图片资源(不区分大小写)
location ~* \.(jpg|png|gif)$ {
expires 30d;
root /var/www/images;
}
# 默认匹配
location / {
root /var/www/html;
index index.html;
}
}配置说明:
- 精确匹配
favicon.ico,关闭日志提升性能。 ^~ /api/匹配所有以/api/开头的请求,转发到后端服务。- 正则匹配图片文件,设置30天缓存。
- 未匹配的请求由
location /处理,返回静态文件。
到此这篇关于Nginx Location映射规则总结归纳的文章就介绍到这了,更多相关Nginx Location映射规则内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
相关文章
Nginx基础配置(main、events、http、server、location)
本文主要介绍了Nginx基础配置(main、events、http、server、location),文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧2023-06-06
nginx反向代理https内部定向到http报302的问题及解决
这篇文章主要介绍了nginx反向代理https内部定向到http报302的问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教2023-12-12
Nginx 获取客户端真实IP $remote_addr与X-Forwarded-For的实现
我们大多数情况下访问服务时,客户端并不是直接访问到服务器的,本文主要介绍了Nginx 获取客户端真实IP $remote_addr与X-Forwarded-For的实现,具有一定的参考价值,感兴趣的可以了解一下2024-03-03


最新评论