雲伺服器nginx反向代理

❶ Nginx的反向代理跨域

什麼是跨域？

跨域是指a頁面想獲取b頁面資源，如果a、b頁面的協議、域名、埠、子域名不同，或是a頁面為ip地址， b頁面為域名地址，所進行的訪問行動都是跨域

瀏覽器為了安全問題一般都限制了跨域訪問，也就是不允許跨域請求資源

同ip（或domain）,同埠，同協議視為同一個域，一個域內的腳本僅僅具有本域內的許可權，可以理解為本域腳本只能讀寫 本域內的資源，而無法訪問其它域的資源。這種安全限制稱為同源策略

現代瀏覽器在安全性和可用性之間選擇了一個平衡點。 在遵循同源策略的基礎上，選擇性地為同源策略「開放了後門」。例如img script style等標簽，都允許垮域引用資源,然而， 你也只能是引用這些資源而已，並不能讀取這些資源的內容

同源策略限制以下幾種行為：

1.Cookie、LocalStorage 和 IndexDB 無法讀取

2.DOM 和 Js對象無法獲得

3.AJAX 請求不能發送

http://www.domain.com/a.jshttp://www.domain.com/b.js 同一域名，不同文件或路徑 允許http://www.domain.com/lab/c.jshttp://www.domain.com:8000/a.jshttp://www.domain.com/b.js 同一域名，不同埠 不允許http://www.domain.com/a.jshttps://www.domain.com/b.js 同一域名，不同協議 不允許http://www.domain.com/a.jshttp://192.168.4.12/b.js 域名和域名對應相同ip 不允許http://www.domain.com/a.jshttp://x.domain.com/b.js 主域相同，子域不同 不允許http://domain.com/c.jshttp://www.domain1.com/a.jshttp://www.domain2.com/b.js 不同域名 不允許

1、 通過jsonp跨域

2、 document.domain + iframe跨域

3、 location.hash + iframe

4、 window.name + iframe跨域

5、 postMessage跨域

6、 跨域資源共享（CORS）

7、 nginx代理跨域

8、 nodejs中間件代理跨域

9、 WebSocket協議跨域

正向代理 ：代理位於網站和客戶端中間， 客戶端無法訪問某網站，就將請求發送給代理伺服器，代理從網站取回來再發送給客戶端，網站並不知道為誰提供服務

反向代理 ：客戶端訪問某網站的一個頁面， 但是網站並沒有，就偷偷從另外一台伺服器上取回來,然後作為自己的內容吐給用戶，用戶不知道真正提供服務的是誰

對於瀏覽器來說，訪問的就是同源伺服器上的一個url。而nginx通過 檢測url前綴，把http請求轉發到後面真實的物理伺服器。並通過rewrite命令把前綴再去掉。這樣真實的伺服器就可以正確 處理請求，並且並不知道這個請求是來自代理伺服器的。

簡單說，nginx伺服器欺騙了瀏覽器，讓它認為這是同源調用，從而解決了瀏覽器的跨域問題。又通過重寫url，欺騙了真實 的伺服器，讓它以為這個http請求是直接來自與用戶瀏覽器的。

Location/carrots-admin-ajax/{

    proxy_passhttp://dev.admin.carrots.ptteng.com/;

}

proxy_pass 把請求代理到其他主機

兩種寫法hhttp://dev.admin.carrots.ptteng.com/    和     http://dev.admin.carrots.ptteng.com

    如果訪問url = http://server/html/test.jsp ，則被nginx代理後

        情況1，將test/作為根路徑，請求test/路徑下的資源。

        情況2，則被nginx代理後，請求路徑會變為http://proxy_pass/test.jsp，直接訪問server的根資源。

是一個匹配規則，用於攔截請求，匹配任何以/proxy/html/開頭的地址，匹配符合以後，停止往下搜索正則。

對於瀏覽器來說，訪問的就是同源伺服器上的一個url。而nginx通過檢測url前綴，把http請求轉發到後面真實的物理伺服器。並通過rewrite命令把前綴再去掉。這樣真實的伺服器就可以正確處理請求，並且並不知道這個請求是來自代理伺服器的。

