这种并发量上去后部分请求被拒绝的情况我碰过好多次，核心原因基本都是连接数限制或者资源耗尽导致的，给你梳理几个排查和解决的关键点：

1. 先查服务器端的连接与资源限制 #

• 操作系统文件描述符限制：Linux系统默认的文件打开数（每个HTTP连接对应一个文件描述符）通常不高，150并发很可能超过阈值。你可以在服务器上执行ulimit -n查看当前限制，临时调高可以用ulimit -n 10240，要永久生效的话得修改/etc/security/limits.conf文件，添加类似下面的配置：

  * soft nofile 10240
  * hard nofile 10240
  

• Web服务器配置上限：如果用Nginx，检查worker_connections参数（在nginx.conf里），这个值决定了每个worker进程能处理的最大连接数；如果是Apache，看MaxRequestWorkers（旧版本是MaxClients），确保这些参数设置得足够支撑150+的并发连接。
• 服务器资源负载：压测时用top、vmstat监控CPU、内存使用率，如果150并发时CPU跑满或者内存耗尽，服务器根本没法处理新连接，自然会拒绝请求。

2. 优化JMeter客户端的连接配置 #

• 启用HTTP长连接：在JMeter的「HTTP请求默认值」里勾选「Use Keep-Alive」，这样可以复用TCP连接，减少频繁创建/销毁连接的开销，也能避免客户端侧的连接池耗尽。
• 调整JMeter连接池参数：打开jmeter.properties配置文件，找到以下两个参数并调大：

  httpclient.max_total=200  # 全局最大连接数
  httpclient.max_per_route=200  # 单域名最大连接数
  

  确保这两个值大于你的并发数（150），让JMeter能建立足够的连接来支撑压测。
• 客户端系统限制：JMeter运行的机器也有文件打开数限制，同样用ulimit命令调高，避免客户端这边先扛不住。

3. 排查中间网络设备的限制 #

• 检查服务器前面的防火墙、负载均衡器或者CDN，这些设备通常会有并发连接的阈值设置，如果超过就会直接拒绝请求。比如云服务商的安全组、WAF规则，都可能有这类限制，需要确认并调整。

4. 调整压测策略，模拟真实场景 #

• 不要一次性启动150个线程，改用阶梯式加压：比如先启动50个线程稳定运行1分钟，再加到100，最后到150，这样可以观察服务器的负载变化，确认是不是瞬间的连接峰值触发了拒绝机制。
• 添加监控指标：除了JMeter的请求结果，还要监控服务器的CPU、内存、磁盘IO以及Web服务器的连接状态（比如Nginx的nginx -s status），这样能更精准定位问题。

内容的提问来源于stack exchange，提问作者Srinivaso