企业官网建设流程全解析

装 Nginx 这件事，看起来就是一条命令的事，真到了实际环境里，选错安装方式足够让人半夜爬起来回滚。我最早一次部署时图快，用了系统自带源，跑起来才发现版本停在三年前，缺http_v2_module，HTTP/2 根本开不了；临时改成源码编译，又赶上缺 pcre 开发包，./configure阶段直接挂了。这类事踩过几回之后，我对 Nginx 三种安装方式就有了比较固定的判断标准：包管理器安装图省事，源码编译图可控，容器化图环境一致。

Nginx 三种安装方式，说到底就是三条路：走发行版软件仓库直接装、自己下源码编译、拉容器镜像跑起来。三条路都能让 80 端口吐出一个 Welcome 页面，但后续的升级路径、加模块的难易、迁移成本、排障方式完全是两套逻辑。这篇文章是写给需要真正把 Nginx 跑在服务器上的人的——刚接触运维的新手可以照着命令抄，已经用过几年的老手可以直接看编译参数拆解、容器挂载陷阱和排障清单。下面我把三种方式的目录布局、参数含义、实操步骤、验证方法和踩坑经验一次讲透，你在选型时能直接拿去对照。

1. 先想清楚：装个 Nginx 为什么要分三种方式

1.1 三条路的本质差异在哪里

很多人把安装方式理解成"命令不同"，其实差异在于谁替你做了决定。包管理器安装，是发行版维护者替你决定了版本号、编译参数、模块清单和目录布局；源码编译，所有决定权在你手上，包括用哪个版本的 OpenSSL、开哪些模块、装到哪个前缀目录；容器化则是把"运行环境"整体打包，你决定的是挂载哪些配置、暴露哪些端口，镜像里的编译参数仍然由镜像维护者决定。

这个"谁做决定"的差别，会在三个时间点暴露出来。第一个是需要某个模块的时候，比如你要用--with-http_realip_module拿真实客户端 IP，包管理器版本大多已经编译进去了，但如果你要用--with-stream做四层转发或者用第三方模块，就只有编译这一条路。第二个是需要修某个漏洞的时候，容器和包管理器都能一条命令换版本，源码编译要重新走一遍 configure、make、替换二进制、平滑重载的流程。第三个是迁移到新机器的时候，容器化的迁移成本最低，源码编译次之（要记住编译参数），包管理器最省心但也最容易被不同发行版的目录差异绊住。

我的经验是：别把安装方式当成个人偏好问题，它本质上是运维成本的分摊问题。你手上机器多、环境杂，那就往容器和包管理器靠；你只有几台机器但要极致控制模块和性能参数，那就老老实实编译。中间路线是包管理器装主版本、编译装特殊版本，这在同一台机器上并存也完全可行，后文会讲怎么让两个版本互不干扰。

1.2 选型决策：什么场景该选哪种

在动手之前，先花两分钟回答下面几个问题，答案基本就能锁定方案：

• 线上是否要求 Nginx 版本与开发环境完全一致？是，选容器化；否，包管理器就够。
• 是否需要第三方模块或默认未编译的官方模块？是，只能源码编译。
• 服务器数量是否超过十台，且需要批量部署？是，容器化或配置管理 + 包管理器。
• 是否有严格的审计要求，需要精确控制每个二进制文件的来源？是，源码编译并留存编译参数与校验值。
• 只是本地开发、临时验证、跑个静态站点？包管理器或容器，一分钟搞定，别折腾编译。

下面这张表是我自己选型时用的粗筛表，可以直接对照：

提示：不要在同一台机器上既用包管理器装又编译装到/usr/local/nginx，然后忘了两套服务单元都在跑。80 端口只有一个，谁先起谁占，排障时会非常迷惑。真要并存，务必让其中一套改监听端口。

2. 方式一：包管理器安装，最省事也最容易踩版本坑

2.1 安装前的源检查与两条命令

