Nginx本身不支持CGI连接池，因CGI每次请求均fork新进程且无复用机制；优化需依赖外部FastCGI管理器（如php-fpm的pm.*参数）及Nginx的fastcgi_timeout、fastcgi_buffers等代理配置，并可选fastcgi_cache或迁移到HTTP反向代理等现代方案。
明确 CGI 在 Nginx 中的运行机制
CGI 不走 Nginx 的 upstream 或 proxy 模块，而是由 fastcgi_pass（或 scgi_pass、uwsgi_pass）配合外部守护进程（如 spawn-fcgi、fcgiwrap、php-fpm）来承载。真正可配置“连接池”的，是这些外部 FastCGI 管理器，不是 Nginx 本身。
关键配置落在 FastCGI 管理器上
Nginx 只负责转发请求，实际连接复用、进程复用、空闲进程缓存等均由 FastCGI 后端控制。例如：
-
php-fpm：通过
pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers控制子进程池大小；pm.max_requests控制单进程处理请求数（防内存泄漏） - fcgiwrap（轻量 CGI 封装器）：无内置连接池，需配合 systemd socket 激活或 supervisord 实现进程复用，但默认仍是 per-request fork
-
spawn-fcgi：支持预启动固定数量 CGI 进程，相当于简易进程池，可通过
-F参数指定进程数
Nginx 端需匹配的代理参数
虽然 Nginx 不管 CGI 进程池，但它必须正确配置 FastCGI 代理行为，避免因超时或缓冲不当导致请求失败或资源堆积：
-
fastcgi_connect_timeout 30s：建立到 FastCGI 后端的连接超时 -
fastcgi_send_timeout 300s：发送请求头/体给后端的超时（尤其对长编译类 CGI 很关键） -
fastcgi_read_timeout 300s：等待 FastCGI 响应的超时 -
fastcgi_buffers 16 64k和fastcgi_busy_buffers_size 128k：防止大响应体触发临时文件写入 -
fastcgi_cache（可选）：对幂等 CGI 输出做缓存，减少重复执行 —— 这是最接近“连接池效果”的优化手段
替代方案：改用更现代的协议
若目标是降低 CGI 类请求的 fork 开销，建议迁移至：
- FastCGI + php-fpm / gunicorn / uWSGI：自带进程/线程池，支持连接复用与请求复用
-
HTTP 反向代理模式：将 CGI 功能封装成 HTTP 服务（如用 Python Flask 提供 /compile 接口），再用
proxy_pass调用，即可启用keepalive连接池 - 嵌入式执行器（如 OpenResty + Lua）：对简单脚本逻辑直接在 Nginx 层处理，彻底规避进程创建
