Nginx配置完整手册：从入门到高可用部署

配置都改好了，直接来个热加载，网站没掉线，旧进程把手里的连接收尾后退出，新进程接过活儿。就这么一套动作，改配置、跑语法、发个 HUP，线上不停机地把配置换了。这个最后一步特别关键：改完 nginx.conf 或者那些 include 的小文件，别着急发 HUP，先跑一遍 nginx -t，看语法没报错再重载。许多半夜被拉起来的事故，都能从这一步省下来。

在发 HUP 之前，运维一般会做几件事，这不是形式，是把风险留到最小。把配置按功能拆开，放到 /etc/nginx/conf.d/ 和
/etc/nginx/sites-available/，用 include 引过来，清清楚楚；改动都提交到 Git，谁改了什么一目了然；文件权限也要调好，nginx 用户只给读必要的文件。这套流程的核心就是：出事好查，回滚好做。

再往前一步，就是改具体的配置。理解 nginx 的层级很重大：最外面是 main（进程级设置），下面是 events（并发相关），再下面是 http（HTTP 的指令都在这或嵌套），http 里面可以定义 upstream、server，server 里写 location。许多指令只能写在特定块里，放错地方要么报错要么不起作用。举几个常见的：worker_processes 要放 main；worker_connections 在 events；upstream 在 http；listen 和 server_name 在 server；root、index、location 则放在 server 或 location 里。

估算并发能不能顶住，心里要有个数字。一个简单的估算公式是：最大连接数大致等于 worker_processes * worker_connections。把这个放脑子里，方便你判断系统能承载多少并发，再去调 worker_processes（列如设置成 auto 或者按 CPU 核心数）和 worker_connections（看实际负载和文件描述符限制）。

常见场景就是反向代理：location 里用 proxy_pass 把请求转给后端（Tomcat、Node、Django 什么的）。后端放到 upstream 里，挑个负载算法（轮询、ip_hash、least_conn 都有人用）。静态资源是 nginx 的强项，I/O 模型让它处理图片、CSS、JS 特别省心。要上 HTTPS，就在 server 写 listen 443 ssl，然后配 ssl_certificate 和私钥路径，还要思考强制跳转、HSTS、现代加密套件这些细节，既合规又让用户体验好一点。

location 的匹配规则容易踩坑，要记清优先级：准确匹配 = 最先命中；接着是以 ^~ 开头的前缀，表明如果匹配就不要再试正则了；再下来按配置顺序匹配正则；最后才是普通前缀匹配。这个顺序决定了某些请求到底由哪条规则处理。常见做法有：用 = /favicon.ico 准确处理小文件，用 ^~ /static/ 把静态目录直接交给 nginx，避免正则白忙活。

安全不要省。把 server_tokens off; 写上，别暴露版本号；加一些安全头、限流、基于 IP 的 allow/deny，遵循最小权限原则。CSRF 可以检查 Referer，或者在访问阶段做 Token 验证。OpenResty 在这方面好用，它在 nginx 基础上加了 Lua，可以在访问、内容、日志等阶段嵌入脚本，做鉴权、限流或者动态路由。遇到上游节点常常变动的场景，可以把 Consul-Template 拉进来，和 Consul 的服务发现配合，用模版自动改写 upstream 并触发重载，省得人工去改每台机器。

排查问题时工具链也要准备好。语法检查用 nginx -t；看端口和连接用 ss 或 netstat；测试接口用 curl 或 httpie。监控方面，内置的 stub_status 能给基础指标，访问 /nginx_status 会返回 active connections、accepts、handled、requests 等。想要可视化，常用 nginx-prometheus-exporter 或带 VTS 模块的 exporter，把指标拉到 Prometheus，再用 Grafana 做面板。别忘了把 /etc/nginx 纳入版本控制，改动有记录，部署和回滚都有据可依。

一些容易被忽视的小细节，早知道就不会傻等半天。别把所有配置塞进一个文件，拆分后便于管理和审查；复杂的段落要加注释，写清楚为什么这样配，免得后来人猜来猜去；文件权限和运行用户按最小权限配置，减少被滥用的风险。遇到 403 Forbidden，先从权限、root、index 配置和 deny 规则找起，大多数是这几项的问题。

负载均衡的部署里，upstream 可以列多台后端，配合健康检查或者外部工具，把不健康的后端剔除。proxy_pass 不只是转发，还能配合 header、timeout、buffer 等指令把行为细化。关于 HTTPS，除了证书路径别忘了把 session、重定向、HSTS、加密套件全盘思考，别只把证书丢进来就跑。

运维记录很关键。每次改动把测试结果、回滚步骤记录在变更单里，CI/CD 里把语法校验和自动化测试挂上，先在预生产跑一遍再上。线上要回退时，用 git revert 找回历史版本比手敲配置更可靠、更快。紧急情况下，一条 revert 就能把服务拉回到可用状态，比现场改几处配置稳当得多。

再给个实操清单，按步骤走能少犯毛病：修改配置后先跑 nginx -t；把配置拆分并用 include 管理；改动提交到版本控制；检查文件权限并在关键段落加注释；发 HUP 做热重载，观察老进程退出和新进程接手；用 ss/netstat 和 curl 验证监听和接口；用 stub_status 或 Prometheus 监控关键指标。常见的指令放这儿，心里有谱：worker_processes（main），worker_connections（events），listen/server_name（server），root/index（server 或 location），location（URI 路由），proxy_pass（反向代理），upstream（http 定义后端组），ssl_certificate（证书路径），allow/deny（IP 控制），limit_req_zone（http 定义限流内存）。按场景搭配这些指令，就能把 nginx 配成适合你业务的样子。