nginx基本配置

nginx概述

nginx是一款自由的、開源的、高性能的HTTP服務器和反向代理服務器；同時也是一個IMAP、POP三、SMTP代理服務器；nginx能夠做爲一個HTTP服務器進行網站的發佈處理，另外nginx能夠做爲反向代理進行負載均衡的實現。

基本Http服務，能夠做爲Http代理服務器和反向代理服務器，支持經過緩存加速訪問，能夠完成簡單的負載均衡和容錯，支持包過濾功能，支持SSL
高級Http服務，能夠進行自定義配置，支持虛擬主機，支持URL重定向，支持網絡監控，支持流媒體傳輸等
郵件代理服務器，支持IMAP/POP3代理服務功能，支持內部SMTP代理服務功能

反向代理

關於代理

說到代理，首先咱們要明確一個概念，所謂代理就是一個表明、一個渠道；

此時就設計到兩個角色，一個是被代理角色，一個是目標角色，被代理角色經過這個代理訪問目標角色完成一些任務的過程稱爲代理操做過程；如同生活中的專賣店~客人到adidas專賣店買了一雙鞋，這個專賣店就是代理，被代理角色就是adidas廠家，目標角色就是用戶

正向代理

說反向代理以前，咱們先看看正向代理，正向代理也是你們最常接觸的到的代理模式，咱們會從兩個方面來講關於正向代理的處理模式，分別從軟件方面和生活方面來解釋一下什麼叫正向代理

在現在的網絡環境下，咱們若是因爲技術須要要去訪問國外的某些網站，此時你會發現位於國外的某網站咱們經過瀏覽器是沒有辦法訪問的，此時你們可能都會用一個操做FQ進行訪問，FQ的方式主要是找到一個能夠訪問國外網站的代理服務器，咱們將請求發送給代理服務器，代理服務器去訪問國外的網站，而後將訪問到的數據傳遞給咱們！

上述這樣的代理模式稱爲正向代理，正向代理最大的特色是客戶端很是明確要訪問的服務器地址；服務器只清楚請求來自哪一個代理服務器，而不清楚來自哪一個具體的客戶端；正向代理模式屏蔽或者隱藏了真實客戶端信息。

 

 

 正向代理，架設在客戶機與目標主機之間，只用於代理內部網絡對Internet的鏈接請求，客戶機必須指定代理服務器,並將原本要直接發送到Web服務器上的http請求發送到代理服務器中。

反向代理

明白了什麼是正向代理，咱們繼續看關於反向代理的處理方式，舉例如我大天朝的某寶網站，天天同時鏈接到網站的訪問人數已經爆表，單個服務器遠遠不能知足人民日益增加的購買慾望了，此時就出現了一個你們耳熟能詳的名詞：分佈式部署；也就是經過部署多臺服務器來解決訪問人數限制的問題；某寶網站中大部分功能也是直接使用nginx進行反向代理實現的，而且經過封裝nginx和其餘的組件以後起了個高大上的名字：Tengine，有興趣的童鞋能夠訪問Tengine的官網查看具體的信息：http://tengine.taobao.org/
那麼反向代理具體是經過什麼樣的方式實現的分佈式的集羣操做呢，咱們先看一個示意圖：

經過上述的圖解你們就能夠看清楚了，多個客戶端給服務器發送的請求，nginx服務器接收到以後，按照必定的規則分發給了後端的業務處理服務器進行處理了。此時~請求的來源也就是客戶端是明確的，可是請求具體由哪臺服務器處理的並不明確了，nginx扮演的就是一個反向代理角色

反向代理，主要用於服務器集羣分佈式部署的狀況下，反向代理隱藏了服務器的信息！

項目場景

反向代理服務器架設在服務器端，經過緩衝常常被請求的頁面來緩解服務器的工做量，將客戶機請求轉發給內部網絡上的目標服務器；並將從服務器上獲得的結果返回給Internet上請求鏈接的客戶端，此時代理服務器與目標主機一塊兒對外表現爲一個服務器。

 

 一般狀況下，咱們在實際項目操做時，正向代理和反向代理頗有可能會存在在一個應用場景中，正向代理代理客戶端的請求去訪問目標服務器，目標服務器是一個反向單利服務器，反向代理了多臺真實的業務處理服務器。具體的拓撲圖以下：

