CentOS 7下Nginx编译安装与生产实战手册-代码聚汇网

1. 为什么还要写一份 CentOS 7 的 Nginx 手册

很多朋友看到这个题目可能会问：Nginx 的教程网上铺天盖地，CentOS 7 也是老系统了，还有什么好写的？说实话，我写这份手册的原因恰恰就在这里。

因为工作原因，我这些年经手的服务器里，CentOS 7 依然占据相当比例。尤其是传统企业、金融机构、政府项目中，存量 CentOS 7 机器极多，上面的业务系统短期内根本迁移不完。而 Nginx 作为接入层的绝对主力，几乎每台机器上都有它的身影。问题是，网上关于 Nginx 的资料虽然多，但大多是 CentOS 7 刚发布那几年的老文章，依赖源早就变了，编译参数也跟不上时代；要么就是纯讲 Ubuntu 系的配置，跟 CentOS 的 systemd 管理方式对不上；更常见的是那种只讲"怎么装"不讲"为什么这么装"的教程，照着做完稀里糊涂，出了问题完全不知道从哪里排查。

这份手册就是冲着这些问题去的。我会以 CentOS 7 为基线环境，从零开始，完整演示 Nginx 的编译安装、核心配置、常见场景实战以及高频故障排查。不讲废话，不炫技，全部是这些年我在生产环境里实测过、踩过坑之后沉淀下来的东西。

内容覆盖这几个方向：编译安装时的参数如何取舍、配置文件的层级逻辑怎么理解、反向代理和负载均衡到底怎么配才稳、HTTPS 证书怎么接、以及那些动不动就出现的 502、504 状态码到底该怎么查。不管是刚入行的运维新人，还是需要自己动手搭服务的后端开发，这份手册都能直接给你一套可以落地照做的方案。

先说清楚：这里的命令和配置，我默认你手上有一台装好了 CentOS 7 的机器，能联网，并且有 root 权限。如果你连系统都还没装好，建议先搞一台虚拟机练手，后面我会专门讲生产环境与实验室环境的差异。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. Nginx 核心工作模型与 CentOS 7 系统准备

2.1 理解 Nginx 的高性能从何而来

在动手安装之前，先花几分钟把 Nginx 的工作模型弄清楚，这直接关系到后续配置时你能否做出正确判断。

Nginx 采用 master-worker 多进程模型。启动后，你会看到一个 master 进程和若干个 worker 进程。master 进程不处理具体请求，它的职责是读取配置、管理 worker 进程的生命周期、处理平滑重载和日志切割等管理类操作。真正干活的，是那些 worker 进程。

每个 worker 进程内部采用事件驱动模型，基于 epoll（Linux 内核提供的高并发 IO 事件通知机制）来同时监听大量连接。这就是所谓的高并发能力来源：单个 worker 进程可以同时处理成千上万个连接，而不需要像 Apache 那样一个连接就占一个进程或线程。

用生活化的例子来说，Apache 就像一家餐厅，来了一个客人就专门安排一个服务员全程陪着，人少还行，人一多服务员就不够用了。Nginx 的 worker 更像一个经验丰富的前台，他同时接待所有客人，谁有需求他响应谁，空闲的间隙还能收拾桌子、接电话。同样的资源下，接待能力自然高出一个量级。

理解这个模型，你就能明白几个关键结论：

worker 进程数建议设置为 CPU 核心数或核心数的两倍，而不是越多越好。进程多了反而因为上下文切换消耗 CPU。
因为请求是异步处理的，很多你以为会阻塞的配置项，在 Nginx 里有专门的异步处理机制，这也是它适合做反向代理和高并发静态服务的原因。
平滑重载（nginx -s reload）之所以能做到不停机更新配置，正是因为 master 进程会先加载新配置并启动新的 worker，再优雅地关闭旧 worker。

带着这些基础认知，后面配置时你就知道为什么某些参数要这么调了。

2.2 CentOS 7 初始化与安装前置依赖

