Skip to content

Debugging Connection Errors

A connection error is different from an HTTP error. There's no status code because the request never reached the application: the TCP connection was refused, the connection timed out, the hostname didn't resolve, or there's no route to the host. Start with the obvious: is the server actually running?

Symptom

Common error messages in the Errors View:

  • "Connection refused"
  • "Connection timed out"
  • "No route to host"
  • "Network is unreachable"
  • "Unknown host" or DNS resolution errors

Diagnostic Steps

Step 1: Confirm the server is reachable

  1. Open a browser and navigate to the same hostname Load Tester is targeting
  2. If the browser reaches it: Load Tester has a network configuration problem (proxy, firewall, custom DNS). Go to Fix 2.
  3. If the browser can't reach it either: The server is down, the hostname is wrong, or there's a network outage. Go to Fix 1.

Step 2: Verify the test case is using the right hostname

  1. Open Test Case Editor
  2. Right-click the first transaction → Edit
  3. Check the hostname. If it's wrong (recorded against dev.example.com, replay environment is staging.example.com), the test case is pointing at the wrong server.

Solutions

Fix 1: Verify the Server Is Running

Contact operations or the application team and confirm the server is up. Check the URL the test case uses is the right one for the current environment. Start the server if it's down. Re-run the replay once it's back.

Fix 2: Firewall or Proxy

If the browser can reach the server but Load Tester can't, the most likely cause is that your network routes browser traffic through a proxy or firewall rule that Load Tester isn't configured for. v7.0 captures recordings through the Chrome extension, so corporate proxies are handled at the Chrome / OS level for recording. For replay traffic generated directly by Load Tester, the JRE's network settings determine routing.

  • Behind a corporate proxy: You may need to add JVM proxy settings (-Dhttp.proxyHost, -Dhttps.proxyHost) or work with IT to whitelist Load Tester's outbound traffic.
  • Behind a firewall: Identify Load Tester's IP and ask network operations to whitelist it for the target server.

Fix 3: Wrong Environment

If the hostname is genuinely wrong for the environment you're testing, edit the test case to point at the correct one. For widespread hostname changes across many transactions, see Modifying Test Case Content.

Still Stuck?

Ask the AI

My replay returns "Connection refused" on every transaction. The server
is running and I can reach it in a browser from this same machine.
What's blocking Load Tester?