做网站运营、服务器维护的朋友，肯定都遇到过这种紧急情况：网站突然打不开，刷新好几次都没反应，浏览器要么显示“无法连接服务器”，要么弹出“502 Bad Gateway”错误，后台刷新数据也加载失败。这时候心里肯定慌得一批——尤其是电商、资讯、企业官网这类依赖线上流量的平台，网站停一分钟，可能就少很多流量、丢很多客户，甚至影响品牌口碑，损失根本没法估量。
绝大多数时候，网站无法访问的核心原因之一，就是Nginx服务出了问题，要么是服务停止了，要么是重启失败。很多新手遇到这种情况，只会反复输入“systemctl restart nginx”，结果每次都报错，越急越乱，反而耽误了排查时间。其实Nginx重启失败、网站无法访问，并不是什么疑难杂症，只要找对方法，按步骤排查，哪怕是新手，也能在10-30分钟内定位问题、解决问题，快速恢复网站正常访问。
今天这篇文章，就用最口语化、最接地气的方式，把Nginx重启失败的所有常见原因、排查步骤、解决方法讲透，没有复杂的专业术语，全程手把手教学，不管你是刚接触服务器运维的新手，还是有一定经验的老运维，看完都能直接上手操作，紧急解决网站无法访问的燃眉之急。重点是，所有内容都规避了违规违禁词，贴合百度收录规则，大家可以放心参考、转发。
在正式开始排查之前，先跟大家说一个关键前提：所有操作一定要用root权限执行！很多新手排查半天没效果，最后才发现是没有权限，导致很多命令执行失败，白白浪费时间。切换root权限很简单，在终端输入“sudo -i”，输入服务器密码，就能切换到root用户，后续所有命令都能正常执行，这一步一定要记牢。
另外，给大家提个小建议：排查的时候，最好打开两个终端窗口，一个用来执行排查命令，一个用来查看Nginx日志，这样能实时看到错误信息，排查效率会高很多。还有，修改任何配置文件之前，一定要先备份！比如复制一份原配置文件，命名为“nginx.conf.bak”，这样就算改崩了，也能快速恢复，避免雪上加霜——这是运维的基本习惯，新手一定要养成。
一、先搞清楚：Nginx重启失败的常见现象，对号入座更高效
Nginx重启失败不是单一的情况，不同的报错提示，对应不同的问题。咱们先把常见的现象列出来，大家遇到问题时，先对号入座，就能快速锁定排查方向，不用盲目操作。
第一种现象：输入重启命令“systemctl restart nginx”后，终端直接报错，提示“Job for nginx.service failed because the control process exited with error code.”，这是最常见的报错，说明重启过程中出现了明确的错误，系统无法正常启动Nginx服务，网站自然无法访问。
第二种现象：重启命令输入后，没有任何报错，终端显示“OK”，但查看Nginx状态“systemctl status nginx”时，显示“active (running)”，可网站还是打不开，刷新多次依然提示无法连接。这种情况更隐蔽，说明Nginx虽然启动了，但配置有问题，无法正常提供服务，相当于“服务启动了，但没完全启动”。
第三种现象：重启时直接提示“nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)”，这种报错很直观，就是Nginx要监听的端口被其他进程占用了，无法绑定端口，所以重启失败。
第四种现象：报错提示“nginx: [error] open() "/var/run/nginx.pid" failed (2: No such file or directory)”，这是因为Nginx的PID文件丢失了，PID文件是记录Nginx主进程ID的文件，丢失后Nginx无法识别自身进程，就会启动失败。
第五种现象：重启时提示“nginx: [emerg] invalid directive "xxxx" in /etc/nginx/nginx.conf:15”，这种报错是配置文件有语法错误，比如指令拼写错误、少写分号、括号不匹配等，导致Nginx无法解析配置，启动失败。
第六种现象：重启后网站能访问，但打开速度极慢，或者偶尔能打开、偶尔打不开，查看Nginx状态显示正常，这种情况大概率是进程冲突、端口占用不彻底，或者日志文件过大导致的。
大家遇到的重启失败问题，基本都在这六种现象里，记住这些现象，后续排查就能有的放矢，不用瞎忙活。接下来，咱们就从最常见、最容易排查的问题开始，一步步教大家排查和解决，全程口语化，跟着做就行。
二、第一步：查看Nginx状态，锁定错误核心（最基础、最关键）
不管遇到哪种重启失败的情况，第一步都要先查看Nginx的运行状态，通过状态信息，快速锁定错误原因。这一步非常简单，输入命令就能看到详细信息，新手也能轻松操作。
在终端输入命令：systemctl status nginx（如果是CentOS 6及以下系统，输入service nginx status），输入后按回车，终端会显示Nginx的运行状态，包括是否正在运行、启动失败的原因、最近的日志信息等。
这里重点看两个地方：一是“Active”字段，显示“inactive (dead)”说明Nginx服务没启动，显示“failed”说明启动失败，显示“active (running)”说明服务正在运行，但可能有配置问题；二是红色的报错信息，这是排查问题的关键，比如“Process: 1234 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=1/FAILURE)”，后面的“status=1/FAILURE”就是启动失败的标识，再往下看，会有更具体的错误提示，比如“nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)”，直接就告诉我们是端口占用问题。
举个例子：如果输入status命令后，看到“nginx: [emerg] invalid number of arguments in "listen" directive in /etc/nginx/nginx.conf:12”，这就说明，在/etc/nginx/nginx.conf文件的第12行，“listen”指令的参数写错了，咱们直接去修改这一行就行，不用再排查其他问题，效率直接拉满。
这里提醒大家一句：一定要仔细看红色的报错信息，不要跳过，很多新手排查走弯路，就是因为忽略了这些明确的错误提示，反而去瞎找其他原因。如果status命令显示的信息不够详细，咱们可以查看Nginx的详细日志，后面会专门讲日志查看的方法。
三、第二步：检查配置文件语法，解决最常见的重启失败问题
根据我的运维经验，Nginx重启失败，80%的原因都是配置文件有语法错误。很多时候，咱们修改了Nginx配置，比如添加虚拟主机、修改端口、配置反向代理、设置SSL证书，保存后直接重启，结果报错，就是因为配置文件有语法错误——可能是少写了一个分号，可能是括号不匹配，也可能是指令拼写错误，比如把“proxy_pass”写成了“proxy_passs”，看似小事，却能导致Nginx无法启动。
很多新手遇到这种情况，会一个个去翻看配置文件，找半天也找不到错误，浪费时间。其实Nginx自带了配置文件语法检查命令，不用手动查找，输入一条命令，就能快速定位错误所在的文件和行号，非常方便。
在终端输入命令：nginx -t，按回车后，系统会自动检测Nginx主配置文件和所有包含的子配置文件的语法是否正确。如果语法正确，终端会显示“nginx: configuration file /etc/nginx/nginx.conf test is successful”，说明配置文件没问题，可以放心重启；如果有错误，会明确指出错误所在的文件和行号，比如“nginx: (emerg) duplicate extension "gif" in /etc/nginx/conf.d/default.conf:17”，这句话的意思是，在/etc/nginx/conf.d/default.conf文件的第17行，重复写了“gif”扩展名，咱们直接打开这个文件，找到第17行，修改错误即可。
这里有几个细节要注意，新手很容易踩坑：
不同系统的Nginx配置文件路径可能不一样，CentOS系统的主配置文件通常在/etc/nginx/nginx.conf，子配置文件在/etc/nginx/conf.d/目录下；Ubuntu系统的主配置文件在/etc/nginx/nginx.conf，子配置文件在/etc/nginx/sites-available/目录下，大家根据自己的服务器系统查找，不要找错文件。
如果修改的是某个子配置文件，比如添加了一个虚拟主机配置，也可以单独检查这个文件的语法，输入命令：sudo nginx -t -c 子配置文件路径，比如sudo nginx -t -c /etc/nginx/conf.d/myweb.conf，这样能更精准地定位错误，不用检查所有配置文件。
常见的配置文件语法错误有哪些？给大家整理了最容易犯的几种，记下来，以后修改配置时可以提前规避：
（1）少写分号：Nginx配置文件中，每一条指令的结尾都必须加“;”，比如“listen 80;”“server_name www.xxx.com;”，如果少写了分号，就会报错，这是最常见的错误；
（2）括号不匹配：配置文件中，很多指令需要用“{}”包裹，比如server块、location块，比如“server { listen 80; server_name www.xxx.com; }”，如果只写了左括号，没写右括号，或者括号位置写错，都会导致语法错误；
（3）指令拼写错误：比如把“server_name”写成“servername”，把“location”写成“localtion”，把“ssl_certificate”写成“ssl_certificat”，这种拼写错误很隐蔽，需要仔细检查；
（4）端口配置错误：比如在同一个server块中，重复配置“listen 80;”，或者配置的端口不是整数，比如“listen 80.8;”，都会导致错误；
（5）路径错误：配置网站根目录、日志文件路径、SSL证书路径时，路径写错，比如把“/var/www/html”写成“/var/www/htm”，或者路径不存在，也会导致配置文件报错。
修改完配置文件后，一定要再次执行“nginx -t”检查语法，确认无误后，再执行重启命令“systemctl restart nginx”，这样就能避免因为配置错误导致的重启失败。如果修改后还是报错，就再仔细看错误提示，逐行检查配置文件，一般都能找到问题。
四、第三步：排查端口占用，解决“Address already in use”报错
如果重启Nginx时，提示“nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)”，说明Nginx要监听的端口被其他进程占用了，无法绑定端口，所以重启失败。这种情况也非常常见，尤其是服务器上同时运行了多个Web服务，比如Apache、Tomcat、Node.js服务等，都可能占用80（HTTP）或443（HTTPS）端口，导致Nginx无法启动。
解决这个问题的核心思路是：先找到占用端口的进程，然后停止这个进程，或者让Nginx换一个端口监听，二选一即可。咱们一步步来操作，非常简单。
第一步：查找占用端口的进程。Nginx默认监听80端口（HTTP）和443端口（HTTPS），咱们先排查这两个端口，输入命令：sudo lsof -i :80（排查80端口），或者sudo netstat -tulpn | grep :80（两种命令都可以，选一种就行）。如果是排查443端口，就把命令中的80改成443。
这里要注意，如果输入命令后，提示“command not found”，说明服务器上没有安装对应的工具，比如lsof或netstat，这时候需要先安装工具：
如果是Ubuntu/Debian系统，输入：sudo apt install lsof 或 sudo apt install net-tools，安装完成后再执行上面的命令；
如果是CentOS/RHEL系统，输入：sudo yum install lsof 或 sudo yum install net-tools，安装完成后再执行命令。
执行命令后，终端会显示占用该端口的进程信息，包括进程ID（PID）、进程名称（COMMAND）、进程所属用户（USER）等。比如终端显示“nginx 1234 root 6u IPv4 12345 0t0 TCP :http (LISTEN)”，说明是Nginx自身的进程占用了80端口；如果显示“httpd 5678 root 6u IPv4 54321 0t0 TCP :http (LISTEN)”，说明是Apache服务占用了80端口；如果显示“node 7890 root 6u IPv4 98765 0t0 TCP *:http (LISTEN)”，说明是Node.js服务占用了80端口。
第二步：处理占用端口的进程，有两种方法，大家根据自己的需求选择：
方法一：停止占用端口的进程（推荐，适合不需要运行其他Web服务的情况）。比如发现是Apache服务占用了80端口，而我们不需要运行Apache，就可以停止Apache服务，输入命令：sudo systemctl stop apache2（Ubuntu系统）或sudo systemctl stop httpd（CentOS系统）。停止后，再输入命令查看端口占用情况，确认端口已经释放，然后再重启Nginx，一般就能成功。
如果是Nginx自身的旧进程占用了端口，说明之前的Nginx进程没有被完全杀死，输入命令：sudo nginx -s stop（优雅停止Nginx），然后输入ps aux | grep nginx，查看是否有残留的worker进程，如果有，输入sudo kill -9 进程PID（比如sudo kill -9 1234），强制终止残留进程，之后再重启Nginx即可。
这里提醒大家：如果占用端口的是重要进程，比如服务器上的其他业务服务，不要轻易停止，否则会导致其他业务中断，这时候可以选择方法二。
方法二：修改Nginx监听端口（适合需要保留其他进程的情况）。如果不想停止占用端口的进程，就可以让Nginx换一个端口监听，比如把80端口改成8080端口，具体操作如下：
打开Nginx主配置文件或对应的子配置文件，找到“listen”指令，比如“listen 80;”，把80改成其他未被占用的端口，比如“listen 8080;”；
如果配置了HTTPS，还要把443端口改成其他端口，比如“listen 443 ssl;”改成“listen 8443 ssl;”；
保存配置文件，执行“nginx -t”检查语法，确认无误后，重启Nginx；
重启成功后，网站访问地址需要加上端口号，比如之前是www.xxx.com，现在需要改成www.xxx.com:8080（HTTP）或www.xxx.com:8443（HTTPS）。
这里要注意：修改端口后，需要确保服务器的防火墙开放了新的端口，否则用户还是无法访问网站。比如开放8080端口，Ubuntu系统输入：sudo ufw allow 8080，CentOS系统输入：sudo firewall-cmd --permanent --add-port=8080/tcp，然后sudo firewall-cmd --reload，这样防火墙就会开放8080端口，用户就能正常访问了。
另外，给大家一个小技巧：启动Nginx前，先检查一下端口是否被占用，输入命令：sudo ss -tlnp | grep ':80'，快速确认80端口是否空闲，这样能提前避免端口占用导致的重启失败，节省排查时间。
四、第四步：排查进程冲突，解决“进程残留”导致的重启失败
有时候，我们输入重启命令后，报错信息不明显，或者status命令显示“failed”，但找不到具体原因，这时候大概率是Nginx的旧进程没有被完全杀死，导致新进程无法启动，出现进程冲突。这种情况在手动杀死Nginx进程后，或者Nginx服务卡死时，非常容易出现。
比如，之前我们用“kill -9 进程PID”强制杀死了Nginx进程，但还有一些残留的worker进程没有被杀死，这时候再启动Nginx，就会出现进程冲突，导致重启失败。解决这种问题的核心，就是彻底清理Nginx的残留进程，然后再重启服务。
第一步：查看当前系统中的Nginx进程，输入命令：ps aux | grep nginx，按回车后，终端会显示所有包含“nginx”关键字的进程。正常情况下，启动Nginx后，会有一个主进程（master process）和多个工作进程（worker process）；如果重启失败，可能会出现多个主进程，或者残留的worker进程。
第二步：彻底杀死所有Nginx进程，输入命令：sudo pkill -9 nginx，这个命令会强制终止所有包含“nginx”关键字的进程，不管是主进程还是worker进程，都能一次性杀死。如果担心杀不干净，可以再输入ps aux | grep nginx，查看是否还有残留进程，如果还有，就输入sudo kill -9 进程PID，逐个杀死残留进程。
第三步：清理残留的PID文件和锁文件。有时候，Nginx进程被杀死后，会留下PID文件和锁文件，这些文件会导致Nginx认为服务还在运行，从而无法启动。PID文件的默认路径是/var/run/nginx.pid或/run/nginx.pid，锁文件的默认路径是/var/lock/nginx.lock，我们需要手动删除这些文件。
输入命令：sudo rm -f /var/run/nginx.pid（如果路径是www.wukong-b2b.com/run/nginx.pid，就输入sudo rm -f /run/nginx.pid），然后输入sudo rm -f /var/lock/nginx.lock（如果没有这个文件，会提示“没有那个文件或目录”，不用管，继续操作即可）。
第四步：重新启动Nginx，输入命令：systemctl restart nginx，这时候一般就能正常启动了。如果还是启动失败，就再查看status命令的报错信息，结合前面的步骤，排查其他问题。
这里给大家一个小提醒：尽量不要用“kill -9”命令强制杀死Nginx进程，除非万不得已。因为强制杀死进程，容易导致进程残留、PID文件丢失等问题，建议优先使用“sudo nginx -s stop”（快速停止）或“sudo nginx -s quit”（优雅停止，会处理完当前请求后再停止），这样能减少进程残留的概率。
五、第五步：排查权限问题，解决“Permission denied”报错
很多新手会忽略权限问题，导致Nginx重启失败，或者启动后网站无法访问，报错提示“Permission denied”（权限不足）。Nginx运行时，会以指定的用户身份执行，默认情况下，CentOS系统中是“nginx”用户，Ubuntu系统中是“www-data”用户，如果这个用户没有权限访问配置文件、日志目录、网站根目录，就会导致重启失败，或者启动后出现403 Forbidden错误。
权限问题的排查和解决，主要分三步，一步步来，非常简单：
第一步：确认Nginx运行的用户。输入命令：ps aux | grep nginx，终端输出结果中，“USER”列显示的就是Nginx运行的用户，比如“nginx”或“www-data”，记下来这个用户名，后面会用到。
第二步：检查相关目录和文件的权限。Nginx需要访问的目录和文件主要有三个：配置文件目录、日志目录、网站根目录，我们需要确保这些目录和文件的所有者是Nginx运行的用户，并且有对应的读写权限。
检查配置文件目录权限：配置文件目录默认是/etc/nginx，输入命令：ls -l /etc/nginx，查看目录的所有者和权限。如果所有者不是Nginx运行的用户，就输入命令：sudo chown -R nginx:nginx /etc/nginx（CentOS系统，nginx是运行用户），或者sudo chown -R www-data:www-data /etc/nginx（Ubuntu系统，www-data是运行用户），把目录的所有者改成Nginx运行的用户。
检查日志目录权限：日志目录默认是/var/log/nginx，输入命令：ls -l /var/log/nginx，查看所有者和权限。同样，把所有者改成Nginx运行的用户，输入命令：sudo chown -R nginx:nginx /var/log/nginx（CentOS）或sudo chown -R www-data:www-data /var/log/nginx（Ubuntu）。另外，还要确保日志文件有读写权限，输入命令：sudo chmod 644 /var/log/nginx/*，给所有日志文件赋予可读可写权限。
检查网站根目录权限：网站根目录默认是/var/www/html（Ubuntu）或/usr/share/nginx/html（CentOS），输入命令：ls -l /var/www/html（根据自己的根目录路径修改），查看所有者和权限。把所有者改成Nginx运行的用户，输入命令：sudo chown -R nginx:nginx /var/www/html（CentOS）或sudo chown -R www-data:www-data /var/www/html（Ubuntu），然后输入命令：sudo chmod 755 /var/www/html，给网站根目录赋予可执行权限，确保Nginx能访问目录下的文件。
第三步：检查SELinux状态（仅CentOS系统需要，Ubuntu系统无需操作）。SELinux是CentOS系统自带的安全机制，默认是开启状态，有时候会阻止Nginx访问相关目录，导致权限不足，重启失败。我们可以先查看SELinux状态，输入命令：/usr/sbin/sestatus，如果显示“SELINUX=enforcing”，说明SELinux是开启的，需要关闭；如果显示“SELINUX=disabled”，说明已经关闭，不用操作。
关闭SELinux的方法：输入命令：vi /etc/selinux/config，打开配置文件，找到“SELINUX=enforcing”，改成“SELINUX=disabled”，保存并退出，然后重启服务器，SELinux就会关闭。这里提醒大家：生产环境中，不建议直接关闭SELinux，可以通过配置SELinux规则来允许Nginx访问相关目录，不过新手可以先关闭SELinux，解决当前问题，后续再学习SELinux的相关配置。
修改完权限和SELinux状态后，输入命令：systemctl restart nginx，一般就能正常启动Nginx，网站也能正常访问了。如果还是报错，就查看错误日志，确认是否还有其他权限相关的问题。
六、第六步：查看Nginx日志，排查所有隐藏问题（终极方法）
如果前面的步骤都排查完了，Nginx还是重启失败，网站还是无法访问，或者报错信息不明确，这时候就需要查看Nginx的错误日志，日志会记录Nginx运行过程中的所有错误，包括重启失败的具体原因，这是排查所有隐藏问题的终极方法，不管什么问题，都能在日志中找到线索。
Nginx有两个主要的日志文件，一个是错误日志（error.log），一个是访问日志（access.log），我们重点查看错误日志，访问日志主要记录用户的访问请求，对排查重启失败帮助不大。
第一步：找到错误日志的路径。错误日志的默认路径是/var/log/nginx/error.log，不管是CentOS还是Ubuntu系统，默认路径基本都是这个，如果修改过日志路径，可以在Nginx主配置文件中查找，找到“error_log”指令，后面的路径就是错误日志的路径，比如“error_log /var/log/nginx/error.log warn;”。
第二步：查看错误日志。输入命令：sudo tail -50 /var/log/nginx/error.log，这个命令会显示错误日志的最近50行，重点关注带有“error”“emerg”关键字的条目，这些就是导致Nginx重启失败的原因。如果50行不够，可以把50改成100，查看更多日志内容。
给大家举几个常见的日志错误案例，大家可以对应排查：
案例1：日志显示“could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)”，这是日志目录权限不足，按照前面权限排查的步骤，修改日志目录的所有者和权限即可；
案例2：日志显示“invalid directive "proxy_passs" in /etc/nginx/conf.d/ssl.conf:5”，这是配置文件中指令拼写错误，把“proxy_passs”改成“proxy_pass”，保存后重新检查配置、重启Nginx即可；
案例3：日志显示“no such file or directory: "/var/www/html/index.html"”，这是网站根目录下没有默认首页文件（index.html、index.php等），添加一个默认首页文件即可，比如新建一个index.html文件，输入简单的内容，保存后重启Nginx；
案例4：日志显示“nginx: [emerg] SSL_CTX_new() failed (SSL: error:140A80B1:SSL routines:SSL_CTX_check_private_key:no certificate assigned)”，这是SSL证书配置错误，比如证书路径写错、证书文件缺失，重新配置SSL证书路径即可；
案例5：日志显示“nginx: [error] fork() failed while spawning "worker process" (12: Cannot allocate memory)”，这是服务器内存不足，导致Nginx无法创建worker进程，需要释放服务器内存，比如关闭不需要的进程，或者升级服务器内存，之后再重启Nginx。
另外，我们还可以通过日志分析其他问题，比如网站访问慢、异常状态码等，比如输入命令：awk '{print $10, $7}' /var/log/nginx/access.log | sort -nr | head -10，就能查看响应时间最慢的10个请求，帮助我们优化网站性能。如果日志文件太大，查看起来不方便，可以先进行日志分割，比如创建一个脚本，每天备份日志并压缩，避免单文件过大影响查看，具体的脚本可以参考网上的教程，或者去悟空B2B平台www.wukong-b2b.com找专业的运维工具和脚本，上面有很多实用的运维资源，能帮我们节省排查时间，快速解决各类服务器和Nginx相关问题。
七、第七步：排查环境问题，解决“依赖缺失、版本不兼容”导致的重启失败
这种情况相对少见，但也会导致Nginx重启失败，尤其是在服务器系统升级、Nginx版本升级后，容易出现。环境问题主要包括：Nginx依赖的库文件缺失、Nginx版本和系统版本不兼容、Nginx安装不完整等。
第一步：检查Nginx依赖的库文件。Nginx运行需要依赖一些系统库文件，如果这些库文件缺失，就会导致Nginx无法启动。输入命令：ldd /usr/sbin/nginx（CentOS系统）或ldd /usr/bin/nginx（Ubuntu系统），这个命令会显示Nginx依赖的所有库文件，如果有库文件缺失，会提示“not found”，比如“libpcre.so.1 => not found”，说明缺少pcre库文件。
解决方法：安装缺失的库文件，比如缺少pcre库文件，Ubuntu系统输入：sudo apt install libpcre3 libpcre3-dev，CentOS系统输入：sudo yum install pcre pcre-devel；如果缺少openssl库文件，Ubuntu系统输入：sudo apt install openssl libssl-dev，CentOS系统输入：sudo yum install openssl openssl-devel，安装完成后，再重启Nginx即可。
第二步：检查Nginx版本和系统版本是否兼容。比如某些旧版本的Nginx不支持新版本系统的某些特性，比如CentOS 8系统安装了Nginx 1.16以下版本，就可能出现兼容性问题，导致重启失败；或者Ubuntu 22.04系统安装了过旧的Nginx版本，也会出现问题。
解决方法：升级Nginx到最新稳定版本，或者降级到与系统兼容的版本。升级Nginx的方法很简单，Ubuntu系统输入：sudo apt update && sudo apt upgrade nginx，CentOS系统输入：sudo yum update nginx，升级完成后，重启Nginx即可。如果升级后还是有问题，可以卸载当前Nginx，重新安装兼容版本的Nginx。
第三步：检查Nginx安装是否完整。如果Nginx是通过源码安装的，可能是安装过程中出现错误，导致安装不完整，从而无法重启。这种情况可以重新源码安装Nginx，确保安装过程中没有报错，安装完成后，再尝试重启。如果是通过yum或apt命令安装的，可以先卸载Nginx，再重新安装，输入命令：sudo yum remove nginx（CentOS）或sudo apt remove nginx（Ubuntu），卸载完成后，再输入sudo yum install nginx（CentOS）或sudo apt install nginx（Ubuntu），重新安装即可。
八、常见报错案例汇总，遇到问题直接对号入座（新手必看）
前面给大家讲了排查步骤和方法，这里给大家汇总几个最常见的Nginx重启失败报错案例，以及对应的解决方法，大家遇到问题时，直接对号入座，不用再一步步排查，节省时间。
案例1：报错“nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)”
原因：80端口被其他进程占用；
解决方法：用sudo lsof -i :80查看占用端口的进程，停止冲突进程，或修改Nginx监听端口，具体操作前面已经详细讲过。
案例2：报错“nginx: [emerg] invalid number of arguments in "listen" directive in /etc/nginx/nginx.conf:12”
原因：配置文件第12行“listen”指令参数错误；
解决方法：打开nginx.conf文件，找到第12行，修改“listen”指令的参数，比如把“listen 80 8080;”改成“listen 80;”，保存后执行nginx -t检查语法，再重启Nginx。
案例3：报错“nginx: [error] open() "/var/run/nginx.pid" failed (2: No such file or directory)”
原因：PID文件丢失；
解决方法：手动创建PID文件，输入sudo touch /var/run/nginx.pid，然后修改PID文件权限，sudo chown nginx:nginx /var/run/nginx.pid，之后重启Nginx。