簡單說，nginx伺服器欺騙了瀏覽器，讓它認為這是同源調用，從而解決了瀏覽器的跨域問題。又通過重寫url，欺騙了真實的伺服器，讓它以為這個http請求是直接來自與用戶瀏覽器的。

1.執行server塊的rewrite指令(這里的塊指的是server關鍵字後{}包圍的區域，其它xx塊類似)

2.執行location匹配

3.執行選定的location中的rewrite指令

如果其中某步URI被重寫，則重新循環執行1-3，直到找到真實存在的文件

如果循環超過10次，則返回500 Internal Server Error錯誤

7.參考文獻

參考一： https://www.cnblogs.com/gabrielchen/p/5066120.html

參考二： http://blog.csdn.net/shendl/article/details/48443299

8.更多討論

提問：

Q ：例如img script style等標簽，都允許垮域引用資源？

A ：在瀏覽器中，並且載入的方式其實相當於一次普通的GET請求，唯一不同的是，為了安全起見，瀏覽器不允許這種方式下對載入到的資源的讀寫操作，而只能使用標簽本身應當具備的能力（比如腳本執行、樣式應用等等）。

Q ：例如img script style等標簽，都允許垮域引用資源？

A ：在瀏覽器中，並且載入的方式其實相當於一次普通的GET請求，唯一不同的是，為了安全起見，瀏覽器不允許這種方式下對載入到的資源的讀寫操作，而只能使用標簽本身應當具備的能力（比如腳本執行、樣式應用等等）。

Q：JSONP和nginx跨域有什麼不同

JSONP和nginx是完全不同的 是可以跨域的，而且在跨域腳本中可以直接回調當前腳本的函數

原理：是可以跨域的，而且在跨域腳本中可以直接回調當前腳本的函數

script標簽是可以載入異域的JavaScript並執行的，通過預先設定好的callback函數來實現和母頁面的交互。它有一個大名，叫做JSONP跨域，JSONP是JSON with Padding的略稱。它是一個非官方的協議，明明是載入script，為啥和JSON扯上關系呢？原來就是這個callback函數，對它的使用有一個典型的方式，就是通過JSON來傳參，即將JSON數據填充進回調函數，這就是JSONP的JSON+Padding的含義。JSONP只支持GET請求。

❷ 轉載：反向代理伺服器nginx-proxy-manager

什麼是 Nginx Proxy Manager ？

Nginx Proxy Manager 是用於管理 Nginx 代理主機的 Docker 容器，具有簡單、強大的界面。它使您可以輕松地轉發到您在家裡或其他地方運行的網站，包括免費的 SSL，而無需對 Nginx 或 Letsencrypt 了解太多。

通過 phpMyAdmin 在 MariaDB 10 中新建用戶 npm ，創建同名的庫 npm 並授予所有許可權。

在注冊表中搜索 nginx-proxy-manager ，選擇第一個 jc21/nginx-proxy-manager，版本選擇 latest。

在 docker 文件夾中，創建一個新文件夾，並將其命名為 npm，再建 2 個子目錄，分別命名為 data 和 letsencrypt

埠
埠不沖突就行，不確定的話可以用命令查一下

在瀏覽器中輸入 http://群暉IP:2081 就能看到主界面

默認的賬號： [email protected] ，密碼：changeme

登錄後可以編輯用戶信息

之後是密碼

進入主菜單的 SSL Certificates

Add SSL Certificate 有兩種方式，一種是在線申請，另一種是添加已有證書

在線申請和我們在『 免費的泛域名https證書自動續期 』一文中介紹的非常類似，需要選擇 DNS 解析服務提供商，以及填寫 token 等參數

老蘇因為已經配置了 Certbot 並實現了自動續期，所以只需要導入現有證書就可以了，Name 老蘇用了域名，這樣比較容易識別

上傳成功後，證書存放在 /data/custom_ssl/ 目錄中以 npm-1 、 npm-2 等子目錄保存

進入主菜單的 Hosts

以將 http://192.168.0.197:5000 映射到 https://nas.laosu.ml 為例

因為准備用 https 協議訪問，所以必須勾選 Force SSL

其他的 HTTP/2 和 HSTS 和群暉內置的是一樣的，可根據需要勾選，沒啥問題的話老蘇建議都勾上

