首先说下在redhat中的安装方法，
正常安装nginx 需要安装很多的依赖，最后再安装nginx，而且很容易出错。
在nginx官方上有这么一段描述：
Pre-Built Packages for Mainline version
To set up the yum repository for RHEL/CentOS, create the file named /etc/yum.repos.d/nginx.repo with the following contents:
[nginx] name=nginx repo baseurl=http://nginx.org/packages/mainline/OS/OSRELEASE/$basearch/ gpgcheck=0 enabled=1
Replace “OS” with “rhel” or “centos”, depending on the distribution used, and “OSRELEASE” with “6” or “7”, for 6.x or 7.x versions, respectively.
直译为下：
在 /etc/yum.repos.d/ 目录下新建 nginx.repo 文件 内容如下：
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/mainline/rhel/7/$basearch/
gpgcheck=0
enabled=1
然后 执行 yum install nginx 命令
nginx 就安装好了
安装在 /etc/nginx 下 只需要修改配置文件就好了
启动：service nginx start
重新加载配置文件：nginx -s reload
好吧 今天配置新环境时， 执行 yum install nginx 命令 报错了 提示找不到 /mnt/cdrom/repodata/repomd.xml 这个文件，
网上扒了 一下午 又是 在 /etc/yum.repos.d/ 下加 CentOS-Base.repo 又是 删除 安装 什么 yum- * 扒拉扒拉一大堆，都没用
最后找到一个很简单的方法 ：
/etc/yum.repos.d/ 这个目录下有个 redhat 默认的 repo 文件 叫 ：rhel.repo
这个文件里默认的内容是：
[rhel]
name=Red Hat Enterprise Linux packages
baseurl=file:///mnt/cdrom/
enabled=1
gpgcheck=0
改后为：
[rhel]
name=Red Hat Enterprise Linux packages
baseurl=baseurl=http://mirrors.163.com/centos/7/os/x86_64/
enabled=1
gpgcheck=0
然后再 执行 yum install nginx 命令 就可以了
============分割线========================分割线=============================分割线============================
前言
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like 协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发，供俄国大型的入口网站及搜索引擎Rambler（俄文：Рамблер）使用。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好。（百度百科- http://www.dwz.cn/x32kG）
1.Nginx安装
我使用的环境是64位 Ubuntu 14.04。nginx依赖以下模块：
l gzip模块需要 zlib 库
l rewrite模块需要 pcre 库
l ssl 功能需要openssl库
1.1.安装pcre
- 获取pcre编译安装包，在http://www.pcre.org/上可以获取当前最新的版本
- 解压缩pcre-xx.tar.gz包。
- 进入解压缩目录，执行./configure。
- make & make install
- 注： 如果 执行 ./configure 时 报错 configure: error: You need a C++ compiler for C++ support
- 输入 yum install -y gcc gcc-c++ 可以解决
-
1.2.安装openssl
- 获取openssl编译安装包，在http://www.openssl.org/source/上可以获取当前最新的版本。
- 解压缩openssl-xx.tar.gz包。
- 进入解压缩目录，执行./config。
- make & make install
-
1.3.安装zlib
- 获取zlib编译安装包，在http://www.zlib.net/上可以获取当前最新的版本。
- 解压缩openssl-xx.tar.gz包。
- 进入解压缩目录，执行./configure。
- make & make install
-
1.4.安装nginx
- 获取nginx，在http://nginx.org/en/download.html上可以获取当前最新的版本。
- 解压缩nginx-xx.tar.gz包。
- 进入解压缩目录，执行./configure
- make & make install
若安装时找不到上述依赖模块，使用--with-openssl=
启动 nginx
nginx的启动命令是：
/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
-c制定配置文件的路径，不加-nginx会自动加载默认路径的配置文件。
linux 64位安装nginx后启动出错报以下错误
[root @localhost nginx- 1.3 . 0 ]# /usr/local/nginx/sbin/nginx
error while loading shared libraries: libpcre.so. 1 :
cannot open shared object file: No such file or directory
[root @localhost nginx- 1.3 . 0 ]# ldd $(which /usr/local/nginx/sbin/nginx)
linux-vdso.so. 1 => ( 0x00007fff4d5ff000 )
libpthread.so. 0 => /lib64/libpthread.so. 0 ( 0x00007fea7e357000 )
libcrypt.so. 1 => /lib64/libcrypt.so. 1 ( 0x00007fea7e120000 )
libpcre.so. 1 => not found
libz.so. 1 => /lib64/libz.so. 1 ( 0x00007fea7df09000 )
libc.so. 6 => /lib64/libc.so. 6 ( 0x00007fea7db76000 )
/lib64/ld-linux-x86- 64 .so. 2 ( 0x00007fea7e57d000 )
libfreebl3.so => /lib64/libfreebl3.so ( 0x00007fea7d913000 )
libdl.so. 2 => /lib64/libdl.so. 2 ( 0x00007fea7d70f000 )
[root @localhost /]# cd lib64/
[root @localhost lib64]# ln -s libpcre.so. 0.0 . 1 libpcre.so. 1
启动nginx之后，浏览器中输入http://localhost可以验证是否安装启动成功。
如果页面显示 403 forbidden的错误
可能的原因：1、nginx 安装目录下 html 的权限不够 添加 读取 写入 执行 相关权限
2、网站根目录不包含index指令设置的文件。
location / {
root html;
index index.html a.htm;
}
即 以上配置节点 中 的 index.html 不在 安装目录 usr/local/nginx/html/ 这个目录下
2.Nginx配置
安装完成之后，配置目录conf下有以下配置文件，过滤掉了xx.default配置：
| tyler@ubuntu:/opt/nginx-1.7.7/conf$ tree |grep -v default . ├── fastcgi.conf ├── fastcgi_params ├── koi-utf ├── koi-win ├── mime.types ├── nginx.conf ├── scgi_params ├── uwsgi_params └── win-utf |
除了nginx.conf，其余配置文件，一般只需要使用默认提供即可。
2.1.nginx.conf
nginx.conf是主配置文件，默认配置去掉注释之后的内容如下图所示：
l worker_process表示工作进程的数量，一般设置为cpu的核数
l worker_connections表示每个工作进程的最大连接数
l server{}块定义了虚拟主机
n listener监听端口
n server_name监听域名
n location{}是用来为匹配的 URI 进行配置，URI 即语法中的“/uri/”。location / { }匹配任何查询，因为所有请求都以 / 开头。
u root指定对应uri的资源查找路径，这里html为相对路径，完整路径为/opt/ opt/nginx-1.7.7/html/
u index指定首页index文件的名称，可以配置多个，以空格分开。如有多个，按配置顺序查找。
从配置可以看出，nginx监听了80端口、域名为localhost、跟路径为html文件夹（我的安装路径为/opt/nginx-1.7.7，所以/opt/nginx-1.7.7/html）、默认index文件为index.html， index.htm、服务器错误重定向到50x.html页面。
可以看到/opt/nginx-1.7.7/html/有以下文件：
| tyler@ubuntu:/opt/nginx-1.7.7/html$ ls 50x.html index.html |
这也是上面在浏览器中输入http://localhost，能够显示欢迎页面的原因。实际上访问的是/opt/nginx-1.7.7/html/index.html文件。
2.2.mime.types
文件扩展名与文件类型映射表，nginx根据映射关系，设置http请求响应头的Content-Type值。当在映射表找不到时，使用nginx.conf中default-type指定的默认值。例如，默认配置中的指定的default-type为application/octet-stream。
include mime.types;
default_type application/octet-stream;
默认
下面截一段mime.types定义的文件扩展名与文件类型映射关系，完整的请自行查看：
2.3.fastcgi_params
nginx配置Fastcgi解析时会调用fastcgi_params配置文件来传递服务器变量，这样CGI中可以获取到这些变量的值。默认传递以下变量：
这些变量的作用从其命名可以看出。
2.4.fastcgi.conf
对比下fastcgi.conf与fastcgi_params文件，可以看出只有以下差异：
| tyler@ubuntu:/opt/nginx-1.7.7/conf$ diff fastcgi.conf fastcgi_params 2d1 < fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; |
即fastcgi.conf只比fastcgi_params多了一行“fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;”
原本只有fastcgi_params文件，fastcgi.conf是nginx 0.8.30 (released: 15th of December 2009)才引入的。主要为是解决以下问题（参考：http://www.dwz.cn/x3GIJ）：
原本Nginx只有fastcgi_params，后来发现很多人在定义SCRIPT_FILENAME时使用了硬编码的方式。例如，fastcgi_param SCRIPT_FILENAME /var/www/foo$fastcgi_script_name。于是为了规范用法便引入了fastcgi.conf。
不过这样的话就产生一个疑问：为什么一定要引入一个新的配置文件，而不是修改旧的配置文件？这是因为fastcgi_param指令是数组型的，和普通指令相同的是：内层替换外层；和普通指令不同的是：当在同级多次使用的时候，是新增而不是替换。换句话说，如果在同级定义两次SCRIPT_FILENAME，那么它们都会被发送到后端，这可能会导致一些潜在的问题，为了避免此类情况，便引入了一个新的配置文件。
因此不再建议大家使用以下方式（搜了一下，网上大量的文章，并且nginx.conf的默认配置也是使用这种方式）：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
而使用最新的方式：
include fastcgi.conf;
2.5.uwsgi_params
与fastcgi_params一样，传递哪些服务器变量，只有前缀不一样，以uwsgi_param开始而非fastcgi_param。
2.6.scgi_params
与fastcgi_params一样，传递哪些服务器变量，只有前缀不一样，以uwsgi_param开始而非fastcgi_param。
2.7.koi-utf、koi-win、win-utf
这三个文件都是与编码转换映射文件，用于在输出内容到客户端时，将一种编码转换到另一种编码。
koi-win： charset_map koi8-r < -- > windows-1251
koi-utf： charset_map koi8-r < -- > utf-8
win-utf： charset_map windows-1251 < -- > utf-8
koi8-r是斯拉夫文字8位元编码，供俄语及保加利亚语使用。在Unicode未流行之前，KOI8-R 是最为广泛使用的俄语编码，使用率甚至起ISO/IEC 8859-5还高。这3个文件存在是因为作者是俄国人的原因。
以上均亲测
Nginx负载均衡配置实例详解
测试环境
由于没有服务器，所以本次测试直接host指定域名，然后在VMware里安装了三台CentOS。
测试域名 ：a.com
A服务器IP ：192.168.5.149 （主）
B服务器IP ：192.168.5.27
C服务器IP ：192.168.5.126
部署思路
A服务器做为主服务器，域名直接解析到A服务器（192.168.5.149）上，由A服务器负载均衡到B服务器（192.168.5.27）与C服务器（192.168.5.126）上。
域名解析
由于不是真实环境，域名就随便使用一个a.com用作测试，所以a.com的解析只能在hosts文件设置。
打开：C:WindowsSystem32driversetchosts
在末尾添加
192.168.5.149 a.com
保存退出，然后启动命令模式ping下看看是否已设置成功
从截图上看已成功将a.com解析到192.168.5.149IP
A服务器nginx.conf设置
打开nginx.conf，文件位置在nginx安装目录的conf目录下。
在http段加入以下代码
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
}
server{
listen 80;
server_name 192.168.5.149 a.com;
location / {
proxy_pass http://a.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重启nginx
B、C服务器nginx.conf设置
打开nginx.confi，在http段加入以下代码
server{
listen 80;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}
保存重启nginx
测试
当访问a.com的时候，为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的index.html文件，以作区分。
打开浏览器访问a.com结果 如果页面 出现 错误 504 timeout 等 查看 A 服务器 安装目录下的 log/error.log
如果有 连接超时的错误 提示 需要加上以下配置 ip 地址 根据自己的实际情况 修改
A：服务器如下
upstream abc.com {
server 192.168.3.129:80;
server 192.168.3.130:80;
}
server
{
listen 80;
server_name 192.168.3.127 abc.com;
large_client_header_buffers 4 64k;
client_max_body_size 300m;
client_body_buffer_size 128k;
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;
location / {
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;
proxy_pass http://abc.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
B C 服务器如下：
server{
listen 80;
server_name abc.com;
large_client_header_buffers 4 64k;
client_max_body_size 300m;
client_body_buffer_size 128k;
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;
index index.html;
root /data0/htdocs/www;
}
如果A 服务器error.log 里有 这个报错 connect() failed (113: No route to host)
则 执行这个命令 iptables -I INPUT -p tcp --dport 80 -j ACCEPT
打开 设置 防火墙 允许 访问 80 端口
如果A 服务器error.log 里有 这个报错 no live upstreams while connecting to upstream
正在 尝试 解决
现在的 问题是 直接访问abc.com 页面提示 404
如果直接访问 A 服务器ip 192.168.3.127 则可以看到服务器B 或者C 的页面 刷新页面 会不停切换
ip 访问正常 域名访问不了 这个应该是域名解析的问题 和nginx 本身无关 不整了
nginx 和tomcat 整合 转了一篇文章 不错 没有亲测
打开浏览器访问a.com结果，刷新会发现所有的请求均分别被主服务器（192.168.5.149）分配到B服务器（192.168.5.27）与C服务器（192.168.5.126）上，实现了负载均衡效果。
B服务器处理页面
C服务器处理页面
假如其中一台服务器宕机会怎样？
当某台服务器宕机了，是否会影响访问呢？
我们先来看看实例，根据以上例子，假设C服务器192.168.5.126这台机子宕机了（由于无法模拟宕机，所以我就把C服务器关机）然后再来访问看看。
访问结果：
我们发现，虽然C服务器（192.168.5.126）宕机了，但不影响网站访问。这样，就不会担心在负载均衡模式下因为某台机子宕机而拖累整个站点了。
如果b.com也要设置负载均衡怎么办？
很简单，跟a.com设置一样。如下：
假设b.com的主服务器IP是192.168.5.149，负载均衡到192.168.5.150和192.168.5.151机器上
现将域名b.com解析到192.168.5.149IP上。
在主服务器(192.168.5.149)的nginx.conf加入以下代码：
upstream b.com {
server 192.168.5.150:80;
server 192.168.5.151:80;
}
server{
listen 80;
server_name b.com;
location / {
proxy_pass http://b.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重启nginx
在192.168.5.150与192.168.5.151机器上设置nginx，打开nginx.conf在末尾添加以下代码：
server{
listen 80;
server_name b.com;
index index.html;
root /data0/htdocs/www;
}
保存重启nginx
完成以后步骤后即可实现b.com的负载均衡配置。
主服务器不能提供服务吗？
以上例子中，我们都是应用到了主服务器负载均衡到其它服务器上，那么主服务器本身能不能也加在服务器列表中，这样就不会白白浪费拿一台服务器纯当做转发功能，而是也参与到提供服务中来。
如以上案例三台服务器：
A服务器IP ：192.168.5.149 （主）
B服务器IP ：192.168.5.27
C服务器IP ：192.168.5.126
我们把域名解析到A服务器，然后由A服务器转发到B服务器与C服务器，那么A服务器只做一个转发功能，现在我们让A服务器也提供站点服务。
我们先来分析一下，如果添加主服务器到upstream中，那么可能会有以下两种情况发生：
1、主服务器转发到了其它IP上，其它IP服务器正常处理；
2、主服务器转发到了自己IP上，然后又进到主服务器分配IP那里，假如一直分配到本机，则会造成一个死循环。
怎么解决这个问题呢？因为80端口已经用来监听负载均衡的处理，那么本服务器上就不能再使用80端口来处理a.com的访问请求，得用一个新的。于是我们把主服务器的nginx.conf加入以下一段代码：
server{
listen 8080;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}
重启nginx，在浏览器输入a.com:8080试试看能不能访问。结果可以正常访问
既然能正常访问，那么我们就可以把主服务器添加到upstream中，但是端口要改一下，如下代码：
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
server 127.0.0.1:8080;
}
由于这里可以添加主服务器IP192.168.5.149或者127.0.0.1均可以，都表示访问自己。
重启Nginx，然后再来访问a.com看看会不会分配到主服务器上。
主服务器也能正常加入服务了。
最后
一、负载均衡不是nginx独有，著名鼎鼎的apache也有，但性能可能不如nginx。
二、多台服务器提供服务，但域名只解析到主服务器，而真正的服务器IP不会被ping下即可获得，增加一定安全性。
三、upstream里的IP不一定是内网，外网IP也可以。不过经典的案例是，局域网中某台IP暴露在外网下，域名直接解析到此IP。然后又这台主服务器转发到内网服务器IP中。
四、某台服务器宕机、不会影响网站正常运行，Nginx不会把请求转发到已宕机的IP上