pm.max_children是PHP-FPM控制单站最大并发PHP进程数的核心参数，需按站点独立配置并重启对应PHP服务；设过低致502增多，过高易耗尽内存；须配合Nginx限流与程序优化才能有效防攻击和瓶颈。
PHP-FPM 的 pm.max_children 是关键控制项
宝塔面板本身不直接提供“网站级PHP并发数限制”开关，真正起作用的是 PHP-FPM 的进程管理配置。每个网站在宝塔中对应一个独立的 php-fpm.conf（或通过站点配置继承的池配置），核心参数是 pm.max_children——它决定了该站点最多能同时处理多少个 PHP 请求进程。
超过这个数的请求会被排队（受 pm.queue_timeout 和 pm.max_requests 影响），或直接返回 502（如果队列溢出或超时）。这不是“限速”，而是硬性进程数封顶，对防 CPU/内存耗尽最有效。
- 默认值通常为
10或20（取决于 PHP 版本和宝塔模板），对小流量站够用，但高并发场景下极易被刷满 - 设得太低（如
5）会导致用户明显卡顿、502 错误增多；设得太高（如100）可能单站吃光服务器内存（每个 PHP 进程常驻 20–50MB） - 必须结合服务器总内存和实际 PHP 内存占用估算：
max_children ≤ 总可用内存 × 0.8 ÷ 单进程平均内存
在宝塔中修改单个网站的 PHP 并发限制
不能只改全局 PHP-FPM 配置，否则所有网站共用一套限制。要为每个高风险网站单独配池：
- 进入「网站」→ 点击目标站点 → 「设置」→ 「PHP版本」→ 右上角「设置」→ 切换到「配置文件」标签页
- 找到类似
[www]或[www-group1]的段落（这就是该站点对应的 FPM 池名） - 确认已启用
pm = static或pm = dynamic（推荐static，行为更可控），然后设置：pm.max_children = 12<br>pm.start_servers = 6<br>pm.min_spare_servers = 4<br>pm.max_spare_servers = 8
- 保存后，**必须重启对应 PHP 版本的服务**（不是重启 Nginx/Apache），否则配置不生效
为什么改了 pm.max_children 还是扛不住？常见漏点
并发限制失效往往不是参数没改，而是其他环节绕过了控制：
立即学习“PHP免费学习笔记（深入）”；
-
pm = ondemand模式下，pm.max_children仍生效，但启动延迟高，突发请求容易堆积，不建议用于生产站 - 静态资源（.js/.css/.jpg）被错误地交由 PHP 处理（比如 Nginx 配置里
location ~ \.php$范围过大），导致本该由 Nginx 直接返回的文件也占 PHP 进程——检查站点「配置文件」里的location规则是否精准 - WordPress 等程序存在大量无缓存的 XML-RPC、wp-cron.php、REST API 请求，它们都走 PHP，且可能被扫描器高频调用——需配合防火墙规则或插件禁用非必要端点
- 宝塔「网站监控」里看到的「PHP 进程数」是实时值，但
pm.max_children是硬上限，务必用sudo php-fpm74 -t（替换为你实际的 PHP 版本号）校验配置语法，避免因格式错误导致降级使用默认池
配合 Nginx 请求速率限制更稳妥
仅靠 PHP-FPM 限并发，对恶意高频请求（如 CC 攻击）响应滞后。应在 Nginx 层加一层前置限流：
- 在站点「配置文件」的
server块开头加入：limit_req_zone $binary_remote_addr zone=perip:10m rate=4r/s;<br>limit_req zone=perip burst=8 nodelay;
- 这表示：单 IP 每秒最多 4 个请求，允许最多 8 个请求进缓冲队列，超了直接 503
- 注意不要加在
location ~ \.php$内部，否则只限 PHP 请求；加在server级可覆盖所有入口，包括恶意爬虫打的静态路径 - 若站点有合法高并发来源（如内部系统回调），可通过
geo模块白名单绕过
真正的瓶颈常在 PHP 进程内存泄漏、慢查询或未关闭的数据库连接，pm.max_children 只是兜底手段。调参后务必用 htop 和 php-fpm74 -pm status 观察实际进程数与空闲率，而不是只看宝塔后台数字。
