Apache与Nginx在同一服务器反向代理共存端口冲突怎么办

Apache与Nginx在同一服务器反向代理共存端口冲突怎么办

很久以前，老王去饭店吃饭，需要先到饭店，七荤八素点好菜，坐等饭菜上桌，然后大快朵颐，不亦乐乎。有了第三方订餐外卖平台（代理），老王懒得动身前往饭店，老王打个电话或用APP，先选好某个饭店，再点好菜，外卖小哥会送上门来。由于某个品牌的饭店口碑特别好，食客络绎不绝涌入，第三方订餐电话也不绝于耳，但是限于饭店接待能力有限，无法提供及时服务，很多食客等得不耐烦了，纷纷铩羽而归，饭店老总看着煮熟的鸭子飞走了，心疼不已。痛定思痛，老总又成立了几个连锁饭店，形成一个集群，对外提供统一标准的菜品服务，电话订餐电话400-xxx-7777，当食客涌入饭店总台，总台将食客用大巴运到各个连锁店，这样食客既不需要排队，各连锁店都能高速运转起来，一举两得，老总乐开了花，并为此种运作模式起名为“反向代理”（Reverse Proxy)。反向代理在计算机世界里，由于单个服务器的处理客户端（用户）请求能力有一个极限，当用户的接入请求蜂拥而入时，会造成服务器忙不过来的局面，可以使用多个服务器来共同分担成千上万的用户请求，这些服务器提供相同的服务，对于用户来说，根本感觉不到任何差别。
一个典型的 Nginx + Apache 应用方案可以是Nginx 占用 80 端口，过滤静态请求，然后动态请求即 Proxy 到 Apache 的 8080 端口。Proxy 反向代理的好处是访问的时候，始终就是 80 端口，来访者不会觉察到有任何的区别。


但有的应用确非常“聪明”，识别到 Apache 所位于的端口是 8080 ，就会把相关的超链接都一并加上 :8080 的后续。这么就死定了，还能有正常访问麽？！


有个方法可以解决这事，就是把 apache 也运行在80端口上。同一台服务器，有Nginx 也有 Apache，2个httpd服务，都是80，不会冲突麽？


下边就是举例方法。
Nginx.conf 的配置中


server {
 listen 80;
 server_name www.xmc9.com;
}
修改一下。


server {
 listen 192.168.3.3:80;  #指定Nginx只占用某个IP的80端口。
 listen 192.168.10.3:80;  #如果你服务器中有多个IP，还可以指定多个。
 server_name www.xmc9.com;
}
如果你在Nginx有多个虚拟主机，每一个都需要这么修改。


然后轮到 apache 的 httpd.conf
把原来的


Listen 80
改为


Listen 127.0.0.1:80
跟Nginx一样，指定apache所占用的IP及端口。
保存退出，重启apache即可生效。
如果你 apache 上也有多个虚拟主机。无需好像Nginx那样逐一修改，只要都是 80 端口既可。


如：


NameVirtualHost *:80

 ServerAdmin [email protected]
 DocumentRoot /data/web_server/admin
 ServerName www.xmc9.com

这样你是不是以为，就已经万事大吉了？非也。


这样的apache只能通过http://127.0.0.1:80才能访问，那么他还占用80端口就没有意义了。还不如apache用8080，nginx用80算了。
所以此时如果你的服务器有多ip，除了把apache绑定在 127.0.0.1 还能绑定另外一张网卡的IP，那么问题就解决。


可是一般人都是只有一个独立ip的，所以这种方法对很多人来讲就是海市蜃楼。
修改一种思路，apache还是8080端口，修改其中的一个nginx的域名的conf文件


location / {
 try_files $uri @apache;
}
  
location @apache {
 internal;
 proxy_pass http://127.0.0.1:8080;
}
  
location ~ .*.(php|php5)?$ {
 proxy_pass http://127.0.0.1:8080;
}
此时，该域名全部动作都走Apache了，包括静态文件。


