nginx 正确安装并监听 80 端口需依次检查：systemctl status nginx 确认 active (running)，ss -tlnp | grep :80 验证 nginx 进程监听，firewall-cmd 开放 http 服务，setenforce 0 排查 selinux 干扰。
如何确认 Nginx 是否已正确安装并监听 80 端口
很多新手执行 nginx -t 显示 syntax is ok 就以为万事大吉，结果 curl localhost 没响应——其实 Nginx 进程根本没起来，或者被防火墙/SELinux 拦了。
先检查进程：systemctl status nginx，注意看 Active 状态是否为 active (running)；再查端口：ss -tlnp | grep :80，确认是 nginx 进程在监听，而非其他服务（比如 Apache 占着 80）。CentOS 8+ 默认启用 firewalld，漏掉这步就必然 403/超时：firewall-cmd --permanent --add-service=http + firewall-cmd --reload。SELinux 在 enforcing 模式下会阻止 Nginx 访问非标准路径的文件，临时验证可运行 setenforce 0，若问题消失，说明需调整上下文或关闭 SELinux（不推荐生产环境直接关）。
server 块里 root 和 alias 的区别与误用场景
root 是拼接路径，alias 是完全替换。这是最常配错的地方，尤其做静态资源路由时。
比如想把 /static/ 映射到 /var/www/assets/：
location /static/ {
alias /var/www/assets/;
}
如果写成 root /var/www/assets;，Nginx 会尝试访问 /var/www/assets/static/，显然不存在。反过来，配置站点根目录必须用 root：root /var/www/html;，此时 location /blog/ 对应的物理路径是 /var/www/html/blog/。另外注意末尾斜杠：alias 值末尾必须有 /（否则会少一级路径），root 则无所谓。
为什么 gzip_static on 不生效
开启 gzip_static on 后仍返回未压缩的 .html 文件？常见原因有三个：
- 源文件未预生成对应 .gz 文件——Nginx 不会自动压缩，你得手动运行
gzip -k index.html生成index.html.gz - 未在
http或server块中启用gzip on（即使只用 static，基础 gzip 开关也得开着） - 客户端请求头没带
Accept-Encoding: gzip（curl 默认不带，测试要用curl -H "Accept-Encoding: gzip" -I http://localhost/）
还有个隐藏坑：gzip_static 只匹配同名 .gz 文件，不处理 MIME 类型过滤——所以记得配好 gzip_types，否则即便 .gz 存在，Nginx 也可能因类型不匹配而跳过它。
worker_connections 和 worker_processes 怎么设才不翻车
盲目抄网上“设成 cpu 核心数 × 1024”会导致连接数虚高、内存暴涨甚至 OOM。关键看实际并发模型：Nginx 是事件驱动，一个 worker 处理成千上万连接没问题，但每个连接会占内存（约 256KB–1MB，取决于 SSL、buffer 大小等）。
先查系统限制：ulimit -n（用户级）和 cat /proc/sys/net/core/somaxconn（内核级），worker_connections 不能超过前者；worker_processes 通常设为 auto（自动匹配 CPU 核心数），除非你明确要绑核或限制 CPU 使用率。高负载下更值得调的是 worker_rlimit_nofile（提升单 worker 打开文件数上限）和 reset_timedout_connection on（快速回收僵死连接）。
真正卡性能的往往不是 worker 数量，而是磁盘 I/O（日志刷盘）、SSL 握手（启用了 TLS 1.3 + OCSP stapling 会缓解）、或 upstream 超时设置不合理（比如 proxy_read_timeout 过短导致频繁断连）。
配置不是越复杂越稳，很多线上事故源于多加了一行 proxy_buffering off 却没配好 buffer 大小，结果小文件传输直接卡死。
