NGINX 中文站

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:8001;
server 127.0.0.1:8002;
ip_hash;
}

ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用：

1/ nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用 的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。

2/ 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.oschina.net/discuss/thread/622

在文档中是使用$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

以前介绍过Nginx的Rewrite配置这篇文章，今天无意间发现了，这个自动转换程序。

http://www.anilcetin.com/convert-apache-htaccess-to-nginx/

此地址里面的内容包含可以完成上面说的略做修改的功能。自动把.htaccess中的规则转换成nginx下面可用的规则。
很好用，推荐

比如要对 网站目录下的 www 文件夹 进行加密认证

那么 在 nginx.conf 文件中对应的 server 段中 添加引用:
location ^~ /www/ {
auth_basic “TEST-Login”;
auth_basic_user_file /root/htpasswd;
}再在 root 的主目录中 /root/ 创建一个新文件 htpasswd
此文件的书写格式是
用户名:密码
每行一个账户
并且 密码必须使用函数 crypt(3) 加密

官方档说 可以用 Apache 的 htpasswd 工具来创建密码文件
当然也可以使用perl 创建密码文件 新建 一个 pw.pl 文件 其内容：引用:
#!/usr/bin/perl
use strict;

my $pw=$ARGV[0] ;
print crypt($pw,$pw).”\n”;然后执行引用:
chmod +x pw.pl
./pw.pl password
papAq5PwY/QQMpapAq5PwY/QQM 就是password 的crypt()密码
然后 将上面用 perl 生成的 加密后的密码
按照
用户名:密码
的格式写到 htpasswd 文件中

这样既完成了设置

如果 不用
^~ /www/
而用
/www
的话 那么 将只能对目录进行验证 直接访问其下的文件 将不会弹出登录验证

还有 htpasswd 这个文件的名字可以 自己随意设置
用户名 也是 自己随意设置 无需加密
密码必须使用函数 crypt(3) 加密

NGINX 502 Bad Gateway错误是FastCGI有问题，造成NGINX 502错误的可能性比较多。将网上找到的一些和502 Bad Gateway错误有关的问题和排查方法列一下，先从FastCGI配置入手：

1.查看FastCGI进程是否已经启动
NGINX 502错误的含义是sock、端口没被监听造成的。我们先检查fastcgi是否在运行

2.检查系统Fastcgi进程运行情况
除了第一种情况，fastcgi进程数不够用、php执行时间长、或者是php-cgi进程死掉也可能造成nginx的502错误
运行以下命令判断是否接近FastCGI进程，如果fastcgi进程数接近配置文件中设置的数值，表明worker进程数设置太少
netstat -anpo | grep “php-cgi” | wc -l

3.FastCGI执行时间过长
根据实际情况调高以下参数值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

4.头部太大
nginx和apache一样，有前端缓冲限制，可以调整缓冲参数
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
如果你使用的是nginx的负载均衡Proxying，调整
proxy_buffer_size 16k;
proxy_buffers 4 16k;
参见：http://www.ruby-forum.com/topic/169040

5.https转发配置错误
正确的配置方法
server_name www.mydomain.com;
location /myproj/repos {
set $fixed_destination $http_destination;
if ( $http_destination ~* ^https(.*)$ )
{
set $fixed_destination http$1;
}
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Destination $fixed_destination;
proxy_pass http://subversion_hosts;
}
参见：http://www.ruby-forum.com/topic/169040

当然，还要看你后端用的是哪种类型的FastCGI，我用过的有php-fpm，流量约为单台机器40万PV(动态页面), 现在基本上没有碰到502。