nginx文件类型 错误解析漏洞

nginx文件类型 错误解析漏洞
nginx文件类型 错误解析漏洞

漏洞介绍:nginx是一款高性能的web服务器,使用非常广泛,其不仅经常被用作反向代理,也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题,默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析,这将导致严重的安全问题,使得恶意的攻击者可能攻陷支持php的nginx服务器。

漏洞分析:nginx默认以cgi的方式支持php的运行,譬如在配置文件当中可以用这样:

location ~ \.php$ {

root html;

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;

include fastcgi_params;

}

的方式支持对php的解析,location对请求进行选择的时候会使用URI环境变量进行选择,其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name 决定,而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的,这里就是产生问题的点。而为了较好的支持PATH_INFO的提取,在PHP的配置选项里存在cgi.fix_pathinfo选项,其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。

那么假设存在一个https://www.360docs.net/doc/fd7716854.html,/80sec.jpg,我们以如下的方式去访问https://www.360docs.net/doc/fd7716854.html,/80sec.jpg/80sec.php

POC:访问一个nginx来支持php的站点,在一个任何资源的文件如robots.txt后面加上/80sec.php,这个时候你可以看到如下的区别:

访问https://www.360docs.net/doc/fd7716854.html,/robots.txt

HTTP/1.1 200 OK

Server: nginx/0.6.32

Date: Thu, 20 May 2010 10:05:30 GMT

Content-Type: text/plain

Content-Length: 18

Last-Modified: Thu, 20 May 2010 06:26:34 GMT

Connection: keep-alive

Keep-Alive: timeout=20

Accept-Ranges: bytes

访问https://www.360docs.net/doc/fd7716854.html,/robots.txt/80sec.php

HTTP/1.1 200 OK

Server: nginx/0.6.32

Date: Thu, 20 May 2010 10:05:30 GMT

Content-Type: text/plain

Content-Length: 18

Last-Modified: Thu, 20 May 2010 06:26:34 GMT

Connection: keep-alive

Keep-Alive: timeout=20

Accept-Ranges: bytes

其中的Content-Type的变化说明了后端负责解析的变化,该站点就可能存在漏洞。漏洞厂商:https://www.360docs.net/doc/fd7716854.html,

解决方案:

我们已经尝试联系官方,但是此前你可以通过以下的方式来减少损失

关闭cgi.fix_pathinfo为0

或者:

if ( $fastcgi_script_name ~ \..*\/.*php ) {

return 403;

}

PS: 鸣谢laruence大牛在分析过程中给的帮助

原文出处:https://www.360docs.net/doc/fd7716854.html,/nginx-securit.html

Original URL::https://www.360docs.net/doc/fd7716854.html,/nginx/0F22442011.html

系统管理员易犯错误及解决方法汇总

系统管理员易犯错误及解决方法汇总 本文分享的都是系统管理员在工作的时候容易犯的错误,经抚琴煮酒整理并提供解决方法,希望可以给大家一些指导,避免在工作中出现此类问题。作者简介:余洪春,网名抚琴煮酒,英文名Andrew.Yu,武汉某外企高级Linux/Unix系统管理员、项目实施工程师,红帽RHCE 讲师,擅长负载均衡高可用和中小型证券类和商务网站架构,目前关注网站架构研究及网络安全。 一、安装FreeBSD后无法重启 问题描述: 装惯了Linux的人肯定知道一般会有个boot分区,可是在bsd就不那么容易了。在安装FreeBSD 8.1的时候遇到了问题,查阅了chinaunix上面,正好也有相关问题整理,特摘录如下: 我要求FreeBSD分区: 2G For / 4G For swap 10G For /root 256M For /boot 其余 for /usr 安装正常,结果安装重启后便出现杯具了: >> FreeBSD/i386 BOOT Default: 0:da(0,a)/boot/kernel/kernel boot: 原因: 通过网上查资料,了解到手动引导的全过程,发现了问题所在: 由于独立分区/boot造成了FreeBSD引导过程中无法正确找到内核引导的位置。 解决方法: 通过 boot: 0:da(0,e)/loader 可以解决引导问题,然后进入loader界面 *这个引导盘符根据da0s1x 的 x 得来,因此你安装系统的时候/boot所在分区区号,才是真正的x字母,如果不知道就从往后试试 同样由于默认kernel位置是/boot/kernel所以依然需要手动加载 ok load kernel/kernel 获得kernel信息后 ok boot 这样就可以正常引导了。 但是这样还没有彻底解决问题,随后还需要在磁盘挂载的时候输入 mount root>ufs:/dev/da0s1a 才能进入系统,而且每次重启都手动一次。所以其实问题没有彻底解决。 所以,为了避免以上的/boot问题,目前我装机一般规范化操作,一般只分三个区,避免独立分区/boot,也希望玩Linux的朋友们重视下这个问题。 2048M For / 4096M For swap 其余的均For /usr

