1.1 Nginx 在运维场景中的核心定位#

Nginx 是现代互联网基础设施中最关键的组件之一。在企业运维场景中，它凭借三大核心优势成为首选：

高并发与低资源占用是 Nginx 的天然禀赋。相比 Apache 的进程/线程模型，Nginx 采用异步非阻塞的事件驱动架构，可以在单台服务器上轻松处理数万并发连接，同时内存占用仅为 MB 级别。这意味着即使是配置不高的云服务器也能撑起可观的业务流量。

反向代理是 Nginx 最频繁的企业用途。它站在用户和后端应用之间，隐藏真实服务器身份，分发请求到多个后端节点，实现流量分摊和故障隔离。这样既保护了内部系统，也大幅提升了可用性。

静态资源服务与负载均衡则是 Nginx 的双翼。前者让 Nginx 成为高效的文件服务器（极快的静态文件响应速度），后者让它成为流量分配的大脑（支持多种算法的负载均衡）。这三大用途的结合，使 Nginx 成为搭建高可用系统的基石。

1.2 企业三种主流安装方式对比#

生产环境的 Nginx 安装方案没有绝对的”最优”，但有最适合的。下表对比三种方案：

核心建议：内网离线或需要特定模块时选源码编译；标准生产环境用官方 YUM/APT 源（维护成本最低）；容器化项目优先 Docker。

1.3 生产环境推荐安装实操#

以 CentOS/RHEL 为例，使用官方 YUM 源是最规范的做法：

1
# 1. 配置官方 YUM 源（一次性）
2
cat > /etc/yum.repos.d/nginx.repo <<EOF
3
[nginx-stable]
4
name=nginx stable repo
5
baseurl=http://nginx.org/packages/centos/\$releasever/\$basearch/
6
gpgcheck=1
7
enabled=1
8
gpgkey=https://nginx.org/keys/nginx_signing.key
9
EOF
10

11
# 2. 安装 Nginx
12
yum install -y nginx
13

14
# 3. 启动服务
15
systemctl start nginx
16
systemctl enable nginx

源码编译方案（需要特定模块时）：

1
# 下载源码
2
cd /tmp && wget http://nginx.org/download/nginx-1.24.0.tar.gz
3
tar -xzf nginx-1.24.0.tar.gz && cd nginx-1.24.0
4

5
# 配置常用模块
6
./configure \
7
  --prefix=/etc/nginx \
8
  --sbin-path=/usr/sbin/nginx \
9
  --modules-path=/usr/lib64/nginx/modules \
10
  --with-http_ssl_module \
11
  --with-http_v2_module \
12
  --with-http_realip_module \
13
  --with-http_gzip_static_module
14

15
# 编译安装
16
make && make install

关键参数说明

• --with-http_ssl_module：HTTPS 必需
• --with-http_v2_module：HTTP/2 支持
• --with-http_gzip_static_module：静态压缩优化
• --with-http_realip_module：代理场景下获取真实 IP

1.4 安装后的基础运维操作#

安装完成后，这四个操作是运维日常必备：

1
# 查看版本与编译参数
2
nginx -v
3
nginx -V
4

5
# 检验配置语法（修改配置后必做）
6
nginx -t
7

8
# 平滑重启（不中断现有连接）
9
nginx -s reload
10

11
# 强制重启（中断所有连接）
12
systemctl restart nginx

重点区别

• nginx -s reload：主进程读取新配置生成新 worker，旧 worker 处理完现有请求后退出，零中断
• systemctl restart：暴力杀死所有进程重启，会导致活跃连接断开，生产环境严禁使用

2.1 域名访问的完整链路#

当用户在浏览器地址栏输入 www.example.com 时，看似简单的访问实际上经历了四个关键步骤：

第一步：DNS 解析 浏览器先向 DNS 服务器查询 www.example.com 对应的 IP 地址。DNS 递归查询会依次经过本地 DNS、根域名服务器、顶级域名服务器、权威 DNS，最终获得服务器 IP（比如 203.0.113.5）。这一步的作用是将人类可读的域名翻译成机器可识别的 IP。

第二步：TCP 三次握手 浏览器拿到 IP 后，与 Nginx 所在服务器建立 TCP 连接。三次握手的过程是：客户端发送 SYN → 服务器回复 SYN-ACK → 客户端发送 ACK，建立可靠的通信通道。这一步的作用是确保两端都做好了数据传输的准备。

