nginx启动失败应先检查systemd状态和日志：用systemctl status nginx查exit code，journalctl -u nginx查bind端口或pid目录权限问题，并确认execstart路径正确。
nginx 安装后启动失败：检查 systemd 服务状态和日志
安装完 nginx 常见的第一步卡点不是配置写错，而是服务压根没跑起来。直接 systemctl start nginx 返回 silent 或报 Job for nginx.service failed，别急着改 conf。
先确认 nginx 二进制是否在 PATH 里：which nginx；再看它能否手动运行：nginx -t（验证配置语法），nginx -c /etc/nginx/nginx.conf（手动加载配置试跑）。如果这里报错，才是配置问题；如果成功但 systemctl 启动失败，大概率是 systemd 单元文件或权限问题。
-
systemctl status nginx看最近一次失败的 exit code 和日志行 -
journalctl -u nginx --since "1 hour ago" -n 50查原始输出，重点关注bind() to 0.0.0.0:80 failed（端口被占）或open() "/var/run/nginx.pid" failed（/var/run 权限不对） - CentOS/RHEL 默认用
/usr/lib/systemd/system/nginx.service，检查其中ExecStart=是否指向你实际安装的路径（比如编译安装到/usr/local/nginx就得改）
worker_processes 和 worker_connections 怎么设才不浪费也不打满
这两个参数不是越大越好，也不是照搬网上“CPU 核数×2”的建议就安全。真实瓶颈常在文件描述符、内存或 upstream 连接数上。
默认 worker_processes auto 大多数情况够用，但如果你机器有 64 核却只跑一个静态服务，开满 64 个 worker 反而增加调度开销。更关键的是 worker_connections——它限制单个 worker 能同时处理多少连接，但总并发上限是 worker_processes × worker_connections，还得受系统 ulimit -n 约束。
- 先查当前最大文件描述符：
ulimit -n，若小于 65536，需在/etc/security/limits.conf加nginx soft nofile 65536并重启 session - 如果 nginx 主要反向代理 HTTP/1.1，平均每个连接存活 1–3 秒，按 QPS 估算：假设峰值 5000 QPS，平均连接时间 2 秒 → 需要约 10000 并发连接 →
worker_connections设 4096，worker_processes至少 3 - HTTP/2 或长连接场景下，连接复用率高，
worker_connections可适当调低（如 2048），避免单个 worker 内存占用过高
sendfile、tcp_nopush、tcp_nodelay 这三个开关怎么配
它们控制内核如何发送文件数据，对静态资源（JS/CSS/图片）吞吐影响明显，但错误组合反而拖慢小文件响应。
系统易学易懂，用户只需会上网、不需学习编程及任何语言，只要使用该系统平台，只要会打字，即可在线直接完成建站所有工作。本程序适合不懂php环境配置的新手用来在本机调试智能SiteSEO网站优化软件，安装过程极其简单。您的网站地址：http://localhost您的网站后台：登录地址： http://localhost/admin.php密 码： admin服务器套件所包含的软件：nginx-0.7
sendfile on 是核心：让内核直接从磁盘文件复制到 socket 缓冲区，绕过用户态内存拷贝。但仅对本地文件有效，proxy_pass 不走这条路。tcp_nopush 和 tcp_nodelay 是 TCP 层控制，且互斥——前者等缓冲区满再发（减少包数），后者禁用 Nagle 算法（降低小包延迟）。
- 静态文件服务必须开
sendfile on；若用了gzip on，则sendfile自动失效（因为要进 gzip 压缩流程），此时应关掉sendfile，改用gzip_vary on+gzip_proxied any -
tcp_nopush on推荐配合sendfile on使用，适合大文件传输（如视频、下载） -
tcp_nodelay on更适合 WebSocket、API 响应这类小包高频场景，但不要和tcp_nopush同时开，nginx 会忽略后者
access_log off 和 log_format custom 的取舍
日志不是越全越好。默认 access_log /var/log/nginx/access.log 在高并发下会成为 I/O 瓶颈，尤其是机械盘或容器环境。
关掉 access_log 最快，但失去所有请求追踪能力；折中方案是异步写入或采样记录。另外，log_format 里包含 $upstream_response_time 或 $request_time 等变量，会轻微拖慢处理速度（需计算时间差），但对排障价值极高。
- 调试期保留完整日志；上线后若 QPS > 5000 且磁盘 I/O wait 高，考虑
access_log /dev/null或用buffer=64k flush=5s异步刷盘 - 若用 ELK 收集日志，避免在
log_format中写冗余字段（如重复的 $host 和 $server_name），每多一个变量都增加解析开销 - $remote_addr 记录的是直连 IP，如果 nginx 前面有 LB，必须加
set_real_ip_from+real_ip_header X-Forwarded-For，否则所有日志里的 IP 都是 LB 的
调优永远是从监控出发，不是从参数出发。没开 stub_status 或没接入 nginx-module-vts 就调 worker_connections，就像蒙眼换轮胎。真正卡住的往往不是 nginx 本身，而是 upstream 响应慢、DNS 解析阻塞、SSL 握手耗时高——这些地方 nginx 日志里藏得深，得靠 $upstream_connect_time 和 $ssl_handshake_time 这类变量才能揪出来。
