nginx提示：500内部服务器错误解决办法

现在越来越多的网站开始使用 Nginx（“Engine x”）。 Nginx（“Engine x”）是一个高性能的 HTTP 和反向代理服务器以及 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二大的网站 Rambler.ru 开发的，并且已经运行了两年半多了。 Igor 在类似 BSD 的许可证下发布源代码。 如果您有很多并发连接，Nginx 是 Apache 服务器的一个很好的替代方案。 Nginx 还可以用作第 7 层负载均衡服务器。 测试结果显示，Nginx 0.6.31 + PHP 5.2.6（FastCGI）可以支撑超过3万个并发连接，在相同环境下是Apache的10倍。 然而，很多人在使用 Nginx 时会收到 500 错误。 根据我的使用情况，大部分原因是打开文件的句柄太小。 在 Linux 上，使用此命令可以增加进程打开的文件句柄数。 ulimit -SHn 51200 默认情况下仅使用 1000。 如果链接太少你就看不到它。 这种处理方法有效防止了500错误的发生。 今天访问网站时，偶尔会看到 500 Internal Server Error 错误页面。 经过检查相关信息，发现该问题是由于系统内核进程访问过多而受到限制造成的。 答案是： $ ulimit -n 11095 程序限制 只能打开 11095 个文件。 ulimit 命令设置当前用户进程可以拥有的文件描述符的数量。 看起来模拟并发数太高了。 您需要调整nginx.conf中的并发数设置。 （我的配置主机内存2G，CPU 2.8G）复制代码如下： vi /etc/nginx/nginx.conf conf event {worker connection 1024; 调整您复制的代码如下：仍然出现上述问题。 [root@qimutian nginx]# cat /proc/sys/fs/file-max 8192 文件系统最大打开文件数 [root@qimutian nginx]# 使用ulimit -。 ]n 1024 个程序只能打开 1024 个文件。 使用 [root@qimutian nginx]# ulimit -n 8192 进行调整。 或者，通过将 /etc/rc.d/rc.local 添加到启动文件末尾（/etc/sysctl.conf 末尾的 fs.file- max=8192）来永久调整打开文件的数量。 ulimit -n 8192 CentOS5 调整 如果您使用 ulimit -a 检查打开文件的数量，您将看到默认情况下 OPEN FILES 不能超过 1024。 我昨天在压力测试中得到了 500 错误。 检查 nginx 错误以获取更多信息。 500 内部服务器错误。 早上醒来一看，方法1已经调整（永久调整）如下。 vi /etc/security/limits.conf。 将 *soft nofile 8192 *hard nofile 20480 添加到文件末尾。 同时在vi /etc/sysctl.conf末尾添加fs.file-max=8192。 重新启动。 ulimit -n 显示的数字已经是 8192。 方法2（临时使用）直接在终端中输入ulimit -n 8192，然后按Enter键。 500 内部服务器错误。 错误提示： 1. 硬盘可用空间已满。 使用 df -k 检查您的硬盘是否已满。 释放硬盘空间可能有助于解决 500 错误。 如果nginx启用了访问日志，我们建议您在不需要时关闭访问日志。 访问日志会占用大量硬盘空间。 2.nginx配置文件错误。 这没有道理语法错误。 如果你的nginx配置文件有语法错误，启动时会提示。 配置重写时，如果某些规则处理不当，可能会出现 500 错误。 请仔细检查重写规则。 如果配置文件中的某些变量设置不正确，例如引用没有值的变量，也可能会出现 500 错误。 3. 如果不存在以上问题，则可能是模拟并发量过高。 您需要调整nginx.conf中的并发数设置。 解决办法是： 1. 打开 /etc/security/limits.conf 文件并添加要复制的两条语句。 这是代码： * Soft nofile 65535 * Hard nofile 65535 2 打开/etc/nginx/nginx.conf，将worker_processes下复制的那行代码代码为： 3 重新启动nginx，重新加载配置，然后复制代码。 这是代码： 杀死 -9 `ps -ef | grep -v grep | /usr/bin/spawn-fcgi -a 127.0.0.1 - ]p 9000 -C 100 -u www-数据 -f /usr /bin/php-cgi Killall -HUP nginx 重启nginx后，我检查了nginx。 我查看了错误日志，没有发现任何 500 错误。 情况。 4.可能是数据库问题。 在 nginx 或 php 日志中未发现任何问题。 最后发现无法访问数据库。 修复后，问题得到解决。