Debian 系和 RHEL 系的命令不同，但逻辑一致：先更新索引，再装包。Debian 系直接用官方仓库即可：

sudo apt update sudo apt install -y nginx sudo systemctl enable --now nginx nginx -v

RHEL 系要注意，很多发行版自带仓库里的 Nginx 版本非常旧，甚至默认不带。正确的做法是先加官方仓库再装：

# 写入官方仓库配置，注意把版本代号按实际发行版替换 sudo tee /etc/yum.repos.d/nginx.repo > /dev/null <<'EOF' [nginx-stable] name=nginx stable repo baseurl=http://nginx.org/packages/centos/$releasever/$basearch/ gpgcheck=1 enabled=1 gpgkey=https://nginx.org/keys/nginx_signing.key module_hotfixes=true EOF sudo yum install -y nginx sudo systemctl enable --now nginx

这里有个细节值得说：加官方仓库这一步经常被人跳过，然后抱怨"我这台机器的 Nginx 怎么这么老"。发行版仓库为了稳定性会把版本锁定在很旧的稳定分支上，安全补丁是回填的，但新特性一个都没有。如果你需要 HTTP/2、limit_req的较新行为、或者较新的 TLS 默认配置，加官方仓库是成本最低的一步。

2.2 两种发行版的目录布局差异

这是包管理器安装最容易让人迷糊的地方。同样是装完 Nginx，配置文件在哪、站点配置往哪放，两个系完全不同：

Debian 系的sites-available加软链到sites-enabled这套设计，本质上是让"写好的配置"和"生效的配置"分离，停用某个站点只要删软链，不用改文件内容，回滚很方便。RHEL 系是直接把conf.d/下所有.conf全部 include 进来，所以文件名最好带数字前缀控制加载顺序，比如10-api.conf、20-web.conf。我在两套系统之间切换时，第一件事永远是nginx -V看编译参数，第二件事就是看清楚 include 的是哪个目录。

2.3 包管理器方式的优缺点与适用边界

优点很明确：systemd 服务单元、日志切割（logrotate配置）、权限和用户（Debian 系默认 worker 用户是www-data，RHEL 系是nginx）全部帮你配好了，装完就能跑，升级一条命令。对于大多数只做反向代理和静态资源服务的场景，这就是最优解，没必要为了"可控"去折腾编译。

缺点同样明确：你无法增删模块。想加--with-stream做 MySQL 四层转发？想加第三方模块做防盗链或 WAF？只能换方案。另外不同发行版的默认配置差异很大，比如默认是否开启gzip、server_tokens是否暴露版本号、client_max_body_size默认 1M 导致上传大文件直接 413，这些都是我见过的高频问题，装完务必按第 6 节的清单过一遍。

注意：包管理器安装的 Nginx 在升级时可能覆盖你的自定义配置。Debian 系会弹出配置文件冲突提示让你选择保留哪一版，RHEL 系则是.rpmnew文件悄悄放在旁边。升级前把/etc/nginx整体打包备份，是最省事的习惯。

3. 方式二：源码编译安装，把控制权全拿回来

3.1 编译依赖清单与准备动作

源码编译失败，九成栽在依赖上。Nginx 自身的编译依赖其实很少，核心就四类：C 编译器与 make、PCRE（正则，location的~匹配、rewrite都靠它）、zlib（gzip 压缩）、OpenSSL（HTTPS 与 TLS）。

# Debian 系 sudo apt install -y build-essential libpcre2-dev zlib1g-dev libssl-dev # RHEL 系 sudo yum groupinstall -y "Development Tools" sudo yum install -y pcre2-devel zlib-devel openssl-devel

