一、主配置文件結構

main?block；#全局塊配置全局生效event{#事件驅動相關配置 }http{#http/https協議相關配置段 server?{ ... }：#每個server用于定義一個虛擬主機； server?{ ... server_name root alias location?[OPERATOR]?URL?{ ... if?CONDITION?{ ... } } } } stream{ #tcp協議配置段 }

1.全局塊

全局塊主默認的配置文件從開始到event塊之間的的一部分內容，主要設置影響Nginx整個配置指令，影響全局；

2.event塊

event塊主要涉及到的指令用于響應nginx服務器與用戶的網絡連接，常用于配置時間驅動等模塊信息；

3.http塊

http塊是nginx配置文件中最為重要的塊，http自己的全局塊，包括大多數第三方模塊配置也可以添加到這個模塊中，server塊也可以包含在這個快中，

4.server塊

主要定義虛擬主機

5.location塊

每個server塊中可以包含多個location塊，location塊主要用于nginx服務器接收來自客戶端的請求的URL字符串進行匹配處理，nginx許多功能都是在此進行配置的。

二、Nginx正常運行必備的配置：

user?nobody; pid?/var/log/nginx/nginx.pid; worker_processes?auto; worker_rlimit_nofile?1024; master_process?on; error_log?/var/log/nginx/error.log; -------------------------------------------------------------------------------------------------------------------------- events?{ worker_connections?1024; use?epoll; accept_mutex?on; } -------------------------------------------------------------------------------------------------------------------------- http{ include???????mime.types; default_type??application/octet-stream; keepalive_timeout??65; gzip??on; server?{listen?80;server_name?app.liaoxz.com;root???/usr/local/nginx/html/app/;index??index.html?index.htm; } server?{listen?8090;server_name?abb.liaoxz.com;root?/usr/local/nginx/html/abb/;index?index.html; } }

cpu優化相關參數

1.設置worker process 數

worker process是nginx實現高并發的主要關鍵配置，這個建議與cpu核心數一致，

配置work proccess的語法格式：

worker_processes ?number;

2.worker_cpu_affinity cpumask ...;

worker_cpu_affinity auto [cpumask];

將worker進程與cpu進行綁定（綁定之后來自同一worker個進程的請求就會直接使用當前所綁定所指定的cpu）

建議設置成auto，auto表示在服務啟動時就將worker進程與之綁定。

用戶及進程相關

1.user uesr [group]

設置工作進程所使用的用戶或組

2.pid /PATH/TO/PID_FILE;

指定存儲nginx主進程進程號碼的文件路徑；

3.worker_priority number;

指定worker進程的nice值，設定worker進程優先級；[-20,20]

4.worker_rlimit_nofile number;

worker進程所能夠打開的文件數量上限；

5.master_process on |off;

是否以master/worker模型運行nginx

模塊裝載

1.include file | mask;

指明包含進來的其它配置文件片斷；

2.load_module file;

指明要裝載的動態模塊；

事件驅動相關

events{

1）worker_cnnections number;

每個worker進程所能打開的最大并發連接數

2）use method epoll|select|poll；

指明并發連接請求的處理方法；

建議使用epoll

use epoll;

3）accept_mutex on |off；

處理新的連接請求方法；on意味著由各worker輪流處理新請求，off意味著每個新的請求會通知所有的worker進程

}

三、Nginx Gzip壓縮

Gzip功能由模塊 ngx_http_gzip_module提供

官方站點介紹：http://nginx.org/en/docs/http/ngx_http_gzip_module.html

1.Syntax:gzip?on?|?off;
Default:
gzip?off;
Context:http,?server,?location,?if?in?location
默認是off，不啟動Gzip功能，設置為on為生效

2.Syntax:gzip_buffers?number?size;
Default:
gzip_buffers?32?4k|16?8k;
Context:http,?server,?location
用于指定緩沖區數量及每個緩存區的大小
number?緩沖區數量
size?緩存區大小

3.Syntax:gzip_comp_level?level;
Default:
gzip_comp_level?1;
Context:http,?server,?location
指定壓縮程度數字越高表示壓縮效率越高，但是占用系統資源，建議適當設置

4.Syntax:gzip_disable?regex?...;
Default:—
Context:http,?server,?location
This?directive?appeared?in?version?0.6.23.
針對不同類型客戶端進行選擇是否開啟gzip功能
regex?表示瀏覽器類型?支持使用正則表達式
IE瀏覽器?MSIE?[6-10]\;

5.Syntax:gzip_types?mime-type?...;
Default:
gzip_types?text/html;
Context:http,?server,?location
壓縮過濾器，僅對此處設定的MIME類型的內容啟用壓縮功能；

6.Syntax:gzip_proxied?off?|?expired?|?no-cache?|?no-store?|?private?|?no_last_modified?|?no_etag?|?auth?|?any?...;
Default:
gzip_proxied?off;
Context:http,?server,?location
Enables?or?disables?gzipping?of?responses?for?proxied?requests?depending?on?the?request?and?response.?The?fact?that?the?request?is?proxied?is?determined?by?the?presence?of?the?“Via”?request?header?field.?The?directive?accepts?multiple?parameters:

off
disables?compression?for?all?proxied?requests,?ignoring?other?parameters;
expired
enables?compression?if?a?response?header?includes?the?“Expires”?field?with?a?value?that?disables?caching;
no-cache
enables?compression?if?a?response?header?includes?the?“Cache-Control”?field?with?the?“no-cache”?parameter;
no-store
enables?compression?if?a?response?header?includes?the?“Cache-Control”?field?with?the?“no-store”?parameter;
private
enables?compression?if?a?response?header?includes?the?“Cache-Control”?field?with?the?“private”?parameter;
no_last_modified
enables?compression?if?a?response?header?does?not?include?the?“Last-Modified”?field;
no_etag
enables?compression?if?a?response?header?does?not?include?the?“ETag”?field;
auth
enables?compression?if?a?request?header?includes?the?“Authorization”?field;
any
enables?compression?for?all?proxied?requests.

nginx作為代理服務器接收到從被代理服務器發送的響應報文后，在何種條件下啟用壓縮功能的；
off：對代理的請求不啟用
no-cache,?no-store，private：表示從被代理服務器收到的響應報文首部的Cache-Control的值為此三者中任何一個，則啟用壓縮功能；
其他相關請查閱的官方文檔http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_disable

http{

include???????mime.types;
default_type??application/octet-stream;
keepalive_timeout??65;
gzip??on;
gzip_comp_level?4;
gzip_disable?MISE?[4-6]\;
gzip_buffers?32?4k;
}

四、nginx rewrite功能配置

? ? Rewrite 是nginx提供的一個重要功能，其在web服務器中必然會使用到的指令，例如在網站結構更改后，客戶端任可以使用之前使用的URL來進行訪問等操作，實現URL替換功能；

Rewrite功能是由ngx_http_rewrite_module模塊提供；

1、rewrite regex replacement [flag]

將用戶請求的URI基于regex所描述的模式進行檢查，匹配到時將其替換為replacement指定的新的URI；

注意：如果在同一級配置塊中存在多個rewrite規則，那么會自下而下逐個檢查；被某條件規則替換完成后，會重新一輪的替換檢查，因此，隱含有循環機制；[flag]所表示的標志位用于控制此循環機制；

如果replacement是以http://或https://開頭，則替換結果會直接以重向返回給客戶端；

301：永久重定向；

[flag]：

last：重寫完成后停止對當前URI在當前location中后續的其它重寫操作，而后對新的URI啟動新一輪重寫檢查；提前重啟新一輪循環；

break：重寫完成后停止對當前URI在當前location中后續的其它重寫操作，而后直接跳轉至重寫規則配置塊之后的其它配置；結束循環；

redirect：重寫完成后以臨時重定向方式直接返回重寫后生成的新URI給客戶端，由客戶端重新發起請求；不能以http://或https://開頭；

permanent:重寫完成后以永久重定向方式直接返回重寫后生成的新URI給客戶端，由客戶端重新發起請求；

? ? ? ??location / {

? ? ? ? ? rewrite ^/ http://abb.liaoxz.com/abb; ?

? ? ? ? ? ?root ? html;

? ? ? ? ? ? index ?index.html index.htm;

? ? ? ? }

2.if (condition) { ... }

引入一個新的配置上下文 ；條件滿足時，執行配置塊中的配置指令；server, location；

condition：

比較操作符：

==

!=

~：模式匹配，區分字符大小寫；

~*：模式匹配，不區分字符大小寫；

!~：模式不匹配，區分字符大小寫；

!~*：模式不匹配，不區分字符大小寫；

文件及目錄存在性判斷：

-e, !-e

-f, !-f

-d, !-d

-x, !-x

3.return

return code [text];

return code URL;

return URL;

Stops processing and returns the specified code to a client.?

停止處理并將指定的代碼返回給客戶端。 非標準代碼444關閉連接而不發送響應報頭。

?

?4.rewrite_log on | off;

是否開啟重寫日志；

?5.set $variable value;

用戶自定義變量?

五、nginx 后端服務器組配置指令詳解

