如何修复常见的Nginx Web服务器错误

  • 技术文档
  • 2022.03.24
  • 浏览:5440

Nginx是当今非常流行的web服务器。本文将向您展示运行Nginx web服务器时的一些常见错误以及可能的解决方案。这不是一个完整的列表。如果在尝试建议的解决方案后仍然无法修复错误,请检查/var/log/Nginx/目录下的Nginx服务器日志,并在谷歌上搜索以调试问题。

无法连接/拒绝连接

如果在尝试访问网站时看到以下错误:

Firefox can’t establish a connection to the server at www.example.com

www.example.com refused to connect

The site can't be reached, www.example.com unexpectedly closed the connection.

Firefox Unable to connect

可能是这样

  1. Nginx没有运行。您可以使用sudo systemctl status Nginx检查Nginx状态。使用sudo systemctl Start Nginx启动Nginx。如果Nginx无法启动,请运行sudo Nginx-t以查看配置文件是否有任何问题。并查看日志(sudo journalctl-eu nginx),找出它无法启动的原因。
  2. 防火墙阻止端口80和443。如果在Debian/Ubuntu上使用UFW防火墙,请运行sudo UFW allow 80443/tcp以打开tcp端口80和443。如果在RHEL/CentOS/Rocky Linux/AlmaLinux上使用Firewalld,请运行sudo firewall cmd--permanent--add service={http,https},然后sudo systemctl重新加载Firewalld以打开TCP端口80和443。
  3. 失败2本。如果您的服务器使用fail2ban阻止恶意请求,则可能是fail2ban禁止了您的IP地址。运行sudo journalctl-eu fail2ban检查您的IP地址是否被禁止。您可以将您的IP地址添加到fail2ban ignoreip列表中,这样就不会再次被禁止。
  4. Nginx没有在正确的网络接口上监听。例如,Nginx没有监听服务器的公共IP地址。

连接已超时

the connection has timed out

这可能意味着您的服务器处于脱机状态,或者Nginx无法正常工作。我曾经有过一个内存不足的问题,这导致Nginx无法生成工作进程。如果您可以在/var/log/nginx/error中看到以下错误消息。日志文件,服务器内存不足。

fork() failed while spawning "worker process" (12: Cannot allocate memory)

404找不到

nginx 404 not found

404找不到意味着Nginx找不到您的web浏览器要求的资源。原因可能是:

  1. 服务器上不存在web根目录。在Nginx中,web roor目录是使用root指令配置的,如下所示:root/usr/share/Nginx/linuxbabe。com/;。确保您的网站文件(HTML、CSS、JavaScript、PHP)存储在正确的目录中。
  2. PHP-FPM没有运行。您可以使用sudo systemctl status php7检查PHP-FPM状态。4-fpm(Debian/Ubuntu)或sudo systemctl status php fpm
  3. 您忘记包含try_文件$uri/索引。php$is_args$args;Nginx服务器配置文件中的指令。处理PHP代码需要此指令。
  4. 您的服务器没有可用磁盘空间。试着释放一些磁盘空间。您可以使用ncdu实用程序(sudo-apt-install-ncdu或sudo-dnf-install-ncdu)找出哪些目录占用了大量磁盘空间。

403禁止

此错误意味着不允许您访问请求资源。可能的情况包括:

  • 网站管理员通过IP白名单或其他方法阻止公众访问请求的资源。
  • 该网站可能使用ModSecurity等web应用程序防火墙,该防火墙检测到入侵攻击,因此阻止了请求。

发生403时,某些web应用程序可能会显示不同的错误消息。它可能会告诉您“安全连接失败”,而原因是相同的。

secure connection failed nginx

500内部服务器错误

Nginx 500 internal server error