Nginx 502错误触发条件与解决办法汇总===

Nginx 502错误触发条件与解决办法汇总 一些运行在Nginx上的网站有时候会出现502 Bad Gateway错误,有些时候甚至频繁的出现。有些站长是在刚刚转移到Nginx之后就出现了这个问题,所以经常会怀疑这是不是Nginx的问题,但事实上这是个误区。以... 一些运行在Nginx上的网站有时候会出现“502 Bad Gateway”错误,有些时候甚至频繁的出现。有些站长是在刚刚转移到Nginx之后就出现了这个问题,所以经常会怀疑这是不是Nginx的问题,但事实上这是个误区。 以下是从张宴和Ayou的博客搜集整理的一些Nginx 502错误的排查方法,供大家参考: Nginx 502错误的原因比较多,是因为在代理模式下后端服务器出现问题引起的。这些错误一般都不是nginx本身的问题,一定要从后端找原因!但nginx把这些出错都揽在自己身上了,着实让nginx的推广者备受置疑,毕竟从字眼上理解,bad gateway?不就是bad nginx吗?让不了解的人看到,会直接把责任推在nginx身上,希望nginx下一个版本会把出错提示写稍微友好一些,至少不会是现在简单的一句502 Bad Gateway,另外还不忘附上自己的大名。 Nginx 502的触发条件 502错误最通常的出现情况就是后端主机当机。在upstream配置里有这么一项配置:proxy_next_upstream,这个配置指定了nginx在从一个后端主机取数据遇到何种错误时会转到下一个后端主机,里头写上的就是会出现502的所有情况拉,默认是error timeout。error就是当机、断线之类的,timeout就是读取堵塞超时,比较容易理解。我一般是全写上的: proxy_next_upstream error timeout invalid_header http_500 http_503; 不过现在可能我要去掉http_500这一项了,http_500指定后端返回500错误时会转一个主机,后端的jsp出错的话,本来会打印一堆stacktrace的错误信息,现在被502取代了。但公司的程序员可不这么认为,他们认定是nginx出现了错误,我实在没空跟他们解释502的原理了…… 503错误就可以保留,因为后端通常是apache resin,如果apache死机就是error,但resin死机,仅仅是503,所以还是有必要保留的。 解决办法 遇到502问题,可以优先考虑按照以下两个步骤去解决。 1、查看当前的PHP FastCGI进程数是否够用:

Nginx常见错误与解决方法解读

上海纽斯达科技Nginx常见错误与解决方法 上海纽斯达科技有限公司 2014-10-25

文档状态 目的: 在Nginx 服务器出现故障时,能快速定位并解决相关错误。 保密: 本文档仅供内部使用,请勿外传 概述: Nginx 常见错误与问题之解决方法技术指南。 安装环境: 系统环境:redhat enterprise 6.5 64bit 文件状态: 【 】草稿 【 】修改稿 【√】正式发布 文档编号 Nsdkj-778 保 密 等 级 限制 作 者 刘恒亮 最后完成日期 2014-12-25 审 核 人 最后审核日期 2014-12-25 批 准 人 最后批准日期 2014-12-25

