try_files 是 Nginx 自0.6.36 新增的 directive。通常对 try_files 的理解是——它是 if (!-e $request_filename) { rewrite .* /index.php; } 的更简洁的表达。但我发现它们之间还是略有区别，主要表现在两点： 如使用 rewrite，Nginx 要求 document_root 下必须有一个 index 文件，即使我把另一个目录别名整个 document_root，但因为 Nginx 先校验 document_root 下是否有一个 index 文件，所以得放置一个空 index 文件。try_files 则没有 index 文件校验，直接去第二、第三… document_root 找对应的文件。 如使用 try_files $uri $uri/ /index.php，index.php 不能取得 get 变量，例如在 Magento 下，对 http://mydomain/catalogname?mode=list 的访问不能起效，Nginx 交付的页面是 http://mydomain/catalogname。这时必须使用 rewrite。这或许是 try_files 的一个… Continue reading Difference of try_files to rewrite in Nginx
Tag: nginx
Varnish vs Nginx
Fedora 10 release note 提及 Varnish，据说“Varnish 是一个高性能 HTTP 加速器”，又看了一些其他网站的介绍，据说比 squid 快了好几倍。squid 是什么？没听说过。但既然同是反向代理服务器，Varnish 和 Nginx 相比如何？ 我没实测，但引用别人的测试结论： 根据 Connection Times 获知 Varnish 连接速度快于 Nginx，但 Nginx 处理速度快于 Varnish，等待时间几乎一致，总时间 Nginx 要快于 Varnish 15%左右。 根据 HTML transferred 项获知大负载下 Varnish存在较多的丢包问题。 我想我还是坚持走 Nginx，并走好它。
Config CentOS to use the latest software
1and1 VPS OS 可选清单里没有 Fedora，不得不说是个遗憾。当然 CentOS 也不错，可是以前都没接触，使用 CentOS 会有很长的学习过程，但没办法，只能装个 CentOS 用用看。 以前我调查过，CentOS 讲究兼容性，Fedora 追求技术领先。CentOS 安装真得比当初装 Fedora 要容易（Fedora 从6开始到10，我没有一次是一次启动就安装成功的），今天装CentOS 5很顺利（CentOS 兼容性真的那么好？还是我从 Fedora 学来的经验丰富了？） 装完 CentOS，我就面临一个问题：不能 yum install nginx；yum install php 得来的版本也只是 5.1.6。这个简单的比较才觉得 Fedora 的好。我无法想象我还要下载编译 nginx（那一套我还不熟，怕搞砸了）。不过，Extra Packages for Enterprise Linux (EPEL) 已经做好了一个 repository，只要添加这个 repository， sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5Server/x86_64/epel-release-5-3.noarch.rpm 然后就可以用 yum install nginx。 但是，yum install php 得来的版本只能是 5.1.6，目前还没找到好办法。
Create a password file for Nginx basic authentication
It is really a hard time for me to find a way to create a password file for Nginx basic authentication, because I did not realise htpasswd crpty is not available on Windows. Nginx documentation only mentions Use crypt(3) encryption for passwords, so I tried so hard with htpasswd.exe but could not generate a file… Continue reading Create a password file for Nginx basic authentication
Perfect settings for Magento on Nginx
Nginx 的文档不够详细，挺折腾人的。我经过两天181次黑匣试验，终于敢说入了 Nginx 的门。摸清 Nginx 的思路以后，才体会到它的先进性（不仅是效率上的）。php 和 nginx 搭配使用，感觉就不那么草根了，更容易借鉴 python 的 web infrastructure. 从 Apache 到 Ngnix，不容易啊。难就难在要抛弃 Apache 的思维，其实同样的配置在 Nginx 总能做到的，而且更简洁。在Apache 下，我用 symbolic link 实现 Magento 和 WordPress 等一次安装多处使用，当时我认为已经是很简单的解决方案了；转移到 Nginx 平台，多处使用连 symblic link 也省了。 以下是 Magento on Nginx 的配置，perfect，可以以不变应万变，目前我挺得意的。别笑我，这么几行配置，折腾我两天。
My understanding to Nginx so far
Location directive 没有fallback 机制。因为一个 request 只能匹配一个 location，不是常规 location 的话，就是正则表达式 location。假如有两个 location blocks， location / { index index.php; } location /abc { client_max_body_size 32m; } 请别指望 index index.php 会在location /abc 生效。因为这是两个 location，只能有一个生效，另一个被忽略。 正则表达式 location 优先于常规 location 匹配（除非常规 location 使用 ^~ 或 =）；常规 location 之间最长匹配优先；正则表达式 location 之间位置在前优先。 Nginx wiki 文档里关于 location 用到的 “searching stops” 这个词很不恰当，挺误导初学者的思维，让人误以为会有两个或两个以上 location同时生效。 正则表达式 location 以… Continue reading My understanding to Nginx so far
Different syntax in Nginx and Apache
今天发现一个 Nginx 和 Apache 看似细微却影响巨大的语法差异： 在 Apache 里重定向一个域名到另一个域名， RewriteRule (.*) http://destination.com/$1 [r=301,l] 而在 Nginx 里，应该多加一个斜杠/，否则 $1就多了一个斜杠。 rewrite ^/(.*) http://destination.com/$1 permanent;
From Apache to Nginx
我感觉配置 nginx 渐入佳境了。配置 nginx 时应该用不同 apache 的思维，最主要的不同点是： apache 是 fallback 式配置，比如有两个 <directory> block，分别是 mydirectory 和 mydirectory/subdir。mydirectory/subdir 可以重写 mydirectory 的 directives，但 mydirectory/subdir 没有提到的 directives 就沿袭 mydirectory 的 directives。 nginx 是 parallel 式配置，location 只能按优先规则取其一。 另外，我觉得有人批评 apache 层层检测 .htaccess 造成效率低下的一个原因。我感觉这种说法并不妥，很多 apache 发行版默认 allowoverride none，用户只要根据需要在确实需要启用 .htaccess 的那一层启用 allowoverride，这并不造成效率损失，反而带来配置的灵活性。当然，nginx 不需要这种灵活性，因为它不是面向 share hosting 的产品。 除了内存占用大是 apache 的硬伤，其他 nginx 的优势并不明显，apache 同样可以优化配置达到相应的效果，尽管很多配置不是 apache… Continue reading From Apache to Nginx
nginx has no path_info
ngnix 0.6.35 没有实现 path_info。不知道 nginx 开发者是疏忽了，还是觉得没必要在 http server 层实现 path_info。我印象中有很多 php 程序的运行都依赖 $_SERVER[‘PATH_INFO’]，所以在 ngnix proxy pass 给 php-cgi 之前，必须设置好正确的 path_info 参数。 我认为最好的办法还是用正则表达式在 $fastcgi_script_name 里隔离出 script_name 和 path_info，但这样计算出的 path_info 用起来不如 ngnix variable 方便，而且得在脚本的安装位置或扩展名确定时才能写出相应的正则表达式。我是 nginx 新手，在 path_info 上折腾了三天才总结出一个相对满意的方案。如果 nginx 能给我一个 in-built variable $path_info，那会省事很多。 当然我并不想责怪 nginx（apache 已经够令人称赞了，nginx 能超越它实属不易），说不定 nginx 不搞 path_info 有它的道理。 既然这样，php 编程时就应该考虑到 path_info 是不可靠的。以前我不太注意环境参数的获得性，如今审视了一下，除了 $_SERVER[‘PATH_INFO’]以外，$_SERVER[’PHP_SELF’] 和… Continue reading nginx has no path_info