CentOS 7 安装完成后，第一步不是急着装 Nginx，而是先把系统基础环境打点好。

第一件事是确认网络和软件源。执行以下命令：

bash复制ping -c 3 www.baidu.com
yum clean all
yum makecache

如果 ping 不通外网，先排查网络问题，否则后面所有依赖都装不了。yum 源建议直接替换为国内镜像源，速度会快很多。

第二件事是安装编译工具链和 Nginx 所需的依赖库：

bash复制yum install -y gcc gcc-c++ make pcre pcre-devel zlib zlib-devel openssl openssl-devel

逐一说下这些包是干什么用的：

gcc、gcc-c++、make：编译源码的基础工具，缺了它们你连 configure 都跑不起来。
pcre / pcre-devel：Nginx 的 rewrite 模块依赖 PCRE 库来实现正则表达式匹配。没有它，location 中的正则写法、if 指令中的正则判断都会直接报错。
zlib / zlib-devel：用于 Gzip 压缩模块。现代网站基本都开了 gzip，没有这个库编译时会直接报错。
openssl / openssl-devel：HTTPS 功能的基石，同时 HTTP/2、TLS 会话缓存等能力也依赖 OpenSSL 库。

这里有个小坑：CentOS 7 自带的 OpenSSL 版本停留在 1.0.2k，不支持 TLS 1.3。如果你对加密协议版本有合规要求，后面需要自行编译新版 OpenSSL 再编译 Nginx，这个我放到 HTTPS 章节单独讲。

2.3 关闭或合理配置防火墙与 SELinux

CentOS 7 最大的两个拦路虎，一个是 firewalld，一个是 SELinux。

firewalld 是系统的防火墙服务，默认开着。直接执行：

bash复制systemctl stop firewalld
systemctl disable firewalld

生产环境我不建议直接这样关掉，但如果你只是想快速搭服务学习，关闭最省事。如果是生产环境，应该只在防火墙里放行需要的端口，比如：

bash复制firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --reload

SELinux 是另一个容易踩坑的地方。它的安全策略默认会阻止 Nginx 访问某些目录，典型表现是：配置文件看着完全没问题，nginx 也启动了，但访问就是 403 或者 502。最直接的判断方式：

bash复制getenforce

输出 Enforcing 就说明 SELinux 正在强制模式。简单粗暴的做法是改成宽容模式：

bash复制setenforce 0
sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

改完配置文件后建议重启系统生效。不过要提醒一句：SELinux 本身是很好的安全机制，在互联网企业或高安全要求的场景下，正确的做法是学会写 SELinux 策略放行 Nginx 的特定行为，而不是一刀切关闭。实话说，国内大多数团队为了效率都选择了关闭，这个决定对错先不论，但你必须知道自己关掉了什么。

3. Nginx 源码编译安装全流程实操

3.1 官方源与源码编译怎么选

CentOS 7 上安装 Nginx 有两条主流路线：一条是用 EPEL 源或 Nginx 官方源直接装 rpm 包，另一条是下载源码自行编译安装。

两种方式各有利弊。rpm 包安装的优点是省事，依赖自动解决，后续升级方便，并且启动脚本、配置文件路径、日志切割都已经帮你安排好了。缺点是版本相对保守，而且默认编译参数不一定包含你想要的所有模块。

源码编译的优点是灵活，你可以自由选择版本、模块和安装路径，甚至能针对业务场景定制优化选项。缺点是需要自己维护后续升级，同时所有配置文件、systemd 管理脚本都要自己写。

我的建议是：生产环境如果对稳定性要求高、不想花费额外精力维护，直接用 Nginx 官方源装 rpm 包就够了；如果你需要新版本特性，或者要集成第三方模块（比如 Brotli 压缩、Lua 扩展等），或者对 Nginx 的安装路径有统一规划，那就走源码编译。

这里重点讲解源码编译的方式，因为它是理解 Nginx 内部结构的捷径，而且一旦掌握了，后面用 rpm 反而不需要学。

