Nginx 高频面试题完整答案

Nginx 高频面试题完整答案

1. 什么是 Nginx？

Nginx 是一款基于C语言开发、轻量级、高性能、事件驱动、异步非阻塞的开源 Web 服务器、反向代理服务器、负载均衡服务器，由俄罗斯工程师 Igor Sysoev 开发，首个稳定版本发布于2004年，是目前互联网行业主流的核心网关服务软件。

区别于传统同步阻塞服务器，Nginx 核心采用epoll IO多路复用+多进程单线程架构，无频繁线程上下文切换、锁竞争开销，内存占用极低、并发承载能力极强，单机可轻松支撑十万甚至百万级并发连接，完美解决传统服务器的C10K并发瓶颈问题。

功能层面，Nginx 原生支持 HTTP/HTTPS、TCP/UDP四层代理、邮件代理，集成反向代理、负载均衡、动静分离、限流熔断、地址重写、Gzip压缩、跨域处理、缓存、黑白名单、高可用适配等全套运维与网关能力。

凭借高并发、高可用、低功耗、易扩展、支持热部署的核心优势，Nginx 广泛应用于互联网项目的前后端分离架构、API网关、静态资源托管、集群流量分发、CDN边缘节点、微服务入口等核心场景，同时支持OpenResty、Lua脚本拓展，可实现复杂的动态网关业务逻辑，是生产环境必备的基础中间件。

2. Nginx 有哪些优点？

1. 高并发、高性能：Nginx 基于 epoll IO多路复用、异步非阻塞事件驱动模型，摒弃传统服务器同步阻塞、一线程一连接的低效模式，单 Worker 进程可处理数万连接，单机轻松支撑十万级甚至百万级并发请求，并发性能远超 Apache、Tomcat 等传统服务。

2. 内存占用极低、资源开销小：采用轻量化 Master+Worker 多进程架构，Worker 进程无冗余线程、无频繁上下文切换和锁竞争，进程体积小、内存占用极低，高并发场景下不会出现内存暴涨、资源耗尽问题，服务器资源利用率极高。

3. 高稳定性、高可用性：主从进程隔离架构，Master 进程负责管理调度，Worker 进程独立工作，单个 Worker 异常崩溃不会影响其他进程和整体服务运行；支持配置热更新、平滑重启，升级配置、迭代服务无需停机，业务零中断。

4. 原生功能极度丰富：无需额外部署中间件，原生集成反向代理、负载均衡、动静分离、请求限流、IP黑白名单、地址重写、Gzip压缩、跨域处理、资源缓存、防盗链、日志统计等核心网关功能，可满足绝大多数生产运维、流量管控需求。

5. 跨平台、兼容性强：基于C语言编写，可稳定部署在 Linux、Windows、macOS 等主流操作系统，适配物理机、虚拟机、Docker、云服务器等各类部署环境，通用性极强。

6. 模块化设计、扩展性极强：采用核心+模块的架构，核心精简高效，所有拓展功能均以模块形式实现；支持官方模块、第三方模块拓展，同时兼容 OpenResty+Lua 脚本开发，可快速实现动态限流、灰度发布、自定义鉴权等复杂业务逻辑。

7. 支持热部署、运维成本低 ：通过 nginx -s reload 实现平滑重启，加载新配置时不中断现有连接、不影响用户访问；命令简洁、配置清晰、日志完善，运维简单，适配大规模集群管理。

8. 支持多层代理协议、场景全覆盖：不仅支持 HTTP/HTTPS 七层应用层代理，还支持 TCP/UDP 四层传输层代理，可代理数据库、Redis、MQ 等中间件服务，兼顾 Web 网关和底层流量转发场景。

9. 安全性高、抗攻击能力强：可自主配置限流、防刷、IP封禁、请求头过滤、SSL证书加密，能够有效抵御 CC 攻击、爬虫恶意请求、非法访问，作为系统第一道网关，可极大保护后端业务服务安全。

10. 开源免费、生态成熟：开源无版权成本，社区活跃、文档完善、BUG少，行业普及率极高，配套运维工具、解决方案丰富，是企业网关、负载均衡的首选开源组件。

3. Nginx 应用场景

1. 静态资源托管服务器（核心场景）：Nginx 内置零拷贝、文件缓存机制，专门用于托管网站各类静态资源，包括 HTML、CSS、JS、图片、图标、字体、短视频、静态页面等。相比 SpringBoot、Tomcat 等业务容器，Nginx 处理静态文件性能高出数十倍，占用 CPU、内存资源极低，是生产环境静态资源服务的首选，可有效释放后端业务服务性能。

2. 反向代理 + 七层负载均衡（核心场景）：作为业务系统统一入口，接收客户端所有HTTP/HTTPS请求，隐藏后端真实服务集群地址，将请求按照指定算法分发到多台后端业务节点。解决单节点服务性能瓶颈，实现业务水平扩容、流量分摊，支撑高并发业务访问，是微服务、集群架构的基础组件。

3. 动静资源分离架构部署：架构层面拆分动静流量，所有静态资源请求由Nginx直接响应处理，无需转发后端服务；动态接口请求（数据库查询、业务逻辑计算、接口交互）转发至Java、PHP、Go等后端服务。实现流量分层隔离，大幅降低后端服务压力，提升网站整体响应速度与稳定性。

4. 轻量级API网关（通用业务网关）：替代传统重型网关，承担通用流量管控能力，统一实现全局请求拦截、IP黑白名单、接口限流防刷、请求日志收集、参数过滤、权限校验、流量监控等功能。统一规范入口流量，避免后端服务重复开发通用管控逻辑，实现业务与流量治理解耦。

5. SSL证书统一卸载与HTTPS加密：公网业务统一由Nginx配置SSL证书，完成HTTPS加密解密、证书续签、协议适配工作，后端集群全部使用HTTP内网通信。既保障公网访问安全，规避明文传输风险，又降低后端服务SSL加密的性能损耗，简化证书统一运维管理。

6. 流量限流、防刷、抗CC攻击：依托limit_req、limit_conn模块实现精准限流，支持单IP并发连接限制、每秒请求数限制，搭配黑名单封禁、异常请求拦截规则，有效抵御爬虫批量爬取、恶意刷量、CC流量攻击，保护后端业务服务不被恶意流量打垮，保障业务稳定运行。

7. CDN边缘节点加速：广泛应用于CDN内容分发网络的边缘节点，缓存用户高频访问的静态资源、静态页面、视频资源。用户访问时优先从就近Nginx边缘节点获取资源，无需回源中心服务器，大幅降低访问延迟、减少跨地域访问卡顿，同时极大减轻源站流量压力。

8. 四层TCP/UDP代理（底层流量转发）：Nginx 1.9版本后支持四层代理，可实现数据库、Redis、MQ、RPC服务、游戏服务等TCP/UDP协议服务的代理转发与负载均衡。不仅局限于Web服务，可作为底层中间件集群的流量分发工具，适用场景覆盖业务层与基础服务层。

9. 多虚拟主机多站点部署：通过域名、端口、IP三种方式配置虚拟主机，单台Nginx服务器可同时部署多个独立网站、多个业务系统，资源利用率最大化，降低服务器部署成本，是中小企业多站点部署的主流方案。

10. 地址重写、URL规范优化：通过Rewrite模块实现URL重写、伪静态配置、旧链接跳转、域名跳转、参数适配等功能。统一网站URL规范、修复失效链接、适配新旧业务迭代，提升用户体验与搜索引擎收录效果。

11. 资源压缩与页面性能优化：全局开启Gzip压缩，对文本类资源进行压缩传输，减小网络传输体积，缩短页面加载时间；配合浏览器缓存配置，实现静态资源长效缓存，二次访问极速加载，优化前端用户体验。

12. 灰度发布与流量切分：通过Nginx匹配规则、权重配置、IP哈希、Header匹配等方式，实现灰度流量分发，将少量流量引流至新版本服务，其余流量走旧版本服务。实现业务平滑迭代、灰度上线，规避全量更新带来的线上故障风险。

13. 跨域问题统一解决：作为前端后端交互中间层，统一配置CORS跨域响应头，拦截浏览器跨域限制，彻底解决前后端分离架构下的前端接口跨域问题，无需后端代码改造。

4. Nginx 怎么处理请求的？

核心架构前置说明 ：Nginx 采用 Master 主进程 + Worker 工作进程 架构，所有客户端请求均由 Worker 进程通过 epoll IO多路复用、异步非阻塞 机制处理，全程不创建新线程、无阻塞等待，这是Nginx高并发处理请求的核心基础。Master进程仅负责管理调度，不处理任何业务请求。

阶段1：端口监听与连接建立：Nginx启动后，Master进程初始化配置、绑定监听端口，通过惊群锁机制，让多个Worker进程公平竞争监听端口。客户端发起TCP三次握手建立连接，内核将成功的连接分配给空闲的Worker进程，完成请求接入。

阶段2：事件监听与请求读取：Worker进程通过epoll持续监听所有已建立连接的读写事件，全程异步非阻塞。当检测到客户端请求数据就绪时，一次性读取完整HTTP请求报文，包括请求行、请求头、请求体，无轮询开销，单进程可同时监听数万连接。

阶段3：虚拟主机匹配（server块匹配） ：Worker进程解析请求中的端口、Host域名，优先匹配 listen 监听端口，再精准匹配 server_name，定位到对应的server虚拟主机；无匹配域名则命中默认的default_server主机，拦截非法请求。

阶段4：路由规则匹配（location匹配） ：在命中的server块内，按照精确匹配 > 前缀匹配 > 正则匹配 > 普通匹配的优先级，匹配当前请求URI对应的location规则。匹配成功后，加载该location下配置的所有拦截规则，包括rewrite重写、IP黑白名单、限流、防盗链、跨域、缓存、压缩等。

阶段5：请求预处理与规则执行：按顺序执行预处理逻辑：地址重写跳转、非法IP拦截、流量限流、请求头过滤、浏览器UA校验、跨域响应头设置等，校验不通过直接返回403/429等错误码，终止请求；校验通过则进入资源处理阶段。

阶段6：动静资源分类处理：这是核心分流逻辑。若为静态资源（图片、JS、CSS、HTML等），Nginx直接读取本地磁盘文件，通过sendfile零拷贝机制直接响应客户端，无需转发后端；若为动态接口请求（业务查询、数据库交互、接口计算），则通过反向代理转发至upstream后端服务集群。

阶段7：负载均衡与后端转发：匹配upstream集群后，根据预设的轮询、加权轮询、ip_hash、最少连接等算法，挑选一台健康的后端节点，携带客户端请求参数转发请求，同时自动规避max_fails标记的故障节点。

阶段8：接收后端响应数据：Nginx作为网关，接收后端服务返回的响应报文、状态码、响应数据，同时完成响应数据预处理，包括Gzip压缩、资源缓存、响应头统一修改、日志记录等。

阶段9：数据响应客户端：将处理完成的响应数据，通过已建立的TCP连接返回给客户端，完成一次完整的请求响应交互。

阶段10：连接复用与资源释放 ：根据keepalive_timeout配置，长连接会保留连接供后续请求复用，减少TCP重复握手开销；短连接或超时连接会主动关闭，释放socket文件描述符、内存资源，Worker进程持续待命处理下一轮请求。

阶段11：日志落地：请求结束后，自动记录access.log访问日志（请求地址、状态码、响应时间、客户端IP等），异常请求记录error.log错误日志，方便运维排查、流量统计、故障定位。

5. Nginx 是如何实现高并发的？（原理 + 生产实战配置）

Nginx 单机可支撑10万～100万并发连接 ，彻底解决传统 Web 服务器 C10K 瓶颈。其高并发能力不是靠堆资源，而是依靠架构设计、IO模型、系统调优、传输优化、资源复用五大核心机制，区别于 Apache、Tomcat 一连接一线程的低效模型，下面为完整面试原理+生产可直接上线的实战配置。

一、五大核心底层原理（面试必背）

1. Master+Worker 多进程架构，最大化利用多核CPU Nginx 采用主从分离架构，Master 进程只负责管理配置、信号、重启，不处理请求；开启多个 Worker 工作进程，进程数与 CPU 核心数匹配，多进程并行抢占 CPU 资源，充分发挥多核算力。进程之间完全独立，无共享内存竞争、无频繁锁冲突，单个 Worker 崩溃不影响全局服务，兼顾高并发与高可用。

2. 单线程异步非阻塞 + epoll IO多路复用（核心精髓） 传统服务器每来一个连接就创建一个线程，上万连接就上万线程，CPU 上下文切换直接卡死。 Nginx 每个 Worker 进程只有一个主线程 ，通过 Linux epoll 事件驱动模型，单线程可监听数十万 Socket 连接。 全程只处理「读写就绪的连接」，空闲连接不占用任何 CPU，无阻塞、无轮询、无线程切换开销，这是 Nginx 高并发的核心。

3. 资源池复用机制，消除系统频繁开销 Nginx 内置内存池、连接池、文件描述符池，服务启动时一次性预分配资源，请求处理完毕不销毁资源，而是放回池中复用。避免海量并发下频繁创建、销毁内存与连接对象，极大降低系统调用开销，防止高并发场景性能雪崩。

4. Sendfile 零拷贝技术，极致降低CPU损耗 普通文件传输：磁盘→内核缓冲区→用户缓冲区→内核缓冲区→网卡，多次拷贝、CPU 消耗极大。 Nginx 开启零拷贝后，数据直接从磁盘内核态传输到网卡，不经过用户态，无需程序干预，静态资源吞吐性能提升数十倍，高并发下 CPU 占用极低。

5. 长连接复用 + 连接超时回收，稳定海量连接 通过 Keepalive 长连接机制，一次 TCP 三次握手可复用处理上千次 HTTP 请求，避免频繁握手挥手的开销；同时自动清理超时、僵尸、无效连接，防止文件句柄耗尽、内存泄漏，保障长期高并发稳定运行。

二、生产高并发完整调优配置（可直接上线）

以下是企业标准十万级并发优化模板，每一行配置均对应高并发原理，带详细注释：

# 全局高并发调优
worker_processes auto;        # 自动匹配CPU核心，充分利用多核算力
worker_rlimit_nofile 65535;    # 提升单进程最大文件句柄数，支持海量连接

events {
    use epoll;                  # 启用epoll多路复用模型（高并发核心）
    worker_connections 65535;   # 单进程最大支持65535连接
    multi_accept on;            # 一次性接收所有就绪连接，不积压
}

http {
    # 零拷贝+网络传输优化
    sendfile on;                # 开启sendfile零拷贝
    tcp_nopush on;              # 合并小包，减少网络发包次数
    tcp_nodelay on;             # 实时响应，降低接口延迟

    # 长连接复用优化
    keepalive_timeout 65;       # 长连接超时时间
    keepalive_requests 1000;   # 单连接最多复用1000次请求

    # 缓冲区调优，减少频繁IO
    client_header_buffer_size 16k;
    large_client_header_buffers 4 64k;
    client_body_buffer_size 128k;

    # 超时防护，释放无效连接
    client_connect_timeout 60s;
    client_read_timeout 60s;
    client_send_timeout 60s;
}

三、配置与原理一一对应（面试加分点）

• worker_processes auto：适配多核 CPU，多进程并行处理请求，突破单核性能上限；

• use epoll + worker_connections 65535：基于事件驱动，单进程支撑数万连接，解决C10K瓶颈；

• worker_rlimit_nofile 65535：突破系统默认文件句柄限制，支持十万级长连接；

• sendfile 零拷贝：静态请求零CPU拷贝，高并发下服务不卡顿；

• keepalive 长连接：减少 TCP 频繁创建销毁，提升整体吞吐能力。

四、30秒面试极简总结（直接背诵）

Nginx 实现高并发主要依靠五点：

第一，采用 Master+Worker 多进程架构充分利用多核 CPU；

第二，基于 epoll IO 多路复用+单线程异步非阻塞模型，无线程切换开销，支撑海量连接；

第三，内置资源池复用，减少系统调用开销；

第四，开启 sendfile 零拷贝降低 CPU 消耗；

第五，长连接复用+系统参数调优，保障高并发稳定运行，实现单机十万级并发承载能力。

6. 什么是正向代理？（面试完整版深度补全）

正向代理（Forward Proxy） ：是替客户端干活的代理 。客户端无法直接访问目标服务器，通过一台代理服务器中转请求，由代理代替客户端去访问外网资源，返回数据给客户端。正向代理的核心作用是代理客户端、隐藏客户端、赋能客户端。

一、核心工作原理

客户端明确配置代理地址，所有外网请求先交给正向代理服务器；代理服务器代替客户端发起访问、接收响应，最终把数据回传给客户端。整个过程中，目标服务只识别代理IP，完全不知道真实客户端的存在。

二、核心特点（面试必背）

1. 代理对象是客户端：服务于用户/客户端，不服务后端业务服务器；

2. 客户端知情、服务端不知情：客户端手动配置代理，知道代理存在；外网目标服务器只能看到代理IP，无法获取用户真实IP；

3. 突破访问限制、隐藏本机IP：解决内网无法访问外网、网络隔离、地域访问限制等问题；

4. 全局流量中转：可代理所有外网HTTP/HTTPS请求，不局限于某一个网站。

三、典型应用场景

1. 内网机器上网：企业内网服务器无公网IP，通过正向代理访问外网下载依赖、更新软件；

2. 网络穿透、资源访问：突破网络隔离、地域限制访问受限资源；

3. 用户隐私保护：隐藏客户端真实公网IP，避免被网站追踪、封禁；

4. 统一上网管控、审计限流：企业通过正向代理统一管控员工上网行为、限流、拦截违规网站、记录上网日志。

四、常见软件与区别

Nginx 主打反向代理 ，原生对正向代理支持薄弱、配置复杂、功能简陋；企业生产中正向代理一般使用 Squid、Nginx Proxy、V2ray 等专业代理软件。

五、正向代理 vs 反向代理（面试高频对比）

• 正向代理：代理客户端，隐藏用户，用于上网穿透、隐私保护；

• 反向代理：代理服务端，隐藏后端集群，用于网关、负载均衡、动静分离。

六、30秒极简背诵版

正向代理是代理客户端的中转服务，客户端主动配置代理访问外网，真实用户IP被隐藏，外网服务只能看到代理IP。主要用于内网机器上网、突破网络限制、隐私保护和企业上网审计，Nginx不擅长正向代理，多用于反向代理。

7. 什么是反向代理？（面试完整版深度补全）

反向代理（Reverse Proxy） ：是替后端服务干活的代理 ，也是 Nginx 最核心、最主流的应用场景。客户端直接访问代理服务器，完全不知道后端真实业务节点；由反向代理统一接收用户请求，按照规则转发给后端真实服务器处理，最终将后端响应结果返回给客户端。反向代理核心作用是代理服务端、隐藏服务端、管控全网流量。

一、核心工作原理