也有很多人下面这种写法：


upstream zend {
 server 127.0.0.1:8080;
}
  
location / {
 proxy_pass  http://zend;
 proxy_redirect   off;
 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-Scheme $scheme;
}
  
location ~ .*.(php|php5)?$ {
 proxy_pass  http://zend;
 proxy_redirect   off;
 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-Scheme $scheme;
}
大体类似。


Nginx的端口修改
修改 nginx.conf 文件实现。在 Linux 上该文件的路径为 /usr/local/nginx/conf/nginx.conf，Windows 下 安装目录\conf\nginx.conf。


server {
 listen  80;
 server_name localhost;
  
 ……
}
改成


server {
 listen  81;
 server_name localhost;
  
 location / {
 root html;
 index index.html index.htm;
 }
 ……
}
当然改成 8080，8081 什么的都可以，不一定要 81，但是确保 iptable 要放开对该端口的访问。


注意到 location 的配置：


root html; #根目录，相对于安装目录 
index index.html index.htm; #默认主页
默认，你把文件放在安装目录下的 html 文件夹，即可通过 Nginx 访问。


Apache与Nginx的优缺点比较 
1、nginx相对于apache的优点： 
轻量级，同样起web 服务，比apache 占用更少的内存及资源 
抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能 
高度模块化的设计，编写模块相对简单 
社区活跃，各种高性能模块出品迅速啊 
apache 相对于nginx 的优点： 
rewrite ，比nginx 的rewrite 强大 
模块超多，基本想到的都可以找到 
少bug ，nginx 的bug 相对较多 
超稳定 
存在就是理由，一般来说，需要性能的web 服务，用nginx 。如果不需要性能只求稳定，那就apache 吧。后者的各种功能模块实现得比前者，例如ssl 的模块就比前者好，可配置项多。这里要注意一点，epoll(freebsd 上是 kqueue )网络IO 模型是nginx 处理性能高的根本理由，但并不是所有的情况下都是epoll 大获全胜的，如果本身提供静态服务的就只有寥寥几个文件，apache 的select 模型或许比epoll 更高性能。当然，这只是根据网络IO 模型的原理作的一个假设，真正的应用还是需要实测了再说的。 


2、作为 Web 服务器：相比 Apache，Nginx 使用更少的资源，支持更多的并发连接，体现更高的效率，这点使 Nginx 尤其受到虚拟主机提供商的欢迎。在高连接并发的情况下，Nginx是Apache服务器不错的替代品: Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一. 能够支持高达 50,000 个并发连接数的响应, 感谢Nginx为我们选择了 epoll and kqueue 作为开发模型. 
Nginx作为负载均衡服务器: Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务, 也可以支持作为 HTTP代理 服务器对外进行服务. Nginx采用C进行编写, 不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多. 
作为邮件代理服务器: Nginx 同时也是一个非常优秀的邮件代理服务器（最早开发这个产品的目的之一也是作为邮件代理服务器）, Last.fm 描述了成功并且美妙的使用经验. 
Nginx 是一个安装非常的简单 , 配置文件非常简洁（还能够支持perl语法）, Bugs 非常少的服务器: Nginx 启动特别容易, 并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动. 你还能够不间断服务的情况下进行软件版本的升级 . 


3、Nginx 配置简洁, Apache 复杂 
Nginx 静态处理性能比 Apache 高 3倍以上 
Apache 对 PHP 支持比较简单，Nginx 需要配合其他后端用 
Apache 的组件比 Nginx 多 
现在 Nginx 才是 Web 服务器的首选 


4、最核心的区别在于apache是同步多进程模型，一个连接对应一个进程；nginx是异步的，多个连接（万级别）可以对应一个进程 


5、nginx处理静态文件好,耗费内存少.但无疑apache仍然是目前的主流,有很多丰富的特性.所以还需要搭配着来.当然如果能确定nginx就适合需求,那么使用nginx会是更经济的方式. 


