企业官网建设流程全解析

1. 安装前先确定三件事：发行版、软件来源与 CPU 架构

1.1 为什么“2026 年装 nginx”第一件事不是敲命令

很多朋友找我排查 nginx 问题，第一句话都是“我按教程装了，但起不来”。细问之下，十有八九是教程里的命令和当前系统对不上：有人用 Ubuntu 的教程跑到 CentOS 上敲 apt，有人照着编译教程装到一半发现缺依赖，还有人装完发现nginx命令根本不在 PATH 里。

到 2026 年，Linux 安装 nginx 的手段比前几年更分化了。系统包管理器、官方仓库、源码编译、容器镜像四条路都有人在用，而且各自维护的版本、目录结构、服务管理方式都有差别。这不是教程写得不好，而是“安装”本身已经没有唯一标准答案。

所以在动手之前，我建议先花三分钟回答三个问题：

1. 你手上是什么发行版？Debian/Ubuntu 系、RHEL 系，还是基于它们改造的国产 Linux 发行版？
2. 你想用哪个来源装？系统自带源、nginx 官方源，还是源码编译？
3. 机器是什么 CPU 架构？x86_64、aarch64 还是其他？

这三件事没有确定下来，后面每一步都可能白做。保姆级教程的真正意义，不是把命令罗列出来让你复制，而是让你知道为什么在这个环境下要敲这些命令。

1.2 用三分钟把系统、镜像源和 CPU 架构搞清楚

拿到一台新服务器，我习惯先执行下面这几条命令，把这些信息记录下来，之后再查日志、找包、配仓库的时候会省很多事。

cat /etc/os-release uname -m getconf LONG_BIT nproc

cat /etc/os-release会输出系统的 ID、版本号、版本代号。比如 Ubuntu 24.04 会看到ID=ubuntu、VERSION_CODENAME=noble；Rocky Linux 9 会看到ID="rocky"、VERSION_ID="9"。后面配 nginx 官方源的时候，这个版本代号要原样填进去，填错了 apt 会直接提示找不到对应目录。

uname -m输出 CPU 架构。绝大多数云服务器和虚拟机是x86_64，但也有不少 ARM 架构的实例会显示aarch64。如果你要在 ARM 机器上编译安装，有些依赖包的名字会不一样，这一点后面讲编译安装时还会展开。

关于镜像源，我多说一句。国内服务器访问国外官方源有时候速度不稳定，apt 和 dnf 都支持配置国内镜像源。Debian/Ubuntu 系统改/etc/apt/sources.list或者/etc/apt/sources.list.d/下的文件，RHEL 系改 repo 文件里的baseurl。各大云厂商都维护了自己的镜像站，速度基本都能跑满带宽。等我装完系统包之后要apt update或dnf makecache，这一步如果特别慢，大概率就是源的问题。

另外很多国产 Linux 发行版看起来像 CentOS 或者 Ubuntu，但包管理器、软件源目录结构会有调整。遇到这种情况，不要硬套通用命令，先cat /etc/os-release看清它基于哪个生态，再选择对应的安装方式。

2. 快速通路：用系统包管理器把 nginx 跑起来

2.1 Ubuntu/Debian 系：apt 安装与官方源取舍

如果你的系统是 Debian 或 Ubuntu 系的，最省事的方案就是直接走 apt。命令只有两条：

sudo apt update sudo apt install -y nginx

装完之后，服务通常会被自动启动。你可以立刻用systemctl status nginx看一眼状态，再用curl -I http://127.0.0.1验证页面能不能打开。

这里有一个关键选择：用系统自带的源，还是用 nginx 官方源。

系统自带源里的 nginx 版本通常偏保守，可能比官方主线版落后一两个大版本。好处是和系统库配合得好，安全补丁也会随系统更新一起推送。如果你只是要跑一个常规站点，完全够用。但如果你需要用 nginx 官方源里更新的功能，或者希望更及时地拿到新版本，那就要手动添加官方仓库。

添加官方仓库的完整步骤是这样的，以 Ubuntu 24.04 为例：

sudo apt install -y curl gnupg2 ca-certificates lsb-release echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu noble nginx" | sudo tee /etc/apt/sources.list.d/nginx.list curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo gpg --dearmor -o /usr/share/keyrings/nginx-archive-keyring.gpg sudo apt update sudo apt install -y nginx

