配置 Nginx
配置文件語法
配置文件一般是一個文本文件，可以被管理員編輯，可以被程序解析。通過指定一組值，你定義了程序的行為，基於Linux的操作系統，大部分的應用程序都是基於一個大的、複雜的配置文件，這往往變成是一個惡夢般的管理。Apache, PHP, MySQL, Qmail和Bind——所有這些名字帶來了不好的回憶，但是，沒辦法，所有這些應用程序都有自己的配置文件，並且各有自己的語法和格式已成為一個事實。PHP使用了Windows格式的.ini文件，sendmail使用M4宏處理器來編譯配置文件，Zabbix能夠從MySQL資料庫抽取配置，等等。遺憾的是，沒有建立一個標準！同樣，你將要使用的應用程序Nginx，你需要學習它的新語法，它又有新的特點，有自己的辭彙。
另一方面(這是它的優勢之一)，配置Nginx原來是如此的簡單，相比之下，至少比Apache或者其它主流的web伺服器簡單，僅需要掌握一些機制——指令、blocks和整體邏輯結構，實際配置過程中，大部分將是為指令填寫值。
配置指令
Nginx的配置文件被描述為一個具有一定邏輯結構的一組指令列表。應用程序的整個行為通過你去修改這些指令的值就實現了。
默認情況下，Nginx使用了一個主要的配置文件，該文件定義的步驟在第二章中有描述，下載和安裝在建立配置章節，如果你沒有編輯配置文件的路徑和prefix選項，那麼配置文件在你系統中的位置應該是「/usr/local/nginx/conf/nginx.conf」。現在讓我們快速的看一下最前面的幾行。
仔細看看，第首先的兩行：
#user nobody;
worker_processes 1;
正如你理解的，字元「#」 作用，第一行就是個註釋行，換句話說，就是一塊不被解釋的文本，而不管該指令是否有值，其唯一目的是要通過誰打開文件讀取。你可以在一行的開始使用「#」號，也可以在「#」之後跟隨指令。
第二行是一個實際的聲明——一條指令，第一位(worker_processes)是一個設置鍵，你可以附加一個或多個參數，在這裡，參數是 1 ，它標誌著Nginx作為單個worker進程(關於該指令更多的功能介紹會在後面的章節中說明)。
指令總是以分號結尾(';').
每一條指令都有它特別的功能，Nginx就是通過定義這些指令來實現特定的功能。另外，每個指令也有不通的語法，例如，指令worker_process只接受一個數字值，而指令user會讓你指定兩個字元串值——一個是用戶賬戶(Nginx的worker進程會使用該用戶運行)，第二個是用戶組。
Nginx通過模塊的方法來構建，因此，每一個模塊都會提供一組指令。最根本的指令是Nginx核心模塊部分，將會在本章詳細介紹。至於其它模塊所帶來的其它指令，我們將在後面的章節進行探討。
組織和包含
在前面的截圖中，你肯能已經注意到一個特別的指令——include：
include mime.types;
顧名思義，該指令就是用來執行一個對特定文件的包含，換句話說，該文件的內容將被插入到這個確定(確切)的位置。這裡有一個實際的例子，以便幫助我們去理解：
nginx.conf:
user nginx nginx;
worker_processes 4;
include other_settings.conf;
other_settings.conf:
error_log logs/error.log;
pid logs/nginx.pid;
以下是Nginx解釋配置文件的最終結果：
user nginx nginx;
worker_processes 4;
error_log logs/error.log;
pid logs/nginx.pid;
在上面例子中包括了遞歸處理，在這種情況下，你有使用了include指令，在主配置文件中通過該指令將文件other_settings.conf包括了進來，而在該文件中又包含其它的文件。
在最初的配置文件設置中，有兩個文件被使用——nginx.conf和mime.type。然而，對於高級配置來說，這少有五個文件，描述如下：
標準名字 描 述
nginx.conf 應用程序的基本配置文件
mime.types 一個文件擴展列表文件，它們與MIME類型關聯
fastcgi.conf 與FastCGI相關的配置文件
proxy.conf 與Proxy相關的配置文件
sites.conf 配置Nginx提供的web站點，也包括眾所周知的虛擬主機。
推薦每一個域建立一個單獨的文件。
這些文件名是按照慣例來定義的，實際上，沒有任何事去阻止你使用其它的文件名，例如，你可以將FastCGI和Proxy重新組合到有一個普通的文件中，文件名可以叫做proxy_and_fastcgi_config.conf
注意，include指令支持文件名替換，換句話說，使用「*」的文件名，這裡的*可以匹配零個、一個或者是多個連續的字元：
include sites/*.conf;
這將會包含sites目錄下所有以.conf結尾的文件，這種機制允許你去為你的每一個web站點建立一個單獨的文件，然後就像使用上面的指令一樣，通過一條指令就可以一次全部包括進來。
在包含一個文件的時候要仔細點——如果指定的文件不存在，那麼配置檢測就會失敗，Nginx也就不會再啟動了：
# ./nginx -t
: open() "/usr/local/nginx/conf/dummyfile.conf" failed (2: No such file or directory) in /usr/local/nginx/conf/nginx.conf:48
很明顯，先前的配置不為真，由於包含的通配符包含了不存的文件
然後，如果你在你的配置文件插入「include dummy*.conf」，然後再測試它(看一下這種格式在你的系統上是否有配置)，看一下會有什麼情況發生：
# ./nginx –t
the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
configuration file /usr/local/nginx/conf/nginx.conf test is successful
指令塊(blocks)
指令是由模塊提供的——如果你激活一個新模塊，那麼會有一組特定的指令變為有效。模塊也可以使得指令塊(block，區段。在本書的翻譯中，「塊」和「區段」混合使用，有的時候覺得「塊」合適，而有時有覺的是「區段」合適，但表達的是同一個內容)可用，例如，下列是配置文件中的一個邏輯框架。
events {
worker_connections 1024;
}
這個events區段(block)，你可以在默認的配置文件中找到，它來自於由Events模塊，該模塊提供的在指令也只能在該block下使用，例如上面處理的那個例子中, worker_connections只能放置在events區段才有意義。然後有一個重要的例外——一些文件可以放置在配置文件的根本(最開始的部分)，因為它可以給伺服器一個全局的效果。配置文件的根部也就被認為是主要的block。
本章將詳述核心模塊中的塊和指令，模塊為伺服器的順利運作所需。可選模塊(它們在默認情況下是否啟用)將在後面的章節中討論。
注意，在某些情況下，blocks能夠互相嵌套，下面是一個特定的邏輯：
http {
server {
listen 80;
server_name example.com;
access_log /var/log/nginx/example.com.log;
location ^~ /admin/ {
index index.php;
}
}
}
這個例子展示了如何在web站點配置Nginx，這樣你能夠辨別出http區段(而不是，比如說，imap，如果你想利用郵件伺服器的代理功能使用)。
在這個http區段，你可以聲明一個或多個server區段，一個server區段允許你配置一個虛擬主機。在這個例子中，server區段包含了一些配置，這些設置會通過一個主機HTTP頭(Host HTTP header)應用到所有的請求中，用來正確的配置example.com。
在這個server區段內，你可以插入一個或多個location區段，當你需要對特定的路徑進行URI匹配時，這些location區段允許你對這些路徑單獨設置。更多的信息會在第4章提供，在配置Location區段章節。
最後但並非最不重要的，配置的繼承，在一個區段中嵌套了其它的區段，那麼被嵌套的區段會繼承其父區段的設置。access_log指令(在這個例子中，在server區段級別定義了)指定了對於這個伺服器所有的HTTP請求都會記錄在這個文本文件中，
這個條件在location子區段任然成立，但是你可以重新設置access_log指令來禁用這個繼承：
[…]
location ^~ /admin/ {
index index.php;
access_log off;
}
[…]
這樣，日誌除了不能夠記錄 /admin/ 外，它仍可以記錄該站點所有的訪問日誌。對access_log設置的值，在server級別的區段設置的值將會被在location級別的區段設置的值所覆蓋。
高級語言規則
一些重要的資料，這些被看做是Nginx配置文件的語法，它們將幫助你理解某些語法規則，如果你以前沒有在Nginx下工作過，那麼你會覺得難以理解。
接受指令的特有語法
對於偶然發現的這種複雜語法咋看一下可能會難以理解：
rewrite ^/(.*)\.(png|jpg|gif)$ /image.php? file=$1&format=$2 last;
語法詳細的指導了指令的用法。Listen指令只能夠接受一個埠號，來打開一個監聽套接字，location塊或rewrite指令支持複雜的表達式，是為了配置特殊模式。所有這些語法，都將會在各自的章節中通過具體的指令一同解釋。
在後面我們將會學習一個模塊(那就是Rewrite模塊)，它允許你將更加高級的邏輯結構，通過使用if, set, break和return指令以及使用各種變數來處理一個選擇。通過這些新的元素，配置文件開始變得就像編程腳本一樣。不管怎麼說，我們認識的模塊越多，語法也就會變的越豐富。
指令值的單位
最後，你可以使用下列單位，來指定配置文件中所在的環境中所使用的指令值的單位。
k 或 K: 千位元組
m 或 M: 兆位元組
因此，下列的兩個語法是正確的，也是相等的：
client_max_body_size 2M;
client_max_body_size 2048k;
下面是可以指定的時間值，你可以使用下列的縮寫形式：
ms: Milliseconds(毫秒)
s: Seconds(秒)
m: Minutes(分鐘)
h: Hours(小時)
d: Days(天)
w: Weeks(星期)
M: Months (30 days)(月)
y: Years (365 days)(年)
在用一個時間段作為指示值的情況，這將變得特別有用：
client_body_timeout 3m;
client_body_timeout 180s;
client_body_timeout 180;
注意默認的時間單位是秒，在上面的例子中，因此最後兩行的結果一樣。
變數
模塊提供了各種變數，變數被用於指定變數值，例如，Nginx的HTTP核心模塊定義了$nginx_version變數。
在設置log_format指令時，在下列的格式中，你可以包含各種各樣的變數：
[…]
location ^~ /admin/ {
access_log logs/main.log;
log_format main '$pid - $nginx_version - $remote_addr';
}
[…]
注意，一些指令不允許你使用任何變數：
error_log logs/error-$nginx_version.log;
這是一個有效的配置指令，然而，它只會簡單的產生一個名字為「error-$nginx_version.log」的文件，而不會解析改變數。
字元串值
將字元串用作指令值，可以有三種格式，首先，你可以沒有引號的形式：
root /home/example.com/www;
然而，如果你子昂使用一個特殊的字元，例如空格符(" ")，分號(;)或者是花括弧({ })，那麼你就需要使用單引號或者是雙引號：
root '/home/example.com/my web pages';
無論使用單引號或雙引號，Nginx會認為沒有什麼區別。
《解決方案》
膜拜一下！！！！！:em03:
