2014-04-09 10:41:01
来 源
IT技术网
Nginx安装配置
本篇分享了Nginx.conf内容详细说明,希望对于初学Nginx服务器相关的朋友有帮助,更多Nginx安装、配置、报错处理等资源请本站内搜索。。
user  nobody nobody;  # nginx启动使用的默认用户,第一个nobody为用户名,第二个为用户组

# nobody是linux中权限较低的一个普通用户,但不能通过该账号登录系统 worker_processes  1;  # 指定了 Nginx 要开启的进程数。每个Nginx 进程平均耗费10M~12M内存。

# 根据经验,一般指定一个进程足够了,如果是多核CPU,建议指定和CPU的数量一样的进程数即可

# 日志错误级别有stderr, emerg, alert, crit, error, warn, notice, info, debug

# 在源码中分别对应0-8级别,其中debug日志最为详细,stderr最少

# nginx只认第一有效设置,不能使用这样的配置  error_log logs/debug.log debug | info;

error_log  logs/error.log;          # nginx 错误日志 相对于安装路径,默认为/usr/local/nginx/

error_log  logs/error.log  notice;  # nginx 记录警告日志 相对于安装路径,默认为/usr/local/nginx/

error_log  logs/error.log  info;    # nginx 记录信息日志 相对于安装路径,默认为/usr/local/nginx/

pid        logs/nginx.pid;    # 来指定进程id的存放位置 相对于安装路径,默认为/usr/local/nginx/

worker_rlimit_nofile 65535;   # 用于绑定worker进程和CPU,Linux内核 2.4以上可用

# 这个指令是指当一个nginx进程打开的最多文件描述符数目,

# 理论值应该是最多打开文件数(ulimit -n)与nginx进程数相除,

# 但是nginx分配请求并不是那么均匀,所以最好与ulimit -n 的值保持一致

# nginx的工作模式,及最大连接数,ulimit -n 查看 ,通过ulimit -n 2048 修改为2048

events {

use epoll;   # 指定Nginx的工作模式,支持的工作模式有select、poll、kqueue、epoll、rtsig 和/dev/poll

# select和poll都是标准的工作模式,kqueue和epoll是高效的工作模式,

# 不同的是 epoll用在 Linux 平台上,而kqueue用在BSD系统中。

# 对于Linux系统,epoll工作模式是首选

worker_connections  1024;  # 指定nginx每个进程的最大连接数,这是系统参数,一般默认为1024,而nginx的处理能力远不止1024

# 最大客户端连接数由 worker_processes和 worker_connections决定,即:max_clients = worker_processes * worker_connections

# 在作为反向代理时,max_clients 变为:max_clients = worker_processes * worker_connections/4

}

# HTTP服务配置

