A. 為什麼要用nginx來做反向代理
nginx 這個輕量級、高性能的 web server 主要可以干兩件事情：
〉直接作為http server(代替apache，對PHP需要FastCGI處理器支持)；
〉另外一個功能就是作為反向代理伺服器實現負載均衡
以下我們就來舉例說明如何使用 nginx 實現負載均衡。因為nginx在處理並發方面的優勢，現在這個應用非常常見。當然了Apache的 mod_proxy和mod_cache結合使用也可以實現對多台app server的反向代理和負載均衡，但是在並發處理方面apache還是沒有 nginx擅長。
1)環境：
a. 我們本地是Windows系統，然後使用VirutalBox安裝一個虛擬的Linux系統。
在本地的Windows系統上分別安裝nginx(偵聽8080埠)和apache(偵聽80埠)。在虛擬的Linux系統上安裝apache(偵聽80埠)。
這樣我們相當於擁有了1台nginx在前端作為反向代理伺服器；後面有2台apache作為應用程序伺服器(可以看作是小型的server cluster。;-) )；
b. nginx用來作為反向代理伺服器，放置到兩台apache之前，作為用戶訪問的入口；
nginx僅僅處理靜態頁面，動態的頁面(php請求)統統都交付給後台的兩台apache來處理。
也就是說，可以把我們網站的靜態頁面或者文件放置到nginx的目錄下；動態的頁面和資料庫訪問都保留到後台的apache伺服器上。
c. 如下介紹兩種方法實現server cluster的負載均衡。
我們假設前端nginx(為127.0.0.1:80)僅僅包含一個靜態頁面index.html；
後台的兩個apache伺服器(分別為localhost:80和158.37.70.143:80)，一台根目錄放置phpMyAdmin文件夾和test.php(裡面測試代碼為print 「server1「;)，另一台根目錄僅僅放置一個test.php(裡面測試代碼為 print 「server2「;)。
2)針對不同請求 的負載均衡：
a. 在最簡單地構建反向代理的時候 (nginx僅僅處理靜態不處理動態內容，動態內容交給後台的apache server來處理)，我們具體的設置為：在nginx.conf中修改：
復制代碼 代碼如下:
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
〉 這樣當客戶端訪問localhost:8080/index.html的時候，前端的nginx會自動進行響應；
〉當用戶訪問localhost:8080/test.php的時候(這個時候nginx目錄下根本就沒有該文件)，但是通過上面的設置 location ~ \.php$(表示正則表達式匹配以.php結尾的文件，詳情參看location是如何定義和匹配的 http://wiki.nginx.org/NginxHttpCoreMole) ，nginx伺服器會自動pass給 158.37.70.143的apache伺服器了。該伺服器下的test.php就會被自動解析，然後將html的結果頁面返回給nginx，然後 nginx進行顯示(如果nginx使用memcached模塊或者squid還可以支持緩存)，輸出結果為列印server2。
如上是最為簡單的使用nginx做為反向代理伺服器的例子；
b. 我們現在對如上例子進行擴展，使其支持如上的兩台伺服器。
我們設置nginx.conf的server模塊部分，將對應部分修改為：
復制代碼 代碼如下:
location ^~ /phpMyAdmin/ {
proxy_pass 127.0.0.1:80 ;
}
location ~ \.php$ {
proxy_pass 158.37.70.143:80 ;
}
上面第一個部分location ^~ /phpMyAdmin/，表示不使用正則表達式匹配(^~)，而是直接匹配，也就是如果客戶端訪問的 URL是以http://localhost:8080/phpMyAdmin/ 開頭的話(本地的nginx目錄下根本沒有phpMyAdmin目錄)，nginx會自動pass到127.0.0.1:80 的Apache伺服器，該伺服器對phpMyAdmin目錄下的頁面進行解析，然後將結果發送給nginx，後者顯示；
如果客戶端訪問URL是http://localhost/test.php 的話，則會被pass到158.37.70.143:80 的apache進行處理。
因此綜上，我們實現了針對不同請求的負載均衡。
〉如果用戶訪問靜態頁面index.html，最前端的nginx直接進行響應；
〉如果用戶訪問test.php頁面的話，158.37.70.143:80 的Apache進行響應；
〉如果用戶訪問目錄phpMyAdmin下的頁面的話，127.0.0.1:80 的Apache進行響應；
3)訪問同一頁面 的負載均衡：
即用戶訪問http://localhost:8080/test.php 這個同一頁面的時候，我們實現兩台伺服器的負載均衡 (實際情況中，這兩個伺服器上的數據要求同步一致，這里我們分別定義了列印server1和server2是為了進行辨認區別)。
a. 現在我們的情況是在windows下nginx是localhost偵聽8080埠；
兩台apache，一台是127.0.0.1:80(包含test.php頁面但是列印server1)，另一台是虛擬機的158.37.70.143:80(包含test.php頁面但是列印server2)。
b. 因此重新配置nginx.conf為：
〉首先在nginx的配置文件nginx.conf的http模塊中添加，伺服器集群server cluster(我們這里是兩台)的定義：
復制代碼 代碼如下:
upstream myCluster {
server 127.0.0.1:80 ;
server 158.37.70.143:80 ;
}
表示這個server cluster包含2台伺服器
〉然後在server模塊中定義，負載均衡：
復制代碼 代碼如下:
location ~ \.php$ {
proxy_pass http://myCluster ; #這里的名字和上面的cluster的名字相同
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;
}
這樣的話，如果訪問http://localhost:8080/test.php 頁面的話，nginx目錄下根本沒有該文件，但是它會自動將其pass到myCluster定義的服務區機群中，分別由127.0.0.1:80;或者158.37.70.143:80;來做處理。
上面在定義upstream的時候每個server之後沒有定義權重，表示兩者均衡；如果希望某個更多響應的話例如：
復制代碼 代碼如下:
upstream myCluster {
server 127.0.0.1:80 weight=5;
server 158.37.70.143:80 ;
}
這樣表示5/6的幾率訪問第一個server,1/6訪問第二個。另外還可以定義max_fails和fail_timeout等參數。
綜上，我們使用nginx的反向代理伺服器reverse proxy server的功能，將其布置到多台apache server的前端。
nginx僅僅用來處理靜態頁面響應和動態請求的代理pass，後台的apache server作為app server來對前台pass過來的動態頁面進行處理並返回給nginx。
通過以上的架構，我們可以實現nginx和多台apache構成的機群cluster的負載均衡。
兩種均衡：
1)可以在nginx中定義訪問不同的內容，代理到不同的後台server； 如上例子中的訪問phpMyAdmin目錄代理到第一台server上；訪問test.php代理到第二台server上；
2)可以在nginx中定義訪問同一頁面，均衡 (當然如果伺服器性能不同可以定義權重來均衡)地代理到不同的後台server上。 如上的例子訪問test.php頁面，會均衡地代理到server1或者server2上。
實際應用中，server1和server2上分別保留相同的app程序和數據，需要考慮兩者的數據同步。
B. 前端和後端可不可以都是nginx
nginx只能做數據的轉發與傳送，一般不用於運行後端的腳本，所以後端一般需要其他的伺服器如java用tomcat，然後做一層nginx代理網關
單靠nginx是無法運行java代碼
C. 模塊化後的前端怎麼部署django nginx
以vue框架為例，在nginx.conf中監聽80或443埠的server的路由配置設置為：
location ^~ /api { # url如/api/v1.0/user/info等，通過uwsgi轉發到django後端項目中處理
include /etc/nginx/uwsgi_params;
uwsgi_pass 127.0.0.1:8077;
include /etc/nginx/mime.types;
}
location ^~ /static { # 後端的資源文件夾為static，前端請求後端項目包內的靜態文件
root /root/backend_end_project/static/;
}
location ^~ /admin { # django的後台管理頁面通過uwsgi轉交給django處理
include /etc/nginx/uwsgi_params;
uwsgi_pass 127.0.0.1:8077;
include /etc/nginx/mime.types;
}
location ^~ /assets { # 前端的資源文件夾為assets，前端請求前端項目包內的靜態文件
root /root/front_end_project/dist;
}
location / { # 表示其它路徑都交給前端項目根目錄下的index.html處理
root /root/front_end_project;
try_files $uri /index.html;
}
D. 手機淘寶，瀏覽圖文詳情就出現welcom to nginx，是怎麼回事，如何解決
只能等淘寶解決了, 這是他們伺服器報出的問題
E. nginx怎麼部署前端項目
1、安裝護衛神·nginx大師
2、開設站點，綁定和解析域名
3、上傳前端頁面到網站
F. nginx有什麼用
nginx提供了IMAP服務的功能。
Nginx(engine x) 是一個高性能的HTTP和反向代理web伺服器，同時也提供了IMAP/POP3/SMTP服務。Nginx作為一款輕量級的Web伺服器/反向代理伺服器及電子郵件（IMAP/POP3）代理伺服器，在BSD-like 協議下發行。
Nginx作為負載均衡服務，Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務，也可以支持作為 HTTP代理服務對外進行服務。Nginx採用C進行編寫，不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多。
nginx佔有內存少，並發能力強，事實上nginx的並發能力在同類型的網頁伺服器中表現較好，中國大陸使用nginx網站用戶有：網路、京東、新浪、網易、騰訊、淘寶等。
(6)淘寶前端頁面放nginx擴展閱讀：
nginx使用技巧
大體上來說nginx主要用於反向加速代理而不是像squid那樣作為常規代理服務。Nginx的最大優勢在於高負載情況下內存和CPU的低消耗。我不認為squid能給你帶來比nginx更好的性能。
依照NginxImapProxyExample開始你的配置，關於不同配置參數的具體信息，可以用運行於apache上的php腳本做後端驗證，也可以使用運行於同一個伺服器的 nginx-embedded-perl模塊作為 imap/pop代理和認證後端。
G. 輸入淘寶網址，出現「400 Bad Request Request Header Or Cookie Too Large nginx」怎麼進不去呢求指點
出現這種情況，可能是您電腦瀏覽器臨時文件過多造成的，建議您關閉所有頁面，然後打開瀏覽器，點擊網頁上方的「工具」——選擇「Internet選項」——「刪除文件，刪除Cookies」確定（離線文件一並刪除）。也有可能是游覽器的問題，你換個游覽器試試。
H. 如何實現前端用NGINX，後端用Apache
1、nginx相對於apache的優點：
輕量級，同樣起web 服務，比apache佔用更少的內存及資源
抗並發，nginx 處理請求是非同步非阻塞的，而apache 則是阻塞型的，在高並發下nginx 能保持低資源低消耗高性能
高度模塊化的設計，編寫模塊相對簡單
社區活躍，各種高性能模塊出品迅速啊
apache 相對於nginx 的優點：
rewrite ，比nginx 的rewrite 強大
動態頁面
模塊超多，基本想到的都可以找到
少bug ，nginx 的bug 相對較多
超穩定
存在就是理由，一般來說，需要性能的web 服務，用nginx 。如果不需要性能只求穩定，那就apache 吧。
後者的各種功能模塊實現得比前者，例如ssl 的模塊就比前者好，可配置項多。這里要注意一點，epoll(freebsd 上是 kqueue )網路
IO 模型是nginx 處理性能高的根本理由，但並不是所有的情況下都是epoll 大獲全勝的，如果本身提供靜態服務的就只有寥寥幾個文
件，apache 的select 模型或許比epoll 更高性能。當然，這只是根據網路IO 模型的原理作的一個假設，真正的應用還是需要實測了再說
的。
2、作為 Web 伺服器：相比 Apache，Nginx 使用更少的資源，支持更多的並發連接，體現更高的效率，這點
使 Nginx 尤其受到虛擬主機提供商的歡迎。在高連接並發的情況下，Nginx是Apache伺服器不錯的替代品: Nginx在美國是做虛擬主機生
意的老闆們經常選擇的軟體平台之一. 能夠支持高達 50,000 個並發連接數的響應, 感謝Nginx為我們選擇了 epoll and kqueue 作為開發模型.
Nginx
作為負載均衡伺服器: Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作為 HTTP代理 伺服器對外進行
服務. Nginx採用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多.
作為郵件代理伺服器: Nginx 同時也是一個非常優秀的郵件代理伺服器（最早開發這個產品的目的之一也是作為郵件代理伺服器）, Last.fm 描述了成功並且美妙的使用經驗.
Nginx 是
一個安裝非常的簡單 , 配置文件非常簡潔（還能夠支持perl語法）, Bugs 非常少的伺服器: Nginx 啟動特別容易, 並且幾乎可以做到
7*24不間斷運行，即使運行數個月也不需要重新啟動. 你還能夠不間斷服務的情況下進行軟體版本的升級 .
3、Nginx 配置簡潔, Apache 復雜
Nginx 靜態處理性能比 Apache 高 3倍以上
Apache 對 PHP 支持比較簡單，Nginx 需要配合其他後端用
Apache 的組件比 Nginx 多
現在 Nginx 才是 Web 伺服器的首選
4、最核心的區別在於apache是同步多進程模型，一個連接對應一個進程；nginx是非同步的，多個連接（萬級別）可以對應一個進程
5、nginx處理靜態文件好,耗費內存少.但無疑apache仍然是目前的主流,有很多豐富的特性.所以還需要搭配著來.當然如果能確定nginx就適合需求,那麼使用nginx會是更經濟的方式.
apache有先天不支持多核心處理負載雞肋的缺點，建議使用nginx做前端，後端用apache。大型網站建議用nginx自代的集群功能
6、
從個人過往的使用情況來看，nginx的負載能力比apache高很多。最新的伺服器也改用nginx了。而且nginx改完配置能-t測試一下配置有沒
有問題，apache重啟的時候發現配置出錯了，會很崩潰，改的時候都會非常小心翼翼現在看有好多集群站，前端nginx抗並發，後端apache集群，
配合的也不錯。
7、nginx處理動態請求是雞肋，一般動態請求要apache去做，nginx只適合靜態和反向。
8、從我個人的經驗來看，nginx是很不錯的前端伺服器，負載性能很好，在老奔上開nginx，用webbench模擬10000個靜態文件請求毫不吃力。apache對php等語言的支持很好，此外apache有強大的支持網路，發展時間相對nginx更久，
9、
Nginx優於apache的主要兩點：1.Nginx本身就是一個反向代理伺服器 2.Nginx支持7層負載均衡；其他的當然，Nginx可能會比
apache支持更高的並發，但是根據NetCraft的統計，2011年4月的統計數據，Apache依然佔有62.71%，而Nginx是
7.35%，因此總得來說，Aapche依然是大部分公司的首先，因為其成熟的技術和開發社區已經也是非常不錯的性能。
10、你對web server的需求決定你的選擇。大
部分情況下nginx都優於APACHE，比如說靜態文件處理、PHP-CGI的支持、反向代理功能、前端Cache、維持連接等等。在
Apache+PHP（prefork）模式下，如果PHP處理慢或者前端壓力很大的情況下，很容易出現Apache進程數飆升，從而拒絕服務的現象。
11、可以看一下nginx lua模塊...apache比nginx多的模塊，可直接用lua實現apache是最流行的，why？大多數人懶得更新到nginx或者學新事物
12、對於nginx，我喜歡它配置文件寫的很簡潔，正則配置讓很多事情變得簡單運行效率高，佔用資源少，代理功能強大，很適合做前端響應伺服器
13、Apache在處理動態有優勢，Nginx並發性比較好，CPU內存佔用低，如果rewrite頻繁，那還是Apache吧
I. 現在什麼技術取代了jsp
Spring Boot一部分取代了jsp：
以前老的方式是：
1.客戶端請求
2.服務端的servlet或controller接收請求（路由規則由後端制定，整個項目開發的權重大部分在後端）
3.調用service,代碼完成業務邏輯
4.返回jsp
5.jsp展現一些動態的代碼
新的方式是：
1.瀏覽器發送請求
2.直接到達html頁面（路由規則由前端制定，整個項目開發的權重前移）
3.html頁面負責調用服務端介面產生數據（通過ajax等等）
4.填充html，展現動態效果。
（有興趣的童鞋可以訪問一下阿里巴巴等大型網站，然後按一下F12，監控一下你刷新一次頁面，他的http是怎麼玩的，大多數都是單獨請求後台數據，使用json傳輸數據，而不是一個大而全的http請求把整個頁麵包括動+靜全部返回過來）
這樣做的好處是：
1.可以實現真正的前後端解耦，前端伺服器使用nginx。
前端伺服器放的是css，js，圖片等等一系列靜態資源（甚至你還可以css，js，圖片等資源放到特定的文件伺服器，例如阿里雲的oss，並使用cdn加速），前端伺服器負責控制頁面引用，跳轉，調用後端的介面，後端伺服器使用tomcat。
（這里需要使用一些前端工程化的框架比如nodejs，react，router，react，rex，webpack）
2.發現bug，可以快速定位是誰的問題，不會出現互相踢皮球的現象。
頁面邏輯，跳轉錯誤，瀏覽器兼容性問題，腳本錯誤，頁面樣式等問題，全部由前端工程師來負責。
介面數據出錯，數據沒有提交成功，應答超時等問題，全部由後端工程師來解決。
雙方互不幹擾，前端與後端是相親相愛的一家人。
3.在大並發情況下，我可以同時水平擴展前後端伺服器，比如淘寶的一個首頁就需要2000台前端伺服器做集群來抗住日均多少億+的日均pv。
（去參加阿里的技術峰會，聽他們說他們的web容器都是自己寫的，就算他單實例抗10萬http並發，2000台是2億http並發，並且他們還可以根據預知洪峰來無限拓展，很恐怖，就一個首頁。。。）
4.減少後端伺服器的並發壓力，除了介面以外的其他所有http請求全部轉移到前端nginx上。
5.即使後端服務暫時超時或者宕機了，前端頁面也會正常訪問，只不過數據刷不出來而已。
6.也許你也需要有微信相關的輕應用，那樣你的介面完全可以共用，如果也有app相關的服務，那麼只要通過一些代碼重構，也可以大量復用介面，提升效率。
7.頁面顯示的東西再多也不怕，因為是非同步載入。
J. 一個前端頁面如何部署
一個前端頁面，在本地直接打開就能訪問。另外如果是要放到伺服器下的話，可以裝個nginx，或者apache，或者tomcat，直接放到網頁路徑下，就行。