ScrapeBox has been around long enough to have acquired a reputation, most of it earned and some of it unfair. It was built as an SEO swiss army knife — harvest URLs from search engines, check links at enormous volume, scrape keywords, verify page metrics, extract emails, and run a long list of specialised addons — and it does all of that faster than almost anything else on a Windows desktop.
It also has a proxy problem, in the sense that nearly every complaint about ScrapeBox turns out to be a proxy problem, a connections setting, or both. "My harvester stopped returning results" is almost never a bug. It's usually a hundred threads pointed at a search engine through a proxy list that died an hour ago.
This guide covers how ScrapeBox actually uses proxies, which proxy type each module needs, the settings that matter more than the proxy list itself, and how to run it in a way that doesn't burn through addresses in an afternoon.
What ScrapeBox Actually Is
A multi-threaded desktop tool that performs bulk web operations. The core modules and what each one does:
The Harvester. Queries search engines and other sources against footprints and keywords, returning URLs. This is the module people think of first and the one that puts the most stress on proxies.
The Keyword Scraper. Pulls related terms, suggestions, and long-tail variations from search engines and other suggestion sources.
The Link Checker. Verifies whether links exist on pages at very high volume. Backlink verification, outbound link auditing, and broken link discovery all run through this.
The Comment Poster. Submits to blogs, guestbooks, and similar targets. The module responsible for most of ScrapeBox's reputation, and the one to think carefully about — more on that below.
Metrics checkers. Page authority, domain authority, indexation status, and various third-party metrics, generally by querying external services.
The Addons. A large collection of specialised tools — alive checkers, sitemap scrapers, backlink checkers, email grabbers, outbound link checkers, image downloaders, malware checkers, duplicate removers, and many more. Each has its own request profile.
The Automator. Chains operations into repeatable workflows, which is where ScrapeBox becomes genuinely powerful for recurring jobs rather than one-off sessions.
Everything in that list makes HTTP requests in volume, and everything in that list benefits from proxies. But they don't all need the same proxies, and treating them identically is the single most common configuration mistake.
Why ScrapeBox Needs Proxies
Three separate reasons, and knowing which applies to a given module shapes what you should buy.
Rate limiting. Search engines and most sites limit how many requests one address can make in a window. ScrapeBox is fast enough to hit those limits within seconds from a single connection.
Blocking. Search engines in particular respond to automated querying by challenging or blocking the address. Without rotation, a harvesting session ends almost immediately.
Protecting your own connection. Running high-volume link checking from your home or office IP will get that address rate limited across a lot of the internet, which affects everything else you do from it. This alone justifies proxies even for modest use, and it's the reason people who "don't need proxies yet" usually do.
What proxies don't fix: a badly configured client. If your connections setting is 200 and your timeout is 5 seconds, no proxy list will save you. More on that shortly.
Matching Proxy Type to Module
This is where most of the value in this guide sits. ScrapeBox modules have genuinely different requirements, and routing everything through one list is either wasteful or ineffective.
Search engine harvesting. The hardest target. Search engines block hosting ranges aggressively and challenge automated patterns quickly. Options in ascending order of cost and effectiveness:
- Datacenter addresses, which work for some sources and fail fast on the major engines
- Residential addresses, which are the realistic answer for sustained search harvesting
- A managed search results API, where you buy structured results instead of maintaining a harvesting setup at all
Custom footprint harvesting on ordinary sites. Much easier. Most of the web has no meaningful bot detection, and shared datacenter addresses with unlimited bandwidth are ideal — volume matters far more than trust here.
Link checking. The textbook unmetered datacenter workload. Enormous request counts across huge domain diversity, tiny per-request value, and no geographic sensitivity. Anything more expensive is waste.
Metrics and third-party API checkers. These query external services with their own rate limits, usually per-address. Datacenter addresses in reasonable quantity work well, and the constraint is the service's tolerance rather than classification.
Alive checking and status verification. Same profile as link checking. Cheap, high volume, unmetered.
Email and contact extraction. Depends entirely on the target sites. Test datacenter first; escalate where specific sources block.
Comment posting and any submission module. Write operations, which attract far more scrutiny than reads. Dedicated addresses with exclusive reputation control, if you use these modules at all.
The general rule: run separate proxy lists for separate modules. Link checking burns addresses at a rate that would ruin a harvesting list, and there's no reason to let one damage the other.
> Tip: The single biggest cost saving available in ScrapeBox is not using expensive proxies for link checking. It's a high-volume, low-difficulty workload and it's where most people's proxy spend disappears.
HTTP or SOCKS5 in ScrapeBox
ScrapeBox supports both, and which you use matters more than beginners expect.
HTTP proxies are the default assumption for most web tooling and work fine for the majority of ScrapeBox operations. Broad compatibility, well-tested paths.
SOCKS5 operates lower in the stack, doesn't parse your traffic, and adds marginally less overhead per connection. In ScrapeBox specifically, several things make it attractive:
- Lower per-connection overhead matters at ScrapeBox's request volumes. When you're making hundreds of thousands of requests, small per-request savings compound.
- Some addons and connection types behave better over SOCKS5, particularly anything not doing plain HTTP.
- Fewer intermediary complications. A SOCKS5 proxy relays bytes rather than interpreting and potentially modifying requests, which removes a class of subtle problems.
- Remote DNS resolution. SOCKS5 can resolve hostnames at the proxy rather than locally, which both avoids leaking your lookups and produces more consistent results when targets use geographic DNS routing.
Practical guidance: use whichever your list is provided as, test both if your provider supports both on the same credentials, and note that a provider offering both means you can switch per module without buying twice. For heavy harvesting and link checking at volume, SOCKS5 is worth benchmarking against HTTP on your own workload — the difference is usually small and occasionally meaningful.
Configuration note: ScrapeBox needs to know the proxy type. A SOCKS5 list loaded as HTTP will fail in ways that look like dead proxies, and this catches people out regularly. Check the proxy type setting before concluding a list is bad.
Loading and Managing Proxies
The mechanics, and the settings that matter.
Supported formats. ScrapeBox accepts the standard forms:
ip:port:username:password
Both work. Which you use depends on whether you're authenticating by credentials or by IP whitelist. If you're on a static connection or a VPS, whitelisting is slightly faster and removes the credential-format questions entirely.
Loading methods:
- From file. Paste or import a saved list. Fine for static allocations.
- From clipboard. Quick and convenient for testing.
- From URL. The one worth using. Point ScrapeBox at your provider's list endpoint and it pulls a current list each time, which solves the stale-list problem that quietly degrades success rates over weeks.
- From the built-in harvester. ScrapeBox can find public proxies itself. Useful for learning, unusable for production.
Testing proxies. ScrapeBox includes a proxy tester that checks connectivity and can test against specific targets. Two things worth knowing:
- Test against what you're actually going to use them for. A proxy that passes a generic anonymity check and fails your target is useless to you. If you're harvesting a specific engine, test against that engine.
- Keep the working set. Export the addresses that passed and use that list rather than re-testing everything on every run.
Filtering. After testing, filter to the addresses that work for your intended use. Running a job through a list where a third of entries are dead wastes threads on timeouts and inflates your apparent failure rate.
Refresh regularly. Provider pools rotate addresses. A list saved three months ago will have substantially decayed, and the decline is gradual enough that people blame the tool rather than the list.
The Settings That Matter More Than the Proxies
This section resolves most ScrapeBox complaints.
Connections. The number of simultaneous requests. This is the single most consequential setting and the one people set wrong.
- Search engine harvesting: start at 10–20. Not 200. Search engines are the most sensitive target ScrapeBox touches, and high thread counts guarantee challenges.
- Custom footprint harvesting on ordinary sites: 25–50 is usually comfortable.
- Link checking: 50–100, and higher if your addresses and bandwidth support it. This is the workload that tolerates parallelism.
- Metrics checkers: dictated by the external service's rate limit rather than by your appetite.
The tuning method that works: start conservative, run a few hundred requests, record the success rate, double the connections, measure again, and stop when the success rate starts falling. Then step back one level.
Measure successful requests per minute, not raw requests per minute. Two hundred threads at a 30% success rate does less work than fifty at 95%, burns far more addresses, and takes longer overall because of retries.
Timeout. Set this according to your proxy type:
- Datacenter addresses are fast: 10–15 seconds is generous
- Residential addresses are genuinely slower: 30–60 seconds
- Mobile addresses are slower still
An aggressive timeout discards perfectly good responses and makes a working proxy list look dead. If your success rate collapsed after switching to residential proxies, check the timeout before anything else.
Delay between requests. The harvester delay is the cheapest anti-block tool available. Adding two to five seconds costs you time and saves you addresses, and on search engines it's frequently the difference between a session that runs and one that stops after a minute.
User agent rotation. Turn it on. A hundred thousand requests from thousands of addresses with one identical user agent is a trivially detectable pattern, and it undermines the point of having the addresses.
Results per query and pagination depth. Requesting deeper pagination on search engines multiplies your request count and your block risk for results of declining value. Most of the useful returns are shallow.
Harvesting Effectively
Footprints are the actual skill. ScrapeBox's power comes from combining a footprint — a distinctive string that identifies a type of page — with keywords. The quality of your footprints determines the quality of your results far more than any setting.
Use the custom harvester for non-search sources. ScrapeBox can harvest from sources other than the major search engines, and many of them are dramatically more permissive. Where a source will give you what you need without fighting bot detection, use it.
Deduplicate as you go. ScrapeBox has duplicate removal built in for both URLs and domains. Running it before the next stage saves an enormous amount of downstream work.
Split large keyword lists. Enormous harvesting sessions in one run are fragile — one interruption loses the lot. Batch them.
Harvest to file frequently. Long sessions that hold everything in memory until completion are an unnecessary risk.
Watch for engine-specific quirks. Different sources have different tolerance, different pagination behaviour, and different response patterns. Treating them identically produces inconsistent results.
Consider whether you need to harvest at all. For search results specifically, a managed API returns structured data without any of the proxy management, and for many use cases that's both cheaper and more reliable than maintaining a harvesting setup.
Link Checking at Volume
The module where ScrapeBox is genuinely excellent and where the economics are clearest.
This is an unmetered bandwidth workload. Millions of requests, small responses, no geographic sensitivity, and no need for residential classification. Shared datacenter addresses with unlimited bandwidth are exactly right, and anything more expensive is money burned.
Raise connections here. Unlike harvesting, link checking tolerates high parallelism because the targets are diverse — you're spreading load across thousands of domains rather than hammering one.
Use a separate list from your harvester. Link checking burns addresses fast, and there's no reason to damage the pool you use for the sensitive work.
Set a sensible timeout. Some targets are slow; waiting forever wastes threads. Ten to fifteen seconds is usually right on datacenter addresses.
Handle redirects deliberately. Decide whether a redirected link counts, and configure accordingly, because the answer differs by use case.
Batch and checkpoint. Multi-million-link jobs will be interrupted at some point.
Addons and Their Proxy Profiles
The addon collection covers a wide range of request patterns. Broadly:
High-volume, low-sensitivity addons — alive checkers, outbound link checkers, sitemap scrapers, duplicate removers — behave like link checking. Cheap datacenter addresses, high connections, unmetered bandwidth.
Third-party service queries — metrics checkers, backlink checkers, malware checkers — are constrained by the external service's rate limits rather than by classification. You need enough addresses to spread across those limits, and the service's tolerance sets your ceiling.
Content extraction addons — article scrapers, image downloaders, email grabbers — depend on the target sites. Test datacenter first and escalate only where specific sources refuse.
Anything performing a write or submission should use dedicated addresses with exclusive reputation control, for the same reasons that apply to the comment poster.
Bandwidth-heavy addons — image downloading in particular — make unmetered bandwidth a requirement rather than a preference.
The Comment Poster: An Honest Word
ScrapeBox's reputation comes largely from one module, and it deserves direct treatment rather than being quietly skipped.
What mass automated commenting is. Submitting to thousands of blogs, guestbooks, and forms to place links. It's spam, in the ordinary sense of the word. Site owners spend real time cleaning it up, comment sections have been degraded across the web partly because of it, and search engines have devalued the links it produces so thoroughly that the technique has limited effect on rankings anyway.
The practical case against it, setting ethics aside: the links are discounted, the footprints are well known, the collateral risk to a site you care about is real, and the effort is better spent elsewhere. This is one of those situations where the honest advice and the effective advice happen to coincide.
What the same tooling is genuinely good for:
- Link prospecting. Finding relevant sites, resource pages, and potential outreach targets at scale, then contacting them like a person.
- Broken link discovery. Finding dead links on resource pages, which is the basis of a legitimate and effective outreach approach.
- Competitor backlink analysis. Understanding where competitors have earned links.
- Content and site auditing. Checking your own properties at volume.
- Research and data collection. Gathering publicly available information for analysis.
If you use the submission modules at all, use dedicated addresses, keep them entirely separate from everything else, and understand that the addresses will accumulate a reputation you can't undo.
Workflow Examples
ScrapeBox is most useful when modules are chained, and a few concrete workflows show how the proxy requirements shift across stages.
Link prospecting for outreach.
- Harvest URLs using footprints that identify resource pages, roundups, or relevant directories in your niche. Sensitive stage — residential addresses, low connections, delays enabled.
- Deduplicate by domain, since one link per site is the realistic ceiling anyway.
- Run the metrics addons to filter by authority or relevance. Constrained by the third-party service's limits.
- Check the surviving pages are live and relevant. Cheap datacenter addresses, high connections.
- Extract contact details where published, then contact people individually like a human being.
The proxy spend concentrates in step one and step four uses the cheapest addresses available. Running the whole chain through one expensive list is the common error.
Broken link discovery.
- Harvest resource pages in your topic area.
- Run the outbound link checker across them to find dead links. Enormous request volume, entirely undemanding — unmetered datacenter addresses, high connections.
- Filter to dead links pointing at content you could plausibly replace.
- Verify the pages are still maintained.
- Contact the site owner with a useful suggestion.
Step two dominates the request count and costs almost nothing on the right addresses.
Competitor backlink auditing.
- Obtain competitor backlink lists from whatever source you use.
- Verify each link still exists with the link checker. High volume, cheap addresses.
- Check which are dofollow, which redirect, and which are dead.
- Identify patterns — the site types, the page types, the content that attracts links.
Almost entirely link checking, which is why this workflow is cheap to run at scale.
Site auditing on your own properties.
- Scrape your sitemap.
- Check every URL's status and redirect chain.
- Run outbound link checking to find your own dead links.
- Verify indexation.
You control the target, so pacing is a courtesy to your own server rather than an evasion problem, and proxies mainly serve to avoid rate limiting yourself out of third-party services.
Running ScrapeBox Reliably
The operational habits that separate a setup that runs unattended from one that needs babysitting.
Run it on a VPS, not your desktop. A Windows VPS with a static address gives you IP whitelisting, uninterrupted long jobs, and a machine that doesn't sleep. It also keeps high-volume traffic off your working connection.
Watch your host's resource limits. ScrapeBox is fast enough to saturate CPU, memory, and the machine's own connection. High connection counts on an underpowered host produce timeouts that look like proxy failures.
Batch everything long. Break large keyword lists and URL sets into chunks that complete in reasonable time. An interrupted eight-hour job that saved nothing is a wasted day.
Export at every stage. Harvest to file, then load for the next module, rather than chaining everything in memory.
Keep a proxy health routine. Refresh from your provider's endpoint, test against your actual targets, export the working set, and use that. Weekly at minimum, per-session for sensitive work.
Use the Automator for recurring jobs. Anything you do more than twice should be a saved workflow rather than a sequence you remember.
Log what you ran. Which footprints, which keywords, which settings, and what came back. Reproducing a good result six months later is otherwise guesswork.
Monitor your success rate, not your throughput. The number that matters is useful results per hour. A job running at maximum connections with a 20% success rate is slower and more expensive than a calmer one.
Troubleshooting
Symptoms and their usual causes, in the order worth checking.
- Harvester returns nothing — connections too high, proxies dead, or the source is blocking. Check the proxy list first with the tester, then halve your connections.
- Everything times out — timeout set too low for your proxy type. Residential addresses need 30–60 seconds, not 10.
- Proxies test fine but jobs fail — you tested for connectivity rather than against your target. Test against the actual source you're using.
- Worked yesterday, not today — stale list. Refresh from your provider's URL rather than reusing a saved file.
- Proxies fail immediately on load — wrong proxy type selected. A SOCKS5 list loaded as HTTP fails in exactly this way.
- Authentication failures — credential format, or your whitelisted IP changed. Home connections change addresses regularly.
- Results inconsistent between runs — different addresses with different histories drawing different results. Expected on a rotating pool.
- Sudden total failure on one source — that source blocked your provider's range. One decision, not a broken list. Different addresses from a different range are the remedy.
- High CPU or memory — connection count too high for the machine. ScrapeBox is fast but the host has limits.
- Slow throughput despite many connections — bandwidth constrained, or your addresses are slow. Residential and mobile are genuinely slower than datacenter.
The general debugging order: test one proxy manually outside ScrapeBox, then test it in ScrapeBox's tester, then run a small job, then scale up. Establishing where it breaks before changing settings saves a lot of time.
Cost Planning
ScrapeBox's proxy costs are easy to model and easy to get wrong in one specific direction.
The workload split. For a typical setup, request volume divides roughly like this: link checking and alive checking account for the overwhelming majority of requests, addon and metrics queries a substantial minority, and search harvesting a small fraction of the total request count while consuming the most sensitive addresses.
The mistake this creates. People buy residential proxies because harvesting needs them, then route the entire workload through that list. Since link checking generates most of the requests, the majority of the spend goes to the cheapest, least demanding work in the whole toolkit.
The fix is two lists. A large cheap datacenter allocation with unlimited bandwidth for the volume, and a smaller residential allocation for harvesting. The saving is usually substantial and it costs nothing but a configuration change.
Sizing the cheap list. For link checking, address count follows from your connection count and the diversity of your targets. Because you're spreading across thousands of domains rather than hammering one, a modest allocation supports high parallelism. Start with a few hundred addresses and increase if you see rate limiting.
Sizing the harvesting list. Determined by how many requests each address survives before being challenged, which you establish empirically. Run a session, count the requests before block rates climb, and divide your intended volume by that figure.
Bandwidth. Link checking and alive checking generate high request counts with small responses, so unmetered datacenter bandwidth makes the volume irrelevant. Image downloading and content extraction addons are the exception — those are genuinely bandwidth-heavy and would be punishing on a metered plan.
Compare cost per useful result, not cost per address. A cheap list with a low success rate against your specific sources is more expensive per usable URL than a better one. The only way to know is to run the same job through both and count what came back.
Practical Setup Recommendations
A workable starting configuration for someone setting this up properly.
Two proxy lists minimum. One cheap, high-volume list for link checking and the bulk addons. One better list for harvesting and anything sensitive. Keep them separate in ScrapeBox and never mix them.
Load from URL, not from file. Your provider's list endpoint, refreshed each session. This alone prevents the slow decay that causes most "ScrapeBox stopped working" reports.
Authentication by whitelist if you can. Fewer moving parts, no credential formatting issues, marginally faster. Use credentials if your connection's address changes.
Conservative connections, tuned upward. Start low, measure, increase. Resist the temptation to start at the maximum.
Timeouts matched to proxy type. This is a two-second change that resolves a large share of apparent proxy failures.
Test against your real targets. Before every significant job, not just at setup.
Save working sets. Export lists that passed testing against a given source so you're not re-testing everything each run.
Batch long jobs. Checkpointing and resumability matter at ScrapeBox's volumes.
Where ScrapeBox Fits Alongside Other Tools
Being honest about the tool's current position, since a lot of what it was uniquely good for is now available elsewhere.
What it's still excellent at. Bulk link checking at volumes most tools won't attempt. The breadth of the addon collection, which covers a lot of niche operations nobody else bothered to build. Speed on a desktop with no per-request pricing. Footprint-based discovery, where the flexibility of arbitrary search operators still beats structured alternatives.
Where managed APIs have taken over. Search result data specifically. Maintaining a harvesting setup — proxies, rotation, block handling, and the constant adjustment as engines change — is real ongoing work, and buying structured results removes all of it. If search data is what you need rather than a byproduct of a larger workflow, the API is usually both cheaper and more reliable.
Where modern crawlers are better. Technical site auditing on your own properties, where dedicated SEO crawlers give you rendering, structured reporting, and integrations ScrapeBox doesn't.
Where custom code wins. Anything requiring unusual logic, integration with your own systems, or operation on a schedule inside a larger pipeline. ScrapeBox is a desktop tool, and that's a real constraint.
The sensible position: use ScrapeBox for the high-volume, low-complexity bulk operations it does faster than anything else, and don't force it into roles where better-suited tools exist. Most people who find ScrapeBox frustrating are using it for search data, which is the one thing it now has real competition for.
A note on longevity. It's a mature Windows desktop application with a one-time licence and no per-request cost. That pricing model is genuinely unusual now and it's a substantial part of why the tool persists — at high volumes the economics are hard to beat, provided your proxy setup is sensible.
Legal and Ethical Considerations
- Public data collection and terms of service are different questions. Collecting publicly accessible information is generally unproblematic; many sites' terms prohibit automated access, which is a contractual matter with real commercial risk.
- Search engine terms generally prohibit automated querying. This is contractual rather than criminal in most jurisdictions, and it's worth knowing rather than discovering.
- Rate-limit as a matter of conduct. ScrapeBox is fast enough to degrade a small site without intending to. That's an unforced error regardless of legality.
- Respect published crawl directives where they apply to you.
- Don't collect personal data you have no lawful basis to hold. Email extraction in particular engages data protection law directly, and bulk email collection followed by unsolicited contact engages marketing regulation on top of that.
- Automated submission to sites that didn't invite it is spam, and in some jurisdictions and some forms it engages more than platform rules.
- Don't use collected data in ways the source would clearly object to, which is a reasonable heuristic even where the law is unclear.
Not legal advice, and jurisdictions differ. Commercial use at scale warrants a lawyer's review, particularly around email collection and outreach.
Frequently Asked Questions
How many proxies do I need for ScrapeBox?
Depends on the module and your connection count. A rough starting point is roughly one address per two to five connections for sensitive work, and far fewer per connection for link checking where targets are diverse. Tune from observed block rates rather than from a formula.
Do I need residential proxies?
For sustained search engine harvesting, usually yes. For link checking, custom footprint harvesting, and most addons, datacenter is both sufficient and dramatically cheaper. Don't buy residential for the whole workload.
Can I use free proxies with ScrapeBox?
For learning the tool, yes. For anything you care about, no — success rates are poor and unpredictable, addresses die mid-job, and you have no idea who's operating them.
HTTP or SOCKS5?
Either works. SOCKS5 has marginally lower overhead, which compounds at ScrapeBox's volumes, and supports remote DNS resolution. Test both if your provider offers both on the same credentials.
Why did my harvester stop working?
In order of likelihood: connections too high, stale proxy list, timeout too low, or the source blocked your provider's range. Check them in that order.
Should I use the built-in proxy harvester?
For learning, it's fine. For production, no. Public proxies are unreliable, mostly already blocked on anything worth harvesting, and operated by unknown parties.
How do I stop burning through proxies so fast?
Lower your connections, add a delay, separate your lists by module, and stop using your harvesting pool for link checking. In that order.
How do I know if a proxy list is any good before buying?
Load a trial list, test it against the specific source you intend to harvest rather than against a generic checker, and record how many addresses pass and how long they survive a real session. Connectivity tests tell you nothing about whether the addresses work on your targets.
Can I run ScrapeBox and other tools through the same proxies?
You can, and you generally shouldn't share a list between ScrapeBox's high-burn modules and anything delicate. ScrapeBox's volumes will degrade addresses faster than most other tooling, and separate lists cost very little.
Is ScrapeBox still relevant?
For bulk link checking, URL harvesting, and the addon toolkit, it remains fast and capable. For search result data specifically, managed APIs have made a lot of harvesting unnecessary. Use it for what it's still best at.
Getting the Proxy Setup Right
ScrapeBox's request volumes reward lower per-connection overhead, which is a genuine argument for ProxyScrape's SOCKS5 proxies — the same credentials also work over HTTP, so you can run whichever performs better on your own workload without buying twice, and ScrapeBox handles both formats natively. For the bulk of what ScrapeBox does — link checking, alive checking, custom footprint harvesting, and the high-volume addons — their premium datacenter plans with unlimited bandwidth are the right economics, since these workloads need volume rather than trust. Keep a separate residential list for sustained search engine harvesting where datacenter addresses get challenged quickly, and load both from a URL endpoint so ScrapeBox pulls a current list each session rather than working from a file that quietly decayed.
→ Compare SOCKS5 and datacenter plans for ScrapeBox workloads
Nearly every ScrapeBox problem that gets blamed on proxies is actually a connections setting, a timeout mismatched to the proxy type, or a list that went stale weeks ago. Fix those three and a modest proxy allocation will outperform an expensive one used carelessly. Separate your lists by module, tune connections upward from a conservative start rather than downward from the maximum, and put your money into the harvesting pool rather than into link checking — which is the highest-volume, least-demanding thing the tool does and where most people's proxy budget quietly disappears.