前两天我整理了一套 Nginx 的学习笔记把从基础概念到生产环境部署再到面试追问的高频考点全部过了一遍。说实话Nginx 这个东西属于典型的“看着简单用深了全是细节”网上教程一大堆但大多数要么只讲某个零散配置要么直接甩出一长篇官方文档翻译真正能把“为什么这么配”讲明白的内容少之又少。这套 14 小时的课程我反复调整过结构核心思路就一句话——让你用最短的时间把 Nginx 从“会用”变成“懂用”。无论你是刚接触运维的后端开发、准备跳槽的面试党还是被领导丢来一个“帮我把项目部署一下”任务的苦命人这套内容都够用。整个课程覆盖了 Nginx 的核心功能、配置文件逐行拆解、反向代理、负载均衡、多项目部署、日志管理、性能调优以及高频面试题而且所有演示都基于 2026 年最新的稳定版本。我写这篇总结的初衷也很简单帮你把这 14 小时的精华提炼成一份可以随时查阅的文字版地图遇到问题能快速定位而不是从头再看一遍视频。1. 课程整体设计14 小时学 Nginx时间和精力怎么分配如果你打算零基础入门 Nginx最怕的就是“东看一眼西看一眼”式学习。今天刷到一篇反向代理的文章明天看到一个负载均衡的配置每个片段都懂但真到了自己上手配置一台服务器时照样一脸懵。所以这套课程设计的第一原则是搭骨架而不是堆知识点。1.1 整套课程按什么逻辑编排14 个小时听起来很长但如果拆开来看其实是非常典型的四阶段递进阶段一约 2 小时搞懂 Nginx 是什么、能干什么完成源码编译安装、目录结构认识、启动停止重载这些基本操作。阶段二约 4 小时死磕配置文件把 nginx.conf 里的全局块、events 块、http 块、server 块、location 块全部拆开揉碎搞清楚每一条指令的作用。阶段三约 5 小时实战高频场景包括反向代理、负载均衡、静态资源服务、HTTPS 配置、多项目部署、日志切割。阶段四约 3 小时面向面试和排错汇总遇到的高频报错、面试追问、性能调优经验。这个顺序是我实际带人总结出来的经验先会装、再会配、然后会玩、最后会讲。很多人一上来就研究负载均衡算法结果连配置文件在哪一层生效都没搞明白这种学习方式非常容易泄气。1.2 为什么建议你跟着场景学而不是跟着功能学我发现一个很有意思的现象同样一个 proxy_pass 指令背下来很容易但一旦遇到“为什么我的反向代理后端拿到了内网 IP”“为什么我的 WebSocket 连接总是断”“为什么我改了配置 reload 了还是不生效”这类具体问题时背指令的人往往瞬间卡壳。所以整套课程在实战部分全部采用“场景驱动”的讲法。每个场景都包括需求描述、配置实现、验证方法、常见错误四个环节。比如部署一个 Vue3 项目不只会教你写一个 root 指向 dist 目录还会告诉你 history 路由模式下为什么要配 try_files为什么图片能加载但刷新页面就 404。这种学习方式可能比单纯刷文档慢一点但记忆留存率高非常多。我带过的学员里凡是采用场景驱动学习的基本在两周内就能独立处理中小型项目的 Nginx 配置任务。2. 核心功能拆解反向代理、负载均衡与静态资源服务的底层逻辑Nginx 被人用得最多的三个功能就是反向代理、负载均衡和静态资源服务。这三个功能也是最容易在面试中被问到细节的部分所以这一块我们必须聊透。2.1 反向代理一个转发动作背后的三件小事很多人理解反向代理就是“Nginx 把请求转发给后端服务器”。这个理解没有错但到实际配置时有三个细节不注意就会出问题。第一proxy_pass 后面是否带 URI 会影响转发路径。这是 Nginx 里一个非常经典的坑。简单来说如果 proxy_pass 后面不带路径也就是只有 http://后端地址那么 Nginx 会把原始请求的完整 URI 原样转发给后端如果带了路径比如 http://后端地址/那么 location 匹配到的部分会被替换掉。我在课程里专门给了一个对比实验location /api/ { proxy_pass http://backend; }和location /api/ { proxy_pass http://backend/; }这两条配置请求/api/user时后端收到的路径完全不一样。前者后端收到/api/user后者后端收到/user。第二转发请求头是反向代理的“隐形工作”。后端服务经常需要拿到客户端的真实 IP 和协议类型但 Nginx 转发请求时默认 Host 头会被改写客户端 IP 也会变成 Nginx 所在服务器的 IP。所以生产环境的反向代理配置里几乎必然要带上这几行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;这里很多人问的五元组问题也一并说清楚Nginx 转发时TCP 层面的源 IP 确实会被替换成 Nginx 自己的 IP所以后端无法直接通过 socket 拿到客户端真实 IP。解决办法就是通过 X-Forwarded-For 这类 HTTP 头把原始信息带过去后端再解析这个头拿到真实地址。第三代理超时配置直接决定系统的稳定性。默认情况下proxy_read_timeout 是 60 秒如果你的后端接口本身就需要跑 2 分钟那不做任何配置的情况下Nginx 会在 60 秒后主动断开连接。课程里给的建议是不要盲目调大超时时间先搞清楚业务接口的真实耗时再针对性配置。2.2 负载均衡不只是轮询那么简单负载均衡是 Nginx 最亮眼的功能之一很多面试题也喜欢在这一块做文章。Nginx 默认支持的负载均衡算法包括轮询round-robin、加权轮询、ip_hash、least_conn这些在官方文档里都有说明但真正到选型时很多人的思路是模糊的。我个人的经验是如果后端服务是无状态的优先用默认的轮询配合 weight 参数做容量分配如果有会话保持需求可以考虑 ip_hash但要注意它会把同一 IP 的请求都打到同一台机器上一旦这台机器宕机这部分用户的会话会全部失效如果后端机器的配置差异比较大least_conn 往往能获得更均衡的负载效果。配置本身很简单一个典型的 upstream 块长这样upstream backend_servers { least_conn; server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight1; keepalive 32; }很多教程讲到这里就结束了但我建议你再往下想一层Nginx 做负载均衡时和 LVS 这类四层负载均衡有什么区别答案是 LVS 工作在内核态转发效率更高但没法像 Nginx 那样做七层的精细化路由。理解了这个区别你就不难回答面试官的追问“为什么你这个场景用 Nginx 而不是 LVS”2.3 静态资源服务与浏览器缓存的配合Nginx 处理静态资源的性能远高于 Tomcat 这类应用服务器所以很多项目的部署方案都是“动静分离”动态请求转发给后端静态资源直接由 Nginx 返回。这一块的实操其实不复杂核心是 root 与 alias 的区分和缓存头配置。root 和 alias 的区别是另一个高频面试题root 配置的是根目录Nginx 会把完整 URI 拼在 root 后面去找文件alias 配置的是别名它会把 location 匹配到的路径替换掉。举个例子location /static/ { root /var/www/html/; }请求/static/a.png时Nginx 找的是/var/www/html/static/a.png如果改成location /static/ { alias /var/www/html/; }那找的就是/var/www/html/a.png。这个区别不搞懂部署项目时经常会出现“404 找不到文件”的诡异问题。缓存配置方面我常用的一段配置也分享出来location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 30d; add_header Cache-Control public, immutable; }这样配置之后浏览器会对这些静态资源做 30 天的强缓存有效降低服务器压力。但要注意如果你的前端项目是每次构建都会生成带哈希的文件名那这个配置非常合适如果文件名不变但内容经常变那缓存时间过长会导致用户看到旧版本这种情况需要配合构建工具的 hash 命名策略。3. 配置文件详解每个指令放对位置问题就少一半Nginx 的配置文件看起来结构清晰但真正动手时很多人会犯一个低级错误把指令写错了层级。比如把 proxy_pass 写在 http 块里或者把 listen 指令写在 location 块里这些都是不生效甚至直接报错的。3.1 配置文件的层级结构究竟是怎么划分的Nginx 的配置文件采用严格的层级结构从外到内依次是main 全局块配置运行 Nginx 服务器本身的全局属性比如 worker 进程数、PID 文件路径。events 块配置 Nginx 与用户的网络连接模型比如 worker_connections、use epoll。http 块配置 HTTP 服务器相关的公共属性比如 include、default_type、日志格式。server 块配置虚拟主机的相关属性每个 server 块相当于一台“虚拟服务器”。location 块配置 URI 匹配规则和对应处理方式。初学者最容易犯的错误就是把 server 级别的指令放到 http 块里。比如有同学想改端口直接把 listen 8080 写到了 http 块顶层然后 reload 时报错。理解层级划分后这种问题基本不会出现。3.2 高频指令的生效范围与优先级这里我整理了一个高频指令生效范围的速查表方便你部署项目时对照指令可写层级作用说明常见误用场景worker_processesmain设置 worker 进程数通常设为 CPU 核心数误写到 http 块导致不生效worker_connectionsevents单进程最大连接数不配置时默认值偏小高并发下出现 502includehttp引入外部配置文件误写成绝对路径导致启动失败listenserver设置监听端口和地址误写到 location 块中server_nameserver配置域名匹配不配置时默认接受任意 Hostroot/aliashttp/server/location设置站点根目录/别名root 和 alias 混用导致路径错误proxy_passlocation/server/http设置代理转发地址带不带 URI 的差异try_fileslocation/server按顺序检查文件是否存在Vue history 路由下不配置导致刷新 404这个表建议你保存下来配置前先对照一下。我在课程里反复强调Nginx 配置文件本身并不复杂绝大多数问题都出在“放错层级”和“指令误解”这两件事上。3.3 一个典型的单页面应用SPA部署配置长什么样以目前最流行的 Vue3 项目为例很多人问“win 服务器怎么部署 Vue3”其实部署方式跨平台是一致的关键就两点一是把构建产物放到 Nginx 能访问到的目录二是让 history 路由下的所有路径都回退到 index.html。server { listen 80; server_name example.com; root /data/www/my-vue-project/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ { expires 7d; } }这个配置的核心在于 try_files。当用户访问某个前端路由比如/user/123时Nginx 首先尝试按这个 URI 找真实文件找不到就回退到/index.html由前端框架接管路由渲染。如果不加这一行Vue3 的 history 模式部署后刷新页面就会 404这也是前端部署最常见的坑之一。4. 环境部署与日常运维那些你不一定知道但一定会遇到的细节很多人在网上搜索“Nginx 未找到命令”“Nginx 的日志路径”“修改端口号”这类问题说明部署和运维是整个学习过程中最容易让人卡住的环节。这一节我把高频问题集中梳理一遍。4.1 安装方式怎么选源码编译、yum/dnf 与 DockerNginx 的安装方式主要分为三类通过系统包管理器安装、通过源码编译安装、通过 Docker 容器运行。这三类方式各有适用场景。包管理器安装yum install nginx / apt install nginx是最快的方式适合刚入门时快速验证和学习但缺点是版本往往不是最新的且缺少一些自定义模块。源码编译安装适合需要定制模块比如添加第三方模块或追求最新稳定版的场景但编译过程相对复杂特别是离线环境下需要手动下载大量依赖。Docker 部署则是最符合现在微服务架构的方式配置隔离性好迁移方便推荐在服务器资源充足的情况下优先考虑。如果你在 CentOS 8 或类似系统上做离线安装我的经验是提前准备好依赖整合包Nginx 编译依赖 gcc、pcre-devel、zlib-devel、openssl-devel 这几样缺一不可。在不能联网的环境中可以找一台同版本系统的联网机器用yumdownloader --resolve把依赖 RPM 包全部下载下来再拷到离线机器上批量安装。4.2 端口修改、日志路径与开机自启修改 Nginx 端口是再基础不过的操作但 Windows Server 2016 上很多同学会找不到配置文件在哪。其实无论什么系统修改端口的核心就是找到 nginx.conf在 server 块里改 listen 指令。常见路径是Linux 下/etc/nginx/nginx.conf或源码编译的/usr/local/nginx/conf/nginx.confWindows 下就是解压目录里的conf/nginx.conf。改完端口后记得先执行nginx -t校验配置语法是否正确再执行 reload避免改错导致服务中断。日志路径也是老生常谈默认访问日志在logs/access.log错误日志在logs/error.log。如果使用系统包管理器安装一般会在/var/log/nginx/下。日志目录是可以自定义的我一般会单独建一个/var/log/nginx/目录并且按天切割。手动切割日志很简单可以用 cronolog 或写一个 shell 脚本定时重命名日志文件。一个常用的做法是#!/bin/bash # 每日零点切割日志 YESTERDAY$(date -d yesterday %Y%m%d) mv /var/log/nginx/access.log /var/log/nginx/access_${YESTERDAY}.log kill -USR1 $(cat /var/run/nginx.pid)之所以要发送 USR1 信号给 master 进程是因为 Nginx 会重新打开日志文件而不是继续往旧文件里写。这个细节如果不了解很多人在手动切割日志后发现日志不写入新文件就是这个原因。开机自启在 Linux 下建议采用 systemd 服务管理创建/etc/systemd/system/nginx.service文件然后执行systemctl enable nginx即可。Windows 下可以直接把 nginx.exe 做成计划任务或者使用 WinSW 这类工具将其注册为 Windows 服务。4.3 Nginx 可视化配置工具值不值得用近两年 Nginx 可视化管理工具越来越火比如 NginxWebUI、Nginx Proxy Manager 这类开源项目。它们的核心价值是把配置文件的操作变成表单填写降低了上手门槛。我的观点是学习和排错阶段不建议过度依赖可视化工具因为在界面上点出来的配置你并不知道它最终写到了配置文件的哪个位置、为什么要这样写一旦出了诡异的问题排查会更困难。但如果是团队协作、频繁新增站点、需要给非专业运维人员使用可视化工具的效率优势非常明显。课程里我会演示 NginxWebUI 的完整部署过程但强调一点用工具生成配置后一定要打开最终生成的配置文件读一遍搞清楚每一行的含义。这样即便工具出了问题你也可以手工修复。4.4 Nginx 漏洞与版本升级的常规检查安全方面Nginx 偶尔也会爆出 CVE 漏洞比如前阵子大家比较关注的 F5 Nginx 相关漏洞例如 CVE-2025-1695。这类问题的应对策略并不复杂核心是两点关注官方安全公告以及建立版本升级的习惯。不要长期停留在某个旧版本上“稳定运行”现代 Web 环境下安全补丁的滞后带来的风险远大于升级带来的兼容性成本。在异构环境部署上aarch64 架构比如麒麟 V11、树莓派现在越来越常见好在 Nginx 官方源码对 aarch64 支持非常成熟直接下载对应架构的源码编译即可。需要注意的是在 ARM 机器上编译前最好确认一下 openssl 版本部分老版本 openssl 在 ARM 上的性能表现不太理想。5. 面试高频考点与实战追问不背题讲逻辑最后这部分是专门为准备面试的同学准备的。Nginx 的面试题其实高度集中翻来覆去就是那么几个方向但面试官越来越不喜欢“背答案”的候选人他们更在意你能不能把原理讲清楚。5.1 基础题这些内容必须张口就来高频基础题包括Nginx 和 Apache 的区别、正向代理和反向代理的区别、Nginx 的 master-worker 进程模型、Nginx 为什么高并发、什么是惊群问题以及如何解决。这里我展开讲一下 master-worker 进程模型因为 80% 的候选人只能说个皮毛。Nginx 启动后会有一个 master 进程和多个 worker 进程。master 进程不处理具体的请求它负责读取配置、管理 worker 进程的生命周期、接收外部信号。真正干活的是 worker 进程每个 worker 进程都能独立处理并发连接它们之间通过共享内存和锁机制协调资源比如 upstream 的限流计数器、共享 session 等。关于惊群问题简单说就是多个 worker 进程同时监听同一个 socket当新连接到来时所有 worker 都被唤醒但最终只有一个能成功 accept其他进程的唤醒纯属浪费。Nginx 通过 accept_mutexaccept 互斥锁来解决这个问题在开启 accept_mutex 时只有拿到锁的 worker 进程才能 accept 新连接其他进程继续处理已有连接。这也是 Nginx 每进程单线程却能支撑高并发的关键设计之一。5.2 进阶题基于场景的追问才是拉分项面试中真正拉开差距的往往是基于场景的追问。比如下面几个如何做 Nginx 的高可用这种题通常可以从 keepalived 虚拟 IP 的角度回答但更好的回答是结合云平台负载均衡产品对比体现出你对方案的全局理解。再比如如何排查 Nginx 返回 502、504、499 这类状态码的问题排查思路是502 通常是后端服务不可用、连接被拒或处理超时504 是 Nginx 作为网关等待后端响应超时499 则是客户端在 Nginx 等待后端期间主动断开了连接。这个题不是考你背状态码含义而是考你有没有真实的排错经验。正确回答方式是先看 error.log 里对应的 upstream 日志再看后端的访问日志和慢查询日志定位是网络问题、后端处理慢还是连接数被打满。再比如如果你的 Nginx 突然 CPU 飙升你会怎么排查经验型候选人会回答先用 top 看是哪个进程消耗 CPU再用nginx -t检查配置再开 access.log 看是不是有恶意请求再排查是否发生了回源风暴。这类场景题没有标准答案但如果你只回答“重启 Nginx”或者“加机器”面试官基本会判定为没有实战经验。5.3 面试准备的一点额外建议我在课程里带面试环节时经常对学员说一句话不要把 Nginx 当题库背而是要把它当成你负责的 Web 系统的“前门”。面试官真正想确认的是你把这个前门管理到了什么程度是只会开锁还是知道什么时候该换锁、什么时候该加窗户、什么时候该装监控所以准备面试的时候建议你在自己的电脑或云端服务器上把课程里的每个实验都亲手做一遍。面试前把自己项目里用到的 Nginx 配置逐行梳理一遍思考每个配置的目的是什么、去掉会有什么后果。做到这个程度Nginx 相关的面试题对你来说基本就是送分题了。6. 写在最后这套 14 小时课程我建议你怎么吃透如果你决定跟着这套课程学我个人的建议是不要用“看视频”的方式去学而是用“做项目”的方式去学。每看完一个场景的讲解立刻在服务器上把同样的配置敲一遍然后故意改错一个地方观察报错信息。把错误当作学习材料这是我从带人的经验里总结出来最有效的路径。最后分享一个我实际使用中的小技巧给自己建一个 nginx 配置的专属笔记库不用多复杂就是一个带搜索功能的 markdown 文档。每遇到一个坑、每解决一个问题花三分钟记下来配上一句“为什么会出现这个问题”的解释。坚持几个月之后你就会发现面试时脑海里浮现的不是背过的题目而是一个个你真正处理过的真实案例。这套 14 小时的课程给了你完整的知识地图但把地图变成肌肉记忆还需要你自己多走几遍。 Nginx核心配置与生产部署实战：从反向代理到性能调优全覆盖
前两天我整理了一套 Nginx 的学习笔记把从基础概念到生产环境部署再到面试追问的高频考点全部过了一遍。说实话Nginx 这个东西属于典型的“看着简单用深了全是细节”网上教程一大堆但大多数要么只讲某个零散配置要么直接甩出一长篇官方文档翻译真正能把“为什么这么配”讲明白的内容少之又少。这套 14 小时的课程我反复调整过结构核心思路就一句话——让你用最短的时间把 Nginx 从“会用”变成“懂用”。无论你是刚接触运维的后端开发、准备跳槽的面试党还是被领导丢来一个“帮我把项目部署一下”任务的苦命人这套内容都够用。整个课程覆盖了 Nginx 的核心功能、配置文件逐行拆解、反向代理、负载均衡、多项目部署、日志管理、性能调优以及高频面试题而且所有演示都基于 2026 年最新的稳定版本。我写这篇总结的初衷也很简单帮你把这 14 小时的精华提炼成一份可以随时查阅的文字版地图遇到问题能快速定位而不是从头再看一遍视频。1. 课程整体设计14 小时学 Nginx时间和精力怎么分配如果你打算零基础入门 Nginx最怕的就是“东看一眼西看一眼”式学习。今天刷到一篇反向代理的文章明天看到一个负载均衡的配置每个片段都懂但真到了自己上手配置一台服务器时照样一脸懵。所以这套课程设计的第一原则是搭骨架而不是堆知识点。1.1 整套课程按什么逻辑编排14 个小时听起来很长但如果拆开来看其实是非常典型的四阶段递进阶段一约 2 小时搞懂 Nginx 是什么、能干什么完成源码编译安装、目录结构认识、启动停止重载这些基本操作。阶段二约 4 小时死磕配置文件把 nginx.conf 里的全局块、events 块、http 块、server 块、location 块全部拆开揉碎搞清楚每一条指令的作用。阶段三约 5 小时实战高频场景包括反向代理、负载均衡、静态资源服务、HTTPS 配置、多项目部署、日志切割。阶段四约 3 小时面向面试和排错汇总遇到的高频报错、面试追问、性能调优经验。这个顺序是我实际带人总结出来的经验先会装、再会配、然后会玩、最后会讲。很多人一上来就研究负载均衡算法结果连配置文件在哪一层生效都没搞明白这种学习方式非常容易泄气。1.2 为什么建议你跟着场景学而不是跟着功能学我发现一个很有意思的现象同样一个 proxy_pass 指令背下来很容易但一旦遇到“为什么我的反向代理后端拿到了内网 IP”“为什么我的 WebSocket 连接总是断”“为什么我改了配置 reload 了还是不生效”这类具体问题时背指令的人往往瞬间卡壳。所以整套课程在实战部分全部采用“场景驱动”的讲法。每个场景都包括需求描述、配置实现、验证方法、常见错误四个环节。比如部署一个 Vue3 项目不只会教你写一个 root 指向 dist 目录还会告诉你 history 路由模式下为什么要配 try_files为什么图片能加载但刷新页面就 404。这种学习方式可能比单纯刷文档慢一点但记忆留存率高非常多。我带过的学员里凡是采用场景驱动学习的基本在两周内就能独立处理中小型项目的 Nginx 配置任务。2. 核心功能拆解反向代理、负载均衡与静态资源服务的底层逻辑Nginx 被人用得最多的三个功能就是反向代理、负载均衡和静态资源服务。这三个功能也是最容易在面试中被问到细节的部分所以这一块我们必须聊透。2.1 反向代理一个转发动作背后的三件小事很多人理解反向代理就是“Nginx 把请求转发给后端服务器”。这个理解没有错但到实际配置时有三个细节不注意就会出问题。第一proxy_pass 后面是否带 URI 会影响转发路径。这是 Nginx 里一个非常经典的坑。简单来说如果 proxy_pass 后面不带路径也就是只有 http://后端地址那么 Nginx 会把原始请求的完整 URI 原样转发给后端如果带了路径比如 http://后端地址/那么 location 匹配到的部分会被替换掉。我在课程里专门给了一个对比实验location /api/ { proxy_pass http://backend; }和location /api/ { proxy_pass http://backend/; }这两条配置请求/api/user时后端收到的路径完全不一样。前者后端收到/api/user后者后端收到/user。第二转发请求头是反向代理的“隐形工作”。后端服务经常需要拿到客户端的真实 IP 和协议类型但 Nginx 转发请求时默认 Host 头会被改写客户端 IP 也会变成 Nginx 所在服务器的 IP。所以生产环境的反向代理配置里几乎必然要带上这几行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;这里很多人问的五元组问题也一并说清楚Nginx 转发时TCP 层面的源 IP 确实会被替换成 Nginx 自己的 IP所以后端无法直接通过 socket 拿到客户端真实 IP。解决办法就是通过 X-Forwarded-For 这类 HTTP 头把原始信息带过去后端再解析这个头拿到真实地址。第三代理超时配置直接决定系统的稳定性。默认情况下proxy_read_timeout 是 60 秒如果你的后端接口本身就需要跑 2 分钟那不做任何配置的情况下Nginx 会在 60 秒后主动断开连接。课程里给的建议是不要盲目调大超时时间先搞清楚业务接口的真实耗时再针对性配置。2.2 负载均衡不只是轮询那么简单负载均衡是 Nginx 最亮眼的功能之一很多面试题也喜欢在这一块做文章。Nginx 默认支持的负载均衡算法包括轮询round-robin、加权轮询、ip_hash、least_conn这些在官方文档里都有说明但真正到选型时很多人的思路是模糊的。我个人的经验是如果后端服务是无状态的优先用默认的轮询配合 weight 参数做容量分配如果有会话保持需求可以考虑 ip_hash但要注意它会把同一 IP 的请求都打到同一台机器上一旦这台机器宕机这部分用户的会话会全部失效如果后端机器的配置差异比较大least_conn 往往能获得更均衡的负载效果。配置本身很简单一个典型的 upstream 块长这样upstream backend_servers { least_conn; server 192.168.1.10:8080 weight3; server 192.168.1.11:8080 weight1; keepalive 32; }很多教程讲到这里就结束了但我建议你再往下想一层Nginx 做负载均衡时和 LVS 这类四层负载均衡有什么区别答案是 LVS 工作在内核态转发效率更高但没法像 Nginx 那样做七层的精细化路由。理解了这个区别你就不难回答面试官的追问“为什么你这个场景用 Nginx 而不是 LVS”2.3 静态资源服务与浏览器缓存的配合Nginx 处理静态资源的性能远高于 Tomcat 这类应用服务器所以很多项目的部署方案都是“动静分离”动态请求转发给后端静态资源直接由 Nginx 返回。这一块的实操其实不复杂核心是 root 与 alias 的区分和缓存头配置。root 和 alias 的区别是另一个高频面试题root 配置的是根目录Nginx 会把完整 URI 拼在 root 后面去找文件alias 配置的是别名它会把 location 匹配到的路径替换掉。举个例子location /static/ { root /var/www/html/; }请求/static/a.png时Nginx 找的是/var/www/html/static/a.png如果改成location /static/ { alias /var/www/html/; }那找的就是/var/www/html/a.png。这个区别不搞懂部署项目时经常会出现“404 找不到文件”的诡异问题。缓存配置方面我常用的一段配置也分享出来location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 30d; add_header Cache-Control public, immutable; }这样配置之后浏览器会对这些静态资源做 30 天的强缓存有效降低服务器压力。但要注意如果你的前端项目是每次构建都会生成带哈希的文件名那这个配置非常合适如果文件名不变但内容经常变那缓存时间过长会导致用户看到旧版本这种情况需要配合构建工具的 hash 命名策略。3. 配置文件详解每个指令放对位置问题就少一半Nginx 的配置文件看起来结构清晰但真正动手时很多人会犯一个低级错误把指令写错了层级。比如把 proxy_pass 写在 http 块里或者把 listen 指令写在 location 块里这些都是不生效甚至直接报错的。3.1 配置文件的层级结构究竟是怎么划分的Nginx 的配置文件采用严格的层级结构从外到内依次是main 全局块配置运行 Nginx 服务器本身的全局属性比如 worker 进程数、PID 文件路径。events 块配置 Nginx 与用户的网络连接模型比如 worker_connections、use epoll。http 块配置 HTTP 服务器相关的公共属性比如 include、default_type、日志格式。server 块配置虚拟主机的相关属性每个 server 块相当于一台“虚拟服务器”。location 块配置 URI 匹配规则和对应处理方式。初学者最容易犯的错误就是把 server 级别的指令放到 http 块里。比如有同学想改端口直接把 listen 8080 写到了 http 块顶层然后 reload 时报错。理解层级划分后这种问题基本不会出现。3.2 高频指令的生效范围与优先级这里我整理了一个高频指令生效范围的速查表方便你部署项目时对照指令可写层级作用说明常见误用场景worker_processesmain设置 worker 进程数通常设为 CPU 核心数误写到 http 块导致不生效worker_connectionsevents单进程最大连接数不配置时默认值偏小高并发下出现 502includehttp引入外部配置文件误写成绝对路径导致启动失败listenserver设置监听端口和地址误写到 location 块中server_nameserver配置域名匹配不配置时默认接受任意 Hostroot/aliashttp/server/location设置站点根目录/别名root 和 alias 混用导致路径错误proxy_passlocation/server/http设置代理转发地址带不带 URI 的差异try_fileslocation/server按顺序检查文件是否存在Vue history 路由下不配置导致刷新 404这个表建议你保存下来配置前先对照一下。我在课程里反复强调Nginx 配置文件本身并不复杂绝大多数问题都出在“放错层级”和“指令误解”这两件事上。3.3 一个典型的单页面应用SPA部署配置长什么样以目前最流行的 Vue3 项目为例很多人问“win 服务器怎么部署 Vue3”其实部署方式跨平台是一致的关键就两点一是把构建产物放到 Nginx 能访问到的目录二是让 history 路由下的所有路径都回退到 index.html。server { listen 80; server_name example.com; root /data/www/my-vue-project/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ { expires 7d; } }这个配置的核心在于 try_files。当用户访问某个前端路由比如/user/123时Nginx 首先尝试按这个 URI 找真实文件找不到就回退到/index.html由前端框架接管路由渲染。如果不加这一行Vue3 的 history 模式部署后刷新页面就会 404这也是前端部署最常见的坑之一。4. 环境部署与日常运维那些你不一定知道但一定会遇到的细节很多人在网上搜索“Nginx 未找到命令”“Nginx 的日志路径”“修改端口号”这类问题说明部署和运维是整个学习过程中最容易让人卡住的环节。这一节我把高频问题集中梳理一遍。4.1 安装方式怎么选源码编译、yum/dnf 与 DockerNginx 的安装方式主要分为三类通过系统包管理器安装、通过源码编译安装、通过 Docker 容器运行。这三类方式各有适用场景。包管理器安装yum install nginx / apt install nginx是最快的方式适合刚入门时快速验证和学习但缺点是版本往往不是最新的且缺少一些自定义模块。源码编译安装适合需要定制模块比如添加第三方模块或追求最新稳定版的场景但编译过程相对复杂特别是离线环境下需要手动下载大量依赖。Docker 部署则是最符合现在微服务架构的方式配置隔离性好迁移方便推荐在服务器资源充足的情况下优先考虑。如果你在 CentOS 8 或类似系统上做离线安装我的经验是提前准备好依赖整合包Nginx 编译依赖 gcc、pcre-devel、zlib-devel、openssl-devel 这几样缺一不可。在不能联网的环境中可以找一台同版本系统的联网机器用yumdownloader --resolve把依赖 RPM 包全部下载下来再拷到离线机器上批量安装。4.2 端口修改、日志路径与开机自启修改 Nginx 端口是再基础不过的操作但 Windows Server 2016 上很多同学会找不到配置文件在哪。其实无论什么系统修改端口的核心就是找到 nginx.conf在 server 块里改 listen 指令。常见路径是Linux 下/etc/nginx/nginx.conf或源码编译的/usr/local/nginx/conf/nginx.confWindows 下就是解压目录里的conf/nginx.conf。改完端口后记得先执行nginx -t校验配置语法是否正确再执行 reload避免改错导致服务中断。日志路径也是老生常谈默认访问日志在logs/access.log错误日志在logs/error.log。如果使用系统包管理器安装一般会在/var/log/nginx/下。日志目录是可以自定义的我一般会单独建一个/var/log/nginx/目录并且按天切割。手动切割日志很简单可以用 cronolog 或写一个 shell 脚本定时重命名日志文件。一个常用的做法是#!/bin/bash # 每日零点切割日志 YESTERDAY$(date -d yesterday %Y%m%d) mv /var/log/nginx/access.log /var/log/nginx/access_${YESTERDAY}.log kill -USR1 $(cat /var/run/nginx.pid)之所以要发送 USR1 信号给 master 进程是因为 Nginx 会重新打开日志文件而不是继续往旧文件里写。这个细节如果不了解很多人在手动切割日志后发现日志不写入新文件就是这个原因。开机自启在 Linux 下建议采用 systemd 服务管理创建/etc/systemd/system/nginx.service文件然后执行systemctl enable nginx即可。Windows 下可以直接把 nginx.exe 做成计划任务或者使用 WinSW 这类工具将其注册为 Windows 服务。4.3 Nginx 可视化配置工具值不值得用近两年 Nginx 可视化管理工具越来越火比如 NginxWebUI、Nginx Proxy Manager 这类开源项目。它们的核心价值是把配置文件的操作变成表单填写降低了上手门槛。我的观点是学习和排错阶段不建议过度依赖可视化工具因为在界面上点出来的配置你并不知道它最终写到了配置文件的哪个位置、为什么要这样写一旦出了诡异的问题排查会更困难。但如果是团队协作、频繁新增站点、需要给非专业运维人员使用可视化工具的效率优势非常明显。课程里我会演示 NginxWebUI 的完整部署过程但强调一点用工具生成配置后一定要打开最终生成的配置文件读一遍搞清楚每一行的含义。这样即便工具出了问题你也可以手工修复。4.4 Nginx 漏洞与版本升级的常规检查安全方面Nginx 偶尔也会爆出 CVE 漏洞比如前阵子大家比较关注的 F5 Nginx 相关漏洞例如 CVE-2025-1695。这类问题的应对策略并不复杂核心是两点关注官方安全公告以及建立版本升级的习惯。不要长期停留在某个旧版本上“稳定运行”现代 Web 环境下安全补丁的滞后带来的风险远大于升级带来的兼容性成本。在异构环境部署上aarch64 架构比如麒麟 V11、树莓派现在越来越常见好在 Nginx 官方源码对 aarch64 支持非常成熟直接下载对应架构的源码编译即可。需要注意的是在 ARM 机器上编译前最好确认一下 openssl 版本部分老版本 openssl 在 ARM 上的性能表现不太理想。5. 面试高频考点与实战追问不背题讲逻辑最后这部分是专门为准备面试的同学准备的。Nginx 的面试题其实高度集中翻来覆去就是那么几个方向但面试官越来越不喜欢“背答案”的候选人他们更在意你能不能把原理讲清楚。5.1 基础题这些内容必须张口就来高频基础题包括Nginx 和 Apache 的区别、正向代理和反向代理的区别、Nginx 的 master-worker 进程模型、Nginx 为什么高并发、什么是惊群问题以及如何解决。这里我展开讲一下 master-worker 进程模型因为 80% 的候选人只能说个皮毛。Nginx 启动后会有一个 master 进程和多个 worker 进程。master 进程不处理具体的请求它负责读取配置、管理 worker 进程的生命周期、接收外部信号。真正干活的是 worker 进程每个 worker 进程都能独立处理并发连接它们之间通过共享内存和锁机制协调资源比如 upstream 的限流计数器、共享 session 等。关于惊群问题简单说就是多个 worker 进程同时监听同一个 socket当新连接到来时所有 worker 都被唤醒但最终只有一个能成功 accept其他进程的唤醒纯属浪费。Nginx 通过 accept_mutexaccept 互斥锁来解决这个问题在开启 accept_mutex 时只有拿到锁的 worker 进程才能 accept 新连接其他进程继续处理已有连接。这也是 Nginx 每进程单线程却能支撑高并发的关键设计之一。5.2 进阶题基于场景的追问才是拉分项面试中真正拉开差距的往往是基于场景的追问。比如下面几个如何做 Nginx 的高可用这种题通常可以从 keepalived 虚拟 IP 的角度回答但更好的回答是结合云平台负载均衡产品对比体现出你对方案的全局理解。再比如如何排查 Nginx 返回 502、504、499 这类状态码的问题排查思路是502 通常是后端服务不可用、连接被拒或处理超时504 是 Nginx 作为网关等待后端响应超时499 则是客户端在 Nginx 等待后端期间主动断开了连接。这个题不是考你背状态码含义而是考你有没有真实的排错经验。正确回答方式是先看 error.log 里对应的 upstream 日志再看后端的访问日志和慢查询日志定位是网络问题、后端处理慢还是连接数被打满。再比如如果你的 Nginx 突然 CPU 飙升你会怎么排查经验型候选人会回答先用 top 看是哪个进程消耗 CPU再用nginx -t检查配置再开 access.log 看是不是有恶意请求再排查是否发生了回源风暴。这类场景题没有标准答案但如果你只回答“重启 Nginx”或者“加机器”面试官基本会判定为没有实战经验。5.3 面试准备的一点额外建议我在课程里带面试环节时经常对学员说一句话不要把 Nginx 当题库背而是要把它当成你负责的 Web 系统的“前门”。面试官真正想确认的是你把这个前门管理到了什么程度是只会开锁还是知道什么时候该换锁、什么时候该加窗户、什么时候该装监控所以准备面试的时候建议你在自己的电脑或云端服务器上把课程里的每个实验都亲手做一遍。面试前把自己项目里用到的 Nginx 配置逐行梳理一遍思考每个配置的目的是什么、去掉会有什么后果。做到这个程度Nginx 相关的面试题对你来说基本就是送分题了。6. 写在最后这套 14 小时课程我建议你怎么吃透如果你决定跟着这套课程学我个人的建议是不要用“看视频”的方式去学而是用“做项目”的方式去学。每看完一个场景的讲解立刻在服务器上把同样的配置敲一遍然后故意改错一个地方观察报错信息。把错误当作学习材料这是我从带人的经验里总结出来最有效的路径。最后分享一个我实际使用中的小技巧给自己建一个 nginx 配置的专属笔记库不用多复杂就是一个带搜索功能的 markdown 文档。每遇到一个坑、每解决一个问题花三分钟记下来配上一句“为什么会出现这个问题”的解释。坚持几个月之后你就会发现面试时脑海里浮现的不是背过的题目而是一个个你真正处理过的真实案例。这套 14 小时的课程给了你完整的知识地图但把地图变成肌肉记忆还需要你自己多走几遍。