企业官网建设流程全解析

简介：这份 Linux 环境下的 Nginx 1.25.2 预编译包，面向需要快速搭建 Web 服务、反向代理或进行本地联调测试的运维与开发人员，可省去从源码编译、依赖排查到环境适配的繁琐过程，解压后即可启动使用。压缩包共 569 个文件、约 4.26MB，内容以 262 个 C 源文件和 137 个头文件为主体，保留 Nginx 核心模块、HTTP 处理与事件驱动等实现；同时包含 14 个 conf 配置、若干 makefile/make 构建文件、patch 补丁及 readme 说明，便于核对编译产物、迁移配置或后续扩展。通过 ./nginx -V 可查看版本与完整编译参数，其中已集成 pcre-8.45、openssl-1.1.1l、zlib-1.2.11 等常用依赖，能够满足基础 Web 服务与反向代理场景。目录结构保留源码与构建痕迹，对想理解 Nginx 模块组成、验证配置加载或做轻量部署的读者较友好。目前已有 239 人学习下载，适合希望跳过编译流程、直接投入测试和使用的技术人员参考。

1. 解压就能跑的 nginx-1.25.2：预编译包省掉的编译环节

内网一台老服务器，没有 gcc，连不上外部软件源，运维把一个压缩包放到你面前，说这是 nginx-1.25.2 的 Linux 已编译版本，解压就能直接用。这个场景我碰到过不止一次，第一次也吃过亏：解压完执行/sbin/nginx直接报GLIBC_2.28 not found，运行时才发现编译机和目标机不是一路人。所谓“已编译、解压、可直接使用”，本质上是一次./configure && make的决策被提前做完并固化了：模块清单、安装前缀、链接方式全都固定下来。它省掉的是装 pcre、zlib、openssl 开发包和等编译的半小时，代价是你必须自己确认二进制和目标机器的兼容性。这篇写给要在离线或半离线环境快速启动一个稳定 nginx 的人，也写给想弄清楚预编译包边界、避免上线后出现问题的人。

2. 拆开这个已编译包：目录结构、编译参数与依赖边界

拿到包的第一件事不是解压运行，而是检查。预编译包最适合直接使用的场景，是三件事同时成立：目录结构完整、编译参数覆盖你的功能需求、动态库和 glibc 版本在目标机上能兑现。这三件事任何一件不成立，包再好也只是一个看起来能用的二进制文件。

2.1 解压后先看四个目录：conf、sbin、logs、html 各管什么

标准布局的预编译包，顶层通常只有四到五个条目，逐一看过去能读出不少信息。先把包解到统一目录，再做一次目录清单：

# 解压到 /opt 下，路径里不要带空格、中文和括号，nginx 的 include 对路径很敏感 mkdir -p /opt tar -zxvf nginx-1.25.2-linux-x86_64.tar.gz -C /opt # 看顶层结构，以及 sbin/nginx 是否带执行位 ls -la /opt/nginx-1.25.2-linux-x86_64/ ls -l /opt/nginx-1.25.2-linux-x86_64/sbin/nginx

sbin/nginx权限应该是-rwxr-xr-x，如果是-rw-r--r--，说明打包时丢了执行位，chmod +x补上即可，这不是坏事，说明包是普通打包工具压的，没做过额外处理。conf/里至少要有nginx.conf、mime.types、fastcgi_params、koi-utf这几个，mime.types缺失会导致所有静态资源返回application/octet-stream，浏览器直接下载而不是渲染，这个坑很隐蔽。

最后一行要特别留意。nginx 启动时会在 prefix 下创建client_body_temp、proxy_temp、fastcgi_temp、uwsgi_temp、scgi_temp五个临时目录，如果 prefix 所在分区只读，或者运行用户没有写权限，日志里会出现mkdir() "/xxx/client_body_temp" failed (13: Permission denied)，然后 worker 起不来。常见做法是启动前手动建好这五个目录并把属主改成运行用户，比启动失败后再回头找原因省事。

2.2 用 nginx -V 反查编译参数，判断能不能直接上生产

nginx -V是这类包的核心信息来源，大写 V 输出版本加configure arguments，小写 v 只出版本号。注意它把内容打到标准错误，必须重定向才能接管道：

