Nginx的location配置，你是“迷路小菜鳥”還是“火箭工程師”？

你有沒有遇到過這些“坑”：

• /api的請求被分配到/static目錄？
• /favicon.ico的請求總被忽略？
• 正則匹配和前綴匹配打架？

這就是 Nginx的location匹配規(guī)則 的“魔法”！它讓你的請求處理像“高速公路”一樣高效，像“瑞士軍刀”一樣靈活。

本文將帶你從 “迷路小菜鳥” 到 “火箭工程師”，手把手教你寫出“神級配置”！

第一戰(zhàn)：基礎(chǔ)操作——“快遞分揀站”的規(guī)則

1.1 精確匹配（=）：快遞員的“人臉識別”

問題：只有完全相同的路徑才能觸發(fā)配置？

解決方案：用 = 實(shí)現(xiàn)精確匹配！

# 精確匹配 /favicon.ico
location = /favicon.ico {
    root /var/www/static;  # 指定靜態(tài)文件路徑
    expires 30d;           # 瀏覽器緩存30天
}

# 請求示例：
# ? 匹配：http://example.com/favicon.ico
# ? 不匹配：http://example.com/favicon.ico?version=1

注釋：

• = /path：必須完全匹配，連查詢參數(shù)（?后的內(nèi)容）都不行！
• root vs alias：
  • root：路徑拼接（如 /favicon.ico → /var/www/static/favicon.ico）。
  • alias：路徑替換（如 /static/images/logo.png → /var/www/images/logo.png）。

1.2 前綴匹配（無修飾符）：快遞員的“地址模糊搜索”

問題：想匹配所有以 /api 開頭的請求？

解決方案：用 普通前綴匹配！

# 匹配所有以 /api 開頭的路徑
location /api {
    proxy_pass http://backend_api;  # 反向代理到后端API
}

# 請求示例：
# ? 匹配：/api/user、/api/v1/login
# ? 不匹配：/apicheck（因?yàn)殚_頭不是/api）

注釋：

• 最長前綴優(yōu)先：如果有兩個前綴匹配（如 /api 和 /apic），Nginx會選最長的。
• 結(jié)尾斜杠的玄機(jī)：
  • location /api/：必須以 /api/ 開頭（如 /api/123）。
  • location /api：會匹配 /api 和 /apic！

第二戰(zhàn)：正則匹配——“快遞員的魔法濾鏡”

2.1 區(qū)分大小寫的正則匹配（~）：快遞員的“顯微鏡”

問題：想?yún)^(qū)分 .jpg 和 .JPG？

解決方案：用 ~ 實(shí)現(xiàn)區(qū)分大小寫的正則匹配！

# 匹配以 .jpg 結(jié)尾的圖片（區(qū)分大小寫）
location ~ \.jpg$ {
    root /var/www/images;
    expires 30d;
}

# 請求示例：
# ? 匹配：/photo.jpg
# ? 不匹配：/photo.JPG

注釋：

• 正則語法：\. 表示匹配點(diǎn)號，$ 表示結(jié)尾。
• 正則順序敏感：多個正則匹配時，Nginx按配置順序選擇第一個匹配的！

2.2 不區(qū)分大小寫的正則匹配（~*）：快遞員的“全息掃描”

問題：想同時匹配 .jpg、.JPG、.png？

解決方案：用 ~* 實(shí)現(xiàn)不區(qū)分大小寫的正則匹配！

# 匹配所有圖片格式（不區(qū)分大小寫）
location ~* \.(jpg|png|gif)$ {
    root /var/www/images;
    expires 30d;
}

# 請求示例：
# ? 匹配：/logo.PNG、/banner.gif

注釋：

• 多格式匹配：用 | 分隔多個后綴（如 jpg|png|gif）。
• 性能注意：不區(qū)分大小寫的正則匹配速度稍慢，慎用在高頻路徑上！

第三戰(zhàn)：優(yōu)先級規(guī)則——“快遞員的VIP通道”

3.1 優(yōu)先級順序：從“皇帝”到“平民”

問題：為什么我的正則匹配被前綴匹配覆蓋了？

解決方案：牢記 優(yōu)先級順序！

# 精確匹配（皇帝級）
location = / {
    root /var/www/html;
}

# 最長前綴匹配（王侯級）
location ^~ /static/ {
    root /var/www/static;
}

# 正則匹配（士大夫級）
location ~ \.php$ {
    proxy_pass http://php_backend;
}

# 普通前綴匹配（平民級）
location / {
    root /var/www/html;
}

注釋：

• 優(yōu)先級順序：
  1. = 精確匹配
  2. ^~ 最長前綴匹配（停止后續(xù)匹配）
  3. ~ 或 ~* 正則匹配（按配置順序）
  4. 普通前綴匹配（最長匹配）
• 守則：^~ 比正則更優(yōu)先！

第四戰(zhàn)：實(shí)戰(zhàn)案例——“快遞分揀站”的終極挑戰(zhàn)

4.1 場景：電商系統(tǒng)的動靜分離

需求：

