注意error_log off并不能关闭日志记录功能，它将日志文件写入一个文件名为off的文件中，如果你想关闭错误日志记录功能，应使用以下配置：

error_log /dev/null crit;

worker_processes 1;
events {
        worker_connections 1024;
}

http {
        include         mime.types;
        default_type    application/octet-stream;
        sendfile        on;
        keepalive_timeout 65;
        geo $cmccip {
                default 1;　　　#　未定义ip的值为1
                include cmcc.conf; 加载geo.conf文件，这个文件定义移动网关ip
        }
        server {
                listen 801;
                server_name XXXXX;
                location / {
                        if ($cmccip) {
                                rewrite ^ http://tx.com.cn;   未定义ip即非移动ip重定向到tx.com.cn;
                        }
                        root /data/www;
                        index index.wml index.html;

                }
        }
}

cmcc.conf文件内容如下：
211.136.222.90/32 0;

HK 访问起来速度还是不错的，但宽带很少，最大只有2M，超过的话访问会越来越慢。

我在广州设立了squid缓存服务器的架构，分发了所有静态文件。基本上HK 就只有主页的php 传输了。
但这也不小，用 Firebug 查看，首页基本上都有10K 再+上其余的重定向数据。再小20K 左右走不掉。

经过调优，强制启用了Nginx反向代理中也使用 gzip，即 （内陆Nginx） –> gzip –> （香港Nginx） –> gzip –> 用户

流量缩少了10% 但还是处于紧张边缘。
查看 HTTP 访问日志，得出有 google baidu 等蜘蛛抓得也挺狠！于是想到，能不能把搜索引擎的爬虫也从定向到内陆的服务器减少负担？

于是就有了以下这个 Nginx 的配置：

香港配置：

        if ($http_user_agent ~* (baiduspider|googlebot|soso|bing|sogou|yahoo|sohu-search|yodao|YoudaoBot|robozilla|msnbot|MJ12bot|NHN|Twiceler)) {
            rewrite  ^/(.*)$  http://gznow.spider.someqone.com/$1  permanent;
        }
