做技术这一行很多人学完 Nginx 的基础安装和反向代理之后很容易陷入一个瓶颈单个服务能跑但一碰到 LNMP 环境搭建、动静分离 这些工程化概念就感觉文档里讲的都对自己上手却哪里都不对劲。这篇是 Nginx 系列实战的第三篇我抛开那些只讲命令不讲原理的教程就着我自己从零搭 LNMP 的完整过程把架构设计、组件安装、动静分离这几个核心环节拆开揉碎同步把踩过的坑也一并记录下来。这套方案适合刚入门的运维、写后端但不太碰服务器的开发以及想搞明白 动态请求和静态请求到底是怎么分开处理 的同学。一篇下来你能获得一套可直接复制的配置更能理解每一步背后的取舍逻辑。1. LNMP 架构设计与方案选型1.1 为什么选择 LNMP 而不是 LAMP很多人在选择 Web 服务架构时会在 LNMPLinux Nginx MySQL PHP和 LAMPLinux 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 或者麒麟思路完全一致只是包管理命令有差异。组件选型上我有一个很实际的建议表组件推荐版本核心考量Nginx1.24.x 稳定版主线版本功能新但稳定版更安全不要用太老的 1.14/1.16PHP8.2 或 8.3PHP 8 系列性能比 7.4 提升明显JIT 特性在计算型业务里收益可观MySQL8.05.7 已经停止维护别再用旧版本给生产环境埋雷LinuxCentOS 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-develXML 解析、libcurl-develcURL 扩展、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 \ --usernginx \ --groupnginx \ --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] Descriptionnginx - high performance web server Afternetwork.target [Service] Typeforking 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 PrivateTmptrue [Install] WantedBymulti-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 rootlocalhost IDENTIFIED BY YourStrongPass2025;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 webuserlocalhost IDENTIFIED BY WebPass2025; GRANT ALL PRIVILEGES ON myapp.* TO webuserlocalhost; FLUSH PRIVILEGES;注意 MySQL 8.0 的授权语法和旧版没区别但如果你需要远程主机访问用户地址要写成webuser%同时确认防火墙放行 3306 端口。另外强调一个我非常看重的点数据库账号权限必须遵循最小化原则程序只需要操作自己的库就不要给它ALL PRIVILEGES ON *.*。2.4 编译安装 PHP 与 PHP-FPMPHP 是 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-mysqlPDO 连 MySQL、--with-mysqlimysqli 扩展另外根据项目需要选择 SSL、cURL、GD 等./configure \ --prefix/usr/local/php \ --with-config-file-path/usr/local/php/etc \ --enable-fpm \ --with-fpm-usernginx \ --with-fpm-groupnginx \ --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 块里添加一个专门处理静态资源的 locationlocation ~* \.(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/xmlrss text/javascript image/svgxml; 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.comroot 指向 Vue 构建产物 dist 目录因为 Vue 的 history 路由需要把所有找不到的路径都重写到 index.html否则刷新页面就 404server { 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-FPMserver { 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:host127.0.0.1;dbnamemyapp;charsetutf8mb4, webuser, WebPass2025); $stmt $pdo-query(SELECT VERSION()); var_dump($stmt-fetchColumn());看到输出版本号 8.0.x说明 PHP 和 MySQL 之间也通了。这套流程从静态层、动态层到数据层逐级打通后面出现任何问题都能快速定位到具体层级而不是在三个组件之间瞎猜。4.2 动静分离前后对比实测配置和功能都正常后我习惯用简单的压测工具验证动静分离的实际收益。这里用 apache benchab没有的话先安装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中核心参数如下参数默认值建议调整说明pmdynamicdynamic进程管理方式建议保持动态调整pm.max_children5按内存计算最大 worker 数内存 / 单进程占用pm.start_servers2根据启动速度调整启动时创建的 worker 数pm.min_spare_servers1根据波动调整空闲 worker 下限pm.max_spare_servers3根据波动调整空闲 worker 上限request_terminate_timeout030-60s单个请求最大执行时间防止死循环占死进程pm.max_children的计算逻辑我举个例子假如服务器内存 8GB系统其他服务占 3GBPHP 每个进程平均占用 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且权限是 755nginx 用户可能读不到文件也会导致 502。第三个是 fastcgi 超时如果 PHP 脚本执行时间较长而fastcgi_read_timeout设置太短Nginx 会主动断开连接返回 504 或 502。我给接口类站点设置的默认值是 60slocation ~ \.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 GatewayPHP-FPM 未启动、端口或 socket 错误、运行用户权限不足检查进程、端口、日志确认 fastcgi_pass 与监听地址一致504 Gateway Timeout后端响应超时调大 fastcgi_read_timeout / proxy_read_timeout404 静态资源root 与 alias 混淆、路径层级错误确认文件实际路径重新设计 root/alias413 Request Entity Too Largeclient_max_body_size 过小调大 client_max_body_sizeNo input file specifiedSCRIPT_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-FPMPHP 再去访问数据库。把这条链路想明白遇到任何报错都能顺着链路逐层排查而不是在论坛上像无头苍蝇一样搜错误码。这套环境搭完之后后续你还可以继续扩展给 server 块加上 HTTPS 证书、把前端静态资源同步到对象存储和 CDN、在多台服务器之间做负载均衡、甚至把 Nginx 放进 Docker 容器用编排工具管理。但万变不离其宗Nginx 作为入口网关的定位、动静分离的流量调度思想在这套基础环境里已经全部体现出来了。