这里有个常见分叉：PCRE 还是 PCRE2。老版本 Nginx 依赖 PCRE1，新版本从 1.21.5 起对 PCRE2 支持完善，编译时可以直接--with-pcre走系统库或让 Nginx 自带源码编译。如果你在较新的发行版上编译较老的 Nginx，会遇到pcre.h找不到的问题，因为新系统只装了 PCRE2 头文件。最稳的做法是把 Nginx 版本和 PCRE 版本对齐，不确定就让 Nginx 自己带 PCRE 源码编译，configure 时用--with-pcre=../pcre2-10.42指过去。

另外一个容易被忽略的依赖是 OpenSSL 版本。如果你想用较新的 TLS 特性（比如 TLS 1.3 的早期配置、或者某些新的密码套件），而系统自带的 OpenSSL 版本偏旧，可以用--with-openssl=../openssl-3.x让 Nginx 静态链接一份自己的 OpenSSL。代价是后续 OpenSSL 出安全补丁时，你得重新编译一次 Nginx，这是个必须提前想清楚的维护负担。

3.2 configure 参数逐条拆解

这是整篇文章最值得细看的部分。网上大量教程让你直接抄一长串参数，但很少有人解释每一项为什么开。我按用途分四组讲。

第一组：路径控制。--prefix=/usr/local/nginx决定安装根目录，所有其他路径默认都相对它推导出来。如果你想让配置文件独立于程序目录（方便单独做版本管理和备份），可以额外指定：

--prefix=/usr/local/nginx \ --conf-path=/etc/nginx/nginx.conf \ --pid-path=/var/run/nginx.pid \ --error-log-path=/var/log/nginx/error.log \ --http-log-path=/var/log/nginx/access.log

注意--pid-path和日志路径如果指向系统目录，要提前建好目录并赋予正确属主，否则 reload 时会因为找不到 pid 文件而失败，这个报错信息是invalid PID number或者open() "/var/run/nginx.pid" failed，很容易被误判成配置错误。

第二组：HTTP 核心模块。这些是绝大多数生产环境都该开的：

第三组：四层与系统能力。--with-stream用于 TCP/UDP 转发，做数据库代理、邮件代理时必须有；--with-threads开启线程池，在大量小文件静态资源场景下能明显降低阻塞，配合aio threads使用效果最好；--with-file-aio开启异步文件 IO，对大文件传输有帮助。

第四组：编译优化。--with-cc-opt传递编译器参数，常用的是-O2和-fstack-protector-strong；--with-ld-opt传递链接参数，如果 OpenSSL 装在非标准路径，需要在这里加-Wl,-rpath。另外可以加--with-cpu-opt=native做针对当前 CPU 的优化，但我不建议在生产环境用，因为一旦迁移到指令集不同的机器上就会直接崩溃，省下的那点性能不值得。

一条我实际在用的、相对保守但覆盖全面的 configure 命令：

./configure \ --prefix=/usr/local/nginx \ --user=www-data --group=www-data \ --with-http_ssl_module \ --with-http_v2_module \ --with-http_realip_module \ --with-http_gzip_static_module \ --with-http_stub_status_module \ --with-http_sub_module \ --with-threads \ --with-file-aio \ --with-stream \ --with-stream_ssl_module \ --with-cc-opt='-O2 -fstack-protector-strong -Wformat -Werror=format-security'

configure 结束后一定要看输出的 Summary，最后几行会列出PCRE version、OpenSSL version、nginx version和启用的模块列表。如果 OpenSSL 显示not found而你明明要开 HTTPS，那这次的产物是废的，别急着 make。

3.3 编译、安装与版本并存

configure 通过后就是常规动作：

make -j$(nproc) sudo make install sudo /usr/local/nginx/sbin/nginx -V # 能看到完整编译参数，妥善保存

make -j$(nproc)用满 CPU 核数，编译时间通常从一两分钟缩短到几十秒。安装完成后，/usr/local/nginx下会有conf/、html/、logs/、sbin/四个目录，这是个非常干净的布局——所有东西都在一起，备份时打个包就完事，迁移时复制过去就能跑。