6、从个人过往的使用情况来看，nginx的负载能力比apache高很多。最新的服务器也改用nginx了。而且nginx改完配置能-t测试一下配置有没有问题，apache重启的时候发现配置出错了，会很崩溃，改的时候都会非常小心翼翼现在看有好多集群站，前端nginx抗并发，后端apache集群，配合的也不错。 


7、nginx处理动态请求是鸡肋，一般动态请求要apache去做，nginx只适合静态和反向。 


8、從我個人的經驗來看，nginx是很不錯的前端服務器，負載性能很好，在老奔上開nginx，用webbench模擬10000個靜態文件請求毫不吃力。apache對php等語言的支持很好，此外apache有強大的支持網路，發展時間相對nginx更久，bug少但是apache有先天不支持多核心處理負載雞肋的缺點，建議使用nginx做前端，後端用apache。大型網站建議用nginx自代的集群功能 


9、Nginx优于apache的主要两点：1.Nginx本身就是一个反向代理服务器 2.Nginx支持7层负载均衡；其他的当然，Nginx可能会比apache支持更高的并发，但是根据NetCraft的统计，2011年4月的统计数据，Apache依然占有62.71%，而Nginx是7.35%，因此总得来说，Aapche依然是大部分公司的首先，因为其成熟的技术和开发社区已经也是非常不错的性能。 


10、你对web server的需求决定你的选择。大部分情况下nginx都优于APACHE，比如说静态文件处理、PHP-CGI的支持、反向代理功能、前端Cache、维持连接等等。在Apache+PHP（prefork）模式下，如果PHP处理慢或者前端压力很大的情况下，很容易出现Apache进程数飙升，从而拒绝服务的现象。 


11、可以看一下nginx lua模块：https://github.com/chaoslaw...apache比nginx多的模块，可直接用lua实现apache是最流行的，why？大多数人懒得更新到nginx或者学新事物 


12、对于nginx，我喜欢它配置文件写的很简洁，正则配置让很多事情变得简单运行效率高，占用资源少，代理功能强大，很适合做前端响应服务器 


13、Apache在处理动态有优势，Nginx并发性比较好，CPU内存占用低，如果rewrite频繁，那还是Apache吧
1.nginx负载均衡
　　网站的访问量越来越大，服务器的服务模式也得进行相应的升级，比如分离出数据库服务器、分离出图片作为单独服务，这些是简单的数据的负载均衡，将压力分散到不同的机器上。有时候来自web前端的压力，也能让人十分头痛。怎样将同一个域名的访问分散到两台或更多的机器上呢？这其实就是另一种负载均衡了，nginx自身就可以做到，只需要做个简单的配置就行。
　　nginx不单可以作为强大的web服务器，也可以作为一个反向代理服务器，而且nginx还可以按照调度规则实现动态、静态页面的分离，可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做负载均衡，同时还支持后端服务器的健康检查。
Nginx负载均衡一些基础知识：
nginx 的 upstream目前支持 4 种方式的分配 
1)、轮询（默认） 
　　每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 
2)、weight 
　　指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 
2)、ip_hash 
　　每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。  
3)、fair（第三方） 
　　按后端服务器的响应时间来分配请求，响应时间短的优先分配。  
4)、url_hash（第三方）
 
2.nginx负载均衡配置,主要是proxy_pass,upstream的使用
在http段做如下配置，即可实现两个域名
 


upstream  www.xmc9.com  
{
    server   10.0.1.50:8080;
    server   10.0.1.51:8080;
}
 
upstream  xmc9.com   
{
    server   10.0.1.50:8080;
    server   10.0.1.51:8080;
}
 
server
{
    listen  80;
    server_name  www.xmc9.com;
 
    location / {
        proxy_pass        http://www.xmc9.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;
    }
}
 