这意味着web应用程序中存在一些错误。可能是这样

  1. 数据库服务器已关闭。使用sudo systemctl status MySQL检查MySQL/MariaDB状态。用sudo systemctl Start mysql启动它。运行sudo journalctl-eu mysql,找出它无法启动的原因。MySQL/MariaDB进程可能因内存不足而被终止。
  2. 您没有将Nginx配置为使用PHP-FPM,因此Nginx不知道如何执行PHP代码。
  3. 如果web应用程序具有内置缓存,则可以尝试刷新应用缓存以修复此错误。
  4. 您的web应用程序可能会生成自己的错误日志。检查此日志文件以调试此错误。
  5. 您的web应用程序可能具有调试模式。打开它,您将在网页上看到更详细的错误消息。例如,通过在/srv/Modoboa/instance/instance/settings中设置DEBUG=True,可以在Modoboa邮件服务器托管平台中打开调试模式。py文件。
  6. PHP-FPM可能会过载。检查PHP-FPM日志(例如/var/log/php7.4-FPM.log)。如果您发现[pool www]似乎很忙(您可能需要增加pm.start_服务器或pm.min/max_spare_服务器)警告消息,则需要为PHP-FPM分配更多资源。
  7. 有时重新加载PHP-FPM(sudo systemctl reload php7.4-FPM)可以修复错误。

Nginx显示默认页面

welcome to Nginx

如果您试图设置Nginx虚拟主机,并且在web浏览器中键入域名时,会显示默认的Nginx页面,它可能是

  • 您在Nginx虚拟主机中的server_name指令没有使用真实的域名。
  • 你忘了重新加载Nginx。

页面没有正确重定向

Firefox显示此错误,因为页面没有正确重定向。Google Chrome将此错误显示为www.example。com重定向了你太多次。

Firefox The page isn’t redirecting properly

这意味着您配置Nginx重定向的次数过多。例如,您可能在https服务器块中添加了一个不必要的return 301指令,以将HTTP重定向到https连接。

如果已经设置了页面缓存,比如Nginx FastCGI缓存,则需要清除服务器页面缓存。

504网关超时

这意味着像PHP-FPM/MySQL/MariaDB这样的上游服务器无法足够快地处理请求。您可以尝试重新启动PHP-FPM以暂时修复错误,但最好开始调优PHP-FPM/MySQL/MariaDB以获得更快的性能。

以下是my/etc/mysql/mariadb中的InnoDB配置。conf.d/50-server。cnf文件。这是一个非常简单的性能调整。

innodb_buffer_pool_size = 1024M innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_load_at_startup  = ON innodb_log_file_size = 512M innodb_log_buffer_size = 8M  #Improving disk I/O performance innodb_file_per_table = 1 innodb_open_files = 400 innodb_io_capacity = 400 innodb_flush_method = O_DIRECT innodb_read_io_threads = 64 innodb_write_io_threads = 64 innodb_buffer_pool_instances = 3

哪里:

  • InnoDB缓冲池大小至少需要为RAM的一半。(对于具有少量RAM的VP,我建议将缓冲池大小设置为较小的值,如400M,否则VP将耗尽RAM。)
  • InnoDB日志文件大小需要为缓冲池大小的25%。
  • 将读IO线程和写IO线程设置为最大值(64),然后
  • 让MariaDB使用3个InnoDB缓冲池实例。实例数必须与系统上的CPU核数相同。

保存更改后,重新启动MariaDB。

sudo systemctl restart mariadb

您还可以在Nginx中设置更长的超时值,以减少网关超时的机会。编辑Nginx虚拟主机文件,并在服务器{…}中添加以下行块

  proxy_connect_timeout       600;   proxy_send_timeout          600;   proxy_read_timeout          600;   send_timeout                600;

如果将Nginx与PHP-FPM结合使用,那么将fastcgi_read_timeout设置为更大的值,比如300秒。默认值为60秒。

 location ~ /.php$ {      try_files $uri /index.php$is_args$args;      include snippets/fastcgi-php.conf;      fastcgi_split_path_info ^(.+/.php)(/.+)$;       fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;      include fastcgi_params;      fastcgi_read_timeout 300;  }

然后重新加载Nginx。

sudo systemctl reload nginx

PHP-FPM也有每个脚本的最大执行时间。编辑php。ini文件。