3.2 下载源码并完成 configure 参数定制

先到 Nginx 官网下载稳定版本。写这份手册的时候，最新的稳定版本是 1.24.x 系列，我以 nginx-1.24.0 为例。选择稳定版（Stable version）而不是主线版（Mainline version），是生产环境的基本原则。

bash复制cd /usr/local/src
wget https://nginx.org/download/nginx-1.24.0.tar.gz
tar -zxvf nginx-1.24.0.tar.gz
cd nginx-1.24.0

接下来是关键步骤：configure 参数配置。这是源码编译的核心决策点，你的每一个选择都会直接影响最终 nginx 二进制的能力和目录结构。

我用的生产级配置参数如下：

bash复制./configure \
--prefix=/usr/local/nginx \
--user=nginx \
--group=nginx \
--with-http_ssl_module \
--with-http_v2_module \
--with-http_realip_module \
--with-http_stub_status_module \
--with-http_gzip_static_module \
--with-pcre \
--with-stream \
--with-stream_ssl_module \
--with-file-aio

逐个解释一下这些参数的意义：

--prefix=/usr/local/nginx：指定安装根目录。后续配置文件在 /usr/local/nginx/conf 下，日志在 /usr/local/nginx/logs 下，二进制在 /usr/local/nginx/sbin 下。这样全在一个目录树里，管理很方便。
--user=nginx --group=nginx：指定 Nginx 的 worker 进程以 nginx 用户身份运行。这是安全最佳实践，绝不能用 root 跑 worker。
--with-http_ssl_module：HTTPS 支持，必选。
--with-http_v2_module：HTTP/2 支持，现在几乎成了标配。
--with-http_realip_module：当 Nginx 前面还挂着 CDN 或负载均衡时，获取客户端真实 IP 就靠这个模块。
--with-http_stub_status_module：提供监控 Nginx 运行状态的页面，运维必备。
--with-http_gzip_static_module：支持预压缩静态文件，能直接发送 .gz 文件，省去每次请求时压缩的性能损耗。
--with-pcre：显式启用 PCRE 库，rewrite 支持的基础。
--with-stream：启用第四层（TCP/UDP）代理能力。这个非常重要，很多人不知道 Nginx 除了七层反代还能做四层负载均衡。
--with-thread：启用线程池，能显著提升某些阻塞类 IO 场景的处理效率。
--with-file-aio：启用异步文件 IO，配合高性能磁盘时能提升静态文件处理速度。

3.3 编译安装与用户创建

configure 跑完后，再执行编译安装：

bash复制make -j$(nproc)
make install

加 -j$(nproc) 表示用机器的全核并行编译，速度能快好几倍。编译过程可能需要几分钟，看到最后没有 error 就算成功。

编译之前需要创建 nginx 用户：

bash复制useradd -M -s /sbin/nologin nginx

-M 表示不创建 home 目录，-s /sbin/nologin 表示该用户不能登录 shell，这是服务账号的标准做法。

安装完成后，验证版本信息和编译参数：

bash复制/usr/local/nginx/sbin/nginx -V

如果最后一行能看到你刚才配的那一串 configure arguments，说明编译成功，参数也生效了。

3.4 编写 systemd 服务脚本实现开机自启

源码编译安装的 Nginx 没有自带 systemd 服务脚本，需要手动创建。在 /etc/systemd/system/nginx.service 文件中写入以下内容：

ini复制[Unit]
Description=nginx - high performance web server
Documentation=http://nginx.org/en/docs/
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s quit
PrivateTmp=true

[Install]
WantedBy=multi-user.target

然后执行：

bash复制systemctl daemon-reload
systemctl start nginx
systemctl enable nginx

这里有两个细节要注意。

第一个，Type=forking 这个设置。Nginx 启动时，master 进程会 fork 出子进程，然后主进程在后台运行。systemd 通过 PIDFile 来跟踪 Nginx master 进程的 PID，这样才能准确判断服务状态。如果忘记配 PIDFile，systemctl status 的结果会不准确，停服务时也可能出现找不到进程的情况。

