前言

1Panel 的用户越来越多，内置 Web 服务 OpenResty 使用占比也在增加，但网上对其优化的教程很少。博主之前用的是宝塔之前也切换到了1panle了，今天就更新一篇有关 OpenResty 的一些优化建议。可优化设置项较少，需要的小伙伴可以根据实际需求变更配置。如不知道如何迁移网站的可以参考：新手如何将面板从宝塔替换为1panel

1Panel OpenResty 性能优化指南

OpenResty 的优化项大多继承自 Nginx。在 1Panel 的环境中，您通常需要在配置文件（如 nginx.conf 或相应的虚拟主机配置）中进行调整。

1. 核心 Worker 进程优化 (在 nginx.conf 的 main 或 events 块)

这是决定服务器并发处理能力的最重要配置。

📝 注意： 在 1Panel 中，您需要确保系统级别的 ulimit -n 值大于 worker_connections 的设定值，否则配置无法生效。

2. HTTP 请求与连接优化 (在 http 块)

这些设置影响客户端与服务器通信的效率。

3. 启用 Gzip 压缩

虽然会增加 CPU 负载，但可以极大地减少传输数据量，提升用户体验，尤其是在带宽有限的情况下。

4. OpenResty LuaJIT 相关优化 (在 http 块)

OpenResty 核心的性能优势在于 LuaJIT。确保启用 Lua 代码缓存是至关重要的。

5. 日志优化

在高并发场景下，频繁的磁盘 I/O 写日志会成为瓶颈。

6：server_names_hash_bucket_size 参数优化

核心原理与意义

1. 哈希表 (Hash Table)： Nginx 使用哈希表来快速查找客户端请求的 Host 头属于哪个 server 块。server_names_hash_bucket_size 定义了这个哈希表每个桶 (Bucket) 的最大字节数。

2. 触发错误： 如果您配置的 域名过长 或 域名数量过多 导致 Nginx 在初始化时无法将所有域名放入哈希表桶中，Nginx 会启动失败并报错：

   could not build server_names_hash, you should increase server_names_hash_bucket_size

3. 优化目标： 调整此参数的目的是为了避免哈希冲突和确保所有域名能被成功加载，同时尽可能地减少查找时间。

优化建议

默认值： 默认值通常为 32 或 64 字节（取决于 CPU 缓存行大小）。

配置位置

该参数通常配置在 Nginx 配置文件的 http 块中：

Nginx

http {
    # 建议在此处进行配置
    server_names_hash_bucket_size 128; 
    # server_names_hash_max_size 512; # 另一个相关参数
    ...
}

重点提示：

增大此值会轻微增加内存使用，但能显著提高域名查找的稳定性和初始化成功率。在 1Panel 的环境中，如果您的 Web 服务数量较多，建议将其设置为 128 或 256。

7：client_header_buffer_size 参数优化

核心原理与意义

1. 功能： 该参数定义了 Nginx 用于存储客户端请求行（如 GET /path HTTP/1.1）和请求头（如 Host, User-Agent, Cookie 等）的内存大小。

2. 默认值： 默认值通常为 $1\text{k}$ 字节（即 1024 字节）。

3. 触发错误： 如果客户端发送的请求头（尤其是 Cookie 字段或包含大量自定义头的请求）的总大小超过此限制，Nginx 无法完整读取请求头，会立即返回 HTTP 400 Bad Request 错误给客户端。

优化建议

默认值： $1\text{k}$

注意事项

• 内存消耗： 这个缓冲区是针对每个连接分配的。如果设置得太大（例如 $32\text{k}$）并且并发连接数很高（例如 10,000 个连接），会显著增加 Nginx 的内存消耗（$10,000 \times 32\text{k} \approx 320\text{MB}$）。

• 配置位置： 该参数配置在 Nginx 配置文件的 http 块中。

建议： 从小处开始调整。 优先将缓冲区大小从 $1\text{k}$ 增加到 $4\text{k}$ 或 $8\text{k}$。只有在确认 $8\text{k}$ 仍然出现 400 错误时，才考虑进一步增加到 $16\text{k}$ 或 $32\text{k}$。

8：client_max_body_size 参数优化

核心原理与意义

1. 功能： 此参数控制了 Nginx 接受的 HTTP 请求中 POST 或 PUT 等请求方法携带的数据体（如表单数据、文件内容、JSON/XML负载等）的上限。

2. 默认值： 默认值通常为 $1\text{m}$ (1 兆字节)。

3. 触发错误： 如果客户端发送的数据体大小超过此限制，Nginx 会立即返回 HTTP 413 Request Entity Too Large 错误给客户端，并在日志中记录相关信息。

4. 重要性： 设置合理的限制是重要的安全措施，可以防止拒绝服务 (DoS) 攻击——通过发送超大请求来耗尽服务器的内存和带宽资源。

优化建议

默认值： $1\text{m}$

