Linux下Nginx不能启动的解决方法 (linux 下nginx无法启动不了)

Nginx是一个高性能的HTTP和反向代理服务器，适合高并发访问的Web应用服务器。在使用Linux系统的时候，Nginx是一个非常常见的Web服务器，但有时会出现Nginx不能启动的情况，这是因为Nginx的配置或操作系统环境等问题引起的。我们可以通过以下方法解决这些问题。

我们提供的服务有：成都网站建设、做网站、微信公众号开发、网站优化、网站认证、耿马ssl等。为上千余家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的耿马网站制作公司

1.检查错误日志

当Nginx不能启动时，首先需要检查错误日志，日志文件通常位于 /var/log/nginx/error.log，打开日志文件，查找错误消息。常见的错误消息包括读取配置文件错误、端口冲突等。根据日志文件的错误消息，我们可以准确快速地找到问题所在。

2.检查端口是否被占用

如果Nginx无法启动，可能是由于端口被占用。可以使用netstat命令查看当前正在监听的端口和对应的进程。例如，要检查TCP端口80是否被占用，可以使用以下命令：

“`

netstat -ntlp | grep :80

“`

如果端口80被占用，则会显示正在使用该端口的进程的详细信息。需要杀掉占用端口80的进程，以便Nginx能够正常启动。

3.检查配置文件

如果Nginx不能启动，可能是由于配置文件存在语法错误或配置错误。一般情况下，Nginx配置文件位于/etc/nginx/nginx.conf。使用以下命令检查Nginx配置文件的语法是否正确：

“`

nginx -t -c /etc/nginx/nginx.conf

“`

如果配置文件存在语法错误，则会提示错误消息。首先修复配置文件中的语法错误，然后再次检查。

4.检查文件和文件夹权限

在Linux系统中，文件和文件夹的权限对Nginx的启动和运行非常重要。如果Nginx无法启动，请检查Nginx和其包含文件和文件夹的权限。使用以下命令检查文件和文件夹的权限：

“`

ls -l /path/to/nginx/files

“`

如果文件和文件夹没有正确的权限，则会提示错误消息。为了修复权限问题，可以使用以下命令：

“`

sudo chown -R username:group /path/to/nginx/files

sudo chmod -R 755 /path/to/nginx/files

“`

其中，username指的是你的用户名，group指的是你的用户组。

5.查看启动日志

在Nginx启动时，有时会发生一些错误，但错误消息没有显示在错误日志文件中。这时，我们可以查找启动日志以找到问题所在。启动日志通常位于 /var/log/nginx/access.log。使用以下命令查看启动日志：

“`

tl -f /var/log/nginx/access.log

“`

如果没有找到错误日志，但启动日志中包含错误消息，则可以根据消息修复问题。

6.重装或升级Nginx

如果Nginx无法启动，我们可以尝试重新安装或升级Nginx。使用以下命令升级Nginx：

“`

sudo apt-get update

sudo apt-get upgrade nginx

“`

如果升级后Nginx仍然无法启动，则可以尝试删除Nginx并执行重新安装。

在使用Linux系统中，Nginx是非常常见的Web服务器，但有时可能会出现Nginx无法启动的情况。这时，我们需要通过检查错误日志、端口是否被占用、配置文件、文件和文件夹权限、启动日志以及重新安装或升级Nginx等方式来解决问题。通过这些方法，可以解决大多数Nginx无法启动的问题，让我们的Web应用程序更加稳定和可靠。

相关问题拓展阅读：

• 真心求助.nginx错误
• Linux系统问题NGINX？
• nginx做流媒体，安装没问题，启动成功，但是无法访问到页面！

真心求助.nginx错误

Nginx服务器错误一般有以下几点原因：

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。

目的：

在Nginx服务器出现故障时，能快速定位并解决相关错误。

保密：

本文档仅供内部使用，请勿外传

概述：

Nginx常见错误与问题之解决方法技术指南。

安装环境：

系统环境：redhat enterprise 6.5 64bit

1、Nginx 常见启动错误

有的时候初次安装nginx的时候会报这样的错误

in/nginx -c conf/nginx.conf

报错内容：in/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位系统 # ln -s /usr/local/lib/libpcre.so.1 /lib