直接+到 server {   里头即可。意思为：
匹配客户端User agent 不分大小写，凡是含有 baidu，google，bing….
之类爬虫。从定向到指定地址，并匹配原有 url 后续 即:

http://www.gznow.org/bbs/index.php
301 从定性为：
http://gznow.spider.someqone.com/bbs/index.php

这样的话既不影响搜索引擎的收录，也可以把流量分配给其他的服务器。
但如果日后搜索引擎收录的访问地址也成了从定向的地址咋办？
所以就要再多一步，把从定向的目的服务器配置一下：

        if ($http_user_agent ~* (Safari|Navigator|Chrome|Opera|Firefox|msie)) {
            rewrite  ^/(.*)$  http://www.gznow.org/$1  permanent;
        }

也是直接加到 server { 即可
原来跟处理爬虫的一样，不分大小写匹配 user agent 中包含的主流浏览器 msie , firefox , chrome….
从定向到指定地址，并匹配原有 url 后续.
这样即使访客由搜索引擎指引到了从定向的服务器，也能从定向回去。

呵，特殊例子，分享一下。
这么一作，我HK 服务器的流量可立马又省下了 30% 。 放心了不少。

squid不支持常见的gzip压缩的原因，有以下两点:

1,   squid只支持gzip的静态压缩，不支持动态压缩。具体一点说，就是response header里必须有content-length, 不可以用chunked方式。

2,   response header中必须有Vary : Accept-Encoding

只要具备以上几点，squid就可以完美的识别压缩和不压缩的内容。

下面说一下nginx针对这个问题的解决方案:

nginx默认的NginxHttpGzipModule, 采用的是chunked方式的动态压缩，而squid是不支持的。需要使用http_gzip_static_module这个模块，进行pre-compress。

具体方法如下:

ngx_http_gzip_static_module was introduced in nginx 0.6.24. You must enable support at compile time:

./configure –with-http_gzip_static_module …

配置文件写法:

gzip          on

gzip_static on;

gzip_http_version 1.0;
gzip_proxied        any;
gzip_disable        “MSIE [1-6]\.”;

gzip_comp_level     9;

注意，这里没有加入gzip_vary on;。这是因为http_gzip_static_module这个模块，只给没压缩的内容加入了vary header，而不是所有内容都加。
所以不能打开这个参数。可以在nginx.conf中手动设置vary header。这样不管压缩与否，返回的文件都会被加上Vary: Accept-Encoding。

至此，nginx的gzip压缩，就能够被squid完美支持了。如果你使用Http1.0，就会返回你没压缩的内容。如果你使用http1.1，并且发送Accept-Encoding:gzip,deflate，就会返回压缩后的内容。

PS: 我又发现了一个问题，就是squid的cache保存问题。按照文档上说，squid是根据url来缓存对象的。
   也就是说，一个url应该只保留一个cache。如果你交替的申请压缩的和不压缩的内容，是会出现反复MISS的情况的。
   但是我实际测试的过程中，发现不是这样的，交替的申请压缩的和不压缩的内容，是会一直HIT的。这说明squid是同时保存两份cache的(压缩的和不压缩的)。

但这里就有个怪点子，能不能让客户端无论有没有发送Accept-Encoding，服务器都会发送压缩内容呢？

这有几个好处：

1、进一步节省带宽。
2、防止水平一般的爬虫抓页面偷数据。

经测试，此种做法并不会影响普通用户，因为他们都是用先进的浏览器上网的；另外，也不会影响主流的搜索引擎，收录仍然会正常。

要做到这点，需要有两个nginx，但也有办法配置两个虚拟主机就可以，不用启动两个nginx主进程。为了方便，我就以前后来区分它们。

前端nginx：

gzip压缩不在前端nginx进行，前端主要是用来强制修改request header，即写上：

这样，后台的nginx无论如何都将接收到Accept-Encoding:gzip，而不管客户端有没有发。

完整的测试样本：

1. server 127.0.0.1:80;
2. }
3. server {
4. server_name www.gznow.org;
5. listen 80;
6. location / {
7.   proxy_pass http://219.x.x.x;
8.   include proxy.conf;
9.   proxy_set_header Accept-Encoding ‘gzip’;
10. }
11. }

要注意proxy.conf里最好没有写过proxy_set_header Accept-Encoding，我的proxy.conf默认有将Accept-Encoding设为空的，这会造成配置重复。但proxy_set_header不会冲突，可以按配置先后顺序生效，我一时忘了是前生效还是后生效，动手测一下便知。

后端nginx：

后端nginx才是负责压缩的，这里要注意gzip的版本，因为nginx是用http1.0方式作代理，因此gzip的版本就不能是默认的1.1版，改成1.0。

1. server {
2. server_name www.gznow.org;
3. listen 80;
4. location / {
5.   root /html/;
6.   gzip on;
7.   gzip_http_version 1.0;
8. }
9. }

这里就简单点了，gzip的其他参数我就不贴上来，想必大家都有现成的配置，留意下version就好。

配好后，测试一下：

1. curl -I http://www.gznow.org/bbs/index.php

发现返回了Content-Encoding:gzip

不加-I参数呢？

1. curl http://www.gznow.org/bbs/index.php

打印出一堆乱码，把SecureCRT的字符都给弄坏了。

也可以通过以下工具来测试压缩成效 http://gzip.zzbaike.com/

例如主站上有动态文件，也有静态文件。
为了让用户有更快速的体验，一般都会把动态文件的请求跟静态文件分开。
把流量分摊给其他外部节点的 squid 服务器等。

这么我就分享一个配置，不用对程序做任何改动，就可实现静态文件重定向。

        location ~* \.(gif|jpg|png|swf|flv|rar|zip|exe|bmp)$ {
            rewrite  ^/(.*)$  http://img.gxxxx.cn:1394/$1  permanent;
        }

修改后的结果是：

当访问： http://www.gxxxx.cn/bbs/photo/logo.gif
即永久从定向至：http://img.gxxxx.cn:1394/bbs/photo/logo.gif

为了安全，可以关闭这些信息。

方法很简单，只需在 nginx.conf 的 http {  里头加入 server_tokens 的参数
例如：

http {
    include       mime.types;
    default_type  application/octet-stream;
    server_tokens off;     #关闭版本显示
    client_header_timeout       3m;
    client_body_timeout         3m;
    send_timeout                3m;

使用 curl 工具测试结果如下：

HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Fri, 11 Dec 2009 01:47:53 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Keep-Alive: timeout=20
Location: http://www.gznow.cn/index

如果想把 Server 所显示的名称也修改，可以参阅：http://www.oschina.net/bbs/thread/1568?lp=1

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.ABC.com;

}

修改一下。

server {

listen 192.168.3.3:80;       #指定Nginx只占用某个IP的80端口。
listen 192.168.10.3:80;           #如果你服务器中有多个IP，还可以指定多个。
server_name www.ABC.com;

}

如果你在Nginx有多个虚拟主机，每一个都需要这么修改。

然后轮到 apache 的 httpd.conf

把原来的

Listen 80

改为

Listen 127.0.0.1:80

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

如：

NameVirtualHost *:80

<VirtualHost *:80>
    ServerAdmin hello@abc.com
    DocumentRoot /data/web_server/admin
    ServerName www.ABC.com
</VirtualHost>

这样，Nginx 跟 Apache 就仅会占用指定IP的80端口，不会冲突。
只要调整一下 Nginx proxy 的参数。
“聪明”应用问题就能解决了。

所以，我们要在 Nginx 配置中把这一目录的访问都拒绝掉。
由于其 .svn 的目录名较为特殊，需要用到正则表达式，写法如下：

        location ~ ^(.*)\/\.svn\/{
        deny all;
        }

同理，.cvs 也需要这样。

这个办法是把nginx的404错误定向到后端，然后用proxy_store把后端返回的页面保存。

配置：

location / {
root /home/html/;#主目录
expires 1d;#网页的过期时间
error_page 404 =200 /fetch$request_uri;#404定向到/fetch目录下
}

location /fetch/ {#404定向到这里
internal;#指明这个目录不能在外部直接访问到
expires 1d;#网页的过期时间
alias /home/html/;#虚拟目录文件系统地址要和locaion /一致，proxy_store会将文件保存到这目录下
proxy_pass http://www.sudone.com/;#后端upstream地址，/fetch同时是一个代理
proxy_set_header Accept-Encoding ”;#让后端不要返回压缩（gzip或deflate）的内容，保存压缩后的内容会引发乱子。
proxy_store on;#指定nginx将代理返回的文件保存
proxy_temp_path /home/tmp;#临时目录，这个目录要和/home/html在同一个硬盘分区内
}

使用的时候还有要注意是nginx要有权限往/home/tmp和/home/html下有写入文件的权限，在linux下nginx一般会配置成nobody用户运行，这样这两个目录就要chown nobody，设成nobody用户专用，当然也可以chmod 777，不过所有有经验的系统管理员都会建议不要随便使用777。

2、传统缓存之二（!-e）

原理和404跳转基本一致，但更简洁一些：

location / {
root /home/html/;
proxy_store on;
proxy_set_header Accept-Encoding ”;
proxy_temp_path /home/tmp;
if ( !-f $request_filename )
{
proxy_pass http://www.sudone.com/;
}
}

可以看到这个配置比404节约了不少代码，它是用!-f来判断请求的文件在文件系统上存不存在，不存在就proxy_pass到后端，返回同样是用proxy_store保存。

两种传统缓存都有着基本一样的优点和缺点：
缺点1：不支持带参数的动态链接，比如read.php?id=1，因为nginx只保存文件 名，所以这个链接只在文件系统下保存为read.php，这样用户访问read.php?id=2时会返回不正确的结果。同时不支持 http://www.sudone.com/这种形式的首页和二级目录http://www.sudone.com/download/，因为 nginx非常老实，会将这样的请求照链接写入文件系统，而这个链接显然是一个目录，所以保存失败。这些情况都需要写rewrite才能正确保存。
缺点2：nginx内部没有缓存过期和清理的任何机制，这些缓存的文件会永久性地保存在机器上，如果要缓存的东西非常多，那就会撑暴整个硬盘空间。为此可以使用一个shell脚本定期清理，同时可以撰写php等动态程序来做实时更新。
缺点3：只能缓存200状态码，因此后端返回301/302/404等状态码都不会缓存，假如恰好有一个访问量很大的伪静态链接被删除，那就会不停穿透导致后端承载不小压力。
缺点4：nginx不会自动选择内存或硬盘作为存储介质，一切由配置决定，当然在当前的操作系统里都会有操作系统级的文件缓存机制，所以存在硬盘上也不需要过分担心大并发读取造成的io性能问题。

nginx传统缓存的缺点也是它和squid等缓存软件的不同之特色，所以也可看作其优点。在生产应用中它常常用作和squid的搭档，squid 对于带?的链接往往无法阻挡，而nginx能将其访问拦住，例如：http://sudone.com/?和http://sudone.com/在 squid上会被当做两个链接，所以会造成两次穿透；而nginx只会保存一次，无论链接变成http://sudone.com/?1还是http: //sudone.com/?123，均不能透过nginx缓存，从而有效地保护了后端主机。

nginx会非常老实地将链接形式保存到文件系统中，这样对于一个链接，可以很方便地查阅它在缓存机器上的缓存状态和内容，也可以很方便地和别的文件管理器如rsync等配合使用，它完完全全就是一个文件系统结构。

这两种传统缓存都可以在linux下将文件保存到/dev/shm里，一般我也是这么做的，这样可以利用系统内存来做缓存，利用内存的话，清理过期 内容速度就会快得多。使用/dev/shm/时除了要把tmp目录也指向到/dev/shm这个分区外，如果有大量小文件和目录，还要修改一下这个内存分 区的inode数量和最大容量：

mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm

上面的命令在一台有3G内存的机器上使用，因为/dev/shm默认最大内存是系统内存的一半就是1500M，这条命令将其调大成2500M，同时 shm系统inode数量默认情况下可能是不够用的，但有趣的是它可以随意调节，这里调节为480000保守了点，但也基本够用了。

3、基于memcached的缓存

nginx对memcached有所支持，但是功能并不是特别之强，性能上还是非常之优秀。

location /mem/ {
if ( $uri ~ “^/mem/([0-9A-Za-z_]*)$” )
{
set $memcached_key “$1″;
memcached_pass     192.168.1.2:11211;
}
expires 70;
}

这个配置会将http://sudone.com/mem/abc指明到memcached的abc这个key去取数据。

nginx目前没有写入memcached的任何机制，所以要往memcached里写入数据得用后台的动态语言完成，可以利用404定向到后端去写入数据。

4、基于第三方插件ncache

ncache是新浪兄弟开发的一个不错的项目，它利用nginx和memcached实现了一部分类似squid缓存的功能，我并没有使用这个插件的经验，可以参考：

http://code.google.com/p/ncache/

5、nginx新开发的proxy_cache功能

从nginx-0.7.44版开始，nginx支持了类似squid较为正规的cache功能，目前还处于开发阶段，支持相当有限，这个缓存是把链接用md5编码hash后保存，所以它可以支持任意链接，同时也支持404/301/302这样的非200状态。

配置：

首先配置一个cache空间：

proxy_cache_path /path/to/cache levels=1:2 keys_zone=NAME:10m inactive=5m max_size=2m clean_time=1m;

注意这个配置是在server标签外，levels指定该缓存空间有两层hash目录，第一层目录是1个字母，第二层为2个字母，保存的文件名就会 类似/path/to/cache/c/29/b7f54b2df7773722d382f4809d65029c；keys_zone为这个空间起个名 字，10m指空间大小为10MB；inactive的5m指缓存默认时长5分钟；max_size的2m是指单个文件超过2m的就不缓 存；clean_time指定一分钟清理一次缓存。

location / {
proxy_pass http://www.sudone.com/;

proxy_cache NAME;#使用NAME这个keys_zone

proxy_cache_valid 200 302 1h;#200和302状态码保存1小时
proxy_cache_valid 301 1d;#301状态码保存一天
proxy_cache_valid any 1m;#其它的保存一分钟
}

ps：支持cache的0.7.44到0.7.51这几个版本的稳定性均有问题，访问有些链接会出现错误，所以这几个版本最好不要在生产环境中使 用。nginx-0.7下目前所知较为稳定的版本是0.7.39。稳定版0.6.36版也是近期更新，如果在配置里没有使用到0.7的一些新标签新功能， 也可以使用0.6.36版。