sudo nano /etc/php/7.4/fpm/php.ini

可以将该值增加到300秒。

max_execution_time = 300

然后重启PHP-FPM

sudo systemctl restart php7.4-fpm

内存耗尽

如果您在Nginx错误日志中看到以下行,则表示PHP达到了128MB内存限制。

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 57134520 bytes)

你可以编辑php。ini文件(/etc/php/7.4/fpm/php.ini),并增加php内存限制。

memory_limit = 512M

然后重启PHP7。4-FPM。

sudo systemctl restart php7.4-fpm

如果错误仍然存在,那么很可能是web应用程序中的坏PHP代码消耗了大量RAM。

PR_END_文件错误

  1. 您已将Nginx配置为将HTTP请求重定向到HTTPS,但Nginx中没有服务HTTPS请求的服务器块。
  2. 也许Nginx没有运行?
  3. 有时,主Nginx二进制文件正在运行,但辅助进程可能会由于各种原因而失败并退出。检查要调试的Nginx错误日志(/var/log/Nginx/error.log)。

PHP-FPM上游超时

有些人可以在Nginx错误日志文件(在/var/log/Nginx/下)中找到以下错误。

[error] 7553#7553: *2234677 upstream timed out (110: Connection timed out) while reading response header from upstream

可能的解决方案:

  1. 重新启动PHP-FPM。
  2. 升级内存。

资源暂时不可用

有些人可以在Nginx错误日志文件(在/var/log/Nginx/下)中找到以下错误。

connect() to unix:/run/php/php7.4-fpm.sock failed (11: Resource temporarily unavailable)

这通常意味着你的网站有很多访问者,PHP-FPM无法处理大量的请求。您可以调整PHP-FPM子进程的数量,以便它可以处理更多请求。

编辑PHP-FPM www.conf文件。(文件路径因Linux发行版而异。)

sudo /etc/php/7.4/fpm/pool.d/www.conf

默认的子进程配置如下所示:

pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3

上述配置意味着

  • PHP-FPM动态创建子进程。没有固定数量的子进程。
  • 它最多创建5个子进程。
  • PHP-FPM启动时启动2个子进程。
  • 至少有一个空闲进程。
  • 最多有3个空闲进程。

默认设置基于没有太多资源的服务器,比如只有1GB RAM的服务器。如果你有一个高流量的网站,你可能想增加子进程的数量,这样它就可以满足更多的请求。

pm = dynamic pm.max_children = 20 pm.start_servers = 8 pm.min_spare_servers = 4 pm.max_spare_servers = 12

确保有足够的RAM来运行更多的子进程。保存并关闭文件。然后重启PHP-FPM。(您可能需要更改版本号。)

sudo systemctl restart php7.4-fpm

要监视PHP-FPM的运行状况,可以启用状态页面。在PHP-FPM www.conf文件中找到以下行。请注意:

;pm.status_path = /status

删除分号以启用PHP-FPM状态页。然后重启PHP-FPM。

sudo systemctl restart php7.4-fpm

然后编辑Nginx虚拟主机文件。添加以下行。allow和deny指令用于限制访问。只有白名单上的IP地址才能访问状态页面。