第三步：发送 HTTP 请求 TCP 连接建立后，浏览器按照 HTTP 协议格式发送请求，包含请求行、请求头、请求体。请求头中最关键的是 Host 字段（值为 www.example.com），这个字段后文会详细讲。

第四步：Nginx 接收与处理 Nginx 的 worker 进程接收到请求后，开始内部的配置匹配和处理流程（详见 2.2 章）。

2.2 Nginx 内部的请求处理阶段#

请求到达 Nginx 后，内部会经历五个阶段：

阶段一：读取配置 Nginx 从内存中加载已解析的配置树。这就是为什么修改配置后必须执行 nginx -s reload，让主进程重新读取配置文件并生成新的 worker 进程。

阶段二：匹配虚拟主机 Nginx 会查看请求头中的 Host 字段，与配置文件中的 server_name 逐一比对。当找到匹配的 server 块后，本阶段结束。如果没有任何 server 块匹配，则使用第一个 server 块（或 default_server 标记的块）作为默认处理。

阶段三：匹配位置规则 在选定的 server 块内，Nginx 会对请求的 URI（如 /api/users/123）与所有 location 块进行匹配。Nginx 首先精确匹配（location =），再前缀匹配（location ^~），最后正则匹配（location ~），选择优先级最高的那个 location 块。

阶段四：生成响应 根据 location 块的指令执行具体操作。可能是：返回静态文件（从 root 或 alias 指定的目录读取），或者代理请求到后端服务器（proxy_pass），或者执行其他逻辑。

阶段五：返回客户端 Nginx 将响应头和响应体发送回浏览器。浏览器接收完成后，根据 Connection 和 Keep-Alive 字段判断是否保持连接或关闭连接。

2.3 多域名共用一台服务器的原理#

这是初学者最困惑的问题：为什么一个 80 端口能跑多个网站？

答案就在 HTTP 请求头的 Host 字段。当浏览器访问 www.example.com 时，实际发送的 HTTP 请求是这样的：

1
GET / HTTP/1.1
2
Host: www.example.com
3
Connection: keep-alive
4
...

Nginx 接收到请求后，读取 Host: www.example.com 这一行，然后在配置文件中查找：

1
server {
2
    listen 80;
3
    server_name www.example.com;
4
    root /var/www/example;
5
}
6

7
server {
8
    listen 80;
9
    server_name www.other.com;
10
    root /var/www/other;
11
}

通过 server_name 的匹配，Nginx 能够判断这个请求应该由第一个 server 块处理，从而返回 /var/www/example 目录下的文件。如果请求的是 www.other.com，就由第二个 server 块处理，返回 /var/www/other 下的文件。

本质上，多域名共用一个 IP 和端口，是通过 HTTP 请求头中的 Host 字段来区分的。 这就是虚拟主机（Virtual Host）的核心原理。

3.1 什么是虚拟主机#

虚拟主机（Virtual Host）是一种在单台物理服务器上运行多个独立网站的技术。它的核心思想是：逻辑分离，物理共用。

一台物理 Nginx 服务器，通过配置多个 server 块，可以对外提供多个完全独立的网站。每个网站有独立的域名、根目录、日志、权限配置，用户感觉就像访问不同的服务器，但实际上它们共享同一台硬件。

虚拟主机的分辨方式有三个维度：

1. 基于域名（最常用）：同一个 IP 和端口，通过 Host 请求头区分
2. 基于端口（中等常用）：同一个 IP，不同端口对应不同网站
3. 基于 IP（较少使用）：同一个服务器的多个网卡 IP，每个 IP 一个网站

3.2 三种虚拟主机类型与适用场景#

基于域名的虚拟主机

最高效，最符合现代互联网使用习惯。企业内部几十个项目、客户服务等，都可以用不同的二级域名运行在同一个 Nginx 实例上，充分利用服务器资源。

1
listen 80;
2
server_name www.example.com example.com;  # 支持多个域名

基于端口的虚拟主机

当需要在同一个 IP 上暴露多个”独立入口”时使用。比如管理后台用 8080 端口，业务站用 80 端口。缺点是用户需要在 URL 中显式指定端口（如 http://example.com:8080），不太优雅。

