使用Nginx配置解決NetCore的跨域
廢話不多說,直接上Nginx配置
server
{
listen 80;
server_name 你的Id或域名;
location /
{
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods 'GET,POST,PUT,DELETE,PATCH,OPTIONS';
add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';
# 預檢請求直接返回204
if ($request_method = 'OPTIONS') {
return 204;
}
proxy_pass http://需要轉發的Ip:800;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
引數說明:
-
Access-Control-Allow-Origin
- 伺服器預設是不被允許跨域的。給Nginx伺服器配置
Access-Control-Allow-Origin *
後,表示伺服器可以接受所有的請求源(Origin)
,即接受所有跨域的請求
- 伺服器預設是不被允許跨域的。給Nginx伺服器配置
-
Access-Control-Allow-Headers
- 是為了防止出現以下錯誤:
Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response
- 這個錯誤表示當前請求
Content-Type
的值不被支援。其實是我們發起了"application/json"
的型別請求導致的。這裡涉及到一個概念:預檢請求(preflight request)
,請看下面"預檢請求"的介紹。
- 是為了防止出現以下錯誤:
-
Access-Control-Allow-Methods
- 是為了防止出現以下錯誤:
Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.
- 是為了防止出現以下錯誤:
-
給
OPTIONS
新增204
的返回- 是為了處理在傳送
POST
請求時Nginx
依然拒絕訪問的錯誤,傳送"預檢請求"時,需要用到方法 OPTIONS ,所以伺服器需要允許該方法。
- 是為了處理在傳送
-
proxy_set_header
-
Upgrade
- 把代理時
http
請求頭的Upgrade
設定為原來http
請求的請求頭,wss
協議的請求頭為websocket
- 把代理時
-
Connection keep-alive
- 設定nginx支援轉發長連結
-
Host
- 將原
http
請求Header
中的Host
欄位也放到轉發的請求中 -
如果不加這個,Nginx轉發的請求Header裡就不會有Host欄位
- 將原
-
X-Real-IP
- 通常被 HTTP 代理用來表示與它產生 TCP 連線的裝置 IP,這個裝置可能是其他代理,也可能是真正的請求端。需要注意的是,
X-Real-IP
目前並不屬於任何標準,代理和 Web 應用之間可以約定用任何自定義頭來傳遞這個資訊
- 通常被 HTTP 代理用來表示與它產生 TCP 連線的裝置 IP,這個裝置可能是其他代理,也可能是真正的請求端。需要注意的是,
-
X-Forwarded-For
- X-Forwarded-For 請求頭格式:
X-Forwarded-For: client, proxy1, proxy2
,可以看到,XFF 的內容由「英文逗號 + 空格」隔開的多個部分組成,最開始的是離服務端最遠的裝置 IP,然後是每一級代理裝置的 IP。如果一個 HTTP 請求到達伺服器之前,經過了三個代理Proxy1、Proxy2、Proxy3
,IP 分別為IP1、IP2、IP3
,使用者真實 IP 為IP0
,那麼按照 XFF 標準,服務端最終會收到以下資訊:-Forwarded-For: IP0, IP1, IP2
。Proxy3
直連伺服器,它會給 XFF 追加 IP2,表示它是在幫 Proxy2 轉發請求。列表中並沒有 IP3,IP3 可以在服務端通過Remote Address
欄位獲得
- X-Forwarded-For 請求頭格式:
-
-
預檢請求
(preflight request)
跨域資源共享(CORS)標準新增了一組 HTTP 首部欄位,允許伺服器宣告哪些源站有許可權訪問哪些資源。另外,規範要求,對那些可能對伺服器資料產生副作用的HTTP 請求方法(特別是 GET 以外的 HTTP 請求,或者搭配某些 MIME 型別的 POST 請求),瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求(preflight request),從而獲知服務端是否允許該跨域請求。伺服器確認允許之後,才發起實際的 HTTP 請求。在預檢請求的返回中,伺服器端也可以通知客戶端,是否需要攜帶身份憑證(包括 Cookies 和 HTTP 認證相關資料)。 其實Content-Type欄位的型別為application/json的請求就是上面所說的搭配某些 MIME 型別的 POST 請求,CORS規定,Content-Type不屬於以下MIME型別的,都屬於預檢請求 所以 application/json的請求 會在正式通訊之前,增加一次"預檢"請求,這次"預檢"請求會帶上頭部資訊 Access-Control-Request-Headers: Content-Type:
OPTIONS /api/test HTTP/1.1 Origin: http://foo.example Access-Control-Request-Method: POST Access-Control-Request-Headers: Content-Type ...
伺服器回應時,返回的頭部資訊如果不包含
Access-Control-Allow-Headers: Content-Type
則表示不接受非預設的的Content-Type
。即出現以下錯誤:
Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.
注意:Nginx配置了跨域以後,需要去掉NetCore中的跨域程式碼,否則請求將出錯!