location ~ ^/(status|ping)$ {         allow 127.0.0.1;         allow your_other_IP_Address;         deny all;          fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;         fastcgi_index index.php;         include fastcgi_params;         #fastcgi_pass 127.0.0.1:9000;         fastcgi_pass   unix:/run/php/php7.4-fpm.sock; }

保存并关闭文件。然后测试Nginx配置。

sudo nginx -t

如果测试成功,请重新加载Nginx以使更改生效。

sudo systemctl reload nginx

PHP-FPM状态页面示例。

Nginx PHP-FPM status page

PHP-FPM www.conf文件很好地解释了每个参数的含义。

PHP-FPM status page slow requests

如果PHP-FPM非常忙,无法立即为请求提供服务,它将对该请求进行排队。默认情况下,最多可以有511个未决请求,由侦听器决定。backlog参数。

listen.backlog = 511

如果您在PHP-FPM状态页面上看到以下值,则表示从未有请求放入队列,即您的PHP-FPM可以快速处理请求。

listen queue:         0 max listen queue:     0

如果队列中有511个挂起的请求,这意味着您的PHP-FPM非常繁忙,因此您应该增加子进程的数量。

您可能还需要更改Linux内核网络。果心somaxconn设置,它定义了Linux上套接字文件(如PHP-FPM Unix套接字文件)允许的最大连接数。默认情况下,其值在内核5.4之前为128,从内核5.4开始为4096。

[email protected]:~$ sysctl net.core.somaxconn net.core.somaxconn = 128

如果你经营一个高流量的网站,你可以使用一个大的价值。编辑/etc/sysctl。conf文件。

sudo nano /etc/sysctl.cnf

添加以下两行。

net.core.somaxconn = 20000 net.core.netdev_max_backlog = 65535

保存并关闭文件。然后应用设置。

sudo sysctl -p

注意:如果您的服务器有足够的RAM,您可以为PHP-FPM分配固定数量的子进程,如下所示。根据我的经验,这修复了Joomla+Virtuemart网站的500个内部错误。

pm = static pm.max_children = 50

同一网站的两个虚拟主机文件

如果运行sudo nginx-t并看到以下警告。

nginx: [warn] conflicting server name "example.com" on [::]:443, ignored nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored

这意味着有两个虚拟主机文件包含相同的服务器名称配置。不要为一个网站创建两个虚拟主机文件。

对等端重置PHP-FPM连接

Nginx错误日志文件显示以下消息。

recv() failed (104: Connection reset by peer) while reading response header from upstream

这可能是由于重新启动PHP-FPM造成的。如果您自己手动重新启动,则可以忽略此错误。

Nginx插座泄漏

如果在/var/log/nginx/error中发现以下错误消息。日志文件,您的Nginx存在套接字泄漏问题。

2021/09/28 13:27:41 [alert] 321#321: *120606 open socket #16 left in connection 163 2021/09/28 13:27:41 [alert] 321#321: *120629 open socket #34 left in connection 188 2021/09/28 13:27:41 [alert] 321#321: *120622 open socket #9 left in connection 213 2021/09/28 13:27:41 [alert] 321#321: *120628 open socket #25 left in connection 217 2021/09/28 13:27:41 [alert] 321#321: *120605 open socket #15 left in connection 244 2021/09/28 13:27:41 [alert] 321#321: *120614 open socket #41 left in connection 245 2021/09/28 13:27:41 [alert] 321#321: *120631 open socket #24 left in connection 255 2021/09/28 13:27:41 [alert] 321#321: *120616 open socket #23 left in connection 258 2021/09/28 13:27:41 [alert] 321#321: *120615 open socket #42 left in connection 269 2021/09/28 13:27:41 [alert] 321#321: aborting

你可以重启操作系统来解决这个问题。如果不起作用,您需要编译一个调试版本的Nginx,它会在日志中显示调试信息。

Cloudflare错误

如果您的网站运行在Cloudflare CDN(内容交付网络)之后,以下是一些常见错误和解决方案。

521网络服务器关闭

  • Nginx没有运行。
  • 您没有在防火墙中打开TCP端口80和443。
  • 您更改了服务器IP地址,但忘记在Cloudflare中更新DNS记录。

页面没有正确重定向

如果您在SSL/TLS应用程序上的SSL设置设置为“灵活”,但您的源服务器配置为将HTTP请求重定向到HTTPS,则您的Nginx服务器会以加密连接将响应发送回Cloudflare。由于Cloudflare需要HTTP流量,因此它会不断重新发送相同的请求,从而导致重定向循环。在这种情况下,您需要在Cloudflare设置中使用完整(严格)SSL/TLS选项。

Cloudflare SSL TLS full strict

收尾

我希望本文能帮助您修复常见的Nginx web服务器错误。和往常一样,如果你觉得这篇文章很有用,那么订阅我们的免费时事通讯以获得更多提示和窍门?