Skip to content
Performance

Load testing through proxies: a safe k6 plan

Load testing is appropriate only for systems you own or where the owner has explicitly authorized it. A mobile route has finite capacity and is not an unlimited traffic generator.

2 min readReviewed and updated: August 6, 2026

Key points in one minute

  • Run smoke first, then baseline load, and only then heavier profiles.
  • A threshold turns an expectation into a testable criterion.
  • Every workload stage needs its own stop condition.
  • Proxy saturation must not be reported as the destination's limit.

Authorization and test window

Document targets, maximum RPS or VUs, duration, stop conditions, and owners. For production, agree on a window and rapid shutdown plan.

The scope should specify exact hosts, endpoints, test accounts, maximum RPS or VUs, total traffic volume, and exclusions for dependent third-party services. Assign an observer with an immediate stop mechanism and a contact channel to the system owner. If parameters or authorization are unclear, limit work to one smoke request or move the test to an isolated environment.

Workload profile

Smoke detects script errors, average load establishes a baseline, stress explores limits, spike models surges, and soak checks long-duration stability.

Advance only after validating each stage: one iteration, 1 VU, a small canary, target average load, and a separately approved stress phase. At every stage compare error rate, p95, and resources with the baseline. Stop ramping automatically when the predefined error ratio, proxy saturation, or degradation of adjacent services appears.

Thresholds

Set error-rate and response-time percentile thresholds for critical endpoints. Do not rely only on averages, which hide the slow tail.

Define separate thresholds for critical operations, such as error rate, p90, p95, p99, and a minimum count of successful business transactions. Account for cold start and the approved window, but never loosen thresholds after failure merely to obtain a green report. Publish the actual workload profile with results so runs remain reproducible and comparable.

Network bottlenecks

Observe the proxy, mobile route, and destination separately. Otherwise, saturation in one intermediary may be mistaken for an application limit.

Measure generator utilization, proxy queue, open connections, mobile route, and application resources at the same time. If the generator or route saturates first, classify the run as infrastructure-limited rather than an application limit. Never distribute traffic across many egress points to bypass destination controls; that falls outside safe testing.

Practical checklist

  1. 1Obtain a written scope.
  2. 2Start with one iteration.
  3. 3Configure an emergency stop.
  4. 4Record maximum RPS or VUs and total traffic volume.
  5. 5Publish the workload profile with the report.

Sources and documentation

This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.

  1. 1.Grafana k6: Thresholds
  2. 2.Grafana k6: Automated performance testing
  3. 3.OWASP Foundation: APTS Scope Enforcement

Continue reading

More articles on related topics

Honest verification

What an IP-check website actually proves

Read

Practical testing

Testing HTTP and SOCKS5 proxies with curl

Read

Diagnostics

Building an honest proxy checker: states, timeouts, and concurrency

Read