How to Escalate Blocked Proxies With Your Provider

Failures started suddenly, affect one target, and every exit you try fails the same way? That is almost always your client, not the network. Fix the fingerprint or the rate before you open anything.

Failures track specific exit addresses while other addresses from the same vendor succeed? That is a replacement request, not an outage. It is the cheapest ticket to file and the fastest to resolve, provided you name the addresses and show per-address failure counts.

Failures follow the vendor's subnets or ASNs rather than individual addresses, and a different network with your identical client succeeds? That is the real escalation, it goes to engineering rather than support, and you need aggregated evidence rather than a sample.

Everything was down for hours and you want money back? That is a separate claim with its own deadline and its own evidence requirement, and you almost certainly cannot make it unless you were already monitoring from outside the vendor.

Run these four checks before writing anything. They take under twenty minutes and they determine which ticket you are filing.

Check one: does the request fail without the proxy? Run the identical request from your own egress address. If it fails there too, the problem is in your client: TLS fingerprint, header order, cookie handling, or a body you are constructing wrong. Our explainer on TLS fingerprinting covers the most common cause. No vendor can fix this and the ticket will come back rejected.

Check two: do other exits from the same vendor succeed? Pull twenty addresses, run the same request through each, and count. If the split is clean, some addresses failing consistently while others succeed consistently, you have burned addresses. If everything fails at roughly the same rate, you have a network-level problem or a client problem.

Check three: does a different network succeed with your identical client? This is the control that makes the whole case. Same code, same headers, same target, different exit network. If that works, you have isolated the variable to the vendor's network, and you can say so with evidence instead of adjectives.

Check four: is the target having a bad day? Targets go down, deploy broken changes, and tighten rules without warning. Check whether unproxied requests from a second location also degrade at the same moment. Filing a vendor ticket for a target-side change is common and wastes everyone's time.

Write the four answers down before you continue. They form the opening paragraph of the ticket, and a support engineer who reads them will skip three rounds of questions. Our post on detecting when your scraper is blocked covers how to instrument this so the answers are already in your logs when an incident starts.

Most teams file one kind of ticket regardless of what happened. There are three, and knowing which one you are filing changes the evidence, the recipient and the expected outcome.

The distinction matters because the remedies are not interchangeable. A vendor cannot give you a service credit for burned addresses, because burned addresses are not downtime. A vendor cannot replace your way out of a subnet the target has flagged wholesale, because the next address comes from the same range. And engineering will not look at a network claim built on one failing request, because one request is not a pattern.

Deciding which claim you are making, and saying so in the first line, is the single biggest determinant of how fast you get an answer.

Attach these nine things. Support teams triage by how much work your ticket saves them, and this is the difference between a two-hour reply and a two-day one.

1. Timestamps in UTC, with the window start and end stated explicitly. Local time with no offset is the most common reason a vendor cannot find your traffic in their logs.
2. The full request as sent: method, URL, every header, and the body. Redact the credential, not the header name.
3. The full response as received: status line, all headers, and the first two kilobytes of the body. The body is where the challenge page identifies itself.
4. The exit address as the target saw it, not the one you intended to use. Read it back rather than assuming.
5. The gateway host, port and authentication mode you used. On SparkProxy that means naming gateway.sparkproxy.io and whether you connected on 11000, 11002 or 13000, and whether you authenticated by credentials or by whitelist.
6. Your request rate and concurrency at the time, per address and in total. Vendors ask this second, every time.
7. Success rate across three windows: before the incident, during it, and a control set running against a different target or a different network.
8. Failure counts grouped by address and by /24, so the pattern is visible without anyone having to compute it.
9. A job identifier where one exists. Requests through the SparkProxy Scraping API return a job id along with credit and timing values, and pasting that id into a ticket lets an engineer pull the exact request rather than searching for it.

That last point generalises. Anything that turns "find my traffic" into "look at this record" is worth more than a paragraph of description. Our post on measuring proxy success rate covers how to keep items seven and eight available continuously rather than reconstructing them during an incident.

One thing to leave out: screenshots of your own dashboard. They cannot be queried, they carry no timestamps a vendor can trust, and they invite a conversation about how you calculated the metric.

The highest-value item in any proxy ticket is a pair of one-line commands: one that fails through the proxy, one that succeeds without it, both runnable by the support engineer.

# Fails through the proxy
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" \
  -x http://USERNAME:PASSWORD@gateway.sparkproxy.io:11000 \
  https://target.example.com/pricing

# Succeeds from an ordinary egress with the identical client
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" \
  https://target.example.com/pricing

Add the exit address the vendor's network actually gave you, so the engineer can correlate:

curl -sS -x http://USERNAME:PASSWORD@gateway.sparkproxy.io:11000 https://api.ipify.org

If you are on the Scraping API rather than raw proxies, print the response headers so the job id travels with the report:

curl -sS -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://target.example.com/pricing" \
  --data-urlencode "render_js=false" \
  -D - -o /dev/null

Two rules for the reproduction. Keep it minimal, because a failing command with six flags invites an argument about which flag is responsible. And verify it fails reproducibly before you send it, because a reproduction that works on the third attempt tells the vendor your problem is intermittent, which is a different and much slower conversation. Our guide to testing whether your proxy is working covers building these into a standing check rather than writing them under pressure.

Structure beats prose. This shape gets answered fastest:

Claim type: address replacement / network investigation / service credit (pick one)

Window: 2026-09-28 09:14 to 11:40 UTC, ongoing

Target: target.example.com, HTTPS, plain GET, no rendering

