低配置VPS运行Nginx需严格控内存：设worker_processes 1、worker_connections 512；关闭access_log、gzip_static、open_file_cache；简化SSL；调小缓冲区与超时；目标单worker≤60MB（HTTP）或≤100MB（HTTPS）。
低配置机型（如1核1GB内存的VPS）运行Nginx时，内存占用容易成为瓶颈。默认配置下，Nginx主进程+多个worker进程可能轻松占用300MB以上内存，尤其在启用日志、缓存或HTTPS后更明显。关键不是“能不能跑”，而是“如何稳定不OOM”。核心思路是：精简进程模型、关闭非必要模块、限制缓冲区与连接数。
精简worker进程与连接模型
Nginx默认会根据CPU核心数启动worker进程，但在单核机器上开多个worker不仅无益，反而增加调度和内存开销。同时，每个连接都会分配内存用于读写缓冲区和SSL上下文（若启用HTTPS），必须严格限制并发连接规模。
-
固定为单worker：在
nginx.conf中设置worker_processes 1;，避免多进程竞争和额外内存副本 -
降低worker连接上限：设置
worker_connections 512;（而非默认的1024或更高），配合events { use epoll; }提升单进程效率 -
全局连接限制：用
limit_conn_zone $binary_remote_addr zone=addr:10m;+limit_conn addr 10;防止单IP耗尽连接资源
关闭默认启用但低配无需的功能
很多功能在小站点中纯属冗余，却持续占用内存（如缓存元数据、日志缓冲、SSL会话存储）。编译时已静态链接的模块无法卸载，但运行时可禁用其行为。
-
禁用access_log：将
access_log off;加入 http/server/location 块；若需调试，改用access_log /dev/null;避免磁盘IO和日志缓冲区 -
关闭gzip_static和open_file_cache：注释或删除
gzip_static on;和open_file_cache相关指令，前者预加载.gz文件占内存，后者缓存文件句柄和元信息，在小站中收益极低 -
简化SSL配置：禁用会话复用（
ssl_session_cache off;）、缩短超时（ssl_session_timeout 1m;），避免维护大量SSL会话状态
调低缓冲区与超时参数
每个HTTP请求/响应都涉及多级缓冲区（client_header_buffer、client_max_body_size、fastcgi_buffer等），默认值面向中高负载设计，对1GB内存机器过于奢侈。
-
缩小客户端头/体缓冲：设
client_header_buffer_size 1k;、large_client_header_buffers 2 1k;、client_max_body_size 1m; -
缩短各类超时：例如
client_body_timeout 5s;、client_header_timeout 5s;、keepalive_timeout 15s;、send_timeout 5s;，加速连接释放，减少空闲连接驻留内存 -
反向代理场景特别注意：若用作前端代理（如转发到PHP-FPM），需同步调低
fastcgi_buffer_size、fastcgi_buffers（如fastcgi_buffers 8 4k;）和proxy_buffering off;（禁用代理缓冲可省百MB）
验证与持续观察
配置调整后不能只看Nginx是否启动，要实测RSS内存占用和稳定性。建议使用轻量工具持续跟踪，避免“看似正常实则临界”。
-
查看真实内存占用：用
ps aux --sort=-%mem | grep nginx查看各进程RSS值，重点关注worker进程，目标控制在单个worker ≤60MB（纯HTTP）或 ≤100MB（启用HTTPS） -
模拟压测验证：用
ab -n 1000 -c 50 http://your-site/观察是否出现502/503或系统OOM Killer杀进程（dmesg -T | grep -i "killed process"） -
启用简易监控：配合
nginx_status模块（需编译含--with-http_stub_status_module）+ cron脚本每分钟记录活跃连接数与接受连接数，趋势异常可及时干预
