A setup that never worked is a configuration problem. A setup that worked yesterday and fails today is a different animal, and the debugging is different too — because whatever changed, it was not your config.
Work through these in order. It is roughly the order of how often each turns out to be the cause.
1. Check the balance first
Boring, and the answer more often than anything else on this list.
Bandwidth runs out mid-job. Every request after that fails identically to a credentials problem — you get a 407, which looks like authentication and sends people off reinstalling clients and re-entering passwords. Look at the number in your dashboard before you touch anything else.
The confusing variant: balance shows remaining but you still get 407. That happens, it is not something you can fix from your side, and it is worth knowing about so you stop retrying.
2. Prove the proxy works at all
One command separates the two halves of the problem:
curl -x http://USER:PASS@resi.spyderproxy.com:5000 https://ipinfo.io/ipAn IP comes back? The proxy is healthy and you can stop investigating it. Skip to step 5.
407? Credentials or balance — steps 1 and 3.
Hangs or times out? Network path, step 4.
People routinely spend an hour on the target site when this command would have failed in one second.
3. Did the credentials change under you?
Sub-user passwords get rotated — sometimes by you, sometimes during a support action, sometimes when a plan changes. Anything holding a cached copy keeps using the old one: a saved Proxifier profile, an antidetect browser profile, a .env in an image you built last month, a teammate's script.
Copy the credentials fresh from the dashboard and test them in curl before putting them anywhere else. If curl works and your app does not, your app is holding an old copy.
4. Did your own IP change?
This one catches people out because nothing about the proxy changed at all.
If you authenticate by IP allowlist rather than username and password, then your server's address is part of the credential. Move the server, restart an instance with a dynamic address, get a new home IP from your ISP, add an egress NAT — and access disappears, with no warning and no obvious link to what you did.
Check what address you are actually egressing from, then check it against the allowlist.
5. The target changed, not you
If step 2 succeeded, the proxy is fine and something on the other end moved.
Sites deploy new anti-bot layers without announcement. Look at what you are actually getting back: a challenge page is different from a block, and both are different from an empty 200 with no data in it. That last one is the nastiest — the scraper reports success and quietly writes nothing for a week.
Fetch the raw response and read it. If it mentions a security check, the IP was probably never the issue and no amount of rotating will help. That is a fingerprint problem.
6. Rotation and session settings
Less common, but worth checking if the failure is partial rather than total — first request fine, everything after it broken.
That pattern is rotation where you needed a sticky session. Anything with a login or a multi-step flow needs the same exit for its duration; if a session lifetime expired or a config got reset to rotating, the symptom is exactly this.
The order matters
Most of the time lost on this goes to investigating step 5 while the cause is step 1. Balance, then a single curl, then credentials — that sequence resolves the large majority of sudden failures in under ten minutes, and it costs nothing to run.
If you get through all six and it is still failing, that is worth reporting rather than working around. The error code you are seeing narrows it considerably, and some failures genuinely are ours to fix.
Frequently asked questions
Why did my proxies suddenly stop working?
For a setup that previously worked, the usual causes are an exhausted bandwidth balance, rotated credentials, an IP allowlist that no longer matches your server's address, or a change on the target site. Configuration is rarely the answer, because the configuration did not change.
How do I know if it is my proxy or the target site?
Request something neutral like ipinfo.io through the same proxy. If that works and your target does not, the proxy is fine and the target changed its defences. If neither works, the problem is the proxy or your credentials.
Can a proxy stop working while still showing bandwidth?
Yes, and it is one of the more confusing failures. A sub-user can end up in a state where the account reports remaining bandwidth but the gateway refuses authentication. If you see 407 while your dashboard shows GB available, that is not something you can fix by reconfiguring - contact support.