第二个，配置文件里必须设置 pid /usr/local/nginx/logs/nginx.pid;，否则 systemd 找不到 PID 文件，照样报错。安装后默认配置里这一行是有的，但如果你自定义过配置文件，一定要检查这一行还在不在。

启动后访问 http://服务器IP/，能看到"Welcome to nginx!"的页面，就说明一切正常。用 systemctl status nginx 能看到 active (running) 的状态。

4. Nginx 配置文件结构逐层拆解

4.1 nginx.conf 的主干结构

Nginx 的配置文件逻辑上是分层的树状结构，从外到内依次是：main（全局配置）、events（事件模块配置）、http（HTTP 服务配置）、server（虚拟主机配置）、location（请求路径配置）。

我用一句话概括：http 块里可以有多个 server 块，每个 server 块对应一个域名或一组端口的服务；server 块里又可以有多个 location 块，每个 location 对应 URL 路径的处理规则。

打开默认的 /usr/local/nginx/conf/nginx.conf，你会看到文件最开头是这类全局配置：

nginx复制user  nginx;
worker_processes  auto;
error_log  /var/log/nginx/error.log  warn;
pid        /var/log/nginx/nginx.pid;

user nginx：worker 进程的运行身份。
worker_processes auto：让 Nginx 自动匹配 CPU 核心数，一般不需要手动改。
error_log：错误日志路径，排错时第一眼就要看这个文件。

events 块长这样：

nginx复制events {
    worker_connections  1024;
}

worker_connections 表示单个 worker 进程能同时保持的最大连接数。默认 1024 偏小，生产环境一般调到 65535 或更高。但要注意，这个值还受系统文件描述符限制影响，所以还要配合修改 /etc/security/limits.conf。

http 块是配置的核心，里面包含 mime.type 引入、日志格式定义、sendfile、keepalive 等一系列全局 HTTP 行为设置，然后才是一个个 server 块。

说个经验之谈：配置 Nginx 最忌讳的就是把什么东西都堆在 nginx.conf 里。生产环境通常的做法是用 include 指令把不同站点、不同功能的配置拆成独立文件，放到 /usr/local/nginx/conf/conf.d/ 目录下，主配置文件只负责全局设置和 include 引入。后续维护时看到文件名就能大概猜到里面的内容，定位问题快得多。

4.2 虚拟主机 server 块配置实战

server 块的作用是把不同域名、不同端口的请求区分开来，分发到不同的站点处理。

比如你有一台服务器，要同时跑 example.com 和 api.example.com 两个站点，配置可以这样写：

nginx复制server {
    listen       80;
    server_name  example.com www.example.com;
    root         /data/www/example;
    index        index.html index.htm;
}

server {
    listen       80;
    server_name  api.example.com;
    root         /data/www/api;
    index        index.php index.html;
}

这里有几个细节展开说一下。

listen 指令可以只写端口，也可以写成 IP:端口 的形式。如果服务器有多个 IP，想只监听其中一个 IP 上的 80 端口，就写 listen 192.168.1.10:80;。

server_name 是虚拟主机的关键匹配条件。Nginx 在处理请求时，先根据 listen 的端口区分，再根据 HTTP 请求头里的 Host 字段匹配 server_name。如果匹配不到任何 server_name，就用 listen 指令中第一个出现的 server 块或默认 server 块来处理。这也是为什么我建议在每个监听端口上都显式设置一个 default_server，防止别有用心的请求匹配到不希望的站点：

nginx复制server {
    listen 80 default_server;
    return 444;
}

return 444 是 Nginx 的特殊响应码，含义是直接关闭连接，不返回任何内容。把这个配置作为兜底，能有效避免未绑定域名指向服务器 IP 时被扫到。

4.3 location 匹配规则与优先级

location 是 Nginx 配置里最灵活、也最容易写错的部分。它的作用是根据请求的 URL 路径来决定如何处理这个请求。

