尧图网页设计 
做了这么多年后端开发和运维我越来越有一个体会很多看起来复杂的架构问题最后落到入口处往往就是一个Nginx的事。Nginx能被称为“高性能、轻量级服务器”这么多年不是靠营销堆出来的——它资源占用小、并发能力强、配置灵活无论是给前端开个接口、部署一套静态网站、做反向代理还是在内网搭个文件共享服务它都是最省心的选择。这篇文章我想从一个普通开发/运维的使用视角把Nginx从安装、配置到常见坑位完整过一遍。不管你是刚接触Nginx的新手还是已经用过一段时间但想查漏补缺都能在里面找到可以直接照抄的做法。全文偏实战理论只讲够用的部分不会堆术语。1. 为什么说Nginx是“轻量级高性能”服务器1.1 Nginx到底解决了什么问题在Nginx出现之前Web服务器领域基本是Apache的天下。Apache功能齐全、模块丰富但有句老话叫“能力越强负担越重”Apache在处理高并发连接时非常吃力默认的perfork模式会为每个连接创建一个进程并发一上来内存和CPU直接告急。早期互联网流量不大这个问题不明显后来网站访问量爆发式增长C10K问题也就是单台服务器并发处理一万个连接成了所有服务端程序员的噩梦。Nginx正是在这个背景下被设计出来的。它的核心目标很明确用尽量少的系统资源抗住尽量多的并发连接。围绕这个目标它把自己做成了三个关键角色静态文件服务器直接处理图片、JS、CSS、HTML等静态资源性能比Apache高很多。反向代理服务器把请求转发给后端的Tomcat、Node.js、Spring Boot等服务隐藏真实后端地址。负载均衡器把流量分发到多台后端服务器上提高整体吞吐和可用性。这三件事覆盖了绝大多数Web项目的共性需求所以Nginx几乎成了互联网应用的事实标准入口。1.2 轻量级的本质进程模型与资源占用很多人对“轻量级”有误解以为只是安装包小。其实Nginx的轻量核心体现在内存占用和处理模型上。Nginx采用master-worker进程模型启动时只有一个master主进程负责读取配置、管理worker进程和接收外部信号真正干活的是多个worker工作进程。每个worker进程是单线程的但它可以同时处理成千上万个连接。这意味着什么举个例子我的测试服务器是4核CPU、2G内存用Nginx跑一个日活十几万的静态站worker进程总内存占用还不到200MBCPU长期保持在10%以下。对比一下就明白了Apache的prefork模式每个连接一个进程一个进程至少吃掉几MB内存一万个连接就是几十GB普通服务器根本扛不住。即使换成worker模式每个进程开多线程每个线程也有栈空间开销。Nginx的方式是“少量进程 事件驱动”进程数量跟CPU核数绑定而不是跟连接数绑定自然省资源。还有个细节值得注意worker进程数量通常设置为CPU核心数或auto。设置多了反而不好因为进程间切换会消耗CPU还会带来锁竞争设置少了则无法充分利用多核性能。1.3 高并发的底气事件驱动与异步非阻塞Nginx能低资源消耗地处理高并发靠的不是魔法而是事件驱动模型。在Linux上Nginx使用epoll在macOS/BSD上使用kqueue。这两个系统调用允许一个进程同时监控数千个网络连接的读写事件只有事件发生时才去处理没有事件就继续监听让CPU一直处在干活状态而不是空转等待。我用一个生活化的类比说明传统的Apache像餐厅里的一对一服务一个服务员全程盯着一个客人客人点菜、催菜、结账服务员都在旁边干等着客人多了就只能加服务员成本跟着涨。Nginx则像一个高效的前台手里揣着小本子客人招手才过去记下来之后去后厨催单中间还能顺手接待其他客人。所以同样的服务员数量Nginx能服务的客人数量翻几十倍。当然Nginx的事件驱动也有适用边界。它擅长处理I/O密集的任务比如静态文件读取、代理转发但如果后端业务逻辑本身非常耗时比如大量CPU计算瓶颈就不在Nginx而在后端应用这时Nginx能做的只是尽量把请求平滑地分发过去。2. 部署并跑起来常见安装方式的实操对比2.1 二进制包安装的适用场景我自己的习惯是测试环境用系统自带的二进制包生产环境用源码编译安装。二进制包安装最省事适合快速上手。在Ubuntu/Debian系列上sudo apt update sudo apt install nginx -y nginx -v systemctl start nginx systemctl enable nginx在CentOS/RHEL包括Rocky Linux、AlmaLinux 9这些新一代发行版上sudo yum install nginx -y # 或者 sudo dnf install nginx -y systemctl start nginx systemctl enable nginx用二进制包安装有个好处系统会自动处理依赖、配置文件路径、服务启动脚本。装完默认就能访问打开浏览器输入服务器IP就能看到欢迎页。日常维护也方便升级用apt upgrade或yum update直接搞定。但它也有坑系统源里的版本一般偏旧比如某些发行版带的Nginx可能还是1.18/1.20等老版本不支持一些新特性。另一个问题是官方源没有的部分模块比如rtmp流媒体模块、image-filter等装不了这时候就需要编译安装了。2.2 源码编译安装为什么值得学源码编译是进阶的第一道门槛也是我觉得每个Nginx使用者都应该掌握的操作。原因很实在版本最新可以自己选择。编译时可以自由启用/禁用模块按需定制。可以把SSL模块静态编进去避免升级OpenSSL后动态加载出问题。在纯内网环境没有外部源可用时只有源码编译这条路最可靠。编译前需要准备三个依赖PCRE正则表达式支持、OpenSSLSSL/TLS支持、zlibgzip压缩支持。关于PCRE我推荐从官网下载pcre-8.45源码包这个版本虽然出来很久了但和Nginx的兼容性非常稳定配套使用几乎不会出幺蛾子。编译流程三步走# 1. 解压源码并进入目录 wget http://nginx.org/download/nginx-1.26.0.tar.gz tar -zxvf nginx-1.26.0.tar.gz cd nginx-1.26.0 # 2. 配置编译参数 ./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_gzip_static_module \ --with-stream \ --with-pcre/opt/pcre-8.45 \ --with-openssl/opt/openssl \ --with-zlib/opt/zlib # 3. 编译并安装 make -j4 make install这里有几个容易忽略的细节--prefix决定了Nginx安装到哪个目录默认是/usr/local/nginx如果之后要用nginx -s reload管理最好在/etc/nginx里建一个软链或者把nginx二进制加到PATH里。--with-http_ssl_module一定要加否则后面配HTTPS会提示找不到ssl指令。--with-http_v2_module是HTTP/2支持现在主流浏览器都在用建议加上。纯内网环境比如aarch64服务器不上外网要提前把依赖源码包和Nginx源码包下载好内网机器上再解压编译。整个过程不需要联网这是它最大的优势。编译完启动/usr/local/nginx/sbin/nginx -t /usr/local/nginx/sbin/nginx看到nginx: ... is successful就说明配置文件没问题。2.3 Windows环境下的安装与注意事项Windows上装Nginx和Linux完全不是一回事但确实有很多人在用主要是本地开发调试。Windows版的Nginx不是以服务方式运行的。从官网下载zip包后解压到某个目录强烈建议不要解压到带空格的路径比如C:\Program Files然后打开命令行窗口运行cd C:\nginx-1.26.0 start nginx.exe启动后在任务管理器里能看到两个nginx.exe进程一个master一个worker。停止用nginx.exe -s stop重载配置用nginx.exe -s reload。Windows上我踩过两次坑在这里提醒大家第一路径分隔符问题。Nginx在Windows上解析路径时C:/dir/file和C:\dir\file都可能遇到问题特别是涉及autoindex和include时。我遇到过一次典型报错nginx: [emerg] createfile() d:/phpstudy_pro/www/admin2.com/nginx.htaccess failed排查了半天发现是配置文件里包含了一个并不存在的htaccess文件路径Nginx启动时尝试创建/读取失败。解决方法是检查include路径是否真实存在并且尽量用正斜杠。第二端口被占用。Windows上80端口经常被IIS或其他程序占用。处理方案二选一要么改Nginx的listen端口要么把占用程序停掉。查端口用netstat命令最直接。3. 核心配置拆解从静态文件到反向代理3.1 配置文件结构与核心指令Nginx的配置全部集中在主配置文件nginx.conf里无论你是用apt装的/etc/nginx/nginx.conf还是编译安装的/usr/local/nginx/conf/nginx.conf核心结构都一样。打开nginx.conf你会看到一层层嵌套的块我习惯把它拆成三个层级全局块最外层配置worker进程数、运行用户、错误日志位置等。比如worker_processes auto;、user www-data;。events块配置连接处理方式核心是worker_connections它定义了每个worker进程能同时打开的最大连接数。http块HTTP协议相关的所有配置里面可以包含多个server块每个server块代表一个虚拟主机。http块里最常用的几个指令我整理成了一张表指令作用建议值sendfile开启零拷贝发送文件ontcp_nopush数据包攒一批再发送提升吞吐onkeepalive_timeout客户端长连接超时30-65gzip开启响应压缩onclient_max_body_size限制客户端请求体积按业务定默认1m另外强烈建议开启include机制。apt安装的Nginx在http块末尾默认有include /etc/nginx/conf.d/*.conf;这样每个站点的配置可以单独立文件不会全堆在主配置里维护起来舒服很多。3.2 静态文件服务与autoindex在线文件浏览静态文件服务是Nginx最基础也最拿手的场景。核心就是一个server块加一个locationserver { listen 80; server_name example.com; root /var/www/example; index index.html; }关键概念是root和alias的区别。root会拼接完整的路径比如root /var/www;配合location /static/请求/static/a.png时实际找的是/var/www/static/a.png而alias会把location前缀替换掉alias /data/files/;配合location /files/请求/files/a.png时找的是/data/files/a.png。刚学的时候容易混记住一句话alias是“替换”root是“拼接”。除了托管静态站Nginx还能当简单的文件共享服务器这就是热词里老提到的“autoindex在线文件浏览”。在内网环境给同事共享大文件、搭建软件仓库这个功能非常实用。配置如下location /download/ { alias /data/softwares/; autoindex on; # 开启目录浏览 autoindex_exact_size off; # 显示可读大小而非精确字节 autoindex_localtime on; # 显示服务器本地时间 charset utf-8,gbk; # 解决中文文件名乱码 }开启后浏览器访问http://你的IP/download/就会列出一个文件列表点击即下载。注意一点autoindex on默认会列出服务器上这个目录下的所有文件如果目录里有机密文件一定要用location的访问控制或干脆不要开启。我见过有人不小心把整个/目录挂出来结果全网都能下他的系统文件相当危险。3.3 反向代理与负载均衡配置反向代理是Nginx生产环境里用得最多的功能。为什么要反向代理本质是为了解耦客户端只认识Nginx不知道真正的后端服务在哪Nginx把请求转发给内网里的Tomcat、Node.js、Python后端等再拿回响应返回给客户端。最简单的一个反向代理配置location /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; proxy_set_header X-Forwarded-Proto $scheme; }这行proxy_set_header X-Real-IP $remote_addr;很关键。因为经过了Nginx后端看到的TCP来源IP是Nginx自己的IP不做转发的化后端的真实客户端IP会全线丢失。做日志分析、风控、审计时这个头必须配上。当后端服务有很多个实例时就需要负载均衡了。Nginx的负载均衡用upstream块定义一组后端服务器upstream backend_pool { server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight2; server 192.168.1.12:8080 down; } location / { proxy_pass http://backend_pool; }Nginx支持几种负载均衡策略默认轮询每个请求轮流分配给不同后端weight权重按比例分配适合后端配置高低不一的集群ip_hash同一个IP的请求固定打到同一台后端解决session问题least_conn优先分给当前连接数最少的那台适合请求处理时间不均匀的业务。刚才那个配置里我加了一个server 192.168.1.12:8080 down;表示手动标记这台机下线Nginx不会把流量分给它。这个技巧在做灰度发布或后端单台重启时很实用不用改业务加个down就能临时摘除一台机器。3.4 多站点部署主域名与二级域名一台服务器部署多个网站是Nginx的看家本领核心就是配置多个server块用server_name区分域名。比如主域名example.com指向一个默认站点二级域名blog.example.com指向博客api.example.com指向后端接口server { listen 80; server_name example.com; root /var/www/main; } server { listen 80; server_name blog.example.com; root /var/www/blog; } server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:9000; } }server_name的匹配顺序也有讲究先做精确匹配再匹配以*开头的通配符再匹配以*结尾的通配符最后按正则匹配。如果一个请求没匹配上任何server_name会落到配置文件里排在最前面的那个server作为默认站点。建议在配置里显式加一个默认server块server { listen 80 default_server; return 444; }return 444是Nginx的一个特殊状态码表示直接断开连接不返回任何内容。这么干那些没绑定到你这台服务器上域名比如别人扫到的IP域名就会被挡在外面。多站点管理时我强烈推荐一个目录结构在/etc/nginx/下建sites-available放所有配置文件和sites-enabled放软链只有启用的才链过来。这是Debian系的做法用软链控制启停比把配置文件放在conf.d里直接生效要安全——写错配置不会瞬间暴雷。3.5 SSL证书配置与HTTP强制跳转HTTPS已经是标配了配Nginx的SSL其实不复杂但第一次见到一堆证书变量时确实会懵。先从证书服务商那里下载证书注意要下载Nginx类型的证书服务商一般会区分Apache、IIS、Nginx格式。这个坑真的常见很多人在Godaddy这类平台下载证书时随便下了一个Apache格式回来配置发现证书链加载失败。Nginx类型的证书通常有两部分证书链文件有的叫fullchain、有的叫bundle——包含网站证书和中间证书。私钥文件.key——生成CSR时产生的私钥一定不能泄露。nginx.conf里的配置server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/certs/example.com_fullchain.crt; ssl_certificate_key /etc/nginx/certs/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; root /var/www/example; }如果还想开启HTTP/2把listen改成listen 443 ssl http2;即可。HTTP/2能通过多路复用显著提升页面加载速度特别是资源多的站点效果明显。HTTP强制跳转到HTTPS的配置一般是单独一个server块server { listen 80; server_name example.com; return 301 https://$host$request_uri; }这样用户访问http://example.com/xxx浏览器会跳到https://example.com/xxx。我遇到过一种报错客户端访问HTTPS站点时返回no required ssl certificate was sent。这个错误有两层含义如果你是客户端说明服务端没有配置正确的证书如果你是自己配置的服务端那多半是证书文件或私钥路径写错了或者是证书链不完整浏览器/curl无法验证。排查方法是先用openssl s_client -connect 域名:443看看证书是否正常加载再检查nginx错误日志看有没有cannot load certificate或PEM_read_bio这类关键字。4. 进阶运维平滑升级、进程管理与高并发调优4.1 平滑升级的原理与操作线上Nginx升级最怕什么怕流量中断。老版本有安全漏洞必须升但又不能停机这时候就要用平滑升级。平滑升级的原理是利用Nginx的信号机制向master进程发送USR2信号让它启动一个全新的master和一组worker进程新旧两套进程同时存在新master接管配置和监听确认正常后给旧master发WINCH信号让它关闭旧的worker进程最后发QUIT信号让旧master退出。实际操作步骤# 1. 拿到旧版本的PID号 cat /usr/local/nginx/logs/nginx.pid # 2. 编译好新版本替换二进制文件 # 先备份旧二进制 cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old make -C /usr/local/nginx-1.26.0 make -C /usr/local/nginx-1.26.0 install # 3. 语法检查确认新配置没问题 /usr/local/nginx/sbin/nginx -t # 4. 向旧master进程发送USR2信号 kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid) # 5. 等待片刻把新老进程都列出来确认新master已经起来 ps -ef | grep nginx # 6. 确认正常后关闭旧worker进程 kill -WINCH $(cat /usr/local/nginx/logs/nginx.pid) # 7. 观察日志确认没有请求出问题后杀掉旧master kill -QUIT $(cat /usr/local/nginx/logs/nginx.pid)如果发现新版本有问题可以回滚发HUP信号给旧master让它重新拉起worker进程然后发TERM信号给新master进程把它终止。整个过程流量几乎无感知这就是Nginx敢自称高可用的底气。4.2 进程管理与信号控制Nginx的进程控制全靠信号这个理解了之后就变得很简单。常用命令其实就是几条nginx -s stop # 立即停止 nginx -s quit # 优雅退出处理完当前请求再退出 nginx -s reload # 重载配置优雅重启worker nginx -s reopen # 重新打开日志文件日志切割常用其中reload是最高频的操作它的内部流程是master收到HUP信号后重新加载配置文件并校验如果配置有误则不执行校验通过后启动一组新的worker进程同时通知旧的worker把手上正在处理的请求处理完再退出。所以reload过程中服务不会中断正在进行的请求也不会被强杀。信号和对应动作的完整表格信号作用TERM/INT立即停止所有进程QUIT优雅停止处理完当前请求再退HUP重载配置启动新worker结束旧workerUSR1重新打开日志文件USR2平滑升级启动新masterWINCH优雅关闭旧worker进程实际操作中注意一点如果在sbin目录下找不到nginx命令比如用systemctl管理的情况可以直接用kill系列命令操作前提是拿到正确的master PID。千万别在没搞清楚PID的情况下kill -9所有nginx进程那样会让正在处理的请求全部断开还可能留下pid文件不一致的问题。4.3 高并发场景下的关键调优参数高并发的调优是个系统工程Nginx配置只是其中一层系统内核也要配合。我从Nginx配置和系统层面分别说。Nginx配置层有几个核心参数直接影响并发能力worker_processes auto; # 等于CPU核数 worker_rlimit_nofile 65535; # 每个worker可打开的文件描述符上限 events { worker_connections 10240; # 每个worker最多处理10240个连接 use epoll; # Linux上明确用epoll模型 } http { keepalive_timeout 30; # 长连接超时太短会频繁重连太长浪费连接 sendfile on; tcp_nopush on; tcp_nodelay on; gzip on; # 开启压缩 gzip_types text/plain text/css application/json application/javascript; }计算一下最大并发连接数worker_processes * worker_connections也就是CPU核数×10240。一台4核服务器理论并发就是40960个连接实际受带宽、内存、后端处理速度影响但已经很能打了。打开文件描述符限制这个参数特别容易被忽略。Nginx每个连接要占用一个文件描述符默认的ulimit -n是1024只够处理几百个并发连接。改法# 在 /etc/security/limits.conf 里追加 * soft nofile 65535 * hard nofile 65535内核层面还要注意两个参数。一个是net.ipv4.ip_local_port_range如果Nginx作为代理大量主动向后端发起连接本地端口不够用会直接报错一般建议扩大到1024到65535。另一个是net.core.somaxconn定义了系统层面最大监听队列长度Nginx的listen backlog超过它会被截断高并发下容易丢连接。压测验证推荐用wrk或者ab不需要太复杂的工具ab -n 100000 -c 1000 http://your-domain/看Requests per second和Time per request这两个指标对比调优前后的数据就能知道改动有没有效果。4.4 upstream keepalive与长连接复用很多人在配Nginx反向代理时忽略了一个细节Nginx默认向后端转发请求时每个请求都可能新建一条TCP连接。高并发下握手开销会吃掉大量资源响应变慢。解决办法是开启upstream keepalive长连接复用。具体配置如下upstream backend_pool { server 127.0.0.1:8080; keepalive 32; # 每个worker连接池里最多保留32条空闲连接 } location / { proxy_pass http://backend_pool; proxy_http_version 1.1; # 连接复用要求HTTP/1.1或以上 proxy_set_header Connection ; # 清空Connection头避免影响复用 }这里有个容易出错的点如果只加keepalive 32没有设置proxy_http_version 1.1和清空Connection头连接复用其实是失效的。因为默认的HTTP/1.0下每个请求结束后连接就关闭keepalive形同虚设。keepalive的值不是越大越好。这个值是每个worker进程的空闲连接池上限设得太大后端稍微一忙空闲连接就被占满新请求照旧新建连接设得太小频繁的握手抵消不了收益。经验值是从16到64之间先试试压测时观察后端的TIME_WAIT连接数来微调。我在反转Tomcat集群时用32实测握手开销下降明显后端TIME_WAIT从几千降到几百。5. 常见问题与排查技巧实录5.1 配置文件错误与路径问题Nginx配置容易出错好在它自带语法检查神器nginx -t。改完配置先执行nginx -t如果语法有问题会精确指出错误在哪一行。正常情况下输出nginx: configuration file /etc/nginx/nginx.conf test is successful。但有些错误不是语法层面的。比如热词里那个nginx: [emerg] createfile() d:/phpstudy_pro/www/admin2.com/nginx.htaccess failed报错的大白话是Nginx在启动时尝试访问一个叫nginx.htaccess的文件但路径不对或文件不存在。出现这种问题通常是配置文件里有include或auth_basic_user_file指向了一个不存在的位置或者目录权限不对。解决办法检查对应文件是否存在、路径中的盘符和分隔符是否被正确解析。Windows下尤其要小心解压路径、日志路径、站根目录都建议用正斜杠。还有一类常见错误是[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)意思是80端口被占了。排查用ss -lntp或netstat -lntp看谁在用是别的Nginx实例还是其他服务然后停掉冲突进程或者改port。5.2 SSL相关报错与证书问题SSL问题大概能占日常疑难杂症的三成。我把高频问题整理成了一份速查表问题现象大概率原因排查方向证书加载失败日志报PEM_read_bio证书格式不对或文件损坏用openssl命令看证书内容完整性浏览器提示不安全/不受信任中间证书缺失只上传了站点证书下载fullchain/bundle版本no required ssl certificate was sent服务端没配证书或配错或客户端TLS版本过低用openssl s_client核查更新客户端TLS页面跳转后提示Mixed Content页面里还有http的图片/脚本前端资源改成https或加CSP升级安全策略证书过期忘了续期加定时任务做自动续期提前告警no required ssl certificate was sent还有一个触发场景是客户端要求客户端证书mTLS但没发如果服务端配置了ssl_verify_client on而对端没有提供证书就会报这个错。排查时先看自己的服务端是不是开了双向认证别一上来就怀疑证书坏了。5.3 进程管理异常无法停止、端口占用、残留进程进程管理遇到的问题千奇百怪举几个我实际碰到过的一是怎么都停不掉Nginx。用nginx -s stop没反应查进程发现页面服务还在。这种情况一般是信号丢失或pid文件被改动。最稳妥的做法是先用ps -ef | grep nginx找到master PID然后kill -QUIT 主PID优雅停止不要上来就kill -9。二是端口明明显示没被占用但Nginx就是提示bind失败。这多半是IPv6和IPv4同时绑定的问题Nginx默认监听[::]:80和0.0.0.0:80两套其中一套被占就会报错。解决方法是listen明确指定IP比如listen 0.0.0.0:80;。三是reload后配置没有生效。先确认配置文件语法完整然后用nginx -T把所有生效配置打出来看看是不是include了别的文件把你的配置覆盖了。5.4 卸载与重装注意事项换发行版、升级大版本、从二进制包切到编译安装都可能涉及卸载Nginx。卸载这件事看着简单实际容易留尾巴。系统包安装的卸载# Debian/Ubuntu apt purge nginx nginx-common # CentOS/RHEL yum remove nginx编译安装的卸载就要小心了因为大部分编译安装没有make uninstall。需要手动清理rm -rf /usr/local/nginx rm -f /etc/init.d/nginx # 如果做过启动脚本 rm -f /etc/systemd/system/nginx.service # 如果注册过systemd服务 rm -rf /var/log/nginx # 日志 rm -rf /etc/nginx # 配置文件如果存在重装之前务必先备份两样东西nginx.conf和站点配置文件。我见过有人重装后手忙脚乱配SSL结果发现私钥没备份只能重新生成CSR去申请证书平白多等几个小时。重装时版本选择也有讲究。当前Nginx稳定版和主线版的差别主要在特性和bugfix生产环境建议选stable覆盖的版本。下载渠道推荐国内镜像站或者Nginx官网也可以直接用系统源装。如果是纯内网预先把rpm包或源码包传进去离线安装完全可行。最后说点我的个人体会用Nginx这么多年踩过的坑大多不是高级问题而是基础细节。我现在养成了三个雷打不动的习惯第一所有配置改动先nginx -t再reload绝不多留一秒错误配置在线第二每个站点独立一个配置文件用include管理主配置保持精简出了事定位快第三日志一定要认真看把access_log格式加上响应时间和上游处理时间排查性能问题全靠它逆推现场。如果你也是刚起步建议先把静态站点和反向代理跑通再依次加上SSL、负载均衡、缓存、长连接调优每加一个能力就压测验证一次。把基本功打扎实了Nginx会是你手里最趁手的那把工具。 Nginx轻量级高性能服务器：安装配置、反向代理与高并发调优实战
做了这么多年后端开发和运维我越来越有一个体会很多看起来复杂的架构问题最后落到入口处往往就是一个Nginx的事。Nginx能被称为“高性能、轻量级服务器”这么多年不是靠营销堆出来的——它资源占用小、并发能力强、配置灵活无论是给前端开个接口、部署一套静态网站、做反向代理还是在内网搭个文件共享服务它都是最省心的选择。这篇文章我想从一个普通开发/运维的使用视角把Nginx从安装、配置到常见坑位完整过一遍。不管你是刚接触Nginx的新手还是已经用过一段时间但想查漏补缺都能在里面找到可以直接照抄的做法。全文偏实战理论只讲够用的部分不会堆术语。1. 为什么说Nginx是“轻量级高性能”服务器1.1 Nginx到底解决了什么问题在Nginx出现之前Web服务器领域基本是Apache的天下。Apache功能齐全、模块丰富但有句老话叫“能力越强负担越重”Apache在处理高并发连接时非常吃力默认的perfork模式会为每个连接创建一个进程并发一上来内存和CPU直接告急。早期互联网流量不大这个问题不明显后来网站访问量爆发式增长C10K问题也就是单台服务器并发处理一万个连接成了所有服务端程序员的噩梦。Nginx正是在这个背景下被设计出来的。它的核心目标很明确用尽量少的系统资源抗住尽量多的并发连接。围绕这个目标它把自己做成了三个关键角色静态文件服务器直接处理图片、JS、CSS、HTML等静态资源性能比Apache高很多。反向代理服务器把请求转发给后端的Tomcat、Node.js、Spring Boot等服务隐藏真实后端地址。负载均衡器把流量分发到多台后端服务器上提高整体吞吐和可用性。这三件事覆盖了绝大多数Web项目的共性需求所以Nginx几乎成了互联网应用的事实标准入口。1.2 轻量级的本质进程模型与资源占用很多人对“轻量级”有误解以为只是安装包小。其实Nginx的轻量核心体现在内存占用和处理模型上。Nginx采用master-worker进程模型启动时只有一个master主进程负责读取配置、管理worker进程和接收外部信号真正干活的是多个worker工作进程。每个worker进程是单线程的但它可以同时处理成千上万个连接。这意味着什么举个例子我的测试服务器是4核CPU、2G内存用Nginx跑一个日活十几万的静态站worker进程总内存占用还不到200MBCPU长期保持在10%以下。对比一下就明白了Apache的prefork模式每个连接一个进程一个进程至少吃掉几MB内存一万个连接就是几十GB普通服务器根本扛不住。即使换成worker模式每个进程开多线程每个线程也有栈空间开销。Nginx的方式是“少量进程 事件驱动”进程数量跟CPU核数绑定而不是跟连接数绑定自然省资源。还有个细节值得注意worker进程数量通常设置为CPU核心数或auto。设置多了反而不好因为进程间切换会消耗CPU还会带来锁竞争设置少了则无法充分利用多核性能。1.3 高并发的底气事件驱动与异步非阻塞Nginx能低资源消耗地处理高并发靠的不是魔法而是事件驱动模型。在Linux上Nginx使用epoll在macOS/BSD上使用kqueue。这两个系统调用允许一个进程同时监控数千个网络连接的读写事件只有事件发生时才去处理没有事件就继续监听让CPU一直处在干活状态而不是空转等待。我用一个生活化的类比说明传统的Apache像餐厅里的一对一服务一个服务员全程盯着一个客人客人点菜、催菜、结账服务员都在旁边干等着客人多了就只能加服务员成本跟着涨。Nginx则像一个高效的前台手里揣着小本子客人招手才过去记下来之后去后厨催单中间还能顺手接待其他客人。所以同样的服务员数量Nginx能服务的客人数量翻几十倍。当然Nginx的事件驱动也有适用边界。它擅长处理I/O密集的任务比如静态文件读取、代理转发但如果后端业务逻辑本身非常耗时比如大量CPU计算瓶颈就不在Nginx而在后端应用这时Nginx能做的只是尽量把请求平滑地分发过去。2. 部署并跑起来常见安装方式的实操对比2.1 二进制包安装的适用场景我自己的习惯是测试环境用系统自带的二进制包生产环境用源码编译安装。二进制包安装最省事适合快速上手。在Ubuntu/Debian系列上sudo apt update sudo apt install nginx -y nginx -v systemctl start nginx systemctl enable nginx在CentOS/RHEL包括Rocky Linux、AlmaLinux 9这些新一代发行版上sudo yum install nginx -y # 或者 sudo dnf install nginx -y systemctl start nginx systemctl enable nginx用二进制包安装有个好处系统会自动处理依赖、配置文件路径、服务启动脚本。装完默认就能访问打开浏览器输入服务器IP就能看到欢迎页。日常维护也方便升级用apt upgrade或yum update直接搞定。但它也有坑系统源里的版本一般偏旧比如某些发行版带的Nginx可能还是1.18/1.20等老版本不支持一些新特性。另一个问题是官方源没有的部分模块比如rtmp流媒体模块、image-filter等装不了这时候就需要编译安装了。2.2 源码编译安装为什么值得学源码编译是进阶的第一道门槛也是我觉得每个Nginx使用者都应该掌握的操作。原因很实在版本最新可以自己选择。编译时可以自由启用/禁用模块按需定制。可以把SSL模块静态编进去避免升级OpenSSL后动态加载出问题。在纯内网环境没有外部源可用时只有源码编译这条路最可靠。编译前需要准备三个依赖PCRE正则表达式支持、OpenSSLSSL/TLS支持、zlibgzip压缩支持。关于PCRE我推荐从官网下载pcre-8.45源码包这个版本虽然出来很久了但和Nginx的兼容性非常稳定配套使用几乎不会出幺蛾子。编译流程三步走# 1. 解压源码并进入目录 wget http://nginx.org/download/nginx-1.26.0.tar.gz tar -zxvf nginx-1.26.0.tar.gz cd nginx-1.26.0 # 2. 配置编译参数 ./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_gzip_static_module \ --with-stream \ --with-pcre/opt/pcre-8.45 \ --with-openssl/opt/openssl \ --with-zlib/opt/zlib # 3. 编译并安装 make -j4 make install这里有几个容易忽略的细节--prefix决定了Nginx安装到哪个目录默认是/usr/local/nginx如果之后要用nginx -s reload管理最好在/etc/nginx里建一个软链或者把nginx二进制加到PATH里。--with-http_ssl_module一定要加否则后面配HTTPS会提示找不到ssl指令。--with-http_v2_module是HTTP/2支持现在主流浏览器都在用建议加上。纯内网环境比如aarch64服务器不上外网要提前把依赖源码包和Nginx源码包下载好内网机器上再解压编译。整个过程不需要联网这是它最大的优势。编译完启动/usr/local/nginx/sbin/nginx -t /usr/local/nginx/sbin/nginx看到nginx: ... is successful就说明配置文件没问题。2.3 Windows环境下的安装与注意事项Windows上装Nginx和Linux完全不是一回事但确实有很多人在用主要是本地开发调试。Windows版的Nginx不是以服务方式运行的。从官网下载zip包后解压到某个目录强烈建议不要解压到带空格的路径比如C:\Program Files然后打开命令行窗口运行cd C:\nginx-1.26.0 start nginx.exe启动后在任务管理器里能看到两个nginx.exe进程一个master一个worker。停止用nginx.exe -s stop重载配置用nginx.exe -s reload。Windows上我踩过两次坑在这里提醒大家第一路径分隔符问题。Nginx在Windows上解析路径时C:/dir/file和C:\dir\file都可能遇到问题特别是涉及autoindex和include时。我遇到过一次典型报错nginx: [emerg] createfile() d:/phpstudy_pro/www/admin2.com/nginx.htaccess failed排查了半天发现是配置文件里包含了一个并不存在的htaccess文件路径Nginx启动时尝试创建/读取失败。解决方法是检查include路径是否真实存在并且尽量用正斜杠。第二端口被占用。Windows上80端口经常被IIS或其他程序占用。处理方案二选一要么改Nginx的listen端口要么把占用程序停掉。查端口用netstat命令最直接。3. 核心配置拆解从静态文件到反向代理3.1 配置文件结构与核心指令Nginx的配置全部集中在主配置文件nginx.conf里无论你是用apt装的/etc/nginx/nginx.conf还是编译安装的/usr/local/nginx/conf/nginx.conf核心结构都一样。打开nginx.conf你会看到一层层嵌套的块我习惯把它拆成三个层级全局块最外层配置worker进程数、运行用户、错误日志位置等。比如worker_processes auto;、user www-data;。events块配置连接处理方式核心是worker_connections它定义了每个worker进程能同时打开的最大连接数。http块HTTP协议相关的所有配置里面可以包含多个server块每个server块代表一个虚拟主机。http块里最常用的几个指令我整理成了一张表指令作用建议值sendfile开启零拷贝发送文件ontcp_nopush数据包攒一批再发送提升吞吐onkeepalive_timeout客户端长连接超时30-65gzip开启响应压缩onclient_max_body_size限制客户端请求体积按业务定默认1m另外强烈建议开启include机制。apt安装的Nginx在http块末尾默认有include /etc/nginx/conf.d/*.conf;这样每个站点的配置可以单独立文件不会全堆在主配置里维护起来舒服很多。3.2 静态文件服务与autoindex在线文件浏览静态文件服务是Nginx最基础也最拿手的场景。核心就是一个server块加一个locationserver { listen 80; server_name example.com; root /var/www/example; index index.html; }关键概念是root和alias的区别。root会拼接完整的路径比如root /var/www;配合location /static/请求/static/a.png时实际找的是/var/www/static/a.png而alias会把location前缀替换掉alias /data/files/;配合location /files/请求/files/a.png时找的是/data/files/a.png。刚学的时候容易混记住一句话alias是“替换”root是“拼接”。除了托管静态站Nginx还能当简单的文件共享服务器这就是热词里老提到的“autoindex在线文件浏览”。在内网环境给同事共享大文件、搭建软件仓库这个功能非常实用。配置如下location /download/ { alias /data/softwares/; autoindex on; # 开启目录浏览 autoindex_exact_size off; # 显示可读大小而非精确字节 autoindex_localtime on; # 显示服务器本地时间 charset utf-8,gbk; # 解决中文文件名乱码 }开启后浏览器访问http://你的IP/download/就会列出一个文件列表点击即下载。注意一点autoindex on默认会列出服务器上这个目录下的所有文件如果目录里有机密文件一定要用location的访问控制或干脆不要开启。我见过有人不小心把整个/目录挂出来结果全网都能下他的系统文件相当危险。3.3 反向代理与负载均衡配置反向代理是Nginx生产环境里用得最多的功能。为什么要反向代理本质是为了解耦客户端只认识Nginx不知道真正的后端服务在哪Nginx把请求转发给内网里的Tomcat、Node.js、Python后端等再拿回响应返回给客户端。最简单的一个反向代理配置location /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; proxy_set_header X-Forwarded-Proto $scheme; }这行proxy_set_header X-Real-IP $remote_addr;很关键。因为经过了Nginx后端看到的TCP来源IP是Nginx自己的IP不做转发的化后端的真实客户端IP会全线丢失。做日志分析、风控、审计时这个头必须配上。当后端服务有很多个实例时就需要负载均衡了。Nginx的负载均衡用upstream块定义一组后端服务器upstream backend_pool { server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight2; server 192.168.1.12:8080 down; } location / { proxy_pass http://backend_pool; }Nginx支持几种负载均衡策略默认轮询每个请求轮流分配给不同后端weight权重按比例分配适合后端配置高低不一的集群ip_hash同一个IP的请求固定打到同一台后端解决session问题least_conn优先分给当前连接数最少的那台适合请求处理时间不均匀的业务。刚才那个配置里我加了一个server 192.168.1.12:8080 down;表示手动标记这台机下线Nginx不会把流量分给它。这个技巧在做灰度发布或后端单台重启时很实用不用改业务加个down就能临时摘除一台机器。3.4 多站点部署主域名与二级域名一台服务器部署多个网站是Nginx的看家本领核心就是配置多个server块用server_name区分域名。比如主域名example.com指向一个默认站点二级域名blog.example.com指向博客api.example.com指向后端接口server { listen 80; server_name example.com; root /var/www/main; } server { listen 80; server_name blog.example.com; root /var/www/blog; } server { listen 80; server_name api.example.com; location / { proxy_pass http://127.0.0.1:9000; } }server_name的匹配顺序也有讲究先做精确匹配再匹配以*开头的通配符再匹配以*结尾的通配符最后按正则匹配。如果一个请求没匹配上任何server_name会落到配置文件里排在最前面的那个server作为默认站点。建议在配置里显式加一个默认server块server { listen 80 default_server; return 444; }return 444是Nginx的一个特殊状态码表示直接断开连接不返回任何内容。这么干那些没绑定到你这台服务器上域名比如别人扫到的IP域名就会被挡在外面。多站点管理时我强烈推荐一个目录结构在/etc/nginx/下建sites-available放所有配置文件和sites-enabled放软链只有启用的才链过来。这是Debian系的做法用软链控制启停比把配置文件放在conf.d里直接生效要安全——写错配置不会瞬间暴雷。3.5 SSL证书配置与HTTP强制跳转HTTPS已经是标配了配Nginx的SSL其实不复杂但第一次见到一堆证书变量时确实会懵。先从证书服务商那里下载证书注意要下载Nginx类型的证书服务商一般会区分Apache、IIS、Nginx格式。这个坑真的常见很多人在Godaddy这类平台下载证书时随便下了一个Apache格式回来配置发现证书链加载失败。Nginx类型的证书通常有两部分证书链文件有的叫fullchain、有的叫bundle——包含网站证书和中间证书。私钥文件.key——生成CSR时产生的私钥一定不能泄露。nginx.conf里的配置server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/certs/example.com_fullchain.crt; ssl_certificate_key /etc/nginx/certs/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; root /var/www/example; }如果还想开启HTTP/2把listen改成listen 443 ssl http2;即可。HTTP/2能通过多路复用显著提升页面加载速度特别是资源多的站点效果明显。HTTP强制跳转到HTTPS的配置一般是单独一个server块server { listen 80; server_name example.com; return 301 https://$host$request_uri; }这样用户访问http://example.com/xxx浏览器会跳到https://example.com/xxx。我遇到过一种报错客户端访问HTTPS站点时返回no required ssl certificate was sent。这个错误有两层含义如果你是客户端说明服务端没有配置正确的证书如果你是自己配置的服务端那多半是证书文件或私钥路径写错了或者是证书链不完整浏览器/curl无法验证。排查方法是先用openssl s_client -connect 域名:443看看证书是否正常加载再检查nginx错误日志看有没有cannot load certificate或PEM_read_bio这类关键字。4. 进阶运维平滑升级、进程管理与高并发调优4.1 平滑升级的原理与操作线上Nginx升级最怕什么怕流量中断。老版本有安全漏洞必须升但又不能停机这时候就要用平滑升级。平滑升级的原理是利用Nginx的信号机制向master进程发送USR2信号让它启动一个全新的master和一组worker进程新旧两套进程同时存在新master接管配置和监听确认正常后给旧master发WINCH信号让它关闭旧的worker进程最后发QUIT信号让旧master退出。实际操作步骤# 1. 拿到旧版本的PID号 cat /usr/local/nginx/logs/nginx.pid # 2. 编译好新版本替换二进制文件 # 先备份旧二进制 cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old make -C /usr/local/nginx-1.26.0 make -C /usr/local/nginx-1.26.0 install # 3. 语法检查确认新配置没问题 /usr/local/nginx/sbin/nginx -t # 4. 向旧master进程发送USR2信号 kill -USR2 $(cat /usr/local/nginx/logs/nginx.pid) # 5. 等待片刻把新老进程都列出来确认新master已经起来 ps -ef | grep nginx # 6. 确认正常后关闭旧worker进程 kill -WINCH $(cat /usr/local/nginx/logs/nginx.pid) # 7. 观察日志确认没有请求出问题后杀掉旧master kill -QUIT $(cat /usr/local/nginx/logs/nginx.pid)如果发现新版本有问题可以回滚发HUP信号给旧master让它重新拉起worker进程然后发TERM信号给新master进程把它终止。整个过程流量几乎无感知这就是Nginx敢自称高可用的底气。4.2 进程管理与信号控制Nginx的进程控制全靠信号这个理解了之后就变得很简单。常用命令其实就是几条nginx -s stop # 立即停止 nginx -s quit # 优雅退出处理完当前请求再退出 nginx -s reload # 重载配置优雅重启worker nginx -s reopen # 重新打开日志文件日志切割常用其中reload是最高频的操作它的内部流程是master收到HUP信号后重新加载配置文件并校验如果配置有误则不执行校验通过后启动一组新的worker进程同时通知旧的worker把手上正在处理的请求处理完再退出。所以reload过程中服务不会中断正在进行的请求也不会被强杀。信号和对应动作的完整表格信号作用TERM/INT立即停止所有进程QUIT优雅停止处理完当前请求再退HUP重载配置启动新worker结束旧workerUSR1重新打开日志文件USR2平滑升级启动新masterWINCH优雅关闭旧worker进程实际操作中注意一点如果在sbin目录下找不到nginx命令比如用systemctl管理的情况可以直接用kill系列命令操作前提是拿到正确的master PID。千万别在没搞清楚PID的情况下kill -9所有nginx进程那样会让正在处理的请求全部断开还可能留下pid文件不一致的问题。4.3 高并发场景下的关键调优参数高并发的调优是个系统工程Nginx配置只是其中一层系统内核也要配合。我从Nginx配置和系统层面分别说。Nginx配置层有几个核心参数直接影响并发能力worker_processes auto; # 等于CPU核数 worker_rlimit_nofile 65535; # 每个worker可打开的文件描述符上限 events { worker_connections 10240; # 每个worker最多处理10240个连接 use epoll; # Linux上明确用epoll模型 } http { keepalive_timeout 30; # 长连接超时太短会频繁重连太长浪费连接 sendfile on; tcp_nopush on; tcp_nodelay on; gzip on; # 开启压缩 gzip_types text/plain text/css application/json application/javascript; }计算一下最大并发连接数worker_processes * worker_connections也就是CPU核数×10240。一台4核服务器理论并发就是40960个连接实际受带宽、内存、后端处理速度影响但已经很能打了。打开文件描述符限制这个参数特别容易被忽略。Nginx每个连接要占用一个文件描述符默认的ulimit -n是1024只够处理几百个并发连接。改法# 在 /etc/security/limits.conf 里追加 * soft nofile 65535 * hard nofile 65535内核层面还要注意两个参数。一个是net.ipv4.ip_local_port_range如果Nginx作为代理大量主动向后端发起连接本地端口不够用会直接报错一般建议扩大到1024到65535。另一个是net.core.somaxconn定义了系统层面最大监听队列长度Nginx的listen backlog超过它会被截断高并发下容易丢连接。压测验证推荐用wrk或者ab不需要太复杂的工具ab -n 100000 -c 1000 http://your-domain/看Requests per second和Time per request这两个指标对比调优前后的数据就能知道改动有没有效果。4.4 upstream keepalive与长连接复用很多人在配Nginx反向代理时忽略了一个细节Nginx默认向后端转发请求时每个请求都可能新建一条TCP连接。高并发下握手开销会吃掉大量资源响应变慢。解决办法是开启upstream keepalive长连接复用。具体配置如下upstream backend_pool { server 127.0.0.1:8080; keepalive 32; # 每个worker连接池里最多保留32条空闲连接 } location / { proxy_pass http://backend_pool; proxy_http_version 1.1; # 连接复用要求HTTP/1.1或以上 proxy_set_header Connection ; # 清空Connection头避免影响复用 }这里有个容易出错的点如果只加keepalive 32没有设置proxy_http_version 1.1和清空Connection头连接复用其实是失效的。因为默认的HTTP/1.0下每个请求结束后连接就关闭keepalive形同虚设。keepalive的值不是越大越好。这个值是每个worker进程的空闲连接池上限设得太大后端稍微一忙空闲连接就被占满新请求照旧新建连接设得太小频繁的握手抵消不了收益。经验值是从16到64之间先试试压测时观察后端的TIME_WAIT连接数来微调。我在反转Tomcat集群时用32实测握手开销下降明显后端TIME_WAIT从几千降到几百。5. 常见问题与排查技巧实录5.1 配置文件错误与路径问题Nginx配置容易出错好在它自带语法检查神器nginx -t。改完配置先执行nginx -t如果语法有问题会精确指出错误在哪一行。正常情况下输出nginx: configuration file /etc/nginx/nginx.conf test is successful。但有些错误不是语法层面的。比如热词里那个nginx: [emerg] createfile() d:/phpstudy_pro/www/admin2.com/nginx.htaccess failed报错的大白话是Nginx在启动时尝试访问一个叫nginx.htaccess的文件但路径不对或文件不存在。出现这种问题通常是配置文件里有include或auth_basic_user_file指向了一个不存在的位置或者目录权限不对。解决办法检查对应文件是否存在、路径中的盘符和分隔符是否被正确解析。Windows下尤其要小心解压路径、日志路径、站根目录都建议用正斜杠。还有一类常见错误是[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)意思是80端口被占了。排查用ss -lntp或netstat -lntp看谁在用是别的Nginx实例还是其他服务然后停掉冲突进程或者改port。5.2 SSL相关报错与证书问题SSL问题大概能占日常疑难杂症的三成。我把高频问题整理成了一份速查表问题现象大概率原因排查方向证书加载失败日志报PEM_read_bio证书格式不对或文件损坏用openssl命令看证书内容完整性浏览器提示不安全/不受信任中间证书缺失只上传了站点证书下载fullchain/bundle版本no required ssl certificate was sent服务端没配证书或配错或客户端TLS版本过低用openssl s_client核查更新客户端TLS页面跳转后提示Mixed Content页面里还有http的图片/脚本前端资源改成https或加CSP升级安全策略证书过期忘了续期加定时任务做自动续期提前告警no required ssl certificate was sent还有一个触发场景是客户端要求客户端证书mTLS但没发如果服务端配置了ssl_verify_client on而对端没有提供证书就会报这个错。排查时先看自己的服务端是不是开了双向认证别一上来就怀疑证书坏了。5.3 进程管理异常无法停止、端口占用、残留进程进程管理遇到的问题千奇百怪举几个我实际碰到过的一是怎么都停不掉Nginx。用nginx -s stop没反应查进程发现页面服务还在。这种情况一般是信号丢失或pid文件被改动。最稳妥的做法是先用ps -ef | grep nginx找到master PID然后kill -QUIT 主PID优雅停止不要上来就kill -9。二是端口明明显示没被占用但Nginx就是提示bind失败。这多半是IPv6和IPv4同时绑定的问题Nginx默认监听[::]:80和0.0.0.0:80两套其中一套被占就会报错。解决方法是listen明确指定IP比如listen 0.0.0.0:80;。三是reload后配置没有生效。先确认配置文件语法完整然后用nginx -T把所有生效配置打出来看看是不是include了别的文件把你的配置覆盖了。5.4 卸载与重装注意事项换发行版、升级大版本、从二进制包切到编译安装都可能涉及卸载Nginx。卸载这件事看着简单实际容易留尾巴。系统包安装的卸载# Debian/Ubuntu apt purge nginx nginx-common # CentOS/RHEL yum remove nginx编译安装的卸载就要小心了因为大部分编译安装没有make uninstall。需要手动清理rm -rf /usr/local/nginx rm -f /etc/init.d/nginx # 如果做过启动脚本 rm -f /etc/systemd/system/nginx.service # 如果注册过systemd服务 rm -rf /var/log/nginx # 日志 rm -rf /etc/nginx # 配置文件如果存在重装之前务必先备份两样东西nginx.conf和站点配置文件。我见过有人重装后手忙脚乱配SSL结果发现私钥没备份只能重新生成CSR去申请证书平白多等几个小时。重装时版本选择也有讲究。当前Nginx稳定版和主线版的差别主要在特性和bugfix生产环境建议选stable覆盖的版本。下载渠道推荐国内镜像站或者Nginx官网也可以直接用系统源装。如果是纯内网预先把rpm包或源码包传进去离线安装完全可行。最后说点我的个人体会用Nginx这么多年踩过的坑大多不是高级问题而是基础细节。我现在养成了三个雷打不动的习惯第一所有配置改动先nginx -t再reload绝不多留一秒错误配置在线第二每个站点独立一个配置文件用include管理主配置保持精简出了事定位快第三日志一定要认真看把access_log格式加上响应时间和上游处理时间排查性能问题全靠它逆推现场。如果你也是刚起步建议先把静态站点和反向代理跑通再依次加上SSL、负载均衡、缓存、长连接调优每加一个能力就压测验证一次。把基本功打扎实了Nginx会是你手里最趁手的那把工具。