phpEnv本身不控制Nginx的keepalive行为，其默认Nginx配置未启用upstream keepalive，所有后端请求均为短连接；必须显式配置upstream块、keepalive指令及proxy_http_version 1.1等参数，并注意Windows环境下的TCP探活限制与安全软件干扰。
phpEnv 本身不控制 Nginx 的 keepalive 行为，它只是 Windows 下的集成环境套件；真正起作用的是你手动修改的 nginx.conf 和 upstream 配置。默认 phpEnv 安装的 Nginx 完全不启用 upstream keepalive，所有后端请求都是短连接——这是性能瓶颈的常见根源。
phpEnv 中 Nginx 与 PHP-FPM 的长连接必须显式配置 upstream
phpEnv 默认把 PHP-FPM 当作普通 fastcgi 后端处理，走的是 fastcgi_pass，而非 proxy_pass + upstream。但 keepalive 只在 upstream 块中通过 keepalive 指令生效，fastcgi_pass 不支持该机制。
- 必须把 PHP-FPM 改为 HTTP 协议暴露（例如用 php-fpm 的
www.sock配合 nginx 的http代理，或改用127.0.0.1:9000并启用 HTTP 模式） - 新建
upstream php_backend块，写入server 127.0.0.1:9000;和keepalive 32; - location 中改用
proxy_pass http://php_backend;，并配套加上proxy_http_version 1.1;和proxy_set_header Connection ''; - PHP-FPM 自身需开启
pm.max_children与连接池匹配，否则空闲 keepalive 连接会因后端拒绝而被 Nginx 主动断开
Windows 下 phpEnv 的 keepalive_timeout 容易被忽略
Windows 系统对 TCP keepalive 探测的支持不如 Linux 成熟，默认内核参数响应慢、超时长。Nginx 的 keepalive_timeout 若设为 75s，在 phpEnv 场景下极易积累大量 TIME_WAIT 或卡住的半死连接。
- 建议将
keepalive_timeout设为30s（全局或 server 级），避免客户端空闲太久还占着句柄 - 若后端是本地 PHP-FPM，可同步调低
fastcgi_read_timeout和proxy_read_timeout至60s，防止超时错位引发 504 - 不要依赖
keepalive_requests过高（如 10000），phpEnv 的单 worker 进程并发能力有限，设为500已足够，过高反而导致连接复用率下降
proxy_socket_keepalive 是防火墙/杀毒软件干扰下的救命配置
Windows 环境下，安全软件（如 360、腾讯电脑管家）或企业防火墙常静默丢弃空闲 >300s 的 TCP 连接，Nginx 却仍把它当有效连接复用，结果发请求时直接报 connection reset by peer 或 502。
立即学习“PHP免费学习笔记（深入）”；
- 必须在 location 或 upstream 对应的 proxy 区域启用
proxy_socket_keepalive on 240s 10s 3; - 其中
240s是关键：要小于本地网络实际空闲切断阈值（多数 Win 安全软件为 300–420s），提前探测失效连接 - 该指令仅在 Nginx ≥ 1.15.3 且编译时启用了 TCP_KEEPIDLE/TCP_KEEPINTVL 支持时才生效；phpEnv 自带版本若低于此，需升级 Nginx 二进制
- 搭配
tcp_tw_reuse = 1（需管理员权限改 Windows 注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters）可进一步缓解端口耗尽
真正难调的不是加几行配置，而是确认 phpEnv 里 Nginx 和 PHP-FPM 是否真的跑在同一个协议栈层级、是否被中间层（杀软、Windows Filter Platform）劫持了 socket 生命周期——这些不会报错，只会让 keepalive 表面生效、实则失效。
