How do you troubleshoot a connection reset spike during scaled-up load?

First determine whether the errors are concentrated on the load-generator side or genuinely coming from the system under test, by checking whether the errors correlate with the load generator's own resource exhaustion (CPU, available file descriptors, ephemeral port exhaustion) rather than assuming the target application itself is failing.

Check operating system-level connection limits on the machine(s) generating load specifically - the number of available ephemeral ports and open file descriptor limits are common, easy-to-overlook ceilings that produce exactly this kind of socket error once thread counts get high enough, independent of whether the target system could actually handle the load.

Verify whether HTTP Keep-Alive is being used effectively across the test plan - if connections are being opened and closed rapidly rather than reused, that dramatically increases the rate of connection setup/teardown, which stresses both the load generator's and the target's connection-handling resources far more than a test reusing persistent connections the way a real browser typically would.

Check the target system's own connection pool, load balancer, or web server configuration for connection limits and timeout settings that might be legitimately rejecting connections once concurrent load crosses a certain threshold, since in that case the errors are a genuine finding about the system under test's actual capacity, not a JMeter or load-generator artifact to be engineered around.

If the errors only appear once a certain thread count or distributed-agent count is reached, and don't scale linearly with load beyond that point, that pattern itself is a useful diagnostic signal pointing toward a specific fixed limit, like a connection pool size or a firewall's concurrent-connection ceiling, being hit rather than a genuinely proportional performance degradation under load.