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

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.

可能是这样

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地址。

连接已超时

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

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

404找不到

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应用程序可能会显示不同的错误消息。它可能会告诉您“安全连接失败”，而原因是相同的。

500内部服务器错误

这意味着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显示默认页面

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

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

页面没有正确重定向

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

这意味着您配置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状态页面示例。

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

如果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选项。

收尾

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