1
server {
2
    listen 80;
3
    server_name example.com;
4
}
5

6
server {
7
    listen 8080;
8
    server_name example.com;
9
}

基于 IP 的虚拟主机

服务器有多个网卡或 IP 时，每个 IP 绑定一个网站。这种方式在云环境中已基本淘汰（弹性 IP 变动频繁），仅在物理机多 IP 场景下使用。

3.3 基于域名的虚拟主机配置示例#

最常见的配置就是基于域名，这是初学者必须掌握的最基础配置单元：

1
server {
2
    # 1. 监听的端口，80 是 HTTP 默认端口
3
    listen 80;
4

5
    # 2. 虚拟主机的域名，支持精确匹配和通配符
6
    server_name www.example.com example.com;
7

8
    # 3. 网站根目录，所有静态文件都从这里查找
9
    root /var/www/example;
10

11
    # 4. 目录访问时默认返回的文件（按顺序查找）
12
    index index.html index.htm;
13

14
    # 基础位置规则：返回静态文件
15
    location / {
16
        # 如果请求的文件或目录不存在，返回首页（SPA 应用常用）
17
        try_files $uri $uri/ /index.html;
18
    }
19
}

逐行解析

• listen 80：告诉 Nginx 在 80 端口监听请求
• server_name：域名匹配，支持 www.example.com（精确）、*.example.com（泛域名）、example.com ~^.*\.example\.com$（正则）
• root /var/www/example：假如请求是 /index.html，Nginx 会从 /var/www/example/index.html 读取文件
• index index.html：访问目录时，默认追加 index.html，即 / 自动变成 /index.html

4.1 三种安装方式的目录差异对比#

同样是 Nginx，因为安装方式不同，关键文件的位置也完全不同。这是初学者排查问题时最常出现的坑：

