选择一个 适用于 Nginx 的 Linux 专用服务器 可以提升高流量网站、API 网关和反向代理的性能。然而，仅靠专用硬件并不能保证更高的并发能力。不正确的 worker 设置、文件描述符限制、TLS 开销以及上游应用程序运行缓慢等因素，都可能在服务器达到其标称容量之前，就已限制了吞吐量。
本指南介绍了实用的 Nginx 调优方法、合理的连接限制，以及从 VPS 或共享基础设施升级时需要考虑的关键硬件因素。
Nginx 如何处理高并发
Nginx 采用事件驱动架构来管理大量连接，而无需为每个请求创建单独的线程。在 Linux 系统上，诸如 epoll 之类的高效事件通知机制有助于工作进程处理网络活动。
尽管如此，连接容量仍取决于 CPU 资源、内存、操作系统限制、上游服务以及流量特征。一万个空闲连接所消耗的资源，与一万个同时进行的数据库请求所消耗的资源并不相同。
在调整配置之前，请先测量活跃连接数、每秒请求数、响应延迟以及上游处理时间。
配置 worker_processes 和 worker_connections
有两个重要的 Nginx 指令用于控制工作进程的并发性：worker_processes 和 worker_connections。
设置工作进程
以下配置可让 Nginx 根据可用的 CPU 资源来选择工作进程数量：
worker_processes auto;
events {
worker_connections 4096;
multi_accept off;
}对于许多专用服务器而言，自动选择工作进程是一个合理的起点。当应用程序受限于存储、上游处理或网络带宽时，增加工作进程数量并不一定能自动提升性能。
了解连接限制
工作者连接限制适用于每个工作者处理的连接，包括与代理上游服务器的连接。
8个工作进程配置为支持4,096个连接，其理论上的工作进程连接总数上限为32,768。但这并不保证能处理32,768个并发客户端请求。
由于文件描述符限制、上游连接、内存占用以及其他限制因素，实际容量可能会低于此数值。
安全地提高 Linux 文件描述符限制
在不检查操作系统限制的情况下增加 worker_connections 值，可能会导致“打开的文件过多”等错误。”
检查正在运行的服务的文件描述符限制和 systemd 配置。在适当的情况下，将服务限制配置为更高，并使其与 Nginx 设置保持一致。
worker_rlimit_nofile 65535;本指令并不能独立地覆盖所有操作系统限制。请检查 systemd 的 LimitNOFILE 设置，并测试运行中的工作进程的实际限制。
避免盲目提高限制值。请监控内存使用情况和连接行为，以确保服务器能够支持额外的工作负载。
优化 TLS 1.3 和 HTTPS 性能
TLS 协商会消耗 CPU 资源，尤其是在客户端建立大量新连接时。现代 TLS 配置、连接复用以及高效的证书处理可以减少不必要的开销。
一个实用的 HTTPS 配置可能包括：
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;请确认与您已安装的 Nginx 和 OpenSSL 版本兼容。在部署前，请正确配置证书链并测试安全设置。
会话复用可以减少重复的握手操作，而 HTTP/2 则可能提高支持该协议的客户端的连接效率。HTTP/3 需要兼容的软件和网络配置。
有关协议选择和兼容性，请参阅我们的 TLS 1.2 与 TLS 1.3 的对比.
保持连接和反向代理优化
Keepalive 连接可减少重复建立连接的情况，但过长的空闲超时时间会增加资源消耗。
对于反向代理，需区分客户端的保持活动（keepalive）行为与上游连接的复用。请核实上游应用程序支持的 HTTP 行为及超时要求。
在诊断网关错误时，请检查 proxy_connect_timeout、proxy_read_timeout 和 proxy_send_timeout 参数。增加这些参数的值可能会掩盖应用程序响应缓慢的问题，而非解决其根本原因。
HTTP 502 错误可能表明上游连接失败，而 504 错误通常反映上游超时情况。在更改限制之前，请检查应用程序日志和网络指标。
CPU、内存和网络瓶颈
专用 CPU 资源可以通过消除物理主机上与该租户无关的资源争用，从而提高性能的可预测性。不过，处理器代数、时钟行为以及应用程序效率仍然至关重要。
内存必须容纳工作连接、缓冲、TLS 状态、操作系统服务以及上游应用程序。
对于大文件下载、媒体传输以及高流量的 API 请求而言，网络吞吐量可能会成为主要的瓶颈。应比较持续带宽和传输策略，而不仅仅是广告宣传的端口速度。
我们的 VPS CPU 抢占时间故障排除指南 有助于在迁移前识别与虚拟化相关的性能问题。
在购买硬件前对 Nginx 进行性能测试
使用 wrk、k6 或其他合适的负载测试框架等工具来模拟具有代表性的流量。在不会成为瓶颈的基础设施上运行测试。
测量吞吐量、连接失败次数、CPU 利用率以及 p95 或 p99 延迟。测试时应包含动态应用程序请求，而不仅仅是测试静态文件。
逐步增加并发量，当延迟或错误超过可接受的阈值时停止测试。请在授权环境中进行测试，以免影响生产环境的用户。
如需进行更全面的能力规划，请参阅我们的 云服务器容量规划指南.
四家 Linux 专用服务器提供商对比
这些经过认证的基础设施提供商均可用于部署 Nginx。具体的配置、网络策略和管理访问权限取决于所选产品。
GTHost：专用 CPU 和网络
GTHost 值得评估其是否能满足持续的网络流量和区域部署需求。请比较不同代的处理器、内存、网络容量以及远程管理功能。
Cherry 服务器：以计算为中心的基础设施
Cherry 服务器 当处理器选择、内存容量和存储性能会影响 Nginx 及上游应用程序的工作负载时，这一点尤为重要。请核实所选服务器的硬件配置和部署选项。
InterServer：经济型 Linux 主机
InterServer 这为专用硬件和经常性成本提供了另一个比较依据。请确认 Linux 的安装选项、管理职责、存储规格以及网络配额。
NovoServe：网络密集型应用程序
NovoServe 当网络容量和部署地域是重要考量因素时，这一点值得考虑。请咨询有关带宽承诺、端口配置和基础设施支持等具体产品的详细信息。
应比较完整的配置方案和基准测试结果，而不是一味认为广告中宣称的核心数越多，Nginx 的性能就越好。
什么时候应该升级到独立主机？
当经过优化的应用程序持续占用 CPU 资源、面临内存压力，或者需要更可预测的网络和存储性能时，请考虑使用专用硬件。
在迁移之前，请确认数据库查询、缓存和上游服务并非主要瓶颈。
我们的 SaaS 应用程序专用服务器对比 提供了额外的硬件选择指南。
常见问题解答
Nginx 最多能处理多少个连接？
没有一个放之四海皆准的数值。容量取决于工作节点的配置、操作系统的限制、可用资源、上游行为以及工作负载特征。
TLS 1.3 能让 Nginx 运行得更快吗？
对于受支持的连接，TLS 1.3 可以减少握手过程中的往返次数，但实际的应用程序性能取决于连接复用、网络延迟和服务器资源。
专用主机是否总是比VPS更好？
不。现代的VPS在性能上可能优于老式的专用硬件。请比较持续性能测试结果、资源保障、管理成本以及可扩展性要求。
最终裁决
有效的 Nginx 调优应从设定合理的 worker 数量上限、配置文件描述符、安全的 TLS 设置以及具有代表性的负载测试开始。
比较 GTHost, Cherry Servers、InterServer 和 NovoServe，这些服务均基于经过验证的硬件规格、网络策略和完整的运营成本。当实际工作负载需求证明有必要采用专用基础设施时，请进行升级。
