新手第一次碰Nginx十个里有八个都倒在了安装这一步。不是yum源里找不到包就是编译的时候报缺少OpenSSL再要么就是明明启动成功了浏览器却怎么都访问不了。这篇文章要做的就是把“Linux系统下安装配置 Nginx”这条链路彻底讲透把我自己踩过的、帮别人排查过的那些坑按一条完整的路线梳理出来。文章会覆盖CentOS/RHEL系列和Ubuntu/Debian系列两套主流环境安装上会给包管理器与源码编译两条路径但重点放在源码编译——不是因为它一定更好而是因为只有亲手编译过一次你才能真正理解Nginx的目录结构、模块体系和配置加载机制之后遇到问题才知道往哪里查。为了模拟图文效果凡是关键命令的终端输出我都会用代码块贴出来你照着比对即可不用脑补。需要注意文章默认你有一台root权限的Linux机器至少2G内存。如果你用的是云服务器建议先给系统盘留出10G以上空间如果你在虚拟机里操作快照先打一个后面折腾坏了可以秒回滚。1. 动手之前先把你的Linux环境摸清楚很多人装Nginx失败不是因为命令敲错而是因为环境本身没搞清楚。同一套命令在CentOS 7上能跑通在Ubuntu 24上可能连包名都不一样所以在敲第一条安装命令之前先花两分钟确认三件事。1.1 确认发行版和系统架构先执行下面的命令看看你的系统到底是什么cat /etc/os-release uname -m第一行会告诉你发行版名称和版本号比如CentOS Stream 9、Ubuntu 24.04 LTS这类第二行是CPU架构x86_64表示64位Intel/AMD处理器aarch64表示ARM架构后面下载源码包和选择编译参数时都要用到。这里特别强调一下aarch64的情况。最近几年国产ARM服务器越来越多很多人照搬x86教程去编译结果在configure阶段或者make阶段莫名报错。其实Nginx源码对ARM架构支持得很完善问题通常出在依赖库上——某些老的PCRE版本在ARM上会有编译告警部分发行版的OpenSSL优化参数也不一样。我的做法是如果机器是aarch64优先用发行版自带的Nginx包或者选择较新的源码版本避免在老版本上浪费时间。1.2 检查历史残留和端口占用接着检查一下系统里是不是已经装过Nginx以及80端口是否被占用which nginx rpm -qa | grep nginx # CentOS系 dpkg -l | grep nginx # Ubuntu系 ss -lntp | grep :80如果which nginx有输出说明旧版本已经存在建议先用包管理器卸载干净再手动删除/etc/nginx或/usr/local/nginx目录防止新旧配置互相干扰这是个非常容易踩的隐性坑。80端口如果被占用需要看是被谁占的——可能是Apache、Caddy也可能是你自己跑的某个Java服务。Nginx默认监听80端口端口被占后启动会直接报错但报错信息比较隐蔽往下看第6章我会专门讲。1.3 规划安装路径这一步很少人重视但直接决定你后面维护的体验。我把两种方案摆出来包管理器安装命令装完配置文件在/etc/nginx/日志在/var/log/nginx/可执行文件在/usr/sbin/nginx文件散落在系统目录里但好处是权限、用户、systemd服务脚本统统帮你配好了。源码编译安装所有文件默认集中在/usr/local/nginx/下面结构一目了然卸载就是删目录升级就是换二进制。坏处是systemd服务脚本、日志轮转这些周边要自己配。我个人的倾向是如果你是要学习原理或者公司要求统一目录规范选源码编译如果你只想要一个能快速稳定运行的Web服务器包管理器就够了。这篇教程的重点放在源码编译因为它在Linux下的通用性最强而且能把Nginx的运行机制完整带出来。2. 两种主流安装路径包管理器 vs 源码编译我为什么推荐后者“能用yum install nginx解决的问题为什么要源码编译”这个问题我被问过很多次。答案取决于你的场景我先把两条路的真实差异说清楚。2.1 包管理器安装的真实面貌CentOS/RHEL系使用yum或dnfUbuntu/Debian系使用apt。优点是傻瓜化依赖关系自动处理装完就可以直接systemctl start nginx服务脚本、默认配置、日志目录全都现成。但有两个痛点需要注意。第一个痛点是版本滞后尤其是CentOS自带的Nginx版本可能停留在1.20甚至更老新版本里的HTTP/3支持、更好的OCSP性能、新的TLS默认配置全都享受不到。第二个痛点是模块定制受限如果你想加http_sub_module、stream模块或者第三方的ngx_cache_purge包管理器安装的Nginx很难做无损扩展因为默认二进制里没编译这些模块你又不能单独把模块塞进已有的二进制里。2.2 源码编译的价值与代价源码编译更像自己组装一台主机主板、CPU、内存条都是你亲自挑的。对Nginx来说你可以在编译时决定启用哪个模块、禁用哪个模块甚至可以针对当前机器的CPU型号启用更激进的优化指令集。代价也很实在第一编译时间大约5到15分钟取决于机器性能第二依赖库的-devel开发包必须自己装第三后续升级时要重新编译一次。对一个需要长期维护的线上服务来说这些成本换来的是可控性和可理解性我认为是划算的。2.3 我的选择建议对比项包管理器安装源码编译安装安装速度分钟级5-15分钟默认版本偏旧官网最新稳定版配置文件位置/etc/nginx/usr/local/nginx/conf日志位置/var/log/nginx/usr/local/nginx/logs模块定制受限于发行版编译参数完全自定义systemd服务自带需手动编写卸载方式包管理器统一管理删除安装目录即可我的结论是学习环境、生产环境只要你有时间和耐心都建议源码编译一遍。编译过程能让你知道Nginx依赖什么、模块怎么加载、目录在哪里这个认知在运维排障的时候价值极大。等你完整走完编译流程之后再回头看yum安装的那些东西你的理解深度会完全不同。3. 源码编译安装全流程实录含每一步为什么进入正题。这一章我会按实际执行顺序把源码编译安装Nginx的每一步完整走一遍并解释每个操作的含义。3.1 先装齐四类依赖库Nginx并不是“一个软件包解压就能跑”的程序编译它需要依赖GCC编译器、PCRE正则表达式库、zlib压缩库和OpenSSL加密库。这四个缺一不可缺了任何一个configure阶段就会直接报错。CentOS/RHEL系统执行yum install -y gcc gcc-c make autoconf automake pcre-devel zlib-devel openssl-develUbuntu/Debian系统执行apt update apt install -y build-essential libpcre3-dev zlib1g-dev libssl-dev注意CentOS系的包名是pcre-devel和openssl-develUbuntu系是libpcre3-dev和libssl-dev中间差了好几个字母复制错命令会直接提示找不到软件包。这里的-devel或-dev包是开发头文件编译C程序时必须在系统里能找到对应的头文件比如pcre.h、openssl/ssl.h只装运行库是不行的。3.2 下载并解压Nginx源码包去Nginx官网下载最新稳定版。整理本文时稳定版本是1.26.x系列你可以到 https://nginx.org/en/download.html 查看当前版本号。下载时注意区分Linux源码包和Windows包别下错。cd /usr/local/src wget https://nginx.org/download/nginx-1.26.1.tar.gz tar -zxvf nginx-1.26.1.tar.gz cd nginx-1.26.1这里我特意选了/usr/local/src作为源码存放目录这是Linux服务器的惯例目录专门放需要编译的源码包方便统一管理和清理。解压后进入目录你可以先用ls看一眼目录结构里面比较关键的几个东西是configure脚本编译前的配置工具、src目录所有源码、conf目录自带的基础配置模板。3.3 configure配置阶段的关键参数configure是源码安装最重要的环节可以把它理解成“装修前的设计图确认”——你要在哪个位置建房子、要不要落地窗、要不要装地暖这些在开工前就要定好。我常用的配置命令是./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_stub_status_module \ --with-http_sub_module \ --with-stream逐个说下含义--prefix/usr/local/nginx指定安装目录。Nginx编译后所有东西都会装到这里配置、日志、静态文件也都以这里为根路径。如果你后续要升级或卸载只需要操作这个目录不会有文件散落在系统各处。--with-http_ssl_module启用HTTPS支持。没有这个模块你无法配置SSL证书无法监听443端口这是线上环境必须启用的模块。--with-http_v2_module启用HTTP/2协议支持。HTTP/2在并发请求和传输效率上比HTTP/1.1有明显提升现在很多接口、静态资源服务器都在用。注意1.25.1版本之后Nginx官方调整了模块命名新版本用--with-http_v2_module更老一点的版本可能写作--with-http_v2_module如果你编译的老版本提示找不到就后退一步用--with-http_v2_module或者直接用--with-http_ssl_module就够了。--with-http_stub_status_module启用状态页模块。开启后访问/nginx_status可以看到当前连接数、请求数等基础指标排查性能问题非常有用。--with-http_sub_module响应内容替换模块边缘场景会用比如给静态页面插入一段JS或者替换成CDN域名。--with-stream启用TCP/UDP四层代理能力。Nginx不只是Web服务器还是优秀的负载均衡器这个模块是做数据库、Redis、MongoDB等TCP层负载均衡的基础。对虚拟化、容器化环境来说四层代理能力很实用。另外还有两个常见参数--with-debug用于启用调试日志在生产环境不建议开启--with-http_realip_module用于读取真实客户端IP当你的Nginx前面还有一层CDN或LB时就需要它。这些参数不需要一次全部塞进去用到哪类功能再编译哪类模块是合理的。configure执行后如果看到Configuration summary和Configuration successful字样说明配置检查通过。如果中途报错通常是缺开发包比如the HTTP rewrite module requires the PCRE library就是缺pcre-devel/usr/include/openssl/ssl.h: No such file就是缺openssl-devel回到3.1补装后重新运行configure即可。3.4 make编译与make install安装配置检查通过后开始编译make -j$(nproc)-j参数指定并行编译的进程数$(nproc)会自动获取当前机器的CPU核心数比如8核机器就是make -j8能明显缩短编译时间。如果编译过程中出现error不要慌把最后几行错误信息拉到最上面看真正的原因绝大多数和头文件缺失、语法版本不兼容有关。编译完成后执行安装make install安装完成后看一眼产物目录ls -l /usr/local/nginx/你会看到四个子目录conf配置文件目录、html默认静态页面目录里面是index.html和50x.html、logs日志目录包括error.log和access.log、sbin可执行文件目录nginx二进制就在这里面。这个目录结构就是Nginx源码安装的“干净”优势所在。3.5 验证安装并建立全局命令先验证nginx二进制是否可用/usr/local/nginx/sbin/nginx -v /usr/local/nginx/sbin/nginx -V小写的-v只输出版本号大写的-V会列出完整的编译参数和模块信息。执行后你应该会看到类似下面的输出nginx version: nginx/1.26.1 built by gcc 8.5.0 20210514 (Red Hat 8.5.0) (GCC) configure arguments: --prefix/usr/local/nginx --with-http_ssl_module ...为了之后敲命令方便我习惯建立一个软链接把nginx加入系统PATHln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx之后直接敲nginx就能执行不用再输一长串路径。如果你有洁癖不想污染系统目录也可以只在/etc/profile.d/里添加PATH环境变量但我个人觉得软链更直白也方便后续写systemd脚本时引用。4. 把Nginx跑起来之前先读懂它的核心配置骨架很多人装完Nginx就急着启动启动完发现一切正常但配置什么意思完全不知道。等你需要修改端口、添加域名、配置HTTPS时就只能复制粘贴人家的配置片段出了问题毫无头绪。所以我在启动前先花一章把nginx.conf这本“说明书”拆开讲明白。4.1 nginx.conf的整体结构与作用域源码安装的配置主文件是/usr/local/nginx/conf/nginx.conf。Nginx配置遵循严格的层级结构大类可以分成四个层级main全局块整个配置文件的最外层设置Nginx进程本身比如运行用户、worker进程数、错误日志路径。events事件块设置连接处理模型比如每个worker进程能同时维持的最大连接数。httpHTTP块所有Web服务功能都在这里配置包括MIME类型、日志格式、gzip压缩以及server子块。server虚拟主机块和location匹配块http块内部每定义一个server就是一台虚拟主机可以独立监听端口、绑定域名location进一步匹配URI路径配置不同的访问规则。可以把这个结构想象成一家公司main是老板events是行政人事http是业务部门server是具体项目组location是项目组里的具体岗位。指令写在哪个层级就作用于哪个范围。4.2 main区与events区关键项打开ngin.conf开头几行就是main区。最值得关注的是这几项user nginx;指定worker进程运行的系统用户。如果你是源码安装这条默认被注释了意味着Nginx会以root身份运行worker进程这在高危环境下是不推荐的。我习惯创建一个低权限用户user nobody;或者自己新建一个nginx用户再指定。worker_processes auto;worker进程数量。建议设置为auto让Nginx自动根据CPU核心数启动对应数目的worker。设少了浪费CPU设多了反而增加上下文切换开销。error_log logs/error.log notice;错误日志路径和级别。注意这里的路径是相对--prefix的也就是/usr/local/nginx/logs/error.log。pid logs/nginx.pid;PID文件路径后面写systemd服务时要用。events块里的核心是worker_connections 1024;。它表示每个worker进程可以同时保持1024个连接。理论上最大并发连接数约等于worker_processes × worker_connections但实际还会受文件描述符限制所以线上调优时通常还要用ulimit -n配合提高文件描述符上限。4.3 http区关键指令与最小可用serverhttp块是整个配置的重头戏。这里我不贴官方一大长串默认配置而是给一个最小可用的完整配置样例你可以直接复制然后逐行理解http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; access_log logs/access.log main; gzip on; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } } }include mime.types;引入MIME映射表。这个文件会和ngin.conf一起生成它告诉Nginx不同后缀的文件应该用哪个Content-Type返回比如.html对应text/html.css对应text/css。sendfile on;启用高效的文件发送模式。简单说就是让Nginx直接从内核态发送文件给客户端减少用户态拷贝静态文件性能提升明显。keepalive_timeout 65;客户端连接保持超时时间。设置为65秒可以降低频繁建连的开销但建议根据业务调整不要盲目增大。server块里的listen 80表示监听80端口server_name localhost表示匹配本地访问。location /匹配所有请求root html表示网站根目录指向/usr/local/nginx/htmlindex index.html index.htm指定默认首页文件名。4.4 配置文件正确性检查与生效指令改动配置之后第一步不是重启而是先检查语法nginx -t如果语法有误Nginx会明确提示错误发生在第几行、哪个指令有问题。比如nginx: [emerg] unknown directive xxx in /usr/local/nginx/conf/nginx.conf:12看到这样的输出多半是某个指令拼写错误或者该指令需要特定模块才支持。在修改配置之前我还强烈建议你先备份cp /usr/local/nginx/conf/nginx.conf /usr/local/nginx/conf/nginx.conf.bak这个习惯在两三周以后会救你一命——当你改了一堆配置、发现Nginx起不来时备份文件就是你的后悔药。语法检查通过后执行nginx -s reload优雅重载配置。reload和restart最大的区别是reload不会中断现有请求会先起一套新配置的worker进程再逐步替换掉旧worker这是生产环境推荐的操作方式。5. 注册systemd服务开机自启和优雅重载的完整闭环源码编译安装的一个不便之处是它不会自动注册systemd服务。这意味着你重启机器后Nginx不会自己起来也没法用systemctl start nginx来管理。解决这个问题需要手动写一个service文件。5.1 为什么源码安装没有自带service脚本使用yum或apt安装时软件包会把初始化脚本和systemd unit文件一并装好卸载时也会自动清理。源码安装则是“从零到一”全都自己摆平所以我们需要手动补上这一步。5.2 手写nginx.service文件的每个字段含义创建服务文件vim /etc/systemd/system/nginx.service写入如下内容[Unit] DescriptionThe NGINX HTTP and reverse proxy server Afternetwork.target [Service] Typeforking PIDFile/usr/local/nginx/logs/nginx.pid ExecStartPre/usr/local/nginx/sbin/nginx -t ExecStart/usr/local/nginx/sbin/nginx ExecReload/usr/local/nginx/sbin/nginx -s reload ExecStop/usr/local/nginx/sbin/nginx -s quit PrivateTmptrue [Install] WantedBymulti-user.target逐个拆解一下[Unit]里的Afternetwork.target表示Nginx要在网络服务就绪后再启动否则可能出现网络未初始化就监听端口的问题。Typeforking是Nginx、Apache这类“启动后fork子进程并让主进程后台运行”的程序的标准配置。需要配合PIDFile来让systemd通过PID文件判断服务是否成功启动。ExecStartPre比较特殊它会在每次启动服务前先执行nginx -t做语法检查万一配置有错会直接中止启动流程不会让Nginx带病启动。ExecReload指定重载命令ExecStop指定停止命令。注意这里用-s quit而不是-s stopquit会让Nginx优雅地处理完当前请求后再退出stop是立即终止生产环境用quit更安全。PrivateTmptrue给服务单独分配/tmp空间隔离更安全这是很多新手写unit文件时容易漏掉的安全加固项。写完后需要重新加载systemd配置systemctl daemon-reload systemctl enable nginx systemctl start nginx systemctl status nginxenable会创建开机自启动的符号链接start立即启动服务。如果你是第一次执行ExecStartPre会先检查配置配置没问题才真正启动。看到Active: active (running)就是启动成功。5.3 常用运维命令速查注册了systemd之后日常运维就变得很顺手。这里列几个高频命令systemctl start nginx # 启动 systemctl stop nginx # 停止 systemctl reload nginx # 优雅重载配置 systemctl restart nginx # 重启 systemctl status nginx # 查看状态 systemctl enable nginx # 设置开机自启 systemctl disable nginx # 取消开机自启另外强烈建议你在每次发布新配置前手动执行一次nginx -t再加systemctl reload nginx。虽然ExecStartPre已经帮你把关了但手工检查能让你在reload前多一道确认尤其在生产环境谨慎一点不过分。6. 安装配置过程中最常见的四个坑按排查链路走一遍这一章是全文含金量最高的一部分。我把这几年在Nginx安装配置上遇到的高频故障按真实的排查链路写出来。不是直接给答案而是带着你一步步定位这样以后你遇到类似问题才不会被表象迷惑。6.1 坑一nginx启动报错但你看不到任何输出很多新手执行nginx命令后发现终端没有任何提示但ps -ef | grep nginx又看不到进程或者系统提示nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)。这种“没输出”或“启动即失败”的情况排查链路第一步是看错误日志tail -f /usr/local/nginx/logs/error.log日志会非常直白地告诉你问题比如端口被占用[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)找到占用者ss -lntp | grep :80如果是其他Web服务在占用要么停掉对方要么把Nginx的listen端口改成8080或其他端口。如果你不想查日志也可以用前台调试模式运行Nginxnginx -g daemon off;这种模式会把Nginx的调试信息直接打印到当前终端报什么错一目了然。排查完记得用CtrlC结束再以正常daemon方式启动。6.2 坑二curl 127.0.0.1有响应浏览器就是打不开这个问题是“排障链路”的经典案例。本机访问正常说明Nginx进程没问题配置没问题外部不通说明流量被挡在某个环节。我建议按下面的链路一步步排查curl 127.0.0.1 # 第一步本机访问验证Nginx进程本身 curl 你的公网IP # 第二步验证本机网络和监听 systemctl status firewalld # 第三步检查本机防火墙 getenforce # 第四步检查SELinux状态如果是云服务器第五步去云控制台检查安全组。安全组是最容易忽略的一环我在帮朋友排障时遇到不止一次Nginx配置没问题、防火墙也放行了但安全组没放行80端口外部就是访问不了。CentOS 7以上系统如果开启了firewalld需要放行HTTP服务firewall-cmd --add-servicehttp --permanent firewall-cmd --reload如果系统开启了SELinux且getenforce返回Enforcing那还要放行Nginx网络连接setsebool -P httpd_can_network_connect 1这里-P参数表示永久生效。有一些教程会让你直接setenforce 0临时关闭SELinux这只建议在测试环境临时验证时使用生产环境千万别这么干安全防线不能随便撤。6.3 坑三./configure阶段缺少依赖包这个问题的报错样式非常典型checking for PCRE library ... not found ./configure: error: the HTTP rewrite module requires the PCRE library.如果你用的是CentOS执行yum install -y pcre-devel如果是Ubuntuapt install -y libpcre3-dev同理还有zlib和OpenSSL的报错找对应的-devel包补上即可。这里有个进阶经验有时候./configure报错提示缺了某个库但你已经装过了那多半是32位/64位头文件路径不统一或者安装的库版本过旧。可以用下面命令验证头文件是否真实存在find /usr/include -name pcre.h find /usr/include/openssl -name ssl.h如果头文件在但Nginx还是找不到可以在configure时手动指定路径比如--with-cc-opt-I/usr/local/include这种情况非常少见但如果你遇到了知道排查方向就不慌。6.4 坑四nginx -s reload提示PID文件不存在执行reload时报错[error] open() /usr/local/nginx/logs/nginx.pid failed (2: No such file or directory)这种情况通常发生在你手动停止了Nginx之后或者在systemd服务配置里的PIDFile路径和nginx实际写PID的路径不一致。排障链路是这样先确认Nginx是否在运行如果没运行先启动再reload如果运行了但还是报PID文件缺失就用-c参数显式指定配置文件nginx -c /usr/local/nginx/conf/nginx.conf或者检查nginx.conf里的pid指令到底写的是什么路径。源码编译默认是logs/nginx.pid也就是/usr/local/nginx/logs/nginx.pid但如果你改过--prefix这个路径会跟着变。systemd脚本里的PIDFile必须和实际路径完全一致否则systemd状态会显示异常虽然Nginx本身可能跑得好好的。7. 从一个静态站点到一个反向代理装完Nginx之后最值得做的事安装配置本身不是目的让Nginx真正干活才是。最后这一章我带你做几个最基础、也最高频的场景配置。这些配置不仅现在能用以后扩展到HTTPS、负载均衡思路都是一脉相承的。7.1 静态站点配置前面4.3那个最小配置已经能跑静态站点了。把网站文件丢到/usr/local/nginx/html目录下访问http://你的IP就能看到首页。这里要提醒几个细节。第一目录权限要注意nginx运行用户或nobody用户必须对HTML目录有读权限否则会出现403 Forbidden。第二如果你要挂一个新的静态站点不要直接改根server而是在http块里新增一个server块server { listen 80; server_name www.example.com; root /data/www/example; index index.html; location / { try_files $uri $uri/ 404; } }try_files $uri $uri/ 404这行的意思是先找请求的文件找不到就找目录还是找不到就返回404。很多人挂完新站点访问404大多是因为忘了写这行或者目录路径不对。7.2 用Nginx做目录文件共享如果你只想临时把一个目录下的文件分享给团队下载Nginx的autoindex模块可以秒开一个文件列表页比搭FTP省事得多location /download/ { alias /data/share/; autoindex on; autoindex_exact_size off; autoindex_localtime on; }autoindex on开启目录列表autoindex_exact_size off让文件大小显示为更易读的KB/MB单位autoindex_localtime on让文件时间显示为服务器本地时间而不是UTC。这个功能在团队内网非常实用但注意如果目录是公网开放的一定要加访问认证或者放到内网环境否则就是裸奔。7.3 反向代理基础与超时参数Nginx最核心的生产价值之一就是反向代理。最典型的用法是把外部请求转发给内网某个Java、Node.js或Python服务server { listen 80; server_name api.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_connect_timeout 60s; proxy_read_timeout 60s; proxy_send_timeout 60s; } }这里最重要的是三个header设置。Host头如果不透传后端服务可能无法识别你的域名X-Real-IP和X-Forwarded-For是让后端拿到真实客户端IP否则后端看到的全是Nginx的地址日志和风控全废了。超时参数也值得多说一句。proxy_connect_timeout是Nginx与后端建立连接的超时时间proxy_read_timeout是两次读操作之间的超时时间不是整个响应的总超时。新手经常把read_timeout理解成“接口最慢不能超过60秒”然后就发现一些耗时长但正常的请求被莫名其妙断开。如果你用的是proxy_mirror这种镜像流量模块来做流量复制测试超时逻辑也是同一套思路别只盯着默认值60秒很多超时报警其实是这里没调明白。7.4 平滑升级的思路最后提一个很多人迟早要面对的问题Nginx大版本升级。nginx -s reload只能重载配置不能替换二进制。真正的平滑升级需要利用信号机制思路是编译新版本Nginx到新目录备份旧二进制用新二进制替换旧文件然后向旧master进程发送USR2让它启动新master进程再用WINCH优雅退出旧worker。这套操作比较进阶我不建议初学阶段就上生产做实验。你可以先在测试机上跑一遍流程熟悉后就知道整个生命周期是怎么回事。真到生产升级时还有更高阶的方案是直接用容器镜像来管理Nginx那种场景下“平滑升级”就有更现代化的玩法。我实测下来的感受是Nginx的学习曲线其实非常平缓但最劝退新手的就是安装配置这一关。只要你亲手编译过一次把目录结构、配置文件、systemd注册这几个基础建设打好底子后面遇到的绝大多数Nginx问题你都能凭第一反应判断出应该去看哪个日志、哪个配置。 Linux下Nginx源码编译安装全流程：避坑指南与配置实践
新手第一次碰Nginx十个里有八个都倒在了安装这一步。不是yum源里找不到包就是编译的时候报缺少OpenSSL再要么就是明明启动成功了浏览器却怎么都访问不了。这篇文章要做的就是把“Linux系统下安装配置 Nginx”这条链路彻底讲透把我自己踩过的、帮别人排查过的那些坑按一条完整的路线梳理出来。文章会覆盖CentOS/RHEL系列和Ubuntu/Debian系列两套主流环境安装上会给包管理器与源码编译两条路径但重点放在源码编译——不是因为它一定更好而是因为只有亲手编译过一次你才能真正理解Nginx的目录结构、模块体系和配置加载机制之后遇到问题才知道往哪里查。为了模拟图文效果凡是关键命令的终端输出我都会用代码块贴出来你照着比对即可不用脑补。需要注意文章默认你有一台root权限的Linux机器至少2G内存。如果你用的是云服务器建议先给系统盘留出10G以上空间如果你在虚拟机里操作快照先打一个后面折腾坏了可以秒回滚。1. 动手之前先把你的Linux环境摸清楚很多人装Nginx失败不是因为命令敲错而是因为环境本身没搞清楚。同一套命令在CentOS 7上能跑通在Ubuntu 24上可能连包名都不一样所以在敲第一条安装命令之前先花两分钟确认三件事。1.1 确认发行版和系统架构先执行下面的命令看看你的系统到底是什么cat /etc/os-release uname -m第一行会告诉你发行版名称和版本号比如CentOS Stream 9、Ubuntu 24.04 LTS这类第二行是CPU架构x86_64表示64位Intel/AMD处理器aarch64表示ARM架构后面下载源码包和选择编译参数时都要用到。这里特别强调一下aarch64的情况。最近几年国产ARM服务器越来越多很多人照搬x86教程去编译结果在configure阶段或者make阶段莫名报错。其实Nginx源码对ARM架构支持得很完善问题通常出在依赖库上——某些老的PCRE版本在ARM上会有编译告警部分发行版的OpenSSL优化参数也不一样。我的做法是如果机器是aarch64优先用发行版自带的Nginx包或者选择较新的源码版本避免在老版本上浪费时间。1.2 检查历史残留和端口占用接着检查一下系统里是不是已经装过Nginx以及80端口是否被占用which nginx rpm -qa | grep nginx # CentOS系 dpkg -l | grep nginx # Ubuntu系 ss -lntp | grep :80如果which nginx有输出说明旧版本已经存在建议先用包管理器卸载干净再手动删除/etc/nginx或/usr/local/nginx目录防止新旧配置互相干扰这是个非常容易踩的隐性坑。80端口如果被占用需要看是被谁占的——可能是Apache、Caddy也可能是你自己跑的某个Java服务。Nginx默认监听80端口端口被占后启动会直接报错但报错信息比较隐蔽往下看第6章我会专门讲。1.3 规划安装路径这一步很少人重视但直接决定你后面维护的体验。我把两种方案摆出来包管理器安装命令装完配置文件在/etc/nginx/日志在/var/log/nginx/可执行文件在/usr/sbin/nginx文件散落在系统目录里但好处是权限、用户、systemd服务脚本统统帮你配好了。源码编译安装所有文件默认集中在/usr/local/nginx/下面结构一目了然卸载就是删目录升级就是换二进制。坏处是systemd服务脚本、日志轮转这些周边要自己配。我个人的倾向是如果你是要学习原理或者公司要求统一目录规范选源码编译如果你只想要一个能快速稳定运行的Web服务器包管理器就够了。这篇教程的重点放在源码编译因为它在Linux下的通用性最强而且能把Nginx的运行机制完整带出来。2. 两种主流安装路径包管理器 vs 源码编译我为什么推荐后者“能用yum install nginx解决的问题为什么要源码编译”这个问题我被问过很多次。答案取决于你的场景我先把两条路的真实差异说清楚。2.1 包管理器安装的真实面貌CentOS/RHEL系使用yum或dnfUbuntu/Debian系使用apt。优点是傻瓜化依赖关系自动处理装完就可以直接systemctl start nginx服务脚本、默认配置、日志目录全都现成。但有两个痛点需要注意。第一个痛点是版本滞后尤其是CentOS自带的Nginx版本可能停留在1.20甚至更老新版本里的HTTP/3支持、更好的OCSP性能、新的TLS默认配置全都享受不到。第二个痛点是模块定制受限如果你想加http_sub_module、stream模块或者第三方的ngx_cache_purge包管理器安装的Nginx很难做无损扩展因为默认二进制里没编译这些模块你又不能单独把模块塞进已有的二进制里。2.2 源码编译的价值与代价源码编译更像自己组装一台主机主板、CPU、内存条都是你亲自挑的。对Nginx来说你可以在编译时决定启用哪个模块、禁用哪个模块甚至可以针对当前机器的CPU型号启用更激进的优化指令集。代价也很实在第一编译时间大约5到15分钟取决于机器性能第二依赖库的-devel开发包必须自己装第三后续升级时要重新编译一次。对一个需要长期维护的线上服务来说这些成本换来的是可控性和可理解性我认为是划算的。2.3 我的选择建议对比项包管理器安装源码编译安装安装速度分钟级5-15分钟默认版本偏旧官网最新稳定版配置文件位置/etc/nginx/usr/local/nginx/conf日志位置/var/log/nginx/usr/local/nginx/logs模块定制受限于发行版编译参数完全自定义systemd服务自带需手动编写卸载方式包管理器统一管理删除安装目录即可我的结论是学习环境、生产环境只要你有时间和耐心都建议源码编译一遍。编译过程能让你知道Nginx依赖什么、模块怎么加载、目录在哪里这个认知在运维排障的时候价值极大。等你完整走完编译流程之后再回头看yum安装的那些东西你的理解深度会完全不同。3. 源码编译安装全流程实录含每一步为什么进入正题。这一章我会按实际执行顺序把源码编译安装Nginx的每一步完整走一遍并解释每个操作的含义。3.1 先装齐四类依赖库Nginx并不是“一个软件包解压就能跑”的程序编译它需要依赖GCC编译器、PCRE正则表达式库、zlib压缩库和OpenSSL加密库。这四个缺一不可缺了任何一个configure阶段就会直接报错。CentOS/RHEL系统执行yum install -y gcc gcc-c make autoconf automake pcre-devel zlib-devel openssl-develUbuntu/Debian系统执行apt update apt install -y build-essential libpcre3-dev zlib1g-dev libssl-dev注意CentOS系的包名是pcre-devel和openssl-develUbuntu系是libpcre3-dev和libssl-dev中间差了好几个字母复制错命令会直接提示找不到软件包。这里的-devel或-dev包是开发头文件编译C程序时必须在系统里能找到对应的头文件比如pcre.h、openssl/ssl.h只装运行库是不行的。3.2 下载并解压Nginx源码包去Nginx官网下载最新稳定版。整理本文时稳定版本是1.26.x系列你可以到 https://nginx.org/en/download.html 查看当前版本号。下载时注意区分Linux源码包和Windows包别下错。cd /usr/local/src wget https://nginx.org/download/nginx-1.26.1.tar.gz tar -zxvf nginx-1.26.1.tar.gz cd nginx-1.26.1这里我特意选了/usr/local/src作为源码存放目录这是Linux服务器的惯例目录专门放需要编译的源码包方便统一管理和清理。解压后进入目录你可以先用ls看一眼目录结构里面比较关键的几个东西是configure脚本编译前的配置工具、src目录所有源码、conf目录自带的基础配置模板。3.3 configure配置阶段的关键参数configure是源码安装最重要的环节可以把它理解成“装修前的设计图确认”——你要在哪个位置建房子、要不要落地窗、要不要装地暖这些在开工前就要定好。我常用的配置命令是./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_stub_status_module \ --with-http_sub_module \ --with-stream逐个说下含义--prefix/usr/local/nginx指定安装目录。Nginx编译后所有东西都会装到这里配置、日志、静态文件也都以这里为根路径。如果你后续要升级或卸载只需要操作这个目录不会有文件散落在系统各处。--with-http_ssl_module启用HTTPS支持。没有这个模块你无法配置SSL证书无法监听443端口这是线上环境必须启用的模块。--with-http_v2_module启用HTTP/2协议支持。HTTP/2在并发请求和传输效率上比HTTP/1.1有明显提升现在很多接口、静态资源服务器都在用。注意1.25.1版本之后Nginx官方调整了模块命名新版本用--with-http_v2_module更老一点的版本可能写作--with-http_v2_module如果你编译的老版本提示找不到就后退一步用--with-http_v2_module或者直接用--with-http_ssl_module就够了。--with-http_stub_status_module启用状态页模块。开启后访问/nginx_status可以看到当前连接数、请求数等基础指标排查性能问题非常有用。--with-http_sub_module响应内容替换模块边缘场景会用比如给静态页面插入一段JS或者替换成CDN域名。--with-stream启用TCP/UDP四层代理能力。Nginx不只是Web服务器还是优秀的负载均衡器这个模块是做数据库、Redis、MongoDB等TCP层负载均衡的基础。对虚拟化、容器化环境来说四层代理能力很实用。另外还有两个常见参数--with-debug用于启用调试日志在生产环境不建议开启--with-http_realip_module用于读取真实客户端IP当你的Nginx前面还有一层CDN或LB时就需要它。这些参数不需要一次全部塞进去用到哪类功能再编译哪类模块是合理的。configure执行后如果看到Configuration summary和Configuration successful字样说明配置检查通过。如果中途报错通常是缺开发包比如the HTTP rewrite module requires the PCRE library就是缺pcre-devel/usr/include/openssl/ssl.h: No such file就是缺openssl-devel回到3.1补装后重新运行configure即可。3.4 make编译与make install安装配置检查通过后开始编译make -j$(nproc)-j参数指定并行编译的进程数$(nproc)会自动获取当前机器的CPU核心数比如8核机器就是make -j8能明显缩短编译时间。如果编译过程中出现error不要慌把最后几行错误信息拉到最上面看真正的原因绝大多数和头文件缺失、语法版本不兼容有关。编译完成后执行安装make install安装完成后看一眼产物目录ls -l /usr/local/nginx/你会看到四个子目录conf配置文件目录、html默认静态页面目录里面是index.html和50x.html、logs日志目录包括error.log和access.log、sbin可执行文件目录nginx二进制就在这里面。这个目录结构就是Nginx源码安装的“干净”优势所在。3.5 验证安装并建立全局命令先验证nginx二进制是否可用/usr/local/nginx/sbin/nginx -v /usr/local/nginx/sbin/nginx -V小写的-v只输出版本号大写的-V会列出完整的编译参数和模块信息。执行后你应该会看到类似下面的输出nginx version: nginx/1.26.1 built by gcc 8.5.0 20210514 (Red Hat 8.5.0) (GCC) configure arguments: --prefix/usr/local/nginx --with-http_ssl_module ...为了之后敲命令方便我习惯建立一个软链接把nginx加入系统PATHln -s /usr/local/nginx/sbin/nginx /usr/sbin/nginx之后直接敲nginx就能执行不用再输一长串路径。如果你有洁癖不想污染系统目录也可以只在/etc/profile.d/里添加PATH环境变量但我个人觉得软链更直白也方便后续写systemd脚本时引用。4. 把Nginx跑起来之前先读懂它的核心配置骨架很多人装完Nginx就急着启动启动完发现一切正常但配置什么意思完全不知道。等你需要修改端口、添加域名、配置HTTPS时就只能复制粘贴人家的配置片段出了问题毫无头绪。所以我在启动前先花一章把nginx.conf这本“说明书”拆开讲明白。4.1 nginx.conf的整体结构与作用域源码安装的配置主文件是/usr/local/nginx/conf/nginx.conf。Nginx配置遵循严格的层级结构大类可以分成四个层级main全局块整个配置文件的最外层设置Nginx进程本身比如运行用户、worker进程数、错误日志路径。events事件块设置连接处理模型比如每个worker进程能同时维持的最大连接数。httpHTTP块所有Web服务功能都在这里配置包括MIME类型、日志格式、gzip压缩以及server子块。server虚拟主机块和location匹配块http块内部每定义一个server就是一台虚拟主机可以独立监听端口、绑定域名location进一步匹配URI路径配置不同的访问规则。可以把这个结构想象成一家公司main是老板events是行政人事http是业务部门server是具体项目组location是项目组里的具体岗位。指令写在哪个层级就作用于哪个范围。4.2 main区与events区关键项打开ngin.conf开头几行就是main区。最值得关注的是这几项user nginx;指定worker进程运行的系统用户。如果你是源码安装这条默认被注释了意味着Nginx会以root身份运行worker进程这在高危环境下是不推荐的。我习惯创建一个低权限用户user nobody;或者自己新建一个nginx用户再指定。worker_processes auto;worker进程数量。建议设置为auto让Nginx自动根据CPU核心数启动对应数目的worker。设少了浪费CPU设多了反而增加上下文切换开销。error_log logs/error.log notice;错误日志路径和级别。注意这里的路径是相对--prefix的也就是/usr/local/nginx/logs/error.log。pid logs/nginx.pid;PID文件路径后面写systemd服务时要用。events块里的核心是worker_connections 1024;。它表示每个worker进程可以同时保持1024个连接。理论上最大并发连接数约等于worker_processes × worker_connections但实际还会受文件描述符限制所以线上调优时通常还要用ulimit -n配合提高文件描述符上限。4.3 http区关键指令与最小可用serverhttp块是整个配置的重头戏。这里我不贴官方一大长串默认配置而是给一个最小可用的完整配置样例你可以直接复制然后逐行理解http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for; access_log logs/access.log main; gzip on; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } } }include mime.types;引入MIME映射表。这个文件会和ngin.conf一起生成它告诉Nginx不同后缀的文件应该用哪个Content-Type返回比如.html对应text/html.css对应text/css。sendfile on;启用高效的文件发送模式。简单说就是让Nginx直接从内核态发送文件给客户端减少用户态拷贝静态文件性能提升明显。keepalive_timeout 65;客户端连接保持超时时间。设置为65秒可以降低频繁建连的开销但建议根据业务调整不要盲目增大。server块里的listen 80表示监听80端口server_name localhost表示匹配本地访问。location /匹配所有请求root html表示网站根目录指向/usr/local/nginx/htmlindex index.html index.htm指定默认首页文件名。4.4 配置文件正确性检查与生效指令改动配置之后第一步不是重启而是先检查语法nginx -t如果语法有误Nginx会明确提示错误发生在第几行、哪个指令有问题。比如nginx: [emerg] unknown directive xxx in /usr/local/nginx/conf/nginx.conf:12看到这样的输出多半是某个指令拼写错误或者该指令需要特定模块才支持。在修改配置之前我还强烈建议你先备份cp /usr/local/nginx/conf/nginx.conf /usr/local/nginx/conf/nginx.conf.bak这个习惯在两三周以后会救你一命——当你改了一堆配置、发现Nginx起不来时备份文件就是你的后悔药。语法检查通过后执行nginx -s reload优雅重载配置。reload和restart最大的区别是reload不会中断现有请求会先起一套新配置的worker进程再逐步替换掉旧worker这是生产环境推荐的操作方式。5. 注册systemd服务开机自启和优雅重载的完整闭环源码编译安装的一个不便之处是它不会自动注册systemd服务。这意味着你重启机器后Nginx不会自己起来也没法用systemctl start nginx来管理。解决这个问题需要手动写一个service文件。5.1 为什么源码安装没有自带service脚本使用yum或apt安装时软件包会把初始化脚本和systemd unit文件一并装好卸载时也会自动清理。源码安装则是“从零到一”全都自己摆平所以我们需要手动补上这一步。5.2 手写nginx.service文件的每个字段含义创建服务文件vim /etc/systemd/system/nginx.service写入如下内容[Unit] DescriptionThe NGINX HTTP and reverse proxy server Afternetwork.target [Service] Typeforking PIDFile/usr/local/nginx/logs/nginx.pid ExecStartPre/usr/local/nginx/sbin/nginx -t ExecStart/usr/local/nginx/sbin/nginx ExecReload/usr/local/nginx/sbin/nginx -s reload ExecStop/usr/local/nginx/sbin/nginx -s quit PrivateTmptrue [Install] WantedBymulti-user.target逐个拆解一下[Unit]里的Afternetwork.target表示Nginx要在网络服务就绪后再启动否则可能出现网络未初始化就监听端口的问题。Typeforking是Nginx、Apache这类“启动后fork子进程并让主进程后台运行”的程序的标准配置。需要配合PIDFile来让systemd通过PID文件判断服务是否成功启动。ExecStartPre比较特殊它会在每次启动服务前先执行nginx -t做语法检查万一配置有错会直接中止启动流程不会让Nginx带病启动。ExecReload指定重载命令ExecStop指定停止命令。注意这里用-s quit而不是-s stopquit会让Nginx优雅地处理完当前请求后再退出stop是立即终止生产环境用quit更安全。PrivateTmptrue给服务单独分配/tmp空间隔离更安全这是很多新手写unit文件时容易漏掉的安全加固项。写完后需要重新加载systemd配置systemctl daemon-reload systemctl enable nginx systemctl start nginx systemctl status nginxenable会创建开机自启动的符号链接start立即启动服务。如果你是第一次执行ExecStartPre会先检查配置配置没问题才真正启动。看到Active: active (running)就是启动成功。5.3 常用运维命令速查注册了systemd之后日常运维就变得很顺手。这里列几个高频命令systemctl start nginx # 启动 systemctl stop nginx # 停止 systemctl reload nginx # 优雅重载配置 systemctl restart nginx # 重启 systemctl status nginx # 查看状态 systemctl enable nginx # 设置开机自启 systemctl disable nginx # 取消开机自启另外强烈建议你在每次发布新配置前手动执行一次nginx -t再加systemctl reload nginx。虽然ExecStartPre已经帮你把关了但手工检查能让你在reload前多一道确认尤其在生产环境谨慎一点不过分。6. 安装配置过程中最常见的四个坑按排查链路走一遍这一章是全文含金量最高的一部分。我把这几年在Nginx安装配置上遇到的高频故障按真实的排查链路写出来。不是直接给答案而是带着你一步步定位这样以后你遇到类似问题才不会被表象迷惑。6.1 坑一nginx启动报错但你看不到任何输出很多新手执行nginx命令后发现终端没有任何提示但ps -ef | grep nginx又看不到进程或者系统提示nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)。这种“没输出”或“启动即失败”的情况排查链路第一步是看错误日志tail -f /usr/local/nginx/logs/error.log日志会非常直白地告诉你问题比如端口被占用[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)找到占用者ss -lntp | grep :80如果是其他Web服务在占用要么停掉对方要么把Nginx的listen端口改成8080或其他端口。如果你不想查日志也可以用前台调试模式运行Nginxnginx -g daemon off;这种模式会把Nginx的调试信息直接打印到当前终端报什么错一目了然。排查完记得用CtrlC结束再以正常daemon方式启动。6.2 坑二curl 127.0.0.1有响应浏览器就是打不开这个问题是“排障链路”的经典案例。本机访问正常说明Nginx进程没问题配置没问题外部不通说明流量被挡在某个环节。我建议按下面的链路一步步排查curl 127.0.0.1 # 第一步本机访问验证Nginx进程本身 curl 你的公网IP # 第二步验证本机网络和监听 systemctl status firewalld # 第三步检查本机防火墙 getenforce # 第四步检查SELinux状态如果是云服务器第五步去云控制台检查安全组。安全组是最容易忽略的一环我在帮朋友排障时遇到不止一次Nginx配置没问题、防火墙也放行了但安全组没放行80端口外部就是访问不了。CentOS 7以上系统如果开启了firewalld需要放行HTTP服务firewall-cmd --add-servicehttp --permanent firewall-cmd --reload如果系统开启了SELinux且getenforce返回Enforcing那还要放行Nginx网络连接setsebool -P httpd_can_network_connect 1这里-P参数表示永久生效。有一些教程会让你直接setenforce 0临时关闭SELinux这只建议在测试环境临时验证时使用生产环境千万别这么干安全防线不能随便撤。6.3 坑三./configure阶段缺少依赖包这个问题的报错样式非常典型checking for PCRE library ... not found ./configure: error: the HTTP rewrite module requires the PCRE library.如果你用的是CentOS执行yum install -y pcre-devel如果是Ubuntuapt install -y libpcre3-dev同理还有zlib和OpenSSL的报错找对应的-devel包补上即可。这里有个进阶经验有时候./configure报错提示缺了某个库但你已经装过了那多半是32位/64位头文件路径不统一或者安装的库版本过旧。可以用下面命令验证头文件是否真实存在find /usr/include -name pcre.h find /usr/include/openssl -name ssl.h如果头文件在但Nginx还是找不到可以在configure时手动指定路径比如--with-cc-opt-I/usr/local/include这种情况非常少见但如果你遇到了知道排查方向就不慌。6.4 坑四nginx -s reload提示PID文件不存在执行reload时报错[error] open() /usr/local/nginx/logs/nginx.pid failed (2: No such file or directory)这种情况通常发生在你手动停止了Nginx之后或者在systemd服务配置里的PIDFile路径和nginx实际写PID的路径不一致。排障链路是这样先确认Nginx是否在运行如果没运行先启动再reload如果运行了但还是报PID文件缺失就用-c参数显式指定配置文件nginx -c /usr/local/nginx/conf/nginx.conf或者检查nginx.conf里的pid指令到底写的是什么路径。源码编译默认是logs/nginx.pid也就是/usr/local/nginx/logs/nginx.pid但如果你改过--prefix这个路径会跟着变。systemd脚本里的PIDFile必须和实际路径完全一致否则systemd状态会显示异常虽然Nginx本身可能跑得好好的。7. 从一个静态站点到一个反向代理装完Nginx之后最值得做的事安装配置本身不是目的让Nginx真正干活才是。最后这一章我带你做几个最基础、也最高频的场景配置。这些配置不仅现在能用以后扩展到HTTPS、负载均衡思路都是一脉相承的。7.1 静态站点配置前面4.3那个最小配置已经能跑静态站点了。把网站文件丢到/usr/local/nginx/html目录下访问http://你的IP就能看到首页。这里要提醒几个细节。第一目录权限要注意nginx运行用户或nobody用户必须对HTML目录有读权限否则会出现403 Forbidden。第二如果你要挂一个新的静态站点不要直接改根server而是在http块里新增一个server块server { listen 80; server_name www.example.com; root /data/www/example; index index.html; location / { try_files $uri $uri/ 404; } }try_files $uri $uri/ 404这行的意思是先找请求的文件找不到就找目录还是找不到就返回404。很多人挂完新站点访问404大多是因为忘了写这行或者目录路径不对。7.2 用Nginx做目录文件共享如果你只想临时把一个目录下的文件分享给团队下载Nginx的autoindex模块可以秒开一个文件列表页比搭FTP省事得多location /download/ { alias /data/share/; autoindex on; autoindex_exact_size off; autoindex_localtime on; }autoindex on开启目录列表autoindex_exact_size off让文件大小显示为更易读的KB/MB单位autoindex_localtime on让文件时间显示为服务器本地时间而不是UTC。这个功能在团队内网非常实用但注意如果目录是公网开放的一定要加访问认证或者放到内网环境否则就是裸奔。7.3 反向代理基础与超时参数Nginx最核心的生产价值之一就是反向代理。最典型的用法是把外部请求转发给内网某个Java、Node.js或Python服务server { listen 80; server_name api.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_connect_timeout 60s; proxy_read_timeout 60s; proxy_send_timeout 60s; } }这里最重要的是三个header设置。Host头如果不透传后端服务可能无法识别你的域名X-Real-IP和X-Forwarded-For是让后端拿到真实客户端IP否则后端看到的全是Nginx的地址日志和风控全废了。超时参数也值得多说一句。proxy_connect_timeout是Nginx与后端建立连接的超时时间proxy_read_timeout是两次读操作之间的超时时间不是整个响应的总超时。新手经常把read_timeout理解成“接口最慢不能超过60秒”然后就发现一些耗时长但正常的请求被莫名其妙断开。如果你用的是proxy_mirror这种镜像流量模块来做流量复制测试超时逻辑也是同一套思路别只盯着默认值60秒很多超时报警其实是这里没调明白。7.4 平滑升级的思路最后提一个很多人迟早要面对的问题Nginx大版本升级。nginx -s reload只能重载配置不能替换二进制。真正的平滑升级需要利用信号机制思路是编译新版本Nginx到新目录备份旧二进制用新二进制替换旧文件然后向旧master进程发送USR2让它启动新master进程再用WINCH优雅退出旧worker。这套操作比较进阶我不建议初学阶段就上生产做实验。你可以先在测试机上跑一遍流程熟悉后就知道整个生命周期是怎么回事。真到生产升级时还有更高阶的方案是直接用容器镜像来管理Nginx那种场景下“平滑升级”就有更现代化的玩法。我实测下来的感受是Nginx的学习曲线其实非常平缓但最劝退新手的就是安装配置这一关。只要你亲手编译过一次把目录结构、配置文件、systemd注册这几个基础建设打好底子后面遇到的绝大多数Nginx问题你都能凭第一反应判断出应该去看哪个日志、哪个配置。