首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

Nginx服务器常见错误和解决办法

Nginx服务器错误一般有以下8个原因,每一种原因下方,分别给出了解决的方法,如下: 1、请求的header过大。nginx默认的header长度上限是4k,如果超过了这个值,nginx会直接返回400错误。 解决方法:配置nginx.conf相关设置。可以通过以下2个参数来调整header上限:client_header_buffer_size 16k;large_client_header_buffers 4 16k。 2、上传文件过程中出现错误。这时浏览器显示“413 Request Entity Too Large”。这是因为没有设置client_max_body_size,这个参数默认只是1M,也就是说发布的文章内容大小不能超过1M。 解决方法:增加如下两行到nginx.conf的http{}段, 增大nginx上传文件大小限制:设置允许发布内容为8M:client_max_body_size 8M;client_body_buffer_size 128k。 另外如果运行的是php,那么还要检查php.ini,这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,这样就不会因为提交数据大小不一致出现的错误:post_max_size = 8M;upload_max_filesize = 6M。 修改完配置后,别忘记重新加载。 3、客户端在为等到服务器相应返回前就关闭了客户端描述符。一般出现在客户端设置超时后,服务器主动关闭。 解决方法:根据实际Nginx后端服务器的处理时间修改客户端超时时间。 4、脚本错误(php语法错误、lua语法错误)。 解决方法:查看nginx_err_log php_err_log。 5、访问量过大,系统资源限制,不能打开过多文件。 磁盘空间不足。(access log开启可能导致磁盘满溢,服务器主动关闭)。 解决方法:修改/etc/sysctl.conf文件,并使用下面的命令确认: #sysctl -p。要使 limits.conf 文件配置生效,必须要确保 pam_limits.so 文件被加入到启动文件中。 6、后端服务无法处理,业务中断。 解决方法:从后端日志获取错误原因,解决后端服务器问题。 7、后端服务器在超时时间内,未响应Nginx代理请求。 解决方法:根据后端服务器实际处理情况,调正后端请求超时时间。 8、网站页面缓存过大。 解决方法:配置nginx.conf相关设置:fastcgi_buffers 8 128k;send_timeout 60。

01

Linux磁盘满问题分析

线上一台Linux服务器最近经常磁盘根分区满告警, 但不是普通的日志文件或数据文件过多过大,现象如下: 1)执行“df -h”查看各分区空间的使用情况 [root@XEN64 /]# df -h Filesystem      Size  Used Avail Use% Mounted on /dev/sda1       9.8G  8.7G  535M  95% / devtmpfs        7.7G     0  7.7G   0% /dev tmpfs           7.7G     0  7.7G   0% /dev/shm tmpfs           7.7G  666M  7.1G   9% /run tmpfs           7.7G     0  7.7G   0% /sys/fs/cgroup /dev/sda3        20G  3.3G   16G  18% /usr/local 可以看到根分区使用率超过了预警值, 进入根目录,查看根目录下各子目录的大小: [root@XEN64 /]# du -sm * 0       bin 180     boot 0       dev 24      etc 3       home 0       lib 0       lib64 1       lost+found 1       media 1       mnt 32      opt du: cannot access 'proc/17842/task/17842/fd/4': No such file or directory du: cannot access 'proc/17842/task/17842/fdinfo/4': No such file or directory du: cannot access 'proc/17842/fd/4': No such file or directory du: cannot access 'proc/17842/fdinfo/4': No such file or directory 0       proc 2       root 666     run 0       sbin 1       srv 0       sys 96      tmp 5856    usr 221     var 进一步检查/usr目录: [root@XEN64 /usr]# du -sm * 358     1.2-compat 164     bin 1       etc 1       games 33      include 912     lib 432     lib64 101     libexec 3269    local 1       man 46      sbin 547     share 1       src 0       tmp 对比du和df的结果,可以发现两者的已使用大小不一致, du命令得到的已用大小远小于df命令已用大小,初步猜测存已被删除文件仍然有进程在写它,导致du命令发现不了。 如果允许,最简单的处理方式是重启机器,不然用下列命令找出被删除的,但仍然可能有进程在写它的文件: pids=`ps aux|awk '{print $2}'`;for pid in $pids; do lsof -p $pid|grep del; done 见到庐山真面目: [root@XEN64 /proc]# pids=`ps aux|awk '{print $2}'`;for pid in $pids; do lsof -p $pid|grep del; done stati 28885 root    1w      REG        8,1 5969132048     409096 /tmp/process_monitor-root.log (deleted) stati 28885 root    2w      REG        8,1 5969132048     409096 /tmp/process_monitor-root.log (deleted) stati 28885 root    3u      REG        8,4   20480039   35651587 /data/consumer/log/consumer.log.5 (deleted) consumer 29756 root    1w   REG        8,1 5969132048     409

03

在CentOS上配置基于主机的入侵检测系统(IDS)  

AIDE (“高级入侵检测环境”的简称)是一个开源的基于主机的入侵检测系统。AIDE通过检查大量文件属性的不一致性来检查系统二进制文件和基本配置文件的完整性,这些文件属性包括权限、文件类型、索引节点、链接数、链接名、用户、组、文件大小、块计数、修改时间、添加时间、创建时间、acl、SELinux安全上下文、xattrs,以及md5/sha校验值在内的各种特征。 AIDE通过扫描一台(未被篡改)的Linux服务器的文件系统来构建文件属性数据库,以后将服务器文件属性与数据库中的进行校对,然后在服务器运行时对被修改的索引了的文件发出警告。出于这个原因,AIDE必须在系统更新后或其配置文件进行合法修改后重新对受保护的文件做索引。 对于某些客户,他们可能会根据他们的安全策略在他们的服务器上强制安装某种入侵检测系统。但是,不管客户是否要求,系统管理员都应该部署一个入侵检测系统,这通常是一个很好的做法。 在 CentOS或RHEL 上安装AIDE AIDE的初始安装(同时是首次运行)最好是在系统刚安装完后,并且没有任何服务暴露在互联网甚至局域网时。在这个早期阶段,我们可以将来自外部的一切闯入和破坏风险降到最低限度。事实上,这也是确保系统在AIDE构建其初始数据库时保持干净的唯一途径。(LCTT 译注:当然,如果你的安装源本身就存在安全隐患,则无法建立可信的数据记录) 出于上面的原因,在安装完系统后,我们可以执行下面的命令安装AIDE: # yum install aide 我们需要将我们的机器从网络断开,并实施下面所述的一些基本配置任务。 配置AIDE 默认配置文件是/etc/aide.conf,该文件介绍了几个示例保护规则(如FIPSR,NORMAL,DIR,DATAONLY),各个规则后面跟着一个等号以及要检查的文件属性列表,或者某些预定义的规则(由+分隔)。你也可以使用此种格式自定义规则。

04
领券