How to Use SparkProxy With Epic Traffic Bot

Epic Traffic Bot Pro is a Windows application that drives many concurrent Chrome sessions through proxies, with device emulation, geolocation spoofing, a scripting engine and a scheduler. Pointed at infrastructure you control, it is a browser-level load generator with a geographic dimension most load tools don't have. Four jobs it does well:

Everything below assumes the target is yours, or that you hold written authorisation to test it. The terms section sets out where that line sits, because the software can be pointed at things the line does not cover.

One gateway line, not a proxy list

SparkProxy exposes a single host, gateway.sparkproxy.io. Rotation happens on our side, so the Proxy tab takes one line instead of a thousand:

gateway.sparkproxy.io:11000

Three things to do on that screen:

1. Paste the line above into the proxy text box. The count below the box should read 1.
2. Leave Download Proxies and Auto Update Proxies alone. Both append free public proxies to the same list, and a load test running half on your paid gateway and half on scraped public IPs produces numbers you cannot interpret.
3. Click Use Proxies.

One gotcha the documentation flags and everyone hits anyway: a device created with its own PROXY value under Configure Devices ignores the global list entirely. If your tasks are clearly not going through the gateway, check the per-device proxy field before you check anything else.

Authenticate by IP whitelist, not credentials

Every SparkProxy plan supports both IP whitelisting and username:password authentication. For this tool, whitelisting is the one to use, and the reason is architectural rather than a preference.

Epic Traffic Bot drives Chrome through chromedriver. Chrome's --proxy-server switch has never accepted inline credentials, so a proxy that answers with 407 Proxy Authentication Required raises a native auth dialog. A task running in Invisible Mode has nobody to answer it, and the run dies with a connection error that looks like a proxy fault. Epic's own troubleshooting page maps those failures to a generic "use better proxies" note, which sends people down the wrong path for hours. Whitelisting removes the whole class of failure.

Add the public IP of the machine running the bot in the SparkProxy dashboard. If you run on a VPS, that means the VPS address, not your laptop's. Confirm which address you are actually presenting:

curl.exe -s https://ipinfo.io/ip

Then confirm the egress works before you open the bot at all:

curl.exe -s -x http://gateway.sparkproxy.io:11000 https://ipinfo.io/json

A different country and ASN in the response means the whitelist entry is live. If you do need credentials, because you rotate the bot between machines, the four-field form goes in the proxy box:

gateway.sparkproxy.io:11000:USERNAME:PASSWORD

Test that pair outside the application first, so a failure inside the bot is unambiguous:

curl.exe -s -x http://USERNAME:PASSWORD@gateway.sparkproxy.io:11000 https://ipinfo.io/json

The mechanics of both methods, including why a stale whitelist entry is a liability, are covered in how proxy authentication works and what IP whitelisting is for proxies.

All three live on the same host. The port picks the behaviour.

SOCKS5 on 13000 carries TCP, which covers everything a Chrome-driven task does. There is no UDP ASSOCIATE, so don't design around it.

Sticky sessions are selected with a token in the username:

# Same token twice: the exit IP must be identical both times.
curl.exe -s -x http://USERNAME-session-lt01:PASSWORD@gateway.sparkproxy.io:11002 https://ipinfo.io/json
curl.exe -s -x http://USERNAME-session-lt01:PASSWORD@gateway.sparkproxy.io:11002 https://ipinfo.io/json

# Rotating pool on 11000: a different exit each call.
curl.exe -s -x http://USERNAME:PASSWORD@gateway.sparkproxy.io:11000 https://ipinfo.io/json

# SOCKS5 on 13000. Use socks5h so DNS resolves at the exit, not on your box.
curl.exe -s -x socks5h://USERNAME:PASSWORD@gateway.sparkproxy.io:13000 https://ipinfo.io/json

Picking between them is simple. If your script is a single page view, use 11000. If your script logs in, adds an item and reaches checkout, use 11002, otherwise step three arrives from a different country than step one and you end up measuring your own session handling instead of your capacity. What a sticky session proxy is covers how long a token holds and when to cycle it.

This is the section that decides whether your run works.

Epic Traffic Bot's Tasks field sets how many parallel browser tasks run at once. Your SparkProxy plan's thread allowance is how many simultaneous connections your account may hold open. One browser task holds many threads. They are not the same unit, and treating them as one is the single most common cause of a failed first run.

A page load fans out. Chromium's default socket pool limits, defined in client_socket_pool_manager.cc, allow 6 sockets per host group, 32 per proxy chain, and 256 per pool. Through a proxy, each of those sockets is a separate tunnel to gateway.sparkproxy.io. So one task can hold up to 32 threads at peak on a heavy page, and typically settles somewhere between 4 and 10.

