直接用 ss -tn state established | grep ':80|:443' | wc -l 查 Web 服务 TCP 并发连接数（含 Keep-Alive），或通过 php-fpm status 页面获取 active processes 值，该值最接近真实处理 Laravel 请求的进程数。
用 ss 或 netstat 实时看 Laravel 服务的并发连接数
Laravel 本身不内置连接数监控，真正承载 HTTP 连接的是 Web 服务器（如 Nginx）或 PHP-FPM 进程。直接看 php-fpm 的活跃 socket 连接最贴近“Laravel 并发请求”含义。
执行：
ss -tn state established | grep ':80\|:443' | wc -l或
netstat -an | grep ':80\|:443' | grep ESTABLISHED | wc -l——这统计的是当前与 Web 服务建立的 TCP 连接数，含 Keep-Alive 空闲连接，比实际“正在处理的请求”略高。
- 注意端口要和你实际监听的一致（比如
:8000开发环境、:443生产 HTTPS） -
ss比netstat更轻量，推荐优先用；旧系统若无ss再 fallback - 这个数值不是 Laravel 应用层的“请求数”，而是底层 TCP 连接数，对排查连接堆积、TIME_WAIT 泛滥更有效
在 Laravel 日志里埋点统计每秒活跃请求（应用层视角）
如果想监控“Laravel 正在执行中的请求”数量（比如排除空闲 Keep-Alive），得靠中间件 + 共享存储计数。不能依赖内存变量（多进程下不共享），必须用 redis 或 memcached。
- 在全局中间件中用
Redis::incr('laravel:active_requests')进入时加 1，finally块里减 1 - 用
Redis::get('laravel:active_requests')配合定时脚本（如每秒一次）输出到监控系统 - 务必设置 key 过期（如
Redis::expire('laravel:active_requests', 60)），避免因异常未减导致计数卡死 - 注意：FPM 子进程崩溃或 SIGTERM 中断可能导致减操作丢失，可加简单重置逻辑（比如连续 5 秒无更新就清零）
用 php-fpm 自带状态页查实时活跃子进程数
php-fpm 的 status 页面返回的 active processes 是最接近“当前正在处理 PHP 请求”的指标，比 TCP 连接数更精准反映 Laravel 实际负载。
- 需在
php-fpm.conf或 pool 配置中开启：pm.status_path = /status<br>ping.path = /ping
，并确保 Nginx 转发规则放行 - 访问
http://your.app/status?json，提取active processes字段值——这就是此刻真正跑着 Laravel 代码的进程数 - 该值受
pm.max_children限制，若长期接近上限，说明需要调优或扩容，而非单纯加机器 - 注意权限：Nginx 用户必须能访问 FPM 的 socket 或端口，否则返回 502 或空白
为什么不用 Apache mod_status 或 New Relic？
因为它们要么不适用（Laravel 多数跑在 Nginx + PHP-FPM 架构），要么引入额外复杂度。New Relic 等 APM 工具确实能出“每秒请求数（RPS）”，但 RPS ≠ 并发连接数——它统计的是完成速率，无法反映瞬时堆积。
-
mod_status只适用于 Apache，且默认不暴露连接详情；强行用会偏离主流部署栈 - APM 工具的“并发数”字段常是估算值（如基于采样或队列长度），不如
ss或php-fpm status直接读内核/进程状态可靠 - 真正容易被忽略的是：**并发连接数飙升往往源于前端未设超时、客户端重试风暴、或数据库锁住请求不返回**——监控只是第一步，得结合
slowlog和SHOW PROCESSLIST一起看
