Nginx是目前比较主流的HTTP反向代理服务器（其企业版提供了基于TCP层的反向代理插件），对于构建大型分布式web应用，具有举足轻重的作用。简单来说，nginx有2个主要的功能：动/静态资源分离、负载均衡。
动/静态资源分离：nginx支持正则表达式以区分静态资源或者动态资源，其中动态资源可以进一步转发给后端的proxy server，而静态资源则可以在nginx层面使用本地缓存策略或者重定向（类CDN）到其他nginx上。
负载均衡：对于动态资源而言，如果有多个proxy server，那么nginx将会根据一定的算法选择合适的server，并转发请求，最终将客户端request相对均衡的分发给多个server。
Nginx作为“单点”，面向客户端请求，并将请求转发给后端的某个server，因为server可以有多个，那么从整体而言，提升了站点的“资源整合”能力，提升了站点的整体吞吐能力；但因为受限于nginx本身的IO模型，并没有“降低”对物理资源的消耗（即性能开支）；通常nginx作为整个站点的“避雷针”和导流通道，它应该被架设在物理资源较为优越的机器上，比如8U物理机，32核心，64G内存，对磁盘要求相对较低，对CPU、内存、网卡带宽有较高的要求，因为nginx不仅需要和客户端请求建立链接，而且还需要与后端proxy server建立链接并且负责流量输入、输出（这和LVS、Haproxy有本质区别），这种双倍的链接建立，就要求机器具有较高的内存和CPU，如果你的nginx还有大量的“静态资源”cache，还需要使用高速、高容量的磁盘。因为nginx节点最终为所有proxy server流量的总和，那么它应该具有更高的网卡带宽。
为了避免资源竞争，应该避免nginx和web server部署在同一个节点上，因为web server通常为CPU和内存高耗型，这会大大降低nginx的代理能力。
1) 在中小型应用中（PV在KW级别，单一垂直web应用），通常一个nginx代理多个（组）server即可。
2）对于大中型应用，一个nginx将无法支撑全部的流量，我们将会采用多个nginx代理（复制了1）中的架构模型），并在nginx前端继续构建高性能的分流设备，比如LVS、Haproxy等更低层的软/硬件负载均衡器，这种负载均衡器通常只是“转发”，而不涉及到流量的输出，所以转发效率将会更高，承载能力更强。
3）无论何时，我们也不希望nginx存在单点故障问题，那么通常我们还需要使用keepalived（其他同类型技术，VIP）来提高nginx节点的可用性，即Master-backup模式。
4）当有多个nginx时，为了提升后端server的代理能力，通常还会让多个nginx之间交叉重叠代理后端的server。
一、常用模块
在nginx 中，有几个常用的模块（module）：
- ngx_http_core_module：核心模块；内置模块。
- ngx_http_upstream_module：“upstream”模块，内置模块，核心模块；用于请求的“负载均衡”。
- ngx_http_proxy_module：“请求代理”模块，核心模块；将请求转发给代理Server，或者对请求进行额外的cache操作。
- ngx_http_rewrite_module：“URL重写”模块，内置模块；根据规则，rewrite特定的URL并转发给代理Server。
- ngx_http_access_module：“访问控制”模块；“允许”或者“拒绝”特定的IP列表对server的访问，内置模块。
- ngx_http_limit_conn_module：“访问控制”模块；可以限定每个key（可以为客户端IP）允许的最大并发连接数，内置模块。
- ngx_http_limit_req_module：“访问控制”模块；可以限定每个key（可以为客户端IP）在单位之间内允许处理的request个数，“流量控制”，内置模块。
- ngx_http_headers_module：“header”模块；主要是“add_header”和“expired”两个指令，向response中添加header信息，内置模块。
- ngx_http_charset_module：“字符集”模块；在响应头部的“Content-Type”中增加charset信息，内置模块。
- ngx_http_addition_module：“增添”模块；在response内容之前或者之后额外添加文本信息，内置模块。
- ngx_http_sub_module：“后置修改响应”模块；可以过滤并替换response内容中特定的字符串，附加模块，需要在编译时指定“--with-http_sub_module”。
- ngx_http_fastcgi_module：将请求发送给“fastcgi”服务器，内置模块。
- ngx_http_geo_module：“geo”模块；创建一个变量，此变量的值由client ip值决定，对实现小型私有“CDN”方案有参考价值，内置模块。
- ngx_http_geoip_module：“geo”模块；通过配置（数据源）可以得知client ip所属的“城市”、“区域”等信息，对实现小型私有的CDN有一定的参考价值，附加模块，需要在编译时指定“--with-http_geoip_module”。
- ngx_http_gzip_module：“gzip”模块；对response使用gzip压缩，对减少数据传输量有益，内置模块。
- ngx_http_gzip_static_module：“gzip”模块；对response使用gzip压缩，输出为“.gz”文件，附加模块，需要在编译时指定“--with-http_gzip_static_module”。
- ngx_http_image_filter_module：“图片”模块；可以对“JPEG”、“GIF”、“PNG”格式的图片进行裁剪等操作，附加模块，需要在编译时指定“--with-http_image_filter_module”。
- ngx_http_status_module/ngx_http_stub_status_module：“nginx内部状态”模块；用于获取nginx内部的一些状态统计信息，通常用来获取一些简单的统计数据，其中nginx_http_stub_status_module为附加模块，编译时需要指定“--with-http_stub_status_module”。
- nginx-http-concat：第三方附加模块，由taobao开发，主要用于合并“静态资源”请求，提升性能，需要额外下载，并在编译时添加“--add-module=/root/software/nginx-http-concat-master”。
- ngx_cache_purge：第三方附件模块，由frickle提供，当在proxy中使用cache保存静态资源时，那么cache_purge模块提供删除过期数据的功能支持，需要额外下载，并在编译时添加“--add-module=/root/software/ngx_cache_purge”。
二、安装（mac下）
接下来，我们就尝试安装nginx，从官网下载最新版1.8.0压缩包，并按照如下步骤一次安装，本人所使用的平台为mac OS（很遗憾，mac下安装这些软件，还是相当的费劲）。为了方便起见，我们将上述常用的module一次性全部安装或者加载（避免以后重新增加module带来的麻烦）。下文中所下载的软件都先保存到/usr/local/src下。
1、下载ngx_cache_purge模块：http://labs.frickle.com/nginx_ngx_cache_purge/，解压后保存在本地目录。
2、下载ngx-http-concat模块：https://github.com/alibaba/nginx-http-concat，解压后保存在本地目录。
3、下载nginx并解压，保存在/usr/local/src，重命名为“nginx-1.8.0-src”。
4、configure操作，通过--prefix指定nginx最终的可执行文件copy到哪个目录，这个目录不需要提前创建。
##进入nginx目录 ./configure --prefix=/usr/local/nginx-1.8.0 --with-http_stub_status_module --with-http_ssl_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --add-module=/usr/local/src/nginx-http-concat-master --add-module=/usr/local/src/ngx_cache_purge/
极有可能你会得到一个错误“./configure: error: the HTTP rewrite module requires the PCRE library.”，这意味着如果需要安装rewrite模块，那么就需要安装PCRE包（perl正则表达式）。
##mac系统,linux下均可使用此编译安装的方式 ##首先下载pcre包：http://www.pcre.org/，解压 ##进入解压包 sudo ./configure --prefix=/usr/local sudo make sudo make install
然后你还会得到一个错误“./configure: error: the HTTP image filter module requires the GD library.”，GD包主要用于图形处理，这个需要手动安装。安装GD之前，需要依次安装libpng、libjpeg，freetype，zlib（mac下不需要安装，默认已经有了）。
##libpng，在sourceforge.net上搜索“libpng”，下载tar.xz文件，解压，并执行如下命令 sudo ./configure --prefix=/usr/local sudo make sudo make install
##libjpeg，在http://www.ijg.org/files目录下，下载jpegsrc.v9a.tar.gz(或者下载最新的压缩包，不要下载源文件版) sudo ./configure --prefix=/usr/local sudo make sudo make install
##freetype,在sourceforge.net上搜索“freetype”，下载tar.bz2文件，并解压。 sudo ./configure --prefix=/usr/local sudo make sudo make install
##libgd：https://bitbucket.org/libgd/gd-libgd/downloads,下载tar.xz格式文件，如果你知道如何编译，也可以在libgd.org下载源码。 sudo ./configure --prefix=/usr/local --with-jpeg=/usr/local --with-png=/usr/local --with-freetype=/usr/local sudo make sudo make install
在安装libgd时，必须指定jpeg,png，freetype这些lib的位置，否则此后在nginx安装时会报错：
Undefined symbols for architecture x86_64:
"_gdImageCreateFromPngPtr", referenced from:
_ngx_http_image_resize in ngx_http_image_filter_module.o
"_gdImagePngPtr", referenced from:
_ngx_http_image_resize in ngx_http_image_filter_module.o
ld: symbol(s) not found for architecture x86_64
上述lib安装完毕之后，然后再次运行3）中的nginx的configure指令，应该就没有错误，然后依次执行“make” “make install”，此后我们会在“/usr/local/nginx-1.8.0”目录下看到相关的可执行文件、配置文件等。如果确实安装成功，那么我们此前的“nginx-1.8.0-src”即可删除，此后的操作只需要在安装后的文件中进行即可。
5、测试运行
进入sbin目录，执行“./nginx”，启动nginx，如果出错，请到logs目录下查看原因。然后在浏览器中输入“127.0.0.1”（无需端口），你将会得到nginx的欢迎页。
接下来，我们将依次介绍nginx的几个常用的模块，在认识如何配置nginx的同时，简单了解nginx的工作原理。
我们可以通过“./nginx -V”查看nginx的configure信息。
“./nginx -t”用于检测配置文件是否合法。
“./nginx -s stop”：关闭。
“./nginx -s quit”：优雅关闭。
“./nginx -s reopen”：重新打开log文件
“./nginx -s reload”：重新加载配置信息，我们在修改了conf文件之后，通常使用reload即可直接加载，无需重启nginx。
nginx会启动一个master进程，和“worker_processes”个worker进程，其中master进程主要的作用就是“加载、评定配置信息”、“维护worker进程”，worker进程用于处理实际的request，nginx基于平台的event模型，向worker进程分发request。
当master进程收到reload信号时，首先检测配置文件的合法性，然后尝试使用新的配置信息；如果成功，master将启动新的worker进程，并向原来的worker进程发消息请求他们shutdown，此后request将会被抓发给新的worker进程，对于原来的worker将自己已经accept的请求处理完之后即关闭；如果配置文件有问题，master将会回滚配置的更改，而worker进程不受任何影响。
6、配置文件样例
#user nobody;
worker_processes 2;
worker_rlimit_core 256m;
worker_rlimit_nofile 65535;
error_log logs/error.log info;
#pid logs/nginx.pid;
daemon on;
worker_priority 0;
events {
#use epoll;
use kqueue;#linux 请使用epoll
accept_mutex on;
accept_mutex_delay 500ms;
worker_connections 65535;
}
http {
include mime.types;
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"';
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
access_log logs/localhost.access.log main;
location / {
root html;
index index.html index.htm;
}
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
include vhosts/*.conf;
}
上面的配置信息应该是最基本的，基本上nginx能够对静态页面做代理，下文中所有的模块都基于这个配置模板。
三、代理简析
nginx一个重要的能力就是静态文件的代理（或cache），包括html、images等，这些静态文件通常放置在本地，比如：/data/www（一些html文件，css，js等），/data/images（图片文件）。
location / {
root html;
#index index.html index.htm;
}
location /images {
root /data;
}
root”表示文件所在的本地路径，最终请求的uri将会被添加到root路径之后，形成完整的文件路径，比如“127.0.0.1/images/header.jpg”，其uri为“images/header.jpg”，那么最终将会访问本地的“/data/images/header.jpg”（如果本地文件没有访问权限，将会抛出“Permission denied”）。此处还涉及到location的匹配优先级的问题，就像“/images/header.jpg”对于location为“/”和“/images”都匹配，在这种情况下，nginx将会选择“最长前缀”的哪一个，即“/images”；此外，location还能支持正则表达式，所以匹配的规则将会比较复杂，我们稍后详解location。
对于动态代理，需要配置一个（或一组，通过upstream模块支持）web server，nginx接收客户端请求（可以对header进行修改），然后传递给web server，并等待接收proxy server的响应内容，然后再把response发送给客户端（可以对response的内容或者header进行修改），在此过程中，nginx需要与客户端、web server均要建立链接，nginx就像一个“转发桥”，只是负责将请求，根据location或者其他规则，匹配到一个合适的web server上。
server {
listen 80 default_server;
server_name localhost;
location / {
proxy_pass http://127.0.0.1:8080;
}
}
proxy_pass将请求转发给web server，不过这个指令还有更多的意义，我们稍后详解upstream、proxy模块。动态代理，即实际处理请求（响应数据的server）的server在运行时通过一定的算法计算得到的，而且还可以根据请求的参数特征来修改response的内容；通常我们会指定多个web server，根据一定的“负载均衡”算法选取其中一个负责处理实际的请求。
“server_name”这个指令非常有用，nginx通常根据http请求header中的“Host”字段与“server_name”列表匹配，判定使用哪个“server”配置，然后根据uri匹配location，判定将次request交给哪个web server处理。关于server_name的匹配规则，还需要一定的了解。(如下部分配置样例中省略了部分无关的信息)
server {
listen 80;
server_name example.org www.example.org;
}
server {
listen 80;
server_name *.example.org;
}
server {
listen 80;
server_name mail.*;
}
server {
listen 80;
server_name ~^(?<name>.+)\.example\.net$;
}
对于指定的请求，nginx从header中host值，将按照如下顺序进行匹配：
1）精确的全限定名：比如server_name为“www.exmaple.org”，“example.org”。
2）以“*”开头的最长的通配名称：比如server_name为“*.exmaple.org”。
3）以“*”结束的最长的通配名称：比如server_name为“mail.*”。
4）首个匹配的正则表达式。nginx中正则表达式以“~”或者“~*”开头，我们稍后详解nginx的正则格式。
注意，在nginx中，通配表达式和正则表达式被认为是不同的，通配表达式必须以“*”开头或者结束，且“*”不能在字符串的中间出现，比如“www.*.example.org”是不合法的；否则应该在正则表达式中使用“*”，比如“~^w.*\.exmaple\.org$”，注意如果在正则表达式中使用字符串“.”，应该需要转义为“\.”,否则“.”是被作为正则表达式中特殊模式（即匹配任意字符串）；通配表达式，“*”可以匹配任意多个部分，比如“*.example.org”可以匹配“www.exmaple.org”、“www.sub.exmaple.org”；那么对于“.example.org”这种格式被认为是一种特殊的正则表达式，它可以匹配“exmaple.org”、“*.example.org”。
上文中提到，nginx中正则表达式必须以“~”开头（或者~*开头，表示字符大小写敏感）、“^”、“$”结尾，这三个特殊符号构成nginx（或者说是PCRE）正则表达式，否则被认为是普通的“全限定名”。如果你了解过正则表达式，其实这些还是非常容易理解的，不过如果正则表达式中包括“{”、“}”表示匹配次数区间，那么整个表达式都需要用引号包含，否则会编译错误。
server_name "~^(?<name>\w\d{1,3}+)\.example\.net$"
正则表达式中可以使用"?<name>"这种格式，在PCRE中称为“命名捕获”（named captures），那么“name”可以作为当前context中的一个变量使用。在nginx中还可以使用“数字”类型的命名捕获。
##参数方式
server {
server_name ~^(www\.)?(?<domain>.+)$;
location / {
root /sites/$domain;
}
}
##数字方式，效果等同
server {
server_name ~^(www\.)?(.+)$;
location / {
root /sites/$2;
}
}
我们还需要对待那些特殊的情况，比如请求的header中没有“Host”或者为空，那么可以用一个空字符串来匹配这种请求：
server {
server_name example.org www.example.org "" 192.168.1.1;
}
当然有些时候，我们还会使用IP去访问一个nginx（没有配置host解析，通常在测试环境），那么我们我们请求的“Host”就是一个IP字符串，那么我们仍然可以按照这种规则配置server_name。
server {
listen 80 default_server;
server_name _;
}
如上述例子所示，“default_server”表示为如果没有任何匹配的server_name时，将选择此server来处理。其中server_name如果配置为“_”，则表示此server匹配所有的“Host”，这些Host仅为那些不能通过“精确全限定名”、“通配表达式”、“正则表达式”匹配的。
根据server侦听的端口号，将会把“精确匹配”、“以*开头的通配表达式”、“以*结尾的通配表达式”保存在三个hashtable中（cache），这个hashtable的大小可以通过配置文件调整；针对一个host，将会首先使用“精确匹配”，如果没有找到相应的server_name，将会从“以*开头的通配表达式”中查找，然后再从“已*结尾的通配表达式”中查找；从“通配表达式”的hashtable中查找，要慢于“精确匹配”，不过对于“.example.org”这种格式会被保存在“通配表达式”的hashtable中，而不是保存在“精确匹配”的hashtable中。对于“正则表达式”时最慢的一种方式，也是最后参与匹配的，将会根据它们在配置文件中的顺序，依次去匹配。基于这些原因，比较好的办法就是尽可能的使用“精确全限定名”，比如：
server {
server_name example.org www.example.org *.example.org;
}
server {
server_name sub.example.org;
}
而不是像这样简单的配置：
server {
server_name .example.org;
}
如果你定义了较多的server配置或者较长的server_name字符串，那么就需要通过“server_names_hash_max_size”（会影响server_name的个数）、“server_names_hash_bucket_size”（影响server_name的字符串长度）来调整配置，否则会抛出错误，我们不需要贸然去调整这两个参数，直到它出错。
四、负载均衡
使用nginx，其实还对其“负载均衡”的特性比较看重。通常我们有多个web server对等部署，nginx将会通过“负载均衡”模块将请求转发给合适的web server，最终提升了web站点的整体吞吐能力，同时也提高了可用性。需要注意，nginx目前是Http层面的负载均衡器，在1.9V之后将提供TCP层面的负载均衡支持。如下为nginx内置的负载均衡算法：
1）round-robin：轮询，request将会依次有序的分发给web server。one by one！默认使用此算法。
2）least-connected：最小连接数，请求将会被分发给当前链接数最小的server。配置名“least_conn”。
3）ip-hash：根据请求的客户端IP作为hashing key，来判定选择哪个server。配置名“ip_hash”。
http {
upstream backend {
##least_conn;
server 192.168.1.110 weight=3;
server 192.168.1.120;
}
server {
listen 80 default_server;
#
server_name _;
location / {
proxy_pass http://backend;
}
}
}
上述配置，就是一个简单的“负载均衡”的样例，首先在一个“upstream”区块中声明server列表，然后在proxy_pass指令中使用它；如果没有声明“负载均衡”算法，那么默认就是用“round-robin”，其他可选值为“least_conn”、“ip_hash”，“负载均衡”算法需要在upstream区块的首行声明。
“least_conn”算法可以让全局的性能开支，在多个server之间趋于平衡，因为不同的server可能在物理性能上就有差距，而且不同的request处理耗时也不尽相同；如果希望处理比较快的server能够尽可能的接收更多的请求，那些负载较高的server也能稳步推进（后续我们会提到流量控制），那么“least_conn”算法将非常适合。通常我们在production环境中，均采用此算法。
“least_conn”和“round-robin”算法，将会把一个客户端（来自同一个IP）的请求分发给不同的server上，这在某些情况下并不妥，比如“粘性session”，同一个客户端的请求应该被转发给同一个server（除非此server失效后，才会被转发到其他server），否则session会话中的数据将会丢失。那么“ip_hash”算法将比较适合。不过基于残酷的现实，粘性session的设计方案并不通用。
能够影响负载均衡策略的还有一个重要的参数：权重；“权重”用来标记某个server承载请求的“优先级”，通常权重越高的server将优先获得客户端请求，事实上“权重”也是表示一个server“承载”能力的大小，我们通常可以对硬件配置较高的server给予较高的权重，这有点像粗颗粒的“虚拟化”，如果一个server的硬件配置是另一个的2倍，那么可以将权重值设置为其2倍。
默认upstream中所有的server权重都一样，那么“负载均衡”算法将平等对待它们。
upstream backend {
server 192.168.1.110 weight=3 max_fails=3 fail_timeout=10s;
server 192.168.1.120;
server 192.168.1.130;
}
对于上述配置，每5个请求，将有3个分发给“192.168.1.110”，其他两个server各一个。上述提到的三种负载均衡算法中，都可以使用weight。
“健康监测”对于负载均衡是必须的，这是提供可用性、“故障迁移”的必要手段。比如当某个server失效，请求未能正常处理，那么我们应该将分发给那些“正常”的server，并将故障的server从列表中移除，直到它恢复，以避免后续更多的请求处理失败。nginx当与一个server建立链接失败后，会在“fail_timeout”时间内最多尝试“max_fails”次，如果仍为失败，则将次server标记为“failed”，并从服务列表中移除。默认“max_fails”为1，如果“max_fails”为0，则表示关闭“健康检测”；“fail_timeout”（默认位10s）表示检测多久后被标记为“failed”，nginx会以优雅的方式检测那些失效的server，如果它们再次上线，则将它们标记为“alive”，即可继续提供服务。
更多的关于“负载均衡”配置方式，我们将在下文“upstream”模块中详解。
五、计量单位
nginx配置文件中，对于表示“数据尺寸”的数字后，可以跟上“k”、“m”、“g”等单位缩写字母，无单位后缀表示“字节”。对于表示“时间”的数字，可以使用“ms”、“s”、“m”（分钟）、h、d（天）、w（周）、M（月）、y（年），我们还能以组合的方式使用它们，比如“1h 30m”，表示一小时30分钟，相当于“90m”或者“5400s”，无单位后缀表示“秒”。如下例：
proxy_cache_path /home/proxy_cache_path levels=1:2 keys_zone=cache_one:64m inactive=1d max_size=30g;
六、HTTPS配置
https突然风靡起来，就连小论坛也开始用https，显的很技术派，似乎它的低性能的缺点并没有想象的那么可怕。在实际环境中，nginx和后端的web server均可以支持htps，为了架构的简单性，以及不希望web协议干扰程序的实现，我们通常在nginx这一次支持https，而在web server层（比如tomcat）则继续使用http协议。配置样例如下：
upstream backend
{
server 192.168.1.110:8080;
server 192.168.1.120:8080;
}
server {
listen 80;
server_name www.example.com example.com;
rewrite ^/(.*)$ https://$host/$1 last;
}
server {
listen 443;
server_name www.example.com example.com;
ssl on;
ssl_certificate /usr/local/nginx/conf/ssl/example.com_bundle.crt;
ssl_certificate_key /usr/local/nginx/conf/ssl/example.com.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
keepalive_timeout 60;
ssl_protocols SSLv3 TLSv1 TLSv1.2 TLSv1.1;
ssl_ciphers HIGH:!aNULL:!MD5:!EXPORT56:!EXP;
ssl_prefer_server_ciphers on;
location / {
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
proxy_pass http://backend;
}
}
无论如何，你在使用HTTPS之前，需要开启SSL，如果是线上应用，还需要从第三方机构购买一个合法的认证包（如果自己生成，其实并没有什么卵用），这个包里将会包含crt和key两个文件，然后根据上述nginx样例将文件的路径配置正确即可，需要提醒，nginx需要有访问这两个文件的权限。
SSL操作需要消耗额外的CPU资源，主要在SSL握手阶段，有2种方式可以减少每个客户端的这种操作：1）开启链接的keepalive选项（http 1.1），那么一个客户端可以通过一个（次）链接发送多个请求，事实上达成了链接重用的目的，减少了创建链接和“握手”的次数。 2）重用SSL session参数，以避免此后的子链接再进行握手操作，通过“ssl_session_cache”配置，session将会被保存在cache中，可以在workers进程之间共享，1M的cache空间可以保存大概4000个sessions，缓存生命周期默认为5分钟，可以通过“ssl_session_cache”修改。“ssl_session_cache shared:SSL:10m”表示cache可以在多个workers进程之间共享，cache名位“SSL”，缓存大小为10M（数据尺寸，不是10分钟）。
上述配置，任何http请求都会被rewrite成https，不过在proxy_pass分发给后端web server时使用http协议，这是一种比较常用的方式，所以让你的网站支持https，只需要在nginx层做认证即可，不需要调整web server的配置。
七、其他
在描述nginx的指令之前，我们基本熟悉了nginx指令的配置方式：“<指令名称> 值 [可选参数名=参数值];”，以“;”结束，一个区块我们可以包含多个指令，那么这种区块称为context（上线文），nginx中常用的区块有“http”、“events”、“server”、“upstream”、“location”等，最外层的context称之为“main”，context通常是有继承关系，比如“location”需要包含在“server”中。“#”表示行注释。
在nginx配置文件中，如果配置项表示路径，比如“root /data/images”，如果为相对路径，则起始与nginx根目录。
一个指令可以被配置在多个context下，比如“root”：
http {
root /data/www;
server {
listen 80;
server_name localhost;
root /data/www/html;
location / {
root html;
index index.html index.htm;
}
}
}
那么根据context的继承关系，子context的指令将覆盖其父context，同理，其他指令也将是如此。
八、nginx常规配置模板
#user www www;
worker_processes auto;
error_log /home/wwwlogs/nginx_error.log crit;
#pid /usr/local/nginx/nginx.pid;
#Specifies the value for maximum file descriptors that can be opened by this process.
worker_rlimit_nofile 655350;
events
{
use epoll;
worker_connections 655350;
}
http
{
include mime.types;
default_type application/octet-stream;
server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;
client_max_body_size 50m;
server_tokens off;
sendfile on;
tcp_nopush on;
keepalive_timeout 60;
tcp_nodelay on;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 256k;
proxy_connect_timeout 600;
proxy_read_timeout 600;
proxy_send_timeout 600;
proxy_buffer_size 64k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml text/xml application/json;
gzip_vary on;
log_format access '$remote_addr - $remote_user [$time_local] $host '
'"$request" $status $body_bytes_sent $request_time '
'"$http_referer" "$http_user_agent" "$http_x_forwarded_for"'
'$upstream_addr $upstream_status $upstream_response_time' ;
server {
listen 80;
server_name _;
return 403;
}
include vhost/*.conf;
}
以“exmaple.org”为例，如下为基于upstream负载均衡模式的配置：
upstream example_backend {
server 127.0.0.1:9080;
server 192.168.1.198:9080;
}
server {
listen 80;
server_name www.example.org example.com .example.org;
location / {
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
proxy_pass http://example_backend;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
access_log logs/www.example.org.log;
location ~ .*\.(gif|jpg|jpeg|png|bmp|ico|swf|xml|css|js)$ {
proxy_pass http://example_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
expires 15d;
}
location ~ .*\.(jhtml)$ {
proxy_pass http://example_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
expires -1;
}
}
上述配置中，对后端web server返回的静态类型文件，让浏览器缓存15天，对于jhtml格式的动态文件不缓存。
九、基于HTTPS配置核心配置
upstream example_backend {
server 127.0.0.1:9080;
server 192.168.1.198:9080;
}
server {
listen 80;
server_name www.example.org example.org;
rewrite ^/(.*)$ https://$host/$1 last;
}
server {
listen 443;
server_name www.example.org example.org;
ssl on;
ssl_certificate /usr/local/nginx/conf/ssl/example.crt;
ssl_certificate_key /usr/local/nginx/conf/ssl/example.key;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1 TLSv1.2 TLSv1.1;
ssl_ciphers HIGH:!aNULL:!MD5:!EXPORT56:!EXP;
ssl_prefer_server_ciphers on;
location / {
...
}
}
十、对于文件系统而言，基于nginx缓存的配置
upstream static_backend {
server 192.168.1.198:8080;
server 127.0.0.1:8080;
}
#设置Web缓存区名称为cache_one，内存缓存空间大小为256MB，1天没有被访问的内容自动清除，硬盘缓存空间大小为30GB。
proxy_temp_path /home/proxy_temp_dir;
proxy_cache_path /home/proxy_cache_path levels=1:2 keys_zone=cache_one:256m inactive=1d max_size=30g;
server {
listen 80;
server_name static.example.org;
location / {
proxy_next_upstream http_502 http_504 error timeout invalid_header;
proxy_cache cache_one;#nginx本地cache开启
proxy_cache_valid 200 304 30d;
proxy_cache_valid 301 302 404 1m;
proxy_cache_valid any 1m;
proxy_cache_key $host$request_uri;
add_header X-Proxy-Cache $upstream_cache_status;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header If-Modified-Since $http_if_modified_since;
expires 30d;#客户端缓存，在header中增加“Expires”
add_header Cache-Control public;
proxy_pass http://static_backend;
if_modified_since before;
}
#location ~ /purge(/.*) {
# allow 127.0.0.1;
# allow 192.168.1.0/24;
# deny all;
# proxy_cache_purge cache_one $host$1$is_args$args;
# }
#https://github.com/FRiCKLE/ngx_cache_purge/
access_log /home/wwwlogs/static.example.org.log access;
}
相关推荐
本文将针对“学习过程中的简单总结概述理解”这一主题，重点关注Nginx、MySQL以及源码理论的分析，帮助读者深入理解这些关键知识点。 首先，让我们探讨Nginx。Nginx是一个高性能的HTTP和反向代理服务器，广泛用于...
一、Lua-Nginx-Module概述 1.1 Lua-Nginx-Module的诞生与目标 Lua-Nginx-Module由OpenResty团队开发，旨在提供一种轻量级、高效且易于使用的机制，使开发者能够在Nginx内部处理复杂的业务逻辑，如动态内容生成、...
#### 知识点一：Nginx 概述与特性 - **Nginx**：一款高性能的Web服务器和反向代理服务器，以其稳定性、丰富的功能集、简单的配置文件和低资源消耗而闻名。 - **高性能**：能够处理大量并发连接，并且提供低延迟响应...
#### 一、Nginx概述 - **Nginx历史**：Nginx是由俄罗斯程序员Igor Sysoev在2004年开始开发的一款高性能HTTP和反向代理Web服务器软件。自发布以来，因其出色的性能表现和稳定性，迅速成为全球广泛使用的Web服务器之...
#### 一、Nginx概述 Nginx是一款高性能的HTTP和反向代理Web服务器，它同时也是一个IMAP/POP3/SMTP代理服务器。Nginx以其高稳定性、丰富的功能集、简单的配置文件以及低资源消耗而闻名于世。在第四版的《Nginx ...
#### 一、Nginx负载均衡技术概述 在互联网环境下，随着访问量的不断增长，单一服务器往往难以满足需求，这时候就需要采用负载均衡技术来分担请求压力。Nginx作为一款高性能的HTTP服务器及反向代理服务器，广泛应用...
一、Nginx架构概述 Nginx采用模块化设计，主要分为以下几个核心模块： 1. **事件处理模块**：Nginx基于epoll（Linux）、kqueue（FreeBSD）等高效事件模型，实现非阻塞I/O，保证高并发性能。 2. **网络连接模块**：...
#### 一、Nginx 概述 - **定义**: Nginx（发音为 “engine x”）是一款轻量级的 Web 服务器/反向代理服务器以及电子邮件 (IMAP/POP3) 代理服务器。它采用 BSD-like 许可证发布。 - **开发者**: 由俄罗斯程序员 Igor...
#### 一、Nginx 概述 Nginx 是一款高性能的开源 Web 服务器和反向代理服务器，被广泛应用于搭建静态和动态网站、负载均衡、缓存加速以及安全代理等方面。其高效稳定的表现使其成为互联网领域不可或缺的技术之一。 ...
### 一、Nginx概述 Nginx是一款开源的Web服务器，由Igor Sysoev编写，用于替代Apache等其他Web服务器。Nginx以其轻量级、高性能、稳定性和灵活性而闻名，非常适合高并发场景下的负载均衡、反向代理等功能。随着...
- **OpenResty概述**：OpenResty是一个基于Nginx与许多第三方模块的高性能Web平台。它不仅包含了标准Nginx的核心功能，还集成了LuaJIT运行时环境，允许开发者直接在Nginx内部使用Lua脚本编写高性能的应用程序逻辑。 ...
**一、Nginx概述** 1. **性能特点**：Nginx采用事件驱动模型，能够同时处理大量连接，尤其适合高并发场景。其静态文件处理能力强，对于处理静态资源如HTML、图片和视频等具有明显优势。 2. **反向代理**：Nginx...
#### 一、概述 Nginx是一款广受赞誉的高性能开源Web服务器和反向代理服务器。它以其卓越的性能和稳定性，在全球范围内被广泛应用于各种规模的网站和服务中。 #### 二、核心特点与优势 1. **高并发处理能力** - ...
压缩包中的“Nginx从入门到实践视频课程.txt”文件可能是课程大纲或笔记，提供了每章节的详细内容概述，便于学习者跟踪进度和复习关键点。 总结起来，这个课程全面覆盖了Nginx的各个方面，适合初学者和有一定经验的...
通过这些实战案例的学习，读者不仅可以深入理解Nginx的工作原理，还能掌握一系列实用的技术技巧，从而更好地利用Nginx构建高效稳定的Web服务器环境。 #### 总结 Nginx凭借其出色的性能和灵活性，在Web服务器领域...
文章最后会总结Nginx的功能特性，并推荐读者进一步学习官方文档以获取更深入的理解和技术支持。 以上就是从给定的文件标题、描述、标签和部分内容中提取的关键知识点。这些内容覆盖了Nginx的基础知识、安装配置、...
#### 一、概述 在 FreeBSD 8 系统上搭建一个稳定的 Nginx 和 PHP 运行环境是许多 Web 开发者的需求。本指南将详细介绍从系统安装到配置 Nginx 和 PHP 的全过程，适合初学者参考学习。 #### 二、准备工作 1. **...
#### 知识点一：LNMP架构概述 LNMP（Linux + Nginx + MySQL + PHP）是一种流行的Web服务器架构，用于搭建高性能的动态网站或应用程序。其中： - **Linux**：作为操作系统，提供了稳定、安全、免费的运行环境。 - *...