并发上不去、响应变慢？Nginx 性能优化的选型逻辑

并发上不去，问题可能不在 Nginx 本身

有站长反馈，Nginx 配置照着教程改了一遍，并发还是卡在几百就上不去了。这种情况往往不是参数问题，而是底层资源先到顶了。连接数、文件描述符、磁盘 IO、带宽，任何一个环节卡住，Nginx 都跑不快。

排查顺序建议从系统层开始：先看 ulimit 和 sysctl 的文件描述符限制，再看磁盘 IO 是否吃满，最后才回头看 Nginx 配置。很多所谓「Nginx 性能问题」，其实是系统默认值太小导致的。

不同业务场景，优化重点完全不同

静态资源站和动态 API 服务的优化思路差别很大。静态站吃带宽和磁盘 IO，动态站吃 CPU 和内存。

• 静态资源站：重点在 sendfile、gzip 和缓存策略，硬件上优先保证带宽和磁盘读写。
• API 网关：重点在连接复用和超时设置，CPU 单核性能要够强。
• 反向代理：重点在 upstream 配置和健康检查，网络延迟比算力更关键。

搞清楚自己的业务属于哪一类，优化才能有的放矢。

选机器：Nginx 场景下什么配置更划算

Nginx 对 CPU 单核性能敏感，但对核心数没那么贪婪。与其买一堆低频核心，不如选单核性能强的型号。内存方面，如果做缓存或反代，适当大一点有好处，但没必要盲目堆。

真正容易被忽略的是带宽和磁盘。如果站点面向港澳台和东南亚用户，延迟要求高，可以考虑香港裸机云 XII，E5-2683v4*2 配 64G 和 20M 带宽，做 Nginx 反代和静态分发都比较稳。

如果是面向欧美的大流量场景，带宽需求更大，那 G 口机器更合适。美国硅谷大带宽服务器 X 提供 G 口带宽，适合做下载节点或 CDN 回源，跑 Nginx 分发时不会因为带宽先卡住。

优化是匹配，不是堆配置

Nginx 性能优化的核心逻辑是「匹配」：参数匹配业务、硬件匹配流量。盲目照搬别人的配置，或者一味加 CPU 内存，都容易花冤枉钱。先压测、再定位、最后调优，顺序不能反。