前言
Nginx（發音同“engine X”）是異步框架的網頁服務器，也可以用作反向代理、負載平衡器和HTTP緩存。
本文將講述如何使用 Nginx 在 Web 前后端分離開發中實現路由的轉發。
Web 開發通常使用的是前后端分離的開發模式，即前端和后端分別進行開發，前端通過 Ajax 請求后端的接口，將獲取數據將數據渲染到頁面上。前端開發會使用腳手架搭建前端開發環境，其底層通常會啟動一個本地服務器，通常使用的是 nodejs 的 Express 框架。而后端則是提供接口，一般是放在線上的一個開發用的域名下。
這在開發過程中會導致 跨域 問題，即在一個域名下的網頁，是無法通過 Ajax 請求另一個（不同源）域名下的接口 API 的。這是瀏覽器的同源策略，是瀏覽器的一個非常重要的安全策略。
解決這個問題的其中一個方案是使用 代理。具體來說，就是在本地啟動一個服務器（如 localhost:4000），發送給該服務器的請求會根據請求路由（比如判斷 url 是否有前綴 /api）進行轉發，分別轉發到前端開發的服務器（如 localhost:3000），以及后端服務器（比如 dev.yoursite.com）。這樣通過一個代理服務器，因為請求的 api 都是同一個域名下的，自然就不會造成跨域問題，從而導致請求失敗。
下面我們就來講解如何使用 Nginx 來實現反向代理。
簡單認識 Nginx 配置文件
安裝好 Nginx 后，我們需要確定下 Nginx 的默認配置文件的位置。執行命令 nginx -t，該命令會檢測 nginx 的默認配置文件語法是否正確，并進行測試，最后輸出結果。我們可以從輸出中得到默認配置文件所在的位置。
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
還有另外一種方法可以得到默認配置文件的位置，那就是執行 nginx -h。該命令會輸出 nginx 的簡易幫助文檔，其中的 -c filename 的配置項說明也指出了默認配置項的路徑。
-c filename : set configuration file (default: /etc/nginx/nginx.conf)
通過這個文檔，我們也可以知道，使用 -c 配置項可以自定義配置文件。如果不指定文件，使用默認配置文件。
下面我們來修改一下 Nginx 到這個默認配置文件 nginx.config 來首先代理功能。
nginx.config 文件的 http 后面的代碼塊中，應該會有類似下面這行的代碼：
include /etc/nginx/conf.d/*.conf;
這行代碼的作用是將 /etc/nginx/conf.d 目錄下的后綴為 .conf 的文件內容嵌入到引入位置中，作為配置的一部分執行。
如果你是在 macOS 安裝的 Nginx，可能會有點不同。我使用 brew 安裝的 Nginx 為為 include servers/*;，對應嵌入的是 servers 目錄下的所有文件。
為什么會用到這種嵌入的語法呢？因為這樣我們就可以將不同項目需要用到的配置放到不同的配置文件里，好處就是可以快速地找到對應項目要修改的配置文件，不用擔心不小心修改了其他項目的配置。另外如果直接在 nginx.conf 上修改，使其變得臃腫。這符合設計模式的 單一職責原則。
此外，你可以會奇怪conf.d 目錄的命名為什么要加上 .d ？如果你使用 Linux 過一段時間，你會發現某些目錄或文件的末尾會加上一個 d，比如 httpd、crond、vsftpd 等。其實這是為了說明這些文件都屬于是 daemon（服務）。這里的服務指的是系統的服務，主要分為系統本身需要的服務，以及負責網絡的服務。我們的 conf.d 就是屬于后者。
編寫 Nginx 配置文件
我們在 conf.d 目錄下創建名為 demo.conf 的文件，寫入以下內容，然后啟動 Nginx。
server {
listen 5000;
server_name localhost;
location / {
proxy_pass http://localhost:3000;
}
location /api/ {
proxy_pass http://localhost:4000;
}
}
該配置啟用了 localhost:5000 的服務器，將 localhost:5000 下開頭為 /api/ url 請求代理到了 localhost:4000（后端接口服務器）。其他請求則是代理到 localhost:3000（前端）。下面我們具體解析一下配置文件里面內容的作用。
listen 設置了服務器的端口號，server_name 則設置了主機名。
location
location 表示進行路由的匹配，如果匹配則執行對應代碼塊里的操作。location 可以使用 前綴匹配 以及 正則匹配（需要以 ~* 或 ~ 開頭）。我們這里的配置使用的是前綴匹配。
這里有個點需要注意一下，Nginx 的路由匹配和一般的按順序匹配第一個的路由匹配方案（比如后端的 gin、前端的 vue-router 的路由匹配方案）不同，nginx 匹配路由的方式為：
- 首先進行前綴匹配，遍歷所有的前綴匹配，從中選擇前綴匹配最長的；
- 然后會進行正則匹配，在所有正則匹配中，從前往后選擇第一個符合的；
- 如果能找到匹配的正則匹配，使用其對應的配置；如果沒有，則使用之前找到的那個最長的前綴匹配對應的配置。
所以，當請求為 localhost:5000/api/xx 時， / 和 /api/ 都能夠前綴匹配。根據規則，雖然位置更靠前的 / 也符合前綴匹配，但 /api 更長，所以最終匹配的是 /api。
proxy_pass
確定好匹配的 location 后，我們再看看 proxy_pass 又做了什么操作。proxy_pass 用于將請求路由映射到指定的協議和地址。本質是將發送給 Nginx 的請求處理并發送到另一個服務器，然后將返回的數據作為 Nginx的返回數據返回。
proxy_pass 后如果使用的是 URI（端口后面至少有一個 /），那么 Nginx 就會 替換 掉 location 匹配的那部分字符。
listen 5000;
server_name localhost;
location /name/ {
proxy_pass http://127.0.0.1/remote/;
}
# localhost:5000/name/fstar
# 會被映射請求為
# 127.0.0.1/remote/fstar
可以看到，/name/ 的部分在映射時被移除（或者說是替換）了。
proxy_pass 后如果使用的是不是 URI（端口后沒有任何東西），Nginx 會將源請求完全映射到代理服務上：
listen 5000;
server_name localhost;
location /some/path/ {
proxy_pass http://127.0.0.1;
}
# localhost:5000/some/path/x/y
# 會被映射請求為
# 127.0.0.1/some/path/x/y
這里的 /some/path 并沒有被移除。
我們的 demo.conf 文件的 proxy_pass 使用的不是 URI，所以是將路由完全映射到另一個服務。
思考題
請問，下面有兩段配置（區別是 proxy_pass 結尾是否有 /）？如果請求 /kite/api/xx，分別會映射為什么？
location /kite/api/ {
proxy_pass http://localhost:5000;
}
location /kite/api/ {
proxy_pass http://localhost:5000/;
}
前面我們講 proxy_pass 的時候說過，proxy_pass 后面如果不是 URI，會正常轉發；如果是 URI，就移除 location 匹配的前綴再進行轉發，體現的是替換路由的效果。上面這兩個配置的區別就在于末尾的這個 /，有 / 是 URI，沒有的不是 URI，從而導致完全不一樣的結果，依次分別為：
http://localhost:5000/kite/api/xx
http://localhost:5000/xx
所以，在寫 Nginx 配置的時候，一定要注意端口后面的 / 是否有必要保留。因為它的有無會導致兩種截然不同的效果。
參考文章
- Nginx 官方文檔
- stackoverflow - How do I rewrite URLs in a proxy response in NGINX
總結
到此這篇關于利用Nginx代理如何解決前端跨域問題的文章就介紹到這了,更多相關Nginx代理解決前端跨域內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！