server
{
    listen  80;
    server_name  xmc9.com;
 
    location / {
        proxy_pass        http://www.xmc9.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;
    }
}
 
3.注意的几个小问题
3.1 多台机器间session的共享问题
配置负载均衡比较简单,但是最关键的一个问题是怎么实现多台服务器之间session的共享
下面有几种方法(以下内容来源于网络,第四种方法没有实践.)
1). 不使用session，换作cookie
　　能把session改成cookie，就能避开session的一些弊端，在从前看的一本J2EE的书上，也指明在集群系统中不能用session，否则惹出祸端来就不好办。如果系统不复杂，就优先考虑能否将session去掉，改动起来非常麻烦的话，再用下面的办法。
2). 应用服务器自行实现共享
　　php可以用数据库或memcached来保存session，从而在php本身建立了一个session集群，用这样的方式可以令 session保证稳定，即使某个节点有故障，session也不会丢失，适用于较为严格但请求量不高的场合。但是它的效率是不会很高的，不适用于对效率要求高的场合。
以上两个办法都跟nginx没什么关系，下面来说说用nginx该如何处理：
3).  ip_hash
　　nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，ip_hash是在upstream配置中定义的：
 


upstream backend {
    server 127.0.0.1:8080 ;
    server 127.0.0.1:9090 ;
    ip_hash;
}
　　ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用：
　　nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。
　　nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，或者再搭一个squid，然后指向应用服务器。最好的办法是用location作一次分流，将需要session的部分请求通过ip_hash分流，剩下的走其它后端去。
4). upstream_hash
　　为了解决ip_hash的一些问题，可以使用upstream_hash这个第三方模块，这个模块多数情况下是用作url_hash的，但是并不妨碍将它用来做session共享。假如前端是squid，他会将ip加入x_forwarded_for这个http_header里，用upstream_hash可以用这个头做因子，将请求定向到指定的后端：可见这篇文档：http://www.sudone.com/nginx/nginx_url_hash.html
在文档中是使用$request_uri做因子，稍微改一下：
hash   $http_x_forwarded_for;


这样就改成了利用x_forwarded_for这个头作因子，在nginx新版本中可支持读取cookie值，所以也可以改成：
hash   $cookie_jsessionid;


　　假如在php中配置的session为无cookie方式，配合nginx自己的一个userid_module模块就可以用nginx自发一个cookie，可参见userid模块的英文文档：http://wiki.nginx.org/NginxHttpUserIdModule
　　另可用姚伟斌编写的模块upstream_jvm_route：http://code.google.com/p/nginx-upstream-jvm-route/
3.2 后端服务器自动加上端口的问题

　　一个典型的 Nginx + Apache 应用方案可以是Nginx 占用 80 端口，过滤静态请求，然后动态请求即 Proxy 到 Apache 的 8080 端口。Proxy 反向代理的好处是访问的时候，始终就是 80端口，来访者不会觉察到有任何的区别。但有的应用确非常“聪明”，识别到 Apache 所位于的端口是 8080 ，就会把相关的超链接都一并加上 :8080 的后续。这么就死定了，还能有正常访问麽？！有个方法可以解决这事，就是把 apache 也运行在80端口上。同一台服务器，有Nginx 也有 Apache，2个httpd服务，都是80，不会冲突麽？

nginx.conf 的配置中
 


server {
    listen 80;
    server_name www.xmc9.com;
    ....
}
修改为：
 


server {
    listen 123.123.123.123:80; #指定Nginx只占用某个公网IP的80端口。
    #listen 123.123.123.124:80; #如果你服务器中有多个IP，还可以指定多个。
    server_name www.xmc9.com;
....
}
把 apache 的配置文件 httpd.conf 中的
Listen 80


改为
Listen 127.0.0.1:80


跟Nginx一样，指定apache所占用的IP及端口。

保存退出，重启apache即可生效。

小麦藏阁