注意几个细节。第一，noble是 Ubuntu 24.04 的版本代号，不同版本要换掉，比如 22.04 对应jammy。第二，这种源只提供 nginx 官方编译的版本，不会和系统自带的 nginx 包同时存在，如果之前用 apt 装过，建议先卸载干净再切换。第三，在 “nginx.org/packages/ubuntu” 这一行中，架构是自动识别的，x86_64 和 aarch64 都会拿到对应包。

2.2 RHEL 系：yum/dnf 与 EPEL 的坑

RHEL 系的系统，包括 Rocky Linux、AlmaLinux、CentOS Stream 这些，包管理命令现在是dnf。直接执行：

sudo dnf install -y nginx

这里有个很大的坑：如果系统没有启用 EPEL（Extra Packages for Enterprise Linux），这个命令很可能会提示找不到 nginx 包。所以更稳妥的顺序是先装 EPEL：

sudo dnf install -y epel-release sudo dnf makecache sudo dnf install -y nginx

RHEL 系装完 nginx 之后，服务默认不会启动，要手动执行：

sudo systemctl enable --now nginx

另外，RHEL 系机器如果开着 SELinux，nginx 启动后访问页面可能遇到403 Forbidden。这不是 nginx 本身的问题，而是 SELinux 阻止了进程访问某些目录。排查时先用getenforce看当前状态，如果显示Enforcing，可以先临时切换成Permissive试一下，确认是 SELinux 的锅再决定要不要调整布尔值或者文件上下文。生产环境不要直接关掉 SELinux，正确做法是找到具体违规项，放行对应权限。

2.3 装完先别高兴，来一套快速体检

不管是 apt 还是 dnf 安装，装完后我都会按固定顺序做一套“快速体检”，确保真的能用了，而不是只看到nginx命令存在。

# 1. 查看版本 nginx -v # 2. 检查配置是否有语法错误 sudo nginx -t # 3. 确认服务是启动状态，并且已设置开机自启 systemctl status nginx --no-pager -l systemctl is-enabled nginx # 4. 本机请求一次，看返回码 curl -I http://127.0.0.1

curl -I如果返回HTTP/1.1 200 OK，说明 nginx 已经在工作。如果看到的是一堆 HTML 文本，那可能是 80 端口被其他服务占用，后面我会专门讲端口冲突的排查。

3. 需要自定义模块时的源码编译安装全流程

3.1 哪些场景必须编译安装

系统包管理器方便，但有个限制：能装的模块是固定的。你可能会遇到这些场景，包管理器满足不了：

• 需要第三方模块，比如nginx-rtmp-module、headers-more-nginx-module、lua-nginx-module；
• 需要自己选择编译参数，比如启用--with-stream（四层负载均衡）、--with-http_v2_module（HTTP/2）；
• 需要把 nginx 安装到自定义目录，方便多版本共存或者做二进制分发；
• 需要基于特定分支或者打了补丁的源码来做定制。

在 2026 年，HTTP/3 相关的编译需求比前几年明显多了。如果你要体验 HTTP/3，nginx 官方有对应的 QUIC 分支，需要通过源码编译的方式启用--with-http_v3_module。这种事情用 apt 是做不到的。

3.2 依赖准备的通用套路

源码编译最烦的不是make，而是缺依赖。很多教程直接就给./configure && make && make install，结果一执行，第一步就报错。

以 Ubuntu/Debian 系为例，我通常先装这一组：

sudo apt install -y build-essential libpcre3-dev zlib1g-dev libssl-dev

• build-essential提供 gcc、g++ 和 make；
• libpcre3-dev提供正则表达式库，nginx 的 rewrite 模块依赖它；
• zlib1g-dev提供压缩库，gzip 模块依赖它；
• libssl-dev提供 SSL/TLS 库，--with-http_ssl_module依赖它。

RHEL 系对应的安装命令是：

sudo dnf groupinstall "Development Tools" sudo dnf install -y pcre-devel zlib-devel openssl-devel