location 的匹配规则分两类：前缀匹配和正则匹配。常用的写法有以下几种：

nginx复制location = / {
    # 精确匹配根路径
}

location /images/ {
    # 普通前缀匹配
}

location ~ \.php$ {
    # 正则匹配，区分大小写
}

location ~* \.(jpg|png)$ {
    # 正则匹配，忽略大小写
}

location ^~ /static/ {
    # 前缀匹配，如果匹配成功则不再进行正则匹配
}

匹配优先级是初学者最头疼的部分，我用一句话概括：精确匹配（=）最高，其次是 ^~ 前缀匹配，然后是正则匹配（~ 与 ~*），最后是普通前缀匹配。

如果拿不准优先级，有个笨办法：写完后用 nginx -t 测试配置，再用 curl 测试各种路径看是否命中了预期 location。

分享一个真实踩坑经历。我之前配置过一个下载站：

nginx复制location /downloads/ {
    alias /data/files/;
}

location ~ \.(mp4|zip)$ {
    root /data/files/;
    expires 7d;
}

结果所有 /downloads/ 下的 mp4 文件都走的是下面那个正则规则，因为正则优先级高于普通前缀匹配。这导致文件路径被 root 解析为 /data/files/ 加原始 URI 路径，文件全 404 了。后来我把 downloads 的 location 改成 ^~ 才解决。这个问题的教训是：如果要让某个前缀路径完全掌控匹配行为，就用 ^~ 切断正则匹配。

5. 高频实战场景配置：反向代理、负载均衡与 HTTPS

5.1 反向代理配置：从入门到生产级

反向代理是 Nginx 最核心的场景之一。所谓反向代理，简单说就是客户端访问的是 Nginx，Nginx 再把请求转发给后端的真实服务器，然后把结果返回给客户端。客户端全程不知道后端服务器的存在。

一个最简单的反向代理配置：

nginx复制server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

这里面的四个 proxy_set_header 每一个都很讲究：

Host $host：把原始请求的 Host 头透传给后端。没有这一行，后端应用拿到的 Host 是后端服务器的内网 IP，很多根据域名做跳转或生成链接的逻辑就全乱了。
X-Real-IP $remote_addr：后端要拿客户端真实 IP，就靠这个头。
X-Forwarded-For：如果请求经过了多级代理（比如 CDN 再到 Nginx），这个头会把每一级的 IP 都追加进去，后端可以根据它追踪完整链路。
X-Forwarded-Proto $scheme：告诉后端原始请求是 HTTP 还是 HTTPS。后端如果要根据协议来生成安全 Cookie 或做 HTTPS 强制跳转，这个头就很重要。

生产环境往往还要加几个超时和缓冲参数：

nginx复制location / {
    proxy_pass http://backend;
    proxy_connect_timeout 5s;
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
    proxy_buffer_size 4k;
    proxy_buffers 8 4k;
}

proxy_connect_timeout 控制与后端建立连接的超时时间，设太短在高并发时会有大量连接失败，设太长又容易堆积僵死连接。实测下来 5 秒是比较合理的值。proxy_read_timeout 是两次读取操作之间的超时时间，不是说整个请求的耗时上限，这个理解要准确。

5.2 负载均衡 upstream 配置与调度策略

当后端服务有多台时，就需要用 upstream 定义一组后端服务器，让 Nginx 做负载均衡。这是 Nginx 作为接入网关的核心价值。

nginx复制upstream backend_cluster {
    # 默认的轮询策略
    server 192.168.1.11:8080 weight=3;
    server 192.168.1.12:8080 weight=1;
    server 192.168.1.13:8080 backup;
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://backend_cluster;
    }
}

upstream 的调度策略有几种，我按推荐程度排序：

轮询（默认）：每个请求按时间顺序逐一分配给不同的后端。适合所有后端性能相近的场景。
weight 权重：在轮询基础上给每台服务器设置权重。适合不同机器配置高低不一的场景。
ip_hash：根据客户端 IP 计算 hash 值，固定分配到一台后端。适合需要保持 Session 的应用。
least_conn：把请求分给当前连接数最少的后端。适合长连接请求占比高、各后端负载不均衡的场景。

