靜态web伺服器的主要功能由ngx_http_core_module子產品（http架構的主要成員）實作，當然，一個完整的靜态web伺服器還有許多功能是由其他的http子產品實作的。本節主要讨論如何配置一個包含基本功能的靜态web伺服器，文中會完整地說明ngx_http_core_module子產品提供的配置項及變量的用法，但不會過多說明其他http子產品的配置項。在閱讀完本節内容後，讀者應當可以通過簡單的查詢相關子產品（如ngx_http_gzip_filter_module、ngx_http_image_filter_module等）的配置項說明，友善地在nginx.conf配置檔案中加入新的配置項，進而實作更多的web伺服器功能。
除了2.3節提到的基本配置項外，一個典型的靜态web伺服器還會包含多個server塊和location塊，例如：
所有的http配置項都必須直屬于http塊、server塊、location塊、upstream塊或if塊等（http配置項自然必須全部在http{}塊之内，這裡的“直屬于”是指配置項直接所屬的大括号對應的配置塊），同時，在描述每個配置項的功能時，會說明它可以在上述的哪個塊中存在，因為有些配置項可以任意地出現在某一個塊中，而有些配置項隻能出現在特定的塊中，在第4章介紹自定義配置項的讀取時，相信讀者就會體會到這種設計思路。
nginx為配置一個完整的靜态web伺服器提供了非常多的功能，下面會把這些配置項分為以下8類進行詳述：虛拟主機與請求的分發、檔案路徑的定義、記憶體及磁盤資源的配置設定、網絡連接配接的設定、mime類型的設定、對用戶端請求的限制、檔案操作的優化、對用戶端請求的特殊處理。這種劃分隻是為了幫助大家從功能上了解這些配置項。
在這之後會列出ngx_http_core_module子產品提供的變量，以及簡單說明它們的意義。
由于ip位址的數量有限，是以經常存在多個主機域名對應着同一個ip位址的情況，這時在nginx.conf中就可以按照server_name（對應使用者請求中的主機域名）并通過server塊來定義虛拟主機，每個server塊就是一個虛拟主機，它隻處理與之相對應的主機域名請求。這樣，一台伺服器上的nginx就能以不同的方式處理通路不同主機域名的http請求了。
（1）監聽端口
文法：listen address:port [ default(deprecated in 0.8.21) | default_server | [ backlog=num | rcvbuf=size | sndbuf=size | accept_filter=filter | deferred | bind | ipv6only=[on|off] | ssl ] ];
預設：listen 80;
配置塊：server
listen參數決定nginx服務如何監聽端口。在listen後可以隻加ip位址、端口或主機名，非常靈活，例如：
如果伺服器使用ipv6位址，那麼可以這樣使用：
在位址和端口後，還可以加上其他參數，例如：
下面說明listen可用參數的意義。
default：将所在的server塊作為整個web服務的預設server塊。如果沒有設定這個參數，那麼将會以在nginx.conf中找到的第一個server塊作為預設server塊。為什麼需要預設虛拟主機呢？當一個請求無法比對配置檔案中的所有主機域名時，就會選用預設的虛拟主機（在11.3節介紹預設主機的使用）。
default_server：同上。
backlog=num：表示tcp中backlog隊列的大小。預設為–1，表示不予設定。在tcp建立三次握手過程中，程序還沒有開始處理監聽句柄，這時backlog隊列将會放置這些新連接配接。可如果backlog隊列已滿，還有新的用戶端試圖通過三次握手建立tcp連接配接，這時用戶端将會建立連接配接失敗。
rcvbuf=size：設定監聽句柄的so_rcvbuf參數。
sndbuf=size：設定監聽句柄的so_sndbuf 參數。
accept_filter：設定accept過濾器，隻對freebsd作業系統有用。
deferred：在設定該參數後，若使用者發起建立連接配接請求，并且完成了tcp的三次握手，核心也不會為了這次的連接配接排程worker程序來處理，隻有使用者真的發送請求資料時（核心已經在網卡中收到請求資料包），核心才會喚醒worker程序處理這個連接配接。這個參數适用于大并發的情況下，它減輕了worker程序的負擔。當請求資料來臨時，worker程序才會開始處理這個連接配接。隻有确認上面所說的應用場景符合自己的業務需求時，才可以使用deferred配置。
bind：綁定目前端口/位址對，如127.0.0.1:8000。隻有同時對一個端口監聽多個位址時才會生效。
ssl：在目前監聽的端口上建立的連接配接必須基于ssl協定。
（2）主機名稱
文法：server_name name [...];
預設：server_name "";
server_name後可以跟多個主機名稱，如server_name www.testweb.com、download.testweb.com;。
在開始處理一個http請求時，nginx會取出header頭中的host，與每個server中的server_name進行比對，以此決定到底由哪一個server塊來處理這個請求。有可能一個host與多個server塊中的server_name都比對，這時就會根據比對優先級來選擇實際處理的server塊。server_name與host的比對優先級如下：
1）首先選擇所有字元串完全比對的server_name，如www.testweb.com。
2）其次選擇通配符在前面的server_name，如*.testweb.com。
3）再次選擇通配符在後面的server_name，如www.testweb.*。
4）最後選擇使用正規表達式才比對的server_name，如~^.testweb.com$。
實際上，這個規則正是7.7節中介紹的帶通配符散清單的實作依據，同時，在10.4節也介紹了虛拟主機配置的管理。如果host與所有的server_name都不比對，這時将會按下列順序選擇處理的server塊。
1）優先選擇在listen配置項後加入[default | default_server]的server塊。
2）找到比對listen端口的第一個server塊。
如果server_name後跟着空字元串（如server_name "";），那麼表示比對沒有host這個http頭部的請求。
注意 nginx正是使用server_name配置項針對特定host域名的請求提供不同的服務，以此實作虛拟主機功能。
（3）server_names_hash_bucket_size
文法：server_names _hash_bucket_size size;
預設：server_names _hash_bucket_size 32|64|128;
配置塊：http、server、location
為了提高快速尋找到相應server name的能力，nginx使用散清單來存儲server name。server_names _hash_bucket_size設定了每個散列桶占用的記憶體大小。
（4）server_names _hash_max_size
文法：server_names _hash_max_size size;
預設：server_names _hash_max_size 512;
server_names _hash_max_size會影響散清單的沖突率。server_names _hash_max_size越大，消耗的記憶體就越多，但散列key的沖突率則會降低，檢索速度也更快。server_names _hash_max_size越小，消耗的記憶體就越小，但散列key的沖突率可能增高。
（5）重定向主機名稱的處理
文法：server_name_in_redirect on | off;
預設：server_name_in_redirect on;
配置塊：http、server或者location
該配置需要配合server_name使用。在使用on打開時，表示在重定向請求時會使用server_name裡配置的第一個主機名代替原先請求中的host頭部，而使用off關閉時，表示在重定向請求時使用請求本身的host頭部。
（6）location
文法：location [=|~|~*|^~|@] /uri/ { ... }
location會嘗試根據使用者請求中的uri來比對上面的/uri表達式，如果可以比對，就選擇location {}塊中的配置來處理使用者請求。當然，比對方式是多樣的，下面介紹location的比對規則。
1）= 表示把uri作為字元串，以便與參數中的uri做完全比對。例如：
2）~表示比對uri時是字母大小寫敏感的。
3）~*表示比對uri時忽略字母大小寫問題。
4）^~表示比對uri時隻需要其前半部分與uri參數比對即可。例如：
5）@表示僅用于nginx服務内部請求之間的重定向，帶有@的location不直接處理使用者請求。
當然，在uri參數裡是可以用正規表達式的，例如：
注意，location是有順序的，當一個請求有可能比對多個location時，實際上這個請求會被第一個location處理。
在以上各種比對方式中，都隻能表達為“如果比對...則...”。如果需要表達“如果不比對...則...”，就很難直接做到。有一種解決方法是在最後一個location中使用/作為參數，它會比對所有的http請求，這樣就可以表示如果不能比對前面的所有location，則由“/”這個location處理。例如：
下面介紹一下檔案路徑的定義配置項。
（1）以root方式設定資源路徑
文法：root path;
預設：root html;
配置塊：http、server、location、if
例如，定義資源檔案相對于http請求的根目錄。
在上面的配置中，如果有一個請求的uri是/download/index/test.html，那麼web伺服器将會傳回伺服器上/opt/web/html/download/index/test.html檔案的内容。
（2）以alias方式設定資源路徑
文法：alias path;
配置塊：location
alias也是用來設定檔案資源路徑的，它與root的不同點主要在于如何解讀緊跟location後面的uri參數，這将會緻使alias與root以不同的方式将使用者請求映射到真正的磁盤檔案上。例如，如果有一個請求的uri是/conf/nginx.conf，而使用者實際想通路的檔案在/usr/local/nginx/conf/nginx.conf，那麼想要使用alias來進行設定的話，可以采用如下方式：
如果用root設定，那麼語句如下所示：
使用alias時，在uri向實際檔案路徑的映射過程中，已經把location後配置的/conf這部分字元串丢棄掉，是以，/conf/nginx.conf請求将根據alias path映射為path/nginx.conf。root則不然，它會根據完整的uri請求來映射，是以，/conf/nginx.conf請求會根據root path映射為path/conf/nginx.conf。這也是root可以放置到http、server、location或if塊中，而alias隻能放置到location塊中的原因。
alias後面還可以添加正規表達式，例如：
這樣，請求在通路/test/nginx.conf時，nginx會傳回/usr/local/nginx/conf/nginx.conf檔案中的内容。
（3）通路首頁
文法：index file ...;
預設：index index.html;
有時，通路站點時的uri是/，這時一般是傳回網站的首頁，而這與root和alias都不同。這裡用ngx_http_index_module子產品提供的index配置實作。index後可以跟多個檔案參數，nginx将會按照順序來通路這些檔案，例如：
接收到請求後，nginx首先會嘗試通路path/index.php檔案，如果可以通路，就直接傳回檔案内容結束請求，否則再試圖傳回path/html/index.php檔案的内容，依此類推。
（4）根據http傳回碼重定向頁面
文法：error_page code [ code... ] [ = | =answer-code ] uri | @named_location
當對于某個請求傳回錯誤碼時，如果比對上了error_page中設定的code，則重定向到新的uri中。例如：
注意，雖然重定向了uri，但傳回的http錯誤碼還是與原來的相同。使用者可以通過“=”來更改傳回的錯誤碼，例如：
也可以不指定确切的傳回錯誤碼，而是由重定向後實際處理的真實結果來決定，這時，隻要把“=”後面的錯誤碼去掉即可，例如：
如果不想修改uri，隻是想讓這樣的請求重定向到另一個location中進行處理，那麼可以這樣設定：
（5）是否允許遞歸使用error_page
文法：recursive_error_pages [on | off];
預設：recursive_error_pages off;
确定是否允許遞歸地定義error_page。
（6）try_files
文法：try_files path1 [path2] uri;
配置塊：server、location
try_files後要跟若幹路徑，如path1 path2...，而且最後必須要有uri參數，意義如下：嘗試按照順序通路每一個path，如果可以有效地讀取，就直接向使用者傳回這個path對應的檔案結束請求，否則繼續向下通路。如果所有的path都找不到有效的檔案，就重定向到最後的參數uri上。是以，最後這個參數uri必須存在，而且它應該是可以有效重定向的。例如：
下面介紹處理請求時記憶體、磁盤資源配置設定的配置項。
（1）http包體隻存儲到磁盤檔案中
文法：client_body_in_file_only on | clean | off;
預設：client_body_in_file_only off;
當值為非off時，使用者請求中的http包體一律存儲到磁盤檔案中，即使隻有0位元組也會存儲為檔案。當請求結束時，如果配置為on，則這個檔案不會被删除（該配置一般用于調試、定位問題），但如果配置為clean，則會删除該檔案。
（2）http包體盡量寫入到一個記憶體buffer中
文法：client_body_in_single_buffer on | off;
預設：client_body_in_single_buffer off;
使用者請求中的http包體一律存儲到記憶體buffer中。當然，如果http包體的大小超過了下面client_body_buffer_size設定的值，包體還是會寫入到磁盤檔案中。
（3）存儲http頭部的記憶體buffer大小
文法：client_header_buffer_size size;
預設：client_header_buffer_size 1k;
配置塊：http、server
上面配置項定義了正常情況下nginx接收使用者請求中http header部分（包括http行和http頭部）時配置設定的記憶體buffer大小。有時，請求中的http header部分可能會超過這個大小，這時large_client_header_buffers定義的buffer将會生效。
（4）存儲超大http頭部的記憶體buffer大小
文法：large_client_header_buffers number size;
預設：large_client_header_buffers 4 8k;
large_client_header_buffers定義了nginx接收一個超大http頭部請求的buffer個數和每個buffer的大小。如果http請求行（如get /index http/1.1）的大小超過上面的單個buffer，則傳回"request uri too large" (414)。請求中一般會有許多header，每一個header的大小也不能超過單個buffer的大小，否則會傳回"bad request" (400)。當然，請求行和請求頭部的總和也不可以超過buffer個數*buffer大小。
（5）存儲http包體的記憶體buffer大小
文法：client_body_buffer_size size;
預設：client_body_buffer_size 8k/16k;
上面配置項定義了nginx接收http包體的記憶體緩沖區大小。也就是說，http包體會先接收到指定的這塊緩存中，之後才決定是否寫入磁盤。
注意 如果使用者請求中含有http頭部content-length，并且其辨別的長度小于定義的buffer大小，那麼nginx會自動降低本次請求所使用的記憶體buffer，以降低記憶體消耗。
（6）http包體的臨時存放目錄
文法：client_body_temp_path dir-path [ level1 [ level2 [ level3 ]]]
預設：client_body_temp_path client_body_temp;
上面配置項定義http包體存放的臨時目錄。在接收http包體時，如果包體的大小大于client_body_buffer_size，則會以一個遞增的整數命名并存放到client_body_temp_path指定的目錄中。後面跟着的level1、level2、level3，是為了防止一個目錄下的檔案數量太多，進而導緻性能下降，是以使用了level參數，這樣可以按照臨時檔案名最多再加三層目錄。例如：
client_body_temp_path /opt/nginx/client_temp 1 2;
如果新上傳的http 包體使用00000123456作為臨時檔案名，就會被存放在這個目錄中。
（7）connection_pool_size
文法：connection_pool_size size;
預設：connection_pool_size 256;
nginx對于每個建立成功的tcp連接配接會預先配置設定一個記憶體池，上面的size配置項将指定這個記憶體池的初始大小（即ngx_connection_t結構體中的pool記憶體池初始大小，9.8.1節将介紹這個記憶體池是何時配置設定的），用于減少核心對于小塊記憶體的配置設定次數。需慎重設定，因為更大的size會使伺服器消耗的記憶體增多，而更小的size則會引發更多的記憶體配置設定次數。
（8）request_pool_size
文法：request_pool_size size;
預設：request_pool_size 4k;
nginx開始處理http請求時，将會為每個請求都配置設定一個記憶體池，size配置項将指定這個記憶體池的初始大小（即ngx_http_request_t結構體中的pool記憶體池初始大小，11.3節将介紹這個記憶體池是何時配置設定的），用于減少核心對于小塊記憶體的配置設定次數。tcp連接配接關閉時會銷毀connection_pool_size指定的連接配接記憶體池，http請求結束時會銷毀request_pool_size指定的http請求記憶體池，但它們的建立、銷毀時間并不一緻，因為一個tcp連接配接可能被複用于多個http請求。
下面介紹網絡連接配接的設定配置項。
（1）讀取http頭部的逾時時間
文法：client_header_timeout time（預設機關：秒）;
預設：client_header_timeout 60;
用戶端與伺服器建立連接配接後将開始接收http頭部，在這個過程中，如果在一個時間間隔（逾時時間）内沒有讀取到用戶端發來的位元組，則認為逾時，并向用戶端傳回408 ("request timed out")響應。
（2）讀取http包體的逾時時間
文法：client_body_timeout time（預設機關：秒）；
預設：client_body_timeout 60;
此配置項與client_header_timeout相似，隻是這個逾時時間隻在讀取http包體時才有效。
（3）發送響應的逾時時間
文法：send_timeout time;
預設：send_timeout 60;
這個逾時時間是發送響應的逾時時間，即nginx伺服器向用戶端發送了資料包，但用戶端一直沒有去接收這個資料包。如果某個連接配接超過send_timeout定義的逾時時間，那麼nginx将會關閉這個連接配接。
（4）reset_timeout_connection
文法：reset_timeout_connection on | off;
預設：reset_timeout_connection off;
連接配接逾時後将通過向用戶端發送rst包來直接重置連接配接。這個選項打開後，nginx會在某個連接配接逾時後，不是使用正常情形下的四次握手關閉tcp連接配接，而是直接向使用者發送rst重置包，不再等待使用者的應答，直接釋放nginx伺服器上關于這個套接字使用的所有緩存（如tcp滑動視窗）。相比正常的關閉方式，它使得伺服器避免産生許多處于fin_wait_1、fin_wait_2、time_wait狀态的tcp連接配接。
注意，使用rst重置包關閉連接配接會帶來一些問題，預設情況下不會開啟。
（5）lingering_close
文法：lingering_close off | on | always;
預設：lingering_close on;
該配置控制nginx關閉使用者連接配接的方式。always表示關閉使用者連接配接前必須無條件地處理連接配接上所有使用者發送的資料。off表示關閉連接配接時完全不管連接配接上是否已經有準備就緒的來自使用者的資料。on是中間值，一般情況下在關閉連接配接前都會處理連接配接上的使用者發送的資料，除了有些情況下在業務上認定這之後的資料是不必要的。
（6）lingering_time
文法：lingering_time time;
預設：lingering_time 30s;
lingering_close啟用後，這個配置項對于上傳大檔案很有用。上文講過，當使用者請求的content-length大于max_client_body_size配置時，nginx服務會立刻向使用者發送413（request entity too large）響應。但是，很多用戶端可能不管413傳回值，仍然持續不斷地上傳http body，這時，經過了lingering_time設定的時間後，nginx将不管使用者是否仍在上傳，都會把連接配接關閉掉。
（7）lingering_timeout
文法：lingering_timeout time;
預設：lingering_timeout 5s;
lingering_close生效後，在關閉連接配接前，會檢測是否有使用者發送的資料到達伺服器，如果超過lingering_timeout時間後還沒有資料可讀，就直接關閉連接配接；否則，必須在讀取完連接配接緩沖區上的資料并丢棄掉後才會關閉連接配接。
（8）對某些浏覽器禁用keepalive功能
文法：keepalive_disable [ msie6 | safari | none ]...
預設：keepalive_disable msie6 safari
http請求中的keepalive功能是為了讓多個請求複用一個http長連接配接，這個功能對伺服器的性能提高是很有幫助的。但有些浏覽器，如ie 6和safari，它們對于使用keepalive功能的post請求處理有功能性問題。是以，針對ie 6及其早期版本、safari浏覽器預設是禁用keepalive功能的。
（9）keepalive逾時時間
文法：keepalive_timeout time（預設機關：秒）;
預設：keepalive_timeout 75;
一個keepalive 連接配接在閑置超過一定時間後（預設的是75秒），伺服器和浏覽器都會去關閉這個連接配接。當然，keepalive_timeout配置項是用來限制nginx伺服器的，nginx也會按照規範把這個時間傳給浏覽器，但每個浏覽器對待keepalive的政策有可能是不同的。
（10）一個keepalive長連接配接上允許承載的請求最大數
文法：keepalive_requests n;
預設：keepalive_requests 100;
一個keepalive連接配接上預設最多隻能發送100個請求。
（11）tcp_nodelay
文法：tcp_nodelay on | off;
預設：tcp_nodelay on;
确定對keepalive連接配接是否使用tcp_nodelay選項。
（12）tcp_nopush
文法：tcp_nopush on | off;
預設：tcp_nopush off;
在打開sendfile選項時，确定是否開啟freebsd系統上的tcp_nopush或linux系統上的tcp_cork功能。打開tcp_nopush後，将會在發送響應時把整個響應標頭放到一個tcp包中發送。
2.4.5 mime類型的設定
下面是mime類型的設定配置項。
mime type與檔案擴充的映射
文法：type {...};
定義mime type到檔案擴充名的映射。多個擴充名可以映射到同一個mime type。例如：
預設mime type
文法：default_type mime-type;
預設：default_type text/plain;
當找不到相應的mime type與檔案擴充名之間的映射時，使用預設的mime type作為http header中的content-type。
types_hash_bucket_size
文法：types_hash_bucket_size size;
預設：types_hash_bucket_size 32|64|128;
為了快速尋找到相應mime type，nginx使用散清單來存儲mime type與檔案擴充名。types_hash_bucket_size 設定了每個散列桶占用的記憶體大小。
types_hash_max_size
文法：types_hash_max_size size;
預設：types_hash_max_size 1024;
types_hash_max_size影響散清單的沖突率。types_hash_max_size越大，就會消耗更多的記憶體，但散列key的沖突率會降低，檢索速度就更快。types_hash_max_size越小，消耗的記憶體就越小，但散列key的沖突率可能上升。
下面介紹對用戶端請求的限制的配置項。
（1）按http方法名限制使用者請求
文法：limit_except method ... {...}
nginx通過limit_except後面指定的方法名來限制使用者請求。方法名可取值包括：get、head、post、put、delete、mkcol、copy、move、options、propfind、proppatch、lock、unlock或者patch。例如：
注意，允許get方法就意味着也允許head方法。是以，上面這段代碼表示的是禁止get方法和head方法，但其他http方法是允許的。
（2）http請求包體的最大值
文法：client_max_body_size size;
預設：client_max_body_size 1m;
浏覽器在發送含有較大http包體的請求時，其頭部會有一個content-length字段，client_max_body_size是用來限制content-length所示值的大小的。是以，這個限制包體的配置非常有用處，因為不用等nginx接收完所有的http包體—這有可能消耗很長時間—就可以告訴使用者請求過大不被接受。例如，使用者試圖上傳一個10gb的檔案，nginx在收完標頭後，發現content-length超過client_max_body_size定義的值，就直接發送413 ("request entity too large")響應給用戶端。
（3）對請求的限速
文法：limit_rate speed;
預設：limit_rate 0;
此配置是對用戶端請求限制每秒傳輸的位元組數。speed可以使用2.2.4節中提到的多種機關，預設參數為0，表示不限速。
針對不同的用戶端，可以用$ limit_rate參數執行不同的限速政策。例如：
（4）limit_rate_after
文法：limit_rate_after time;
預設：limit_rate_after 1m;
此配置表示nginx向用戶端發送的響應長度超過limit_rate_after後才開始限速。例如：
11.9.2節将從源碼上介紹limit_rate_after與limit_rate的差別，以及http架構是如何使用它們來限制發送響應速度的。
下面介紹檔案操作的優化配置項。
（1）sendfile系統調用
文法：sendfile on | off;
預設：sendfile off;
可以啟用linux上的sendfile系統調用來發送檔案，它減少了核心态與使用者态之間的兩次記憶體複制，這樣就會從磁盤中讀取檔案後直接在核心态發送到網卡裝置，提高了發送檔案的效率。
（2）aio系統調用
文法：aio on | off;
預設：aio off;
此配置項表示是否在freebsd或linux系統上啟用核心級别的異步檔案i/o功能。注意，它與sendfile功能是互斥的。
（3）directio
文法：directio size | off;
預設：directio off;
此配置項在freebsd和linux系統上使用o_direct選項去讀取檔案，緩沖區大小為size，通常對大檔案的讀取速度有優化作用。注意，它與sendfile功能是互斥的。
（4）directio_alignment
文法：directio_alignment size;
預設：directio_alignment 512;
它與directio配合使用，指定以directio方式讀取檔案時的對齊方式。一般情況下，512b已經足夠了，但針對一些高性能檔案系統，如linux下的xfs檔案系統，可能需要設定到4kb作為對齊方式。
（5）打開檔案緩存
文法：open_file_cache max = n [inactive = time] | off;
預設：open_file_cache off;
檔案緩存會在記憶體中存儲以下3種資訊：
檔案句柄、檔案大小和上次修改時間。
已經打開過的目錄結構。
沒有找到的或者沒有權限操作的檔案資訊。
這樣，通過讀取緩存就減少了對磁盤的操作。
該配置項後面跟3種參數。
max：表示在記憶體中存儲元素的最大個數。當達到最大限制數量後，将采用lru（least recently used）算法從緩存中淘汰最近最少使用的元素。
inactive：表示在inactive指定的時間段内沒有被通路過的元素将會被淘汰。預設時間為60秒。
off：關閉緩存功能。
例如：
（6）是否緩存打開檔案錯誤的資訊
文法：open_file_cache_errors on | off;
預設：open_file_cache_errors off;
此配置項表示是否在檔案緩存中緩存打開檔案時出現的找不到路徑、沒有權限等錯誤資訊。
（7）不被淘汰的最小通路次數
文法：open_file_cache_min_uses number;
預設：open_file_cache_min_uses 1;
它與open_file_cache中的inactive參數配合使用。如果在inactive指定的時間段内，通路次數超過了open_file_cache_min_uses指定的最小次數，那麼将不會被淘汰出緩存。
（8）檢驗緩存中元素有效性的頻率
文法：open_file_cache_valid time;
預設：open_file_cache_valid 60s;
預設為每60秒檢查一次緩存中的元素是否仍有效。
下面介紹對用戶端請求的特殊處理的配置項。
（1）忽略不合法的http頭部
文法：ignore_invalid_headers on | off;
預設：ignore_invalid_headers on;
如果将其設定為off，那麼當出現不合法的http頭部時，nginx會拒絕服務，并直接向使用者發送400（bad request）錯誤。如果将其設定為on，則會忽略此http頭部。
（2）http頭部是否允許下畫線
文法：underscores_in_headers on | off;
預設：underscores_in_headers off;
預設為off，表示http頭部的名稱中不允許帶“_”（下畫線）。
（3）對if-modified-since頭部的處理政策
文法：if_modified_since [off|exact|before];
預設：if_modified_since exact;
出于性能考慮，web浏覽器一般會在用戶端本地緩存一些檔案，并存儲當時擷取的時間。這樣，下次向web伺服器擷取緩存過的資源時，就可以用if-modified-since頭部把上次擷取的時間捎帶上，而if_modified_since将根據後面的參數決定如何處理if-modified-since頭部。
相關參數說明如下。
off：表示忽略使用者請求中的if-modified-since頭部。這時，如果擷取一個檔案，那麼會正常地傳回檔案内容。http響應碼通常是200。
exact：将if-modified-since頭部包含的時間與将要傳回的檔案上次修改的時間做精确比較，如果沒有比對上，則傳回200和檔案的實際内容，如果比對上，則表示浏覽器緩存的檔案内容已經是最新的了，沒有必要再傳回檔案進而浪費時間與帶寬了，這時會傳回304 not modified，浏覽器收到後會直接讀取自己的本地緩存。
before：是比exact更寬松的比較。隻要檔案的上次修改時間等于或者早于使用者請求中的if-modified-since頭部的時間，就會向用戶端傳回304 not modified。
（4）檔案未找到時是否記錄到error日志
文法：log_not_found on | off;
預設：log_not_found on;
此配置項表示當處理使用者請求且需要通路檔案時，如果沒有找到檔案，是否将錯誤日志記錄到error.log檔案中。這僅用于定位問題。
（5）merge_slashes
文法：merge_slashes on | off;
預設：merge_slashes on;
此配置項表示是否合并相鄰的“/”，例如，//test///a.txt，在配置為on時，會将其比對為location /test/a.txt；如果配置為off，則不會比對，uri将仍然是//test///a.txt。
（6）dns解析位址
文法：resolver address ...;
設定dns名字解析伺服器的位址，例如：
resolver 127.0.0.1 192.0.2.1;
（7）dns解析的逾時時間
文法：resolver_timeout time;
預設：resolver_timeout 30s;
此配置項表示dns解析的逾時時間。
（8）傳回錯誤頁面時是否在server中注明nginx版本
文法：server_tokens on | off;
預設：server_tokens on;
表示處理請求出錯時是否在響應的server頭部中标明nginx版本，這是為了友善定位問題。
在記錄access_log通路日志檔案時，可以使用ngx_http_core_module子產品處理請求時所産生的豐富的變量，當然，這些變量還可以用于其他http子產品。例如，當uri中的某個參數滿足設定的條件時，有些http子產品的配置項可以使用類似$arg_parameter這樣的變量。又如，若想把每個請求中的限速資訊記錄到access日志檔案中，則可以使用$limit_rate變量。
表2-1列出了ngx_http_core_module子產品提供的這些變量。