1、Nginx 常见启动错误 有的时候初次安装nginx的时候会报这样的错误 sbin/nginx -c conf/nginx.conf 报错内容:sbin/nginx: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory 启动时如果报异常error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory 这说明我们的环境还不是和启动需要 小小的配置一下 解决方法(直接运行): 32位系统 [root@sever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib 64位系统 [root@sever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64 然后执行ps -ef | grep nginx 查看nginx进程确认是否真的已经启动了,在进程列表里会有最起码两个, worker(nginx工作进程)和master(nginx主进程) root 4349 1 0 02:24 ? 00:00:00 nginx: master process sbin/nginx -c conf/nginx.conf nginx 4350 4349 0 02:24 ? 00:00:00 nginx: worker process root 4356 28335 0 02:30 pts/1 00:00:00 grep nginx NGINX 就 OK了 2、400 bad request错误的原因和解决办法 配置nginx.conf相关设置如下. client_header_buffer_size 16k; large_client_header_buffers 4 64k; 根据具体情况调整,一般适当调整值就可以。 3、Nginx 502 Bad Gateway错误 在php.ini和php-fpm.conf中分别有这样两个配置项:max_execution_time和 request_terminate_timeout。

linux centos安装nginx常见错误及解决办法

1. 安装完成Nginx后无法站外访问? 刚安装好nginx一个常见的问题是无法站外访问,本机wget、telnet都正常。而服务器之外,不管是局域网的其它主机还是互联网的主机都无法访问站点。如果用telnet的话,提示: 正在连接到192.168.0.xxx...不能打开到主机的连接,在端口 80: 连接失败 如果用wget命令的话,提示: Connecting to 192.168.0.100:80... failed: No route to host. 如果是以上的故障现象,很可能是被CentOS的防火墙把80端口拦住了,尝试执行以下命令,打开80端口: iptables -I INPUT -p tcp --dport 80 -j ACCEPT 然后用: /etc/init.d/iptables status 查看当前的防火墙规则,如果发现有这样一条: ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 就说明防火墙规则已经添加成功了,再在站外访问就正常了。 2. 编译pcre错误(源码安装nginx必须先要装pcre) libtool: compile: unrecognized option `-DHAVE_CONFIG_H' libtool: compile: Try `libtool --help' for more information. make[1]: *** [pcrecpp.lo] Error 1 make[1]: Leaving directory `/usr/local/src/pcre-8.21' make: *** [all] Error 2

Nginx 错误处理方法

Nginx (―engine x‖) 是一个高性能的HTTP 和反向代理服务器,也是一个 IMAP/POP3/SMTP 代理服务器。Nginx 是由Igor Sysoev 为俄罗斯访问量第二的Rambler.ru 站点开发的,它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。Nginx 超越Apache 的高性能和稳定性。 Nginx+Tomcat是目前主流的Java web架构,很多公司在使用,Nginx+Tomcat通过简单的配置,可以实现高性能的负载均衡,通过本文学习,可以实现Nginx+Tomcat 负载均衡。 工具资源 1、Java运行环境,JDK 2、Tomcat7.0.65压缩版下载 3、Nginx1.8.1稳定版下载 本文基于win10进行配置 配置步骤 1、JDK环境配置略 2、Tomcat安装配置 请参考:一台服务器安装运行多个Tomcat及注册服务 本测试安装两个Tomcat,端口分别是8801和8802 安装配置完成后请确保每一个Tomcat可以正常访问 为了区分两个Tomcat,本文将第二个Tomcat的页面名称改为:Apache Tomcat/7.0.65-2 3、Nginx配置

1.解压Nginx到D盘根目录 2.修改Nginx配置 #user nobody; worker_processes 1; #工作进程的个数 #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; #单个进程最大连接数} http {

服务器故障解决思路

遇到服务器故障,问题出现的原因很少可以一下就想到。基本上都会从以下步骤入手: 一、尽可能搞清楚问题的前因后果 不要一下子就扎到服务器前面,你需要先搞明白对这台服务器有多少已知的情况,还有故障的具体情况。不然你很可能就是在无的放矢。 必须搞清楚的问题有: ? 故障的表现是什么?无响应?报错? ? 故障是什么时候发现的? ? 故障是否可重现? ? 有没有出现的规律(比如每小时出现一次) ? 最后一次对整个平台进行更新的内容是什么(代码、服务器等)? ? 故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)? ? 基础架构(物理的、逻辑的)的文档是否能找到? ? 是否有监控平台可用? (比如Munin 、Zabbix 、 Nagios 、 New Relic … 什么都可以) ? 是否有日志可以查看?. (比如Loggly 、Airbrake 、 Graylog…) 最后两个是最方便的信息来源,不过别抱太大希望,基本上它们都不会有。只能再继续摸索了。 二、有谁在? 1 2 $ w $ last

用这两个命令看看都有谁在线,有哪些用户访问过。这不是什么关键步骤,不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。(ne cook in the kitchen is enough.) 三、之前发生了什么? 1 $ history 查看一下之前服务器上执行过的命令。看一下总是没错的,加上前面看的谁登录过的信息,应该有点用。另外作为admin 要注意,不要利用自己的权限去侵犯别人的隐私哦。 到这里先提醒一下,等会你可能会需要更新 HISTTIMEFORMAT 环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令,同样会令人抓狂的。 四、现在在运行的进程是啥? 1 2 $ pstree -a $ ps aux 这都是查看现有进程的。 ps aux 的结果比较杂乱, pstree -a 的结果比较简单明了,可以看到正在运行的进程及相关用户。 五、监听的网络服务 1 2 3 $ netstat -ntlp $ netstat -nulp $ netstat -nxlp 我一般都分开运行这三个命令,不想一下子看到列出一大堆所有的服务。netstat -nalp 倒也可以。不过我绝不会用 numeric 选项 (鄙人一点浅薄的看法:IP 地址看起来更方便)。 找到所有正在运行的服务,检查它们是否应该运行。查看各个监听端口。在netstat 显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。 如果服务器上有好几个Java 或者Erlang 什么的进程在同时运行,能够按PID 分别找到每个进程就很重要了。 通常我们建议每台服务器上运行的服务少一点,必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着,那还是做个记录,回头有空的时候清理一下,重新组织一下服务器。

nginx 负载均衡宕机配置

1.摘要 (1)结论 详细描述了nginx记录失效节点的6种状态(time out、connect refuse、500、502、503、504,后四项5XX需要配置proxy_next_upstream中的状态才可以 生效)、失效节点的触发条件和节点的恢复条件、所有节点失效后nginx会进 行恢复并进行重新监听。 (2)Nginx 负载均衡方式介绍 Nginx的负载均衡方式一共有4种:rr(轮询模式)、ip_hash、fair、url_hash。(3)Ngxin负载均衡和相关反向代理配置内容 Nginx负载均衡和与容错相关的反向代理的配置。 (4)获取后端流程 后端server的自动容错流程图。 (5)测试环境和测试结果 针对几种错误方式进行自动容错测试。 2.结论 (1)nginx 判断节点失效状态 Nginx 默认判断失败节点状态以connect refuse和time out状态为准,不以HTTP错误状态进行判断失败,因为HTTP只要能返回状态说明该节点还可以正常连接,所以nginx判断其还是存活状态;除非添加了proxy_next_upstream指令设置对404、502、503、504、500和time out等错误进行转到备机处理,在next_upstream过程中,会对fails进行累加,如果备用机处理还是错误则直接返回错误信息(但404不进行 记录到错误数,如果不配置错误状态也不对其进行错误状态记录),综述,nginx记录错误数量只记录timeout 、connect refuse、502、500、503、504这6种状态,timeout和connect refuse是永远被记录错误状态,而502、500、503、504只有在配置proxy_next_upstream后nginx才会记录这4种HTTP错误到fails中,当fails大 于等于max_fails时,则该节点失效; (2)nginx 处理节点失效和恢复的触发条件 nginx可以通过设置max_fails(最大尝试失败次数)和fail_timeout(失效时间,在到达最大尝试失败次数后,在fail_timeout的时间范围内节点被置为失效,除非所 有节点都失效,否则该时间内,节点不进行恢复)对节点失败的尝试次数和失效时间 进行设置,当超过最大尝试次数或失效时间未超过配置失效时间,则nginx会对节点 状会置为失效状态,nginx不对该后端进行连接,直到超过失效时间或者所有节点都失效后,该节点重新置为有效,重新探测; (3)所有节点失效后nginx将重新恢复所有节点进行探测 如果探测所有节点均失效,备机也为失效时,那么nginx会对所有节点恢复为有效,重新尝试探测有效节点,如果探测到有效节点则返回正确节点内容,如果还是全 部错误,那么继续探测下去,当没有正确信息时,节点失效时默认返回状态为502,但是下次访问节点时会继续探测正确节点,直到找到正确的为止。

nginx面试题大全及答案

nginx面试题大全及答案 Nginx的并发能力在同类型网页服务器中的表现,相对而言是比较好的,因此受到了很多企业的青睐,我国使用Nginx网站的知名用户包括腾讯、淘宝、百度、京东、新浪、网易等等。Nginx是网页服务器运维人员必备技能之一,下面为大家整理了一些比较常见的Nginx相关面试题,仅供参考: 1、请解释一下什么是Nginx? Nginx是一个web服务器和反向代理服务器,用于HTTP、HTTPS、SMTP、POP3和IMAP协议。 2、请列举Nginx的一些特性。 Nginx服务器的特性包括: 反向代理/L7负载均衡器 嵌入式Perl解释器 动态二进制升级 可用于重新编写URL,具有非常好的PCRE支持 3、请列举Nginx和Apache 之间的不同点

4、请解释Nginx如何处理HTTP请求。 Nginx使用反应器模式。主事件循环等待操作系统发出准备事件的信号,这样数据就可以从套接字读取,在该实例中读取到缓冲区并进行处理。单个线程可以提供数万个并发连接。 5、在Nginx中,如何使用未定义的服务器名称来阻止处理请求? 只需将请求删除的服务器就可以定义为: Server {listen 80;server_name ““ ;return 444;} 这里,服务器名被保留为一个空字符串,它将在没有“主机”头字段的情况下匹配请求,而一个特殊的Nginx的非标准代码444被返回,从而终止连接。 6、使用“反向代理服务器”的优点是什么? 反向代理服务器可以隐藏源服务器的存在和特征。它充当互联网云和web服务器之间的中间层。这对于安全方面来说是很好的,特别是当您使用web托管服务时。 7、请列举Nginx服务器的最佳用途。 Nginx服务器的最佳用法是在网络上部署动态HTTP内容,使用SCGI、WSGI应用程序服务器、用于脚本的FastCGI处理程序。它还可以作为负载均衡器。

nginx错误处理方法

Nginx (“engine x”) 是一个高性能的 HTTP 和反向代理服务器,也是一个IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的站点开发的,它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。Nginx 超越 Apache 的高性能和稳定性。 Nginx+Tomcat是目前主流的Java web架构,很多公司在使用,Nginx+Tomcat通过简单的配置,可以实现高性能的负载均衡,通过本文学习,可以实现Nginx+Tomcat 负载均衡。 工具资源 1、Java运行环境,JDK 2、压缩版下载 3、稳定版下载 本文基于win10进行配置 配置步骤 1、JDK环境配置略 2、Tomcat安装配置 请参考:一台服务器安装运行多个Tomcat及注册服务 本测试安装两个Tomcat,端口分别是8801和8802 安装配置完成后请确保每一个Tomcat可以正常访问 为了区分两个Tomcat,本文将第二个Tomcat的页面名称改为:Apache Tomcat/、Nginx配置 1.解压Nginx到D盘根目录

2. 3.修改Nginx配置 #user nobody; worker_processes 1; #工作进程的个数 #error_log logs/; #error_log logs/ notice; #error_log logs/ info; #pid logs/; events { worker_connections 1024; #单个进程最大连接数 } http { include ; #文件扩展名与文件类型映射表 default_type application/octet-stream; #默认文件类型 #access_log logs/ main;

nginx学习总结

Nginx学习总结 Nginx概述及注意事项 ?nginx是一个高性能的 HTTP 和反向代理服务器,也是一个 IMAP/POP3/SMTP 代理服务 器。 ?目前Nginx使用简单的轮巡(polling)算法来实现负载均衡,所以无法做基本 链接计数的负载均衡。 ?目前官方 Nginx 并不支持 Windows,您只能在包括 Linux、UNIX、BSD 系统下安装和 使用; ?Nginx 本身只是一个 HTTP 和反向代理服务器,它无法像 Apache 一样通过安装各种模 块来支持不同的页面脚本,例如 PHP、CGI 等; ?Nginx 支持简单的负载均衡和容错; ?支持作为基本 HTTP 服务器的功能,例如日志、压缩、Byte ranges、Chunked responses、 SSL、虚拟主机等等,应有尽有。 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不间断运行,即使运行数个月也不需要重新启动。

nginx部署手册

部署手册 1环境介绍 1.1路径规划 程序安装包路径:/home/gzyhpay/setup Nginx部署路径:/home/gzyhpay/nginx Web资源部署路径:/home/gzyhpay/webapp/应用名 Web日志路径:/home/gzyhpay/logs/ 需ip访问的应用的web日志路径:/home/gzyhpay/weblogs/iprequest Jdk路径:/home/gzyhpay/jdk Jboss路径:/home/gzyhpay/jboss/ Jboss系统日志路径:/home/gzyhpay/jboss/standalone/log 应用程序发布路径:/home/gzyhpay/jboss/standalone/deployments 银行认证凭证路径:/home/gzyhpay/work/bankconf 应用日志路径:/home/gzyhpay/work/logs/应用名 应用文件下载缓存路径:/home/gzyhpay/work/download/应用名 应用文件上传缓存路径:/home/gzyhpay/work/upload/应用名 2新建服务器的软件准备 2.1Web服务器软件部署 Web服务器采用nginx中间件。要部署nginx中间件,需先确保web服务器安装了g++或c++编译环境。没有g++或c++的操作系统请找安装盘安装。 2.1.1nginx安装包 /home/gzyhpay/setup/nginx 2.1.2安装 执行setupNGINX.sh脚本直至完成安装。程序安装后,会自动在当前用户目录下建立nginx目录,如home/gzyhpay/nginx。 2.1.3基本配置 fastcgi.conf proxy_conf.conf reload.sh testConfig.sh mime.types 以下以$NGINXHOME代表nginx所在目录,目前路径为:/home/gzyhpay/nginx

Nginx工作原理和优化

目录(?)[-] 1. Nginx的模块与工作原理 2. NginxFastCGI运行原理 1. 什么是FastCGI 2. NginxFastCGI运行原理 3. spawn-fcgi与PHP-FPM 4. NginxPHP-FPM 3. Nginx优化 1. 编译安装过程优化 2. 利用TCMalloc优化Nginx的性能 3. Nginx内核参数优化 4. PHP-FPM的优化 1. Nginx的模块与工作原理 Nginx由内核和模块组成,其中,内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件将客户端请求映射到一个location block(location是Nginx配置中的一个指令,用于URL匹配),而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。 Nginx的模块从结构上分为核心模块、基础模块和第三方模块: 核心模块:HTTP模块、EVENT模块和MAIL模块 基础模块:HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块,第三方模块:HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。 用户根据自己的需要开发的模块都属于第三方模块。正是有了这么多模块的支撑,Nginx 的功能才会如此强大。 Nginx的模块从功能上分为如下三类。 Handlers(处理器模块)。此类模块直接处理请求,并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。 Filters (过滤器模块)。此类模块主要对其他处理器模块输出的内容进行修改操作,最后由Nginx输出。 Proxies (代理类模块)。此类模块是Nginx的HTTP Upstream之类的模块,这些模块主要与后端一些服务比如FastCGI等进行交互,实现服务代理和负载均衡等功能。 图1-1展示了Nginx模块常规的HTTP请求和响应的过程。 图1-1展示了Nginx模块常规的HTTP请求和响应的过程。 Nginx本身做的工作实际很少,当它接到一个HTTP请求时,它仅仅是通过查找配置文件将此次请求映射到一个location block,而此location中所配置的各个指令则会启动不同的模块去完成工作,因此模块可以看做Nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块(当然,多个location可以复用同一个模块)。handler 模块负责处理请求,完成响应内容的生成,而filter模块对响应内容进行处理。 Nginx的模块直接被编译进Nginx,因此属于静态编译方式。启动Nginx后,Nginx的模块被自动加载,不像Apache,首先将模块编译为一个so文件,然后在配置文件中指定是否

Nginx常见错误与解决方法

目的: 在Nginx服务器出现故障时,能快速定位并解决相关错误。 保密: 本文档仅供内部使用,请勿外传 概述: Nginx常见错误与问题之解决方法技术指南。 安装环境: 系统环境:redhat enterprise6.564bit

1、Nginx常见启动错误 有的时候初次安装nginx的时候会报这样的错误 sbin/nginx-c conf/nginx.conf 报错内容:sbin/nginx:error while loading shared libraries:libpcre.so.1: cannot open shared object file:No such file or directory 启动时如果报异常error while loading shared libraries:libpcre.so.1:cannot open shared object file:No such file or directory这说明我们的环境还不是和启动需要 小小的配置一下 解决方法(直接运行): 32位系统[root@sever lib]#ln-s/usr/local/lib/libpcre.so.1/lib 64位系统[root@sever lib]#ln-s/usr/local/lib/libpcre.so.1/lib64 然后执行ps-ef|grep nginx查看nginx进程确认是否真的已经启动了,在进程列表里会有最起码两个,worker(nginx工作进程)和master(nginx主进程) root43491002:24?00:00:00nginx:master process sbin/nginx-c conf/nginx.conf nginx43504349002:24?00:00:00nginx:worker process root435628335002:30pts/100:00:00grep nginx NGINX就OK了 2、400bad request错误的原因和解决办法 配置nginx.conf相关设置如下. client_header_buffer_size16k; large_client_header_buffers464k; 根据具体情况调整,一般适当调整值就可以。 3、Nginx502Bad Gateway错误

如何定时清理Linux系统中的Nginx日志

如何定时清理Linux系统中的Nginx日志 导读:Nginx日志文件如何不定情清理,会变得越来越大,影响Nginx服务器的运行,下面小编就给大家介绍下Linux中清理Nginx日志的方法,一起来了解下吧。 nginx日志文件需要手动分割,创建脚本文件clear_log.sh 文件路径/usr/local/nginx/clear_log.sh vi clear_log.sh。输入如下内容 #!/bin/bash cp /usr/local/nginx/logs/error.log /usr/local/nginx/error-$(date -d “yesterday” +“%Y%m%d”).log #先复制原来的错误日志文件,请根据自己实际的日志路径填写 cat /dev/null 》/usr/local/nginx/logs/error.log #清空错误日志文件 cp/usr/local/nginx/logs/access.log /var/log/nginx/access/access-$(date -d “yesterday” +“%Y%m%d”).log #先复制原来的正常访问日志 cat /dev/null 》/usr/local/nginx/logs/access.log #清空原来的正常访问日志 创建dellog.sh文件,路径/usr/local/nginx vi dellog.sh #!/bin/sh find /usr/nginx/logs/error -mtime +7 -type f -name /*.log | xargs rm -f find /usr/nginx/logs/access -mtime +7 -type f -name /*.log | xargs rm -f #定期删除七天前的日志文件 启动linux下的计划任务,将刚才创建好的两个shell脚本加入此计划 crontab -e,输入如下内容 0 0 * * * /usr/nginx/clear_log.sh #每天0点执行/usr/nginx/clear_log.sh 0 0 * * * /usr/nginx/dellog.sh

Nginx常见错误与解决方法

纽斯达科技Nginx常见错误与解决方法 纽斯达科技 2014-10-25

文档状态 目的: 在Nginx服务器出现故障时,能快速定位并解决相关错误。 : 本文档仅供部使用,请勿外传 概述: Nginx常见错误与问题之解决方法技术指南。 安装环境: 系统环境:redhat enterprise 6.5 64bit

1、Nginx 常见启动错误 有的时候初次安装nginx的时候会报这样的错误 sbin/nginx -c conf/nginx.conf 报错容:sbin/nginx: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory 启动时如果报异常error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory 这说明我们的环境还不是和启动需要 小小的配置一下 解决方法(直接运行): 32位系统 [rootsever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib 64位系统 [rootsever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64 然后执行ps -ef | grep nginx 查看nginx进程确认是否真的已经启动了,在进程列表里会有最起码两个, worker(nginx工作进程)和master(nginx主进程) root 4349 1 0 02:24 ? 00:00:00 nginx: master process sbin/nginx -c conf/nginx.conf nginx 4350 4349 0 02:24 ? 00:00:00 nginx: worker process root 4356 28335 0 02:30 pts/1 00:00:00 grep nginx NGINX 就 OK了 2、400 bad request错误的原因和解决办法 配置nginx.conf相关设置如下. client_header_buffer_size 16k; large_client_header_buffers 4 64k; 根据具体情况调整,一般适当调整值就可以。 3、Nginx 502 Bad Gateway错误 在php.ini和php-fpm.conf中分别有这样两个配置项:max_execution_time和 request_terminate_timeout。

nginx配置文件详解

nginx配置文件详解 user nginx; #运行用户 worker_processes 8; #启动进程,通常设置成和cpu的数量相等 #规则设定 #(1)cpu有多少个核,就有几位数,1代表内核开启,0代表内核关闭 #(2)worker_processes最多开启8个,8个以上性能就不会再提升了,而且稳定性会变的更低,因此8个进程够用了 #8核CPU,开启8个进程。00000001表示开启第一个cpu内核,00000010表示开启第二个cpu内核,依次类推;有多少个核,就有几位数,1表示该内核开启,0表示该内核关闭。 worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; pid /var/run/nginx.pid; #PID文件 error_log /data/logs/nginx/error.log crit; #全局错误日志 worker_rlimit_nofile 655350; #指定进程可以打开的最大描述符:数目。 events { use epoll; #epoll是多路复用IO(I/O Multiplexing)中的一种方式,但是仅用于linux2.6以上内核,可以大大提高nginx的性能 worker_connections 655350; #单个后台worker process进程的最大并发链接数 } http { include mime.types; #设定mime类型,类型由mime.type文件定义 default_type application/octet-stream; #默认文件类型 server_tokens off; #隐藏版本号 charset utf-8; #默认编码 server_names_hash_bucket_size 128; #服务器名字的hash表大小 client_header_buffer_size 32k; #客户端请求头部的缓冲区大小。 large_client_header_buffers 4 32k; #客户端请求头缓冲大小。 client_max_body_size 200m; #设定通过nginx上传文件的大小 sendfile on; #用于开启高效文件传输模式。将tcp_nopush和tcp_nodelay两个指令设置为on用于防止网络阻塞; tcp_nopush on; #告诉nginx在一个数据包里发送所有头文件,而不一个接一个的发送。 keepalive_timeout 60; #keepalive超时时间。 tcp_nodelay on; #告诉nginx不要缓存数据,而是一段一段的发送--当需要及时发送数据时,就应该给应用设置这个属性。 #FastCGI相关参数是为了改善网站的性能:减少资源占用,提高访问速度。 fastcgi_connect_timeout 300; #连接到后端fastcgi超时时间 fastcgi_send_timeout 300; #向fastcgi请求超时时间(这个指定值已经完成两次握手后向fastcgi传送请求的超时时间) fastcgi_read_timeout 300; #接收fastcgi应答超时时间,同理也是2次握手后 fastcgi_buffer_size 64k; #读取fastcgi应答第一部分需要多大缓冲区,该值表示使用1个64kb的缓冲区读取应答第一部分(应答头) fastcgi_buffers 4 64k; #指定本地需要多少和多大的缓冲区来缓冲fastcgi应答请求 fastcgi_busy_buffers_size 128k; #默认值是fastcgi_buffer的2倍 fastcgi_temp_file_write_size 128k; #写入缓存文件使用多大的数据块,默认值是fastcgi_buffer的2倍 fastcgi_intercept_errors on; #对错误页面重定向,结合error_page使用

Nginx+PHP-FPM优化技巧总结

Nginx+PHP-FPM优化技巧总结 1.Unix域Socket通信 之前简单介绍过Unix Domain Socket这种通信方式,参见:Nginx+PHP-FPM的域Socket配置方法 Unix域Socket因为不走网络,的确可以提高Nginx和php-fpm通信的性能,但在高并发时会不稳定。 Nginx会频繁报错: connect() to unix:/dev/shm/php-fcgi.sock failed (11: Resource temporarily unavailable) while connecting to upstream 可以通过下面两种方式提高稳定性: 1)调高nginx和php-fpm中的backlog 配置方法为:在nginx配置文件中这个域名的server下,在listen 80后面添加default backlog=1024。 同时配置php-fpm.conf中的listen.backlog为1024,默认为128。 2)增加sock文件和php-fpm实例数 再新建一个sock文件,在Nginx中通过upstream模块将请求负载均衡到两个sock文件背后的两套php-fpm实例上。 2.php-fpm参数调优 2.1进程数

php-fpm初始/空闲/最大worker进程数 pm.max_children = 300 pm.start_servers = 20 pm.min_spare_servers = 5 pm.max_spare_servers = 35 2.2最大处理请求数 最大处理请求数是指一个php-fpm的worker进程在处理多少个请求后就终止掉,master进程会重新respawn一个新的。这个配置的主要目的是避免php解释器或程序引用的第三方库造成的内存泄露。 pm.max_requests = 10240 2.3最长执行时间 最大执行时间在php.ini和php-fpm.conf里都可以配置,配置项分别为max_execution_time和 request_terminate_timeout。 其作用及其影响参见:Nginx中502和504错误详解 3.php-fpm的高CPU使用率排查方法 3.1CPU使用率监控方法 1)top命令 直接执行top命令后,输入1就可以看到各个核心的CPU使用率。而且通过top -d 0.1可以缩短采样时间。