生产环境最常用的组合是轮询加 weight，必要时配合 ip_hash。backup 标记的服务器只在所有非 backup 服务器都不可用时才启用，这是典型的冷备方案。

还有两个容易被忽视的指令：

nginx复制upstream backend_cluster {
    keepalive 32;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

keepalive 32 是设置 Nginx 与后端服务器之间保持的长连接数量。如果没有这个配置，Nginx 每次转发请求给后端都要新建 TCP 连接，请求量一大就建立大量 TIME_WAIT 连接，性能和稳定性都会受影响。加上 keepalive 之后，连接复用率大幅提升，实测高并发场景下性能提升明显。

要注意的是，配合 keepalive 使用 proxy_pass 时，后端地址必须使用 upstream 的名称而不是直接写 IP 加端口，否则 keepalive 不生效。

5.3 HTTPS 配置与证书链补全

HTTPS 在现在已经是标配了。CentOS 7 上配置 HTTPS 主要是两件事：拿到证书、然后正确配置 Nginx。

假设你已经从证书服务商那里拿到了证书文件（通常包括证书文件与私钥文件），Nginx 的配置如下：

nginx复制server {
    listen 443 ssl;
    server_name secure.example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;
}

几个要点展开讲：

ssl_certificate 配置的证书文件必须是完整证书链。所谓完整证书链，就是从你的站点证书开始，到中间证书，再到根证书的完整链条。很多初次配置 HTTPS 的人只上传了站点证书，结果在手机上访问时提示"证书不受信任"。解决方法是把中间证书的内容拼接到站点证书后面，或者直接用证书服务商提供的 fullchain 文件。

ssl_protocols 建议配置为 TLSv1.2 TLSv1.3。TLS 1.0 和 1.1 存在已知漏洞，现在主流浏览器已经默认禁用。如果你的 Nginx 是编译时用的系统自带 OpenSSL 1.0.2k，它不支持 TLS 1.3，那只能写 TLSv1.2。

ssl_session_cache 一定要配。它的作用是缓存会话密钥，让客户端在重新连接时不需要再做完整的 TLS 握手，能显著降低 HTTPS 的响应延迟。shared:SSL:10m 表示在共享内存中划分 10MB 用来缓存会话信息，10MB 大约可以缓存 40000 个会话。

另外建议加上 HTTP 自动跳转 HTTPS 的配置：

nginx复制server {
    listen 80;
    server_name secure.example.com;
    return 301 https://$host$request_uri;
}

这个 301 跳转会丢失 POST 请求的 body，但用来做 HTTPS 强制跳转完全够用。

5.4 静态文件服务与缓存策略优化

Nginx 处理静态文件的性能远优于后端应用服务器（Tomcat、Node.js、Python 应用等），所以资源分离部署是常规做法。

nginx复制server {
    listen 80;
    server_name static.example.com;

    location /static/ {
        alias /data/www/static/;
        expires 7d;
        access_log off;
        add_header Cache-Control "public, max-age=604800";
    }
}

expires 7d 会在响应头里自动加上 Expires 和 Cache-Control，告诉浏览器这个文件 7 天之内都不用重新请求。access_log off 则关闭静态资源的访问日志——这些请求量往往很大，但没多少排查价值，关掉可以节省不少磁盘 IO 和存储。

生产环境我还会额外开启 gzip：

nginx复制gzip on;
gzip_comp_level 5;
gzip_min_length 1k;
gzip_types text/plain text/css application/json application/javascript application/xml image/svg+xml;

gzip_comp_level 5 是性能和压缩率的折中值。1 和 9 我都测过，1 压缩率太低，9 压缩率只比 5 高一点点但 CPU 占用高不少。gzip_min_length 1k 表示小于 1KB 的文件不压缩，因为压缩这类小文件反而会造成额外开销。

6. 常见故障排查与性能调优实录

6.1 启动失败、404 与 403 问题定位

我整理了一份高频问题速查表，把这些年遇到过的、以及被问得最多的问题分门别类列出来。

由 Nginx 进程管理引发的启动失败

这类问题通常伴随以下报错信息：nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)，以及 nginx: [error] open() "/usr/local/nginx/logs/nginx.pid" failed (2: No such file or directory)。