Don't take that table on faith for your own site. Measure it. Run a pilot with Tasks set to 3 and count live connections to the gateway from Windows while it runs:

$gw = (Resolve-DnsName gateway.sparkproxy.io -Type A).IPAddress

1..60 | ForEach-Object {
  $n = @(Get-NetTCPConnection -State Established |
         Where-Object { $gw -contains $_.RemoteAddress }).Count
  "{0}  threads={1}" -f (Get-Date -Format HH:mm:ss), $n
  Start-Sleep -Seconds 5
}

Take the peak, divide by 3, and you have a threads-per-task figure for your specific page. That number, not a rule of thumb, is what you size the plan against. The connection accounting behind it is explained in understanding concurrent connections in proxies.

SparkProxy plans include unlimited data transfer. What changes between tiers is the maximum bandwidth speed and the concurrent thread allowance:

The formula is Tasks = plan threads / threads-per-task, then take 20% off for retries and slow-closing sockets. On Starter with images on, that lands you around 6 or 7 tasks. It feels low until you remember each task is a full Chrome instance pulling a real page.

Two things arrive before the top of that table does. The first is your machine: Epic's documentation puts an i7 or i9 with 16 to 32 GB of RAM at roughly 70 to 120 parallel tasks in Invisible Mode, and 20 to 40 in Visible Mode. So a single box saturates somewhere around Boost. Past that you scale by adding VPS instances and whitelisting each one, not by buying a bigger plan for the same machine. The second is bandwidth, which is the next section.

What happens if you ignore this? Two things, in order. Requests made while your allowance is fully in use may be queued or refused until a slot frees up, which is what turns into ERR_PROXY_CONNECTION_FAILED and timeouts across most of your tasks. And if the overshoot is sustained, the Fair Usage Policy applies:

"Sustained attempts to exceed your allocated thread count, or any attempt to circumvent that allocation ... constitute a breach of this Fair Usage Policy. Where we identify such use, we may restrict the bandwidth speed available to your account."

The restriction is proportionate and is lifted once usage comes back inside the plan, but the run you were in the middle of is already ruined. Size it correctly the first time. The 24-hour free trial exists precisely so you can measure threads-per-task against your own pages before you pick a tier.

Data volume is unlimited, speed is not, and for a load test speed is usually the binding constraint. Convert your plan into pages per second by dividing by your real page weight:

Get your real page weight from Chrome DevTools, Network tab, the "transferred" figure at the bottom after a hard reload. A 5 MB page on Starter gives you 0.25 page loads per second no matter what you set Tasks to.

Two consequences worth acting on. Turning Disable Images on cuts most pages to a quarter or a half of their weight and buys real concurrency, but it also means you are no longer testing image delivery or CDN behaviour, so decide which of the two you care about for that run. And if you are measuring pure origin capacity with no geographic requirement, run the generator direct with proxies off: the proxy adds a hop and a speed cap and tells you nothing extra. Proxies earn their place when the request genuinely has to originate somewhere else.

Country selection is a token in the username, using ISO 3166-1 alpha-2 codes across 80+ countries:

# Exit from Germany, rotating.
curl.exe -s -x http://USERNAME-country-de:PASSWORD@gateway.sparkproxy.io:11000 https://ipinfo.io/json

# Exit from Germany, pinned for a whole journey.
curl.exe -s -x http://USERNAME-country-de-session-lt01:PASSWORD@gateway.sparkproxy.io:11002 https://ipinfo.io/json

Setting the IP is half the job. The browser has to agree, or your geo QA passes for the wrong reason. Under Configure Devices > Advanced Settings:

• Browser Language: de or de-DE. The bot needs the language code, not the country name.
• Browser Timezone: set it to match, or pick the automatic match to browser language.
• Geolocation Settings: match the browser language, or supply Berlin coordinates directly.
• Proxy Settings at the device level: leave it off so devices use the global gateway line, unless you are deliberately running one device per country.

Why bother? A German exit IP arriving with Accept-Language: en-US and an America/New_York timezone is not a German visit. Your CDN will serve the German edge while your application serves the English bundle, and the render check reports success while testing a combination no real user has. This is about test fidelity, not disguise. What geo-targeting means in proxies covers how the routing decision is actually made.

For checking your own ads and landing pages by market, run this shape on port 11002 with Visible Mode on and Tasks at 2 or 3. You want to watch the page, not generate volume: currency formatting, the right offer, geo redirects that fire once instead of looping, and consent banners that appear where they legally must.