注意事项与配置

• 单位： 可以使用 $k$ (千字节)、$m$ (兆字节) 或 $g$ (吉字节) 作为单位。

• 内存消耗： 这个参数不会直接大幅增加 Nginx 的内存消耗，因为 Nginx 通常会将请求体写入临时文件，而不是完全加载到内存中。但过大的值会增加磁盘 I/O 和处理时间。

• 配置位置： 该参数可以在 Nginx 配置文件的 http 块、server 块 或 location 块中配置。

  • 在 location 块配置时，可以为不同的路径提供不同的限制，例如：

    Nginx

    http {
        client_max_body_size 10m; # 默认值
    
        server {
            location /upload/videos {
                client_max_body_size 512m; # 针对特定上传路径放宽限制
            }
        }
    }
    

• 代理链： 如果 OpenResty 前面还有负载均衡器或 CDN (如 Varnish, Cloudflare)，也需要确保整个代理链路上所有设备的请求主体限制都大于或等于此值，否则客户端仍可能被上游设备拒绝。

9：keepalive_timeout 参数优化

核心原理与意义

1. 功能： 此参数定义了客户端与服务器建立连接后，在没有数据传输时，连接可以保持空闲的最大秒数。

2. HTTP/1.1 与 Keep-Alive： HTTP/1.1 默认启用 Keep-Alive (持久连接)。它允许在同一 TCP 连接上发送和接收多个 HTTP 请求/响应，而不是每发送一个请求就建立和断开一次连接。

3. 重要性：

   • 提高效率： 避免了频繁建立和断开 TCP 连接（三次握手/四次挥手）的延迟和开销。

   • 性能提升： 对于加载多个资源的网页（如图片、CSS、JS），可以在一个连接上快速完成加载，显著减少延迟。

4. 超时后果： 一旦连接空闲时间超过 keepalive_timeout，Nginx 会主动关闭该 TCP 连接。

优化建议

推荐范围： 60 秒到 90 秒。

注意事项与配置

• 资源占用： 时间过长（如 $300\text{s}$）会导致 Nginx 的 Worker 进程持有大量空闲连接，消耗内存和文件描述符，在高并发下可能导致资源耗尽。

• 时间过短： 时间过短（如 $10\text{s}$）会迫使客户端频繁重新建立连接，反而增加了延迟和 TCP/IP 握手开销。

• 配置位置： 该参数通常配置在 Nginx 配置文件的 http 块中：

Nginx

http {
    keepalive_timeout 65; # 推荐值
    
    # 另一个相关参数：限制单个连接上允许的最大请求数
    keepalive_requests 100; # 默认值，不宜过大
    ...
}

结论： 将 keepalive_timeout 保持在 60-75 秒的范围内，是平衡性能提升和资源占用的最佳实践。

优化后的配置示例

http {
    # gzip相关配置
    gzip on;
    gzip_min_length 1k;
    gzip_comp_level 6;
    gzip_buffers 4 16k;
    gzip_http_version 1.1;
    gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php application/json;
    gzip_vary on;
    gzip_proxied any;
    gzip_disable "msie6";

    # 服务器名字hash表大小
    server_names_hash_bucket_size 128;

    # 客户端请求头缓冲区大小
    client_header_buffer_size 32k;
    large_client_header_buffers 4 32k;

    # 客户端请求主体最大允许大小
    client_max_body_size 32m;

    # 长连接超时时间
    keepalive_timeout 60;

    # 其他配置...
}

总结

以上就是今天分享的全部内容了，都是基于VMRack 三网精品 4核4G的机器捣鼓出来的。你可以根据网站的负载类型（静态服务多还是动态计算多）和资源配置（CPU 核心数、内存大小）来调整上述配置，并在实际环境中进行压力测试以找到最佳平衡点。

VMRack 机房在美国洛杉矶 Equinix LA4 金融级数据中心，主打配备全新 AMD EPYC 7K62 高性能处理器，CPU 核心数高达 192 个，vCPU是1：1的资源配比性能稳定，采用分布式块存储和三副本机制，大大提高了磁盘读写能力，轻松应对超高IOPS需求。现目前主要运营三条线路：三网精品（CN2 GIA/9929/CMIN2）、三网优化（163/10099/CMI）以及 美国原生（Global BGP），三条线路基本满足绝大部分人群的日常使用需求以及中小企业日常的办公需求。可以说 VMRack 在线路方面是非常具有竞争优势的。三网精品直连为中国大陆用户提供了低延迟，高速度的优化网络体验，对于日常办公、娱乐、看视频以及海外电商都是非常适用的；三网优化具有非常大的带宽口子，非常满足需要大流量下载的应用场景，比如CND内容分发、影视站点播等；而美国原生则者主打极致性价比和全球连接性，作为美西落地机是非常具有性价比的。

官网地址：https://www.vmrack.net/

TG交流群： https://t.me/vmrack_chat