前者说明 80 端口已经被其他进程占用，排查命令是 ss -lntp | grep :80，找到占用进程后处理；后者发生在 Nginx 进程被强制 kill 之后，PID 文件没有正常清理，直接把配置文件里的 pid 路径对应文件删除再启动即可。

由权限问题引发的 403 与 404

403 的场景很典型：配置文件的路径存在，文件也在，但 nginx 用户没有权限读取目录。这种情况在 CentOS 7 上最常见的原因就是目录权限设置不当或 SELinux 拦截。先用 ls -ld /data/www/static 确认目录权限，确保 other 有读和执行权限；如果是生产环境目录按用户隔离，就把目录属主改为 nginx。然后再确认 SELinux 是否拦截。

404 则要区分是磁盘上没文件，还是路径映射错误。重点检查 root 和 alias 的用法是否混淆：root 会把完整 URI 路径拼接到 root 目录后面；alias 则会把匹配的 location 前缀完全替换为 alias 中指定的路径。很多 404 都是 root 和 alias 搞混导致的。

访问日志与错误日志是排错第一手资料来源

遇到问题先看日志，这是我每次都要强调的习惯。访问日志在 /usr/local/nginx/logs/access.log，错误日志在 /usr/local/nginx/logs/error.log。尤其是错误日志，通常会直接告诉你是权限问题、上游连接失败还是配置错误，指向性非常明确。

6.2 502 Bad Gateway 与 504 Gateway Timeout

502 Bad Gateway 和 504 Gateway Timeout 是反向代理场景中最高频的故障，但两者含义不同，排查方向也不同。

502 Bad Gateway：Nginx 作为代理，在向后端服务器转发请求时，收到了无效响应。常见原因有：

后端服务没启动或进程崩了，连接直接被拒绝。
后端服务启动但监听端口不对，从 Nginx 服务器上 curl 127.0.0.1:后端端口 就能测出来。
后端服务性能瓶颈，大量请求堆积，处理不过来直接放弃连接。
fastcgi 场景下，PHP-FPM 进程数耗尽。

排查顺序是：先确认后端进程活着，再确认端口连通性，再看后端服务日志和 Nginx error 日志。

504 Gateway Timeout：Nginx 等待后端响应超时了，触发的是 proxy_read_timeout 设置的时间。常见场景是后端某个接口本身耗时很长（比如导出大批量数据、同步调用外部系统），或者后端整体负载过高导致响应缓慢。

解决思路分两层：一是在配置层面合理调大超时时间；二是在应用层面优化接口耗时，或者把这些慢操作改为异步任务，从 HTTP 层快速返回，后台慢慢执行。我在生产环境经常见到 504 只是因为某个接口需要 70 秒而超时时间设了 60 秒，这种情况直接调大超时时间就行，不要过度设计。

6.3 worker 进程数、连接数与系统参数优化

高并发场景下，即使 Nginx 配置本身没问题，系统层的参数也可能成为瓶颈。

文件描述符限制

每个 TCP 连接都要占用一个文件描述符，系统默认的单进程文件描述符上限通常是 1024，远不够用。需要同时修改系统级和用户级限制：

bash复制echo "fs.file-max = 1000000" >> /etc/sysctl.conf
sysctl -p

echo "* soft nofile 65535" >> /etc/security/limits.conf
echo "* hard nofile 65535" >> /etc/security/limits.conf

再在 nginx.conf 主配置里加上：

nginx复制worker_rlimit_nofile 65535;

TCP 连接优化

在 /etc/sysctl.conf 中添加以下几项，然后执行 sysctl -p 生效：

