杭州品茶网，Nginx调优深度解析：10个技巧让网站提速3倍

页面可用性和响应速度有明显改善：平均首屏时间从原来的2.4秒降到1.1秒左右，带宽消耗下降约四成，静态资源的缓存命中率稳定在70%以上，后端接口的错误率也降到了个位数。监控面板上高峰期的连接数曲线趋于平稳，磁盘写入压力也明显减轻。改动完成后的一次压测，连接并发400、持续30秒，99分位延迟比调整前低了近一半。说白了，就是“稳”了。

先说我们怎么确认效果的。改配置前先把监控和压测铺好：Prometheus拉取nginx-vts的数据，Grafana画图，关键看请求率、active connections、cache hit ratio、upstream响应时间。压测工具用wrk和ab，两套都跑，参数分别是wrk -t12 -c400 -d30s和ab -n10000 -c200。每次改完一项，就跑一轮，先观察错误码和后端延迟，再看客户端的响应时间分布。这个流程必须有，别靠感觉改配置。

监控到位之后，先动的是传输层和并发相关的参数。把worker_processes设成和CPU核数一致，不多不少；每个worker的最大连接数也拉高到能支撑预期并发的水平，注意是总连接数 = worker_processes * worker_connections。系统层面把sendfile、tcp_nodelay、tcp_nopush都打开，keepalive_timeout和keepalive_requests按场景调，减少频繁握手的开销。内核参数上，把net.core.somaxconn、net.ipv4.tcp_tw_reuse等设置到合理值，避免短连接堆积。做了这些之后，连接建立和维护的效率明显好转，尤其是在并发突增的时候。

接着是缓存和压缩。静态资源走长缓存，给图片、JS、CSS下发Expires或Cache-Control max-age=31536000，并加immutable标签，让浏览器少发If-Modified请求。动态内容用proxy_cache做代理缓存，按业务设定不同的cache zone和缓存键，避免重复打后端。具体操作上，proxy_cache_path配置好路径、大小和inactive时间；location里用proxy_cache_key、proxy_cache_valid控制不同状态码和内容的缓存策略。压缩方面给文本类开启gzip，把gzip_min_length设到合适值，别去压1KB的小文件，gzip_types列出html、css、js、json等常见类型，尽量减少传输量，特别是移动端收益明显。

在反向代理的缓冲和超时设置也下了工夫。proxy_buffer_size、proxy_buffers和proxy_busy_buffers_size根据上游响应大小调整，避免large uploads或慢后端时nginx把数据写到磁盘。proxy_read_timeout、proxy_send_timeout和send_timeout做了业务侧限流，防止某个慢请求把连接占死。之前日志里常见的“upstream timed out”基本少了。

协议层面把HTTP/2和TLS优化起来。启用HTTP/2后，多路复用减少了页面上并发小文件请求的延迟，配合TLS 1.3和一套现代的加密套件，既提高了安全性也提升了性能。证书链、OCSP、session resumption这些也一并检查过，避免TLS握手成为瓶颈。整合后，尤其是移动网络环境下，握手和首包时间都有改善。

关于日志和磁盘I/O的优化也不能忽视。高流量站点的访问日志极容易把磁盘写爆，采取了有条件地记录访问日志（按需记录错误或特定路径），同时用logrotate做周期归档和压缩。再配合nginx的map或geo模块，先把已知的爬虫或恶意IP按规则拦截在外面，减少无效日志写入。效果是磁盘写入量下降，监控报警也少了。

静态资源的优化除了缓存，还有合并与CDN策略。前端构建阶段通过Webpack把多个小文件打包、压缩、做哈希命名，减少浏览器的请求数和缓存失效情况。资源上CDN后端只保留必要的回源，边缘节点缓存降低了源站带宽和延迟。在nginx上则保持合理的cache-control头，避免CDN和浏览器之间产生冲突。

监控到位后，针对短板进行有针对性的微调。比如发现某些大文件请求会占用较多buffer，就把对应location单独设置较大的proxy_buffers；某些API响应体积虽小但高QPS，就开启更短的cache短期缓存，降低后端压力。每改一项都记录配置变更和对应的压测结果，便于回滚或二次优化。实践告诉人：不做记录，调了就忘，风险会累积。

安全和访问控制上也做了基本的硬化。限制不必要的HTTP方法，设置合理的client_max_body_size防止大流量上传压垮服务；对敏感路径做了IP白名单或简单鉴权，减少被滥用的可能。nginx本身有限额，复杂的防护则借助WAF或上游网关来处理。

这是从结果向前倒推的流程。要回到最初的原因：为什么要改？因为默认的Nginx配置偏保守，既没开启压缩也没做缓存策略，日志无差别记录，worker设置也往往没为高并发优化。真实的线上表现就是延迟高、带宽吃紧、后端压力大，监控面板会告诉你这些问题在哪。我们先把监控铺好，再做逐项优化，最后通过压测验证。

最后一次完整验证是在把缓存、压缩、协议和连接参数全部调整完后进行的。那次wrk跑了30秒，并发400，95分位和99分位的延时都下降，后端的平均响应时间也稳住在可接受区间。面板上能看到的是：cache hit提升、后端请求减少、错误率下降。调试过程里碰到的坑不少，但一步步来，能看见变化，这点挺让人有成就感的。