64位系统 # ln -s /usr/local/lib/libpcre.so.1 /lib64

然后执行ps -ef | grep nginx 查看nginx进程确认是否真的已经启动了，在进程列表里会

有最起码两个， worker(nginx工作进程)和master（nginx主进程）

root:24 ? 00:00:00 nginx: master process in/nginx -c

conf/nginx.conf

nginx2:24 ? 00:00:00 nginx: worker process

root02: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。

这两项都是用来配置一个PHP脚本的更大执行时间的。当超过这个时间时，PHP-FPM不只会终止脚本的执行，罩友

还会终止执行脚本的Worker进程。所以Nginx会发现与自己通信的连接断掉了，就会返回给客户端502错误。

以PHP-FPM的request_terminate_timeout=30秒时为例，报502 Bad Gateway错误的具体信息如下：

1）Nginx错误访问日志：

/物饥槐09/19 01:09:00 27600#0: *78887 recv() failed (104: Connection reset by peer) while reading response header from upstream,

client: 192.168.1.101, server: test.com, request: “POST /index.php HTTP/1.1″, upstream: ”

host: “test.com”, referrer: “

“

2）PHP-FPM报错日志：

WARNING: childexited on signal 15 (SIGTERM) after 21008.seconds from start

所以只需将这两项的值调大一些就可以让PHP脚本不会因为执行时间长而被终止了。request_terminate_timeout可以覆盖max_execution_time，

所以如果不想改全局的php.ini，那只改PHP-FPM的配置就可以了。

此外要注意的是Nginx的upstream模块中的max_fail和fail_timeout两项。有时Nginx与上游服务器（如Tomcat、FastCGI）的通信只是偶然断掉了，

但max_fail如果设置的比较小的话，那么在接下来的fail_timeout时间内，Nginx都会认为上游服务器挂掉了，都会返回502错误。

所以可以将max_fail调大一些，将fail_timeout调小一些。

4、Nginx出现的413 Request Entity Too Large错误

这个错误一般在上传文件的时候会出现，

编辑Nginx主配置文件Nginx.conf，找到http{}段，添加

client_max_body_size 10m; //设置多大根据自己的需求作调整.

如果运行php的话这个大小client_max_body_size要和php.ini中的如下值的更大值一致或

者稍大，这样就不会因为提交数据大小不一致出现的错误。

post_max_size = 10M

upload_max_filesize = 2M

5、解决504 Gateway Time-out(nginx)

遇到这个问题是在升级discuz论坛的时候遇到的一般看来, 这种情况可能是由于nginx默认的

fastcgi进程响应的缓冲区太小造成的, 这将导致fastcgi进程被挂起, 如果你的fastcgi服务

对这个挂起处理的不好, 那么最后就极有可能导致504 Gateway Time-out,现在的网站, 尤其某

些论坛有大量的回复和很多内容的, 一个页面甚至有几百K。默认的fastcgi进程响应的缓冲区

是8K, 我们可以设置大点在nginx.conf里, 加入： fastcgi_buffers 8 128k这表示设置

fastcgi缓冲区为8×128

当然如果您在进行某一项即时的操作, 可能需要nginx的超时参数调大点，例如设置成90秒：

send_timeout 90;只是调整了这两个参数, 结果就是没有再显示那个超时, 效果不错

Nginx中关于与上游服务器通信超时时间的配置factcgi_connect/read/send_timeout。

以Nginx超时时间为90秒，PHP-FPM超时时间为300秒为例，报504 Gateway Timeout错误时的Nginx错误访问日志如下：

/09/19 00:55:51 27600#0: *78877 upstream timed out (110: Connection timed out) while reading response header from upstream,

client: 192.168.1.101, server: test.com, request: “POST /index.php HTTP/1.1″, upstream: ”

host: “test.com”, referrer: “

“

调高这三项的值（主要是read和send两项，默认不配置的话Nginx会将超时时间设为60秒）之后，504错误也解决了。

而且这三项配置可以配置在http、server级别，也可以配置在location级别。担心影响其他应用的话，就配置在自己应用的location中吧。

要注意的是factcgi_connect/read/send_timeout是对FastCGI生效的，而proxy_connect/read/send_timeout是对proxy_pass生效的。

配置举例：