cd /opt/nginx-1.25.2-linux-x86_64 # 大写 V：版本 + 编译机 + 编译器 + configure 参数，内容走 stderr ./sbin/nginx -V 2>&1 # 只把 -- 开头的参数拆出来，方便逐条核对 ./sbin/nginx -V 2>&1 | tr ' ' '\n' | grep '^--'

输出里第一行是nginx version: nginx/1.25.2，接着是built by gcc x.y.z和built with OpenSSL ...，最后一行是完整参数。逐项看什么：--prefix=决定默认配置和日志的相对基准目录，后面所有相对路径都从这里算起，如果它是/usr/local/nginx而你把包放在/opt下，直接用./sbin/nginx启动会去/usr/local/nginx/conf/nginx.conf找配置，报open() "/usr/local/nginx/conf/nginx.conf" failed。这是预编译包最常见的问题，解决办法见第 3 章的-p。

模块清单决定功能边界。--with-http_ssl_module没有，配置里写ssl_certificate会直接报unknown directive "ssl_certificate"；--with-http_realip_module没有，反向代理后面拿不到客户端真实 IP，set_real_ip_from同样报未知指令；--with-http_stub_status_module没有，做不了/status监控页；--with-stream没有，四层转发这条路直接堵死。这些不是配置写错，是二进制里根本没有这段代码，改配置永远改不出来。

还要看--with-pcre、--with-zlib、--with-openssl后面跟的是路径还是=dynamic。跟路径说明这几个库被静态编进去了，二进制会大一些（几 MB），但换机器不用另装库；带=dynamic或者干脆没写，说明是动态链接，目标机上必须有对应.so。预编译包为了减小体积，多数走动态链接，所以下一节的检查不能省。

顺便一个 1.25.x 的版本细节：从 1.25.1 起listen 443 ssl http2;这种写法被标记为废弃，改成listen 443 ssl;加一行http2 on;，老写法虽然还能跑但日志里会持续输出告警。拿到 1.25.2 的包，配置里如果还留着listen ... http2，nginx -t就会提示，别当成错误忽略过去。

2.3 glibc 与动态库依赖：ldd 一把梭确认真能跑

判断“能不能在这台机器上跑”只需要两行命令，但要看懂结果。

# 1. 列出所有动态依赖，重点看有没有 "not found" ldd ./sbin/nginx # 2. 看二进制引用的最高 GLIBC 符号版本 objdump -T ./sbin/nginx | grep -o 'GLIBC_[0-9.]*' | sort -V | uniq | tail -3 # 3. 看目标机自己的 glibc 版本 getconf GNU_LIBC_VERSION

第一行输出里，每一行形如libpcre.so.1 => /lib64/libpcre.so.1，如果出现=> not found，说明这个库目标机上没有，最典型的是libpcre.so.1和libssl.so.1.1，补装对应运行库即可，注意只需要运行时库，不需要-devel。

第二行和第三行是一组对比。objdump那条会打印出二进制引用到的所有GLIBC_x.y符号版本，取最大的那个；如果它大于getconf输出的目标机版本，那这个包在这台机器上永远起不来，报错形式是./sbin/nginx: /lib64/libc.so.6: version 'GLIBC_2.28' not found (required by ./sbin/nginx)。这种不一致没法靠装库绕过，只能换一个在更老系统上编译的包，或者在目标机同版本环境里自己编一个。

把两条结论合起来就是判定表：ldd无not found，且最高GLIBC符号版本不高于目标机版本，这个 nginx-1.25.2 的 Linux 已编译包就可以直接投入使用了。两个条件缺一，先解决依赖问题，不要急着改配置，配置改得再对，加载器那一步就过不去。

3. 把 nginx-1.25.2 在 Linux 上跑起来的最小命令序列

依赖确认通过之后，启动本身只有几步，但顺序很重要：先前台看到错误，再改成后台，最后交给服务管理器。反过来的顺序会让你在日志里翻半天。

3.1 前台启动与 -p 指定 prefix：第一次启动别急着 daemon

预编译包的 prefix 是编译时固定的，而你的解压目录几乎不可能刚好是那个路径。-p参数就是用来在运行时覆盖 prefix 的，它改变的是一批相对路径的解析基准：配置文件名、日志、pid 文件、临时目录都跟着走。