客户端无需任何配置，直接访问 Nginx 对外暴露的域名/端口；Nginx 作为统一入口，接收所有HTTP/HTTPS请求，经过规则匹配、流量处理后，转发给内网真实的业务服务集群。在整个交互过程中，客户端只认识 Nginx，完全感知不到后端服务器的存在；后端服务也只接收 Nginx 转发的请求，只能看到 Nginx 内网IP，彻底隔离内外网。

二、核心特点（面试必背）

1. 代理对象是后端服务端：保护、代理内网业务集群，不处理客户端上网请求；

2. 客户端不知情、服务端被隐藏：用户无感知、无需配置代理，彻底隐藏后端真实IP、端口、集群架构；

3. 全局流量统一管控入口：所有公网流量必须经过反向代理，实现流量统一收口；

4. 单代理多服务分发：一台 Nginx 可代理数十上百个后端服务，实现多业务统一接入。

三、生产核心应用场景

1. 统一网关入口：作为微服务、前后端分离项目的唯一流量入口，统一管理所有请求；

2. 七层负载均衡：将海量用户请求分发到多台后端节点，解决单节点性能瓶颈，支持水平扩容；

3. 后端安全防护：内网服务不暴露公网，避免被恶意扫描、攻击、爬虫爆破；

4. 请求统一预处理：统一处理 HTTPS 解密、跨域、限流、缓存、压缩、日志、防盗链；

5. 动静分离流量转发：静态资源本地响应，动态接口反向代理转发后端业务服务；

6. 灰度发布与故障隔离：通过权重、规则切分流量，支持灰度上线，自动剔除故障后端节点。

四、正向代理 VS 反向代理（高频面试对比）

1. 正向代理：代理【客户端】，隐藏用户IP，用于内网上网、突破限制、隐私穿透，Nginx不擅长；

2. 反向代理：代理【服务端】，隐藏后端集群，用于网关、负载均衡、流量管控，是Nginx核心能力。

五、30秒极简背诵版

反向代理是代理后端服务的网关模式，用户直接访问Nginx，无需任何配置，Nginx统一接收请求并转发内网真实业务服务，全程隐藏后端真实IP与集群架构。主要用于统一流量入口、负载均衡、安全防护、请求预处理，是Nginx最核心、生产使用最多的功能。

8. 反向代理服务器的优点是什么？（原理 + 全套实战代码）

Nginx反向代理是微服务、集群架构的流量基石，不仅能实现请求转发，还能解决服务安全、性能、扩容、运维等核心问题。下面结合面试高分原理 + 生产可直接上线的实战配置，逐条拆解所有核心优点，每条优点对应专属落地代码。

一、隐藏后端真实服务，提升全网安全性（核心优点）

原理：内网业务服务不暴露公网，所有公网请求仅访问Nginx，彻底隐藏后端真实IP、端口、集群架构，避免后端被恶意扫描、端口爆破、爬虫攻击，从网关层筑牢安全防线。

# 实战配置：纯反向代理，隐藏后端，禁止直接访问内网服务
server {
    listen 80;
    server_name api.test.com;

    # 统一转发所有接口请求
    location / {
        proxy_pass http://backend_api_cluster;
        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_hide_header Server;
    }
}