負載均衡

咱們已經明確了所謂代理服務器的概念，那麼接下來，nginx扮演了反向代理服務器的角色，它是以依據什麼樣的規則進行請求分發的呢？不用的項目應用場景，分發的規則是否能夠控制呢？

這裏提到的客戶端發送的、nginx反向代理服務器接收到的請求數量，就是咱們說的負載量

請求數量按照必定的規則進行分發到不一樣的服務器處理的規則，就是一種均衡規則

因此~將服務器接收到的請求按照規則分發的過程，稱爲負載均衡。

負載均衡在實際項目操做過程當中，有硬件負載均衡和軟件負載均衡兩種，硬件負載均衡也稱爲硬負載，如F5負載均衡，相對造價昂貴成本較高，可是數據的穩定性安全性等等有很是好的保障，如中國移動中國聯通這樣的公司纔會選擇硬負載進行操做；更多的公司考慮到成本緣由，會選擇使用軟件負載均衡，軟件負載均衡是利用現有的技術結合主機硬件實現的一種消息隊列分發機制

nginx支持的負載均衡調度算法方式以下：

1. weight輪詢（默認）：接收到的請求按照順序逐一分配到不一樣的後端服務器，即便在使用過程當中，某一臺後端服務器宕機，nginx會自動將該服務器剔除出隊列，請求受理狀況不會受到任何影響。 這種方式下，能夠給不一樣的後端服務器設置一個權重值（weight），用於調整不一樣的服務器上請求的分配率；權重數據越大，被分配到請求的概率越大；該權重值，主要是針對實際工做環境中不一樣的後端服務器硬件配置進行調整的。

2. ip_hash：每一個請求按照發起客戶端的ip的hash結果進行匹配，這樣的算法下一個固定ip地址的客戶端總會訪問到同一個後端服務器，這也在必定程度上解決了集羣部署環境下session共享的問題。

3. fair：智能調整調度算法，動態的根據後端服務器的請求處理到響應的時間進行均衡分配，響應時間短處理效率高的服務器分配到請求的機率高，響應時間長處理效率低的服務器分配到的請求少；結合了前二者的優勢的一種調度算法。可是須要注意的是nginx默認不支持fair算法，若是要使用這種調度算法，請安裝upstream_fair模塊

4. url_hash：按照訪問的url的hash結果分配請求，每一個請求的url會指向後端固定的某個服務器，能夠在nginx做爲靜態服務器的狀況下提升緩存效率。一樣要注意nginx默認不支持這種調度算法，要使用的話須要安裝nginx的hash軟件包

查看nginx進程是否啓動

$ ps -ef|grep nginx

nginx會自動根據當前主機的CPU的內核數目建立對應的進程數量(當前ubuntu主機是2核4線程配置)

 

備註：這裏啓動的服務進程實際上是4個進程，由於nginx進程在啓動的時候，會附帶一個守護進程，用於保護正式進程不被異常終止；若是守護進程一旦返現nginx繼承被終止了，會自動重啓該進程。

守護進程通常會稱爲master進程，業務進程被稱爲worker進程

啓動nginx服務器命令

直接執行nginx會按照默認的配置文件進行服務器的啓動

$ nginx

中止nginx服務命令

$ nginx -s stop
or
$ nginx -s quit

從新啓動加載

一樣也可使用命令reopen和reload來從新啓動nginx或者從新加載配合着文件

測試配置是否正確 在 nginx/sbin 下執行 sudo ./nginx -t

而後重啓nginx 在 nginx/sbin 下執行 sudo ./nginx -s reload

 

nginx配置

nginx是一個功能很是強大的web服務器加反向代理服務器，同時又是郵件服務器等等

在項目使用中，使用最多的三個核心功能是反向代理、負載均衡和靜態服務器

這三個不一樣的功能的使用，都跟nginx的配置密切相關，nginx服務器的配置信息主要集中在nginx.conf這個配置文件中，而且全部的可配置選項大體分爲如下幾個部分

ain                                # 全局配置

events {                            # nginx工做模式配置

}

http {                                # http設置
    ....

    server {                        # 服務器主機配置
        ....
        location {                    # 路由配置
            ....
        }

        location path {
            ....
        }

        location otherpath {
            ....
        }
    }

    server {
        ....

        location {
            ....
        }
    }

    upstream name {                    # 負載均衡配置
        ....
    }
}