為什麼要另外安裝 nginx proxy manager 而不是用群暉內置的反向代理的原因，老蘇在一開始就講了，裝完之後老蘇還發現了幾個優點：

❸ Nginx反向代理docker容器進行域名解析綁定的實現方法

可以把多個域名映射到同一個IP地址上

docker 鏡像名稱由REPOSITORY和TAG組成 [REPOSITORY[:TAG]] ，TAG默認為latest

在宿主機創建持久化 conf--配置目錄 html--靜態網站目錄 logs--日誌目錄 cert--存放證書目錄

將容器內的 nginx.conf 與 default.conf 文件分別拷貝到主機/mnt/nginx與目錄/mnt/nginx/conf下，分別執行

conf目錄下創建nginx.conf文件

首先要在域名管理中做好域名簡析

在conf.d目錄下創建 域名為ab..com的配置文件 ab..com.conf 文件 包含ssl證書

在conf.d目錄下創建 域名為gh..com的配置文件 gh..com.conf 文件 包含ssl證書

ginx.conf並沒有在etc/nginx/conf目錄下。

允許https訪問 的 default.conf 文件

將伺服器的配置文件掛載到容器中，這樣我們修改配置文件會方便一些。

退出nginx容器，將容器中的文件nginx.conf先拷貝到宿主機中，conf.d目錄下的 default.conf 文件拷貝出來

執行 docker stop ef 命令停止剛剛創建的nginx容器，ef是容器Id，然後執行 docker rm ef 移除容器，

-v /docker-root/nginx/conf/nginx.conf :/etc/nginx/nginx.conf

/docker-root/nginx/conf/nginx.conf 宿主機中的ngix配置文件 掛載 到容器的 /etc/nginx/nginx.conf 配置文件

-v /docker-root/nginx/conf/conf.d:/etc/nginx/conf.d

/docker-root/nginx/conf/conf.d 宿主機中的 配置目錄 conf.d 掛載到 容器的 /etc/nginx/conf.d 目錄上

-v /docker-root/nginx/cert:/cert/

映射ssl 證書文件

命令，重新創建nginx容器

這樣就可以將配置文件、log、靜態頁面映射到宿主機中。需要修改或者查看直接在宿主機中修改或者查看就可以了。需要注意的是， 配置文件雖然映射到宿主機中，但是如需配置路徑，還需配置成容器中的路徑 。

注意發布到 雲伺服器上 伺服器安全組是否開放了443埠。

把 vue 生成的 dist目錄下的文件 上傳到 伺服器

/root/docker-root/vue-mcyl-src

文件目錄 dist 目錄 Dockerfile 文件

轉到 此目錄下

使用下面的命令 生成鏡像

啟動容器

docker run -d mcyl-vue:v1.0

conf.d 目錄下的配置文件 default.conf

防火牆原因，需要將通信的埠開放

解決辦法：

firewall-cmd --zone=public --add-port=9080/tcp --permanent

firewall-cmd --zone=public --add-port=8080-8080/tcp

參考 http://www.ttlsa.com/web/multiple-https-host-nginx-with-a-ip-configuration/

❹ nginx反向代理三種模式

1、基於IP代理

2、基於域名代理

3、基於埠代理

Nginx是一款輕量級的Web 伺服器/反向代理伺服器及電子郵件(IMAP/POP3)代理伺服器，其特點是佔用內存少，並發能力強，是我們在Web開發中最常用的工具之一。

此外，Nginx能提供性能穩定、並且提供配置靈活的轉發功能。它可以根據不同的正則匹配，採取不同的轉發策略，並且Nginx對返回結果進行錯誤頁跳轉，異常判斷等。如果被分發的伺服器存在異常，它可以將請求重新轉發給另外一台伺服器，然後自動去除異常伺服器。

❺ Nginx反向代理實現負載均衡配置圖解

首先簡單的介紹下修改默認的nginx conf 大概在 ~ 行 去掉前面的#號 重啟nginx

#location ~ php$ {# proxy_pass ;#}改為 location ~ php$ { proxy_pass // : ;}

分別訪問 出現如下圖已經能夠針對不同請求訪問伺服器了