# 后端集群全程内网部署，无公网暴露
upstream backend_api_cluster {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

二、实现负载均衡，支持服务水平扩容

原理：单台业务服务存在性能瓶颈、单点故障问题，通过反向代理+upstream集群，将海量请求均匀分发到多台后端节点，实现流量分摊，支持服务无限水平扩容，提升整体并发承载能力。

# 实战配置：加权轮询负载均衡，适配不同配置服务器
upstream backend_api_cluster {
    server 192.168.1.10:8080 weight=3; # 高配机器承载更多流量
    server 192.168.1.11:8080 weight=1;
    server 192.168.1.12:8080 backup;   # 备用节点，主节点故障自动接管
}

三、统一网关预处理，解耦后端业务

原理：在网关层统一处理HTTPS加密解密、跨域、缓存、压缩、日志、限流、防盗链等通用逻辑，后端服务只需专注业务开发，无需重复开发通用流量管控功能，实现业务与运维解耦。

# 实战配置：一站式请求预处理
server {
    listen 443 ssl;
    server_name api.test.com;

    # 统一SSL证书配置，后端走HTTP内网通信
    ssl_certificate /usr/local/nginx/ssl/test.pem;
    ssl_certificate_key /usr/local/nginx/ssl/test.key;

    location /api/ {
        # 统一跨域处理
        add_header Access-Control-Allow-Origin https://web.test.com;
        add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
        
        # 统一限流防刷
        limit_req zone=api_req_zone burst=15 nodelay;
        
        # 开启响应压缩
        gzip on;
        gzip_types application/json;

        proxy_pass http://backend_api_cluster;
    }
}

# 全局限流规则
http {
    limit_req_zone $binary_remote_addr zone=api_req_zone:10m rate=8r/s;
}

四、实现动静分离，极致优化访问性能

原理：利用Nginx处理静态资源性能远超后端业务容器的优势，静态资源直接由Nginx本地响应，动态接口转发后端服务，减少后端CPU、IO压力，大幅提升页面加载速度。

# 实战配置：标准动静分离架构
server {
    listen 80;
    server_name web.test.com;

    # 静态资源直接本地返回，开启长期缓存
    location ~* \.(html|css|js|png|jpg|ico|svg)$ {
        root /data/web/static;
        expires 7d;
        add_header Cache-Control "public,max-age=604800";
    }

    # 动态接口转发后端服务
    location / {
        proxy_pass http://backend_api_cluster;
    }
}

五、故障自动隔离，提升服务高可用

原理：通过upstream健康检查参数，自动识别故障后端节点，临时剔除宕机、超时的服务，不再分发流量，待节点恢复后自动重新接入，避免单点故障导致整体业务不可用。

# 实战配置：故障自动隔离、重试机制
upstream backend_api_cluster {
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
    # 连续3次请求失败，剔除节点30秒，期间不再分发流量
}

六、支持灰度发布，实现业务平滑迭代

原理：通过Nginx权重、IP哈希、请求头匹配规则，精准切分流量，将少量流量引流到新版本服务，大部分流量走旧版本，实现灰度上线，规避全量更新的线上风险。

# 实战配置：权重灰度发布
upstream backend_old {
    server 192.168.1.10:8080 weight=9; # 90%流量旧版本
}
upstream backend_new {
    server 192.168.1.12:8080 weight=1; # 10%流量灰度新版本
}

七、30秒面试极简背诵版

反向代理主要有六大核心优点：

一是隐藏后端真实IP，提升服务安全性；

二是实现负载均衡，支持服务水平扩容；

三是统一处理SSL、跨域、限流等通用逻辑，解耦后端业务；

四是实现动静分离，大幅提升访问性能；

五是自动隔离故障节点，保障服务高可用；

六是支持灰度流量切分，实现业务平滑迭代。

9. Nginx 目录结构有哪些？（编译安装 + yum安装 完整版详解）

Nginx 主流安装方式分为源码编译安装 （生产常用、自定义度高）和yum/apt在线安装（默认系统路径），两种目录结构不同，下面为面试+生产完整详解，包含每目录核心功能、生产用途。

一、源码编译安装（默认路径 /usr/local/nginx）------ 企业生产主流

/usr/local/nginx/
├── conf/        # 核心配置目录（重中之重）
├── html/        # 默认静态资源根目录
├── logs/        # 日志与进程文件目录
├── sbin/        # 核心二进制启动程序
├── modules/     # 动态扩展模块目录
├── temp/        # 运行临时缓存目录
└── client_body_temp/ # 客户端请求临时文件

各目录详细作用（面试必背）

(1)conf 配置目录

存放所有Nginx配置文件，核心主配置文件为 nginx.conf，包含全局块、events、http、server、location所有规则；同时包含mime.types资源类型文件、默认配置样例，生产所有反向代理、限流、负载均衡规则均在此配置。

(2)sbin 程序目录

存放唯一二进制可执行文件 nginx，所有启停、重载、信号操作均依赖该程序：start启动、stop停止、reload平滑重启、reopen日志切割，是Nginx的程序核心。

(3)logs 日志目录

包含三大核心文件：

① access.log：全站访问日志，记录所有用户请求、IP、状态码、响应时间，用于日志分析、故障排查；

② error.log：错误日志，记录配置报错、服务异常、转发失败信息，是排错核心依据；

③ nginx.pid：记录当前Nginx Master进程号，用于进程管理、信号发送。

(4)html 静态资源目录

Nginx默认静态站点根目录，内置index.html默认首页、50x.html错误页面，无自定义静态目录时，可直接存放网站静态资源。

(5)modules 模块目录

存放后期动态编译的拓展模块.so文件，无需重新编译Nginx主程序，可动态加载限流、防盗链、监控等第三方模块，扩展性极强。

(6)temp 临时目录

存放高并发场景下的请求临时缓存、文件分片数据，Nginx运行自动生成，无需手动修改，定期自动清理。

二、Yum/Apt 在线安装目录（系统默认路径）

Linux系统yum安装Nginx，目录分散存放，适配系统服务管理：

# 核心配置路径
/etc/nginx/             # 主配置目录
/etc/nginx/nginx.conf   # 主配置文件
/etc/nginx/conf.d/      # 子配置文件目录（可拆分多站点配置）

# 日志路径
/var/log/nginx/         # access.log、error.log

# 程序启动路径
/usr/sbin/nginx         # 启动二进制程序

# 默认静态页面
/usr/share/nginx/html/

三、面试高频考点总结

1. 生产优先使用编译安装：目录集中、管理统一、支持自定义模块、版本可控；

2. 核心三目录必须掌握：sbin（启停程序）、conf（配置规则）、logs（日志排错）；

3. yum安装特点：配置拆分、conf.d可单独存放多站点配置，运维更规范；

4. 禁止随意修改temp目录：误删会导致高并发请求异常、服务报错。

四、30秒极简背诵版

Nginx编译安装核心目录有sbin启动目录、conf配置目录、logs日志目录、html静态目录、modules模块目录和temp临时目录；yum安装路径分散，配置在/etc/nginx、日志在/var/log/nginx。

其中conf、sbin、logs是生产运维最核心的三大目录，所有配置修改、服务启停、故障排错都围绕这三个目录展开。

10. Nginx 配置文件 nginx.conf 有哪些属性模块？（层级+原理+实战全解）

Nginx主配置文件 nginx.conf 采用分层嵌套、逐级生效 的模块结构，整体分为 5大核心模块，优先级从全局到局部逐级细化，局部配置覆盖全局配置。所有生产配置、流量规则、性能调优、负载均衡均基于这五大模块实现，是Nginx运维与面试核心基础。

一、全局块（main 全局模块）------ 最高层级

作用范围：全局生效，控制Nginx整体进程、日志、权限、系统资源，不针对单个网站、单个请求。

核心功能：定义进程运行参数、全局日志、进程PID、系统资源限制，是Nginx服务启动的基础配置。

常用核心参数：

• worker_processes auto：工作进程数，自动适配CPU核心，高并发核心调优参数；

• error_log /logs/error.log warn：全局错误日志路径与日志级别；

• pid /logs/nginx.pid：指定Nginx主进程PID文件路径；

• worker_rlimit_nofile 65535：单进程最大文件句柄数，突破系统限制；

• user nginx：指定Nginx运行用户，保障权限安全。

二、events 模块 ------ 网络连接核心模块

作用范围：全局生效，专门控制Nginx网络IO、连接模型、并发能力，是支撑高并发的核心模块。

核心功能：定义IO多路复用模型、单进程最大连接数、连接接收机制，直接决定Nginx并发上限。

常用核心参数：

• use epoll：启用epoll IO多路复用模型（Linux专属，高并发必备）；

• worker_connections 65535：单个Worker进程最大支持连接数；

• multi_accept on：一次性接收所有就绪连接，避免连接积压；

• accept_mutex on：开启惊群锁，多进程公平抢占连接，提升稳定性。

三、http 模块 ------ HTTP服务总模块（核心常用）

作用范围：所有HTTP/HTTPS网站服务生效，属于服务全局配置，可包含多个子模块与虚拟主机。

核心功能：定义Web服务通用规则，包含资源压缩、长连接、缓存、日志格式、限流、MIME类型、后端集群等全局HTTP配置，所有server虚拟主机默认继承该模块参数。

常用核心参数 & 子模块：

• 基础配置：include mime.types（资源类型映射）、default_type（默认文件类型）；

• 性能调优：sendfile on（零拷贝）、keepalive_timeout（长连接超时）、gzip（资源压缩）；

• 日志配置：log_format（自定义日志格式）、access_log（访问日志路径）；

• 流量管控：全局限流、IP黑白名单、请求缓冲区配置；

• 嵌套子模块：upstream模块（后端负载均衡集群）。

四、server 模块 ------ 虚拟主机模块

作用范围：单个虚拟主机站点生效，一个http模块可配置多个server块，实现单机器多站点部署。

核心功能：绑定监听端口、匹配域名、独立配置单站点规则，隔离不同网站的流量与配置。

常用核心参数：

• listen 80：绑定服务监听端口；

• server_name www.test.com：绑定站点域名；

• default_server：默认虚拟主机，拦截未匹配域名的请求；

• SSL配置、站点日志、跨域、全局请求拦截等单站点专属配置。

五、location 模块 ------ 路径匹配规则模块（最细粒度）

作用范围 ：server模块内部，针对指定URI路径精准生效，是处理具体请求的核心模块，局部配置覆盖上层所有全局配置。

核心功能：根据请求路径匹配规则，实现反向代理、动静分离、重写跳转、限流防刷、缓存、防盗链、权限控制、跨域处理等所有精细化流量操作。

匹配优先级（面试必考）：精确匹配(=) > 前缀匹配(^~) > 正则匹配(~/~*) > 普通前缀匹配

常用核心功能：反向代理proxy_pass、静态资源托管、rewrite重写、limit_req限流、expires缓存、add_header跨域。

六、拓展子模块：upstream 负载均衡模块

归属层级：嵌套在http模块内部，独立于server模块。

核心功能：定义后端业务服务集群，配置负载均衡算法、权重、故障隔离、备用节点，为server的location反向代理提供后端集群地址。

核心参数：weight权重、max_fails故障次数、fail_timeout隔离时长、backup备用节点、ip_hash会话保持。

七、完整层级结构梳理（清晰闭环）

全局块 → events块 → http块（含upstream） → server虚拟主机块 → location路径规则块，层级逐级细化，下层配置优先于上层，实现全局统一调优+局部精准管控。

八、生产完整极简配置模板（对应所有模块）

# 1. 全局块
worker_processes auto;
worker_rlimit_nofile 65535;
error_log /usr/local/nginx/logs/error.log warn;
pid /usr/local/nginx/logs/nginx.pid;

# 2. events模块
events {
    use epoll;
    worker_connections 65535;
    multi_accept on;
}

# 3. http模块
http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;
    gzip on;

    # 3.1 嵌套upstream负载均衡子模块
    upstream backend_cluster {
        server 192.168.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
        server 192.168.1.11:8080 weight=1;
    }

    # 4. server虚拟主机模块
    server {
        listen 80;
        server_name www.test.com;

        # 5. location路径规则模块
        location ~* \.(css|js|png|jpg)$ {
            root /data/static;
            expires 7d;
        }

        location / {
            proxy_pass http://backend_cluster;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

九、30秒面试极简背诵版

Nginx配置文件分为五大核心模块：

全局块管控整体进程与系统资源；

events模块负责网络IO与并发连接，是高并发核心；

http模块定义全站HTTP通用规则，包含upstream负载均衡子模块；

server模块配置独立虚拟主机，实现多站点部署；

location模块精准匹配请求路径，实现反向代理、限流、动静分离等精细化流量处理，配置层级由全局到局部，局部优先覆盖全局。

11. cookie 和 session 区别？（面试完整版深度补全）

HTTP 协议是无状态协议 ，服务端无法自动识别用户身份，Cookie 和 Session 就是为解决 HTTP 无状态、会话保持、用户身份识别 而生的两套会话跟踪技术。二者搭配工作、相辅相成，但存储位置、安全性、性能、生命周期完全不同，是面试高频必考题。

一、完整工作流程（底层原理）

1. 客户端第一次请求服务端，服务端校验无会话信息，自动生成唯一的 SessionID；

2. 服务端开辟服务端内存/Redis空间存储用户会话数据，同时通过 Set-Cookie 响应头将 SessionID 下发给浏览器；

3. 浏览器自动接收并保存 Cookie，后续每次请求，浏览器自动携带 Cookie 中的 SessionID；

4. 服务端通过请求中的 SessionID 匹配对应会话数据，精准识别用户身份，完成会话保持。

二、七大核心维度详细对比（面试满分）

(1)存储位置不同（最核心区别）

Cookie ：存储在客户端浏览器本地；

Session ：存储在服务端（服务器内存/Redis）。

(2)数据安全性不同

Cookie：安全性极低，数据暴露在客户端，可被用户查看、篡改、窃取、伪造，禁止存放密码、密钥等敏感数据；

Session：数据存放在服务端，客户端只存ID，核心数据不外露，安全性极高，适合存放用户权限、登录状态、隐私信息。

(3)数据大小限制不同

Cookie ：单条Cookie最大 4KB，单域名最多20~50条，存储容量极小；

Session：无严格大小限制，可存储大量用户数据、业务信息。

(4)生命周期不同

Cookie：分为会话Cookie（关闭浏览器失效）和持久Cookie（可设置days过期，长期保存在本地）；

Session：默认浏览器关闭会话失效，服务端默认30分钟超时销毁，无法持久化（需手动Redis持久化）。

(5)性能开销不同

Cookie ：占用客户端资源，每次请求自动携带，轻微增加请求头体积； S

ession ：占用服务端内存资源，在线用户量大时，服务端压力明显，需Redis分布式优化。

(6)跨域与共享能力不同

Cookie：严格区分域名、端口，默认不跨域，可通过配置实现子域名共享；

Session ：默认单服务独享，集群多服务场景无法共享，必须借助 Redis 实现分布式Session共享。

(7)依赖关系不同

Session 默认 依赖 Cookie 存储 SessionID；

Cookie 完全独立，可单独使用，无需依赖 Session。 （拓展：Cookie被禁用时，可通过URL重写传递SessionID兜底）

三、各自优缺点总结

Cookie 优缺点

优点 ：减轻服务端压力、数据本地化存储、支持持久化、无需服务端维护； 缺点：容量小、安全性差、易被篡改窃取、存在跨域限制。

Session 优缺点

优点 ：安全可靠、容量无限制、适合存储敏感用户信息； 缺点：占用服务端资源、单机存在上限、集群需额外解决共享问题、默认无法持久化。

四、生产使用规范（面试加分项）

1. 非敏感、小型、长期数据（用户名、主题配色、站点配置）存 Cookie；

2. 敏感、隐私、登录、权限数据（登录态、Token、用户角色）存Session/Redis；

3. 分布式集群必须使用Redis 统一托管Session，解决多服务会话不共享问题；

4. Cookie生产必须开启 HttpOnly、Secure，防止JS窃取和跨站攻击。

五、30秒极简背诵版（直接面试默写）

Cookie和Session是HTTP无状态的会话保持技术。Cookie存客户端、容量小、安全性差、可持久化、不占服务端资源；Session存服务端、安全性高、无容量限制、占用服务器资源、默认依赖Cookie存储SessionID。Cookie适合存放非敏感本地配置，Session存放用户登录、权限等敏感数据，集群场景需用Redis实现分布式Session共享。

12. 为什么 Nginx 不使用多线程？（面试深度完整版）

核心结论前置 ：Nginx 并非不能用 多线程，而是主动放弃传统多线程模型 。Nginx 采用多进程 + 单线程 + epoll 异步非阻塞 架构，相比 Apache、Tomcat「一连接一线程/一进程」的多线程模型，彻底解决了高并发下线程切换、锁竞争、资源抢占、稳定性差的核心痛点，是支撑十万级并发的关键设计。

一、传统多线程模型的致命缺陷（Nginx 规避的问题）

传统服务器（Apache/Tomcat）多线程模型逻辑：每来一个客户端连接，创建/分配一个独立线程处理请求。在高并发场景下存在四大致命短板：

1. 线程上下文切换开销极大：操作系统线程数存在上限，上万并发对应上万线程，CPU 需要频繁切换线程上下文，消耗大量 CPU 资源，导致系统吞吐量断崖式下跌。

2. 频繁锁竞争，并发阻塞严重：多线程共享进程内存空间，访问全局资源必须加锁；大量锁等待、锁冲突会阻塞请求处理，彻底丧失并发能力。

3. 线程资源开销高、上限低：每个线程独占独立栈内存、文件描述符，线程数量越多，内存占用越高，单机并发上限仅有数千，无法支撑海量连接。

4. 单点异常连锁崩溃：多线程共享进程资源，单个线程内存溢出、卡死、异常崩溃，会导致整个进程挂掉，服务稳定性极差。

二、Nginx 弃用多线程、选用多进程单线程的核心优势

1. 无线程切换开销，CPU 利用率极致拉满 每个 Nginx Worker 进程内部只有一个主线程，通过 epoll 事件驱动模型，单线程异步非阻塞监听数万连接。全程无线程创建、销毁、上下文切换，CPU 资源全部用于处理业务请求，高并发性能碾压传统多线程模型。

2. 进程独立内存，无锁竞争、无并发阻塞 Nginx 多个 Worker 进程内存完全独立，不共享全局资源，无需频繁加锁解锁，从底层规避多线程锁冲突、锁等待问题，并发处理全程无阻塞。

3. 隔离性极强，服务稳定性拉满 多进程架构天然隔离故障：单个 Worker 进程因异常、内存泄漏、BUG 崩溃，不会影响 Master 进程和其他 Worker 进程，整体服务不宕机、不中断。而多线程模型一旦单线程异常，整体进程直接崩溃。

4. 精准利用多核 CPU，性能最大化 通过 worker_processes auto 匹配 CPU 核心数，一核心绑定一个 Worker 进程，并行算力拉满，规避多线程多核抢占、调度混乱问题，资源利用率更高。

5. 资源开销极低，支持十万级长连接 单线程模型无冗余线程资源占用，内存、CPU 开销极小，配合文件句柄调优，单机可稳定支撑十万甚至百万级长连接，彻底解决 C10K 并发瓶颈。

三、补充误区纠正（面试加分项）

Nginx 并非完全没有线程 ：Nginx 会启动少量辅助线程 ，用于日志写入、磁盘IO、缓存清理等后台任务，但核心请求处理全程单线程无锁，完全不使用传统业务多线程模型。

四、30秒极简背诵版（面试直接默写）

Nginx 放弃传统多线程模型，核心是为了适配高并发场景。传统多线程存在上下文切换开销大、锁竞争严重、资源占用高、稳定性差的问题。Nginx 采用多进程单线程+epoll异步非阻塞架构，无线程切换、无锁冲突、进程故障隔离、CPU利用率极高，既能充分利用多核算力，又能保障高并发、高可用，是其单机十万级并发的核心设计。

13. Nginx 和 Apache 的区别？（面试深度完整版 + 生产选型）

核心面试结论前置 ：Nginx 是异步非阻塞、事件驱动、多进程单线程 架构，主打高并发、低资源、高可用；Apache 是同步阻塞、进程/线程模型 架构，主打稳定、功能全、动态解析强。生产环境高并发网关、静态服务、集群入口首选 Nginx，传统动态 PHP 老旧业务首选 Apache。

一、底层IO与核心架构区别（最本质区别）

(1)Nginx（异步非阻塞 + epoll 事件驱动）

采用 Master+Worker 多进程架构，每个 Worker 单线程，依托 Linux epoll 多路复用模型。一个进程可以同时监听数万连接，无请求时不占用CPU，全程无阻塞、无轮询，只处理就绪事件，是高并发的核心基石。

(2)Apache（同步阻塞 + 一连接一线程/进程）

采用传统同步阻塞模型，经典 Prefork/Worker/Event 三种模式，核心逻辑为每来一个请求，独占一个进程/线程，请求未处理完成、IO未就绪时，线程全程阻塞占用资源，无法处理新请求。

二、七大核心维度深度对比（面试满分）

(1)并发承载能力

Nginx ：单机支持10万～100万长连接，高并发性能极强，无连接数瓶颈；

Apache：单机极限并发仅数千，连接数超过上限后直接卡顿、拒绝服务，无法应对海量流量。

(2)资源占用情况

Nginx：内存、CPU 占用极低，无频繁线程切换、锁竞争，闲置资源几乎为0；

Apache：每连接独占独立线程/进程，高并发下内存暴涨、CPU上下文切换频繁，资源开销极大。

(3)稳定性与故障隔离

Nginx：进程独立隔离，单个Worker异常崩溃不影响全局，支持热重启、热配置，业务零中断；

Apache：线程耦合度高，高并发下易出现进程卡死、内存溢出，重启直接断流，无平滑重启能力。

(4)静态/动态处理能力

Nginx：自带 sendfile 零拷贝，静态资源处理性能碾压 Apache，极致适合动静分离；不擅长复杂动态脚本解析；

Apache：原生深度适配 PHP、Perl 动态脚本，动态代码解析、.htaccess 分布式配置能力极强，静态性能薄弱。

(5)运维与扩展性

Nginx：模块化设计、支持Lua动态拓展、配置简洁、支持灰度流量、限流、负载均衡、缓存全套网关能力，适配微服务、云原生架构；

Apache：模块臃肿、拓展繁琐、配置冗长，仅适合传统单体站点，不适合大规模集群网关场景。

(6)连接模型差异

Nginx：支持长连接复用、连接池复用，减少TCP频繁握手开销；

Apache：默认短连接为主，高并发下频繁创建销毁连接，系统开销巨大。

(7)跨平台与场景适配

Nginx：轻量便携，适配Docker、云服务器、边缘节点、网关层；

Apache：偏重臃肿，仅适配传统Linux物理机老旧站点。

三、各自核心优缺点总结

Nginx 核心优势与短板

优势：高并发、低功耗、高可用、支持热更新、功能全面、适配网关与集群、扩展性强；

短板：动态脚本解析能力弱、分布式配置能力不如Apache。

Apache 核心优势与短板

优势：极度稳定、兼容性极强、动态脚本支持好、支持.htaccess目录独立配置、权限精细化；

短板：并发弱、资源开销大、无热重启、不适合高流量网关场景。

四、生产环境选型标准（面试加分核心）

1. 首选 Nginx 的场景：网站网关入口、负载均衡集群、动静分离架构、静态资源服务器、高并发接口服务、微服务流量入口、CDN边缘节点、云原生容器部署。

2. 首选 Apache 的场景：传统 PHP 单体老旧项目、需要目录独立权限配置（.htaccess）、低并发内部站点、老旧兼容业务。

五、30秒极简背诵版（面试直接默写）

Nginx采用异步非阻塞epoll事件驱动、多进程单线程架构，高并发、低资源、支持热重启、稳定性强，适合网关、负载均衡、动静分离等高并发场景；Apache采用同步阻塞一连接一线程模型，并发弱、资源开销大，但动态脚本解析强、极度稳定，适合传统PHP老旧业务。目前企业生产主流全面使用Nginx，Apache仅用于老旧项目兼容。

|------|---------------------------|-------------------|
| 维度 | Nginx | Apache Httpd |
| 模型 | 异步非阻塞 epoll，多进程单线程 | 同步阻塞多进程 / 多线程 |
| 并发性能 | 十万级高并发，静态资源极强 | 并发上限低，几千连接性能下滑 |
| 内存占用 | 极低 | 高，每个连接占用独立进程 / 线程 |
| 热更新 | 支持 reload 平滑重启 | 重启会断流 |
| 动静分离 | 天生适合，零拷贝静态加速 | 动态模块强，静态性能弱 |
| 扩展性 | 模块化，OpenResty 支持 Lua 动态脚本 | 原生模块开发繁琐 |
| 适用场景 | 网关、负载均衡、高并发静态站点 | 传统 PHP 动态站点、老旧业务 |

14. 什么是动态资源、静态资源分离？（面试满分完整版）

动静分离 是 Nginx 架构中最核心的优化方案之一，全称静态资源与动态请求分离架构 。核心思想：根据请求资源类型，将流量拆分处理，各司其职。利用 Nginx 擅长高并发、静态读写、零拷贝的优势处理静态资源，将需要业务计算、数据库交互的动态请求，转发给后端 Tomcat、SpringBoot、PHP 等业务容器处理，彻底解放后端服务性能。

一、静态资源（Static Resource）详解

定义 ：提前编写、固化存在服务器磁盘中，无需后端程序运算、无需查询数据库，每次访问返回内容完全一致的资源。

常见类型：

• 页面类：html、htm 静态页面

• 样式脚本类：css、js、json 静态配置文件

• 媒体图片类：png、jpg、gif、jpeg、ico、svg、字体文件

• 视频文档类：mp4、txt、pdf 等固定文件资源

核心特点 ：内容固定、可缓存、无业务逻辑、IO读写为主、高并发友好，Nginx处理性能远超Java/PHP容器。

二、动态资源（Dynamic Resource）详解

定义 ：无法直接读取文件返回，需要后端程序执行业务逻辑、查询数据库、运算渲染、权限校验，实时动态生成响应内容的请求资源，每次访问返回内容可能不同。

常见类型：

• 接口请求：后端 Java、Go、PHP 业务 API 接口

• 数据查询：用户信息、订单数据、列表数据、实时统计数据

• 动态渲染：后端模板渲染页面、实时业务反馈

• 读写操作：新增、修改、删除业务数据等交互请求

核心特点 ：依赖CPU运算、依赖数据库、不可长期缓存、有业务状态、并发压力大，必须由专业业务容器处理，Nginx无法替代。

三、动静分离核心架构原理

所有客户端请求统一经过 Nginx 网关，Nginx 通过 location 正则匹配/路径匹配 自动分流：

1. 匹配到静态资源请求 → Nginx 直接读取本地磁盘文件，通过 sendfile 零拷贝机制直接响应客户端，无需转发后端；

2. 匹配到动态业务请求 → Nginx 通过反向代理 proxy_pass 转发至后端业务服务集群，由后端完成业务计算后返回数据；

3. 全程流量隔离、职责拆分、互不干扰，实现架构解耦与性能最大化。

四、生产标准完整可上线配置（带优化参数）

server {
    listen 80;
    server_name web.test.com;

    # 统一处理所有静态资源，开启缓存、压缩、零拷贝优化
    location ~* \.(html|css|js|png|jpg|jpeg|gif|ico|svg|ttf|mp4|txt)$ {
        root /data/nginx/static;  # 静态资源本地目录
        expires 7d;               # 浏览器缓存7天
        add_header Cache-Control "public,max-age=604800";
        gzip on;                  # 开启静态压缩
        gzip_types text/css application/javascript image/svg+xml;
        access_log off;           # 关闭静态资源日志，减少IO开销
    }

    # 所有剩余请求为动态接口，转发后端集群
    location / {
        proxy_pass http://backend_service_cluster;
        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;
    }
}

# 后端动态服务集群
upstream backend_service_cluster {
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}

五、动静分离核心优势（面试必背）

1. 极致提升访问性能：Nginx 基于epoll+零拷贝处理静态资源，性能是SpringBoot/Tomcat的10~100倍，大幅降低页面首屏加载时间。

2. 大幅减轻后端服务压力：图片、脚本、页面等高频静态流量不经过后端，后端服务仅专注业务逻辑与数据库交互，避免无效IO与CPU消耗。

3. 支持多级缓存加速：静态资源可开启浏览器缓存、Nginx本地缓存、CDN节点缓存，动态请求无法缓存，实现全网加速。

4. 流量隔离、提升稳定性：爬虫、恶意刷量大多针对静态资源，流量被Nginx拦截，不会打垮后端业务接口，保障核心业务稳定。

5. 架构解耦、便于扩容维护：静态资源、动态业务独立部署、独立优化、独立扩容，前端资源迭代无需重启后端服务。

六、面试易错点纠正

• ❌ 误区：动静分离就是把文件放Nginx、接口放后端 ✅ 正解：不仅是存放，核心是流量分流、性能优化、缓存加速、架构解耦的整套架构方案；

• ❌ 误区：静态资源完全不需要后端 ✅ 正解：静态资源纯客户端展示，无业务逻辑，Nginx可独立完成响应；

• ❌ 误区：动静分离只适用于网站项目 ✅ 正解：前后端分离、小程序、APP后台、管理系统均适用。

七、30秒极简背诵版（面试直接默写）

动静分离是Nginx核心架构优化方案，将网站资源分为静态资源和动态资源。静态资源是无需后端计算的固定文件，由Nginx直接本地响应、开启缓存加速；动态资源是需要后端运算、查库的业务请求，转发给SpringBoot、PHP等容器处理。核心作用是各司其职、隔离流量、减轻后端压力、提升页面访问速度，是前后端分离项目的标准生产架构。

15. 为什么要做动静分离？（面试深度完整版 + 生产核心价值）

核心结论前置 ：动静分离的本质是扬长避短、各司其职、架构解耦。利用 Nginx 高并发、IO 性能强的优势处理静态资源，让后端 Java/PHP/Go 服务只专注复杂业务逻辑与数据库运算，解决传统架构「动静混跑」导致的性能瓶颈、后端压垮、页面卡顿、扩容昂贵等生产问题。

一、彻底发挥软硬件性能优势，最大化资源利用率

静态资源读写属于纯磁盘IO、无运算、无数据库交互 的轻量请求，是 Nginx 的强项。Nginx 基于 epoll 异步非阻塞 + sendfile 零拷贝机制，处理静态资源的性能是 Tomcat、SpringBoot 等业务容器的 10~100 倍。

而动态接口需要 CPU 运算、业务逻辑判断、数据库查询、事务处理，属于高消耗请求，必须由后端业务程序处理。

如果动静混跑，所有请求全部打向后端服务，会造成高端业务CPU浪费在低端文件IO上，资源利用率极低，性能严重浪费。动静分离让 Nginx 扛流量、后端扛计算，硬件性能各司其职、极致利用。

二、大幅降低后端服务压力，避免业务被静态流量打垮

互联网网站、管理系统、APP 页面中，80% 以上的请求都是图片、JS、CSS、静态页面等静态流量，真正的业务动态接口请求不足 20%。

若无动静分离：海量静态请求会大量占用后端服务线程池、连接池、CPU、内存资源，导致正常业务接口排队、超时、卡顿，极端场景下爬虫、刷量流量直接打垮后端核心业务。

做了动静分离：高频静态流量全部由 Nginx 直接拦截响应，不经过后端，后端服务只需承载少量核心业务请求，后端压力直接降低 60%~80%，核心业务稳定性大幅提升。

三、支持多级缓存加速，极致优化用户访问速度

静态资源具备内容固定、可缓存、可复用的特性，动静分离架构下可以实现三级全网加速：

1. 浏览器本地缓存：Nginx 配置 expires 过期时间，用户二次访问直接读取本地缓存，无需重复请求服务器；

2. Nginx 本地缓存：高频静态资源本地落地，无需重复读取磁盘；

3. CDN 边缘缓存：静态资源可下沉至全国 CDN 节点，用户就近访问，大幅降低跨地域延迟、减少回源流量。

而动态请求实时性强、内容不固定，无法长期缓存。动静分离精准区分可缓存与不可缓存资源，页面首屏加载速度提升数倍，彻底解决网页卡顿、加载缓慢问题。

四、流量物理隔离，提升服务安全性与抗攻击能力

互联网中绝大多数恶意爬虫、CC 刷量、批量扫描流量，都集中针对图片、页面、资源路径等静态地址。

动静分离架构下，所有静态恶意流量全部拦截在 Nginx 网关层，攻击流量无法穿透到后端业务服务，有效保护接口、数据库、核心业务逻辑不被攻击、爬取、爆破，从流量层面筑牢安全防线。

五、架构解耦，降低运维与扩容成本

1. 业务解耦：前端静态资源与后端代码完全分离，前端迭代、页面改版、资源更新无需重启后端服务，迭代效率更高；

2. 扩容解耦 ：静态流量暴涨只需扩容 Nginx 节点，业务流量暴涨只需扩容后端服务，针对性扩容，避免整体集群扩容的昂贵成本；

3. 故障隔离：静态资源异常、CDN 故障不会影响核心业务接口，后端数据库卡顿也不影响页面静态展示，故障影响范围最小化。

六、规避连接池耗尽问题，提升系统吞吐量

后端服务（Tomcat/SpringBoot）线程池、数据库连接池数量有限，若大量静态请求占用连接，会导致动态业务无可用连接、请求排队超时。动静分离彻底释放后端连接池资源，全部用于处理核心业务交互，系统整体吞吐量大幅提升。

七、30秒极简背诵版（面试直接默写）

做动静分离核心是架构优化、性能优化与稳定性优化。

一是扬长避短，让Nginx处理高IO静态资源、后端专注业务计算，最大化利用服务器性能；

二是过滤海量静态流量，大幅减轻后端服务压力，避免核心业务被打垮；

三是支持多级缓存与CDN加速，提升用户访问速度；

四是实现流量隔离，提升抗攻击能力；

五是架构解耦，实现静态、业务独立迭代与扩容，降低运维成本，是现代前后端分离项目的标准最优架构。

16. 什么叫 CDN 服务？（面试满分完整版）

CDN 全称：内容分发网络（Content Delivery Network） ，是一套基于就近访问、缓存加速、分布式节点的静态资源分发加速架构，也是 Nginx 动静分离架构的上层核心加速方案。

核心本质：把源站静态资源下沉到全国/全球边缘节点，让用户就近访问，替代远程回源访问，实现低延迟、高并发、抗流量、减压源站的效果。

一、核心架构与工作原理

CDN 架构分为两层：中心源站 + 边缘缓存节点，企业源站只负责存储原始资源，不直接面向终端用户承载海量流量，完整工作流程如下：

1. 资源预热/首次回源：静态资源首次被访问或提前预热时，CDN边缘节点会向企业源站拉取资源，缓存至本地节点；

2. 智能DNS调度 ：用户发起资源请求时，智能DNS根据用户地理位置、网络质量、节点负载，匹配距离用户最近、最稳定的CDN边缘节点；

3. 边缘节点响应：节点存在缓存资源则直接返回给用户，无需访问源站；缓存失效/无缓存时，才会向源站回源拉取资源并重新缓存；

4. 长效缓存更新：遵循Nginx配置的expires缓存规则，自动过期、刷新资源，保障资源时效性。

核心特点 ：全程静态资源不走源站、动态资源不支持CDN缓存，完美适配Nginx动静分离架构。

二、CDN 核心适用资源

仅适配可缓存、固定不变、无实时业务逻辑的静态资源，和Nginx动静分离的静态资源完全对齐：

• 页面资源：html静态页面、htm文件；

• 样式脚本：css、js、json静态配置文件；

• 多媒体资源：图片、图标、字体、短视频、音频、文档；

• 静态公共组件：全局静态模板、公共资源文件。

不支持场景：后端动态接口、实时数据查询、用户个性化动态内容、需要鉴权校验的实时业务。

三、五大核心生产价值（面试必背）

1. 极致降低访问延迟，优化用户体验：解决跨地域、跨运营商访问卡顿问题，偏远地区、异地用户无需远程访问源站，就近节点秒响应，大幅提升页面首屏加载速度；

2. 彻底减轻源站压力：90%以上的静态流量由CDN边缘节点承接，源站仅处理少量动态业务请求和节点回源请求，彻底规避静态流量打垮源站的问题；

3. 抗高并发、抗CC攻击、抗爬虫：海量流量、恶意爬虫、CC攻击全部拦截在CDN边缘节点，无法穿透到企业源站和后端业务集群，全方位保护核心业务安全；

4. 节省服务器与带宽成本：无需扩容源站服务器和公网带宽，依托CDN分布式节点承载海量流量，大幅降低企业运维和带宽开销；

5. 提升全网稳定性与容错性：单个CDN节点故障不影响整体服务，调度系统自动切换至正常节点，同时源站宕机时，已缓存的静态资源仍可正常访问，保障页面基础展示。

四、CDN 与 Nginx 动静分离的关联（面试加分核心）

1. 层级递进 ：Nginx动静分离是内网网关层优化 ，CDN是公网边缘层优化，二者层层加速、层层防护；

2. 能力互补：Nginx负责内网动静流量分流、本地缓存、资源优化；CDN负责公网就近加速、全网流量承接、高防抗攻击；

3. 场景绑定：企业生产标准架构为「CDN + Nginx动静分离 + 后端业务集群」，是高并发网站、APP、小程序的标配架构。

五、30秒极简背诵版（面试直接默写）

CDN是内容分发网络，通过在全国部署边缘缓存节点，结合智能DNS调度，让用户就近访问静态资源，无需远程回源企业源站。核心作用是降低用户访问延迟、减轻源站带宽和并发压力、抗爬虫和CC攻击、优化全网访问速度。CDN仅缓存静态资源，和Nginx动静分离架构适配互补，是互联网项目公网加速的核心方案。

17. Nginx 怎么做的动静分离？（面试满分完整版）

Nginx 实现动静分离的核心逻辑：基于 location 路径匹配规则，精准区分静态资源请求和动态业务请求，实现流量分层分流、各司其职。静态资源由 Nginx 直接读取本地文件零拷贝响应，动态接口反向代理转发后端业务集群，从网关层完成性能优化与流量减压，是生产环境标准的高性能架构方案。

一、核心实现原理

1、Nginx 作为全站统一流量入口，接收客户端所有 HTTP/HTTPS 请求； 2、通过 location 正则匹配、后缀匹配，区分请求资源类型； 3、静态资源（图片、样式、脚本、静态页面等）直接 Nginx 本地响应，不经过后端服务； 4、动态业务请求（接口查询、数据读写、业务运算）转发至 Java/PHP/Go 后端集群处理； 5、配套缓存、压缩、日志优化，最大化提升动静分离架构性能。

二、生产可直接上线完整配置（带全套优化）

# 后端业务服务集群定义
upstream backend_api_cluster {
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name web.test.com;

    # 1、处理所有静态资源请求：直接本地响应 + 缓存优化 + 关闭冗余日志
    location ~* \.(html|htm|css|js|json|png|jpg|jpeg|gif|ico|svg|ttf|woff|mp4|txt|pdf)$ {
        root /data/nginx/static;  # 静态资源本地存储目录
        expires 7d;               # 浏览器强缓存7天
        add_header Cache-Control "public,max-age=604800";
        gzip on;                  # 开启静态资源压缩
        gzip_types text/css application/javascript image/svg+xml;
        access_log off;           # 关闭静态资源访问日志，减少磁盘IO压力
    }

    # 2、处理动态接口请求：反向代理转发后端集群
    location / {
        proxy_pass http://backend_api_cluster;
        # 透传客户端真实信息
        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;
    }
}

三、详细执行流程拆解

1. 请求接入：用户访问网站页面，发起页面、图片、接口等全部请求，统一到达 Nginx 网关；

2. 静态资源匹配响应：请求后缀命中静态资源规则，Nginx 读取本地磁盘静态文件，通过 sendfile 零拷贝机制直接返回客户端，全程不经过后端服务；同时浏览器缓存资源，二次访问无需重复请求；

3. 动态请求转发处理：接口类动态请求未匹配静态规则，Nginx 通过反向代理转发至后端业务集群，由后端完成业务逻辑、数据库查询后返回响应数据；

4. 结果统一返回：Nginx 汇总所有响应，完成压缩、响应头统一处理后返回客户端。

四、生产进阶优化细节（面试加分）

1. 精准匹配兜底：通过正则批量匹配所有静态资源后缀，避免遗漏，同时避免过度匹配导致动态资源拦截异常；

2. 缓存分层优化：结合浏览器缓存、Nginx 本地缓存、CDN 边缘缓存，实现三级加速，大幅降低重复请求压力；

3. 日志优化：关闭静态资源日志，仅保留动态接口日志，减少磁盘IO损耗，提升服务吞吐量；

4. 故障隔离：后端服务故障仅影响动态业务，静态页面可正常访问，最小化故障影响范围。

五、核心价值复盘（衔接前文考点）

通过 Nginx 动静分离，充分发挥 Nginx 高并发、IO性能强、零拷贝的优势处理静态资源，让后端业务服务专注 CPU 密集型的业务运算、数据处理，彻底解决动静混跑架构中后端服务被海量静态流量打垮、页面加载卡顿、服务器资源浪费的问题，是高并发网站、前后端分离项目、小程序后台的标准生产架构。

六、30秒极简背诵版（面试直接默写）

Nginx通过location正则匹配资源后缀实现动静分离，图片、css、js、html等静态资源由Nginx直接读取本地文件、开启缓存压缩、直接响应客户端，无需转发后端；接口类动态请求通过反向代理转发后端业务集群处理。核心是流量分层分流，各司其职，减轻后端压力、提升页面访问速度，是生产环境核心性能优化方案。

18. Nginx 负载均衡的算法怎么实现的？策略有哪些？（面试完整版：原理+配置+场景）

Nginx 负载均衡核心依托 ngx_http_upstream_module 模块实现，用于后端服务集群的请求分发，解决单节点瓶颈、实现服务高可用。算法分为原生内置5种核心策略 （开源版自带）和第三方拓展策略（需安装模块），每种算法底层实现逻辑、适配场景差异极大，是面试高频核心考点，以下为完整落地详解。

一、原生内置负载均衡算法（生产常用、无需额外安装）

1. 普通轮询（默认算法）

底层实现原理 ：Nginx 维护一个后端节点列表，接收客户端请求后，按照节点配置顺序依次轮流分发请求，无权重、无差异化分配，所有节点接收请求数量完全均等。自动跳过被标记为down、故障的节点，仅分发流量到健康节点。

核心特点：请求绝对平均分配、逻辑简单、无状态，不考虑节点性能、响应速度、连接数差异。

适用场景：后端所有服务器配置、性能一致，无性能差异的集群场景。

# 普通轮询 默认配置，无需额外参数
upstream backend_cluster {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

2. 加权轮询（weight，生产最常用）

底层实现原理 ：Nginx 采用平滑加权轮询算法 （核心面试考点），并非简单累计权重分发。核心逻辑：每个节点维护两个值，有效权重（weight） 和当前权重。每次请求分发时，选取当前权重最大的节点处理请求，处理完成后该节点当前权重减去总权重，所有节点重新累加原始权重。

该算法解决了传统加权轮询「集中分发、流量扎堆」的问题，实现流量均匀且按权重比例分配，高并发下流量分布更平稳。

核心特点：权重越高，接收请求比例越高；支持差异化适配不同配置服务器，流量分配平滑无扎堆。

适用场景：后端服务器配置、性能不一致，高配机器承载更多流量，低配机器承载少量流量。

# 加权轮询配置：权重3:1分配流量
upstream backend_cluster {
    server 192.168.1.10:8080 weight=3; # 高配节点，75%流量
    server 192.168.1.11:8080 weight=1; # 低配节点，25%流量
}

3. ip_hash（IP哈希，会话保持专用）

底层实现原理 ：Nginx 获取客户端真实公网IP，对IP进行哈希运算，根据哈希结果固定映射到某一台后端节点。同一客户端IP的所有请求，始终分发到同一后端服务器，实现会话保持。

核心特点：天然解决集群Session共享问题；节点上下线会导致哈希映射重分配，短暂会话失效；不支持权重配置。

适用场景：无分布式Session、需要本地会话保持、用户登录态绑定单节点的场景。

# ip_hash 会话保持配置
upstream backend_cluster {
    ip_hash; # 开启IP哈希算法
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

4. least_conn（最少连接优先）

底层实现原理 ：Nginx 实时统计每个后端节点的当前活跃连接数，优先将新请求分发到活跃连接数最少、负载最低的节点。若多个节点连接数一致，默认走轮询逻辑。

核心特点：动态适配节点负载，自动规避高负载节点，优先盘活空闲节点；适配请求处理时长不一致的场景。

适用场景：后端请求处理耗时差异大、业务耗时不稳定、长连接居多的业务场景。

# 最少连接优先配置
upstream backend_cluster {
    least_conn; # 开启最少连接算法
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

5. url_hash（URL哈希，静态缓存专用）

底层实现原理：对请求的完整URL进行哈希运算，相同URL固定分发到同一后端节点。区别于ip_hash，以请求资源路径为维度绑定节点，而非客户端IP。

核心特点：相同资源固定节点缓存，提升缓存命中率，减少重复缓存开销；静态资源场景性能提升显著。

适用场景：后端为缓存服务器、静态资源服务、CDN回源节点场景。

# url_hash 配置
upstream backend_cluster {
    hash $request_uri; # 基于完整URL哈希
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

二、第三方拓展负载均衡算法（企业进阶使用）

1. fair 算法（响应时间优先）

实现原理 ：根据后端节点历史平均响应时间动态分配流量，响应速度越快、耗时越短的节点，分配更多请求；响应慢、负载高的节点自动减少流量。

特点 ：智能适配节点性能波动，极致优化响应速度；需安装 nginx-upstream-fair 模块。

适用场景：对接口响应速度要求极高的核心业务。

三、负载均衡辅助核心参数（生产必备、面试加分）

所有算法均可搭配以下参数，实现高可用容错，是生产落地核心：

• max_fails=3：最大失败次数，连续3次请求失败，判定节点故障；

• fail_timeout=30s：节点故障后，30秒内不再分发流量，30秒后自动重试接入；

• backup：标记为备用节点，所有主节点故障后才接管流量；

• down：手动标记节点下线，永久剔除流量分发列表。

# 带容错参数的完整生产配置
upstream backend_cluster {
    server 192.168.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 weight=1 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 backup; # 备用节点
}

四、算法生产选型对照表（面试必背）

• 节点配置一致、普通业务：默认普通轮询；

• 节点性能不均、差异化流量：加权轮询（首选）；

• 需要会话保持、绑定用户节点：ip_hash；

• 请求耗时不均、长连接业务：least_conn；

• 静态缓存、CDN资源服务：url_hash；

• 极致响应速度、动态择优：fair第三方算法。

五、30秒极简面试背诵版

Nginx负载均衡基于upstream模块实现，原生核心算法有四种：

普通轮询按顺序均分请求；

加权轮询基于平滑权重，适配不同性能节点，是生产主流；

ip_hash基于客户端IP哈希，实现会话保持；

least_conn优先分发到最少连接节点，适配负载不均场景。

拓展url_hash适配静态缓存，fair按响应时间择优。搭配故障自动剔除、备用节点参数，可实现集群高可用流量分发。

19. 如何用 Nginx 解决前端跨域问题？（面试满分完整版+生产避坑）

一、跨域核心原理 ：浏览器遵循同源策略 ，协议、域名、端口任一不同，前端JS请求即触发跨域拦截。跨域错误是浏览器限制，并非服务端报错。

Nginx解决跨域的核心逻辑：在网关层统一添加CORS跨域响应头，放行跨域请求，无需修改前后端代码，是生产最简、最稳定的跨域解决方案。

二、跨域请求分类（必懂，配置关键）

1. 简单请求：GET、POST、HEAD请求，无自定义请求头、无复杂Content-Type，浏览器直接发起请求，返回响应头即可放行。

2. 预检OPTIONS请求 ：PUT、DELETE等请求、携带Token/自定义请求头、Content-Type为application/json的请求，浏览器会先发送OPTIONS预检请求，校验跨域权限，预检通过才会发起正式请求。生产必须处理OPTIONS请求，否则跨域失效。

三、生产标准安全配置（禁止*通配符，企业首选）

生产环境绝对不使用 Access-Control-Allow-Origin *，存在极大安全风险，采用指定可信域名精准放行，同时兼容预检请求、自定义请求头、超时缓存：

# 全局跨域配置（适配所有API接口）
location /api/ {
    # 1. 精准放行前端可信域名（替换为实际前端域名）
    add_header Access-Control-Allow-Origin https://web.test.com always;
    # 2. 允许所有常用请求方法
    add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS always;
    # 3. 放行自定义请求头（Token、Content-Type等，按需补充）
    add_header Access-Control-Allow-Headers Content-Type,Authorization,Token,X-Requested-With always;
    # 4. 允许携带Cookie、登录态凭证（关键！前后端登录必备）
    add_header Access-Control-Allow-Credentials true always;
    # 5. 预检请求缓存时长（24小时，减少重复预检请求，优化性能）
    add_header Access-Control-Max-Age 86400 always;

    # 核心：拦截OPTIONS预检请求，直接返回204，不转发后端
    if ($request_method = OPTIONS) {
        return 204;
    }

    # 正常请求反向代理转发后端服务
    proxy_pass http://backend_api_cluster;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

四、关键配置参数详解（面试必考）

1. always 参数：Nginx默认仅对2xx/3xx响应添加响应头，添加always可保证4xx/5xx异常请求也能返回跨域头，彻底杜绝跨域报错遗漏。

2. Access-Control-Allow-Credentials true ：开启凭证放行，允许前端携带Cookie、LocalStorage、Token令牌，开启后绝对不能用*通配符域名，必须指定具体域名。

3. OPTIONS预检返回204：无内容、成功状态码，快速响应预检请求，不占用后端接口资源，提升跨域请求性能。

4. Access-Control-Max-Age：缓存预检结果，避免每次复杂请求都发送OPTIONS预检，大幅减少无效请求。

五、多前端域名适配方案（企业多终端场景）

若存在多个前端域名（官网、后台管理、小程序后台），通过Nginx变量动态匹配放行，无需重复配置：

location /api/ {
    # 定义可信域名列表，动态匹配
    if ($http_origin ~* ^(https://web.test.com|https://admin.test.com)$) {
        add_header Access-Control-Allow-Origin $http_origin always;
    }

    add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS always;
    add_header Access-Control-Allow-Headers Content-Type,Authorization always;
    add_header Access-Control-Allow-Credentials true always;
    add_header Access-Control-Max-Age 86400 always;

    if ($request_method = OPTIONS) {
        return 204;
    }

    proxy_pass http://backend_api_cluster;
}

六、生产常见坑点避坑（面试加分项）

坑点1：配置跨域后依然报错：未加always参数，异常请求无跨域响应头，导致报错。

坑点2：携带Token跨域失败：未在Allow-Headers中配置Authorization/Token自定义请求头。

坑点3：开启凭证后用*通配符：浏览器直接拦截，同源策略禁止通配符+凭证共存。

坑点4：未处理OPTIONS请求：复杂请求预检失败，正式请求无法发起。

坑点5：多层Nginx代理跨域失效：需在最外层网关配置跨域，内层代理无需重复配置，避免响应头覆盖冲突。

七、30秒极简面试背诵版

Nginx解决跨域的核心是网关层配置CORS响应头，无需改动业务代码。区分简单请求和OPTIONS预检请求，生产禁用*通配符，精准放行可信前端域名；配置允许的请求方法、自定义请求头，开启凭证携带，缓存预检请求优化性能，拦截OPTIONS请求直接返回204。

适配多域名场景，解决前后端分离架构的浏览器跨域拦截问题，是企业标准跨域解决方案。

20. Nginx 虚拟主机怎么配置？（面试完整版+三种模式+生产实战）

核心概念 ：Nginx 虚拟主机（Virtual Host）核心作用是单台服务器、单个Nginx服务，部署多个独立网站/业务系统，实现服务器资源最大化利用，无需为每个站点单独部署服务器。其本质是通过规则区分不同请求，将流量分发到不同站点目录，是中小企业多站点部署的核心方案。

Nginx 支持三种虚拟主机配置方式：域名区分（最常用）、端口区分、IP区分，三种方式可单独使用，也可混合使用，以下为原理+可直接上线的生产配置。

一、域名区分虚拟主机（生产主流、面试必考）

原理 ：监听同一端口（默认80/443），通过请求头中的 server_name 域名 区分不同站点，不同域名对应不同网站根目录、配置规则，是线上多站点部署的标准方案。

适用场景：单服务器部署多个独立域名网站，共用端口、公网IP。

# 站点1：官网 www.test.com
server {
    listen 80;
    server_name www.test.com test.com; # 绑定主域名+泛域名
    root /data/nginx/www; # 站点根目录
    index index.html index.htm; # 默认访问首页
    access_log /usr/local/nginx/logs/www.log; # 独立站点日志
}

# 站点2：后台管理 admin.test.com
server {
    listen 80;
    server_name admin.test.com;
    root /data/nginx/admin;
    index index.html;
    access_log /usr/local/nginx/logs/admin.log;
}

# 站点3：博客 blog.test.com
server {
    listen 80;
    server_name blog.test.com;
    root /data/nginx/blog;
    index index.html;
}

二、端口区分虚拟主机

原理 ：共用同一服务器IP、同一域名，通过不同监听端口区分不同站点，端口不同则视为不同虚拟主机。

适用场景：内网测试环境、同一业务多版本部署、无独立域名的内部系统。

# 80端口：正式站点
server {
    listen 80;
    server_name web.test.com;
    root /data/nginx/prod;
}

# 8080端口：测试站点
server {
    listen 8080;
    server_name web.test.com;
    root /data/nginx/test;
}

# 8090端口：预发布站点
server {
    listen 8090;
    server_name web.test.com;
    root /data/nginx/staging;
}

三、IP区分虚拟主机

原理 ：服务器配置多个网卡/多个公网IP，同一端口、不同IP绑定不同虚拟主机，通过请求访问的服务器IP区分站点。

适用场景：业务隔离要求高、需要不同IP独立备案、多IP流量拆分的企业场景。

# 绑定IP1 192.168.1.10
server {
    listen 192.168.1.10:80;
    server_name _;
    root /data/nginx/ip1_site;
}

# 绑定IP2 192.168.1.11
server {
    listen 192.168.1.11:80;
    server_name _;
    root /data/nginx/ip2_site;
}

四、默认虚拟主机（拦截非法请求，生产必备）

通过 default_server 配置默认虚拟主机，用于拦截未匹配到任何server_name的非法域名、泛解析、恶意请求，防止恶意流量入侵。

server {
    listen 80 default_server; # 当前端口默认兜底主机
    server_name _; # 匹配所有无效域名
    return 403; # 直接拒绝访问，提升安全性
}

五、虚拟主机匹配优先级（面试高频考点）

Nginx 接收请求后，严格按照以下优先级匹配虚拟主机，优先级从高到低：

1. 精准匹配 IP+端口 的虚拟主机；

2. 精准匹配 完整域名 的 server_name；

3. 匹配 泛域名（如 *.test.com）；

4. 匹配 default_server 默认虚拟主机；

5. 无任何匹配时，命中端口第一个配置的 server 块。

六、HTTPS虚拟主机配置（生产标准）

线上业务标配HTTPS，基于域名虚拟主机配置SSL证书，实现加密访问：

server {
    listen 443 ssl;
    server_name www.test.com;
    # SSL证书配置
    ssl_certificate /usr/local/nginx/ssl/test.pem;
    ssl_certificate_key /usr/local/nginx/ssl/test.key;
    ssl_protocols TLS1.2 TLS1.3;
    root /data/nginx/www;
    index index.html;
}

# HTTP强制跳转HTTPS
server {
    listen 80;
    server_name www.test.com;
    return 301 https://$host$request_uri;
}

七、面试易错点避坑

1. 多个server块端口冲突会报错，同端口只能通过域名区分，不能重复绑定相同IP+端口；

2. default_server 全局仅需配置一个，多配置会导致匹配异常；

3. 泛域名匹配优先级低于精准域名，不会误伤正式站点；

4. 虚拟主机独立配置日志、根目录、规则，站点之间完全隔离、互不影响。

八、30秒极简背诵版

Nginx虚拟主机有三种配置方式，最常用域名区分，通过server_name绑定不同域名实现单服务器多站点部署；其次是端口区分，同域名不同端口隔离站点；IP区分通过多网卡IP绑定不同站点。

可配置default_server拦截非法请求，请求按精准域名、泛域名、默认主机的优先级匹配，生产线上域名虚拟主机+HTTPS是标准部署方案。

21. location 的作用是什么？（面试完整版）

location 是 Nginx server 虚拟主机模块内部的核心细粒度匹配模块 ，是 Nginx 实现精细化流量管控的核心载体。核心作用为：根据客户端请求的URI 请求路径，按照固定优先级规则精准匹配请求，对匹配成功的请求执行自定义专属规则，实现请求分流、权限管控、性能优化、业务适配，不同 location 可配置完全不同的处理逻辑，局部配置优先覆盖 server 全局配置。

一、location 核心功能（生产全覆盖）

1. 请求路径精准分流：区分静态资源请求、动态接口请求，实现动静分离架构，是 Nginx 性能优化的核心基础。

2. 反向代理转发：匹配接口路径，将动态请求转发至后端 upstream 业务集群，实现负载均衡、服务代理。

3. 地址重写跳转：结合 rewrite 规则实现旧链接跳转、URL 规范化、域名重定向、参数适配。

4. 流量限流与防刷：针对指定接口、路径单独配置限流规则，精准防护核心接口，避免全局限流误伤正常业务。

5. 资源缓存与压缩：对静态资源路径单独配置 expires 缓存、gzip 压缩，针对性优化页面加载性能。

6. 跨域统一处理：为 API 接口路径配置 CORS 跨域响应头，解决前后端分离跨域问题。

7. 权限与安全管控：配置 IP 黑白名单、拦截非法请求、限制访问终端、防盗链，防护核心路径（如后台管理接口）。

8. 日志精细化管控：针对不同路径开启/关闭访问日志，区分核心接口日志与静态资源冗余日志，减少磁盘IO损耗。

二、location 匹配优先级（面试必考核心）

Nginx 严格按照从高到低优先级匹配，匹配成功即终止匹配，不再向下遍历：

1. 精确匹配 =：精准匹配完整 URI，优先级最高，命中后直接生效；

2. 前缀强制匹配 ^~：前缀匹配，匹配成功后忽略所有正则匹配，适合核心路径兜底；

3. 正则匹配 ~ / ~*：~ 区分大小写、~* 不区分大小写，优先级低于强制前缀匹配；

4. 普通前缀匹配：无任何符号的默认前缀匹配，优先级最低；

5. 默认匹配 /：全局兜底匹配，所有未命中规则的请求均会命中。

三、生产常用配置示例

server {
    listen 80;
    server_name web.test.com;

    # 精确匹配首页
    location = / {
        index index.html;
    }

    # 正则匹配所有静态资源，直接本地响应+缓存
    location ~* \.(css|js|png|jpg|html)$ {
        root /data/static;
        expires 7d;
        gzip on;
    }

    # 接口路径跨域+反向代理
    location /api/ {
        add_header Access-Control-Allow-Origin https://web.test.com;
        proxy_pass http://backend_cluster;
    }

    # 后台路径IP白名单限制
    location /admin/ {
        allow 192.168.1.0/24;
        deny all;
        proxy_pass http://admin_cluster;
    }

    # 全局兜底匹配
    location / {
        proxy_pass http://default_cluster;
    }
}

四、30秒极简面试背诵版

location是Nginx server块内的路径匹配核心模块，通过URI路径精准匹配客户端请求，按固定优先级执行差异化规则。主要用于实现动静分离、反向代理负载均衡、URL重写、接口限流、资源缓存压缩、跨域处理、IP权限管控等精细化流量操作，局部配置可覆盖全局，是Nginx网关流量治理、架构优化的核心基础。

22. 限流怎么做的？（面试满分完整版：模块+算法+配置+实战）

Nginx 开源版原生提供两大限流模块，分别针对请求频率限流 和并发连接数限流 ，基于内核算法实现无感知流量防护，无需额外部署组件，是生产环境防刷、抗CC、保护后端服务的核心手段。核心分为 limit_req_zone（频率限流，令牌桶算法） 和 limit_conn_zone（连接限流，漏桶算法），二者搭配使用可实现全维度流量管控。

一、limit_req_zone 频率限流（核心常用）

作用 ：限制同一客户端IP每秒最大请求次数 ，拦截高频刷接口、爬虫批量请求、CC攻击流量，基于令牌桶算法，支持突发流量缓冲，适配绝大多数业务场景。

核心原理：系统匀速生成令牌，每个请求必须获取有效令牌才能放行，无令牌则拒绝请求；支持预存少量令牌，应对业务突发流量，兼顾稳定性与可用性。

1. 全局配置（http块，全局生效）

# 频率限流规则：基于客户端IP限流，内存空间10m，每秒生成10个令牌（10请求/秒）
limit_req_zone $binary_remote_addr zone=api_req_zone:10m rate=10r/s;

2. 局部生效（server/location块，精准限流）

location /api/ {
    # burst=20：突发缓冲队列，最多缓存20个突发请求
    # nodelay：缓冲队列请求立即放行，不延迟等待令牌
    limit_req zone=api_req_zone burst=20 nodelay;
    proxy_pass http://backend_api_cluster;
}

3. 参数逐行详解（面试必考）

• $binary_remote_addr：限流维度，基于客户端真实IP限流，精准区分不同用户；

• zone=api_req_zone:10m：定义限流内存区域，名称api_req_zone，分配10M内存，可存储数万IP限流状态；

• rate=10r/s：限流阈值，单个IP每秒最多允许10次请求；

• burst=20：突发缓冲阈值，瞬间超量请求最多缓存20个，避免正常突发流量被误杀；

• nodelay：缓冲队列内的请求立即放行，超出队列的请求直接返回429限流码，无延迟阻塞。

二、limit_conn_zone 并发连接限流

作用 ：限制同一客户端IP的最大实时并发连接数 ，基于漏桶算法，固定连接处理上限，防止单IP占用过多服务连接资源，杜绝连接池耗尽问题。

核心原理：服务端维持固定连接容量，新连接进入后若超出阈值直接丢弃，连接处理完毕释放名额，流出速率恒定，无突发扩容能力。

1. 完整生产配置

http {
    # 连接限流规则：基于IP统计并发连接数，内存空间10m
    limit_conn_zone $binary_remote_addr zone=conn_zone:10m;
}

location / {
    # 单IP最大允许20个实时并发连接
    limit_conn conn_zone 20;
    # 限流后返回标准429状态码
    limit_req_status 429;
}

三、多维度精准限流（企业进阶方案）

除了IP限流，可基于请求参数、接口路径、请求头实现精细化限流，避免全局限流误伤正常用户：

# 基于接口路径差异化限流
limit_req_zone $binary_remote_addr$request_uri zone=uri_req_zone:20m rate=5r/s;

location /api/login {
    # 登录接口严格限流，防止暴力破解
    limit_req zone=uri_req_zone burst=5 nodelay;
}

location /api/list {
    # 普通查询接口宽松限流
    limit_req zone=api_req_zone burst=30 nodelay;
}

四、生产限流避坑要点（面试加分）

1. 内存空间合理配置：zone内存过小会导致限流状态丢失，高频业务建议配置10M-50M，适配海量IP访问；

2. 区分业务限流阈值：登录、支付等核心接口严格限流，资讯、查询类接口放宽阈值，适配业务特性；

3. 禁用全局严苛限流：避免全站统一限流，防止正常批量操作、批量查询被误拦截；

4. 状态码统一规范：限流统一返回429 Too Many Requests，便于前端提示、日志监控、告警统计；

5. 多层限流防护：CDN边缘限流+Nginx网关限流双层防护，彻底拦截恶意流量。

五、30秒极简面试背诵版

Nginx限流依靠两大原生模块实现：

limit_req_zone基于令牌桶算法，限制单IP每秒请求频率，支持burst突发缓冲，适配业务波动流量；

limit_conn_zone基于漏桶算法，限制单IP实时并发连接数，防止连接资源耗尽。

生产中二者搭配使用，按接口维度差异化配置阈值，统一返回429状态码，可有效拦截爬虫、CC攻击、高频恶意请求，保护后端服务稳定运行。

23. 漏桶算法和令牌桶算法（面试超全对比 + Nginx落地原理）

漏桶算法与令牌桶算法是互联网最主流的两种流量限流算法，Nginx限流模块分别对应适配这两种算法，核心用于解决流量突发、流量过载、CC攻击、爬虫刷量问题，保护后端服务稳定性。

二者核心区别：漏桶匀速出水、拒绝突发流量；令牌桶匀速生成令牌、支持合理突发流量。

一、漏桶算法（Leaky Bucket）------ Nginx limit_conn 底层算法

1、核心原理

将网络流量比作水流，系统存在一个固定容量的漏桶，客户端请求水流持续流入桶内，漏桶以固定恒定的速率向外出水（处理请求）。当流入流量速率大于流出速率，桶内水流堆积；若桶被填满，多余的请求水流直接溢出丢弃，实现限流效果。

2、核心特性

• 流量绝对匀速：请求处理速率恒定，完全不随客户端请求波动，流量整形效果极强；

• 不支持突发流量：无论瞬时请求量多大，都只能按固定速率处理，突发流量直接丢弃；

• 限制并发连接数 ：核心管控实时并发连接数量，而非请求频率；

• 削峰能力弱、稳压能力强：适合需要绝对平稳流量的业务场景。

3、Nginx落地对应

对应 Nginx limit_conn_zone 并发限流模块，通过限制单IP最大实时并发连接数，固定服务连接处理上限，避免单用户占用过多服务器连接资源，防止连接池耗尽、服务卡死。

4、适用场景

接口实时性要求低、禁止流量突发、需要严格平稳流量的场景，如后台数据同步、定时任务上报、日志推送等。

二、令牌桶算法（Token Bucket）------ Nginx limit_req 底层算法

1、核心原理

系统以固定匀速持续生成令牌，存入固定容量的令牌桶中，多余令牌会被丢弃，不会无限堆积。客户端每发起一次请求，必须从桶中获取一枚有效令牌，无令牌则请求被拦截（返回429限流）。桶内可预存一定数量令牌，当出现瞬时突发流量时，可消耗预存令牌快速处理请求，无需等待系统生成新令牌。

2、核心特性

• 支持合理突发流量：可通过预存令牌承接短时间流量峰值，适配互联网业务波峰波谷特性；

• 限制请求频率 ：核心管控单位时间请求次数，精准防刷、防CC攻击；

• 限流阈值灵活：通过rate设置匀速请求上限，burst设置突发流量缓冲上限；

• 削峰能力强、兼顾稳定性与可用性。

3、Nginx落地对应

对应 Nginx limit_req_zone 请求频率限流模块，是Nginx默认、生产最常用的限流算法。搭配burst突发缓冲、nodelay立即放行参数，完美适配电商秒杀、活动峰值、用户高频查询等突发业务场景。

4、适用场景

绝大多数互联网业务，存在瞬时流量峰值、需要防爬虫、防CC攻击、允许合理突发流量的场景，如商品查询、用户登录、接口请求、页面访问等。

三、两大算法核心面试对比（必背）

对比维度	漏桶算法	令牌桶算法
Nginx对应模块	limit_conn_zone（并发限流）	limit_req_zone（频率限流）
限流维度	实时并发连接数	单位时间请求次数
流量特性	匀速处理，无突发能力	匀速生成令牌，支持合理突发
核心作用	稳定流量、防止连接资源耗尽	防刷防攻击、承接业务峰值
削峰能力	弱	强
业务适配性	差，不适合突发业务	强，适配绝大多数线上业务

四、生产最佳实践（面试加分）

企业生产环境不单独使用单一算法 ，采用令牌桶+漏桶双层限流组合方案：通过令牌桶算法限制接口请求频率，拦截爬虫、CC恶意高频请求；通过漏桶算法限制单IP最大并发连接，防止单个用户占用过多服务资源，双层防护全方位保障服务高可用。

五、30秒极简背诵版

漏桶算法对应Nginx limit_conn并发限流，请求如水流入桶，固定速率处理，不支持突发流量，主打流量稳压，限制并发连接数；令牌桶算法对应limit_req频率限流，系统匀速生成令牌，请求需获取令牌放行，可预存令牌承接突发流量，主打削峰防刷，适配绝大多数线上业务。

生产中二者搭配使用，实现双层流量防护。

24. Nginx 配置高可用性怎么配置？（生产两套方案：主备高可用 + 集群多活高可用）

Nginx 单机存在单点故障风险，一旦服务器宕机、Nginx进程崩溃、网络异常，全网流量将全部中断。生产环境针对Nginx网关层高可用，主流分为主备高可用（Keepalived+Nginx） 、**集群多活高可用（LVS+Nginx集群）**两套成熟方案，适配不同业务规模，同时搭配Nginx原生后端健康检查，实现网关+业务双层高可用，以下为完整原理、实战配置、故障切换逻辑与面试考点。

一、方案一：Keepalived+Nginx 主备高可用（中小企业主流）

该方案为单机故障兜底方案，部署两台配置一致的Nginx服务器（一主一备），依托Keepalived实现虚拟VIP漂移、自动故障切换，全程无需人工干预，解决Nginx单点故障问题。

1. 架构原理

两台服务器（主节点、备节点）部署相同Nginx配置，绑定同一个虚拟VIP（公网/内网浮动IP）；正常情况下仅主节点抢占VIP，承接所有业务流量，备节点处于待命状态；当主节点Nginx宕机、服务器死机、网络中断时，Keepalived检测到故障，自动将VIP漂移至备节点，备节点瞬间接管所有流量，实现业务无中断。

2. 核心环境准备

• 两台服务器：主节点（192.168.1.10）、备节点（192.168.1.11）

• 虚拟VIP：192.168.1.100（对外统一访问IP，全程不改变）

• 两台机器Nginx配置、版本完全一致，业务代码同步

• 两台机器安装Keepalived服务

3. 完整生产配置

（1）主节点 Keepalived 配置 /etc/keepalived/keepalived.conf

global_defs {
   router_id nginx_master  # 主节点标识
}
# 定义VRRP虚拟组，实现VIP漂移
vrrp_instance NGINX_HA {
    state MASTER         # 主节点角色
    interface eth0       # 本机网卡名称
    virtual_router_id 51 # 集群统一ID，主备必须一致
    priority 100         # 主节点优先级（高于备机）
    advert_int 1         # 心跳检测间隔1秒

    # 对外浮动VIP（核心）
    virtual_ipaddress {
        192.168.1.100/24
    }
}
# 监控Nginx进程，进程挂掉自动切换
vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 1    # 1秒检测一次
    weight -20    # Nginx异常，优先级降20，低于备机
}
track_script {
    check_nginx
}

（2）备节点 Keepalived 配置 /etc/keepalived/keepalived.conf

global_defs {
   router_id nginx_backup
}
vrrp_instance NGINX_HA {
    state BACKUP         # 备节点角色
    interface eth0
    virtual_router_id 51 # 与主节点一致
    priority 80          # 优先级低于主机
    advert_int 1

    virtual_ipaddress {
        192.168.1.100/24
    }
}
# 同主机一致的进程检测脚本
vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 1
    weight -20
}
track_script {
    check_nginx
}

（3）Nginx进程检测脚本（主备通用）/etc/keepalived/check_nginx.sh

#!/bin/bash
# 检测Nginx进程是否存活
nginx_status=$(ps -ef | grep nginx | grep -v grep | wc -l)
if [ $nginx_status -eq 0 ];then
    # Nginx宕机，停止Keepalived，触发VIP漂移
    systemctl stop keepalived
fi

4. 故障切换流程

1. 正常状态：主节点优先级高，绑定VIP，承载所有流量，备机静默待命；

2. 故障触发：主节点Nginx崩溃、服务器宕机，检测脚本感知异常，停止本机Keepalived；

3. VIP漂移：备节点检测不到主节点心跳，自动抢占VIP；

4. 流量恢复：备节点接管所有公网/内网流量，业务无感知、零中断；

5. 故障恢复：主节点重启后，优先级高于备机，VIP自动回迁，恢复主备常态。

5. 方案优缺点

优点：部署简单、成本低、切换秒级完成、业务零中断，适配中小企业、中小型流量业务；

缺点：同一时间只有一台Nginx工作，无法水平扩容，流量上限单机器瓶颈。

二、方案二：LVS+Nginx 集群多活高可用（大厂高并发主流）

针对超大流量、高并发业务，摒弃主备单点待命模式，采用LVS四层负载均衡 + 多台Nginx工作节点的多活架构，所有Nginx节点同时对外提供服务，无单点、无闲置节点，支持无限水平扩容。

1. 架构层级

客户端流量 → LVS高可用集群（主备） → 多台Nginx节点集群 → 后端业务服务集群

2. 核心原理

• LVS作为顶层四层负载均衡，基于TCP协议转发流量，性能极高、无应用层瓶颈；

• 后端部署多台Nginx节点，所有节点同时承接流量，实现流量分摊；

• LVS自带节点健康检查，自动剔除宕机、异常的Nginx节点，不再分发流量；

• LVS自身搭配Keepalived实现主备高可用，彻底消除顶层单点故障。

3. Nginx节点集群配置（核心）

所有Nginx节点配置完全一致，统一对接后端upstream业务集群，无需VIP配置，只需保证服务正常监听：

http {
    # 后端业务集群统一配置
    upstream backend_service {
        server 192.168.2.10:8080 max_fails=3 fail_timeout=30s;
        server 192.168.2.11:8080 max_fails=3 fail_timeout=30s;
    }

    server {
        listen 80;
        server_name web.test.com;
        location / {
            proxy_pass http://backend_service;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

4. 方案优缺点

优点 ：多节点多活、流量均分、支持水平扩容、并发上限极高，单台Nginx故障不影响整体业务，稳定性拉满； 缺点：架构复杂、部署运维成本高，适合中大型高并发业务场景。

三、配套：Nginx后端服务被动健康检查（全局兜底）

无论以上哪种高可用架构，都需搭配Nginx原生健康检查，实现后端业务节点故障自动隔离，完善整体高可用体系：

upstream backend_service {
    server 192.168.2.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.2.11:8080 max_fails=3 fail_timeout=30s;
    # 参数说明：
    # max_fails=3：连续3次请求失败，判定节点故障
    # fail_timeout=30s：故障节点30秒内不再分发流量，30秒后自动重试恢复
}

补充：Nginx开源版无主动健康检查，仅支持被动健康检查（请求失败后剔除）；如需定时主动探测后端节点，可使用OpenResty、Nginx Plus商业版或自研定时探测脚本。

四、30秒极简面试背诵版

Nginx高可用有两套生产方案：中小企业用Keepalived+Nginx主备架构，通过虚拟VIP漂移、进程心跳检测，主节点故障时备机秒级接管流量，实现业务零中断；高并发场景用LVS+Nginx多活集群，LVS四层负载均衡兜底，多台Nginx同时工作、流量均分，支持水平扩容。

同时搭配Nginx upstream被动健康检查，自动剔除故障后端节点，全方位实现网关层+业务层高可用。

25. Nginx 怎么判断IP不可访问？（黑名单封禁+白名单放行+生产实战）

Nginx 主要通过allow/deny IP黑白名单模块实现IP访问权限管控，精准判断并拦截非法IP、禁止指定IP访问服务，同时可结合限流模块、变量匹配实现临时/永久IP封禁，是网关层基础安全防护手段，可精准拦截恶意扫描、爬虫、攻击IP。该模块属于Nginx原生内置模块，无需额外安装，支持单IP、IP段、全网权限配置。

一、核心匹配规则与优先级

Nginx 黑白名单遵循自上而下匹配、匹配即终止 的规则，末尾默认兜底，优先级如下：精准IP/IP段配置优先生效，最后通过 deny all / allow all 全局兜底，所有未匹配IP统一管控。

二、三大生产实战配置场景

1、白名单模式（仅放行指定IP，高危场景首选）

适用于后台管理、内网接口、核心权限接口，仅允许内网/指定办公IP访问，拒绝所有外网IP，安全性最高。

# 后台接口全局白名单管控
location /admin/ {
    allow 192.168.1.0/24;  # 放行内网网段
    allow 127.0.0.1;       # 放行本机回环地址
    deny all;              # 拒绝所有其他IP访问
}

2、黑名单模式（封禁指定恶意IP/IP段）

适用于拦截爬虫、高频刷接口、CC攻击、恶意扫描的IP，仅封禁目标IP，放行所有正常用户。

# 全局封禁恶意IP
location / {
    deny 113.12.xx.xx;     # 封禁单个恶意公网IP
    deny 185.199.xx.0/24;  # 封禁恶意IP段
    allow all;             # 放行剩余所有正常IP
}

3、结合限流实现动态临时封禁（进阶生产方案）

静态黑白名单需手动配置，生产中结合限流模块，对高频异常请求IP自动拦截、临时封禁，实现动态防护，无需人工干预。

http {
    # 基于客户端IP限流，1秒5次请求上限
    limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=5r/s;
}

server {
    location /api/ {
        limit_req zone=ip_limit burst=10 nodelay;
        # 超频次IP自动返回429，限制访问
        limit_req_status 429;
    }
}

三、关键知识点与避坑点（面试加分）

1. 生效层级：allow/deny 可配置在 http、server、location 层级，层级越细优先级越高，location层级配置仅管控指定接口路径。

2. IP格式支持：支持单个IP、CIDR网段（如192.168.1.0/24），不支持模糊匹配，配置精准无误差。

3. 反向代理真实IP获取 ：若前端存在CDN、多层Nginx代理，必须配置 proxy_set_header X-Real-IP $remote_addr;，否则会拦截代理内网IP，导致正常用户无法访问。

4. 优先级避坑：白名单场景必须「先allow、后deny」，若先deny all会直接拦截所有IP，配置失效。

四、30秒极简面试背诵版

Nginx通过原生allow/deny黑白名单判断IP是否可访问，遵循自上而下匹配规则。白名单模式先放行指定内网/可信IP、兜底拒绝全网，适配核心接口防护；黑名单模式封禁恶意IP/IP段、放行正常用户。生产可结合limit_req限流模块，对高频异常IP动态临时封禁，多层防护拦截恶意访问，同时需配置真实IP获取，避免代理场景误拦截。

26. 在 nginx 中，如何使用未定义的服务器名称来阻止处理请求？（面试完整版）

在Nginx中，未定义的服务器名称 指客户端通过无效域名、泛解析域名、空域名、直接IP访问等方式发起请求，请求携带的 Host 头部无法匹配任何正常业务的 server_name。我们可以通过配置默认虚拟主机 + 无效服务器名称拦截的方式，统一拦截这类非法请求，拒绝处理未知域名流量，防护服务器安全。

一、核心实现原理

Nginx在端口监听层面支持配置 default_server 默认虚拟主机，作用是：当前端口下所有未匹配到有效server_name 的请求，全部默认进入该虚拟主机处理。同时Nginx支持配置 server_name _;，该配置不匹配任何真实有效域名，专门用于兜底拦截所有无效、未定义的服务器名称请求。

核心逻辑：正常业务域名精准匹配对应站点，无效域名、未知Host请求全部命中默认主机，统一拒绝，避免恶意泛解析流量、扫描流量访问业务。

二、生产完整可上线配置

# 拦截所有未定义域名、无效Host、IP直接访问请求
server {
    listen 80 default_server;   # 当前80端口默认兜底主机
    listen 443 ssl default_server; # HTTPS端口兜底拦截
    server_name _;              # 匹配所有未定义、无效服务器名称（无真实域名）
    
    # 直接返回403禁止访问，拒绝处理非法请求
    return 403;
}

三、关键参数详解

1. default_server：端口级别的默认匹配标识，优先级最低，所有精准域名匹配失败后，统一命中该主机，是拦截未定义域名的核心参数。

2. server_name _：Nginx专属无效域名匹配规则，不绑定任何真实业务域名，专门用于兜底拦截，不会与任何正常业务域名冲突。

四、拓展优化：适配泛解析恶意跳转

部分恶意请求会携带乱序Host头，可结合域名校验严格拦截，同时屏蔽无效请求日志刷屏：

server {
    listen 80 default_server;
    server_name _;
    access_log off; # 关闭无效请求日志，避免日志冗余刷屏
    return 403;
}

五、生产核心作用（面试加分）

1. 拦截恶意泛解析流量：防止域名被恶意泛解析，避免陌生域名挂载到自身服务器窃取权重、发起攻击；

2. 屏蔽IP直接访问：禁止用户通过服务器公网IP、内网IP直接访问站点，仅允许指定域名访问；

3. 拦截端口扫描、恶意探测：屏蔽爬虫、扫描工具对端口的批量探测请求，提升网关安全性；

4. 规范流量入口：仅放行业务合规域名流量，过滤所有未知非法流量。

六、30秒极简面试背诵版

通过配置带default_server的默认虚拟主机、设置server_name _，拦截所有未定义、无效、不匹配的域名请求以及IP直接访问、恶意泛解析流量。所有精准域名匹配失败的请求会命中默认主机，统一返回403拒绝处理，可屏蔽端口扫描和恶意探测，规范流量入口，提升Nginx服务安全性。

27. 怎么限制浏览器访问？（面试完整版+多场景实战拦截）

Nginx 限制浏览器访问的核心原理是解析客户端请求的 User-Agent（UA 请求头），通过匹配浏览器标识、爬虫特征、客户端类型，实现「拦截恶意爬虫、限制老旧浏览器、禁止工具访问、仅放行指定浏览器」等精细化访问控制，无需后端代码改造，网关层直接拦截过滤，是生产轻量安全防护的常用手段。

一、核心知识点

UA（User-Agent）是客户端访问标识，浏览器、爬虫、接口请求工具（curl、postman）都会携带专属UA信息，Nginx 通过内置全局变量 $http_user_agent 捕获该标识，结合正则匹配实现访问拦截与放行，支持精准匹配、模糊匹配、批量拦截。

二、生产五大实战场景配置（可直接上线）

1、拦截所有爬虫、扫描工具、恶意请求（通用防护）

拦截百度爬虫、谷歌爬虫、端口扫描工具、curl、wget、爬虫脚本等非法批量访问，保护服务器资源：

server {
    listen 80 default_server;
    server_name _;
    access_log off; # 关闭无效请求日志，避免日志冗余刷屏
    return 403;
}

2、限制老旧低版本浏览器访问（兼容业务）

拦截IE6、IE7、IE8等老旧浏览器，避免兼容问题导致页面错乱、功能异常，仅放行现代浏览器：

# 拦截IE6/7/8老旧浏览器
if ($http_user_agent ~* (MSIE 6.0|MSIE 7.0|MSIE 8.0)) {
    return 403;
}

3、仅放行指定浏览器（严格权限管控）

涉密系统、内网后台专用，只允许Chrome、Edge浏览器访问，拦截所有其他浏览器、工具：

# 非Chrome、Edge浏览器全部拦截
if ($http_user_agent !~* (Chrome|Edg)) {
    return 403;
}

4、禁止移动端访问（仅允许PC端）

针对仅适配PC端的后台系统，拦截手机、平板等移动端设备访问：

# 匹配移动端UA标识并拦截
if ($http_user_agent ~* (Mobile|Android|iOS|iPhone|iPad|Huawei|Xiaomi)) {
    return 403;
}

5、拦截指定非法客户端/自定义爬虫

针对自定义爬虫、恶意批量访问客户端，精准匹配专属UA并封禁：

if ($http_user_agent ~* (test-spider|illegal-client)) {
    return 403;
}

三、进阶优化：UA为空拦截（防止伪造空请求）

部分恶意攻击、脚本请求会清空UA请求头，可单独拦截空UA请求，完善防护体系：

# 拦截UA为空的请求
if ($http_user_agent = "") {
    return 403;
}

四、生产避坑要点（面试加分）

1. UA可伪造，仅做轻量防护：User-Agent可被客户端随意篡改，该方式只能拦截普通爬虫、扫描工具，无法防御高级伪造请求，不能替代IP黑名单、限流、WAF防护；

2. 匹配不精准易误杀：正则匹配需严谨，避免关键词重合导致正常浏览器被拦截，优先使用精准特征匹配；

3. 配置层级建议：建议配置在server全局层级，统一拦截全站非法访问，无需在每个location重复配置；

4. 区分搜索引擎爬虫：业务如需SEO，需放行百度、谷歌正规爬虫（保留baidu、google字段），仅拦截恶意爬虫。

五、30秒极简面试背诵版

Nginx限制浏览器访问核心通过$http_user_agent变量匹配客户端UA实现，支持拦截爬虫、扫描工具、老旧浏览器、移动端设备及非法请求工具。

可按需配置黑名单拦截恶意客户端、白名单放行指定浏览器、拦截空UA请求，属于网关层轻量防护。

注意UA可伪造，仅适用于基础防刷、防爬虫，无法防御高级伪造攻击，生产需搭配IP黑名单、限流规则实现多层防护。

28. Rewrite 全局变量是什么？（面试完整版+实战用法）

Nginx Rewrite 全局变量是 Nginx 内置的核心内置变量，专门用于获取请求、客户端、服务、URL、请求头等各类信息，配合 rewrite 重写规则、if 判断、反向代理、流量跳转实现精细化URL处理、域名跳转、参数适配，是Nginx地址重写、动态路由的核心基础，所有rewrite重写逻辑均依赖全局变量实现。

一、Rewrite 高频核心全局变量（面试必背+生产常用）

• $scheme ：请求协议，取值为http / https，常用于HTTP强制跳转HTTPS场景

• $host：请求携带的域名/主机名，优先级：请求Header Host > 匹配的server_name > 本机主机名

• $request_uri：完整原始请求URI，包含路径+全部参数，不会自动去除参数、不会标准化路径（最常用）

• $uri：当前处理的标准化URI，自动去除请求参数、修复路径冗余，是Nginx内部处理后的路径

• $args：URL请求参数（问号后面的所有参数），可单独获取、拼接、替换请求参数

• $remote_addr：客户端真实IP地址，可用于IP匹配跳转、地域流量分发

• $http_user_agent：客户端UA标识，识别浏览器、设备、爬虫，实现差异化跳转

• $http_referer ：请求来源页面地址，核心用于防盗链、来源流量统计、外链拦截

• $server_name：当前匹配成功的Nginx虚拟主机域名

• $server_port：当前服务监听端口

• $request_method：请求方式，GET/POST/PUT/DELETE，可根据请求方法拦截或跳转

• $time_local：本地请求时间，用于日志、动态规则适配

二、Rewrite 四大核心flag标记（配套必备）

rewrite 完整语法：rewrite 正则匹配规则 跳转地址 [flag];，flag决定重写执行逻辑，面试高频考点：

• last：终止当前location规则，重新发起新一轮全局匹配，多用于内部URL重写，浏览器地址不变

• break：终止当前所有规则，直接使用当前URI处理请求，不再重新匹配，性能最优

• redirect：302临时重定向，浏览器地址变更，临时跳转、业务迭代过渡使用

• permanent：301永久重定向，浏览器永久缓存跳转规则，域名永久迁移、旧链接失效跳转使用

三、生产实战案例（变量+rewrite落地）

1、HTTP强制跳转HTTPS（$scheme）

if ($scheme != https) {
    rewrite ^(.*)$ https://$host$request_uri permanent;
}

2、旧域名永久跳转新域名（host、request_uri）

rewrite ^(.*)$ https://new.test.com$request_uri permanent;

3、携带参数完整跳转（保留原有URL参数）

rewrite /old.html /new.html?$args break;

4、移动端设备自动跳转移动端页面（$http_user_agent）

if ($http_user_agent ~* (Mobile|Android|iOS)) {
    rewrite ^(.*)$ https://m.test.com$request_uri redirect;
}

四、高频易错点（面试避坑）

1. request_uri 与 uri 区别 ：request_uri 保留完整参数、原始路径；uri 去除参数、标准化路径，跳转优先用 $request_uri 避免参数丢失；

2. last 与 break 区别：last 会重新匹配location，break 直接终止规则、不再匹配，内部重写优先用break；

3. 301/302场景区分：永久业务迁移用permanent(301)，临时测试、灰度跳转用redirect(302)；

4. 所有Rewrite变量支持if判断、正则匹配，可灵活组合实现复杂流量跳转逻辑。

五、30秒极简面试背诵版

Rewrite全局变量是Nginx内置的请求信息变量，核心常用变量有scheme请求协议、host请求域名、request_uri完整请求路径、args请求参数、http_referer来源地址、http_user_agent客户端标识。

配合last/break/redirect/permanent四大flag，可实现HTTP跳转HTTPS、域名迁移、设备差异化跳转、参数适配等URL重写功能，是Nginx流量规整、页面跳转的核心能力。

29. Nginx 如何实现后端服务的健康检查？（面试满分完整版：开源被动+主动全方案）

Nginx 针对后端业务集群提供被动健康检查（开源版原生支持） 和主动健康检查（商业版/第三方模块支持） 两种核心方案，用于自动识别后端节点故障、自动剔除异常节点、节点恢复后自动回切，彻底规避后端单点故障导致的业务报错，是保障服务高可用的核心能力。其中开源版无原生主动健康检查，仅支持被动探测，生产可通过第三方模块、OpenResty、商业版实现主动健康巡检。

一、被动健康检查（Nginx 开源版原生、无需插件）

被动检查核心逻辑：不主动定时探测后端节点，仅在转发业务请求时统计节点失败次数，触发阈值后临时剔除故障节点，是所有开源Nginx默认自带的健康检查机制。

1、核心配置与完整参数

upstream backend_cluster {
    # 后端业务节点
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}

2、核心参数详解（面试必考）

• max_fails=3：故障判定阈值，指定时间内连续3次请求失败（超时、5xx报错、连接失败），判定节点故障；

• fail_timeout=30s：故障隔离时长，节点被判定故障后，30秒内不再分发任何流量；30秒后自动重试探测，节点恢复正常则重新接入集群；

• 默认兜底参数：单次请求超时、后端主动断开、响应5xx状态码，均会被统计为失败请求。

3、完整故障流转流程

1. 正常状态：所有后端节点正常接收、处理请求，失败次数清零；

2. 节点故障：某节点连续3次请求异常，触发阈值，被临时剔除集群；

3. 故障隔离：30秒内所有流量仅分发至正常节点，故障节点静默待命；

4. 自动重试：30秒超时后，自动尝试转发少量请求探测节点状态；

5. 节点恢复：探测请求成功，节点重新加入集群，恢复流量分发；探测失败则继续隔离。

4、优缺点总结

优点：原生支持、零部署成本、轻量无性能损耗、适配所有开源环境；

缺点：存在请求误伤，必须有真实业务请求失败才会触发剔除，无流量时无法感知节点故障，故障发现存在延迟。

二、主动健康检查（精准无误伤、生产高阶方案）

主动检查核心逻辑：Nginx后台定时主动向后端节点发送探测请求 ，无需依赖业务流量，实时感知节点存活状态，提前剔除故障节点，完全避免用户请求误伤，是高可用业务首选方案。该能力开源版原生不支持，三种落地方式如下：

1、Nginx Plus 商业版（官方原生）

商业版内置成熟主动健康检查模块，支持HTTP/HTTPS/TCP/UDP全协议探测，可自定义探测接口、超时时间、成败阈值，配置简单、稳定性强，适配大型企业高并发集群。

2、第三方模块 nginx_upstream_check_module（中小企业主流）

淘宝开源的健康检查模块，适配开源Nginx，编译安装后可实现毫秒级主动巡检，是开源环境最常用的主动健康检查方案。

生产完整可上线配置

upstream backend_cluster {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    # 主动健康检查核心配置
    check interval=3000 rise=2 fall=3 timeout=2000 type=http;
    # 自定义HTTP探测请求（探测后端健康接口）
    check_http_send "GET /health HTTP/1.0\r\n\r\n";
    # 2xx/3xx状态码判定节点正常
    check_http_expect_alive http_2xx http_3xx;
}

参数详解

• interval=3000：探测间隔，每3秒主动探测一次后端节点；

• rise=2：连续2次探测成功，判定节点恢复健康，重新接入集群；

• fall=3：连续3次探测失败，判定节点故障，立即剔除；

• timeout=2000：探测请求超时时间，2秒未响应则判定失败；

• type=http：探测协议，支持http/https/tcp，适配各类后端服务。

3、OpenResty+Lua 自研探测（大厂定制方案）

基于OpenResty生态，通过Lua脚本自定义健康检查逻辑，可实现复杂探测规则、动态节点管理、告警联动，灵活性极高，适配个性化业务场景。

三、被动检查 vs 主动检查 核心对比（面试高频）

|------|-------------|---------------------|
| 对比维度 | 被动健康检查 | 主动健康检查 |
| 支持版本 | Nginx开源版原生 | 商业版/第三方模块/OpenResty |
| 探测方式 | 依赖真实业务请求统计 | 后台定时主动探测 |
| 故障感知 | 延迟高、无流量无法感知 | 实时感知、无延迟 |
| 业务误伤 | 存在，需失败请求触发 | 完全无误伤 |
| 性能开销 | 零开销 | 极低（自定义探测频率） |

四、生产最佳实践（面试加分）

1. 中小企业开源环境：被动检查+第三方主动模块搭配使用，兼顾低成本与高可用；

2. 高并发核心业务：优先主动健康检查，提前屏蔽故障节点，保障用户零感知；

3. 后端服务必须提供专属/health健康探测接口，精准反馈服务运行状态，避免端口通但业务异常的误判；

4. 搭配故障日志监控、告警机制，节点频繁上下线及时排查集群问题。

五、30秒极简面试背诵版

Nginx后端健康检查分被动和主动两种。开源版原生支持被动健康检查，通过max_fails统计请求失败次数、fail_timeout隔离故障节点，无需额外部署，但依赖业务流量、存在误伤。主动健康检查需Nginx Plus商业版或第三方模块实现，后台定时主动探测后端健康接口，实时剔除故障节点、恢复正常节点，无业务误伤、故障感知精准。生产环境一般搭配使用，最大化保障后端集群高可用。

30. Nginx 如何开启压缩？（完整原理+生产全配置+避坑详解）

Nginx 内置 ngx_http_gzip_module 压缩模块，无需额外安装，核心作用是对服务端响应资源进行Gzip压缩，减小网络传输文件体积（压缩率可达30%-70%），大幅提升页面加载速度、降低带宽消耗、减少接口响应延迟，是前端性能优化、生产环境必备的基础配置。该模块默认仅压缩服务端返回给客户端的响应数据，原生不支持压缩客户端上传的请求数据。

一、生产完整可直接上线配置（全参数标准版）

# 全局HTTP层级开启全站压缩
http {
    # 开启Gzip压缩总开关
    gzip on;
    # 仅压缩大于1KB的资源，小文件压缩得不偿失，避免压缩损耗大于传输收益
    gzip_min_length 1k;
    # 压缩缓冲区：开辟4个16K缓冲区缓存压缩数据，提升压缩效率
    gzip_buffers 4 16k;
    # 适配HTTP/1.0老旧协议，兼容低版本客户端
    gzip_http_version 1.1;
    # 压缩等级 1-9：等级越高压缩率越高、CPU消耗越大，生产最优取值6（均衡压缩率与性能）
    gzip_comp_level 6;
    # 指定需要压缩的资源类型（核心：仅压缩文本类资源，不压缩图片、视频等已压缩资源）
    gzip_types
        text/plain
        text/css
        text/javascript
        text/html
        application/javascript
        application/json
        application/xml
        image/svg+xml;
    # 开启Vary响应头，告知客户端资源经过压缩，兼容缓存机制
    gzip_vary on;
    # 禁止对IE6及以下老旧浏览器压缩，兼容浏览器bug
    gzip_disable "MSIE [1-6]\.";
}

二、核心参数逐行详解（面试必背）

• gzip on/off：压缩总开关，on开启、off关闭，默认关闭；

• gzip_min_length：最小压缩文件阈值，小于该大小的文件不压缩，避免小文件压缩后体积变大、浪费CPU；

• gzip_buffers：压缩缓冲区配置，定义压缩时使用的缓存空间，提升压缩处理效率；

• gzip_http_version：适配的HTTP协议版本，默认1.1，兼容主流客户端；

• gzip_comp_level：压缩等级，1级压缩最快、体积最大，9级压缩最慢、体积最小；生产固定6级，兼顾性能与压缩效果；

• gzip_types：精准匹配需要压缩的MIME资源类型，仅配置的资源会被压缩；

• gzip_vary：开启后携带Vary: Accept-Encoding响应头，让代理服务器、CDN正确识别压缩资源，避免缓存错乱；

• gzip_disable：屏蔽老旧异常浏览器，避免压缩后页面解析错乱。

三、生产核心适配规则（避坑重点）

1. 不压缩二进制大文件：jpg、png、gif、mp4、zip等图片、视频、压缩包资源，本身已做过压缩处理，再次压缩几乎无效果，还会浪费CPU资源，禁止加入gzip_types；

2. 优先压缩文本资源：html、css、js、json、xml、svg等文本资源，压缩效果极佳，是核心优化对象；

3. 层级生效规则：配置在http层级全局生效，可在server/location层级单独关闭或重写规则，局部覆盖全局配置；

4. 动态接口适配：后端返回的JSON接口数据开启压缩后，可大幅减小接口响应体积，提升接口请求速度。

四、局部关闭压缩实战场景

部分动态接口、实时推送接口无需压缩，可单独关闭：

location /websocket/ {
    gzip off; # 长连接、实时接口关闭压缩，降低延迟
    proxy_pass http://backend_websocket;
}

五、30秒极简面试背诵版

Nginx通过原生gzip模块开启资源压缩，生产开启gzip总开关，设置1k最小压缩阈值、6级均衡压缩等级，仅对html、css、js、json等文本类资源压缩，屏蔽老旧浏览器和小文件压缩。开启gzip_vary适配缓存，不压缩图片视频等已压缩资源，可有效减小传输体积、降低带宽消耗、优化页面和接口访问速度，是Web性能核心优化手段。

31. ngx_http_upstream_module 的作用是什么？（面试完整版详解）

ngx_http_upstream_module 是 Nginx 核心原生负载均衡模块，无需额外安装，是实现后端服务集群调度、反向代理、流量分发、高可用容错的核心基础模块，也是 Nginx 支撑微服务集群、业务水平扩容、消除单点故障的关键组件。该模块专门用于定义、管理、调度后端业务服务集群，承接 Nginx 反向代理的流量转发核心逻辑，所有 Nginx 七层负载均衡能力均依赖此模块实现。

一、核心完整功能（面试必背）

1. 定义后端服务集群 支持批量配置多台后端业务节点（IP+端口），将多个独立业务服务封装为一个 upstream 集群，统一对外提供服务，替代单节点后端服务，支撑业务水平扩容。

2. 提供多种负载均衡调度算法 内置多款主流调度算法，适配不同生产场景：默认轮询 均匀分发流量；加权轮询 适配配置差异服务器；ip_hash 实现会话保持；least_conn最小连接数调度，规避繁忙节点，精准优化流量分配。

3. 后端节点高可用容错 原生支持被动健康检查，通过 max_fails、fail_timeout 参数统计请求失败次数，自动识别宕机、超时、报错的故障节点，临时剔除集群，不再分发流量；待节点恢复后自动重新接入，彻底规避后端单点故障，保障业务高可用。

4. 精细化节点权重与状态管控 支持配置节点权重（weight）、备用节点（backup）、不可用节点（down），可实现流量权重分配、故障冗余备份、节点手动下线等精细化管控，适配灰度发布、故障切换、集群运维场景。

5. 连接复用与超时防护 支持后端连接长连接复用，减少频繁创建销毁连接的开销；可自定义连接超时、读取超时、发送超时参数，防止请求卡死、连接堆积，优化集群整体稳定性。

6. 请求重试与故障兜底 支持 proxy_next_upstream 重试机制，当前节点请求失败、超时、报错时，自动重试分发至集群内其他正常节点，最大程度减少用户请求失败，提升业务容错率。

二、核心常用参数（生产实战）

upstream backend_cluster {
    server 192.168.1.10:8080 weight=3;    # 权重配置，承载更多流量
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s; # 故障自动剔除
    server 192.168.1.12:8080 backup;       # 备用节点，主节点故障接管
    server 192.168.1.13:8080 down;         # 手动下线节点，暂停分发流量
    ip_hash;                               # 开启会话保持
    least_conn;                            # 开启最小连接调度
}

三、核心使用场景

1. 业务集群负载均衡：解决单后端服务性能瓶颈，实现多节点流量分摊，支撑高并发业务；

2. 服务高可用保障：自动隔离故障节点，规避单点故障，实现业务无感知容错；

3. 灰度流量发布：通过权重配比，实现新旧版本服务流量切分，平滑迭代业务；

4. 异构服务器适配：通过权重区分高低配置服务器，合理分配流量，提升资源利用率。

四、30秒极简面试背诵版

ngx_http_upstream_module是Nginx原生核心负载均衡模块，核心作用是定义和管理后端业务集群，内置轮询、加权轮询、ip_hash、最小连接数等调度算法，实现流量均匀分发。同时支持后端节点被动健康检查、故障自动剔除、节点权重管控、请求重试兜底，可实现业务水平扩容、消除单点故障、保障集群高可用，是Nginx七层反向代理与负载均衡的核心依赖模块。

核心负载均衡模块，实现：

1. 定义后端服务集群 upstream；

2. 内置多种负载均衡调度算法；

3. 后端故障自动隔离、重试、连接复用；

4. 配置权重、备用节点、最大连接数、超时时间。

32. 什么是 C10K 问题？（面试完整版深度补全）

C10K 问题 是互联网早期经典的单机并发性能瓶颈问题 ，全称 Client 10K，核心定义为：传统同步阻塞Web服务器，无法稳定支撑单机1万及以上并发TCP连接，是早期Web服务高并发落地的核心阻碍。该问题最早在1999年被提出，彼时主流服务器架构完全无法适配万级并发场景。

一、传统服务器产生C10K瓶颈的核心原因

早期 Apache、Tomcat 采用一连接一线程/一连接一进程的同步阻塞架构，存在三大致命短板，直接触发C10K瓶颈：

1. 线程资源上限极低：操作系统对线程数量有严格限制，单机最大线程数通常仅有数千，无法创建上万线程支撑万级连接。

2. CPU上下文切换爆炸：若强行开启上万线程，CPU需要频繁在不同线程间切换上下文，绝大部分算力消耗在切换调度上，几乎无法处理业务请求，服务直接卡顿、宕机。

3. 同步阻塞等待浪费资源：线程建立连接后，会阻塞等待客户端请求数据，大量线程处于空闲阻塞状态，资源被无效占用，系统吞吐量急剧下降。

二、Nginx 完美解决 C10K 问题的核心原理

Nginx 彻底摒弃传统同步阻塞多线程架构，通过四大核心设计突破万级并发瓶颈，不仅解决C10K问题，还实现单机十万、百万级并发（C100K）：

1. epoll IO多路复用模型（核心） ：单Worker线程可监听数万甚至数十万Socket连接，仅对「读写就绪的活跃连接」处理请求，空闲连接不占用任何CPU资源，彻底杜绝无效阻塞与轮询开销。

2. 异步非阻塞请求处理：全程无线程阻塞、无等待，请求处理不卡顿线程流程，单线程极致压榨CPU算力。

3. Master+Worker 多进程架构：多进程适配多核CPU，无共享内存、无锁竞争，进程独立运行，稳定性与并发能力双重拉满。

4. 资源池复用机制：连接、内存、文件句柄统一复用，避免频繁创建销毁资源的系统开销，支撑海量长连接稳定运行。

三、延伸：C100K 问题

C100K 即单机十万级并发连接瓶颈，传统服务器完全无法企及，而Nginx凭借上述架构优势，无需特殊硬件配置，普通服务器即可轻松突破十万级并发，完美适配现代互联网高并发业务场景。

四、30秒极简面试背诵版

C10K问题是传统同步阻塞服务器无法支撑单机一万并发连接的性能瓶颈，核心原因是一连接一线程架构存在线程上限低、CPU上下文切换开销大、连接阻塞浪费资源的问题。Nginx通过epoll IO多路复用、异步非阻塞模型、多进程架构和资源复用机制，彻底解决C10K瓶颈，单机可轻松支撑十万级以上并发，是高并发Web服务的核心架构优势。

33. Nginx 是否支持将请求压缩到上游？（面试完整版深度补全）

核心结论 ：Nginx 官方开源版原生不支持【客户端请求体压缩后转发上游】 ，仅原生支持后端响应体压缩后返回客户端 ；如需实现请求上行压缩（压缩客户端请求转发给后端上游服务），必须依赖第三方模块或业务层适配，二者极易混淆，是面试高频易错点。

一、两类压缩场景核心区分（必背）

1. 下行响应压缩（原生支持） 客户端请求→Nginx→上游服务返回数据→Nginx Gzip压缩 →返回客户端。 通过自带 ngx_http_gzip_module + gzip_proxied 配置即可实现，是生产最常用的压缩场景，无需额外插件。gzip_proxied 专门用于开启代理场景下后端响应的压缩能力，适配反向代理架构。

2. 上行请求压缩（原生不支持） 客户端上传压缩请求体→Nginx→压缩请求转发上游服务。 Nginx 原生无任何指令可压缩客户端请求体并转发给上游，默认只会透传原始请求数据，无法实现上行压缩。

二、原生模块能力详解

Nginx 内置的 gzip、gunzip 模块仅作用于响应输出阶段：

• gzip模块：压缩Nginx返回给客户端的响应数据，不处理上行请求；

• gunzip模块 ：用于解压客户端上传的Gzip请求体，方便后端读取原始数据，只能解压、不能压缩上行请求；

• gzip_proxied指令：仅控制「是否对上游返回的响应做Gzip压缩」，和上行请求压缩无关。

三、实现上游请求压缩的两种生产方案

1、第三方模块实现（技术方案可行）

通过 ngx_http_gzip_request_module 第三方拓展模块，可实现客户端请求体Gzip压缩后转发上游，补齐Nginx原生短板，适配大文件上传、大数据接口请求场景。该模块需重新编译Nginx引入，不属于官方原生模块。

2、业务层兜底方案（生产主流）

绝大多数企业生产环境不改造Nginx，采用业务层适配： 客户端直接压缩请求体上传 → Nginx透明透传 → 上游后端服务自行解压处理。 优势：零网关改造、稳定性高、无兼容性问题，是行业通用最优解。

四、高频面试避坑点

1. 不要混淆请求上行压缩 和响应下行压缩，Nginx仅原生支持后者；

2. gzip_proxied 不开启上行压缩，仅开启代理响应下行压缩；

3. gunzip是解压模块，无法实现请求压缩转发；

4. 开源版无原生上行压缩能力，商业版Nginx Plus也未内置该功能。

五、30秒极简面试背诵版

Nginx原生仅支持后端响应下行Gzip压缩返回客户端，可通过gzip_proxied开启代理场景响应压缩；原生不支持客户端请求上行压缩转发上游服务。如需实现上行请求压缩，可通过第三方gzip_request模块编译拓展，生产主流方案为客户端压缩、Nginx透传、后端自行解压，规避网关改造风险。

34. 如何在 Nginx 中获得当前的时间？（面试完整版+实战配置）

Nginx 内置两个专属全局时间变量，可直接获取服务器当前时间，无需自定义脚本、无需第三方模块，原生支持日志打印、请求匹配、时间规则限流、动态参数拼接等场景，是运维与流量规则开发的常用基础变量，两个变量适配不同业务场景。

一、两大核心时间变量（原生内置、开箱即用）

• $time_local ：服务器本地格式化时间，默认格式为 YYYY/MM/DD HH:MM:SS，可读性极强，是日志记录、时间展示的首选变量，适配国内服务器时区展示习惯。

• $time_iso8601 ：ISO8601标准时间格式，格式为 YYYY-MM-DDTHH:MM:SS+时区，格式标准化、可直接用于接口参数、时间校验、日志归档，适配程序解析、数据对接场景。

二、核心变量区别（面试易错点）

1. 格式不同：time_local 斜杠分隔、无时区；time_iso8601 横杠标准格式、携带时区信息，符合国际时间规范。

2. 用途不同：time_local 侧重人工查看日志、运维排查；time_iso8601 侧重程序解析、数据存储、接口参数传递。

3. 通用性不同：ISO8601格式是行业通用标准，适配日志采集工具（ELK）、监控系统、业务数据对接，兼容性更强。

三、生产实战落地场景（可直接复制配置）

1、自定义日志格式，记录请求精准时间（最常用）

在http层级自定义日志格式，打印标准化时间，方便日志分析与故障定位：

http {
    # 自定义日志格式，同时携带本地时间+标准ISO时间
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" $request_time iso_time:$time_iso8601';
    access_log  /usr/local/nginx/logs/access.log  main;
}

2、根据时间段限流/放行请求（动态时间规则）

利用时间变量匹配工作时段、夜间时段，实现差异化流量管控，比如仅工作日白天放行后台接口：

server {
    listen 80;
    server_name admin.test.com;

    # 匹配夜间23点-次日6点，禁止后台访问
    if ($time_local ~* \d{4}/\d{2}/\d{2} (23|00|01|02|03|04|05):) {
        return 403;
    }

    location / {
        proxy_pass http://backend_admin;
    }
}

3、响应头返回请求时间，辅助业务排查

在响应头携带Nginx服务器时间，方便前后端联调、定位时间时差问题：

location /api/ {
    add_header X-Nginx-Time-Local $time_local;
    add_header X-Nginx-Time-Iso $time_iso8601;
    proxy_pass http://backend_cluster;
}

四、拓展：高精度时间变量

Nginx 还内置 $msec 变量，返回当前时间的毫秒级时间戳，用于精准统计接口耗时、请求时间差，适配高精度性能监控场景，是性能优化排查的核心变量。

五、30秒极简面试背诵版

Nginx通过三个原生内置变量获取当前服务器时间：time_local为本地可读格式化时间，多用于运维日志查看；time_iso8601为ISO标准带时区时间，适配程序解析、数据对接；$msec为毫秒级时间戳，用于高精度耗时统计。可用于自定义日志、时间段限流、响应头时间返回等场景，无需额外插件，原生直接生效。

35. 用 Nginx 服务器解释 -s 的目的是什么？（面试完整版深度补全）

核心定义 ：nginx -s 是 Nginx 官方内置的进程信号管控命令，核心作用是向 Nginx Master 主进程发送管控信号，实现服务停止、配置重载、日志切割等运维操作，无需手动杀死进程、无需重启服务，是生产环境 Nginx 日常运维的核心指令。

该命令依托 Nginx 主从进程架构实现，所有信号仅作用于 Master 进程，由 Master 进程调度管理所有 Worker 工作进程，保障运维操作的安全性与稳定性。

一、四大核心指令完整详解（生产必用+面试必考）

(1)nginx -s stop（快速停止/强制停止）

原理 ：向 Master 进程发送 TERM 信号，强制立即终止所有 Master、Worker 进程，直接断开所有正在处理的用户请求，不等待请求执行完毕。

适用场景 ：服务异常卡死、紧急下线、测试环境快速重启，生产正式环境禁止使用，会造成用户请求中断、数据丢失。

(2)nginx -s quit（优雅停止）

原理 ：向 Master 进程发送 QUIT 信号，不会强制终止进程，会等待所有正在处理的请求执行完成、连接释放后，再逐步关闭 Worker 进程、最终退出 Master 进程，全程不中断正常业务请求。

适用场景：生产服务正常停机维护、版本下线、服务器关机，是生产停机的唯一规范指令。

(3)nginx -s reload（平滑重启/配置重载）

原理 ：最核心、最常用的生产指令。Master 进程不退出，首先校验新配置语法合法性，配置无误后，启动一批新的 Worker 进程加载新配置 ，同时逐步关闭旧的 Worker 进程（等待旧请求处理完毕再销毁）。 全程零服务停机、零请求中断，实现配置热更新、业务平滑迭代。

适用场景：修改反向代理、限流、负载均衡、静态缓存等所有配置后的生效操作。

(4)nginx -s reopen（日志切割）

原理：向 Master 进程发送 USR1 信号，通知 Nginx 重新打开日志文件，实现日志切割轮转。 生产中日志文件分割后，无需重启服务，通过该指令让 Nginx 写入新日志文件，避免日志持续堆积、单日志文件过大。

适用场景：定时日志切割、日志归档、日志文件轮换运维。

二、面试高频易错点对比

1. stop 和 quit 核心区别：stop 强制断连、丢失请求；quit 优雅等待请求结束，生产停机只用 quit。

2. reload 不是重启服务：reload 仅重启 Worker 工作进程，Master 进程始终存活，服务全程在线，无停机时间。

3. reopen 不重启进程：仅重新挂载日志文件，不改动任何进程和业务配置，纯日志运维操作。

三、生产最佳实践

1. 配置修改后先执行 nginx -t 校验语法，再执行 nginx -s reload，避免配置错误导致服务异常；

2. 生产环境停机统一使用 nginx -s quit，杜绝 stop 强制停机；

3. 搭配定时任务执行 nginx -s reopen，实现日志自动切割归档。

四、30秒极简面试背诵版

nginx -s 是Nginx进程信号管控指令，用于运维管控服务。包含四大核心操作：stop强制快速停服务、中断请求；quit优雅停机，等待请求结束再退出；reload平滑重载配置，Master进程不重启、业务零中断，是配置更新核心指令；reopen用于日志切割，重新挂载日志文件。生产优先使用quit停机、reload更新配置，禁用stop强制停机。

nginx -s 发送信号控制进程：

• nginx -s stop：快速强制停止，断开连接；

• nginx -s quit：优雅停止，处理完现有连接再退出；

• nginx -s reload：平滑重启，加载新配置，不中断业务；

• nginx -s reopen：重新切割日志文件（日志切割用）。

36. 如何在 Nginx 服务器上添加模块？（面试完整版+生产实操步骤）

Nginx 添加自定义/第三方模块分为静态编译添加（全版本通用） 和**动态模块加载（Nginx1.9.11+ 新版特性）**两种方式，核心区别为是否需要重新编译整体Nginx、是否中断服务。生产中优先使用动态模块，兼容稳定、运维成本更低，以下是完整原理+实操步骤+优缺点对比。

一、静态编译添加模块（传统方案，全版本支持）

该方式适用于所有Nginx版本，核心原理是基于原有Nginx源码，重新编译整合新模块，将模块代码直接编译进Nginx主程序，永久生效，无法单独卸载。

1、完整生产实操步骤

1. 准备源码与模块包：保留当前Nginx对应版本源码（关键！必须同版本编译，避免版本不匹配报错），下载所需第三方模块源码，存放至源码同级目录。

2. 查看原有编译参数 ：执行 nginx -V 复制原有全部 configure 编译参数，保证新编译配置与原服务一致，避免功能丢失。

3. 追加模块重新配置 ：进入Nginx源码目录，拼接原有编译参数，通过 --add-module=模块绝对路径 添加第三方模块（静态模块）。 示例：./configure 原有全部参数 --add-module=/usr/local/nginx-module/nginx_upstream_check_module

4. 编译安装（仅编译不覆盖） ：执行 make 编译，禁止直接执行make install，避免覆盖现有运行环境。

5. 平滑替换二进制程序 ：停止Nginx服务，将编译生成的 objs/nginx 二进制文件，替换原有 sbin/nginx 程序。

6. 校验重启 ：执行 nginx -t 校验配置，无误后启动服务，模块永久生效。

2、核心优缺点

• 优点：全版本兼容、模块与Nginx深度融合、运行性能稳定、无额外加载开销；

• 缺点：操作繁琐、必须重新编译、模块无法动态卸载，增减模块均需重新编译替换程序，生产风险较高。

二、动态模块加载（主流生产方案，Nginx1.9.11+支持）

Nginx 1.9.11 及以上版本支持动态模块（Dynamic Module） ，核心原理是将第三方模块编译为独立的 .so 动态库文件，无需重新编译整个Nginx，无需替换主程序，通过配置文件按需加载、卸载，不影响原有服务架构。

1、完整生产实操步骤

1. 环境校验 ：执行 nginx -v 确认版本≥1.9.11，支持动态模块功能。

2. 保留源码、查看编译参数 ：同静态编译，保留对应版本源码，通过 nginx -V 获取原有编译参数。

3. 编译动态模块 ：进入源码目录，拼接原有参数，通过 --add-dynamic-module=模块路径 编译生成动态库。 示例：./configure 原有参数 --add-dynamic-module=/模块源码路径，执行 make 编译。

4. 获取动态库文件 ：编译完成后，在 objs/modules/ 目录下生成 xxx.so 动态模块文件。

5. 配置加载模块 ：在Nginx主配置文件 nginx.conf 最顶部 添加加载指令： load_module modules/xxx.so;

6. 校验生效 ：执行 nginx -t 校验配置，nginx -s reload 平滑重载，模块无需停机即可生效。

2、核心优缺点

• 优点：无需重编Nginx主程序、不替换原有二进制文件、支持动态加载/卸载、运维风险低、适配生产不停机迭代；

• 缺点：仅支持1.9.11以上高版本Nginx，低版本无法使用。

三、静态模块 vs 动态模块 核心对比（面试高频）

1. 适配版本：静态模块全版本通用；动态模块仅Nginx1.9.11+支持。

2. 编译方式：静态模块编译进Nginx主程序；动态模块编译为独立.so库文件。

3. 启停影响：静态模块需停机替换程序；动态模块可热加载、不停机生效。

4. 可维护性：静态模块无法单独卸载；动态模块可通过注释load_module指令快速禁用。

5. 生产选型：高版本Nginx优先动态模块，老旧低版本只能使用静态编译模块。

四、生产避坑要点（面试加分）

1. 源码版本必须一致：编译模块的源码版本，必须与当前运行的Nginx版本完全一致，否则会出现版本不兼容、服务启动失败；

2. 编译参数必须完整：重新编译时必须携带原有全部configure参数，否则会丢失原有负载均衡、gzip、rewrite等内置功能；

3. 禁止生产随意make install：静态编译仅执行make，手动替换程序，make install会覆盖现有配置、日志、程序，导致服务异常；

4. 动态模块加载位置：load_module指令必须放在nginx.conf文件最顶部，全局生效，放在http/server块内会报错。

五、30秒极简面试背诵版

Nginx添加模块分静态编译和动态加载两种方式。低版本用静态编译，通过--add-module参数将模块编译进主程序，需替换二进制文件、稳定性高但运维繁琐；1.9.11+高版本优先动态模块，通过--add-dynamic-module编译.so动态库，在配置文件顶部用load_module加载，支持热更新、无需停机、可灵活卸载。生产核心要点是保证源码版本一致、保留原有编译参数，避免服务功能丢失。

核心命令总结：

• 静态添加模块：./configure --add-module=模块路径 + make编译替换程序

• 动态添加模块：./configure --add-dynamic-module=模块路径 + load_module加载库文件

37. 生产中如何设置 worker 进程的数量呢？（面试满分完整版：原理+场景+调优规范）

Nginx worker_processes 用于配置工作进程数量，是核心性能调优参数，直接决定CPU多核利用率与并发处理能力。配置核心原则：贴合业务场景、适配CPU核心、避免资源浪费与性能抢占，不盲目配置最大数，不同业务场景对应最优配置，同时适配Nginx多进程架构特性。

一、核心前置原理

Nginx Master进程仅负责管理调度，不处理业务请求；所有HTTP/代理请求、IO处理均由Worker工作进程完成。Worker进程为CPU密集型调度，进程数与CPU核心数匹配时，可最大化利用多核算力，避免进程过多导致CPU上下文切换、进程抢占资源，或进程过少导致核心闲置、性能浪费。

二、三大生产场景标准配置（企业通用规范）

1、通用默认配置（适配90%普通业务）

配置指令 ：worker_processes auto;

解析：Nginx自动识别服务器CPU核心数，自动匹配进程数（核心数=Worker进程数），官方推荐默认配置。无需人工干预，适配绝大多数混合业务（静态资源+反向代理+接口转发），开箱即用、零调优成本、稳定性最强。

2、静态资源密集型场景（纯静态托管、CDN节点、文件服务）

最优配置 ：Worker进程数 = CPU物理核心数

原理 ：静态资源处理（sendfile零拷贝、文件读取）属于CPU轻密集、IO低耗时操作，单Worker进程处理效率极高。进程数等于核心数可独占CPU算力，无进程冗余、无上下文切换开销，多进程反而会造成资源抢占、性能下降。

示例 ：8核CPU服务器，配置 worker_processes 8;

3、反向代理/IO密集型场景（微服务网关、接口转发、负载均衡）

最优配置 ：Worker进程数 =CPU物理核心数 × 2

原理 ：反向代理业务存在大量后端请求等待、网络IO阻塞、超时重试场景，属于IO密集型业务。单个Worker进程会频繁进入阻塞等待状态，CPU核心会闲置，双倍进程数可充分打满CPU算力，利用空闲CPU资源处理更多并发请求，大幅提升整体吞吐量。

示例 ：8核CPU服务器，配置 worker_processes 16;

三、配套核心调优参数（必须搭配生效）

调整Worker进程数后，必须同步修改单进程连接数，否则并发上限无法提升：

# 全局进程配置
worker_processes auto; # 或 核心数/核心数*2
worker_rlimit_nofile 65535; # 提升单进程文件句柄上限

events {
    use epoll;
    worker_connections 65535; # 单进程最大并发连接数
    multi_accept on;
}

集群总并发上限公式：总连接数 = worker_processes × worker_connections

四、生产严格避坑规则（面试高频考点）

1. 禁止超配进程：Worker进程数严禁远超CPU核心数2倍，过多进程会引发频繁CPU上下文切换、锁竞争，导致CPU占用飙升、吞吐量断崖式下跌。

2. 区分物理核心/逻辑核心 ：配置以CPU物理核心数为准，不参考超线程逻辑核心，避免过度配置。

3. 不建议低配固定值：禁止固定配置1、2个进程，多核服务器会造成大量CPU核心闲置，浪费服务器算力资源。

4. 动态优先于静态 ：未知业务场景、混合业务优先使用 auto 自动适配，兼顾性能与稳定性。

五、30秒极简面试背诵版

生产中Nginx worker进程配置分三种场景：通用混合业务使用auto自动匹配CPU核心数，稳定零调优；静态资源IO轻量业务，进程数等于CPU物理核心数，避免资源抢占；反向代理IO密集型网关业务，进程数设为核心数两倍，打满闲置CPU算力。

同时配套调高单进程文件句柄和连接数，禁止超配进程导致CPU切换开销过大，最大化保障高并发性能与服务稳定性。

38. Nginx 完整状态码大全（标准HTTP+Nginx专属扩展，带生产排查释义）

一、1xx 信息性状态码（请求接收中，继续处理）

100 Continue：继续请求，客户端可继续发送请求体，服务端已接收请求头，等待完整请求数据，多用于大文件上传场景。

101 Switching Protocols：协议切换成功，常见于HTTP升级为WebSocket、HTTPS协议协商场景。

102 Processing：服务端正在处理请求，无响应数据返回，避免客户端超时断开（极少用）。

二、2xx 成功状态码（请求完全正常响应）

200 OK：请求成功，服务端正常返回所有资源数据，生产最常用成功状态码。

201 Created：资源创建成功，多用于POST新增接口、文件上传创建资源场景。

202 Accepted：请求已接收，正在异步处理，暂未返回最终结果。

204 No Content：请求成功，但无任何响应内容返回，常用于纯回调、删除接口。

206 Partial Content：分片请求成功，断点续传、视频/大文件分片下载专用状态码。

三、3xx 重定向/缓存状态码（资源跳转、缓存复用）

301 Moved Permanently：永久重定向，资源永久迁移至新URL，浏览器永久缓存跳转规则，适配域名永久迁移、HTTP强制跳转HTTPS。

302 Found：临时重定向，资源临时跳转，不缓存跳转规则，适配临时页面跳转、登录拦截跳转。

303 See Other：请求成功，跳转至新资源页面，常用于POST请求跳转GET页面，防止重复提交。

304 Not Modified：协商缓存命中，资源未更新，服务端不返回新数据，浏览器直接复用本地缓存，大幅减少带宽消耗。

307 Temporary Redirect：临时重定向，保留原请求方法与请求体，区别于302，适配POST请求跳转场景。

308 Permanent Redirect：永久重定向，保留原请求方法，适配永久迁移的POST接口跳转。

四、4xx 客户端错误状态码（请求非法，客户端问题）

400 Bad Request：请求非法，请求报文格式错误、参数异常、JSON格式错误、请求头不合法，Nginx无法解析请求。

401 Unauthorized：未授权/未登录，无身份凭证、Token过期失效，需重新登录认证。

402 Payment Required：预留状态码，多用于付费接口、额度超限场景，极少通用业务使用。

403 Forbidden：权限拒绝，核心原因：Nginx文件目录权限不足、IP被封禁、跨域拦截、防盗链拦截、接口无访问权限。

404 Not Found：资源不存在，请求URL路径错误、静态文件丢失、后端接口路由不存在。

405 Method Not Allowed：请求方法不允许，接口仅支持GET/POST，客户端使用PUT/DELETE/OPTIONS等非法方法请求。

406 Not Acceptable：响应资源格式不匹配客户端Accept请求头，无法适配客户端解析格式。

408 Request Timeout：客户端请求超时，长时间未发送完整请求数据、网络卡顿。

409 Conflict：请求冲突，资源版本冲突、重复提交、数据状态不一致导致请求失败。

410 Gone：资源永久删除，旧接口、旧页面已下线，无法恢复访问。

411 Length Required：缺少Content-Length请求头，非法请求格式。

413 Request Entity Too Large：请求体过大，超出Nginx client_max_body_size配置限制，文件上传超限专属报错。

414 Request-URI Too Long：请求URL过长，参数过多、恶意超长链接请求被拦截。

415 Unsupported Media Type：请求体数据格式不支持，后端不接收当前Content-Type类型。

429 Too Many Requests：请求过多被限流，触发Nginx limit_req/limit_conn限流规则，防刷拦截。

五、5xx 服务端错误状态码（Nginx/后端服务异常，生产高频报错）

500 Internal Server Error：服务端内部异常，后端代码报错、脚本执行失败、Nginx配置语法隐性错误、权限严重异常。

501 Not Implemented：服务器不支持当前请求方法、协议，无法完成请求处理。

502 Bad Gateway：网关错误（生产最高频），后端服务宕机、未启动、端口未监听、程序崩溃、Nginx转发地址错误、后端无响应。

503 Service Unavailable：服务不可用，后端服务过载、集群节点全部下线、服务维护中、Nginx限流熔断、节点全部故障被剔除。

504 Gateway Timeout：网关超时，后端接口响应过慢、数据库查询卡顿、网络延迟高，超出Nginx proxy_read_timeout超时配置。

505 HTTP Version Not Supported：服务器不支持客户端请求的HTTP协议版本。

507 Insufficient Storage：服务器存储空间不足，无法处理请求（文件上传、资源存储场景）。

六、Nginx 专属扩展状态码（面试/生产独有，高频排查重点）

444 No Response：Nginx专属，主动关闭连接、不返回任何响应，多用于拦截恶意请求、爬虫、攻击流量，静默拦截。

499 Client Closed Request：客户端主动断开连接，请求未完成就关闭页面、取消请求、网络中断，服务端未响应完毕。

400 Request Header Or Cookie Too Large：请求头/Cookie过大，超出Nginx缓冲区配置限制，需调大client_header_buffer_size。

七、面试30秒极简背诵版（高频核心汇总）

1xx为请求协商状态；

2xx请求成功，核心200正常响应、206分片下载；

3xx为重定向与缓存，301永久重定向、302临时重定向、304缓存命中；

4xx客户端错误，核心400参数非法、401未认证、403权限拒绝、404资源不存在、413上传超限、429限流；

5xx服务端错误，核心500程序异常、502后端宕机、503服务不可用、504网关超时；

Nginx独有444静默拦截恶意请求、499客户端主动断连。