bash复制net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_keepalive_time = 600

net.ipv4.tcp_tw_reuse 允许复用处于 TIME_WAIT 状态的连接，能减少大量短连接场景下的连接建立时间。tcp_max_syn_backlog 调大后，可以缓解高并发下 TCP 握手队列溢出导致的连接失败问题。

worker 连接数调整

在 events 块中：

nginx复制events {
    worker_connections 65535;
    use epoll;
    multi_accept on;
}

multi_accept on 表示每个 worker 进程一次可接受多个新连接，避免单个连接一来就唤醒进程造成不必要的上下文切换。

6.4 Nginx 安全加固清单

最后分享一份我在生产环境落地的安全基线配置。不追求极端安全，但能规避绝大多数常见风险。

nginx复制# 隐藏版本号
server_tokens off;

# 限制请求体大小，防止超大上传拖垮服务
client_max_body_size 50m;

# 防 SQL 注入/XSS 的基础过滤规则
# 根据业务实际调整，不能盲目照抄
if ($request_uri ~* (select|insert|delete|union|into|load_file|outfile)) {
    return 403;
}

# 禁用不安全的 HTTP 方法
if ($request_method !~ ^(GET|HEAD|POST)$) {
    return 405;
}

# 限制单个 IP 的并发连接数
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;

# 限制单个 IP 的请求速率
limit_req_zone $binary_remote_addr zone=reqs:10m rate=10r/s;
limit_req zone=reqs burst=20 nodelay;

每个配置都有它存在的理由：

server_tokens off 隐藏 Nginx 版本号，防止攻击者根据版本漏洞精准打击。

client_max_body_size 默认值只有 1MB，但生产环境经常需要上传文件，这个值要根据实际业务设置。设太大会被恶意攻击者利用来填满磁盘或耗尽内存，设太小业务又跑不起来，需要明确业务边界再定。

限流配置尤其需要注意 burst 参数。rate=10r/s 表示平均每秒 10 个请求，burst=20 表示允许瞬间最多堆积 20 个请求的缓冲区。带 nodelay 时，缓冲区内请求会一次性处理完而不是排着队慢慢来，这会牺牲一些平滑性但能显著降低用户感知的延迟。

安全配置强调一点：安全规则必须跟业务匹配。如果有人不需要登录就能访问某个导出接口，限流规则就必须在这个接口上加强而不是只写在总入口。直接抄网上那些封禁 SQL 关键字的大段 if 规则，反而容易误伤正常业务请求，需要非常谨慎。

7. 后记：把手册落进日常工作的建议

这份手册从环境准备写到编译安装，从配置文件拆解到高频故障排查，基本覆盖了 Nginx 在 CentOS 7 上从零到生产可用的完整链条。

最后再分享几点我个人的体会，供参考。

第一，不要迷信某个版本的默认配置。Nginx 的默认配置只是一个能工作的起跑线，真正决定系统运行质量的是那些针对你业务场景的调优和取舍。每做一个调整，都要记录当时的背景和预期效果，别只顾着执行命令。

第二，强烈建议把配置纳入版本控制。Nginx 配置就是基础设施的代码，用 Git 管理起来，每次变更留下记录，出问题才能快速回滚和对比。我在实际工作中曾因为一条配置的前后差异排查了一个多小时，靠的就是 Git 历史定位到问题。

第三，把本地的运维脚本和调试命令积累成语录式文档或自动化脚本。比如一键执行 nginx -t、查看模块列表、检查 upstream 健康状态等操作，写进脚本后能节省大量重复劳动。时间花的值得。

根据我这些年的操作经验，Nginx 在 CentOS 7 上的稳定程度其实相当高，真正出问题的场景，十个里有八个是配置理解不到位，一个是系统环境冲突，还有一个是容量规划没跟上。只要把这份手册里提到的基础打牢，把排查思路理顺，你手里的服务器就能稳很长一段时间。

CentOS 7下Nginx编译安装与生产实战手册