這樣當我們訪問 l的時候 前端的nginx會自動進行響應 當訪問 /test php的時候(這個時候nginx目錄下根本就沒有該文件) 但是通過上面的設置location ~ php$(表示

訪問php頁面test php : 的Apache進行響應

訪問目錄phpMyAdmin下的頁面的話 : 的Apache進行響應

修改原始默認的nginx conf的server模塊部分（大概在 ~ 行）

#location ~ php$ {# proxy_pass ;#}修改為 location ^~ /phpMyAdmin/ { proxy_pass : ;} location ~ php$ { proxy_pass : ;}

上面第一個部分location ^~ /phpMyAdmin/ 表示不使用; index index

2.在配置文件nginx.conf的模塊中添加伺服器集群server cluster的定義。Tw.WinGWit.

upstream myCluster { server 192.168.2.3:8080 ; server 192.168.2.2:80 ; server 192.168.2.8:80 ;}

表示這個server cluster包含3台伺服器

3.然後在server模塊中定義負載均衡

location ~ .php$ { proxy_pass //myCluster ; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}

proxy_pass //myCluster ; 這里的名字和上面的cluster的名字相同

配置好後，當訪問頁面，nginx目錄下根本沒有該文件，但是它會自動將其pass到myCluster定義的伺服器群，分別由上述的3台伺服器中的一台來做處理。

上面在定義upstream的時候每個server之後沒有定義權重，表示兩者均衡；如果希望某個更多響應的話，可以加weight

upstream myCluster { server 192.168.2.3:8080 weight=5; server 192.168.2.2:80 ; server 192.168.2.8:80 ;}

這樣表示5/7的幾率訪問第一個server,1/7訪問第二個、第三個。另外還可以定義max_fails和fail_timeout等參數。

所以我們使用nginx的反向代理伺服器reverse proxy server的功能，將其布置到多台apache server的前端。

nginx僅僅用來處理靜態頁面響應和動態請求的代理pass，後台的apache伺服器來對前台pass過來的動態頁面進行處理並返回給nginx。

❻ Nginx 使用反向代理 解決非同步api獲取問題！

問題解決非常簡單，在寶塔伺服器站點配置中，對nginx站點配置增加如下配置信息：

1、location 後面的/api是匹配本地url中帶有指定目錄所用；
2、 rewrite ^/api/(.*)$ /$1 break; 這一段是用來進行匹配修改的，意思是去除掉後面的api
3、 proxy_pass http://localhost:8080; 這一段是用來設置轉發地址的，意思就是你要把/api 這個路徑指向的地址；
比如說你本地是 123.com 你要把 123.com/api 變成 234.com/api 就在 proxy_pass中輸入 http://234.com 即可；

❼ Nginx反向代理的使用及原理

正向代理，用通俗的方式來說，就是代理伺服器只起到轉發的作用，例如，在顧客進商店購買東西，商店就是一個正向代理，起到的作用就是把商品從廠家代理售賣到顧客手中。

反向代理，就是顧客的請求是確定的，但將商品的需求信息發送給代理商之後，代理商通過各種方式尋找不同的供貨商，再把供貨商提供的商品轉交給顧客。顧客是不知道代理商背後的供貨商是誰的。這種方式有點類似於目前的「三隻松鼠」等網路直銷平台的邏輯，顧客發送芒果乾的請求給三隻松鼠，三隻松鼠從全國進行供貨商的選擇，拿到貨品後再打上三隻松鼠的logo轉交給顧客，實現反向的代理，代理的是供貨商，顧客不知道具體的供應商是誰(所以才會要求包裝上需要印上供應商的名稱和地址，要不然出問題都不知道找誰。)

Nginx的安裝網路有很多資源，包括Linux和Windows的，在此不表。主要關注一下如何進行配置，來看看 nginx.conf.default 中的配置信息：

可以看到，主要的幾個配置模塊：

下面主要講講經常使用的server以及location的配置。

gzip壓縮中

對於阿里雲上的配置，我們直接使用一級域名 abc.com 解析阿里雲伺服器的IP地址：

❽ nginx 反向代理和後端伺服器獲取真實 ip

nginx 反向代理是什麼？

為了提高吞吐量，有些伺服器是專門跑程序用的，有些伺服器是跑靜態資源的。

你可能訪問一個網頁，裡面有圖片，而這個圖片並不是你訪問的這個網頁的伺服器，也叫前端伺服器，而是你的圖片請求被 Nginx 轉發到了一台後端伺服器，由後端伺服器提供給前端伺服器再返回到客戶端的。

我這台 nginx 的配置非常細致，有 nginx.conf ,在這個配置中包含了兩個文件夾，一個是 sites-available ，一個是 sites-enabled , nginx.cof 一般用來做整個 nginx 的配置。

域名配置段在 sites-avaliable 下，然後建立一個軟連接到 sites-enabled 下去。

反向代理就寫在域名配置段里，客戶端通過訪問伺服器，伺服器將請求分配按照 server 段里的則正匹配，將請求按照 fastcgi 發送到 php-fpm 通過分配再到我們的程序。

反向代理一樣，也需要通過正則來捕捉到用戶的請求。(2018-12-9,現在流行的做法是將靜態資源全部壓縮打包,丟到cdn上去，伺服器基本只做埠轉發,https配置,日誌,負載均衡,等很多很多功能)

server 段里多加以上這一條，前端的反向代理的工作就完成了。

(當然要開啟反向代理在 nginx.conf 里)以上捕捉到圖片格式結尾的就將這種請求轉發到伺服器地址，後端伺服器只要監聽這個埠將 root 指向資源目錄就行了。

當這一切做完後會發現，後端伺服器獲取到的並不是用戶的 ip 地址而是前端伺服器的 ip (通過 nginx 的訪問日誌)，這是正常的。

因為本來就是前段請求的，但是可以通過 proxy_set_header 段將用戶的真實ip帶到後端伺服器去，而後端伺服器需要接收傳過來的這個參數。

日誌的格式默認情況下是不接收這種參數的，日誌格式在 nginx.conf 裡面定義，默認沒有定義，自己加上去就可以了。

這就是日誌的格式，可以自己添加和修改，上面主要描述的是定義一個格式這個格式的名字為main。

這個格式里包含了哪些東西順序是怎樣的，定義訪問成功的日誌的路徑，使用main格式來進行寫入。

改完後，前端伺服器 nginx -s reload ，後端伺服器 nginx -s reopen 。

反向代理就是這樣。有反向代理，當然也有正向代理了，也很簡單。

原文鏈接: nginx反向代理和後端伺服器獲取真實ip-伺服器

❾ 京東大佬細說：Nginx反向代理時保持長連接，看完直呼"學到了！"

前言：

深入了解nginx，get到nginx的一些性能優化方向。除了了解如何保持長連接，也通過本案例學習到開源中間件的一些常用定位思路和優化方法。

場景描述

HTTP1.1之後，HTTP協議支持持久連接，也就是長連接，優點在於在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。如果我們使用了nginx去作為反向代理或者負載均衡，從客戶端過來的長連接請求就會被轉換成短連接發送給伺服器端。為了支持長連接，我們需要在nginx伺服器上做一些配置。

要求

到長連接，我們必須做到以下兩點：

i.從client到nginx是長連接

ii.從nginx到server是長連接

對於客戶端而言，nginx其實扮演著server的角色，反之，之於server，nginx就是一個client。

保持和Client的長連接

我們要想做到Client與Nginx之間保持長連接，需要：

i.Client發送過來的請求攜帶「keep-alive」header。

ii.Nginx設置支持keep-alive。

HTTP配置

默認情況下，nginx已經開啟了對client連接的keepalive 支持。對於特殊場景，可以調整相關參數。

大多數情況下，keepalive_requests = 100也夠用，但是對於 QPS 較高的場景，非常有必要加大這個參數，以避免出現大量連接被生成再拋棄的情況，減少TIME_WAIT。QPS=10000 時，客戶端每秒發送 10000 個請求 (通常建立有多個長連接)，每個連接只能最多跑 100 次請求，意味著平均每秒鍾就會有 100 個長連接因此被 nginx 關閉。同樣意味著為了保持 QPS，客戶端不得不每秒中重新新建 100 個連接。因此，如果用netstat命令看客戶端機器，就會發現有大量的TIME_WAIT的socket連接 (即使此時keepalive已經在 Client 和 NGINX 之間生效)。

保持和Server的長連接

想讓Nginx和Server之間維持長連接，最樸素的設置如下：

upstream配置

upstream中，有一個參數特別的重要，就是 keepalive 。 這個參數和之前http裡面的 keepalive_timeout 不一樣。這個參數的含義是，連接池裡面最大的空閑連接數量。

不理解？沒關系，我們來舉個例子：

場景：

有一個HTTP服務，作為upstream伺服器接收請求，響應時間為100毫秒。要求性能達到10000 QPS，我們需要在nginx與upstream伺服器之間建立大概1000條HTTP請求。（1000/0.1s=10000）

最優情況：

假設請求非常的均勻平穩，每一個請求都是100ms，請求結束會被馬上放入連接池並置為idle（空閑）狀態。

我們以0.1s為單位：

1. 我們現在keepalive的值設置為10，每0.1s鍾有1000個連接。

2. 第0.1s的時候，我們一共有1000個請求收到並釋放。

3. 第0.2s的時候，我們又來了1000個請求，在0.2s結束的時候釋放。

請求和應答都比較均勻，0.1s釋放的連接正好夠用，不需要建立新連接，且連接池中沒有idle狀態的連接。

第一種情況：

應答非常平穩，但是請求不平穩 的時候

1.第0.3s的時候，我們只有500個請求收到，有500個請求因為網路延遲等原因沒有進來。這個時候，Nginx檢測到連接池中有500個idle狀態的連接，就直接關閉了（500-10）個連接。

2.第0.4s的時候，我們收到了1500個請求，但是現在池裡面只有（500+10）個連接，所以Nginx不得不重新建立了（1500-510）個連接。如果在第4步的時候，沒有關閉那490個連接的話，只需要重新建立500個連接。

第二種情況：

請求非常平穩，但是應答不平穩 的時候

1. 第0.3s的時候，我們一共有1500個請求收到。但是池裡面只有1000個連接，這個時候，Nginx又創建了500個連接，一共1500個連接。

2.第0.3s的時候，第0.3s的連接全部被釋放，我們收到了500個請求。 Nginx檢測到池裡面有1000個idle狀態的連接，所以不得不釋放了（1000-10）個連接。造成連接數量反復震盪的一個推手，就是這個keepalive 這個最大空閑連接數。上面的兩種情況說的都是 keepalive設置的不合理導致Nginx有多次釋放與創建連接的過程，造成資源浪費。

keepalive 這個參數設置一定要小心，尤其是對於 QPS 要求比較高或者網路環境不穩定的場景，一般根據 QPS 值和 平均響應時間能大致推算出需要的長連接數量。然後將keepalive設置為長連接數量的10%到30%。

location配置

HTTP 協議中對長連接的支持是從 1.1 版本之後才有的，因此最好通過proxy_http_version 指令設置為 1.1。HTTP1.0不支持keepalive特性，當沒有使用HTTP1.1的時候，後端服務會返回101錯誤，然後斷開連接。而「Connection」 header 可以選擇被清理，這樣即便是 Client 和 Nginx 之間是短連接，Nginx 和 upstream 之間也是可以開啟長連接的。

另外一種高級方式

http裡面的map的作用是：讓轉發到代理伺服器的 "Connection" 頭欄位的值，取決於客戶端請求頭的"Upgrade" 欄位值。

如果$http_upgrade沒有匹配，那 "Connection" 頭欄位的值會是upgrade。

如果$http_upgrade為空字元串的話，那 "Connection" 頭欄位的值會是 close。

【補充】

NGINX支持WebSocket。對於NGINX將升級請求從客戶端發送到後台伺服器，必須明確設置Upgrade和Connection標題。這也算是上面情況所非常常用的場景。HTTP的Upgrade協議頭機制用於將連接從HTTP連接升級到WebSocket連接，Upgrade機制使用了Upgrade協議頭和Connection協議頭。為了讓Nginx可以將來自客戶端的Upgrade請求發送到後端伺服器，Upgrade和Connection的頭信息必須被顯式的設置。

【注意】

在nginx的配置文件中，如果當前模塊中沒有proxy_set_header的設置，則會從上級別繼承配置。繼承順序為：http, server, location。如果在下一層使用proxy_set_header修改了header的值，則所有的header值都可能會發生變化，之前繼承的所有配置將會被丟棄。所以，盡量在同一個地方進行proxy_set_header，否則可能會有別的問題。