How to load testing locally hosted website or API
Why you need a public URL
Our load generators are hosted in the cloud, so your service, website, API or web service needs to be publicly available in order for our load testing agents to reach to your endpoint.
If you host your service, website, API or web service locally there are a few tools that you can use to expose a locally hosted website to the Internet.
Load generators run in cloud data centers, not on your machine, so they can never resolve http://localhost, a private IP range such as 192.168.x.x or 10.x.x.x, or a port that is only bound on your laptop. See https://loadfocus.com/docs/knowledge-base/using-valid-url-endpoints for the full list of what counts as a reachable target.
Tools that expose a local server to the Internet
Here are services that let you expose certain ports on your local machine so that the outside world can connect to them:
Services above allow you to easily share a web service on your local development machine without messing with DNS and firewall settings.
How tunnel tools work
Both tools follow the same basic pattern: a small client on your machine opens an outbound connection to the tunnel provider's relay server (outbound connections are rarely blocked by firewalls or NAT). The provider assigns a public URL and forwards inbound requests on that URL back down the tunnel to the port you exposed locally. No DNS changes, port forwarding, or firewall rules needed, which is why this is the fastest way to get a local app reachable for a quick test.
Things to consider before load testing through a tunnel
- Free-tier limits: most free tunnel plans cap bandwidth or the number of concurrent connections. Under real load, hundreds or thousands of virtual users, you can hit the tunnel's own ceiling before you hit your application's, and the numbers you get back describe the tunnel, not your app.
- Extra latency: every request now makes an additional hop through the tunnel provider's relay server. Response times will be higher than what the same code would show once deployed behind your normal infrastructure, so treat absolute numbers with caution.
- Stability during the test: if the tunnel process crashes, or the machine running it sleeps or loses network, every in-flight request fails at once. For anything longer than a quick smoke test, run the tunnel from an always-on machine rather than a laptop.
- Exposure: a tunnel makes your local environment reachable by anyone who has, or guesses, the generated URL, for as long as the tunnel stays open. Keep the exposure window short, use the provider's authentication options if available, and avoid tunneling an environment that contains real production data.
When a tunnel is the right tool
A tunnel is a good fit for a quick sanity check: confirming an endpoint handles a modest number of concurrent requests before it ships, or reproducing an issue found in a cloud test against a local build. For serious capacity planning or benchmark numbers, deploy to a staging environment that mirrors production infrastructure as closely as possible. The tunnel hop adds noise that makes absolute response times unreliable, though relative comparisons, testing the same tunneled setup before and after a code change, can still tell you something useful.