http {

include       mime.types;                 # 引用同目录下的mime.types文件,可以减少主配置文件的复杂度

default_type  application/octet-stream;   # default_type属于http核心模块指令,这里设定默认类型为二进制流,如文件类型为定义时使用这种方式

# Nginx的HttpLog模块指令,用于指定Nginx日志的输出格式

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';

# main为此日志输出格式的名称,可以在下面的access_log指令中引用

access_log  logs/access.log  main buffer=32K;  # 设置Nginx被访问的日志路径、格式和缓存大小,相对于安装路径,默认为/usr/local/nginx/

# 日志格式默认值是combined,缓存大小默认是off

# 如果不想记录日志,可以使用“access_log  off;”指令关闭日志记录

client_max_body_size  20m;   # 用来设置允许客户端请求的最大的单个文件字节数,默认值为1M

client_header_buffer_size    32K;   # 用于指定来自客户端请求头的 headerbuffer大小

# 对于大多数请求,1K的缓冲区大小已经足够,如果自定义了消息头或有更大的 Cookie,

# 可以增加缓冲区大小。这里设置为32K,默认值为1K

large_client_header_buffers  4 32K; # 用来指定客户端请求中较大的消息头的缓存最大数量和单位大小

# 这里表示设置最大缓存量为4个32K

sendfile        on;  # 用于开启高效文件传输模式,默认值是off

tcp_nopush      on;  # 用于控制TCP链接是否推送,默认值是on

tcp_nodelay     on;  # 用于控制TCP链接是否延迟,默认值是on

# 将tcp_nopush和tcp_nodelay两个指令设置为on用于防止网络阻塞

client_header_timeout  10;  # 设置客户端请求头读取超时时间,单位:秒,默认值为60

client_body_timeout    10;  # 设置客户端请求主体读取超时时间,单位:秒,默认值为60

send_timeout          10;   # 指定响应客户端的超时时间,单位:秒,默认值为60

# 这个超时仅限于两个连接活动之间的时间,

# 如果超过这个时间,客户端没有任何活动,Nginx将会关闭连接

keepalive_timeout  65;  # 保持连接时间,单位:秒,超过该时间,服务器会关闭连接

# HttpGzip模块配置,这个模块支持在线实时压缩输出数据流

gzip  on;    # 用于设置开启或者关闭gzip模块,on表示开启GZIP压缩,实时压缩输出数据流,默认值为off

gzip_min_length  1k;   # 设置允许压缩的页面最小字节数,页面字节数从header头的Content-Length中获取。

# 默认值是0,不管页面多大都进行压缩。建议设置成大于1K的字节数,小于1K可能会越压越大

gzip_proxied     any;  #

gzip_buffers     4    16k;  # 设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流

# 这里表示申请4个单位为16K的内存作为压缩结果流缓存

# 如果没有设置,默认值是申请跟原始数据相同大小的内存空间去存储gzip压缩结果

gzip_http_version    1.1;   # 用于设置识别HTTP协议版本,默认值是1.1,目前大部分浏览器已经支持GZIP解压,使用默认即可

gzip_comp_level    1;     #  gzip压缩比(1——9),1 压缩比最小处理速度最快,9 压缩比最大但处理最慢(传输快但比较消耗cpu)默认值是1

gzip_types   text/plain;  # 匹配MIME类型进行压缩,无论是否指定, “text/html”类型总是会被压缩的

gzip_vary    on;          # 让前端的缓存服务器缓存经过GZIP压缩的页面,例如用Squid缓存经过Nginx压缩的数据

# Nginx负载均衡配置

upstream mywebsite.net{ # upstream指令指定了一个负载均衡器的名称mywebsite.net,可以随便指定,默认值为空

ip_hash;    # Nginx负载均衡调度算法,不设置时为轮询(算法),Nginx总共支持四种方法:

# 轮询(默认):每个请求按时间顺序逐一分配到不同的后端服务器,如果后端某台服务器宕机,

# 故障系统被自动剔除,使用户访问不受影响。采用此算法时,可以设置Weight(轮询权值),

# Weight值越大,分配到的访问机率越高,主要用于后端每个服务器性能不均的情况下

# 例如:server 192.168.0.110:80 weight=5;

# ip_hash:每个请求按访问 IP 的 hash 结果分配,这样来自同一个IP 的访客固定访问一个后端服务器,

# 有效解决了动态网页存在的 session共享问题

# fair:比上面两个更加智能的负载均衡算法。此种算法可以依据页面大小和加载时间长短智能地进行负载均衡,

# 也就是根据后端服务器的响应时间来分配请求,响应时间短的优先分配。Nginx 本身是不支持 fair的,

# 如果需要使用这种调度算法,必须下载Nginx的upstream_fair模块。

# url_hash:按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,可以进一步提高后端缓存服务器的效率。

# Nginx本身是不支持url_hash的,如果需要使用这种调度算法,必须安装Nginx 的 hash软件包

server 192.168.0.110:80;   # 指定后端服务器的IP地址和端口

server 192.168.0.119:80  down;  # down状态表示当前的server暂时不参与负载均衡

server 192.168.0.120:8009  backup;  # backup状态表示预留的备份机器。当其他所有的非 backup机器出现故障或者忙的时候,

# 才会请求backup机器,因此这台机器的压力最轻,调度算法为ip_hash时,不能为该状态

server 192.168.0.211:8080   max_fails=3  fail_timeout=20s;  # max_fails,允许请求失败的次数,默认为 1

# 当超过最大次数时,返回proxy_next_upstream  模块定义的错误

# fail_timeout,在经历了max_fails次失败后,暂停服务的时间

# max_fails可以和fail_timeout一起使用

# 注意: 当负载调度算法为 ip_hash时,后端服务器在负载均衡调度中的状态不能是weight和backup

}

# server虚拟主机配置

server {

listen       80;   # 监听的端口

server_name  192.168.0.110 www.mywebsite.net;  # 指定IP 地址或者域名,多个域名之间用空格分开

charset koi8-r;  # 设置网页的默认编码格式

access_log  logs/host.access.log  main;  # 根据访问域名生成对应的访问日志

location / {

root   html;    # 根目录,相对于安装路径,默认为/usr/local/nginx/

index  index.html;   #  默认主页,在根目录下

open_file_cache max=1000 inactive=20s;

open_file_cache_valid    30s;

open_file_cache_min_uses 2;

open_file_cache_errors   on;

}

location ~* .(gif|jpg|jpeg|png|css|js|ico)$ {

root images;

}

location /lua {

lua_code_cache off;

content_by_lua_file /usr/local/nginx/lua/test.lua;

}

error_page   500 502 503 504  /50x.html;

location = /50x.html {

root   html;

}

}

}

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。