location ~ \.php$ {

root /home/cdai/test.com;

include fastcgi_params;

fastcgi_connect_timeout;

fastcgi_read_timeout0;

fastcgi_send_timeout0;

fastcgi_passunix:/dev/shm/php-fcgi.sock;

fastcgi_indexindex.php;

fastcgi_paramSCRIPT_FILENAME /home/cdai/test.com$fastcgi_script_name;

}

6、如何使用Nginx Proxy

朋友一台服务器运行tomcat 为8080端口,IP:192.168.1.2:8080,另一台机器

IP:192.168.1.8. 朋友想通过访问

即可访问tomcat服务.配置如下:

在192.168.1.8的nginx.conf上配置如下:

server {

listen 80;

server_name java.linuxtone.org

location / {

proxy_pass

include /usr/local/nginx/conf/proxy.conf;

}

}

7. 安装完成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/tcp dpt:80

就说明防火墙规则已经添加成功了，再在站外访问就正常了。

8、如何关闭Nginx的LOG

access_log /dev/null

error_log /dev/null

此外，错误日志主要记录客户端访问nginx出错时的日志，通过错误日志，能快速定位客户端访问异常！

错误信息

错误说明

“upstream prematurely（过早的） closed connection”

请求uri的时候出现的异常，是由于upstream还未返回应答给用户时用户断掉连接造成的，对系统没有影响，可以忽略

“recv() failed (104: Connection reset by peer)”

（1）服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；

（2）客户关掉了浏览器，而服务器还在给客户端发送数据；

（3）浏览器端按了Stop

“(111: Connection refused) while connecting to upstream”

用户在连接时，若遇到后端upstream挂掉或者不通，会收到该错误

“(111: Connection refused) while reading response header from upstream”

用户在连接成功后读取数据时，若遇到后端upstream挂掉或者不通，会收到该错误

“(111: Connection refused) while sending request to upstream”

Nginx和upstream连接成功后发送数据时，若遇到后端upstream挂掉或者不通，会收到该错误

“(110: Connection timed out) while connecting to upstream”

nginx连接后面的upstream时超时

“(110: Connection timed out) while reading upstream”

nginx读取来自upstream的响应时超时

“(110: Connection timed out) while reading response header from upstream”

nginx读取来自upstream的响应头时超时

“(110: Connection timed out) while reading upstream”

nginx读取来自upstream的响应时超时

“(104: Connection reset by peer) while connecting to upstream”

upstream发送了RST，将连接重置

“upstream sent invalid header while reading response header from upstream”

upstream发送的响应头无效

“upstream sent no valid HTTP/1.0 header while reading response header from upstream”

upstream发送的响应头无效

“client intended to send too large body”

用于设置允许接受的客户端请求内容的更大值，默认值是1M，client发送的body超过了设置值

“reopening logs”

用户发送kill -USR1命令

“gracefully shutting down”,

用户发送kill -WINCH命令

“no servers are inside upstream”

upstream下未配置server

“no live upstreams while connecting to upstream”

upstream下的server全都挂了

“SSL_do_handshake() failed”

SSL握手失败

“ngx_slab_alloc() failed: no memory in SSL session shared cache”

ssl_session_cache大小不够等原因造成

“could not add new SSL session to the session cache while SSL handshaking”

Linux系统问题NGINX？

就是把外部流量分配到内部的多个服务器上去，达到均衡的效果

反向代理是个替枣宽族巧悄身凳弊

nginx做流媒体，安装没问题，启动成功，但是无法访问到页面！

如态哗芦果windows下可以芦毕，linux不可以，那只能从防火帆带墙、selinux入手。

防火墙关掉， 使用命令 /etc/init.d/iptables stop

selinux关掉，使用命令 setenforce 0

关于linux 下nginx无法启动不了的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。

成都网站营销推广找创新互联，全国分站站群网站搭建更好做SEO营销。
创新互联（www.cdcxhl.com）四川成都IDC基础服务商，价格厚道。提供成都服务器托管租用、绵阳服务器租用托管、重庆服务器托管租用、贵阳服务器机房服务器托管租用。

本文标题：Linux下Nginx不能启动的解决方法 (linux 下nginx无法启动不了)
当前路径：http://www.shufengxianlan.com/qtweb/news15/508965.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联