-
Nginx的高危漏洞
[Nginx]post by Holmesian / 2011-8-26 12:32 Friday这个貌似从昨天晚上开始就很热了,主要是针对Nginx+FastCGI组合跑PHP的环境,原因是传递变量不统一(Ngnix在遇到%00空字节时与FastCGI处理不一致,导致可以在图片中嵌入PHP代码然后通过访问××××.gif%00.php来执行其中的php代码)受影响的Nginx版本:nginx 0.5.*nginx 0... -
更改Nginx的原生错误提示
[Nginx]post by Holmesian / 2010-11-14 11:19 Sunday一般网站前端使用Nginx时,不可避免地会遇到一些类似502、504、404、403等等的错误,这些生硬的错误提示看上去给人的感觉有些不太友好,虽然对于一些常见的错误页面比如404可以在Nginx的配置文件中指定错误页面,但是这只能解决一部分问题而且相对比较繁琐,实际上我们可以通过修改Nginx的源码让Nginx提供原生的友好的HTML提示。
来看看吧
-
Nginx上传目录禁止PHP运行
[Nginx]post by Holmesian / 2010-11-12 19:59 Friday为了安全起见,我们一般会对上传目录禁止运行php脚本
在apache下面我们可以通过:<Directory /website/attachments>php_flag engine off</Directory>的方式来来禁用目录下文件php执行权限。那么在nginx里面同样可以实现这种方法,那就是location的优先匹配,关于location可以参考刚才的文章这里简单就举个例子location ^~ /attachments/{access_log off;}这样 attachments这个目录 就不会再去跳转给fastcgi去执行php了.这里利用了nginx下location指令的处理顺序优先级特点.但上面的方法只能算一种技巧,一般不这样设置,正确的方法为:location /upload/ {
location ~ .*\.(php)?$
{
deny all;
}
}
而对于多个目录的话,可以一起进行限定:location ~* ^/(attachments|images)/.*\.(php|php5)$
{
deny all;
} -
Nginx的location用法备忘
[Nginx]post by Holmesian / 2010-11-12 19:49 FridayNginx的配置文件相当的漂亮,配合适当的缩进和约定的格式看起来跟漂亮的代码一样。
Nginx中最基本也是最实用的一个命令就是location了,location必须放在server中,现在摘录一些相关的文档以备忘。
-
Nginx解决“no resolver defined to resolve xxx.xxx”
[Nginx]post by Holmesian / 2010-8-25 10:31 Wednesday在Ngnix中如果用变量作为反向代理的地址时,容易出现“no resolver defined to resolve xxx.xxx”的问题,例如:
-
解决Nginx下二级目录斜杠问题
[Nginx]post by Holmesian / 2010-3-13 10:32 Saturday不少网站页面习惯于在URL中的目录名后不加斜杠“/”,这在在apache下会自动添加一个斜杠从而不会造成什么问题,但是如果URL中的二级目录名后不加斜杠的话在Nginx下就会出现403 Forbidden的问题。在网上找到的比较可靠的原因供以想深究的TX进行参考:
在某些情况下(具体可参考 wiki.nginx.org),Nginx 内部重定向规则会被启动,例如,当 URL 指向一个目录并且在最后没有包含“/”时,Nginx 内部会自动的做一个 301 重定向,这时会有两种情况:
1、 server_name_in_redirect on(默认),URL 重定向为: server_name 中的第一个域名 + 目录名 + /;
2、 server_name_in_redirect off,URL 重定向为: 原 URL 中的域名 + 目录名 + /。
当你有多个 域名要指向同一个虚拟主机,并且你自己写 301 重定向规则把它们合并到某一个域名时,情况就更复杂了:
首先,nginx 检查 URL,如果符合条件,就用该规则(你写的)做第一遍重定向,接着,检查新生成的 URL,如果符合内部自动重定向之条件,就用前面提到的规则再做一次重定向。
至于 PHP 的 $_SERVER["SERVER_NAME"],在 nginx 中默认是由 nginx 的变量 $server_name 提供,这时它和重定向没有关系,始终是 server_name 设置中的第一个域名,但这是可以被改变的,在你的 nginx 配置中找到 fastcgi_param 部分,修改
fastcgi_param SERVER_NAME $server_name;
为
fastcgi_param SERVER_NAME $host;
但 现在就要注意了,此时的 $_SERVER["SERVER_NAME"] 会受你写的和 nginx 自己的重定向规则所影响而变化。
现 在就清楚了,如果 MediaWiki 是通过 $_SERVER["SERVER_NAME"] 来自己处理 URL 的话,那么在 nginx + php 的默认环境下,它获得的将始终是 server_name 设置中的第一个域名,所以造成了“不管通过什么域名访问 MediaWiki 首页,都会被跳转到其中的一个域名上。”,这不是 nginx 的重定向造成的,虽然默认 server_name_in_redirect 是 on,但这个指令的影响范围仅仅只是 nginx 自己内部的重定向规则。 -
Nginx下做永久重定向的简单方法
[Nginx]post by Holmesian / 2010-3-12 17:18 Friday有不少TX可能因为一些原因(比如说天朝的cn域名不停政策变化等)从cn域名转换到了其他域名,但是原来使用的cn域名可能已经积攒了大量的搜索引擎亲和因子,在各大搜索引擎被收录了上万的页面,冒然的直接启用新域名会显得得不偿失。所以这个时候通过一些方法最大可能地保存原来已经有的一些网页资源是势在必行的事情。
...
-
FreeBSD+nginx+spawn-fcgi出错的解决
[Nginx]post by Holmesian / 2010-2-1 13:34 Monday终于解决FreeBSD下Nginx做前端 FastCGI的PHP出现问题的情况了,原因很囧
过程如下:
ecjtu# whereis php-cgi
php-cgi: /usr/local/bin/php-cgi
ecjtu# spawn-fcgi -a 127.0.0.1 -p 139 -C 64 -f /usr/local/php/bin/php-cgi
spawn-fcgi: child exited with: 127
ecjtu# spawn-fcgi -a 127.0.0.1 -p 139 -C 64 -u www -f /usr/local/bin/php-cgi
spawn-fcgi: child exited with: 13
ecjtu# spawn-fcgi -a 127.0.0.1 -p 139 -C 64 -U www -f /usr/local/bin/php-cgi
spawn-fcgi: child spawned successfully: PID: 39766
现在OK了
莫非127错误是php-cgi位置错误 13错误是大写U写成了小写u