最近两三年，新发行版里 PCRE 逐渐被 PCRE2 替代，Ubuntu 24.04 上就会同时存在libpcre3-dev和libpcre2-dev。nginx 较新版本在 configure 时会自动识别系统里的 PCRE 库。如果你发现 configure 报错说找不到 PCRE，不用慌，先把libpcre3-dev装上，基本上都能解决。

3.3 configure、编译与安装，参数要一次性看清

假设我要把 nginx 安装到/usr/local/nginx，并且启用几个常用模块，完整的编译安装命令如下：

cd /usr/local/src sudo wget https://nginx.org/download/nginx-1.26.2.tar.gz sudo tar -zxvf nginx-1.26.2.tar.gz cd nginx-1.26.2 ./configure \ --prefix=/usr/local/nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_stub_status_module \ --with-http_realip_module \ --with-http_gzip_static_module \ --with-stream \ --with-stream_ssl_module \ --with-pcre make -j$(nproc) sudo make install

重点解释几个参数，别看着多就慌。

--prefix指定安装目录，nginx 的配置、日志、二进制都会放在这个目录下面。--with-http_ssl_module启用 HTTPS 支持，这是必选项，不做 HTTPS 的现代网站几乎没有。--with-stream启用四层 TCP/UDP 代理，做端口转发、数据库代理会用到。--with-http_v2_module启用 HTTP/2，如果你的站点面向用户，这个建议开。--with-http_stub_status_module会提供/nginx_status监控页，看连接数很方便，虽然现在是 Prometheus 生态更流行了，但自己排查问题时这个页仍然很实用。

make -j$(nproc)的-j参数是并行编译，nproc会返回 CPU 核心数量。如果服务器配置低，比如只有 2 核，那make -j5反而可能更慢，可以把-j去掉。

编译完成后，nginx 被安装到/usr/local/nginx。目录结构和包管理器安装的完全不同，这在后面配置的时候要特别留意。

4. 给编译版 nginx 补一个 systemd 服务

4.1 systemd 之前：自己管理进程的方式

源码编译安装后的 nginx，最大的痛点是它没有被接入 systemd。你直接敲systemctl start nginx，多半会得到一行提示：服务不存在。

很多老教程会让你写一个/etc/init.d/nginx启动脚本，或者直接在/etc/rc.local里加启动命令。这些办法在今天的新系统上已经不够体面了。Systemd 管理进程的好处是：有统一的日志、有崩溃自动拉起能力、可以用systemctl status查看健康状态。所以我强烈建议，编译装完后的第一件事，就是补一个 systemd 服务文件。

4.2 一行行写一份 nginx.service

在我的服务器上，这份服务文件长这样：

[Unit] Description=nginx - high performance web server Documentation=https://nginx.org/en/docs/ After=network-online.target Wants=network-online.target [Service] Type=forking PIDFile=/usr/local/nginx/logs/nginx.pid ExecStart=/usr/local/nginx/sbin/nginx ExecReload=/usr/local/nginx/sbin/nginx -s reload ExecStop=/usr/local/nginx/sbin/nginx -s quit PrivateTmp=true [Install] WantedBy=multi-user.target

把它保存到/etc/systemd/system/nginx.service。

几个字段值得讲明白：

Type=forking告诉 systemd：这个服务启动后会 fork 出子进程，父进程退出，子进程在后台继续跑。nginx 默认就是这种工作方式，所以必须声明，否则 systemd 会误判服务启动失败。

PIDFile指向 nginx 写入自己主进程 PID 的文件。systemd 靠它来跟踪 nginx 是否还在运行。路径要和你编译时指定的--prefix=/usr/local/nginx对得上，不然 systemd 会找不到 PID 文件，状态就会显示异常。

ExecReload和ExecStop用的是 nginx 的信号机制。nginx -s reload会平滑重载配置，不中断现有连接；nginx -s quit会优雅退出，处理完当前请求后再关闭。不要用ExecStop=/bin/kill，那样是强杀。

保存后执行：

sudo systemctl daemon-reload sudo systemctl enable --now nginx sudo systemctl status nginx --no-pager -l

看到active (running)，编译版的 nginx 才算真正融入了系统。之后你就能像管理其他服务一样管理它了。

5. 验证安装是否真正成功：端口、进程、访问页与防火墙