cd /opt/nginx-1.25.2-linux-x86_64 # -p 指定运行时 prefix，-c 用相对路径（相对 -p），-g 追加全局指令 # daemon off 让 master 留在前台，错误直接打在终端上，第一次启动必用 ./sbin/nginx -p /opt/nginx-1.25.2-linux-x86_64 -c conf/nginx.conf -g "daemon off;"

三个参数各管一件事。-p把 prefix 改成当前目录，接下来conf/nginx.conf就解析成/opt/nginx-1.25.2-linux-x86_64/conf/nginx.conf，logs/error.log同理。-c如果写成绝对路径，-p对它就不起作用了，所以要么全相对，要么全绝对，别混着来。-g是往配置最外层注入指令，daemon off;让进程不脱离终端，Ctrl+C 就能停，这比启动后台再ps找进程、kill收尸快得多。

前台跑起来之后，终端会持续输出访问日志和错误日志，任何一个配置问题都会当场报出来，不用去logs/里翻。确认没问题后 Ctrl+C，再去掉-g用后台方式启动。

3.2 配置文件里必须改的三处：user、pid、日志路径

默认的nginx.conf是给编译时 prefix 写的，搬到新目录后有几处必须对齐。一份可直接用的最小配置骨架：

# 运行用户。只有 master 以 root 启动时这一行才生效，非 root 启动会告警并忽略 user nobody; # auto 按 CPU 核数起 worker，容器里 CPU 受限时建议改成固定数字 worker_processes auto; # pid 用绝对路径，避免 -p 不一致导致后续 reload 找不到进程 pid /opt/nginx-1.25.2-linux-x86_64/logs/nginx.pid; # error_log 级别 warn 足够，排查阶段可临时降到 info；debug 需要编译时带 --with-debug error_log /opt/nginx-1.25.2-linux-x86_64/logs/error.log warn; events { # 单 worker 最大连接数，与 worker_processes 相乘是理论上限 worker_connections 10240; } http { include mime.types; default_type application/octet-stream; # 日志格式里加 $request_time 和 $upstream_response_time，后面排查慢请求全靠它 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" rt=$request_time urt=$upstream_response_time'; access_log /opt/nginx-1.25.2-linux-x86_64/logs/access.log main; sendfile on; keepalive_timeout 65; server { # 第一次启动用 8080，避开 80 端口的权限问题 listen 8080; server_name _; location / { # root 用绝对路径，不要依赖 prefix root /opt/nginx-1.25.2-linux-x86_64/html; index index.html index.htm; } } }

三处改动的作用各不相同。user只在 master 是 root 时有效，非 root 启动日志会打一条the "user" directive makes sense only if the master process runs with super-user privileges, ignored，这条是告警不是错误，可以忽略，但要知道它意味着静态文件权限按当前用户算。pid写成绝对路径是为了让nginx -s reload无论从哪个目录执行都能找到 master，这是预编译包最常遇到的问题之一，后面第 5 章细说。error_log和access_log同理，相对路径会跟-p绑定，一旦启动和重载用的-p不一致，日志就会写到两个不同的地方，排查时看错文件。server_name _是通配，内网单机场景够用。

3.3 三件套验证：nginx -t、ss、curl

配置写完不要直接重启，按顺序验三遍。

# 1. 语法检查，-t 只解析配置不启动进程；-T 会顺带把最终配置打印出来 ./sbin/nginx -p /opt/nginx-1.25.2-linux-x86_64 -c conf/nginx.conf -t # 2. 看端口是否真的监听了，-l 只列 LISTEN，-n 不做域名解析，-p 显示进程 ss -lntp | grep 8080 # 3. 发一个 HEAD 请求，只关心状态码和响应头 curl -I http://127.0.0.1:8080/

第一条要注意-t的局限：它只做配置语法和文件可达性检查，不检查端口是否被占用，也不检查 upstream 后端是否活着。所以nginx -t通过不代表能起来，端口冲突是启动时才报的bind() to 0.0.0.0:8080 failed (98: Address already in use)。第二条补的就是这个。第三条返回200 OK且Content-Type: text/html说明 mime.types 加载正常，如果返回application/octet-stream，回去查include mime.types的相对路径。三件套里任意一条不过，先修再往下走。

3.4 注册成 systemd 服务：daemon off 与 LimitNOFILE

手工-p启动适合验证，长期跑还是交给 systemd，机器重启能自动起来，日志也能进 journal。写一个 unit 文件：