版本并存的小技巧：如果你需要让新编译的 Nginx 和系统自带的并存，最好的方式是装到带版本号的前缀下，比如/usr/local/nginx-1.26.2，然后建一个软链/usr/local/nginx -> /usr/local/nginx-1.26.2。升级时新版本装到新目录，改软链指向，出问题改回来即可，这是一秒钟回滚的方案。

源码编译还有一个杀手级特性：平滑升级。不需要停服务就能换二进制：

# 假设新版本二进制放在 /usr/local/nginx/sbin/nginx.new kill -USR2 $(cat /var/run/nginx.pid) # 启动新主进程，旧进程转存 heredoc sleep 2 kill -WINCH $(cat /var/run/nginx.pid.oldbin) # 优雅关闭旧 worker # 确认无误后 kill -QUIT $(cat /var/run/nginx.pid.oldbin)

这套信号的语义是：USR2拉起新版本主进程，WINCH让旧 worker 停止接收新连接并把连接处理完，QUIT彻底结束旧主进程。如果新版本跑起来有问题，在QUIT之前发HUP给旧主进程就能立刻回退，这是我为什么敢在生产环境直接换二进制的原因。

3.4 编译环节的高频坑点

第一坑是重编译时忘了带旧参数。你自己编译时加了一堆--with-*，半年后要升级版本，重新 configure 时凭记忆写了一遍，漏了--with-stream，结果依赖四层转发的业务直接挂掉。所以每次make install之后，把nginx -V的完整输出存进版本库，下次照抄。

第二坑是权限与 worker 用户。--user=指定的用户必须真实存在，否则启动时报getpwnam("www-data") failed。此外日志目录的属主要与 worker 用户匹配，否则会看到open() "/var/log/nginx/access.log" failed (13: Permission denied)。

第三坑是升级后配置不兼容。新版本可能移除了某些老指令（比如早期版本废弃的ssl指令），换二进制后 reload 直接失败并保持旧配置运行——好消息是不影响服务，坏消息是你会以为升级成功了。所以换完二进制必须nginx -t加curl -I双重验证。

4. 方式三：容器化运行，一次配置到处跑

4.1 镜像标签怎么选

容器化装 Nginx 的核心问题是选标签。官方镜像的标签体系大致有三类：nginx:latest（跟随最新稳定版，不要在生产用）、nginx:1.26.2（精确版本，推荐）、nginx:1.26.2-alpine（基于 Alpine，体积小但用 musl libc）。

我的选择是精确版本 + 非 Alpine，理由有两个：一是精确版本让"开发环境和线上环境一致"这件事真正成立，二是 Alpine 的 musl libc 在 DNS 解析、nsswitch、某些第三方模块上行为和 glibc 有差异，遇到问题时排查成本高。体积从 180MB 降到 50MB 的收益，在现在这个存储成本下基本可以忽略。如果你的场景对镜像体积非常敏感，或者运行在资源受限的边缘设备上，再考虑 Alpine。

选镜像时还要确认一件事：镜像里编译了哪些模块。可以进容器执行nginx -V查看，官方镜像默认带了http_ssl、http_v2、http_realip、http_stub_status、http_gzip_static等常见模块，但--with-stream是不带的。需要四层转发就得自己写 Dockerfile 基于源码编译，那时候就等于把第 3 节的流程搬进镜像构建里，只是构建结果可复现。

4.2 两种启动方式：run 与 compose

临时验证用docker run最快：

docker run -d --name nginx-demo \ -p 80:80 -p 443:443 \ -v /opt/nginx/conf/nginx.conf:/etc/nginx/nginx.conf:ro \ -v /opt/nginx/conf.d:/etc/nginx/conf.d:ro \ -v /opt/nginx/html:/usr/share/nginx/html:ro \ -v /opt/nginx/logs:/var/log/nginx \ --restart unless-stopped \ nginx:1.26.2

--restart unless-stopped一定要加，否则宿主机重启后容器不会自己起来，这个坑我见过不止一次。挂载配置时用:ro只读，避免容器内进程误改宿主机文件。

