先說(shuō)說(shuō)跨域這事情吧。早在13年，我剛接觸前端開(kāi)發(fā)的時(shí)候就遇到了跨域，那時(shí)候剛開(kāi)始流行前后端分離。解決跨域就是直接用get jsonp。還是小白的我，也沒(méi)有去想跨域的其它解決方式和為什么要采用這種解決方式。
創(chuàng)新互聯(lián)是一家專(zhuān)業(yè)提供三亞企業(yè)網(wǎng)站建設(shè),專(zhuān)注與網(wǎng)站制作、成都網(wǎng)站建設(shè)、HTML5、小程序制作等業(yè)務(wù)。10年已為三亞眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專(zhuān)業(yè)網(wǎng)站設(shè)計(jì)公司優(yōu)惠進(jìn)行中。
最近，做一個(gè)二次開(kāi)發(fā)的項(xiàng)目，也碰到了用網(wǎng)頁(yè)請(qǐng)求http post，瀏覽器跨域，不能獲取返回?cái)?shù)據(jù)的問(wèn)題，所以再次來(lái)梳理下這個(gè)跨域，為什么最后選擇了nginx代理。
首先，什么是跨域呢？首先需要了解的是同源和跨源的概念。對(duì)于相同源，其定義為：如果協(xié)議、端口（如果指定了一個(gè)）和主機(jī)對(duì)于兩個(gè)頁(yè)面是相同的，則兩個(gè)頁(yè)面具有相同的源。 只要三者之一任意一點(diǎn)有不同，那么就為不同源。 同源策略限制從一個(gè)源加載的文檔或腳本如何與來(lái)自另一個(gè)源的資源進(jìn)行交互。這是一個(gè)用于隔離潛在惡意文件的關(guān)鍵的安全機(jī)制。當(dāng)一個(gè)資源從與該資源本身所在的服務(wù)器的域或端口不同的域或不同的端口請(qǐng)求一個(gè)資源時(shí)，資源會(huì)發(fā)起一個(gè)跨域 HTTP 請(qǐng)求?？缬虿灰欢ㄊ菫g覽器限制了發(fā)起跨站請(qǐng)求，而也可能是跨站請(qǐng)求可以正常發(fā)起，但是返回結(jié)果被瀏覽器攔截了。 簡(jiǎn)單的來(lái)說(shuō)，出于安全方面的考慮，頁(yè)面中的JavaScript無(wú)法訪問(wèn)其他服務(wù)器上的數(shù)據(jù)，即“同源策略”。而跨域就是通過(guò)某些手段來(lái)繞過(guò)同源策略限制，實(shí)現(xiàn)不同服務(wù)器之間通信的效果。
跨域的解決方案也有很多種。
類(lèi)型一：有些瀏覽器可以設(shè)置 ，降低它的安全性。但是對(duì)于一個(gè)網(wǎng)站，要求設(shè)置瀏覽器是不切合實(shí)際的。
類(lèi)型二：直接用form方式 ，這種情況下不是ajax請(qǐng)求，而是直接訪問(wèn)目標(biāo)地址了，不存在跨域問(wèn)題，但是這個(gè)頁(yè)面已經(jīng)跳轉(zhuǎn)了。而我們想實(shí)現(xiàn)的只是取另外一個(gè)地址的數(shù)據(jù)到本地顯示而已。
類(lèi)型三：服務(wù)端語(yǔ)言是能夠處理的情況下。
1、CORS 是一個(gè)W3C標(biāo)準(zhǔn)，全稱(chēng)是”跨域資源共享”（Cross-origin resource sharing）。它允許瀏覽器向跨源服務(wù)器，發(fā)出XMLHttpRequest請(qǐng)求，從而克服了AJAX只能同源使用的限制。跨域資源共享（ CORS ）機(jī)制允許 Web 應(yīng)用服務(wù)器進(jìn)行跨域訪問(wèn)控制，從而使跨域數(shù)據(jù)傳輸?shù)靡园踩M(jìn)行。其需要服務(wù)端和客戶(hù)端同時(shí)支持。
對(duì)于簡(jiǎn)單請(qǐng)求，瀏覽器直接發(fā)出CORS請(qǐng)求。具體來(lái)說(shuō)，就是在頭信息之中，增加一個(gè)Origin字段。如果Origin指定的源，不在許可范圍內(nèi)，服務(wù)器會(huì)返回一個(gè)正常的HTTP回應(yīng)。瀏覽器發(fā)現(xiàn)，這個(gè)回應(yīng)的頭信息沒(méi)有包含Access-Control-Allow-Origin字段（詳見(jiàn)下文），就知道出錯(cuò)了，從而拋出一個(gè)錯(cuò)誤，被XMLHttpRequest的onerror回調(diào)函數(shù)捕獲。注意，這種錯(cuò)誤無(wú)法通過(guò)狀態(tài)碼識(shí)別，因?yàn)镠TTP回應(yīng)的狀態(tài)碼有可能是200。如果Origin指定的域名在許可范圍內(nèi)，服務(wù)器返回的響應(yīng)，會(huì)多出幾個(gè)頭信息字段。 Access-Control-Allow-Origin 該字段是必須的。它的值要么是請(qǐng)求時(shí)Origin字段的值，要么是一個(gè)*，表示接受任意域名的請(qǐng)求。 Access-Control-Allow-Credentials 該字段可選。 Access-Control-Expose-Headers 該字段可選。
可以說(shuō)這種辦法主要在header上下功夫，設(shè)置Access-Control-Allow-Origin為所有*允許訪問(wèn)。雖然說(shuō)它支持所有的請(qǐng)求方式，post，delete，put等等，但是它不能兼容ie6，7等等。
例如下圖的nodejs? express 例子：
2、服務(wù)端的http ajax請(qǐng)求全部改為 get jsonp方式 。該方式能夠兼容老式瀏覽器。
3、iframe window.name 這種傳值得方式很巧妙，兼容性也很好。但是在要訪問(wèn)數(shù)據(jù)的地址那個(gè)服務(wù)器要有一個(gè)空的中間頁(yè)面拿來(lái)用。
4、postMessage ， html5 window.postMessage。 同iframe window.name有點(diǎn)像，也是需要服務(wù)端有個(gè)空的html拿來(lái)接收數(shù)據(jù)。而且現(xiàn)在的postMessage兼容性也不好。
5、document.domain 修改為頂級(jí)域名。
6、 WebSocket ，協(xié)議不實(shí)行同源政策，只要服務(wù)器支持，就可以通過(guò)它進(jìn)行跨源通信。
類(lèi)型四：不是簡(jiǎn)單的前后端。假如有個(gè)第三方的api，自己有一個(gè)網(wǎng)站前端，一個(gè)網(wǎng)站后端。
1、自己的網(wǎng)站端和后端源碼放在同一個(gè)服務(wù)端口和目錄下，不存在跨域。當(dāng)直接用網(wǎng)站前端的http訪問(wèn)第三方api，瀏覽器跨域。此時(shí)，改為由網(wǎng)站后端的服務(wù)端語(yǔ)言訪問(wèn)，做個(gè)中間人，將訪問(wèn)的數(shù)據(jù)給網(wǎng)頁(yè)前端。
2、網(wǎng)站前端和后端不是同源的，采用以上的跨域方案，譬如CORS。同樣的網(wǎng)站后端做中間人，訪問(wèn)第三方api，再轉(zhuǎn)給網(wǎng)頁(yè)前端。
3、使用nginx 反向代理解決跨域問(wèn)題。 網(wǎng)站前端訪問(wèn)nginx服務(wù)的地址，nginx設(shè)置代理地址為訪問(wèn)第三方api地址，當(dāng)訪問(wèn)代理地址的時(shí)候，瀏覽器訪問(wèn)的是nginx服務(wù)的地址，實(shí)際是訪問(wèn)第三方api地址。
注意：此時(shí)，如果目錄下有個(gè)proxy.html,因?yàn)樵O(shè)置代理地址是/proxy，碰到這個(gè)地址就被轉(zhuǎn)到”“，所以要訪問(wèn)proxy.html是訪問(wèn)不到的。
4、使用nginx代理地址是解決生產(chǎn)環(huán)境發(fā)布的問(wèn)題了，那么我在開(kāi)發(fā)的時(shí)候使用angular這樣需要打包的框架怎么辦呢。當(dāng)然在開(kāi)發(fā)環(huán)境下，angular也是由類(lèi)似代理地址的解決方案的。
（1）創(chuàng)建配置代理文件：假設(shè)后端服務(wù)的訪問(wèn)地址為，我們可以創(chuàng)建一個(gè)proxy.conf.json文件，放在package.json同目錄下。
（2）改寫(xiě)package.json文件 ，采用--proxy-config命令（angular自帶的命令）。
(3)ajax訪問(wèn)代理地址
此時(shí)， 執(zhí)行 npm start ，即可發(fā)現(xiàn)，瀏覽器訪問(wèn) 的同源地址，實(shí)際上是訪問(wèn).
angular在開(kāi)發(fā)環(huán)境下代理地址的方法類(lèi)似在生產(chǎn)環(huán)境下使用的nginx代理。但是測(cè)試angular是有一個(gè)/api代理地址的巧合。剛好第三方api上面的地址有個(gè)api，才能使用這個(gè)地址，并且能夠簡(jiǎn)寫(xiě)一個(gè)api，才能成功訪問(wèn)，如果更改為其它的，譬如proxy，就測(cè)試失敗。而且proxy.conf.json文件下的設(shè)置也只能是域名和端口。所以，本人測(cè)試，這或許是個(gè)巧合或者是缺陷。
五、其它
當(dāng)然，跨域這個(gè)算是歷史性的問(wèn)題，以后也會(huì)存在這個(gè)問(wèn)題。除了上面各種方法，以及根據(jù)各種方法使用的場(chǎng)合，還有許多其它的方法。例如各大流行框架react，vie應(yīng)該也有像angular一樣，能夠處理跨域的開(kāi)發(fā)環(huán)境方案，接下來(lái)，還是要繼續(xù)學(xué)習(xí)和積累。
原文鏈接：
接 上篇文章 中提到的 Nginx 解析域名地址的問(wèn)題，用一句話描述就是“proxy_pass 中如果配置的是域名地址，Nginx 只有在 start / restart / reload 時(shí)，才會(huì)連接一次域名服務(wù)器解析域名，緩存解析的結(jié)果，后續(xù)則 不會(huì)根據(jù)解析結(jié)果的 TTL 進(jìn)行自動(dòng)更新 ”，如果遇到了域名地址配置有多個(gè) IP ，且還在動(dòng)態(tài)變化，那就會(huì)出現(xiàn) Nginx 把請(qǐng)求轉(zhuǎn)發(fā)到一個(gè)過(guò)期的 IP 地址的情況，連接超時(shí)的報(bào)錯(cuò)日志類(lèi)似這樣：
這個(gè)說(shuō)法在 官方的一篇 2016 年的博客 中有提到：
除此之外，除了一些分析源碼的網(wǎng)絡(luò)文章，暫時(shí)還沒(méi)有找到其他的官方文檔中說(shuō)到這個(gè)細(xì)節(jié)
在 upstream 中可以對(duì)上游的服務(wù)器進(jìn)行更詳細(xì)的設(shè)置，解決 DNS 緩存的問(wèn)題可以在 upstream 中指定需要的負(fù)載均衡算法，比如 least_conn ，并指定 max_fails ，以實(shí)現(xiàn)調(diào)用失敗 N 次之后判定該服務(wù)異常，暫停轉(zhuǎn)發(fā)該服務(wù)
注：
這個(gè)配置的示例是官方博客中的，看到這個(gè)配置時(shí)覺(jué)得有點(diǎn)奇怪，自己進(jìn)行了模擬測(cè)試，測(cè)試的方案是在 hosts 文件中配置一個(gè)模擬的域名與三個(gè) IP 地址，其中兩個(gè) IP 是正確的，另一個(gè)是內(nèi)網(wǎng)不存在的 IP，測(cè)試的結(jié)果就是 Nginx 始終會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到那個(gè)錯(cuò)誤的 IP 去，日志中一直能看到超時(shí)的報(bào)錯(cuò)，配置的 max_fails 仿佛沒(méi)有任何作用（有補(bǔ)充配置了 fail_timeout ，也嘗試配置了 proxy_next_upstream 、 proxy_next_upstream_timeout 和 proxy_next_upstream_tries ）
不清楚用 hosts 配置的方式是不是必然會(huì)出現(xiàn)這樣的情況，因?yàn)槟壳皼](méi)條件測(cè)試真正想要的場(chǎng)景，所以不敢說(shuō)博客中的這種配置是錯(cuò)的【如果以后碰巧有條件能測(cè)試驗(yàn)證，再回頭來(lái)更新
最初學(xué)習(xí) Nginx 的時(shí)候測(cè)試過(guò) max_fails 這個(gè)配置，當(dāng)時(shí)在 upstream 里配置的都是一些 IP 地址的上游服務(wù)。再次按 IP 地址進(jìn)行測(cè)試，在 upstream 中配置兩個(gè)正確的 IP 地址 和一個(gè)錯(cuò)誤的 IP 地址，發(fā)現(xiàn)這樣的配置就是能生效的，失敗一定次數(shù)之后（實(shí)際失敗的次數(shù)比設(shè)置的 max_fails 多，不清楚什么原因），Nginx 在 fail_timeout 時(shí)間內(nèi)就不再轉(zhuǎn)發(fā)請(qǐng)求到那個(gè)錯(cuò)誤的 IP
resolver 的配置詳情可看 官方文檔 ，示例的配置是指定 DNS 服務(wù)器 10.0.0.2，指定 DNS 解析的有效時(shí)間為 10 秒，按博客 《Nginx動(dòng)態(tài)解析upstream域名》 中博主的測(cè)試，不是說(shuō) Nginx 每過(guò) 10 秒會(huì)自己重新調(diào)一次 DNS 解析，而是有請(qǐng)求轉(zhuǎn)發(fā)時(shí)才檢驗(yàn)一次有效期是否過(guò)期
不配置 valid 選項(xiàng)時(shí)，V1.1.9 之后的 Nginx 默認(rèn)會(huì)使用 DNS 解析結(jié)果中的 TTL
在 proxy_pass 中使用變量，帶來(lái)的作用就是在 TTL 過(guò)期時(shí)能再次調(diào)用 DNS 解析，從而解決一直使用緩存結(jié)果的問(wèn)題
這大概是目前官方原版唯一解決 DNS 緩存的解決方案了，帶來(lái)的弊端也如 《Nginx動(dòng)態(tài)解析upstream域名》 的博主所說(shuō)，不能使用 upstream 模塊特有的相關(guān)配置
Nginx Plus 版有更好的配置解決這些問(wèn)題，另外使用 Lua 插件或許也能更完美的解決這個(gè)問(wèn)題，暫時(shí)就沒(méi)什么研究了
如何給自己開(kāi)發(fā)的服務(wù)配置域名，讓外網(wǎng)用戶(hù)可以訪問(wèn)？
解決這個(gè)問(wèn)題需要有域名（要解析），服務(wù)器和自己的服務(wù)
================================================
以上可以條件都具備之后，修改服務(wù)器上的nginx配置即可。
修改nginx配置如下：
原配置（默認(rèn)配置）：
server {
listen 80;
server_name localhost;
}
修改后配置：
server {
listen 80;
server_name 你的域名點(diǎn)吸煙 ;
}
作用是當(dāng)用戶(hù)訪問(wèn)域名"http://你的域名點(diǎn)吸煙 "時(shí)調(diào)轉(zhuǎn)到127.0.0.1:8989上
同時(shí)也可以指定具體的路徑如下：
server {
listen 80;
server_name 你的域名點(diǎn)吸煙 ;
}
作用是當(dāng)用戶(hù)訪問(wèn)路徑"http://你的域名點(diǎn)吸煙 /start"時(shí)調(diào)轉(zhuǎn)到127.0.0.1:8989/home/start上
重慶分公司
重慶分公司