[Unit] Description=nginx 1.25.2 standalone After=network.target [Service] Type=simple # -p 和 -g 必须和手工启动时一致，否则 reload 找不到 pid ExecStart=/opt/nginx-1.25.2-linux-x86_64/sbin/nginx -p /opt/nginx-1.25.2-linux-x86_64 -c conf/nginx.conf -g "daemon off;" ExecReload=/opt/nginx-1.25.2-linux-x86_64/sbin/nginx -p /opt/nginx-1.25.2-linux-x86_64 -c conf/nginx.conf -s reload ExecStop=/opt/nginx-1.25.2-linux-x86_64/sbin/nginx -p /opt/nginx-1.25.2-linux-x86_64 -s quit Restart=on-failure RestartSec=3 # 突破默认文件句柄数，否则高并发下会出现 too many open files LimitNOFILE=65535 [Install] WantedBy=multi-user.target

Type=simple配daemon off;是这套组合的关键，systemd 直接托管 master 进程，不再需要Type=forking加PIDFile的老写法，进程死了也能立刻感知并Restart。ExecReload里的-p和-c一定要和ExecStart对齐，systemd 的reload是拿这条命令去执行的，少一个参数就会报 pid 文件读不到。LimitNOFILE容易被忽略，nginx 默认继承 systemd 的 1024，worker_connections 10240配得再大也受这个上限约束。

如果确实要用 80 端口又不想让 master 以 root 跑，给二进制加 capability 比改配置有效：

# 允许非 root 进程绑定 1024 以下端口 setcap 'cap_net_bind_service=+ep' /opt/nginx-1.25.2-linux-x86_64/sbin/nginx getcap /opt/nginx-1.25.2-linux-x86_64/sbin/nginx

这条对预编译包同样适用，因为 capability 是打在文件属性上的，和编译参数无关。注意重装或覆盖二进制后 capability 会丢，需要重新执行一次。

4. 拿它做静态站与反向代理：可直接抄的配置

跑通之后，绝大多数人拿这个包做两件事：一是当静态资源服务器，二是给后面的应用做反向代理。这两块配置的默认值都有明显的实用倾向，需要理解每个参数在解决什么问题，否则调优就是瞎猜。

4.1 静态资源站点：root 与 alias 的斜杠差异

静态站的核心是路径拼接规则。root是把 location 的匹配部分拼到后面，alias是直接替换掉匹配部分，差一个斜杠结果就完全不同：