nginx支持設置一組服務器作為后端服務器，做為反代或負載均衡都會涉及到

模塊由Module ngx_http_upstream_module模塊提供

http://nginx.org/en/docs/http/ngx_http_upstream_module.html

1.Syntax:upstream name { ... }

Default:—

Context:http

Defines a group of servers. Servers can listen on different ports. In addition, servers listening on TCP and UNIX-domain sockets can be mixed.

用于指定后端服務器組，upstream 后面為自定義的后端服務器組，默認為輪詢調度對后端服務器進行轉發處理請求，如果后端某一臺服務器發生故障調度器服務器會自動將其從組中踢除，待恢復后又自動加回組中。

2.Syntax:server address [parameters];

Default:—

Context:upstream

Defines the address and other parameters of a server. The address can be specified as a domain name or IP address, with an optional port, or as a UNIX-domain socket path specified after the “unix:” prefix. If a port is not specified, the port 80 is used. A domain name that resolves to several IP addresses defines multiple servers at once.

The following parameters can be defined:

weight=number

sets the weight of the server, by default, 1.

max_conns=number

該指令用于指定設置組內服務器

address 服務器地址

[parameters]

weight=number

為組內添加權重，權重值越高服務器被優先用于服務器，組內權重默認為1，如果不設置則組內主句輪詢處理；

max_fails=number

設置一個請求失敗的次數，在一定時間范圍內當對組內服務器請求失敗可允許超過次數，如果請求失敗次數超過該值時則認為該服務器為無效，默認值也是為1,

fail_timeout=number?

該時間設置有兩個作用。一是當多長時間嘗試去連接已失效服務器，第二個是在max_fails里面說到的在一定時間內對組內服務器請求失敗的時間；默認為1；

backup ；

將組內某臺服務器設置為備用服務器，只有所有服務器都處于無效情況下，該服務器才會被用來處理請求

down;?

將組內某臺服務器設置為永久無效狀態。

示例：

http {

upstream baks {

server 10.1.45.61:80 weight=1 max_fails=2 fail_timeout=30s;

server 10.1.45.62:80 weight=3;

server 127.0.0.1:80 backup;

}

}

3.Syntax:ip_hash;

Default:—

Context:upstream

Specifies that a group should use a load balancing method where requests are distributed between servers based on client IP addresses. The first three octets of the client IPv4 address, or the entire IPv6 address, are used as a hashing key. The method ensures that requests from the same client will always be passed to the same server except when this server is unavailable. In the latter case client requests will be passed to another server. Most probably, it will always be the same server as well.

該指令用于實現會話保持功能，將來自于某一客戶端的請求定向到組內任何一臺服務器上，保證客戶端與服務器之間建立穩定的會話，只有在該服務器在無效情況下才會被下一個服務器接收和處理

實例如下:

http {

ip_hash;

upstream baks {

server 10.1.45.61:80 weight=1 max_fails=2 fail_timeout=30s;

server 10.1.45.62:80 weight=3;

server 127.0.0.1:80 backup;

}

}

4.Syntax:keepalive connections;

Default:—

Context:upstream

This directive appeared in version 1.1.4.

Activates the cache for connections to upstream servers.

The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed.

該指令用于設置為每個worker進程保留的空閑的長連接數量。

5.Syntax:least_conn;

Default:—

Context:upstream

This directive appeared in versions 1.3.1 and 1.2.2.

Specifies that a group should use a load balancing method where a request is passed to the server with the least number of active connections, taking into account weights of servers. If there are several such servers, they are tried in turn using a weighted round-robin balancing method.

最少連接調度算法，當server擁有不同的權重時其為wlc;

6.Syntax:hash key [consistent];

Default:—

Context:upstream

This directive appeared in version 1.7.2.

Specifies a load balancing method for a server group where the client-server mapping is based on the hashed key value. The key can contain text, variables, and their combinations. Note that adding or removing a server from the group may result in remapping most of the keys to different servers. The method is compatible with the Cache::Memcached Perl library.

If the consistent parameter is specified the ketama consistent hashing method will be used instead. The method ensures that only a few keys will be remapped to different servers when a server is added to or removed from the group. This helps to achieve a higher cache hit ratio for caching servers. The method is compatible with the Cache::Memcached::Fast Perl library with the ketama_points parameter set to 160.

基于指定的key的hash表來實現對請求的調度，此處的key可以直接文本、變量或二者的組合；

作用：將請求分類，同一類請求將發往同一個upstream server；

轉載于:https://blog.51cto.com/liaoxz/1867467

總結

以上是生活随笔為你收集整理的Nginx基础配置的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。