正式一点的项目用 compose 更清晰，也便于纳入版本管理：

services: nginx: image: nginx:1.26.2 container_name: nginx ports: - "80:80" - "443:443" volumes: - ./conf/nginx.conf:/etc/nginx/nginx.conf:ro - ./conf.d:/etc/nginx/conf.d:ro - ./certs:/etc/nginx/certs:ro - ./html:/usr/share/nginx/html:ro - ./logs:/var/log/nginx restart: unless-stopped healthcheck: test: ["CMD", "curl", "-f", "http://localhost/"] interval: 30s timeout: 3s retries: 3

healthcheck 那段是为了让编排层能感知"进程在但服务不可用"的情况。注意有些精简镜像里没有curl，得换成wget --spider或者用小工具替代，写之前先确认。

4.3 容器内配置、日志与重载的三个陷阱

陷阱一：反向代理指向127.0.0.1。容器里的127.0.0.1是容器自己，不是你宿主机。如果后端服务跑在宿主机上，proxy_pass http://127.0.0.1:8080一定 502。解法有三种：把后端也放进同一 compose 网络用服务名互访（推荐）、用--network host让容器共享宿主网络（简单但失去端口隔离）、或者显式写宿主机在 docker 网桥上的地址（不推荐，地址会变）。

陷阱二：日志拿不出来。官方镜像把access.log软链到了/dev/stdout，所以docker logs能看到。但你一旦挂载了./logs:/var/log/nginx，软链会被覆盖成真实文件，docker logs就空了。这是个静默变化，配置没报错，日志就是不见了。要么不挂载日志目录、靠docker logs加日志驱动收集，要么挂载后明确接受文件日志并用采集工具读取，二选一，别混着猜。

陷阱三：改完配置怎么生效。容器里的主进程是nginx -g "daemon off;"前台运行的，所以要重载用：

docker exec nginx nginx -t # 先校验，别直接 reload docker exec nginx nginx -s reload

先-t再 reload 是个必须养成的动作，配置语法错的时候-t会直接指出行号，reload 则可能只给你一个含糊的失败。另外注意nginx -s reload依赖 pid 文件路径，容器里的路径是镜像里编译死的，所以容器内不要随意改pid指令，否则 reload 会找不到进程。

4.4 容器化的边界在哪里

容器化不是万能的。它最大的价值是环境一致性——开发、测试、生产用同一个镜像摘要（digest，不是 tag），配置挂载不同，行为就一致。它最大的成本是多一层网络和文件系统的抽象，任何"为什么访问不通"的问题，都要多问一句"是宿主机的问题还是容器的问题"。

我的判断标准是：机器数量超过五台、或者团队里有多人需要复现同一个环境，容器化的收益立刻超过成本。单机单实例、只跑一个静态站点，用包管理器一条命令更省心，别为了技术栈统一而统一。

5. 三种方式的横向对比与关键参数选型

5.1 对比表：从安装到日常维护

前面几节是分头讲的，这里把它们拉到一张表里正面对比，方便选型时直接对照：

补充一个很多人关心但常被夸大的点：三种方式的运行性能差异其实很小。差异来源主要是编译优化参数和模块数量，而不是安装方式本身。同一份配置跑同样的压测，包管理器版和源码版的 QPS 差距通常在个位数百分比以内。真正影响性能的是worker_processes、worker_connections、keepalive_timeout、sendfile、gzip这些运行时参数，以及日志写入方式（同步写 vs 缓冲写）。所以不要为了"性能"去选编译安装，为了模块和版本可控才是正经理由。

5.2 两个必须算清楚的参数

装完之后第一件事是核对两个参数，它们直接决定并发能力上限。

worker_processes：通常设auto，等于 CPU 核心数。设多了会有进程切换开销，设少了压不满多核。如果你的场景是大量静态文件传输、IO 密集，可以考虑设为核数的 1.5 到 2 倍，但对绝大多数反向代理场景，auto就是最优。