server { listen 8080; server_name _; # root：请求 /static/a.png 实际读 /data/www/static/a.png location /static/ { root /data/www; expires 7d; add_header Cache-Control "public"; } # alias：请求 /files/a.png 实际读 /data/files/a.png # location 和 alias 末尾都要带斜杠，否则路径会拼错 location /files/ { alias /data/files/; autoindex off; } }

location /files/配alias /data/files/，请求/files/a.png读的是/data/files/a.png；如果 alias 少写末尾斜杠变成/data/files，读的就是/data/filesa.png，直接 404，而且这个 404 很难从日志看出来，因为路径看着“差不多”。root那段的expires 7d和add_header是给静态资源加缓存头，配合文件名哈希做长期缓存才安全，如果文件名不带哈希，缓存时间别设太长，改动后用户拿不到新文件。

性能相关的几个开关放在http块：

gzip_types里只放text/*、application/json、application/javascript这类，不要用*，对已经压缩过的 jpg、mp4、zip 再压一遍纯属浪费 CPU，还可能出现压缩后比原文件大的情况。如果预编译包带了--with-http_gzip_static_module，再加gzip_static on;，让 nginx 优先返回预先压好的.gz文件，省掉运行时压缩。

4.2 反向代理：proxy_pass 尾部斜杠与四个必调参数

反向代理的配置量不大，但每一行都有明确的失败模式：

upstream app_pool { # 后端地址，max_fails/fail_timeout 控制被动健康检查 server 127.0.0.1:9000 max_fails=3 fail_timeout=10s; # 与后端保持长连接，必须配合下面的 proxy_http_version 和 Connection "" keepalive 32; } server { listen 8080; server_name _; location /api/ { # 尾部带斜杠：/api/user 转发成 /user；不带则转发成 /api/user proxy_pass http://app_pool/; proxy_http_version 1.1; # 清空 Connection 头，否则 upstream keepalive 不生效 proxy_set_header Connection ""; 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; proxy_send_timeout 60s; # 请求体上限，按最大上传文件调整 client_max_body_size 50m; # 上传大文件时关掉缓冲，避免先落盘再转发占磁盘 proxy_request_buffering off; } }

proxy_pass尾部那个斜杠是经典问题：带斜杠是“替换 location 匹配的前缀”，不带是“把完整 URI 原样转过去”。后端路由按根路径写就必须带，按带前缀写就不带，配置完一定用curl -v看实际请求行，别靠猜。

proxy_set_header Connection ""和 upstream 里的keepalive是一组，只写 keepalive 不清空 Connection，nginx 仍然会给每个请求新建连接，长连接池形同虚设，表现是后端time_wait数量下不去。X-Forwarded-For用$proxy_add_x_forwarded_for而不是$remote_addr，前者是追加，能保留代理链；如果前面还有一层负载均衡，要配合--with-http_realip_module和set_real_ip_from才能取到真实客户端 IP，模块没编进去的话这一步做不了，只能看X-Forwarded-For的第一个值。

超时三个参数对应三个失败场景：proxy_connect_timeout管连不上后端（后端挂了、端口不通），proxy_read_timeout管连上了但后端迟迟不返回（接口慢查询），proxy_send_timeout管请求体发给后端的过程。默认的 60s 对普通接口够用，对接导出、报表这类长任务要单独放大，但别直接在http块全局放大，按 location 加。

4.3 平滑重载与日志切割：-s reload 和 USR1 到底做了什么

改完配置不重启进程，用信号重载：

# 重载配置：master 收到 HUP，校验新配置，通过则起新 worker，老 worker 处理完存量请求后退出 ./sbin/nginx -p /opt/nginx-1.25.2-linux-x86_64 -c conf/nginx.conf -s reload # 切割日志：先把旧文件改名，再给 master 发 USR1，它会重新打开日志文件 cd /opt/nginx-1.25.2-linux-x86_64/logs mv access.log access.log.$(date +%F) kill -USR1 $(cat nginx.pid)

-s reload的本质是给 master 发HUP信号，master 先做一次配置校验，不通过就保留老配置继续跑，这是它比重启安全的地方。但有个前提：这条命令必须能找到 pid 文件，而 pid 文件的路径由配置里的pid指令决定，所以前面强调写绝对路径。启动时用了一个-p，重载时用了另一个，就会报invalid PID number "" in ".../nginx.pid"。

日志切割为什么不能直接rm：Linux 下文件被删但句柄还开着，磁盘空间不释放，df看着满、du找不到，这就是典型的“黑匣子”现象。正确做法是mv改名后发USR1，master 重新open()一个新文件，老文件在最后一个持有句柄的进程关闭后自然释放，这时再删才干净。这套逻辑值得记牢，出问题时能省下不少找文件的时间。

5. 预编译包最常出问题的五个地方：排查清单

这一章按“现象 → 原因 → 解决”写，都是我在实际环境里反复遇到的。预编译包的麻烦集中在一处：它的所有路径和行为都是编译时定好的，你看到的配置和它实际读的配置可能不是同一个文件。

5.1 启动就报 Permission denied：非 root 绑定 80 端口

现象：nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)，配置语法检查-t是通过的。

原因：Linux 规定 1024 以下端口只有 root 或带CAP_NET_BIND_SERVICE的进程能绑。预编译包本身没有特权，换个包也一样。

解决：三条路选一条。改监听端口到 8080 以上最省事；必须用 80 就在前面挂一层负载均衡或端口转发；或者给二进制打 capability：setcap 'cap_net_bind_service=+ep' /path/to/sbin/nginx，之后非 root 也能绑 80。第三条要注意两点，一是文件被覆盖后 capability 会丢，二是部分文件系统不支持扩展属性，getcap查不到就是没生效。

5.2 reload 报 invalid PID number：-p 不一致或 pid 文件残留

现象：执行-s reload报nginx: [error] invalid PID number "" in "/xxx/logs/nginx.pid"，但进程明明在跑。

原因：nginx -s reload的工作方式是读 pid 文件拿 master 的 PID，再发信号。pid 文件路径来自配置里的pid指令，如果配的是相对路径，它会跟着-p变。启动用了 A 目录、重载用了 B 目录，读的就是两个不同文件，B 目录下那个是空的或者不存在。

解决：把pid写成绝对路径，启动和重载的命令行参数保持完全一致，最好直接封成一个固定脚本或 systemd unit。另外进程被kill -9后 pid 文件会残留，下次启动可能读到旧 PID，删掉残留文件再启，或者用-s quit正常停。

5.3 静态文件一律 403：目录权限与 user 指令的连锁反应

现象：curl返回403 Forbidden，error.log里是open() "/data/www/index.html" failed (13: Permission denied)。

原因：worker 进程按user指令指定的身份跑，非 root 启动时这个指令被忽略，实际用的是当前登录用户。如果静态目录属主是 root 且权限是700，worker 就没有读权限。另一条路径是父目录缺x权限，中间任何一层目录没有执行位，最终文件都读不到。

解决：namei -l /data/www/index.html这条命令会把路径上每一层的权限列出来，一眼看出卡在哪一层。修正方式是给目录加x、给文件加r，属主改成运行用户，不要图省事直接chmod 777，那只是把问题往后推。

5.4 上传大文件返回 413：默认 1m 的请求体上限

现象：上传稍大的文件返回413 Request Entity Too Large，日志里client intended to send too large body。

原因：client_max_body_size默认 1m，预编译包不会改这个值，这是 nginx 的出厂默认。

解决：在对应的server或location里按需设置client_max_body_size 50m;，不要放http块全局放大，那等于对所有接口开放。另外如果前面还有一层代理，那一层也要同步放开，否则请求根本到不了 nginx。这个大文件上传的问题我在项目里遇到过，改成 50m 还不够，继续报 413，才想起来前面还有一层没改。

5.5 运行一段时间后磁盘满但找不到大文件：日志句柄没释放

现象：df -h显示分区 100%，du -sh却统计不出对应大小的目录。

原因：日志文件被rm或mv到其他分区后，仍有进程持有句柄，磁盘块不释放。日志文件用rm删除，但 nginx 还开着文件句柄，所以空间没释放。

解决：用lsof +L1找出被删除但仍被占用的文件，确认是 nginx 后执行kill -USR1 $(cat nginx.pid)让它重开日志。根治办法是配 logrotate，用postrotate发USR1而不是copytruncate，后者在写入频繁时有丢日志的风险。

6. 把它做成可复用的运行基线：软链切换、版本验证与压测

单次部署跑通不算什么，能重复才是本事。我的习惯是把版本目录和软链分开：二进制解到/opt/nginx/1.25.2/，再用/opt/nginx/current指向它，配置、日志、站点目录都放在版本目录之外，这样升级只是换一个软链。

这里有个必须先想清楚的边界：nginx -s reload只让 master 重新加载配置、起新 worker，master 自己执行的仍然是启动时那个二进制，所以换软链后 reload 并不会真的换版本，nginx -V看到的还是老编译参数。真要换二进制只有两条路：直接停服重启，或者走USR2→WINCH→QUIT的平滑升级流程。

平滑升级的三步含义：USR2让 master 用新二进制拉起一个新 master，此时新旧两套共存、都监听同一端口；确认新 master 的日志和端口正常后，WINCH通知老 master 的 worker 优雅退出；观察一段时间没问题，QUIT结束老 master。中间任何一步不对，kill -HUP或直接回滚软链都还来得及，这就是提前留退路的做法。

验证环节不能只看curl通不通。我一般会补三件事：一是用ab -n 2000 -c 50 http://127.0.0.1:8080/或wrk -t4 -c100 -d30s跑一轮，看Requests per second和Failed requests，重点看后者是不是 0；二是如果包里有stub_status模块，加一个/status位置读Active connections和accepts/handled，handled小于accepts说明有连接被丢弃，得回头看worker_connections和LimitNOFILE；三是压测同时tail -f error.log，too many open files、worker_connections are not enough这两条会直接出现在日志里，比看指标快。

最后说个血泪经验：预编译包最大的风险不是它不好用，而是你默认它和源码编译出来的一样。每次拿到新包，先花三分钟跑nginx -V和ldd，再看一眼配置里所有相对路径，这三步做完了，后面基本不会翻车。至于那些版本号、模块清单和软链结构，建议直接写进部署脚本里，别靠记忆——我吃过记错 prefix 导致日志写进两个目录、排查时看了错文件的亏。希望帮到你。

本文还有配套的精品资源，点击获取