作为Nginx系列文章的第三篇这篇我打算把LNMP从零到能跑完整拆一遍。前两篇聊过Nginx的基础配置和虚拟主机玩法但很多朋友在真正部署PHP项目时还是卡壳要么是PHP-FPM与Nginx对接不上返回502要么是静态图片和JS请求全部打到动态解析上服务器CPU直接飘高。这些问题归根结底其实就两件事没想明白——LNMP各组件之间到底怎么协作以及动静分离究竟在分什么。这篇文章会以一套生产可用的LNMP环境为例从组件选型、安装配置、站点搭建到动静分离规则逐一讲解。文中的所有配置我都实际跑过适合已经熟悉Nginx基本指令、准备部署PHP站点的读者也适合那些照抄过网上配置但不知道为什么要这么写的朋友。看完之后你能独立完成一套LNMP环境搭建并搞清楚Nginx、PHP-FPM、MySQL三者之间的请求流转逻辑。1. LNMP的整体架构设计与选型思路1.1 为什么是LNMP而不是LAMPLNMP指的是Linux、Nginx、MySQL、PHP这套组合和传统的LAMPApache替代Nginx相比最大的区别在PHP的执行方式上。Apache时代最常见的PHP运行方式是mod_php直接把PHP解释器以模块形式嵌入Apache进程内部。这种方式的好处是配置简单但缺点也很明显Apache进程为了处理一个PHP请求必须常驻一个完整的PHP解释器内存占用高并发一上来就容易把机器拖垮。Nginx天生是事件驱动的异步架构处理静态文件和反向代理非常高效但它自己并不直接执行PHP代码。Nginx遇到PHP请求时会把请求通过FastCGI协议转交给PHP-FPM进程管理器由PHP-FPM启动PHP子进程来执行脚本再把结果返回给Nginx。这个模型下Nginx只负责流量分发和静态资源响应PHP-FPM按需启动固定数量的子进程资源利用率比mod_php高得多。另一个现实原因是动静分离的天然契合。Nginx对静态文件的处理效率极高而PHP-FPM专注于动态脚本两者各司其职。你在Nginx里通过不同location规则把静态请求和动态请求分流这就是动静分离的核心思想。后面我会专门讲配置实现这里先建立这个整体认知。1.2 组件版本选择的几个关键考虑组件版本选择直接影响后续维护成本我的建议是“能用系统源就用系统源追求新版本再编译”。操作系统方面以Debian/Ubuntu或CentOS系为主流。我在生产环境用得最多的是Ubuntu Server LTS和Debian稳定版apt源里的Nginx、PHP、MySQL版本虽然不一定最新但经过了发行版测试依赖关系完整升级路径清晰。CentOS系的yum源同理。除非你确实需要Nginx最新主线版或者PHP 8.3以上的特殊特性否则没必要一上来就编译安装。Nginx版本选择上稳定版stable和主线版mainline的区别在于新功能推出速度。生产环境我习惯用主线版因为Nginx主线版的稳定性实际上已经足够好而且修复安全漏洞更及时。Ubuntu源默认版本可能略旧但用于学习完全没问题。MySQL方面建议直接上MySQL 8.x或者MariaDB 10.x。MySQL 8默认字符集是utf8mb4对中文支持更友好身份认证插件和缓存策略也做了很多优化。如果公司有Oracle授权顾虑MariaDB作为完全兼容的替代品也很成熟LNMP组合里两者都可以用。PHP版本建议PHP 7.4以上目前主流的PHP 8.x在性能和类型安全上有明显提升。如果你只是学习搭建apt安装默认版本即可如果要跑老项目注意PHP版本的兼容性特别是旧框架对PHP 8的语法支持可能存在问题。1.3 动静分离的工作模型动静分离本质上是一种基于请求类型的路由策略。以最常见的PHP站点为例用户的浏览器发起请求Nginx收到之后会做一次分类如果请求的是静态资源比如图片、CSS、JavaScript、字体文件Nginx直接从磁盘读取文件返回不经过PHP-FPM。如果请求的是PHP脚本比如访问index.php、api.phpNginx通过FastCGI协议转发给PHP-FPMPHP执行完再把HTML或JSON返回给浏览器。这个分类过程由Nginx配置文件中的location匹配规则完成。动态请求通常是匹配以.php结尾的URI静态请求则是匹配常见的静态文件扩展名。理解动静分离的好处得从反向代理的角度看。Nginx在这里扮演的是一个反向代理服务器的角色它屏蔽了后端多台应用服务器的细节对外只暴露一个入口。这样做不仅能让静态资源响应更快更关键的是减轻了PHP-FPM的压力。我见过不少运维事故明明站点访问量不大但PHP-FPM进程全部被占满查下来发现是几万个图片请求全部打到了动态解析上每个图片请求都白白消耗了一个PHP子进程的CPU和内存。动静分离合理配置之后这类问题基本不会出现。2. 核心组件安装从零把三件套跑起来2.1 Nginx的安装与最小配置我用Ubuntu 22.04为例演示其他发行版命令类似。先更新软件源并安装Nginxsudo apt update sudo apt install nginx -y安装完成后Nginx的配置文件目录结构是/etc/nginx/nginx.conf主配置文件/etc/nginx/sites-available/站点配置可用/etc/nginx/sites-enabled/站点配置启用/etc/nginx/conf.d/额外配置片段/var/log/nginx/access.log 和 error.log日志主配置里有几个参数需要关注。worker_processes建议设为CPU核心数可以通过lscpu查看worker_connections表示每个worker进程能同时保持的最大连接数默认1024并发大的场景可以适当调高。静态文件的高效处理依赖sendfile on、tcp_nopush on这两个指令配置里默认就带不要去掉。创建一个站点配置前先确认你的网站根目录存在并且权限正确。我习惯把站点根目录放在/var/www下比如/var/www/examplesudo mkdir -p /var/www/example sudo chown -R $USER:$USER /var/www/example最小的server块长这样server { listen 80; server_name example.com www.example.com; root /var/www/example; index index.php index.html; location / { try_files $uri $uri/ 404; } }用nginx -t检查配置语法没问题就systemctl reload nginx。如果你需要编译安装核心参数大概是这样注意这只是关键参数的示意并非完整命令./configure --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_gzip_static_module \ --with-http_v2_module \ --with-http_realip_module编译安装的优势是版本可控、模块可裁但对大多数场景来说系统源安装已经够用不必额外折腾。2.2 MySQL的安装与初始化MySQL安装同样简单sudo apt install mysql-server -y安装完成后MySQL服务会自动启动但默认的root账号几乎没什么密码策略建议立即执行安全初始化脚本sudo mysql_secure_installation这个脚本会引导你设置root密码、删除匿名用户、禁止root远程登录、删除测试数据库。生产环境建议全部选是。接下来创建一个给PHP站点使用的业务数据库和用户。以数据库名appdb、用户名appuser为例CREATE DATABASE appdb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER appuserlocalhost IDENTIFIED BY 这里写一个强密码; GRANT ALL PRIVILEGES ON appdb.* TO appuserlocalhost; FLUSH PRIVILEGES;我用utf8mb4而不用老的utf8是因为utf8mb4是完整的Unicode实现能存emoji和生僻字老utf8在MySQL里其实是utf8mb3遇到四字节字符会报错。这个坑在早期项目里太常见了。MySQL 8默认的认证插件是caching_sha2_passwordPHP的mysqli和PDO扩展在PHP 7.4以上版本都支持不用担心兼容问题。如果遇到老版本PHP连不上MySQL 8可以考虑在CREATE USER时指定mysql_native_password但更推荐升级PHP版本而不是降低安全标准。2.3 PHP与PHP-FPM的安装与配置PHP本身只是一个命令行解释器真正和Nginx协作的是PHP-FPM。安装命令sudo apt install php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip -y我安装的扩展基本覆盖了绝大多数Web项目的需求php-mysql负责连库php-gd处理图片php-mbstring处理多字节字符串php-xml和php-zip在Composer安装依赖时基本是必需品。安装完成后PHP-FPM的配置文件在/etc/php/版本号/fpm/目录下核心是php.ini和pool.d/www.conf。php.ini里有几个参数建议调整upload_max_filesize 64M post_max_size 68M memory_limit 256M max_execution_time 60这些参数的关系是post_max_size必须大于upload_max_filesize否则大文件上传会被截断memory_limit要大于脚本实际内存峰值否则会报Allowed memory size exhausted。再说pool配置也就是www.conf这里面的listen参数决定了Nginx如何找到PHP-FPMlisten /run/php/php8.1-fpm.sock listen.owner www-data listen.group www-data listen.mode 0660 user www-data group www-data关键点在于listen用的是Unix Socket而不是127.0.0.1:9000。两者都能工作但同机部署时我强烈推荐Unix Socket它走的是内核进程间通信没有TCP协议栈的开销延迟更低也避免了端口被外部扫描的风险。使用Socket时必须要保证Nginx的worker进程通常是www-data用户有权限访问这个Socket文件这就是listen.owner和listen.group要设成和Nginx一致的原因。进程管理模式用pm dynamic即可max_children的数值需要根据服务器内存估算。一个PHP-FPM子进程大约占用30-60MB内存2GB内存的机器建议max_children设为20-30别贪多进程数超过物理内存反而会因为swap导致性能雪崩。3. 动静分离的配置实战Nginx站点配置全拆解3.1 一个完整的server配置组件全都装好之后就到了最关键的一步——写Nginx站点配置把动静分离落地。下面这个配置是我在生产环境使用过的一个完整示例server { listen 80; server_name example.com; root /var/www/example; index index.php index.html; # 动态请求所有以 .php 结尾的URI交给PHP-FPM location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php8.1-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_index index.php; fastcgi_read_timeout 60; } # 静态资源图片、CSS、JS等直接由Nginx处理 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?|ttf|eot)$ { expires 30d; add_header Cache-Control public, no-transform; access_log off; } # 默认规则处理无后缀的请求 location / { try_files $uri $uri/ /index.php?$query_string; } }这个配置里一共有三组location规则分别对应动态请求、静态资源和根路径请求。Nginx在收到请求后会按照location的匹配规则决定走哪一组。以https://example.com/api/user.php为例它匹配第一组被转发给PHP-FPM以https://example.com/static/js/app.js为例它匹配第二组直接读取/var/www/example/static/js/app.js返回给浏览器完全不会占用PHP进程。这里的fastcgi_pass参数就是Nginx与PHP-FPM之间的连接通道用的是安装PHP时生成的Socket文件路径。每次改完配置都记得执行nginx -t再reload避免语法错误导致Nginx直接拒绝启动。3.2 location匹配规则的优先级与陷阱很多新手栽在location上是因为没搞懂Nginx的匹配优先级。Nginx的location规则按优先级从高到低排列精确匹配location /path前缀匹配且带^~location ^~ /static/正则匹配location ~ .php$普通前缀匹配location /static/默认匹配location /正则匹配用~或~*开头有个特点是按照顺序匹配一旦命中就停止。所以如果你写了多个正则location一定要把更具体的规则写在前面。动静分离配置里最需要注意的坑是不要用正则location去匹配所有静态文件之后再套一层动态解析。比如有人这样写location ~* \.(jpg|png|css|js)$ { root /var/www/example; fastcgi_pass unix:/run/php/php8.1-fpm.sock; }这等于把所有静态请求都转发给了PHP-FPM完全失去了动静分离的意义。静态资源就应该由Nginx直接处理这个定位不能搞混。另外一个安全陷阱是.htaccess文件和.user.ini这类隐藏文件。如果你不加保护Nginx可能把以点开头的文件内容直接返回给浏览器而这些文件往往包含敏感配置。建议在server块里加一条拒绝规则location ~ /\. { deny all; }还有PHP脚本解析的安全问题。如果没有对请求做合法性校验攻击者可以构造一个不存在的PHP文件路径比如/var/www/example/upload/nonexistent.php如果Nginx把它也交给PHP-FPM解析就可能触发代码执行漏洞。官方推荐的安全写法是location ~ \.php$ { try_files $uri 404; include fastcgi_params; fastcgi_pass unix:/run/php/php8.1-fpm.sock; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; }try_files $uri 404的作用是只有文件真实存在才进入后面的FastCGI处理否则直接返回404。这一行能堵住绝大多数PHP文件包含攻击。3.3 Rewrite规则与常见框架的伪静态配置PHP框架普遍采用单一入口模式比如ThinkPHP、Laravel所有请求都先进入index.php再由框架内部路由分发。这种模式要求Nginx把所有不存在的文件请求重写到入口文件。我经常用的通用规则是location / { try_files $uri $uri/ /index.php?$query_string; }这样配置之后访问https://example.com/home/index如果磁盘上不存在对应的home目录或index文件Nginx就会把请求转交给index.php处理query_string原样保留框架通过PATH_INFO或路由参数就能解析出真实的控制器和方法。有些老教程会用if判断再rewrite写法是if (!-e $request_filename) { rewrite ^/(.*)$ /index.php/$1 last; }这种写法也能工作但官方文档明确建议优先使用try_files因为if在Nginx里是“邪恶指令”容易出现意想不到的副作用。try_files的语义更清晰性能也更好。WordPress的伪静态则是对固定链接的支持location / { try_files $uri $uri/ /index.php?$args; }基本上现代PHP项目的伪静态规则都可以抽象成一句话文件存在就返回文件文件不存在就进入index.php。需要特别注意的是location /和location ~ .php$的协作关系。当一个PHP请求经过try_files重写为/index.php后Nginx会再次执行location匹配规则此时URI变成了/index.php匹配到php正则location于是转发给PHP-FPM。这个“二次匹配”机制是理解Nginx配置的关键很多配置看着没错但不生效就是没搞懂重写后的请求会重新匹配location。3.4 静态资源的缓存策略与性能调优动静分离配置完成后下一步是优化静态资源的响应性能。浏览器缓存是成本最低的优化手段通过Cache-Control和Expires响应头告诉浏览器“这个文件多久之内不用再问服务器要”。我在配置里用的expires 30d就是Nginx提供的快捷指令等价于给静态资源设置了30天的过期时间。实际使用中建议根据资源类型区别对待资源类型缓存时间建议带哈希指纹的文件app.a1b2c3.js365d文件名变了才需要重新拉取CSS/JS无指纹7d避免更新后浏览器还缓存老版本图片/字体30d一般不会频繁变化HTML页面不缓存保证更新即时生效实现方式可以拆成两个location块或者在一个location里用map变量根据文件扩展名区分。简单场景下直接按扩展名写两个规则即可location ~* \.(js|css)$ { expires 7d; access_log off; } location ~* \.(png|jpg|jpeg|gif|ico|svg|woff2?)$ { expires 30d; access_log off; }同时建议开一下gzip压缩对CSS、JS、SVG这类文本资源的体积削减非常明显gzip on; gzip_types text/plain text/css application/json application/javascript application/xml image/svgxml; gzip_min_length 1024;gzip_min_length 1024的意思是小于1KB的文件不压缩因为压缩小文件带来的CPU开销可能大于传输节省的时间。生产环境里还有一个细节静态资源请求不写访问日志。像图片、CSS这类请求量很大每条都记日志会白白消耗磁盘IO。我在静态location里写了access_log off真实请求量大的站点这个配置能让日志文件增长慢好几倍。3.5 动静分离的另一种形态反向代理到Java应用LNMP里的动静分离是最经典的一种但动静分离的思想不局限在PHP场景。现在很多系统是前后端分离架构前端是Nginx托管的静态页面后端是Java、Go等语言写的微服务接口。Nginx仍然承担“静态直接返回、动态转发到后端应用”的角色只不过fastcgi_pass换成了proxy_pass。以若依微服务这类项目为例常见的部署方式是前端打包后的dist目录放到Nginx站点根目录接口请求转发到后端的Gateway网关server { listen 80; server_name admin.example.com; root /var/www/ruoyi/dist; index index.html; # 前端路由支持 location / { try_files $uri $uri/ /index.html; } # 接口反向代理 location /prod-api/ { 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; } # 静态资源缓存 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 30d; access_log off; } }这段配置里/prod-api/前缀的请求被转发到本机8080端口的后端服务其他请求优先找静态文件找不到就回退到index.html由前端路由接管。从本质上说这依然是动静分离——静态页面交给Nginx动态接口交给应用服务器只不过代理协议从FastCGI换成了HTTP。理解这一点很重要。Nginx在架构里的角色就是流量入口和分发器不管后端是PHP-FPM、Tomcat、Node.js还是Go服务对Nginx来说都是上游服务器。理解了这个模型你就能灵活应对各种部署架构而不是死记某一种配置模板。4. 日志、开机启动与线上问题排查实录4.1 访问日志与错误日志的合理配置日志是排查问题最重要的线索。Nginx默认的访问日志格式比较简单建议自定义一个包含耗时信息的格式log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for rt$request_time uct$upstream_connect_time uht$upstream_header_time urt$upstream_response_time;这个格式多了三类关键信息request_time是Nginx处理完整请求的总耗时upstream_response_time是上游PHP-FPM或后端服务的处理耗时。如果发现request_time很大但upstream_response_time很小说明瓶颈在网络传输或Nginx本身而不是后端应用。在站点配置里指定这个格式access_log /var/log/nginx/example_access.log main; error_log /var/log/nginx/example_error.log warn;静态资源的访问日志用access_log off关掉前面已经提到。错误日志级别用warn即可debug级别会记录海量信息反向坑到自己。PHP-FPM本身的错误日志也要关注配置文件里有个catchworkers_output和php_admin_flag[log_errors]参数。如果PHP脚本出错Nginx错误日志只会显示“Primary script unknown”或者“Connection reset by peer”真正的原因要到PHP-FPM日志里看。4.2 开机启动与systemd管理生产环境千万不要直接用nginx二进制启动服务而是要用systemd管理这样能实现开机自启、崩溃自动拉起、统一日志管理。Debian/Ubuntu安装时已经自动注册了服务只需要启用开机自启sudo systemctl enable nginx sudo systemctl enable php8.1-fpm sudo systemctl enable mysql用systemctl管理服务的日常命令sudo systemctl start nginx sudo systemctl restart php8.1-fpm sudo systemctl status mysql每次修改配置文件后先执行nginx -t检查语法再执行systemctl reload nginx实现平滑生效。reload会重新加载配置并逐步替换worker进程不会中断当前请求这是nginx命令做不到的。PHP-FPM和MySQL同理改完配置后也需要重启或reload。PHP-FPM没有独立的reload命令只能restart重启会中断正在处理的请求所以尽量在低峰期操作。4.3 常见问题与排查技巧速查以下是我在实际排障中遇到过最多的问题整理成一张速查表现象可能原因排查命令/解决方式访问PHP页面返回502 Bad GatewayPHP-FPM未启动、Socket路径不对、权限错误systemctl status php8.1-fpm检查www.conf的listen路径与Nginx的fastcgi_pass是否一致返回504 Gateway TimeoutPHP执行时间超过fastcgi_read_timeout增大fastcgi_read_timeout同时排查PHP脚本是否有死循环或慢查询返回403 Forbiddenindex指令缺失、目录无权限、被deny规则拦截检查站点的index.php是否存在检查nginx worker用户对目录是否有读权限返回404 Not Foundroot路径不对、try_files规则没生效、SCRIOT_FILENAME错误确认请求的真实URI检查SCRIPT_FILENAME是否指向正确文件返回空白页状态码200PHP脚本有语法错误或异常被静默处理查看/var/log/php8.1-fpm.log打开display_errors临时排查静态文件更新后浏览器还是老文件浏览器缓存未过期开发环境把expires设置为off生产环境用带哈希的文件名Nginx启动失败配置文件语法错误、端口被占用nginx -t定位语法问题netstat -tlnp看看80端口是否被其他进程占用排查问题时我习惯的路径是先确认进程状态systemctl status确认三件套都在运行再看Nginx错误日志tail -f /var/log/nginx/error.log然后看PHP-FPM日志最后才怀疑代码问题。按照这个顺序大多数问题能在五分钟内定位。有一个特别容易踩的坑是Socket文件权限问题。Nginx的worker进程以www-data用户运行PHP-FPM创建的Socket也在tmpfs或/run目录下如果listen.mode设置不当Nginx会报Permission denied。我遇到过完全相同的LNMP配置在一台机器上正常换一台机器就502最后发现是PHP-FPM版本升级后Socket文件的默认权限变了。5. 生产环境LNMP的部分性能参数优化5.1 Nginx的进程与连接数调优如果站点并发请求量上来了Nginx默认的worker_processes和worker_connections可能需要调整。我的经验值是worker_processes等于CPU物理核心数worker_connections设到10240左右公式上最大并发数约等于worker_processes乘以worker_connections但实际还要考虑内存占用和文件描述符限制。worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 10240; use epoll; }use epoll是Linux下的高性能事件模型默认一般就是epoll显式写上也无妨。调完这个之后检查系统的文件描述符限制ulimit -n如果小于65535需要调整/etc/security/limits.conf。5.2 FastCGI缓冲与超时的取舍PHP-FPM返回的响应内容较大时Nginx默认会做缓冲。缓冲的好处是PHP-FPM可以快速写完响应并释放进程Nginx再慢慢把内容发给客户端这样避免大量慢速客户端拖住PHP进程。fastcgi_buffers 8 16k; fastcgi_buffer_size 32k; fastcgi_read_timeout 120; fastcgi_connect_timeout 30;如果某个接口需要实时推送比如SSEServer-Sent Events之类的流式响应缓冲反而会拦截数据推送这种情况下需要关闭缓冲fastcgi_buffering off;具体业务具体分析但默认开启缓冲对大多数Web应用是更优选择。5.3 HTTPS与安全加固的补充建议现代站点必须开通HTTPSNginx里配置SSL证书的核心配置片段listen 443 ssl http2; server_name 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;HTTP请求强制跳转到HTTPS在80端口的server块里加一行return 301 https://$host$request_uri;关于安全日常最容易被忽略的是Nginx版本更新。apt源里的版本有安全补丁时记得及时升级日常运维至少要保证隐藏Nginx版本号server_tokens off限制上传目录的PHP执行权限定期检查访问日志中的异常扫描请求。在Linux系统中用rm -rf这类危险操作前一定要再三确认目录路径。我见过有人把整台服务器的文件删光原因就是在root目录下多敲了一个斜杠。教训很惨痛操作之前多看一眼路径没有坏处。我个人在实际操作中还有一个习惯每完成一步配置就用curl测一下响应头和相关页面状态。比如配置完动静分离后分别curl静态文件路径和PHP路径对比响应结果的耗时和处理方式。curl -I可以查看响应头能看到Nginx直接返回静态文件时响应头里会有Accept-Ranges和明确的Content-Type而动态请求会经过FastCGI。多观察这些细节你对整个请求链路的理解会越来越清晰。LNMP这套东西说难不难说简单也不简单核心就是把每个组件的职责边界搞清楚。Nginx负责流量分发和静态资源PHP-FPM负责动态脚本执行MySQL负责数据存储动静分离只是这种职责分工在配置层面的自然体现。按照文章里的方式一步一步搭下来中间再踩几次坑你就能把这些配置从“背下来的”变成“真正理解的”。