5.1 四个核心检查

有些时候，服务状态显示是running，但页面就是打不开。我不会只信systemctl status，还要做以下四项检查，每一项实际上都在回答不同层面的问题：

# 进程层面：nginx 是否在跑，主进程和 worker 进程是否都在 ps -ef | grep nginx # 端口层面：80 端口是否被监听，监听进程是不是 nginx ss -lntp | grep :80 # 本地请求层面：本机访问能否返回正常头信息 curl -I http://127.0.0.1 # 日志层面：有没有报错正在刷屏 sudo tail -f /var/log/nginx/error.log

ps通常能看到一个 master 进程和多个 worker 进程，如果只有 master 没有 worker，说明配置里的 worker 数量设置有问题，通常是worker_processes写成了固定数字，实际起不来。

ss -lntp里看到的监听进程必须是nginx。如果看到的是httpd或者java，那说明 80 端口被别的服务占了。这题下面第七部分会专门讲。

5.2 防火墙和云安全组：最容易漏掉的一步

本地curl通了，你高高兴兴地用浏览器访问服务器公网 IP，结果一直转圈。这种情况九成是防火墙问题。

检查分三层。第一层是本机防火墙。Debian/Ubuntu 常见的是 ufw：

sudo ufw status sudo ufw allow 80/tcp sudo ufw allow 443/tcp

RHEL 系常见的是 firewalld：

sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --reload

第二层是云平台的安全组规则。阿里云、腾讯云、AWS 这些平台都需要在控制台里把入方向的 80 和 443 端口放行。这里通过命令行是查不到的，很多新手在这卡一整天。安全组规则改完之后，通常几秒钟内生效，可以用telnet或者本机以外的机器访问测试。

第三层是 SELinux。前面提过，RHEL 系要特别关注。如果 SELinux 在Enforcing状态，nginx 对非标准目录的读写权限会被限制。遇到 403 或者连接异常，就查一下/var/log/audit/audit.log，里面会有denied的关键字。

6. 安装后必做的配置摸底：三个目录与一套默认配置

6.1 apt 安装与编译安装的目录差异

很多新手栽在“conf 文件到底在哪”这个问题上。其实这就是安装方式决定目录结构，先摸清底，后面才不会晕。

如果是 apt 安装，目录结构是这样的：

• 配置文件：/etc/nginx/
• 主配置：/etc/nginx/nginx.conf
• 可用的站点配置：/etc/nginx/sites-available/
• 启用的站点配置：/etc/nginx/sites-enabled/
• 通用配置片段：/etc/nginx/conf.d/
• 日志：/var/log/nginx/
• 二进制：/usr/sbin/nginx

如果是源码编译安装，目录是：

• 安装根目录：/usr/local/nginx/
• 配置：/usr/local/nginx/conf/nginx.conf
• 日志：/usr/local/nginx/logs/
• 默认站点页面：/usr/local/nginx/html/
• 二进制：/usr/local/nginx/sbin/nginx

两个结构的最大区别在于：apt 版把sites-available和sites-enabled分开了，通过符号链接决定哪些站点生效；编译版只有conf.d的概念。很多照着网上教程配置sites-available的朋友发现没效果，就是因为自己安装的是编译版，根本没有这个目录。

所以拿到一台服务器，我第一件事就是which nginx和nginx -V，搞清楚它是谁装的、装在哪。我见过最混乱的情况是：系统里同时存在 apt 版和编译版，两个 nginx 抢 80 端口，排错排到怀疑人生。避免这个问题的办法很简单：安装前确定好一种方式，不要混着来。

6.2 从默认 nginx.conf 看懂 server、location 和 include

打开/etc/nginx/nginx.conf（或者编译版的/usr/local/nginx/conf/nginx.conf），默认配置看起来挺长，但拆开看就三层结构。

第一层是全局块。比如：

