做前端開發(fā)的同學，幾乎都踩過跨域的坑； 做后端或運維的同學，大概率也寫過 Nginx 跨域配置。

但很多人配置時都會有個疑問：

“為什么我加了 Access-Control-Allow-Origin，瀏覽器還是報跨域？” “add_header 和 proxy_set_header 到底哪個才是加跨域頭的？”

甚至有人誤以為“跨域頭要轉(zhuǎn)發(fā)給后端”，結果白白走了很多彎路。

今天，我們就從這兩個核心指令的區(qū)別入手，徹底講清楚 Nginx 如何正確處理跨域，并附上一套開箱即用的配置模板。

一、核心問題：跨域頭該用add_header還是proxy_set_header？

這是最容易混淆的點。先說結論：

? 處理瀏覽器跨域，只用 add_header！ ? proxy_set_header 是用來給后端傳請求信息的，和跨域校驗本身無關。

很多人踩坑，就是因為把這兩個指令的作用對象搞反了。我們用一張表徹底分清：

一句話總結：

瀏覽器跨域校驗，只看“最終收到的響應頭”里有沒有 Access-Control-\* 字段。 而 add_header 就是專門負責往響應頭里加這些字段的； proxy_set_header 加的是請求頭，瀏覽器根本看不到，自然對跨域無效。

二、跨域的本質(zhì)：是瀏覽器的安全機制，與后端無關

在講配置前，先明確一個關鍵認知：

?? 跨域是瀏覽器的行為，不是后端的行為。

舉個例子： 前端 http://localhost:8080 請求后端 http://localhost:59200，因端口不同，屬于跨域。

這個過程中：

• 后端其實已經(jīng)正常處理了請求并返回了數(shù)據(jù)；
• 但瀏覽器會攔截這份響應，檢查其中是否包含允許 http://localhost:8080 訪問的聲明；
• 如果有，就把數(shù)據(jù)交給前端；如果沒有，就拋出跨域錯誤。

所以，解決跨域的核心，就是讓瀏覽器收到的響應頭中包含合法的 Access-Control-\* 字段。

而 Nginx 的作用，就是在后端未配置這些字段時，替后端“補上”，讓瀏覽器放行。

三、Nginx 跨域配置實操：模板 + 逐行解析

下面是一套生產(chǎn)可用的 Nginx 跨域配置模板，先看代碼，再逐行拆解：

location / {
    # 1. 跨域核心響應頭（給瀏覽器看的）
    add_header 'Access-Control-Allow-Origin' 'http://localhost:8080' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;

    # 2. 預檢請求直接處理，不轉(zhuǎn)發(fā)給后端
    if ($request_method = 'OPTIONS') {
        return 204;
    }

    # 3. 反向代理配置（給后端傳請求信息）
    proxy_pass http://localhost:59200;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

1. 跨域核心：add_header指令詳解

這部分是解決跨域的關鍵，每行都有明確作用，且必須帶 always：

• Access-Control-Allow-Origin：指定允許訪問的前端域名。
  • 填具體地址（如 'http://localhost:8080'）最安全；
  • 若填 '*'，則不能攜帶憑證（如 Cookie、Authorization），否則瀏覽器會拒絕。
• Access-Control-Allow-Methods：列出前端可能使用的 HTTP 方法（如 GET/POST/PUT 等）。
• Access-Control-Allow-Headers：聲明允許的自定義請求頭（如 Content-Type、Authorization）。
• always 關鍵字： ?? 極其重要！ 它確保即使后端返回 404、500 等非 2xx 響應，跨域頭依然會被添加。 如果省略 always，錯誤響應將沒有跨域頭，瀏覽器照樣攔截——這是最常見的“配了卻無效”的原因！

2. 為什么要單獨處理OPTIONS預檢請求？

對于 POST、PUT 等“非簡單請求”，瀏覽器會先發(fā)一個 OPTIONS 預檢請求，詢問服務器：“你允許我這么請求嗎？”

如果 Nginx 不處理，這個 OPTIONS 會被轉(zhuǎn)發(fā)給后端。而很多后端服務根本沒有實現(xiàn) OPTIONS 接口，直接返回 404 或 500，導致預檢失敗。

因此，我們用：

if ($request_method = 'OPTIONS') {
    return 204;
}

讓 Nginx 直接返回 204（No Content），高效通過預檢，避免打擾后端。

3.proxy_set_header的真實作用

這部分和跨域無關，純粹是為了讓后端拿到正確的請求上下文：

• proxy_pass：將請求轉(zhuǎn)發(fā)到后端服務；
• proxy_set_header Host $host：傳遞原始 Host，避免后端路由出錯；
• X-Real-IP / X-Forwarded-For：傳遞客戶端真實 IP，方便日志記錄或風控。

?? 再強調(diào)一次：這些頭是給后端看的，瀏覽器完全不關心。

4. 完整請求流程圖解

結合上述配置，一次跨域請求的完整流程如下：

1. 瀏覽器發(fā)送 OPTIONS 預檢請求 → 到達 Nginx；
2. Nginx 匹配 location /，觸發(fā) OPTIONS 處理邏輯，直接返回 204 + 跨域頭；
3. 瀏覽器校驗通過，發(fā)送真實請求（如 POST）→ 到達 Nginx；
4. Nginx 通過 proxy_set_header 補充 Host/IP 等信息，轉(zhuǎn)發(fā)給后端；
5. 后端處理并返回業(yè)務響應（可能不含跨域頭）；
6. Nginx 接收響應，通過 add_header 添加跨域頭，再返回給瀏覽器；
7. 瀏覽器驗證響應頭合規(guī)，將數(shù)據(jù)交給前端 JavaScript —— 跨域成功！

四、常見踩坑點 & 避坑指南

? 坑 1：加了跨域頭還是報錯？→ 忘了always

解決方案：所有 add_header 跨域指令必須加上 always。

? 坑 2：用proxy_set_header加跨域頭

錯誤示例：proxy_set_header Access-Control-Allow-Origin *; 后果：跨域頭被加到請求頭里，瀏覽器看不到，完全無效。

? 坑 3：Allow-Origin: *+ 攜帶Authorization

問題：瀏覽器禁止 * 與憑證（credentials）共存。 正確做法：必須指定具體前端域名，如 'http://localhost:8080'。

? 坑 4：跨域頭配在server塊，不在location塊

原因：Nginx 中 add_header 不會繼承上級塊的配置。 正確位置：務必放在實際匹配請求的 location 塊內(nèi)。

五、總結

Nginx 處理跨域的核心邏輯其實很簡單：

• ? 用 add_header 給響應頭添加跨域字段，讓瀏覽器放行；
• ? 用 proxy_set_header 給請求頭補充上下文，讓后端正常工作。

記住：

跨域是瀏覽器的安全策略，后端可以完全不知情。 Nginx 充當“中間人”，既幫后端屏蔽了跨域細節(jié)，又幫前端拿到了數(shù)據(jù)。

把上面的配置模板稍作修改（替換你的前端地址和后端地址），就能解決99% 的跨域場景。

到此這篇關于Nginx 跨域配置中add_header 和 proxy_set_header區(qū)別的文章就介紹到這了,更多相關Nginx  add_header 和 proxy_set_header內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論