worker_connections与系统文件句柄上限：每个 worker 能同时处理的连接数由worker_connections决定，而整机上限受ulimit -n约束。理论最大并发连接数约等于：

最大并发 ≈ worker_processes × worker_connections ÷ 2

除以 2 是因为反向代理场景下，每个客户端请求会占用两个连接（客户端到 Nginx、Nginx 到后端）。举例：4 核机器，worker_processes 4，worker_connections 10240，则理论上限约 20480 个并发连接。但此时需要ulimit -n至少为 20480 × 2 再加余量，通常设 65535。如果worker_connections设得很大而ulimit没调，日志里会出现worker_connections are not enough或者Too many open files，这是典型的配置不一致问题，改一边不改另一边就会踩。

同时别忘了worker_rlimit_nofile这个指令，它可以让 Nginx 自己去设句柄上限，避免每次改系统配置：

worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 10240; use epoll; multi_accept on; }

6. 装完之后的验证清单与最小可用配置

6.1 五步验证，一步都不能省

不管用哪种方式装的，验证流程是同一套，我通常按这五步走：

1. 看版本和编译参数：nginx -V，确认版本号正确，并把输出存档。这一步能立刻暴露"装完发现版本不对"和"模块缺失"两类问题。
2. 校验配置语法：nginx -t，输出里要同时看到syntax is ok和test is successful，只有前者代表语法对但实际加载可能仍有问题。
3. 确认监听端口：ss -lntp | grep nginx，正常应该看到0.0.0.0:80和[::]:80。只有 IPv6 没有 IPv4，通常是listen指令写成listen [::]:80而漏了 IPv4 那条。
4. 本地发请求：curl -I http://127.0.0.1/，期望 200 并带Server头。如果返回 403，多半是根目录权限或index文件缺失；返回 404 则是root路径配错。
5. 外部发请求：从另一台机器curl -I，这一步专门用来暴露防火墙、安全组、SELinux 这类"本机通外网不通"的问题。

6.2 一份可以直接抄的最小配置

下面这份配置我几乎在每个新环境都用，静态站点加反向代理两段，覆盖 90% 的起步需求：

