How to Test Sticky and Rotating Proxy Sessions with curl

A proxy test should answer separate questions: did authentication succeed, did the request exit through a proxy, did a rotating credential change the exit IP across independent requests, and did a sticky credential keep the same exit IP for its intended lifetime? One successful request does not prove all four.

This guide uses placeholders and a public IP-echo endpoint. Replace the endpoint with one your organization is permitted to query, and never paste production credentials into shell history, tickets, screenshots, or shared logs.

What the test can and cannot prove

A short curl sequence can verify observable request behavior. It cannot prove the size of a provider's proxy pool, guarantee a future IP, demonstrate that a target website will accept automation, or replace a workload-specific test.

HTTP proxy authentication is distinct from origin-server authentication. An HTTP proxy that requires credentials can respond with 407 Proxy Authentication Required; RFC 9110 defines the related proxy authentication fields, while curl supports proxy credentials with --proxy-user.

Prepare credentials without putting the password in the command

export PROXY_HOST='proxy.example.com:PORT'
export PROXY_USER='customer-ACCOUNT'
read -s PROXY_PASS
export PROXY_PASS

Use test credentials with limited scope. This keeps the password out of shell history, but it is not a secret-manager substitute: curl documents that credentials supplied through command-line arguments can still be visible briefly in process listings on some systems. Avoid this pattern on shared hosts; prefer your approved secret-injection or protected config-file workflow there.[1]↗

Clear the variables after the test:

unset PROXY_HOST PROXY_USER PROXY_PASS STICKY_USER

Step 1: verify authentication and basic forwarding

curl --fail-with-body --silent --show-error \
  --proxy "http://${PROXY_HOST}" \
  --proxy-user "${PROXY_USER}:${PROXY_PASS}" \
  --connect-timeout 10 \
  --max-time 30 \
  https://api.ipify.org
printf '\n'

Interpretation:

• 407 means the proxy is requesting authentication. RFC 9110 requires a proxy-generated 407 response to carry at least one Proxy-Authenticate challenge. Stop target-side retries and fix the proxy credential/authentication path first.[2]↗
• A connection timeout points to DNS, firewall, port, routing, or proxy availability before it points to session behavior.
• A target-side 403 is not the same as proxy authentication failure; classify the response before changing proxy credentials.

Step 2: test rotation with independent requests

Run several new curl processes so connection reuse inside one process does not distort the result:

for i in 1 2 3 4 5; do
  printf '%s ' "$i"
  curl --fail-with-body --silent --show-error \
    --proxy "http://${PROXY_HOST}" \
    --proxy-user "${PROXY_USER}:${PROXY_PASS}" \
    --connect-timeout 10 \
    --max-time 30 \
    https://api.ipify.org
  printf '\n'
  sleep 2
done

A rotating service may select a different exit for each eligible request, but repeated IPs are not automatically a defect. The available geo filter, healthy route set, account policy, connection reuse, and provider selection algorithm can all affect the observed sequence. Record the timestamp, credential mode, requested geography, and each response rather than reporting only “rotation failed.”

Step 3: test a sticky session identifier

Construct the sticky username using the syntax documented for your account. The example below is intentionally generic:

export STICKY_USER='customer-ACCOUNT-session-TEST_SESSION'

for i in 1 2 3; do
  curl --fail-with-body --silent --show-error \
    --proxy "http://${PROXY_HOST}" \
    --proxy-user "${STICKY_USER}:${PROXY_PASS}" \
    --connect-timeout 10 \
    --max-time 30 \
    https://api.ipify.org
  printf '\n'
  sleep 5
done

The same documented session identifier should normally select the same eligible route while that session remains valid. A route can still change after expiry, route loss, policy enforcement, or provider-side health removal. Do not describe stickiness as a permanent IP guarantee.

Step 4: test expiry without guessing

Use the session lifetime documented by the product or account configuration. Record the first exit IP, wait until after the documented expiry boundary, and run a new request with the same session identifier. The useful result is whether behavior matches the documented contract—not whether the IP happened to change once.

Do not shorten the wait and infer expiry from a repeated or changed IP. A repeated IP can be selected again after expiry, and a changed IP before expiry can indicate route loss rather than a timer defect.

Capture a reviewable result

UTC timestamp:
Proxy endpoint:
Credential mode: rotating | sticky
Requested country/region/city:
Session identifier: redacted hash or test label only
Expected lifetime:
Observed status codes:
Observed exit IP sequence:
Connection errors:
Target endpoint:

Redact usernames, passwords, account IDs, full session IDs, and authorization headers before sharing the record.

Common false conclusions

“The IP repeated, so rotation is broken”

A small sample can repeat. Increase the sample only within your authorized rate limits and separate the observations by geography and session mode.

“The IP changed, so sticky sessions are broken”

Confirm that the username syntax and session identifier were identical, the test was inside the documented lifetime, and no route-loss error occurred.

“The origin returned 403, so the proxy password is wrong”

Proxy authentication failures and origin policy responses are different layers. Inspect the HTTP status and response path before changing credentials.

“curl worked, so the browser integration is production-ready”

curl verifies a narrow network path. Browser automation adds DNS behavior, TLS fingerprints, cookies, navigation concurrency, retries, and target-specific policy. Test that workload separately.

Next step

After the curl baseline is stable, apply the same rotation or session parameters to one controlled application request and compare its logs with this baseline. Review the BytesFlows proxy setup guide before scaling, and use the product dashboard to create or inspect test credentials. Keep the rollout limited until authentication errors, route loss, and session expiry are handled explicitly.

References and practical limits

• curl manual↗: --proxy, --proxy-user, timeouts, --fail-with-body, and credential exposure considerations.
• curl HTTP scripting guide↗: proxy authentication and interactive password prompting when the password is omitted.
• RFC 9110↗: HTTP proxy authentication and 407 Proxy Authentication Required semantics.

Use the commands as reproducible test patterns rather than benchmark results. Measure pool behavior, latency, target acceptance, and sticky-session behavior in your own workload, and use the current Dashboard values for BytesFlows hostnames, ports, GEO options, username syntax, and session duration.