Fix JMeter java.net.ConnectException: wrong host or port, firewall, TLS mismatch, timeouts, and injector network path. Symptom, causes, and ordered fixes.
java.net.ConnectException in JMeter
Section titled “java.net.ConnectException in JMeter”Symptom
Section titled “Symptom”In View Results Tree, the JTL, or dashboard error tables you see messages such as:
java.net.ConnectException: Connection refusedjava.net.ConnectException: Connection timed outNon HTTP response code: java.net.ConnectException- Sample marked failed with no normal HTTP status (not 200/404/500)
Often every thread fails immediately, or failures start when the system under test (SUT) or network path is wrong.
Common causes
Section titled “Common causes”| Cause | Why it happens |
|---|---|
| Wrong host, port, or protocol | HTTP Request Defaults / sampler still point at lab host or http vs https |
| Property not applied | Plan uses \${__P(host,)} but CLI omitted -Jhost=... (functions) |
| SUT not listening | Process down, wrong interface, or container port not published |
| Firewall / security group | Injector cannot reach SUT (common in CI and Kubernetes) |
| Connect timeout too short | Network latency or cold start exceeds HTTP Request connect timeout |
| Distributed workers differ | Workers lack DNS/route the controller has (distributed testing) |
Fix (ordered)
Section titled “Fix (ordered)”-
Copy the exact error from the first failed sample (code + message).
-
From the same machine that runs JMeter, test reachability (
curl,Test-NetConnection, browser). If curl fails, it is not a JMeter sampler bug. -
Open HTTP Request Defaults and the failing sampler: protocol, server name, port, path. Prefer one defaults element so hosts stay consistent (web test plan).
-
If the plan uses properties, print the effective command:
Terminal window jmeter -n -t plan.jmx -Jhost=staging.example.com -Jport=443 -l out.jtl -j jmeter.logConfirm
\${__P(host,localhost)}(or similar) is what you intend. -
Raise connect and response timeouts only after host/port are correct.
-
On CI/K8s: check NetworkPolicy, egress, private DNS, and that the job runs in a network that can see the SUT (CI/CD).
-
Distributed: reproduce on a worker shell; fix worker networking and data, not only the controller (remote testing).
Related tools and topics
Section titled “Related tools and topics”| Resource | Use when |
|---|---|
| Non HTTP response code | Broader non-HTTP failures |
| SSLHandshakeException | Connect works but TLS fails |
| GUI works, CLI fails | Host only wrong under CLI |
| Docker / Kubernetes | Container networking |
| Troubleshooting overview | Full triage tree |
Frequently asked questions
Section titled “Frequently asked questions”Is ConnectException an HTTP 500?
Section titled “Is ConnectException an HTTP 500?”No. It usually means JMeter never completed a normal HTTP exchange. The failure is at the TCP/connect layer (or is wrapped as a non-HTTP sample error).
Why does it work on my laptop but fail in CI?
Section titled “Why does it work on my laptop but fail in CI?”CI runners often cannot reach private staging hosts, or -Jhost / secrets differ. Test connectivity from the runner image first.
Should I increase threads to fix Connection refused?
Section titled “Should I increase threads to fix Connection refused?”No. Connection refused means nothing accepted the socket. Fix host, port, process, or firewall first.