user www-data; worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 10240; use epoll; multi_accept on; } http { include mime.types; default_type application/octet-stream; server_tokens off; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" rt=$request_time'; access_log /var/log/nginx/access.log main buffer=32k flush=5s; error_log /var/log/nginx/error.log warn; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; client_max_body_size 20m; gzip on; gzip_min_length 1k; gzip_comp_level 5; gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml; server { listen 80; server_name _; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ =404; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 5s; proxy_read_timeout 60s; } location = /status { stub_status; allow 127.0.0.1; deny all; } } }

几个值得解释的选择。server_tokens off是为了不在错误页里暴露版本号。access_log加了buffer=32k flush=5s，把日志写从每请求一次改成攒批，高并发下能显著减少磁盘 IO，代价是最多延迟 5 秒才落盘，排查实时问题时可以临时去掉。proxy_pass末尾那个斜杠有讲究：http://127.0.0.1:8080/带斜杠会把/api/xxx重写成/xxx转发，不带斜杠则原样转发/api/xxx，这是反向代理最常见的配置错误之一，写之前先确认后端路由的期望路径。client_max_body_size 20m是因为默认 1M，上传稍大的文件就 413，这个报错在浏览器里看不出来，只有抓包或看日志才能发现。

7. 常见问题与排查实录

7.1 端口、权限与安全策略

80 端口起不来，报bind() to 0.0.0.0:80 failed (98: Address already in use)。先ss -lntp | grep :80看是谁占的，常见是系统自带的 httpd/apache 或者上次没关掉的 Nginx。另一种情况是报Permission denied，那说明你用非 root 用户启动且端口小于 1024，编译安装时特别容易遇到，用setcap 'cap_net_bind_service=+ep' /usr/local/nginx/sbin/nginx授权即可，比直接用 root 跑更安全。

403 Forbidden，三种可能按概率排：目录没有index文件且autoindex关闭、目录缺少其他人的执行权限（x位，注意是执行位不是读位）、以及 SELinux 上下文不对。第三种最隐蔽，ls -Z看到user_home_t而不是httpd_sys_content_t，用restorecon -Rv /path修复。

502 Bad Gateway，后端没起或者连不上。除了检查后端进程，还要注意 SELinux 默认禁止 Nginx 主动发起网络连接，需要setsebool -P httpd_can_network_connect 1。这个开关不开，你会看到 502 而错误日志里写Permission denied while connecting to upstream，非常容易误判成后端挂了。

7.2 编译与容器相关的问题

编译阶段最常见的三个报错和处理方式：

容器侧最常见的问题是"改了配置没生效"。九成原因是挂载路径写错——比如把自定义配置挂到/etc/nginx/conf.d/default.conf，但镜像里主配置 include 的是/etc/nginx/conf.d/*.conf，两者其实等价，可如果你挂到了/etc/nginx/nginx.conf.d/，那就完全不生效。验证方法是docker exec nginx cat /etc/nginx/nginx.conf直接看容器里的实际内容，比猜快得多。

还有一个容易被忽略的点：容器内 Nginx 的 worker 用户和宿主机挂载目录的属主必须匹配。官方镜像里 worker 默认以nginx用户运行（UID 101），如果宿主机上挂载目录属主是 root 且权限 700，容器内就会 403。要么调宿主机目录权限，要么在运行参数里指定--user。

7.3 问题速查表

把上面这些整理成一张随手可查的表，排障时按顺序过一遍，能省掉大量试错：

注意：每次改完配置，先nginx -t，再 reload，再curl -I。这三步养成肌肉记忆之后，能挡掉八成的线上事故。跳过-t直接 reload 的做法，我在早期干过，代价是一次配置语法错误让整个站点 502 了将近两分钟。

8. 我这些年在这个环节踩过的坑

有些经验写在文档里显得琐碎，但实际遇到时非常省时间。第一条是把nginx -V的输出当成配置资产管理。源码编译的机器尤其重要，我做过的每个编译安装都会把完整参数写进一个BUILD_INFO文件放在安装目录旁，,内容包括版本号、configure 参数、依赖版本、编译时间。半年后升级时照着这份文件重跑一遍，比凭记忆靠谱得多。

第二条是升级路径要提前演练。容器化看起来很安全，但"换镜像重启"意味着有一次短暂的服务中断窗口（除非你做多实例滚动）；源码编译可以平滑升级但要记住信号顺序；包管理器升级会覆盖配置。三条路的升级动作都不难，难的是在压力下想起来该做哪个。我现在的做法是每种方式的升级步骤写成脚本，脚本里带nginx -t和健康检查，失败自动回退，不依赖临场判断。

第三条关于目录规划：配置目录和数据目录一定要分离。我见过把静态站点放在 Nginx 安装目录下面的做法，编译升级时make install一跑，站点文件被新装的html/目录盖住，只能从备份恢复。源码编译时习惯性加--conf-path=/etc/nginx/nginx.conf，把配置挪出安装目录，站点根目录也单独放到/data/www，从物理上隔开程序和数据，升级就再也不用担心误伤。

第四条是给团队协作的：不管选哪种安装方式，把"怎么装的、装在哪、配置从哪来、日志在哪、怎么重载"这五个问题的答案写在同一个 README 里，放在代码库里。这不是形式主义，我自己就曾经因为换了台机器而花二十分钟找一份编译了三年前版本的 Nginx 的配置文件在哪，最后发现它在一个早已忘记的自定义前缀目录里。安装方式的选择其实没有绝对的对错，真正拉开差距的，是有没有把这些细节记录清楚、把升级和回滚动作标准化。