Nginx 常见配置错误
内容提要
本文总结了Nginx常见的配置错误，包括文件描述符耗尽、无法关闭错误日志、上游未开启长连接、混淆配置继承规则和Alias安全风险。文章提供了解决这些问题的方法和建议。
延伸解读
文件描述符限制：worker_connections 与系统上限的配合
文章指出，仅设置 worker_connections 不足以避免 FD 耗尽，因为系统对每个用户打开的 FD 数量有默认限制（通常 1024）。实际消耗需乘以工作进程数，且受 fs.file-max 全局限制。因此，调整 worker_rlimit_nofile 和系统级 fs.file-max 是必要的，但需注意 worker_rlimit_nofile 乘以 worker_num 不能超过 fs.file-max，否则仍可能报错。
关闭错误日志的正确方式与常见误区
文章强调，使用 error_log off; 并不会关闭错误日志，而是会创建一个名为 off 的日志文件。正确做法是 error_log /dev/null emerg;，将日志写入 /dev/null 设备。这一细节容易被忽略，尤其在磁盘空间受限时，错误配置可能导致意外文件生成，占用空间或造成混淆。
上游长连接：减少 TIME-WAIT 与端口耗尽风险
Nginx 默认与上游使用短连接，每次请求都需三次握手，且关闭后套接字进入 TIME-WAIT 状态（Linux 默认保持五分钟），大量请求可能导致本地端口耗尽。开启 keepalive 可复用 TCP 连接，但需注意 keepalive_requests 限制每个长连接的最大请求数，以及需在 location 中设置 proxy_http_version 1.1 和 Connection 头为空，否则上游可能主动关闭连接。
配置继承实为覆盖：add_header 的层级陷阱
文章澄清，Nginx 的配置继承实际上是低层级覆盖高层级。对于 add_header 指令，若在 server 或 location 中定义了任何 add_header，则 http 层级的 add_header 不会自动继承，而是被完全覆盖。这意味着若希望多个 header 同时生效，必须将所有 add_header 都写在最底层的配置块中，否则可能丢失预期响应头。
Q&A
Nginx 中如何解决文件描述符耗尽的问题？
可以通过设置 worker_connections 和 worker_rlimit_nofile 来限制每个工作进程的 TCP 连接数量和最大文件描述符数量。
如何正确关闭 Nginx 的错误日志？
应使用配置 error_log /dev/null emerg; 来关闭错误日志，而不是 error_log off;，后者会创建名为 off 的日志文件。
Nginx 如何开启与上游服务器的长连接？
可以在 upstream 配置中添加 keepalive 指令，例如 keepalive 16;，并在 proxy_pass 中设置 HTTP/1.1 协议。
Nginx 配置中的继承规则是怎样的？
低层级的配置块优先级高于高层级，低层级配置会覆盖高层级配置。
如何保护 Nginx 的系统状态信息？
可以通过 HTTP Basic 认证或限制 IP 网段来保护状态信息，例如使用 auth_basic 和 allow/deny 指令。
使用 Nginx 的 alias 指令时需要注意什么？
使用 alias 时需确保路径安全，避免用户绕过目录限制，例如应使用 location /pic/ { alias /data/pic/; } 的形式。
