做技术这一行，很多人学完 Nginx 的基础安装和反向代理之后，很容易陷入一个瓶颈：单个服务能跑，但一碰到 "LNMP 环境搭建"、"动静分离" 这些工程化概念，就感觉文档里讲的都对，自己上手却哪里都不对劲。这篇是 Nginx 系列实战的第三篇，我抛开那些只讲命令不讲原理的教程，就着我自己从零搭 LNMP 的完整过程，把架构设计、组件安装、动静分离这几个核心环节拆开揉碎，同步把踩过的坑也一并记录下来。这套方案适合刚入门的运维、写后端但不太碰服务器的开发，以及想搞明白 "动态请求和静态请求到底是怎么分开处理" 的同学。一篇下来，你能获得一套可直接复制的配置，更能理解每一步背后的取舍逻辑。
1. LNMP 架构设计与方案选型
1.1 为什么选择 LNMP 而不是 LAMP
很多人在选择 Web 服务架构时，会在 LNMP（Linux + Nginx + MySQL + PHP）和 LAMP（Linux + Apache + MySQL + PHP）之间纠结。我的结论很直接：除非项目强制要求 Apache 的特性，否则新项目直接上 LNMP 没有悬念。
关键差异在两处。第一处是 Web 服务器的并发模型：Apache 擅长的是进程/线程模型，每个连接占用一个进程或线程，连接多了内存和上下文切换开销非常明显；Nginx 则是事件驱动模型，一个 master 进程加若干 worker 进程，每个 worker 基于 epoll 同时管理成千上万的连接。打个比方，Apache 像是开了一堆窗口，每个顾客单独一个窗口排队，而 Nginx 像一个只有一个取号机的大厅，所有顾客取号后坐着等叫号，窗口少了，服务的人却更多了。
第二处是对 PHP 的处理方式。Apache 作为 Web 服务器可以直接通过 mod_php 将 PHP 解释器加载进自身进程，这看起来省事，但 PHP 模块一旦崩溃，整个 Apache 进程也受影响。LNMP 中 Nginx 本身根本不处理 PHP 程序，而是把动态请求通过 FastCGI 协议转交给独立的 PHP-FPM 进程池处理，两者互相隔离，Web 服务器和动态语言解释器可以各自独立扩展，一方压力大不会拖垮另一方。动静分离能够成立的底层前提，就是这个架构本身就是 "分流" 设计。
1.2 各组件版本选型与安装方式权衡
实际操作时，第一步不是敲命令，而是把组件版本定下来。版本定不好，后面编译失败、模块缺失、兼容性报错会让人怀疑人生。我这次以一套通用组合为例：Nginx 1.24.0、PHP 8.2、MySQL 8.0，操作系统使用 CentOS 7.9（这个组合在存量生产环境中依然常见，如果你用 Rocky Linux、Ubuntu 22.04 或者麒麟，思路完全一致，只是包管理命令有差异）。
组件选型上我有一个很实际的建议表：
| 组件 | 推荐版本 | 核心考量 |
|---|---|---|
| Nginx | 1.24.x 稳定版 | 主线版本功能新，但稳定版更安全；不要用太老的 1.14/1.16 |
| PHP | 8.2 或 8.3 | PHP 8 系列性能比 7.4 提升明显，JIT 特性在计算型业务里收益可观 |
| MySQL | 8.0 | 5.7 已经停止维护，别再用旧版本给生产环境埋雷 |
| Linux | CentOS 7.9 / Rocky 9 | 对应自己熟悉的发行版，不要为了追新随便换 |
安装方式上，Nginx 和 PHP 我坚持源码编译。原因很实际：生产环境往往需要定制编译参数（比如加特定模块、改安装路径），yum 安装虽然快，但二进制包受发行版维护者的决定限制，有些模块默认没编译进去，后期想加就得重新换包，非常被动。MySQL 则更推荐用官方 Yum 仓库安装，因为 MySQL 源码编译耗时太久且对新版本 GCC 的兼容性要求高，自己编译的收益远低于风险。如果你在无外网环境，需要准备本地 Yum 源或 RPM 依赖包，这个我后面实操部分会专门提到。
1.3 动静分离的原理与核心收益
动静分离说白了就一句话：把用户请求中的静态资源（图片、JS、CSS、字体等）和动态接口（PHP、Java、Python 程序生成的响应）分开处理。静态请求由 Nginx 直接读取磁盘或内存缓存返回，动态请求才转发给 PHP-FPM 或后端应用服务。
这套架构的收益非常直接。第一，PHP-FPM 的进程是宝贵资源，每个进程在处理请求期间占用的内存通常在 30-50MB 左右，并发一大很容易打满。如果 1000 个请求里有 800 个是图片和 JS，在动静不分离的架构下这 800 个请求也会白白占用 PHP 进程，分离之后 PHP 只需要处理剩余 200 个动态请求，同样配置下吞吐量差距是倍数级的。第二，Nginx 处理静态文件的能力极强，配合sendfile、gzip、expires缓存策略，静态资源的响应速度和带宽利用率都能明显改善。网站在加载首页时，几十个静态文件能在一瞬间并发返回，这种体验提升用户是直接能感知到的。
理解原理是配置的前提。接下来我就从零开始搭建这套环境。
2. 基础环境与核心组件安装
2.1 系统准备与编译依赖补齐
动手编译前，先把系统基础环境收拾干净。如果你是 CentOS 系，第一步建议先做一次系统更新并将 SELinux 设置成 permissive 或 disabled，否则编译出来的 Nginx 在访问文件时可能被 SELinux 策略拦住，报各种奇怪的 403 和权限错误，排查起来最浪费时间。另外防火墙我这里选择临时关闭或者显式放行 80/443 端口，你按自己安全策略决定，但至少别让防火墙成为第一道 "隐形墙"。
接下来安装编译工具链和依赖库。Nginx 源码编译依赖这几个关键库：pcre-devel（支持正则表达式，重写模块rewrite必需）、zlib-devel（支持 gzip 压缩响应）、openssl-devel（支持 HTTPS 和 TLS 协议）。这些库没装全，编译时才会报错，配置阶段可能毫无提示，所以一定要提前统一装上：
yum install -y epel-release yum groupinstall -y "Development Tools" yum install -y gcc gcc-c++ make pcre-devel zlib-devel openssl-develPHP 编译需要的依赖更多一点，主要涉及 libxml2-devel（XML 解析）、libcurl-devel（cURL 扩展）、libpng/libjpeg 相关库（GD 图像扩展）。我建议在 PHP configure 之前也把这些基础库一次性装齐，避免编译过程中反复补包。这也算是我个人经验里最反常识的一步：很多人以为configure阶段只检查软件版本，实际上它检查的就是这些隐藏的依赖库，缺失一个就报一个错，补一个又冒出来一个，全程焦躁。
2.2 编译安装 Nginx 并注册为系统服务
依赖装好后，下载 Nginx 源码包并解压：
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.0Nginx 的configure参数决定编译出来的二进制包含哪些模块，这个阶段要深思熟虑。我常用的最小完整参数如下：
./configure \ --prefix=/usr/local/nginx \ --user=nginx \ --group=nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_gzip_static_module \ --with-http_stub_status_module \ --with-stream \ --with-stream_ssl_module每个参数都有用途：--with-http_ssl_module和--with-http_v2_module让你后续能直接支持 HTTPS 和 HTTP/2，没有这几个模块后面想做安全访问就要重新编译；--with-stream是四层负载均衡模块，做 TCP/UDP 转发时用得上；--with-http_stub_status_module可以输出 Nginx 运行状态信息，监控排查时很关键。很多教程省略这些解释，导致读者照抄完不知道自己装了什么，出了问题也没有排查抓手。
编译安装并添加 nginx 用户：
make && make install useradd -s /sbin/nologin nginx /usr/local/nginx/sbin/nginx -tnginx -t输出syntax is ok说明配置没问题。接着把 Nginx 注册成 systemd 服务，这样能设置开机启动，也能通过systemctl start/stop/reload管理。在/etc/systemd/system/nginx.service写入：
[Unit] Description=nginx - high performance web server After=network.target [Service] Type=forking PIDFile=/usr/local/nginx/logs/nginx.pid ExecStart=/usr/local/nginx/sbin/nginx ExecReload=/usr/local/nginx/sbin/nginx -s reload ExecStop=/usr/local/nginx/sbin/nginx -s stop PrivateTmp=true [Install] WantedBy=multi-user.target然后执行systemctl daemon-reload && systemctl enable --now nginx，用curl -I http://localhost看到 HTTP 200 就说明 Nginx 已经正常服役了。这步做完，Web 服务器这层就绪。
2.3 安装 MySQL 8.0 并完成初始化
MySQL 我使用官方 Yum 仓库安装，比源码编译省心太多。先添加官方仓库，再安装：
yum localinstall -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm yum install -y mysql-community-server systemctl enable --now mysqld安装完成后，MySQL 8.0 会在日志中生成一个临时 root 密码，需要查出来再登录修改：
grep 'temporary password' /var/log/mysqld.log mysql -uroot -p ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourStrongPass@2025';MySQL 8.0 默认安装了validate_password组件，密码必须有大小写字母、数字和特殊字符，否则会直接拒绝修改。很多人卡在这一步，以为是自己命令写错了，其实是密码策略在把关。如果你确实想降低强度，可以用SET GLOBAL validate_password.policy = LOW;调整，但在生产环境我强烈不建议这么做。
之后创建一个给 PHP 程序使用的数据库账号：
CREATE DATABASE IF NOT EXISTS myapp DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'webuser'@'localhost' IDENTIFIED BY 'WebPass@2025'; GRANT ALL PRIVILEGES ON myapp.* TO 'webuser'@'localhost'; FLUSH PRIVILEGES;注意 MySQL 8.0 的授权语法和旧版没区别，但如果你需要远程主机访问，用户地址要写成'webuser'@'%'，同时确认防火墙放行 3306 端口。另外强调一个我非常看重的点：数据库账号权限必须遵循最小化原则，程序只需要操作自己的库，就不要给它ALL PRIVILEGES ON *.*。
2.4 编译安装 PHP 与 PHP-FPM
PHP 是 LNMP 里安装最需要耐心的一环，因为 configure 参数又多又长，但每一个参数都对应一种能力。先下载解压：
cd /usr/local/src wget https://www.php.net/distributions/php-8.2.14.tar.gz tar -zxvf php-8.2.14.tar.gz cd php-8.2.14这次 PHP 的角色是处理动态请求，所以最核心的参数是--enable-fpm（启用 PHP-FPM 进程管理器）、--with-pdo-mysql（PDO 连 MySQL）、--with-mysqli（mysqli 扩展），另外根据项目需要选择 SSL、cURL、GD 等：
./configure \ --prefix=/usr/local/php \ --with-config-file-path=/usr/local/php/etc \ --enable-fpm \ --with-fpm-user=nginx \ --with-fpm-group=nginx \ --with-pdo-mysql \ --with-mysqli \ --with-openssl \ --with-curl \ --with-gd \ --with-zlib \ --enable-mbstring \ --enable-xml \ --enable-sockets \ --enable-opcache编译过程时间比较长，使用多核编译能节省不少时间：
make -j$(nproc) && make install安装完成后复制默认配置文件，并修改 PHP-FPM 监听方式。www.conf里最关键的参数是listen和user，默认配置经常保持listen = 127.0.0.1:9000，这个可以正常工作；如果追求更高性能，可以改成 Unix Socket 方式listen = /run/php-fpm/www.sock，后面 Nginx 配置时fastcgi_pass也要同步改成 socket 路径。我这次先用 TCP 9000 端口，逻辑更直观，后面调优部分再对比两者差异。
cp php.ini-production /usr/local/php/etc/php.ini cp /usr/local/php/etc/php-fpm.conf.default /usr/local/php/etc/php-fpm.conf cp /usr/local/php/etc/php-fpm.d/www.conf.default /usr/local/php/etc/php-fpm.d/www.conf /usr/local/php/sbin/php-fpm用ps aux | grep php-fpm看到 master 和多个 worker 进程，说明 PHP-FPM 已经起来了。
3. Nginx 核心配置与动静分离实现
3.1 fastcgi 协议的桥梁作用
动静分离的核心配置在 Nginx 的 server 和 location 块里，但要先理解 Nginx 是怎么跟 PHP-FPM 通信的。用户请求到达 Nginx 以后，如果被判定为动态请求，Nginx 会将 HTTP 请求转换成 FastCGI 协议格式，再通过本地 TCP 或 Unix Socket 转发给 PHP-FPM。PHP-FPM 处理完把结果按协议返回，Nginx 拿到结果再组装成 HTTP 响应回给客户端。这个协议转换的工作，体现在配置里就是fastcgi_pass及其附带的一堆fastcgi_param。
一个标准的动态请求 location 配置长得像这样：
location ~ \.php$ { root /data/www/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }第一坑就在SCRIPT_FILENAME。如果配置错误，Nginx 传给 PHP-FPM 的是一个不存在的文件路径，PHP-FPM 会返回 "No input file specified"，页面直接空白。正确值一般是$document_root$fastcgi_script_name，前提是 root 路径要写准确。第二坑是include fastcgi_params不能漏，这个文件里定义了大量 CGI 环境变量（REQUEST_METHOD、QUERY_STRING、REMOTE_ADDR等），少了它 PHP 里的$_SERVER信息会大量缺失，程序可能出现诡异逻辑。
3.2 静态资源直接服务配置
动静分离的第一层配置，是把静态文件从动态请求里摘出来。我在 server 块里添加一个专门处理静态资源的 location：
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?|ttf|eot|mp4|webm)$ { root /data/www/html; expires 30d; add_header Cache-Control "public, no-transform"; access_log off; try_files $uri $uri/ =404; }这个配置做了几件事：root指定静态文件所在目录；expires 30d告诉浏览器这个资源 30 天之内可以直接用本地缓存，不用再发请求；access_log off则是避免静态资源请求刷爆日志文件。这里有个容易搞混的点：root和alias的区别。root会将完整的 URL 路径映射到文件系统，而alias是将 URL 中的某段路径替换成指定目录。比如location /static/下root /data/www/html，请求/static/a.jpg对应文件是/data/www/html/static/a.jpg；如果用alias /data/www/，对应文件是/data/www/a.jpg。这个区别极容易导致图片 404，写配置前想清楚。
除此之外还可以开启 gzip 压缩。文本类静态资源（JS、CSS）经 gzip 后体积能缩小 60% 以上，图片本身已经是压缩格式就不需要再压。开启方式是在 http 块设置：
gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml; gzip_min_length 1024; gzip_vary on;静态资源层配置好后，基本能达到 "浏览器缓存 + 不占用 PHP 进程 + 文本类压缩传输" 三管齐下的效果。
3.3 动态请求转发与 location 匹配优先级
静态资源摘出来后，剩下所有请求默认走动态处理。最基础的配置是：
location / { root /data/www/html; index index.php index.html; } location ~ \.php$ { root /data/www/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }不过实际项目里，很多 PHP 框架（比如 Laravel、ThinkPHP、若依等）为了 URL 美观，所有动态请求都指向单一的入口文件index.php，路径里根本没有.php后缀。这种场景下，需要把动态 location 改成更通用的 try_files 规则：
location / { root /data/www/html; index index.php; try_files $uri $uri/ /index.php?$query_string; }try_files的意思是：先尝试按请求的 URI 直接找文件，找不到就尝试目录，再找不到就重写到/index.php并把原始参数带上。这样框架路由就能接管所有请求。关于 location 的匹配优先级，我在实际配置中发现这是新手最容易懵的地方。优先级从高到低依次是：精确匹配=> 前缀匹配且停止搜索^~> 正则匹配~或~*（按照配置文件顺序） > 普通前缀匹配/xxx/> 默认location /。举个例子，请求/dynamic.php，如果同时存在location = /dynamic.php、location ^~ /static/、location ~ \.php$、location /，最终生效的是location ~ \.php$，因为正则匹配排在普通前缀前面。理解这个顺序，才不会出现 "明明配置了动态规则却不生效" 的情况。
3.4 一台机器部署多个站点时的 server 块隔离
搜 Nginx 相关关键词时，很多人问 "Nginx 部署多个 web 项目" 怎么处理。这个用 LNMP 架构反而简单：每个项目一个 server 块，用server_name（域名）或 listen 端口区分。动静分离规则可以提炼成公共配置，用include或直接在各自 server 块里复用。
我举一个实际场景：同一个 Nginx 上部署一个 Vue3 前端项目和一个 PHP 后端接口项目。
- 前端项目监听 80 端口，
server_name vue.example.com，root 指向 Vue 构建产物 dist 目录，因为 Vue 的 history 路由需要把所有找不到的路径都重写到 index.html，否则刷新页面就 404：
server { listen 80; server_name vue.example.com; root /data/www/vue-dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; } }- PHP 后端项目监听 8080 端口，
server_name api.example.com，按前面的动态请求规则配置 PHP-FPM：
server { listen 8080; server_name api.example.com; root /data/www/php-app; index index.php; location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }上面还用到了反向代理：前端的/api/请求被 Nginx 转发到 PHP 后端 8080 端口。动静分离和反向代理在真实工程里经常是配合使用的关系。这条链路里，Nginx 是入口网关，既负责静态资源直出，又负责动态请求的调度，整个架构一眼望过去非常清晰。
4. 部署验证与性能实测
4.1 从静态页到动态接口的全链路验证
配置写好了，不能光看nginx -t通过就以为万事大吉。我习惯按层级做一次全链路验证。第一步验证静态资源，在/data/www/html下新建一个index.html，用浏览器访问http://服务器IP/，能看到页面就说明 Nginx 静态服务正常，同时验证一下静态图片能否正常加载、gzip 是否生效（响应头里应该出现Content-Encoding: gzip）。
第二步验证 PHP 解析，新建一个test.php：
<?php phpinfo();浏览器访问http://服务器IP/test.php，能输出 PHP 信息页面，说明 Nginx 到 PHP-FPM 的 fastcgi 通路已经打通。这里有个常用排查指令来确认 fastcgi_pass 到底通不通：
cgi-fcgi -bind -connect 127.0.0.1:9000如果系统没有 cgi-fcgi，也可以用telnet 127.0.0.1 9000或ss -lntp | grep 9000确认端口在监听。
第三步验证数据库链路，在 PHP 页面里写入一段连接 MySQL 的代码：
<?php $pdo = new PDO('mysql:host=127.0.0.1;dbname=myapp;charset=utf8mb4', 'webuser', 'WebPass@2025'); $stmt = $pdo->query('SELECT VERSION()'); var_dump($stmt->fetchColumn());看到输出版本号 8.0.x，说明 PHP 和 MySQL 之间也通了。这套流程从静态层、动态层到数据层逐级打通，后面出现任何问题都能快速定位到具体层级，而不是在三个组件之间瞎猜。
4.2 动静分离前后对比实测
配置和功能都正常后，我习惯用简单的压测工具验证动静分离的实际收益。这里用 apache bench（ab），没有的话先安装yum install -y httpd-tools。测试思路是对比同一台机器在分离前后，处理纯静态请求和动态请求的吞吐差异。
# 压测静态文件：一张 100KB 的图片 ab -n 5000 -c 200 http://localhost/static/demo.jpg # 压测动态接口：一个输出 JSON 的 PHP 页面 ab -n 5000 -c 200 http://localhost/api/index.php需要说明的是，ab 在本机压本机，数据仅供参考，但相对趋势非常有说服力。实测下来，静态文件请求的 QPS 通常能达到动态请求的 3-5 倍以上，而且静态请求完全不消耗 PHP-FPM 的 worker 进程。你在后续观察ps aux | grep php-fpm的 CPU 占用时会发现，压测静态资源时 PHP 进程几乎不动，这就是动静分离最直接的证明。
测完之后我还要特别提醒一句：压测并发数不要一上来就拉到 5000、10000，本机资源和 Nginx 连接数是有上限的，压测失败不代表应用有问题，可能是测试工具本身把环境打挂了。建议从-c 50起步逐步加，观察 Nginx 错误日志和系统负载。
4.3 PHP-FPM 与 Nginx 的常见调优参数
动静分离分走了大部分压力，真正到 PHP-FPM 的请求量级会合理很多。但下面的调优参数仍然必要，尤其是高峰期接口处理不过来时，优化的优先级很高。
PHP-FPM 的www.conf中核心参数如下：
| 参数 | 默认值 | 建议调整 | 说明 |
|---|---|---|---|
| pm | dynamic | dynamic | 进程管理方式，建议保持动态调整 |
| pm.max_children | 5 | 按内存计算 | 最大 worker 数：内存 / 单进程占用 |
| pm.start_servers | 2 | 根据启动速度调整 | 启动时创建的 worker 数 |
| pm.min_spare_servers | 1 | 根据波动调整 | 空闲 worker 下限 |
| pm.max_spare_servers | 3 | 根据波动调整 | 空闲 worker 上限 |
| request_terminate_timeout | 0 | 30-60s | 单个请求最大执行时间，防止死循环占死进程 |
pm.max_children的计算逻辑我举个例子：假如服务器内存 8GB，系统其他服务占 3GB，PHP 每个进程平均占用 40MB，那么max_children可以设置为(8-3) * 1024 / 40 ≈ 128。当然这只是理论值，还要结合业务实际压力观察调整。最忌讳的是不测算直接把max_children改成 500，结果内存被打满，Swap 一开，整体性能直线下降。
Nginx 侧的调优相对简单：
worker_processes auto; worker_connections 1024; keepalive_timeout 65; sendfile on; tcp_nopush on;worker_processes auto让 Nginx 按 CPU 核心数自动创建 worker，这是性价比最高的配置。worker_connections表示每个 worker 能同时打开的连接数，默认 1024 够用，如果并发量高可以调到 2048 或 4096，但注意它受系统文件描述符限制，需要同步调整ulimit -n。
5. 常见问题排查与避坑指南
5.1 502 Bad Gateway 的排查思路
502 是 LNMP 里最经典的报错，Nginx 拿到了错误响应也就是 PHP-FPM 不可用的信号。碰到 502 我有一套固定排查顺序，按这个顺序基本十分钟内能定位。
先看 PHP-FPM 进程在不在：
ps aux | grep php-fpm ss -lntp | grep 9000如果进程不在或端口没监听，大概率是 PHP-FPM 没启动或启动后崩溃。启动后要立刻看日志，日志位置默认在/usr/local/php/var/log/php-fpm.log，这里经常记录真正的原因，比如配置错误、端口被占用、listen.allowed_clients限制等。最常见的一个隐藏坑是www.conf里的listen.allowed_clients，有些人为了安全指定成 127.0.0.1，结果fastcgi_pass写的是本机内网 IP，请求就被拒绝了，改成 127.0.0.1 就好。第二个常见原因是运行用户权限问题：PHP-FPM 以 nginx 用户运行，但 web 目录如果属于 root，且权限是 755，nginx 用户可能读不到文件，也会导致 502。第三个是 fastcgi 超时：如果 PHP 脚本执行时间较长，而fastcgi_read_timeout设置太短，Nginx 会主动断开连接返回 504 或 502。我给接口类站点设置的默认值是 60s：
location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_read_timeout 60; fastcgi_connect_timeout 5; fastcgi_send_timeout 60; ... }5.2 静态资源 404 与 403 的常见原因
静态资源 404 和 403 在动静分离配置中也很常见，而且绝大多数不是 Nginx 配置语法错误，而是路径和权限问题。
404 的头号原因是root和alias搞混。前面已经详细说过，这里再强调一遍：root是拼接路径，alias是替换路径。我见过太多人把资源文件放在/data/www/html/imgs/，却在location /imgs/底下写root /data/www/，导致实际找的是/data/www/imgs/imgs/xxx.jpg，当然 404。404 的第二个常见原因是try_files写错，比如静态资源 location 里没有加try_files $uri =404，某些情况下 Nginx 会尝试找 index 文件然后返回 403。
403 基本都是运行用户对文件没有读权限。用ls -l检查文件属主，确认 nginx 用户或 group 对资源目录有r-x权限。常见解法是chown -R nginx:nginx /data/www/html，或者chmod -R 755。特别提醒一句：Too many open files错误虽然不太常见，但静态资源特别多的时候，Nginx worker 的文件描述符上限可能被耗尽，也要同步调高 ulimit。
5.3 上传、超时与日志相关的隐藏坑
生产环境里还有三个高频问题值得单独提。第一个是上传大文件返回 413 Request Entity Too Large，原因是 Nginx 默认client_max_body_size为 1MB。修改方式是在 http、server 或 location 块中加入：
client_max_body_size 50m;第二个是 PHP 上传限制，还包括upload_max_filesize和post_max_size参数，如果只改 Nginx 不改 PHP，上传超过 2MB 依然会失败，两边要配合调整。
第三个是日志相关。Nginx 的访问日志和错误日志路径默认在安装目录的logs/下，分别是access.log和error.log。日志文件长期不清理会无限增长，我一般用 logrotate 配置按天切割并保留 30 天。另外，每次线上变更后，不要只看业务是否正常，tail -f /usr/local/nginx/logs/error.log能帮你发现隐藏告警，这才是长期稳定的保障。
5.4 高频问题速查表
| 错误现象 | 可能原因 | 解决方向 |
|---|---|---|
| 502 Bad Gateway | PHP-FPM 未启动、端口或 socket 错误、运行用户权限不足 | 检查进程、端口、日志，确认 fastcgi_pass 与监听地址一致 |
| 504 Gateway Timeout | 后端响应超时 | 调大 fastcgi_read_timeout / proxy_read_timeout |
| 404 静态资源 | root 与 alias 混淆、路径层级错误 | 确认文件实际路径，重新设计 root/alias |
| 413 Request Entity Too Large | client_max_body_size 过小 | 调大 client_max_body_size |
| No input file specified | SCRIPT_FILENAME 配置错误 | 确认 fastcgi_param 中 root 路径与请求 URI 拼接正确 |
| 页面空白 200 但无内容 | PHP 短标签未开启、opcache 缓存异常 | 检查 php.ini 的 short_open_tag，必要时 reload php-fpm |
| 上游返回真实 IP 不对 | Nginx 代理后五元组改变 | 需要配置 X-Forwarded-For 或 proxy_protocol 来传递真实客户端 IP |
最后一个关于 "ip 头部的五元组信息 nginx 转发会带吗" 的问题，我直接给结论：Nginx 反向代理后，后端服务看到的 TCP 层五元组是 Nginx 发起的连接，不再是客户端的原始五元组。如果业务需要真实客户端 IP，标准的做法是 Nginx 在转发时通过X-Forwarded-For、X-Real-IP等 Header 显式传递，或者使用 proxy_protocol 协议在 TCP 层透传原始连接信息。
5.5 关于 nginx 命令找不到与离线安装
最后补充两个出现在很多搜索场景里的实际问题。一是 "nginx: 未找到命令"，这种情况通常是安装路径不在 PATH 环境变量里，源码编译默认装在/usr/local/nginx/sbin/nginx，要么用全路径执行，要么做软链接：
ln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx二是离线环境安装。我看很多人在搜 "centos8 离线安装 nginx 下载依赖包"，实际流程是：在一台联网的同版本机器上，用yumdownloader --resolve下载所有依赖性 RPM 包，然后拷贝到离线机器执行yum localinstall *.rpm，这样即可避开 "无法解析域名" 的问题。Nginx 本体则可以提前下载好源码包，编译依赖的 pcre、zlib、openssl 也一并准备好，离线环境下照样能完成编译安装。
整套 LNMP 搭建和动静分离配置走到这里，一个能处理静态资源、能解析 PHP 动态脚本、能连接 MySQL 的完整 Web 服务链路就已经跑通了。我在实际部署中最深的体会是，Nginx 的配置语法并不难，难的是脑子里要有一张清晰的请求流转图：请求进来先经过 server 匹配，再经过 location 匹配，静态资源由 Nginx 直接处理，动态请求进入 fastcgi 通道转给 PHP-FPM，PHP 再去访问数据库。把这条链路想明白，遇到任何报错都能顺着链路逐层排查，而不是在论坛上像无头苍蝇一样搜错误码。这套环境搭完之后，后续你还可以继续扩展：给 server 块加上 HTTPS 证书、把前端静态资源同步到对象存储和 CDN、在多台服务器之间做负载均衡、甚至把 Nginx 放进 Docker 容器用编排工具管理。但万变不离其宗，Nginx 作为入口网关的定位、动静分离的流量调度思想，在这套基础环境里已经全部体现出来了。