1
┌─────────────────────────────────────────────────────────────────────┐
2
│  YUM 安装（CentOS/RHEL）                                            │
3
├─────────────────────────────────────────────────────────────────────┤
4
│  主配置文件        /etc/nginx/nginx.conf                            │
5
│  额外配置目录      /etc/nginx/conf.d/*.conf                         │
6
│  执行文件          /usr/sbin/nginx                                  │
7
│  日志目录          /var/log/nginx/                                  │
8
│  运行目录          /var/run/nginx.pid                               │
9
│  缓存目录          /var/cache/nginx/                                │
10
└─────────────────────────────────────────────────────────────────────┘
11

12
┌─────────────────────────────────────────────────────────────────────┐
13
│  源码编译安装（自定义 prefix）                                      │
14
├─────────────────────────────────────────────────────────────────────┤
15
│  主配置文件        /etc/nginx/nginx.conf（根据 --prefix 定制）      │
16
│  额外配置目录      /etc/nginx/conf.d/（同上）                       │
17
│  执行文件          /usr/sbin/nginx（根据 --sbin-path 定制）         │
18
│  日志目录          /var/log/nginx/（需手动创建，权限注意）         │
19
│  运行目录          /var/run/nginx.pid（根据配置中 pid 指令）        │
20
│  缓存目录          自定义（通常在 prefix 子目录）                   │
21
└─────────────────────────────────────────────────────────────────────┘
22

23
┌─────────────────────────────────────────────────────────────────────┐
24
│  Docker 容器化安装                                                   │
25
├─────────────────────────────────────────────────────────────────────┤
26
│  主配置文件        /etc/nginx/nginx.conf（容器内路径）              │
27
│  额外配置目录      /etc/nginx/conf.d/（通常通过 volume 挂载）       │
28
│  执行文件          /usr/sbin/nginx（容器内）                        │
29
│  日志目录          /var/log/nginx/（通常输出到 stdout/stderr）     │
30
│  运行目录          /var/run/nginx.pid（容器内）                     │
31
│  缓存目录          /var/cache/nginx/（可选持久化）                  │
32
└─────────────────────────────────────────────────────────────────────┘

4.2 核心配置目录与文件作用#

在 YUM 安装的标准环境中，重要的配置文件和目录是：

1
/etc/nginx/
2
├── nginx.conf                    # 主配置文件，全局入口
3
├── conf.d/
4
│   ├── default.conf             # 默认虚拟主机配置
5
│   └── example.conf             # 自定义虚拟主机配置（推荐）
6
├── sites-available/             # 可用的站点配置（Debian/Ubuntu 风格）
7
├── sites-enabled/               # 启用的站点配置（软链接指向 available）
8
└── snippets/                    # 可复用的配置片段
9
    └── ssl-params.conf          # SSL 参数（如果使用 HTTPS）

文件作用说明

• nginx.conf：全局配置入口，定义 worker 进程数、连接超时等全局参数，最后通常会用 include /etc/nginx/conf.d/*.conf; 引入其他配置
• conf.d/ 目录：CentOS/RHEL 标准做法，每个虚拟主机写一个独立的 .conf 文件，便于管理
• sites-available/ 和 sites-enabled/：Debian/Ubuntu 的软链接模式，available 中存放所有配置，enabled 中通过 ln -s 创建软链接来启用配置，便于快速启用/禁用站点

典型的 nginx.conf 结构：

1
user nginx;                    # 指定 worker 进程的用户
2
worker_processes auto;         # 自动检测 CPU 核心数
3
error_log /var/log/nginx/error.log;
4

5
events {
6
    worker_connections 1024;   # 单个 worker 的最大连接数
7
}
8

9
http {
10
    include /etc/nginx/mime.types;
11
    default_type application/octet-stream;
12

13
    access_log /var/log/nginx/access.log;
14

15
    # 引入所有虚拟主机配置
16
    include /etc/nginx/conf.d/*.conf;
17
}

4.3 运行时与日志相关目录#

排查 Nginx 问题时，这三类文件是最重要的情报来源：

PID 文件 (/var/run/nginx.pid) 存储 Nginx 主进程的进程号。当执行 systemctl restart nginx 时，系统通过读取这个文件获知主进程 PID，然后向其发送信号。

访问日志 (/var/log/nginx/access.log) 记录每一条 HTTP 请求的详细信息：客户端 IP、请求时间、请求方法、URI、HTTP 状态码、响应字节数等。这是排查”为什么用户收不到响应”的第一手资料。

1
203.0.113.5 - - [29/Nov/2024:10:15:32 +0800] "GET / HTTP/1.1" 200 612 "-" "Mozilla/5.0"

错误日志 (/var/log/nginx/error.log) 记录 Nginx 本身的错误、警告、调试信息。遇到配置问题、宕机、性能异常时，这个日志是诊断的关键。

日志排查技巧

• 实时监控访问日志：tail -f /var/log/nginx/access.log
• 搜索特定 IP 的请求：grep "203.0.113.5" /var/log/nginx/access.log
• 查看 4xx/5xx 错误：grep " [45][0-9][0-9] " /var/log/nginx/access.log
• 错误日志有权限问题时：检查 /var/log/nginx/ 目录的所有者是否为 nginx 用户

5.1 配置文件的层级结构#

Nginx 配置文件是嵌套的块结构，层级关系决定了指令的作用域。理解这个层级是写配置的前提：

1
全局块
2
├── 主配置参数（user、worker_processes 等）
3
│
4
└── events 块
5
    └── 事件驱动模型配置（worker_connections）
6

7
└── http 块
8
    ├── HTTP 全局参数（keepalive_timeout、client_max_body_size）
9
    │
10
    ├── server 块 ①
11
    │   ├── 虚拟主机 ① 的全局参数（listen、server_name）
12
    │   │
13
    │   ├── location 块 ①-a
14
    │   │   └── 位置匹配规则（proxy_pass、root、index）
15
    │   │
16
    │   └── location 块 ①-b
17
    │       └── 位置匹配规则
18
    │
19
    └── server 块 ②
20
        ├── 虚拟主机 ② 的全局参数
21
        └── location 块 ②-a
22
            └── 位置匹配规则

作用域规则：

• 全局块的参数对所有 worker 进程生效
• events 块内的参数控制网络事件处理
• http 块内的参数对所有虚拟主机生效
• server 块内的参数仅对该虚拟主机生效，会覆盖 http 块同名参数
• location 块内的参数仅对该位置匹配生效，优先级最高

5.2 基础语法规则#

Nginx 配置的语法看似简单，但容易出错，这些规则必须掌握：

规则一：指令以分号结尾

1
user nginx;                           # ✓ 正确
2
worker_processes 4;                   # ✓ 正确
3

4
user nginx                            # ✗ 错误：缺少分号
5
worker_processes 4                    # ✗ 错误：缺少分号

规则二：块用大括号包裹

1
server {                              # ✓ 正确
2
    listen 80;
3
}
4

5
server                                # ✗ 错误：缺少大括号
6
    listen 80;

规则三：注释以 # 开头

1
# 这是一行注释
2
server {
3
    listen 80;  # 可以在行尾添加注释
4
}

规则四：字符串引号规则

大多数场景下，字符串不需要引号。但如果字符串包含空格、特殊字符，或者是正则表达式，则必须用引号：

1
server_name example.com;              # ✓ 简单字符串，不需要引号
2
server_name "My Example Site";        # ✓ 包含空格，需要引号
3
location ~ "^/api/.*\.json$" { }     # ✓ 正则表达式，需要引号
4
proxy_pass http://backend;            # ✓ URL，通常不需要引号

5.3 高频基础指令详解#

Nginx 有数百个指令，但运维最常用的也就这几十个。以下是生产环境必调的参数：

worker_processes 定义 worker 进程的数量。通常设置为 CPU 核心数，以充分利用多核性能。

1
worker_processes auto;        # 自动检测 CPU 核心数（推荐）
2
worker_processes 4;           # 手动指定 4 个进程

worker_connections 单个 worker 进程最多能开启的并发连接数。此值乘以 worker_processes 就是 Nginx 的理论最大并发连接数。

1
events {
2
    worker_connections 1024;  # 默认值，通常足够；高并发场景可调到 65535
3
}

keepalive_timeout HTTP Keep-Alive 连接的超时时间。客户端与 Nginx 连接闲置超过此时间后，Nginx 会主动关闭连接。值过小会频繁建立连接（消耗资源），值过大会占用资源（影响并发能力）。

1
keepalive_timeout 65;         # 单位秒，65 秒是 Apache 默认值，Nginx 推荐 60-65

client_max_body_size 客户端请求体的最大大小。上传文件时，如果文件超过此限制，Nginx 会返回 413 错误。

1
client_max_body_size 20M;     # 允许最大 20MB 的请求体，默认是 1MB

client_body_timeout Nginx 等待客户端发送请求体的最大时间。网络不稳定或大文件上传时可能超时。

1
client_body_timeout 12s;      # 单位秒

send_timeout Nginx 发送响应的最大时间。如果客户端在此时间内没有接收任何数据，Nginx 会关闭连接。

1
send_timeout 10s;

性能调优参数组合

对于高并发服务，这套参数是常见的组合：

1
worker_processes auto;
2
worker_rlimit_nofile 65535;         # 系统允许每个进程打开的最大文件数
3

4
events {
5
    worker_connections 10240;       # 高并发推荐值
6
    use epoll;                       # Linux 2.6+ 使用 epoll 模型
7
}
8

9
http {
10
    keepalive_timeout 60;
11
    client_max_body_size 100M;
12
    client_body_timeout 30s;
13
    send_timeout 30s;
14
}

5.4 配置校验与重载规范#

修改配置是 Nginx 运维中最常见的操作，但一个小错误可能导致服务中断。因此，严格的校验与重载流程是硬规定：

步骤一：修改配置

1
# 编辑配置文件
2
vim /etc/nginx/conf.d/example.conf

步骤二：语法校验

1
# 检查语法（强制操作，不允许跳过）
2
nginx -t
3

4
# 预期输出：
5
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
6
# nginx: configuration file /etc/nginx/nginx.conf test is successful

严禁跳过语法检查

如果直接执行 systemctl restart nginx 而配置有错误，可能导致 Nginx 无法启动，影响业务。必须先 nginx -t 验证。

步骤三：平滑重载

1
# 平滑重载（推荐，不中断现有连接）
2
nginx -s reload
3

4
# 或者用 systemctl
5
systemctl reload nginx
6

7
# 查看是否成功（应该看到新的 worker 进程）
8
ps aux | grep nginx

平滑重载的原理

1. Nginx 主进程读取新配置文件
2. 若配置无误，创建新的 worker 进程（使用新配置）
3. 向旧的 worker 进程发送 SIGWINCH 信号
4. 旧 worker 进程不再接受新连接，但继续处理已有连接
5. 旧连接处理完毕后，旧 worker 进程退出
6. 整个过程对用户完全透明，无连接中断

步骤四：验证服务

1
# 检查访问日志，确认请求正常处理
2
tail -f /var/log/nginx/access.log
3

4
# 或者直接测试
5
curl -v http://localhost/

6.1 LNMP 四个字母的含义#

LNMP 是互联网开发部署的标准全栈架构，每个字母代表一个组件：

这四个开源组件，通过松耦合的方式组合在一起，构成了一个高可用、高性能、低成本的互联网应用解决方案。LNMP 之所以流行，是因为这四个组件的特性高度互补。

6.2 LNMP 的请求流转过程#

理解 LNMP 的关键是弄清Nginx、PHP-FPM、MySQL 三者的协作流程：

场景：用户访问一个 WordPress 博客

1
用户浏览器
2
    ↓
3
    │  HTTP 请求：GET /index.php
4
    ↓
5
[Nginx Web 服务器]
6
    │
7
    ├─ 请求是静态文件（.html, .css, .js, .jpg）?
8
    │  ├─ 是 → 直接从硬盘读取，返回给用户 ✓ 快速响应
9
    │  └─ 否 → 转发给 PHP-FPM
10
    │
11
    ↓
12
[PHP-FPM 进程]
13
    │
14
    ├─ 解析 PHP 代码
15
    ├─ 执行业务逻辑
16
    ├─ 查询数据库（发送 SQL 查询）
17
    │
18
    ↓
19
[MySQL 数据库]
20
    │
21
    ├─ 执行 SQL 查询
22
    └─ 返回查询结果
23
    │
24
    ↓
25
[PHP-FPM]
26
    │
27
    ├─ 收到数据库结果
28
    ├─ 继续处理，生成 HTML 页面
29
    │
30
    ↓
31
[Nginx]
32
    │
33
    ├─ 收到 PHP 的 HTML 响应
34
    └─ 转发给用户浏览器
35
    │
36
    ↓
37
用户浏览器（显示页面）

关键点：

• Nginx 只处理静态资源和请求转发，自己不执行 PHP
• Nginx 通过 proxy_pass 或 fastcgi_pass 将动态请求转发给 PHP-FPM
• PHP-FPM 才是真正执行 PHP 代码的进程，它与 MySQL 通信获取数据
• 三者的通信方式：Nginx 和 PHP-FPM 可以通过 Unix Socket（本机，性能高）或 TCP Socket（可网络跨域）通信；PHP 和 MySQL 同样支持两种方式

6.3 LNMP 与 LAMP 的核心区别#

为什么现在企业都用 LNMP，而不是曾经流行的 LAMP（Linux + Apache + MySQL + PHP）？两者的核心差异在于 Web 服务器的并发处理模型：

Apache 的进程/线程模型

1
Apache（主进程）
2
├─ Worker 进程 ① （处理单个请求，独占资源）
3
├─ Worker 进程 ② （处理单个请求，独占资源）
4
├─ Worker 进程 ③ （处理单个请求，独占资源）
5
└─ Worker 进程 ④ （处理单个请求，独占资源）
6

7
限制：最多 256 个进程（可配置），每个进程 ~10-50MB 内存
8
问题：C10K 问题（无法高效处理 10000+ 并发）

Nginx 的事件驱动异步模型

1
Nginx（主进程）
2
└─ Worker 进程（数量 = CPU 核心数）
3
   ├─ 事件循环
4
   ├─ 异步处理请求 ①
5
   ├─ 异步处理请求 ②
6
   ├─ 异步处理请求 ③
7
   └─ ... 可处理数万个并发
8

9
特点：少数进程，单进程内部非阻塞异步处理
10
优势：极低的内存占用，能轻松处理数万并发

为什么 Nginx 性能更好

1. 内存效率：Apache 100 个并发需要 100 个进程（~2GB 内存），Nginx 只需 4 个进程（~20MB 内存）
2. 上下文切换开销：进程越少，CPU 浪费在进程切换的时间越短
3. 扩展性：Nginx 能轻松应对互联网级别的流量，Apache 则容易达到资源瓶颈

实战对比：

结论：LNMP 已经是现代互联网的标配。即便 PHP 在衰落，Nginx 搭配 Python/Node.js/Go 的组合（LNPY、LNNode、LNGO）依然广泛使用，核心优势就是 Nginx 的高性能。