如上述配置文件所示，主要由6個部分組成：

1. main：用於進行nginx全局信息的配置
2. events：用於nginx工做模式的配置
3. http：用於進行http協議信息的一些配置
4. server：用於進行服務器訪問信息的配置
5. location：用於進行訪問路由的配置
6. upstream：用於進行負載均衡的配置

main模塊

觀察下面的配置代碼

# user nobody nobody;
worker_processes 2;
# error_log logs/error.log
# error_log logs/error.log notice
# error_log logs/error.log info
# pid logs/nginx.pid
worker_rlimit_nofile 1024;

上述配置都是存放在main全局配置模塊中的配置項

• user用來指定nginx worker進程運行用戶以及用戶組，默認nobody帳號運行
• worker_processes指定nginx要開啓的子進程數量，運行過程當中監控每一個進程消耗內存(通常幾M~幾十M不等)根據實際狀況進行調整，一般數量是CPU內核數量的整數倍
• error_log定義錯誤日誌文件的位置及輸出級別【debug / info / notice / warn / error / crit】
• pid用來指定進程id的存儲文件的位置
• worker_rlimit_nofile用於指定一個進程能夠打開最多文件數量的描述

event 模塊

 

event {
    worker_connections 1024;
    multi_accept on;
    use epoll;
}

上述配置是針對nginx服務器的工做模式的一些操做配置

• worker_connections 指定最大能夠同時接收的鏈接數量，這裏必定要注意，最大鏈接數量是和worker processes共同決定的。
• multi_accept 配置指定nginx在收到一個新鏈接通知後儘量多的接受更多的鏈接
• use epoll 配置指定了線程輪詢的方法，若是是linux2.6+，使用epoll，若是是BSD如Mac請使用Kqueue

http模塊

 做爲web服務器，http模塊是nginx最核心的一個模塊，配置項也是比較多的，項目中會設置到不少的實際業務場景，須要根據硬件信息進行適當的配置，常規狀況下，使用默認配置便可