• 靜態(tài)資源（.css、.js）直接返回，緩存30天。
• API請求（/api/*）反向代理到后端服務(wù)。
• 所有其他請求返回 index.html。

解決方案：

# 靜態(tài)資源：不區(qū)分大小寫的正則匹配
location ~* \.(css|js|png|jpg|gif)$ {
    root /var/www/static;
    expires 30d;
}

# API請求：最長前綴匹配（優(yōu)先于正則）
location ^~ /api/ {
    proxy_pass http://backend_api;
}

# 默認(rèn)請求：普通前綴匹配
location / {
    root /var/www/html;
    index index.html;
}

注釋：

• 靜態(tài)資源優(yōu)先：用 ~* 匹配圖片和樣式表，避免被 /api 覆蓋。
• API隔離：用 ^~ 確保 /api 不被正則匹配干擾。

第五戰(zhàn)：避坑指南——“快遞員的防雷手冊”

5.1 坑點(diǎn)1：斜杠的“隱形炸彈”

問題：為什么 /api 和 /api/ 會匹配不同的配置？

解決方案：統(tǒng)一路徑結(jié)尾的斜杠！

# 坑點(diǎn)示例
location /api {
    proxy_pass http://backend_api;  # 匹配 /api 和 /apic
}

location /api/ {
    proxy_pass http://backend_api_v2;  # 僅匹配 /api/
}

# 建議：統(tǒng)一用 ^~ 避免歧義
location ^~ /api {
    proxy_pass http://backend_api;
}

注釋：

• 斜杠的玄學(xué)：/api 會匹配 /api/123，但 /api/ 只匹配 /api/！
• 最佳實(shí)踐：用 ^~ 替代普通前綴匹配，避免斜杠陷阱！

5.2 坑點(diǎn)2：正則匹配的“順序詛咒”

問題：為什么第一個正則匹配的配置總是生效？

解決方案：按優(yōu)先級排序！

# 錯誤示例：正則順序顛倒
location ~ \.jpg$ { ... }  # 會被后面的覆蓋！
location ~ \.png$ { ... }  # 實(shí)際生效

# 正確示例：按重要性排序
location ~ \.png$ { ... }  # 更重要的匹配放前面
location ~ \.jpg$ { ... }

注釋：

• 正則順序敏感：Nginx會按配置順序選擇第一個匹配的正則！
• 調(diào)試技巧：用 curl -I http://example.com/test.png 查看實(shí)際匹配的配置。

第六戰(zhàn)：高級技巧——“快遞員的黑科技”

6.1 使用 map 實(shí)現(xiàn)動態(tài)路由

問題：想根據(jù)路徑動態(tài)選擇后端服務(wù)器？

解決方案：用 map 指令！

# 定義變量 $backend，根據(jù)路徑動態(tài)選擇后端
map $uri $backend {
    default http://default-backend;
    "~^/xianyang/" http://xianyang-backend;
    "~^/api/" http://api-backend;
}

server {
    listen 80;

    location / {
        proxy_pass $backend;  # 動態(tài)選擇后端
    }
}

注釋：

• map 的魔法：根據(jù) $uri 動態(tài)設(shè)置 $backend，適合復(fù)雜路由場景。
• 性能優(yōu)勢：map 是預(yù)處理指令，比 if 更高效！

6.2 使用 try_files 實(shí)現(xiàn)優(yōu)雅降級

問題：想先檢查靜態(tài)文件是否存在，否則返回404？

解決方案：用 try_files！

location / {
    try_files $uri $uri/ /index.html;  # 先找文件，再找目錄，最后返回首頁
}

注釋：

• try_files 的流程：
  1. 檢查 $uri 是否存在（如 /about.html）。
  2. 檢查 $uri/ 是否存在（如 /about/ 目錄）。
  3. 最終返回 /index.html（適合SPA應(yīng)用）。

常見問題：你問我答

Q：為什么我的 /api 路徑匹配了 /apic？
A：

• 因?yàn)槠胀ㄇ熬Y匹配是“最長匹配”，/api 會匹配 /apic！
• 解決方法：用 ^~ /api 替代普通前綴匹配。

Q：如何強(qiáng)制重定向到帶斜杠的路徑？
A：

• 在配置中添加 location /api { return 301 /api/; }。

Q：正則匹配為什么比前綴匹配優(yōu)先級低？
A：

• Nginx的設(shè)計哲學(xué)是“先精確匹配，再正則匹配”，確保最長前綴優(yōu)先。

結(jié)論：成為Nginx的“location大師”

通過本文的七個步驟，你已經(jīng)掌握了：

1. 精確匹配：= 的“人臉識別”能力。
2. 前綴匹配：普通前綴和 ^~ 的“地址模糊搜索”。
3. 正則匹配：~ 和 ~* 的“魔法濾鏡”。
4. 優(yōu)先級規(guī)則：從“皇帝”到“平民”的匹配順序。
5. 實(shí)戰(zhàn)案例：電商系統(tǒng)的動靜分離配置。
6. 避坑指南：斜杠陷阱和正則順序詛咒。
7. 高級技巧：map 和 try_files 的“黑科技”。

最后的小彩蛋：
如果你在開發(fā)一個“多租戶系統(tǒng)”，記得用 map 根據(jù)子域名動態(tài)選擇配置，用 ^~ 隔離公共資源路徑！

以上就是Nginx路徑匹配的配置指南的詳細(xì)內(nèi)容，更多關(guān)于Nginx路徑匹配的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論