What changed: nothing on our side. Same code, same headers, same rate as the preceding 14 days.

Triage results: identical request succeeds from our own egress (so not a client fault). 6 of 20 sampled exits fail consistently, 14 succeed consistently. All 6 failing exits are in the same /24. A control run on a different network succeeds at 99 percent.

Ask: replace the 6 listed addresses, and confirm whether the /24 is affected more broadly.

Attached: failing and control curl reproductions, per-address failure counts, full request and response headers for three failures, exit addresses as observed by the target.

Note what is missing. There is no history of how long you have been a customer, no statement about how much this is costing you, and no threat. All three of those move the ticket toward retention and away from the engineer who could fix it. Save them for the account conversation, which is a different conversation with a different person.

Replacement policy is where proxy vendors differ most and publish least. Four shapes cover nearly everything:

• Quota. A fixed number of swaps per month, per address or per account.
• Cooldown. Unlimited in principle, with a minimum holding period that caps it in practice.
• Evidence gate. Swaps granted only when the address fails an objective test, usually a public blacklist lookup.
• Paid. Swaps cost money, sometimes at the full rate.

The evidence gate is the one that catches people, because most addresses that stop working against a specific target never appear on any public blacklist. A target's internal reputation system is not a blacklist, and "this address gets challenged on one site" is not a fault the vendor can verify with a lookup. If your vendor operates an evidence gate, ask in advance what evidence they accept for a target-specific block, and get the answer in writing before you need it. Our explainer on IP blacklisting covers why the public lists and the private reputation systems disagree so often.

When you do ask, ask precisely:

Requesting replacement of the 6 addresses listed below. Each has returned a challenge on every one of the last 200 requests to target.example.com over the last 48 hours, while 14 other addresses on the same account returned 200 for the same request in the same window. Per-address counts attached. Please confirm the replacement addresses are outside 203.0.113.0/24, since all 6 failures are inside it.

The last sentence is the one that saves you a second ticket. Replacements drawn from the same range as the burned addresses will burn the same way, and vendors will honour a range exclusion if you ask for it explicitly.

Run the arithmetic once and you will stop thinking of service credits as a remedy.

A common structure credits a percentage of the monthly fee in bands: something like 10 percent when monthly availability falls below 99.9 percent, and a larger percentage below 99 percent. Read your own agreement for the actual bands, because they vary and ours is not a substitute for yours. Our guide to reading a proxy provider SLA covers where the definitions hide.

Now price a four-hour outage on a 30-day month, which contains 43,200 minutes:

• 4 hours is 240 minutes, so unavailability is 0.556 percent and availability is 99.44 percent.
• On the illustrative band structure above, that lands in the 10 percent band.
• On a $240 a month plan, the credit is $24.00. On a $440 plan, it is $44.00.
• That works out at $6.00 and $11.00 per hour of outage respectively.

If four hours of your pipeline being dark cost you more than $24, and it almost certainly did, the credit is a gesture rather than compensation. Two consequences follow, and both are more useful than the credit.

The real remedy is the failover you built before the outage. Money back does not restore the data you did not collect. Our post on proxy failover and redundancy is the relevant engineering, and it is worth more than any credit clause you could negotiate.

The real lever is the renewal. An outage is evidence in a commercial conversation that happens later, with a different person. Document it properly, then use it there.

One practical gate that catches most teams: nearly every SLA requires the customer to submit a claim within a fixed window, with their own records, and defines availability by the vendor's own monitoring unless you can show otherwise. If you were not measuring from outside the vendor's network, you have no standing to dispute their number. External monitoring is the price of admission for ever making a credit claim, and our post on proxy uptime and reliability covers how to set it up cheaply.

Escalate on a schedule you decide in advance, not when frustration peaks. Four rungs, with the timings being your internal clocks rather than anything a vendor promised:

Rung one, live chat or the ticket queue. File with the full evidence pack. For a total outage, give it two business hours. For a degradation, give it one business day.

Rung two, ask for the ticket to be escalated, by name. Say "please escalate this to your network team" rather than restating the problem. Add anything new you have learned, because a repeated complaint with no new information gets re-queued rather than raised.

Rung three, your account manager. This is the right moment to introduce commercial context, and the first moment it helps rather than hurts. The message is short: here is the ticket number, here is how long it has been open, here is what it is costing, please get engineering eyes on it.

Rung four, decide. If a network-level problem has been open for several days with no plan, you are no longer escalating, you are waiting. Switch the traffic. Our guide to switching proxy providers without downtime covers doing that without making the outage worse.

Write these clocks into your runbook while nothing is broken. During an incident, nobody negotiates escalation timings well.

1. Leading with cancellation. It routes you to retention, which cannot fix a subnet.
2. Changing three things and then reporting. Now nobody can tell which change mattered, including you.
3. Rotating through hundreds of addresses during the incident. It burns addresses that were fine, inflates your failure counts, and destroys the per-address pattern that would have proved your case.
4. Sending a dashboard screenshot instead of logs. Unqueryable, and it starts a debate about your metric.
5. Reporting "it is slow" with no numbers. Latency claims need a distribution, not an adjective. A p50 and p95 before and during is enough.
6. Filing under the wrong claim type. A service credit request lands in billing, where it will sit politely while your network problem goes uninvestigated.

One more worth its own line: check your own acceptable use policy position before escalating. If the target or the pattern sits outside what your contract permits, an escalation invites a review you may not want. Our post on proxy acceptable use policies covers what providers typically restrict, and why proxy accounts get suspended covers what happens when that review goes badly.