http {
    ##
    # 基礎配置
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL證書配置
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # 日誌配置
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip 壓縮配置
    ##

    gzip on;
    gzip_disable "msie6";

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript
 text/xml application/xml application/xml+rss text/javascript;

    ##
    # 虛擬主機配置
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

基礎配置

sendfile on：配置on讓sendfile發揮做用，將文件的回寫過程交給數據緩衝去去完成，而不是放在應用中完成，這樣的話在性能提高有有好處
tc_nopush on：讓nginx在一個數據包中發送全部的頭文件，而不是一個一個單獨發
tcp_nodelay on：讓nginx不要緩存數據，而是一段一段發送，若是數據的傳輸有實時性的要求的話能夠配置它，發送完一小段數據就馬上能獲得返回值，可是不要濫用哦

keepalive_timeout 10：給客戶端分配鏈接超時時間，服務器會在這個時間事後關閉鏈接。通常設置時間較短，可讓nginx工做持續性更好
client_header_timeout 10：設置請求頭的超時時間
client_body_timeout 10:設置請求體的超時時間
send_timeout 10：指定客戶端響應超時時間，若是客戶端兩次操做間隔超過這個時間，服務器就會關閉這個連接

limit_conn_zone $binary_remote_addr zone=addr:5m ：設置用於保存各類key的共享內存的參數，
limit_conn addr 100: 給定的key設置最大鏈接數

server_tokens：雖然不會讓nginx執行速度更快，可是能夠在錯誤頁面關閉nginx版本提示，對於網站安全性的提高有好處哦
include /etc/nginx/mime.types：指定在當前文件中包含另外一個文件的指令
default_type application/octet-stream：指定默認處理的文件類型能夠是二進制
type_hash_max_size 2048：混淆數據，影響三列衝突率，值越大消耗內存越多，散列key衝突率會下降，檢索速度更快；值越小key，佔用內存較少，衝突率越高，檢索速度變慢

日誌配置

access_log logs/access.log：設置存儲訪問記錄的日誌
error_log logs/error.log：設置存儲記錄錯誤發生的日誌

SSL證書加密

ssl_protocols：指令用於啓動特定的加密協議，nginx在1.1.13和1.0.12版本後默認是ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2，TLSv1.1與TLSv1.2要確保OpenSSL >= 1.0.1 ，SSLv3 如今還有不少地方在用但有很多被攻擊的漏洞。
ssl prefer server ciphers：設置協商加密算法時，優先使用咱們服務端的加密套件，而不是客戶端瀏覽器的加密套件

壓縮配置

gzip 是告訴nginx採用gzip壓縮的形式發送數據。這將會減小咱們發送的數據量。
gzip_disable 爲指定的客戶端禁用gzip功能。咱們設置成IE6或者更低版本以使咱們的方案可以普遍兼容。
gzip_static 告訴nginx在壓縮資源以前，先查找是否有預先gzip處理過的資源。這要求你預先壓縮你的文件（在這個例子中被註釋掉了），從而容許你使用最高壓縮比，這樣nginx就不用再壓縮這些文件了（想要更詳盡的gzip_static的信息，請點擊這裏）。
gzip_proxied 容許或者禁止壓縮基於請求和響應的響應流。咱們設置爲any，意味着將會壓縮全部的請求。
gzip_min_length 設置對數據啓用壓縮的最少字節數。若是一個請求小於1000字節，咱們最好不要壓縮它，由於壓縮這些小的數據會下降處理此請求的全部進程的速度。
gzip_comp_level 設置數據的壓縮等級。這個等級能夠是1-9之間的任意數值，9是最慢可是壓縮比最大的。咱們設置爲4，這是一個比較折中的設置。
gzip_type 設置須要壓縮的數據格式。上面例子中已經有一些了，你也能夠再添加更多的格式。

文件緩存配置

open_file_cache 打開緩存的同時也指定了緩存最大數目，以及緩存的時間。咱們能夠設置一個相對高的最大時間，這樣咱們能夠在它們不活動超過20秒後清除掉。
open_file_cache_valid 在open_file_cache中指定檢測正確信息的間隔時間。
open_file_cache_min_uses 定義了open_file_cache中指令參數不活動時間期間裏最小的文件數。
open_file_cache_errors 指定了當搜索一個文件時是否緩存錯誤信息，也包括再次給配置中添加文件。咱們也包括了服務器模塊，這些是在不一樣文件中定義的。若是你的服務器模塊不在這些位置，你就得修改這一行來指定正確的位置。

server模塊

srever模塊配置是http模塊中的一個子模塊，用來定義一個虛擬訪問主機，也就是一個虛擬服務器的配置信息

server {
    listen        80;
    server_name localhost    192.168.1.100;
    root        /nginx/www;
    index        index.php index.html index.html;
    charset        utf-8;
    access_log    logs/access.log;
    error_log    logs/error.log;
    ......
}

核心配置信息以下：

• server：一個虛擬主機的配置，一個http中能夠配置多個server

• server_name：用力啊指定ip地址或者域名，多個配置之間用空格分隔

• root：表示整個server虛擬主機內的根目錄，全部當前主機中web項目的根目錄

• index：用戶訪問web網站時的全局首頁

• charset：用於設置www/路徑中配置的網頁的默認編碼格式

• access_log：用於指定該虛擬主機服務器中的訪問記錄日誌存放路徑

• error_log：用於指定該虛擬主機服務器中訪問錯誤日誌的存放路徑

location模塊

location模塊是nginx配置中出現最多的一個配置，主要用於配置路由訪問信息

在路由訪問信息配置中關聯到反向代理、負載均衡等等各項功能，因此location模塊也是一個很是重要的配置模塊

基本配置

location / {
    root    /nginx/www;
    index    index.php index.html index.htm;
}

location /：表示匹配訪問根目錄

root：用於指定訪問根目錄時，訪問虛擬主機的web目錄

index：在不指定訪問具體資源時，默認展現的資源文件列表

反向代理配置方式

經過反向代理代理服務器訪問模式，經過proxy_set配置讓客戶端訪問透明化

location / {
    proxy_pass http://localhost:8888;
    proxy_set_header X-real-ip $remote_addr;
    proxy_set_header Host $http_host;
}

uwsgi配置

wsgi模式下的服務器配置訪問方式

location / {
    include uwsgi_params;
    uwsgi_pass localhost:8888
}

upstream模塊

upstream模塊主要負責負載均衡的配置，經過默認的輪詢調度方式來分發請求到後端服務器

簡單的配置方式以下

upstream name {
    ip_hash;
    server 192.168.1.100:8000;
    server 192.168.1.100:8001 down;
    server 192.168.1.100:8002 max_fails=3;
    server 192.168.1.100:8003 fail_timeout=20s;
    server 192.168.1.100:8004 max_fails=3 fail_timeout=20s;
}

核心配置信息以下

• ip_hash：指定請求調度算法，默認是weight權重輪詢調度，能夠指定

• server host:port：分發服務器的列表配置

• -- down：表示該主機暫停服務

• -- max_fails：表示失敗最大次數，超過失敗最大次數暫停服務

• -- fail_timeout：表示若是請求受理失敗，暫停指定的時間以後從新發起請求

Nginx的配置文件nginx.conf配置詳解以下：
 
user nginx nginx ;
Nginx用戶及組：用戶 組。window下不指定
 
worker_processes 8;
工做進程：數目。根據硬件調整，一般等於CPU數量或者2倍於CPU。
 
error_log  logs/error.log;  
error_log  logs/error.log  notice;  
error_log  logs/error.log  info;  
錯誤日誌：存放路徑。
 
pid logs/nginx.pid;
pid（進程標識符）：存放路徑。
 
worker_rlimit_nofile 204800;
指定進程能夠打開的最大描述符：數目。
這個指令是指當一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（ulimit -n）與nginx進程數相除，可是nginx分配請求並非那麼均勻，因此最好與ulimit -n 的值保持一致。
如今在linux 2.6內核下開啓文件打開數爲65535，worker_rlimit_nofile就相應應該填寫65535。
這是由於nginx調度時分配請求到進程並非那麼的均衡，因此假如填寫10240，總併發量達到3-4萬時就有進程可能超過10240了，這時會返回502錯誤。
 
events
{
use epoll;
使用epoll的I/O 模型。linux建議epoll，FreeBSD建議採用kqueue，window下不指定。
補充說明:
與apache相類，nginx針對不一樣的操做系統，有不一樣的事件模型
A）標準事件模型
Select、poll屬於標準事件模型，若是當前系統不存在更有效的方法，nginx會選擇select或poll
B）高效事件模型
Kqueue：使用於FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用雙處理器的MacOS X系統使用kqueue可能會形成內核崩潰。
Epoll：使用於Linux內核2.6版本及之後的系統。
/dev/poll：使用於Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。
Eventport：使用於Solaris 10。 爲了防止出現內核崩潰的問題， 有必要安裝安全補丁。
 
worker_connections 204800;
沒個工做進程的最大鏈接數量。根據硬件調整，和前面工做進程配合起來用，儘可能大，可是別把cpu跑到100%就行。每一個進程容許的最多鏈接數，理論上每臺nginx服務器的最大鏈接數爲。worker_processes*worker_connections
keepalive_timeout 60;
keepalive超時時間。
 
client_header_buffer_size 4k;
客戶端請求頭部的緩衝區大小。這個能夠根據你的系統分頁大小來設置，通常一個請求頭的大小不會超過1k，不過因爲通常系統分頁都要大於1k，因此這裏設置爲分頁大小。
分頁大小能夠用命令getconf PAGESIZE 取得。
[root@web001 ~]# getconf PAGESIZE
但也有client_header_buffer_size超過4k的狀況，可是client_header_buffer_size該值必須設置爲「系統分頁大小」的整倍數。
 
open_file_cache max=65535 inactive=60s;
這個將爲打開文件指定緩存，默認是沒有啓用的，max指定緩存數量，建議和打開文件數一致，inactive是指通過多長時間文件沒被請求後刪除緩存。
 
open_file_cache_valid 80s;
這個是指多長時間檢查一次緩存的有效信息。
 
open_file_cache_min_uses 1;
open_file_cache指令中的inactive參數時間內文件的最少使用次數，若是超過這個數字，文件描述符一直是在緩存中打開的，如上例，若是有一個文件在inactive時間內一次沒被使用，它將被移除。
}
 
 
##設定http服務器，利用它的反向代理功能提供負載均衡支持
http
{
include mime.types;
設定mime類型,類型由mime.type文件定義
 
default_type application/octet-stream;
 
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
log_format log404 '$status [$time_local] $remote_addr $host$request_uri $sent_http_location';
日誌格式設置。
$remote_addr與$http_x_forwarded_for用以記錄客戶端的ip地址；
$remote_user：用來記錄客戶端用戶名稱；
$time_local： 用來記錄訪問時間與時區；
$request： 用來記錄請求的url與http協議；
$status： 用來記錄請求狀態；成功是200，
$body_bytes_sent ：記錄發送給客戶端文件主體內容大小；
$http_referer：用來記錄從那個頁面連接訪問過來的；
$http_user_agent：記錄客戶瀏覽器的相關信息；
一般web服務器放在反向代理的後面，這樣就不能獲取到客戶的IP地址了，經過$remote_add拿到的IP地址是反向代理服務器的iP地址。反向代理服務器在轉發請求的http頭信息中，能夠增長x_forwarded_for信息，用以記錄原有客戶端的IP地址和原來客戶端的請求的服務器地址。
 
access_log  logs/host.access.log  main;
access_log  logs/host.access.404.log  log404;
用了log_format指令設置了日誌格式以後，須要用access_log指令指定日誌文件的存放路徑；
 
server_names_hash_bucket_size 128;
#保存服務器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。參數hash bucket size老是等於hash表的大小，而且是一路處理器緩存大小的倍數。在減小了在內存中的存取次數後，使在處理器中加速查找hash表鍵值成爲可能。若是hash bucket size等於一路處理器緩存的大小，那麼在查找鍵的時候，最壞的狀況下在內存中查找的次數爲2。第一次是肯定存儲單元的地址，第二次是在存儲單元中查找鍵 值。所以，若是Nginx給出須要增大hash max size 或 hash bucket size的提示，那麼首要的是增大前一個參數的大小.
 
client_header_buffer_size 4k;
客戶端請求頭部的緩衝區大小。這個能夠根據你的系統分頁大小來設置，通常一個請求的頭部大小不會超過1k，不過因爲通常系統分頁都要大於1k，因此這裏設置爲分頁大小。分頁大小能夠用命令getconf PAGESIZE取得。
 
large_client_header_buffers 8 128k;
客戶請求頭緩衝大小。nginx默認會用client_header_buffer_size這個buffer來讀取header值，若是
header過大，它會使用large_client_header_buffers來讀取。
 
open_file_cache max=102400 inactive=20s;
這個指令指定緩存是否啓用。
例: open_file_cache max=1000 inactive=20s; 
open_file_cache_valid 30s; 
open_file_cache_min_uses 2; 
open_file_cache_errors on;
 
open_file_cache_errors
語法:open_file_cache_errors on | off 默認值:open_file_cache_errors off 使用字段:http, server, location 這個指令指定是否在搜索一個文件是記錄cache錯誤.
open_file_cache_min_uses
語法:open_file_cache_min_uses number 默認值:open_file_cache_min_uses 1 使用字段:http, server, location 這個指令指定了在open_file_cache指令無效的參數中必定的時間範圍內可使用的最小文件數,若是使用更大的值,文件描述符在cache中老是打開狀態.
open_file_cache_valid
語法:open_file_cache_valid time 默認值:open_file_cache_valid 60 使用字段:http, server, location 這個指令指定了什麼時候須要檢查open_file_cache中緩存項目的有效信息.
 
 
client_max_body_size 300m;
設定經過nginx上傳文件的大小
 
sendfile on;
sendfile指令指定 nginx 是否調用sendfile 函數（zero copy 方式）來輸出文件，對於普通應用，必須設爲on。若是用來進行下載等應用磁盤IO重負載應用，可設置爲off，以平衡磁盤與網絡IO處理速度，下降系統uptime。
 
tcp_nopush on;
此選項容許或禁止使用socke的TCP_CORK的選項，此選項僅在使用sendfile的時候使用
 
proxy_connect_timeout 90; 
後端服務器鏈接的超時時間_發起握手等候響應超時時間
 
proxy_read_timeout 180;
鏈接成功後_等候後端服務器響應時間_其實已經進入後端的排隊之中等候處理（也能夠說是後端服務器處理請求的時間）
 
proxy_send_timeout 180;
後端服務器數據回傳時間_就是在規定時間以內後端服務器必須傳完全部的數據
 
proxy_buffer_size 256k;
設置從被代理服務器讀取的第一部分應答的緩衝區大小，一般狀況下這部分應答中包含一個小的應答頭，默認狀況下這個值的大小爲指令proxy_buffers中指定的一個緩衝區的大小，不過能夠將其設置爲更小
 
proxy_buffers 4 256k;
設置用於讀取應答（來自被代理服務器）的緩衝區數目和大小，默認狀況也爲分頁大小，根據操做系統的不一樣多是4k或者8k
 
proxy_busy_buffers_size 256k;
 
proxy_temp_file_write_size 256k;
設置在寫入proxy_temp_path時數據的大小，預防一個工做進程在傳遞文件時阻塞太長
 
proxy_temp_path /data0/proxy_temp_dir;
proxy_temp_path和proxy_cache_path指定的路徑必須在同一分區

proxy_cache_path /data0/proxy_cache_dir levels=1:2 keys_zone=cache_one:200m inactive=1d max_size=30g;
#設置內存緩存空間大小爲200MB，1天沒有被訪問的內容自動清除，硬盤緩存空間大小爲30GB。
keepalive_timeout 120;
keepalive超時時間。
 
tcp_nodelay on;
 
client_body_buffer_size 512k;
若是把它設置爲比較大的數值，例如256k，那麼，不管使用firefox仍是IE瀏覽器，來提交任意小於256k的圖片，都很正常。若是註釋該指令，使用默認的client_body_buffer_size設置，也就是操做系統頁面大小的兩倍，8k或者16k，問題就出現了。
不管使用firefox4.0仍是IE8.0，提交一個比較大，200k左右的圖片，都返回500 Internal Server Error錯誤
 
proxy_intercept_errors on;
表示使nginx阻止HTTP應答代碼爲400或者更高的應答。
 
upstream bakend {
server 127.0.0.1:8027;
server 127.0.0.1:8028;
server 127.0.0.1:8029;
hash $request_uri;
}
nginx的upstream目前支持4種方式的分配
1、輪詢（默認）
每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端服務器down掉，能自動剔除。
2、weight
指定輪詢概率，weight和訪問比率成正比，用於後端服務器性能不均的狀況。
例如：
upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
2、ip_hash
每一個請求按訪問ip的hash結果分配，這樣每一個訪客固定訪問一個後端服務器，能夠解決session的問題。
例如：
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
3、fair（第三方）
按後端服務器的響應時間來分配請求，響應時間短的優先分配。
upstream backend {
server server1;
server server2;
fair;
}
4、url_hash（第三方）
按訪問url的hash結果來分配請求，使每一個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。
例：在upstream中加入hash語句，server語句中不能寫入weight等其餘的參數，hash_method是使用的hash算法
upstream backend {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
tips:
upstream bakend{#定義負載均衡設備的Ip及設備狀態}{
ip_hash;
server 127.0.0.1:9090 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6060;
server 127.0.0.1:7070 backup;
}
在須要使用負載均衡的server中增長
proxy_pass http://bakend/;
每一個設備的狀態設置爲:
1.down表示單前的server暫時不參與負載
2.weight爲weight越大，負載的權重就越大。
3.max_fails：容許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream模塊定義的錯誤
4.fail_timeout:max_fails次失敗後，暫停的時間。
5.backup： 其它全部的非backup機器down或者忙的時候，請求backup機器。因此這臺機器壓力會最輕。
nginx支持同時設置多組的負載均衡，用來給不用的server來使用。
client_body_in_file_only設置爲On 能夠講client post過來的數據記錄到文件中用來作debug
client_body_temp_path設置記錄文件的目錄 能夠設置最多3層目錄
location對URL進行匹配.能夠進行重定向或者進行新的代理 負載均衡
 
 
##配置虛擬機
server
{
listen 80;
配置監聽端口
 
server_name image.***.com;
配置訪問域名
 
location ~* \.(mp3|exe)$ {
對以「mp3或exe」結尾的地址進行負載均衡
 
proxy_pass http://img_relay$request_uri;
設置被代理服務器的端口或套接字，以及URL
 
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
以上三行，目的是將代理服務器收到的用戶的信息傳到真實服務器上
}
 
location /face {
if ($http_user_agent ~* "xnp") {
rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;
}
proxy_pass http://img_relay$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
error_page 404 502 = @fetch;
}
location @fetch {
access_log /data/logs/face.log log404;
rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;
}
location /image {
if ($http_user_agent ~* "xnp") {
rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;
}
proxy_pass http://img_relay$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
error_page 404 502 = @fetch;
}
location @fetch {
access_log /data/logs/image.log log404;
rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg redirect;
}
}

##其餘舉例
server
{
listen 80;
server_name *.***.com *.***.cn;
location ~* \.(mp3|exe)$ {
proxy_pass http://img_relay$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location / {
if ($http_user_agent ~* "xnp") {
rewrite ^(.*)$ http://i1.***img.com/help/noimg.gif redirect;
}
proxy_pass http://img_relay$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#error_page 404 http://i1.***img.com/help/noimg.gif;
error_page 404 502 = @fetch;
}
location @fetch {
access_log /data/logs/baijiaqi.log log404;
rewrite ^(.*)$ http://i1.***img.com/help/noimg.gif redirect;
}
}
server
{
listen 80;
server_name *.***img.com;
 
location ~* \.(mp3|exe)$ {
proxy_pass http://img_relay$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location / {
if ($http_user_agent ~* "xnp") {
rewrite ^(.*)$ http://i1.***img.com/help/noimg.gif;
}
proxy_pass http://img_relay$request_uri;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#error_page 404 http://i1.***img.com/help/noimg.gif;
error_page 404 = @fetch;
}
#access_log off;
location @fetch {
access_log /data/logs/baijiaqi.log log404;
rewrite ^(.*)$ http://i1.***img.com/help/noimg.gif redirect;
}
}
server
{
listen 8080;
server_name ngx-ha.***img.com;
location / {
stub_status on;
access_log off;
}
}
server {
listen 80;
server_name imgsrc1.***.net;
root html;
}

server {
listen 80;
server_name ***.com w.***.com;
# access_log /usr/local/nginx/logs/access_log main;
location / {
rewrite ^(.*)$ http://www.***.com/ ;
}
}
server {
listen 80;
server_name *******.com w.*******.com;
# access_log /usr/local/nginx/logs/access_log main;
location / {
rewrite ^(.*)$ http://www.*******.com/;
}
}
server {
listen 80;
server_name ******.com;
# access_log /usr/local/nginx/logs/access_log main;
location / {
rewrite ^(.*)$ http://www.******.com/;
}
}
location /NginxStatus {
stub_status on;
access_log on;
auth_basic "NginxStatus";
auth_basic_user_file conf/htpasswd;
}
#設定查看Nginx狀態的地址
 
location ~ /\.ht {
deny all;
}
#禁止訪問.htxxx文件
}
 
註釋：變量
Ngx_http_core_module模塊支持內置變量，他們的名字和apache的內置變量是一致的。
首先是說明客戶請求title中的行，例如$http_user_agent,$http_cookie等等。
此外還有其它的一些變量
$args此變量與請求行中的參數相等
$content_length等於請求行的「Content_Length」的值。
$content_type等同與請求頭部的」Content_Type」的值
$document_root等同於當前請求的root指令指定的值
$document_uri與$uri同樣
$host與請求頭部中「Host」行指定的值或是request到達的server的名字（沒有Host行）同樣
$limit_rate容許限制的鏈接速率
$request_method等同於request的method，一般是「GET」或「POST」
$remote_addr客戶端ip
$remote_port客戶端port
$remote_user等同於用戶名，由ngx_http_auth_basic_module認證
$request_filename當前請求的文件的路徑名，由root或alias和URI request組合而成
$request_body_file
$request_uri含有參數的完整的初始URI
$query_string與$args同樣
$sheeme http模式（http,https）盡在要求是評估例如
Rewrite ^(.+)$ $sheme://example.com$; Redirect;
$server_protocol等同於request的協議，使用「HTTP/或「HTTP/
$server_addr request到達的server的ip，通常得到此變量的值的目的是進行系統調用。爲了不繫統調用，有必要在listen指令中指明ip，並使用bind參數。
$server_name請求到達的服務器名
$server_port請求到達的服務器的端口號
$uri等同於當前request中的URI，可不一樣於初始值，例如內部重定向時或使用index