Four fields on the Main screen decide whether your numbers mean anything.

Duration in milliseconds is a random pre-task wait between your min and max. Wait after task finished is the pause after a successful task before the next one starts. Together they set arrival rate. A profile with zero think time models a scenario that has never happened on your site. Pull the real interval from analytics, average session duration divided by pages per session, and set the min and max around it.

Timeout defaults to 60 seconds. Under a genuine overload it is your own site that is slow, so keep this long enough to record the slow response instead of truncating it into a failure you can't diagnose.

Max Visits multiplied by your URL count is the total campaign size. Visit Mode decides distribution: One by One drives each URL to its target before moving on, Shuffle spreads a mixed load across the set. Mixed load is closer to reality; One by One is better for isolating a single endpoint.

Device mix should mirror your analytics. If 62% of your real traffic is mobile, generate Android and iPhone devices in roughly that ratio so the test exercises the same responsive breakpoints and mobile bundles your users hit.

Tag the test traffic

Append a marker parameter to every URL in the campaign:

https://shop.sparkproxy.io/checkout?lt=cap-2026-09

Then use it three ways. Allowlist the parameter in your own WAF or bot manager so your protection stack doesn't block your own capacity test. Filter it out in GA4 so the run doesn't distort your reporting. And grep it in access logs to separate synthetic from organic when you analyse the results. This is the correct way to keep your own detection from interfering with your own test, and it leaves an audit trail showing exactly what the traffic was.

Ramp rather than jumping. Start at 10 tasks, hold for five minutes, watch error rate and p95 latency, then step up. Epic's docs recommend the same gradual increase for machine stability, and it happens to be how you find the knee in a capacity curve.

Monitoring is the opposite shape from load testing: small and frequent instead of large and brief.

• Tasks: 2 to 5
• URLs: one per region you care about, Visit Mode One by One
• Port: 11000, so each check takes a different network path
• Wait after task finished: 300000 for a five-minute cadence
• Timeout: 30 to 60 seconds

The alerting rule matters more than the configuration. A single failure through a rotating pool is a failed path, not a failed site. Require three consecutive failures across three distinct exits before anyone gets paged. If you want the same path every run so failures are comparable over time, switch to port 11002 with a fixed session token per region and accept that you are now monitoring one route rather than many.

The cheapest way to tell "my site is down" apart from "this exit is down" is a control URL. Add a second URL you know is always up, and only alert when the target fails while the control succeeds on the same run. That one addition removes most false pages.

A traffic tool can be pointed at more things than the terms permit, so it is worth knowing exactly where the line is before you build a campaign rather than after.

SparkProxy's Acceptable Use Policy lists activities that are strictly prohibited. Two of them settle most of the questions people have about a tool like this:

"Facilitating fraud, identity theft, or any other illegal financial activity"

"Using the proxies for any activity that violates the rights of third parties"

The consequence is stated just as plainly:

"We reserve the right to immediately suspend or terminate any account found to be in violation of this Acceptable Use Policy without prior notice and without refund."

Here is where that lands for traffic generation. Generating artificial ad clicks, inflating impressions, video views or engagement counts, and manufacturing sessions to move rankings or analytics numbers all sit on the prohibited side of both lines: they facilitate fraud against whoever is paying for or metering that inventory, and they violate that third party's rights. In the United States, artificial ad clicks at scale are prosecuted as wire fraud, so account termination is not the only exposure. Reselling proxy access, or delivering traffic to someone else's property as a service, is separately prohibited under the resale clause.

The uses in this guide sit on the allowed side for one reason: the property under test is yours. Your origin, your landing pages, your ads, your uptime. If you are contracted to test someone else's, get the authorisation in writing before the first run, the same way you would for a penetration test.

Two habits keep you comfortably inside the line. Whitelist only IPs you control, because a shared or stale whitelist entry makes you responsible for traffic you did not send. And tag and log every campaign as described above, so you can show what the traffic was if anyone ever asks. The full text is on the SparkProxy Terms of Use page.

Chrome's network errors surface in the Epic Traffic Bot console, and most of them have a specific cause rather than the generic "bad proxies" answer.

The isolation rule that saves the most time: reproduce the failure with curl.exe outside the bot. If curl succeeds and the bot fails, it is a bot configuration problem. If curl fails too, it is credentials, whitelist, or your thread allowance. Proxy error codes explained maps the status codes a proxy returns to what actually went wrong upstream.

One more Windows-specific trap: a system-level VPN or proxy client running alongside the bot interferes with chromedriver's local port binding, which produces errors that look like proxy failures but are not. Turn those off for the duration of a run.