ThinkPHP6万并发502本质是Nginx与PHP-FPM协同链路断裂，主因PATH_INFO解析失败、FastCGI连接池枯竭、日志/缓存同步阻塞、超时与缓冲区配置失配；须用try_files替代正则、动态调优pm.max_children、异步化日志缓存、统一加宽fastcgi超时及缓冲区。
ThinkPHP6 在承受一万并发请求时出现 502 Bad Gateway，本质不是框架扛不住，而是 Nginx 与 PHP-FPM 协同链路在高负载下断裂。核心问题集中在 PATH_INFO 解析失败、FastCGI 连接池枯竭、日志/缓存同步阻塞、缓冲区与超时配置失配这四类硬性瓶颈。修复需逐层加固，不能只调单点参数。
PATH_INFO 解析必须绕过正则陷阱
一万并发下，Nginx 原生正则提取 $1 极易因匹配抖动返回空值，导致 PHP-FPM 收到非法 SCRIPT_FILENAME 而静默退出，直接触发 502。宝塔或军哥 LNMP 的默认规则普遍存在该缺陷。
- 弃用 location ~ \.php(.*)?$ + fastcgi_param PATH_INFO $1 的写法，改用更稳定的 try_files 模式
- 在站点配置中使用标准规则：location / { try_files $uri $uri/ /index.php?$query_string; }
- 确保 public/index.php 是唯一入口，ThinkPHP 内部通过 $_SERVER['QUERY_STRING'] 解析路由，彻底规避 Nginx 路径解析歧义
PHP-FPM 连接池与系统资源必须匹配万级并发
默认 pm.max_children=5 或 10，面对一万并发，连接排队甚至丢弃是必然结果。但盲目拉高数值会导致内存溢出或进程僵死，需协同调优。
- 按内存估算：每 PHP-FPM worker 约占 20–40MB，16GB 服务器建议 pm.max_children 设为 300–400
- 必须启用动态模式：pm = dynamic，并设 pm.start_servers=64、pm.min_spare_servers=64、pm.max_spare_servers=128
- 同步调整系统级限制：在 /etc/security/limits.conf 中设 www-data soft nproc 65535、hard nproc 65535，并确认 ulimit -n ≥ 65535
- 重启后用 netstat -anpo | grep "php-fpm" | wc -l 实时监控活跃连接数，应稳定在 80% max_children 以下
日志与缓存必须异步化，否则请求线程直接卡死
File 驱动日志同步写入、Redis 缓存无超时、Memcached 文本协议解析开销，在万级并发下会把每个请求拖成“长尾”，Nginx 因超时主动断连，报 502。
立即学习“PHP免费学习笔记（深入）”；
- 日志驱动切为 Swoole 异步队列：composer require topthink/think-swoole，启用 Log::channel('swoole')，Log::write() 变为消息投递
- Redis 缓存强制设超时：redis.timeout=2、redis.read_timeout=2，host 改为 localhost（绕过 IPv6 DNS 查找）
- 禁用 File 缓存：runtime/cache/ 在高并发下极易损坏，.env 中设 CACHE_DRIVER=redis，且 config/cache.php 中 redis.prefix 加项目标识防键冲突
Nginx 与 FastCGI 超时、缓冲区必须整体加宽
默认 fastcgi_read_timeout=60 秒，在慢 SQL 或外部 API 延迟时，PHP-FPM 尚未返回，Nginx 已判定上游失败，返回 502。
- 在 server 或 location 块中统一加大：fastcgi_connect_timeout 300;、fastcgi_send_timeout 300;、fastcgi_read_timeout 300;
- 增大响应头缓冲：fastcgi_buffer_size 32k;、fastcgi_buffers 8 32k;、fastcgi_busy_buffers_size 64k;
- PHP 层同步收紧：php.ini 中 max_execution_time=120，php-fpm.conf 中 request_terminate_timeout=150s，避免单请求无限占用 worker