nginx文件类型 错误解析漏洞

漏洞介绍:nginx是一款高性能的web服务器,使用非常广泛,其不仅经常被用作反向代理,也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题,默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析,这将导致严重的安全问题,使得恶意的攻击者可能攻陷支持php的nginx服务器。 漏洞分析:nginx默认以cgi的方式支持php的运行,譬如在配置文件当中可以用这样: location ~ \.php$ { root html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; include fastcgi_params; } 的方式支持对php的解析,location对请求进行选择的时候会使用URI环境变量进行选择,其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name 决定,而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的,这里就是产生问题的点。而为了较好的支持PATH_INFO的提取,在PHP的配置选项里存在cgi.fix_pathinfo选项,其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。 那么假设存在一个https://www.360docs.net/doc/fd7716854.html,/80sec.jpg,我们以如下的方式去访问https://www.360docs.net/doc/fd7716854.html,/80sec.jpg/80sec.php POC:访问一个nginx来支持php的站点,在一个任何资源的文件如robots.txt后面加上/80sec.php,这个时候你可以看到如下的区别: 访问https://www.360docs.net/doc/fd7716854.html,/robots.txt HTTP/1.1 200 OK Server: nginx/0.6.32 Date: Thu, 20 May 2010 10:05:30 GMT Content-Type: text/plain Content-Length: 18 Last-Modified: Thu, 20 May 2010 06:26:34 GMT Connection: keep-alive Keep-Alive: timeout=20 Accept-Ranges: bytes 访问https://www.360docs.net/doc/fd7716854.html,/robots.txt/80sec.php HTTP/1.1 200 OK Server: nginx/0.6.32 Date: Thu, 20 May 2010 10:05:30 GMT Content-Type: text/plain

相关文档
最新文档