worker_processes auto; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; include /etc/nginx/conf.d/*.conf; }

worker_processes auto让 nginx 根据 CPU 核数自动决定 worker 进程数量。worker_connections表示每个 worker 进程能同时处理的最大连接数。这两个参数决定了 nginx 的并发能力上限。

第二层是http块里的 server 块。每个server块代表一个虚拟主机。拿默认站点来看：

server { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html index.htm; } }

listen 80表示监听 80 端口，server_name是这个虚拟主机的域名，location /匹配所有以/开头的请求，root指定文件根目录，index指定默认首页文件名。

第三层是location块的匹配规则。location /是前缀匹配，location = /是精确匹配，location ~ \.php$是正则匹配。做反向代理、静态文件缓存、访问控制，实际上都是在写 location 规则。

重点说下include这个指令。nginx 主配置里一般都有include /etc/nginx/conf.d/*.conf;，意思是加载这个目录下所有.conf文件。所以你完全可以把每个站点的配置单独放到conf.d/下面，不用把所有内容堆到一个大文件里。改配置、查问题都方便很多。等到你配置的站点多了，你会感激这一点。

7. 高频安装报错排查手册：按错误信息对号入座

7.1 依赖缺失相关：configure 阶段最扎心

源码编译时，看到一个红色的error，很多人就慌了，其实错误信息已经把答案告诉你了。我这里列三个最高频的。

第一个是：

./configure: error: the HTTP rewrite module requires the PCRE library.

这是系统缺 PCRE 开发库。Ubuntu/Debian 装libpcre3-dev，RHEL 系装pcre-devel。装完重新 configure 即可。

第二个是：

./configure: error: the HTTP gzip module requires the zlib library.

缺 zlib。Ubuntu/Debian 装zlib1g-dev，RHEL 系装zlib-devel。

第三个是：

checking for C compiler ... not found ./configure: error: C compiler cc is not found

这会出现在全新系统上，连编译工具链都没有。装build-essential或者gcc、make，这个问题就消失了。

这些报错不是 nginx 的问题，是基础环境的问题。所以编译之前先确认基础依赖，而不是等报错了再去搜。

7.2 端口占用：bind() failed 的完整排查链路

启动 nginx 时看到这样的日志：

[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

说明 80 端口被别的进程占了。不要慌着杀进程，按这个链路来排查：

# 第一步：看谁占了 80 端口 sudo ss -lntp | grep :80 # 第二步：如果查不到，用 lsof 补一下 sudo lsof -i :80 # 第三步：确认占用进程是什么 ps -ef | grep 进程PID

常见的原因包括：系统里已经装过另一个 nginx；Apache/httpd 在跑；还有像我前面说的，apt 版和编译版 nginx 并存，两个都试图监听 80。

确认占用者之后，再根据情况处理。如果占用者是旧的 nginx，可以选择用新的替换，或者把新版的listen 80改成其他端口，两个共存。如果占用者是其他业务进程，那你要想清楚哪个服务该占 80。阻塞宁可只保留一个正确的服务，也不要强行杀掉别的进程，尤其是生产环境。

7.3 配置语法错误：unknown directive 与文件缺失

系统包管理器装完默认配置一般没问题，但你自己改过配置之后，常见的报错有三类。

第一类是：

nginx: [emerg] unknown directive "sever" in /etc/nginx/conf.d/test.conf:2

这种九成是单词拼错了。sever_name写成server_nmae、listen后面少了端口号、分号漏写，都会导致 unknown directive。排查方法很原始但很有效：一行一行看有问题的文件，检查关键字和结尾的分号。

第二类是：

nginx: [emerg] open() "/etc/nginx/sites-enabled/default" failed (2: No such file or directory)

这是符号链接指向的文件不存在，典型场景是sites-enabled里有一个指向sites-available的软链接，但sites-available里对应的文件被误删了。检查ls -l /etc/nginx/sites-enabled/，把失效的链接删掉就行。

第三类是逻辑问题，不会在nginx -t时报错，但访问时表现异常。比如 403 Forbidden。这种要分两头查：一头是文件系统权限，看 nginx 有没有权限访问配置里root指定的目录；另一头是 SELinux，用ausearch -m avc -ts recent查 denial 记录。

不管改了什么配置，遵循一个铁律：sudo nginx -t通过后再systemctl reload nginx。一次都不要跳过。reload是平滑重载，不会中断现有请求，但如果你连语法检查都没过就直接 reload，结果就是 nginx 拒绝加载新配置，服务保持旧配置运行，这种“改了等于没改”的情况特别迷惑人。

8. 装完先别急着部署：用反向代理和负载均衡实测 nginx

8.1 反向代理一次就懂

很多教程装完 nginx 就结束了，但 nginx 真正常用的场景是反向代理。安装验证完，我建议你花三分钟配一个最简单的反向代理，这一步能让后续所有配置都有底气。

现在假设你有一个后端服务跑在127.0.0.1:8080，你想让用户访问 nginx 的 80 端口，由 nginx 把请求转发给 8080 端口。先在conf.d/下新建一个配置文件，比如reverse.conf：

server { listen 80; server_name demo.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

然后验证并重载：

sudo nginx -t sudo systemctl reload nginx

为什么proxy_set_header这几行重要？因为后面那个后端服务看到的请求来源会变成 nginx 的地址，而不是用户真实 IP。X-Real-IP和X-Forwarded-For就是把真实客户端 IP 传给后端的方式。如果你后面要基于 IP 做限流或者审计日志，这一步漏掉，数据全是假的。

你可以用 Python 起一个极简后端来测试：

python3 -m http.server 8080

然后访问 nginx 的 80 端口，浏览器应该能看到这个目录列表页面。看到这个页面，就说明反向代理链路已经通了。

8.2 upstream 与负载均衡的快速验证

反向代理通了之后，负载均衡几乎不需要额外学习成本。upstream就是定义一组后端服务器，proxy_pass直接指向这组服务器的名字。

配置长这样：

upstream backend { server 127.0.0.1:8081; server 127.0.0.1:8082; } server { listen 80; server_name demo.example.com; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

默认策略是轮询，也就是每个请求依次打给 8081、8082，再回到 8081。你可以开两个终端分别跑：

python3 -m http.server 8081 python3 -m http.server 8082

然后连续刷新浏览器，会发现内容在两个端口之间来回切换。如果 8081 停掉，nginx 会自动把请求都转发给 8082，这大概就是 nginx 负载均衡最直观的体现。

upstream里还能加weight参数调整权重，加max_fails和fail_timeout来控制失败重试策略。这些在安装阶段不用研究太深，但知道有这个能力，至少能让你在部署架构时心里有数。

9. 收尾：安装自检清单与我的习惯

9.1 一张表完成安装验收

教程看到这里，你已经不只是安装 nginx，而是把安装、配置、验证、排错串成了一条链路。最后我用一张表帮你做最终验收，每条都过一遍，这个 nginx 才算真正交工。

前端时间我给朋友排查问题，他搞了一整天没搞定，我远程过去发现就是systemctl is-enabled nginx返回了 disabled。服务能手动启动，但机器一重启就消失，这种属于“装了一半”，不算装完。

9.2 我长期维护 Linux nginx 的一些习惯

最后分享几个我实际维护中的习惯，这些踩坑多了之后慢慢形成的。

第一，每次安装或者升级之后，我会把nginx -V输出的完整 configure 参数保存到一个文件里。这样做有实际好处：以后要升级到新版本，直接拿这份参数去配置新源码，不会漏启用模块。很多人在升级时重新编译，结果忘了带某个参数，上线之后才发现功能不见了，要回滚就非常被动。

第二，每次改配置前先备份，改完一定nginx -t。这个习惯看起来简单，但我真的遇到过因为多打了一个空格导致配置加载失败的生产事故。备份命令也不复杂：

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%Y%m%d%H%M%S)

第三，同一台机器上不要混用多种安装方式。这一点我在前面反复提醒过，因为这是最容易踩的隐形坑。要么全用包管理器，要么全用编译安装。容器环境就用镜像，不要在主机的/usr/local里再塞一份 nginx，否则迟早会出端口或者资源竞争问题。

到 2026 年，容器化部署已经非常普遍，很多人可能会问：还有必要掌握裸机安装 nginx 吗？我的回答是：有必要。容器里的 nginx 也是 nginx，它的配置语法、目录结构、排错思路和裸机完全一样。而且你在生产环境里总会遇到一些不能用容器的情况，比如特殊网络环境、性能压测、要直接管理主机资源的时候，懂安装、懂配置、懂排错这一整套链路，才能真正兜住底。这些东西，往往就是日常看起来最普通的“装个 nginx”里积累出来的。