Shared Proxies: The Complete Guide from Beginner to Advanced

Shared proxies have a bad reputation that is roughly half deserved. Yes, you're using an IP address that strangers are also using. Yes, their behaviour affects whether that address works for you. And yes, plenty of people have bought a cheap shared pool, pointed it at a hard target, watched it fail, and concluded that shared proxies are worthless.

But shared proxies also carry an enormous share of the world's legitimate scraping traffic, at a price point that makes projects viable which would be unaffordable otherwise. The difference between those two outcomes is almost entirely about matching the product to the workload — and understanding what sharing actually costs you, which is more specific and more manageable than the reputation suggests.

This guide covers how sharing works, what reputation contamination really means, how to work out whether your workload can tolerate it, how to get the most from a shared pool, and where the honest limits are.

What a Shared Proxy Actually Is

A shared proxy is an IP address that multiple customers use simultaneously. You send requests through it, so does someone else, and neither of you knows about the other.

The variants you'll encounter:

Fully shared. Unlimited or unspecified numbers of users on the same address. Cheapest, least predictable. This is what most bulk datacenter pools are.
Semi-dedicated. A fixed small number of users per address, commonly three. Middle ground on both price and predictability.
Rotating shared pools. You draw from a large pool of shared addresses rather than being assigned specific ones. Functionally shared, but the sharing is spread across many addresses rather than concentrated on a few.
Rotating residential. Almost always shared by design — you're drawing from a pool of consumer devices that many customers use. The sharing is so distributed that it rarely feels like sharing.

Sharing is an axis, not a proxy type. You can have shared datacenter, shared residential, and shared ISP addresses, and the consequences differ in each case.

Four distinct costs, and separating them makes the buying decision much clearer.

Reputation contamination. The main one. Websites accumulate history about IP addresses, and on a shared address that history is the aggregate of everyone using it. Someone else scrapes a marketplace aggressively at 3am; you arrive at 9am and find the address is already flagged. You did nothing wrong and the address is still burned.

Critically, this contamination is target-specific. The person who burned that address on one marketplace probably didn't touch the fifty other sites you care about. An address that's useless for one target is frequently perfect for the rest, which is why the practical impact is much smaller than the theory suggests.

Capacity contention. You're sharing bandwidth and connection slots with people whose usage you can't see. Performance varies for reasons you can't diagnose or influence. On a well-provisioned pool this is negligible; on an oversold one it's the dominant problem.

Unpredictability. The deeper cost. When a shared address fails, you can't tell whether it's your behaviour, someone else's, or the target changing its rules. That diagnostic blindness makes systematic optimisation harder, and it's the thing that frustrates people most.

No whitelistability. You cannot supply a shared address to a partner's firewall allowlist, because other people use it. Any workflow requiring a fixed, exclusive egress address rules out shared proxies entirely.

Notice what isn't on this list: sharing does not affect IP classification. A shared datacenter address and a dedicated datacenter address are equally identifiable as hosting infrastructure. Sharing is a reputation and capacity question, not a detection question. People frequently buy dedicated proxies hoping to solve a classification block, and are disappointed.

The Economics of Why Shared Exists

Understanding the supply side explains both the low price and the quality variance.

A hosting provider acquires IPv4 address space in blocks. The marginal cost of routing one more address through existing infrastructure is close to zero — the expensive parts are the address block itself, the bandwidth, and the servers, all of which are already paid for. So the provider's incentive is to put as much revenue-generating traffic through each address as it can tolerate.

That produces a straightforward tension. More tenants per address means more revenue per address, and also more reputation contamination and more capacity contention. Every shared provider is picking a point on that curve, and where they pick is invisible to you at purchase time.

What follows from this:

Very cheap pools are usually cheap because they're dense. More tenants, more contamination, less predictability. Sometimes that's an acceptable trade and sometimes it isn't.
Refresh discipline costs money. Cycling burned addresses out and acquiring fresh blocks is an ongoing expense that a provider competing purely on price has an incentive to skip.
Diversity costs money. Address space from many ASNs across many regions is more expensive to assemble than one large contiguous block. Low-diversity pools are cheaper to build and worse to use.
Unmetered bandwidth is genuinely cheap at datacenter scale, which is why it's standard on shared datacenter products and why it's the feature least worth worrying about.

None of this makes shared proxies a bad product. It makes them a product where the price differences between providers are usually real differences in something, and where the cheapest option is cheap for reasons that will eventually become visible in your success rate. The way to see through it is to measure diversity and per-target success rate rather than comparing headline address counts and prices.

When Shared Proxies Are the Right Choice

Shared works well when:

You're harvesting public data across many domains. Spreading requests thinly across thousands of addresses is exactly what shared pools are built for. A percentage arriving pre-flagged is priced into the deal.
Volume matters more than any individual address. Link checking, availability monitoring, bulk verification, content monitoring. You'd rather have five thousand mediocre addresses than fifty pristine ones.
Individual failures are cheap. If you can retry through a different address and lose nothing, the exclusivity premium buys you very little.
The target is permissive. An enormous share of the web has no meaningful bot detection at all, and on those sites a shared address performs identically to a dedicated one.
You're testing. Prove the workload works on cheap infrastructure before spending on expensive infrastructure. This should be the default first step for every project.
Budget is genuinely constrained. A large shared pool used carefully substantially outperforms a small dedicated pool used carelessly.
You're doing stateless collection. No logins, no sessions, no accumulated relationship with the target.

When Shared Proxies Are the Wrong Choice

Don't use shared when:

You're logged into accounts. Authentication is where IP history is weighted most heavily, and inheriting a stranger's reputation on a login attempt is a genuinely bad outcome.
You're performing write operations. Posting, submitting, commenting, uploading. Writes attract far more scrutiny than reads, and a burned address means lost work rather than a cheap retry.
An external system whitelists your IP. Structurally impossible with a shared address.
The work is high-value per request. When a single successful request is worth a lot, the price gap between shared and dedicated becomes trivial next to the cost of failure.
You need diagnostic clarity. If you're doing careful optimisation work and need to know that failures are caused by your own behaviour, shared infrastructure hides exactly the signal you need.
Compliance requires known co-tenants. Some organisations simply can't use infrastructure where other users are unknown.
You need guaranteed capacity. Time-sensitive workloads shouldn't be subject to another tenant's traffic burst.

Subnet Diversity: The Thing Nobody Checks

This is the most underrated criterion in evaluating a shared pool, and it explains a lot of otherwise-baffling failures.

IP addresses aren't independent. They're allocated in blocks, and websites block at the block level rather than address by address. When a site decides to block a range, it blocks the whole subnet — often a /24, which is 256 consecutive addresses, and sometimes considerably larger.

The consequence: a pool of five thousand addresses all drawn from a handful of subnets is not five thousand independent chances. It's a handful of chances, replicated. One blocking decision by a target takes out a large fraction of your pool at once.

What good diversity looks like:

Addresses spread across many distinct /24 blocks
Multiple ASNs, meaning multiple hosting providers or network operators
Geographic spread across several datacenters or regions
No single block representing an outsized share of the pool

Checking it is straightforward:

cut -d: -f1 proxies.txt | cut -d. -f1-3 | sort -u | wc -l

If a five thousand address list resolves to twelve /24 blocks, you have twelve meaningfully independent addresses and a lot of redundancy. Compare that count against the raw address count before you buy, and ask the provider about ASN distribution if the list isn't available in advance.

> Tip: When a shared pool suddenly fails wholesale on one target, check whether the failures cluster by subnet before assuming the provider has a problem. Range-level blocking looks like catastrophic pool failure and is actually one blocking decision.

Getting the Most From a Shared Pool

The difference between a shared pool that works and one that doesn't is mostly operational.

Track health per (address, target) pair. This is the single highest-value practice in shared proxy work. Reputation is target-specific. An address burned on one site remains perfectly good on every other. Maintaining a per-pair state table means you route around problems instead of discarding inventory, and it typically recovers a large fraction of a pool that looks dead.

Filter your list before you use it. Test every address against your actual target — not a generic checker — and keep the working set. Re-test on a schedule, because pools rotate addresses and target policies change.

Rotate on failure, not on a timer. A working address is an asset. Keep using it while it works and retire it from a specific target only when that target starts refusing it.

Spread thinly. The whole advantage of a shared pool is breadth. Sending a large fraction of your traffic through a small subset of addresses recreates the problems you bought breadth to avoid.

Keep concurrency per address low. You don't know how much traffic other tenants are pushing through the same address. Assume you're not alone and behave accordingly.

Segment by workload. Don't run high-burn link checking and careful data collection through the same addresses. The burn side degrades the pool for the careful side.

Escalate rather than grinding. If a target's success rate stays under 40% after you've tuned headers, pacing, and fingerprint consistency, the shared pool isn't the right tool for that target. Route that target elsewhere and keep the pool for everything it does handle.

Refresh your list from the provider's API. Pools rotate addresses. A static list pasted in once will quietly degrade over weeks as entries go dead.

Log failures with enough detail to see patterns. Status code, address, subnet, target, and timestamp. Without this you can't distinguish a bad address from a bad subnet from a bad target from your own bad behaviour, and with shared infrastructure that distinction is exactly what you're missing.

Fingerprint and Behaviour Still Dominate

A point worth making bluntly, because it saves people a lot of money.

When someone reports that their shared proxies "keep getting blocked," the cause is often not the sharing. It's a client that doesn't look like a browser. On a shared address you have less margin for error, so poor configuration surfaces faster — but the poor configuration is the actual problem, and upgrading to dedicated addresses without fixing it just moves the failure to more expensive infrastructure.

The things to fix before blaming the pool:

TLS fingerprinting. Your HTTP client produces a distinctive handshake signature. Python's default client, Go's transport, and Node all produce handshakes that look nothing like Chrome regardless of what user agent you send. A Chrome user agent over a Python handshake is a stronger signal than a shared address.

Header completeness and ordering. Send the full realistic set — Accept, Accept-Language, Accept-Encoding, Referer, Connection, and the Sec-Fetch-* family — in the order the claimed browser would emit them. Library defaults match no real browser.

Locale coherence. The address's country, your language header, and your timezone should describe the same place.

Timing variance. Randomised delays, variable session lengths, idle periods. Perfectly regular intervals are a machine signature that no proxy type disguises.

Cookie handling. A client that discards cookies and re-triggers the same challenge repeatedly is trivially identifiable.

Concurrency discipline. Rate limiting is the most common "block" people encounter, and it's caused by their own request rate rather than by anyone else's behaviour.

Fix all of these on shared infrastructure first. If success rate is still poor afterwards, then the sharing genuinely is your constraint and escalation is justified. Most people escalate before doing the work, and pay for the privilege of the same failure.

A Note on Semi-Dedicated

The middle option deserves more attention than it usually gets, because it often resolves the shared-versus-dedicated argument better than either extreme.

Semi-dedicated addresses are limited to a small, specified number of users — typically three. What that buys you:

Bounded contamination. Instead of an unknown number of unknown tenants, you have two. Statistically that's a dramatically smaller chance of arriving at any given target already flagged.
Predictable capacity. Three-way contention is manageable; unbounded contention isn't.
A price point closer to shared than dedicated, usually a modest multiple of the shared rate rather than the several-fold jump to exclusivity.

What it doesn't buy you:

Whitelistability. Still shared, so still unusable where a partner needs a fixed exclusive address.
Full diagnostic clarity. You still can't attribute a failure confidently to your own behaviour.
Account safety. Two strangers is fewer than fifty, but it isn't zero, and login attempts weight IP history heavily enough that exclusivity is worth paying for there.

The workloads where semi-dedicated genuinely fits: moderate-value collection where shared has visibly failed but the cost of dedicated isn't justified by the value per request. Competitive monitoring, mid-tier ecommerce targets, and SEO crawling of protected sites all land here reasonably often.

It's worth testing as a third option in any shared-versus-dedicated comparison rather than treating the choice as binary. The measurement is the same: run the same URL sample through all three, record the status distribution, and compute cost per successful request for each.

Cost Modeling

The arithmetic that should drive the decision.

Dedicated monthly = address count x much higher unit price

That comparison is misleading on its own, because it ignores the thing that actually matters:

A shared pool at a fifth of the price with a third of the success rate is more expensive per usable result. A shared pool at a fifth of the price with 90% of the success rate is dramatically cheaper. Which one you have is an empirical question, and the only way to answer it is to measure both against your real target.

The measurement that settles it:

Take a representative sample of a few hundred real URLs
Run them through a shared trial with your real client configuration
Run the same set through a dedicated trial, same day, same configuration
Record the full status code distribution for each, not just pass/fail
Divide monthly cost by successful requests for each

The result frequently surprises people in both directions. On permissive targets, dedicated buys almost nothing and shared wins by a mile. On hardened targets, shared can be so ineffective that its low price is irrelevant.

The consequences of sharing differ depending on what kind of address you're sharing, and this is worth separating out because the generic advice doesn't apply evenly.

Shared datacenter. The classic case and the one most people mean. Cheap, fast, unmetered, and with the well-understood reputation contamination problem. Subnet diversity matters most here, because datacenter allocations are large contiguous blocks and range-level blocking is common. Works well on permissive targets and struggles on hardened ones, with or without sharing.

Shared residential. Almost all rotating residential is shared, and it barely feels like it. Because you're drawing from millions of addresses and each individual exit is used briefly, contamination is spread so thin that it rarely concentrates on any address you're using. The sharing is real but the practical impact is minimal, which is why nobody markets "dedicated residential" as a mainstream product.

Shared ISP. Less common, since ISP pools are small and the whole value proposition is stability and reputation control. Sharing a small pool of high-trust static addresses concentrates contamination rather than dispersing it, which undermines the point. If you're buying ISP, buy it dedicated.

Shared mobile. An interesting case, because carrier-grade NAT means the address is already shared with thousands of real subscribers. Adding a handful of proxy customers barely changes the picture. What you lose is rotation control — you can't force a reconnect without affecting other tenants — rather than reputation.

The pattern: sharing hurts most when the pool is small and the addresses are valuable. It hurts least when the pool is enormous and each address is used briefly. Datacenter and ISP sit at the painful end; residential and mobile at the tolerable end.

Use Cases in Depth

Bulk link checking and verification. The archetypal shared workload. Millions of HEAD requests across a huge range of domains, where individual failures cost nothing and volume is everything. Unmetered bandwidth and a large cheap pool is exactly the right shape.

Broad content monitoring. Watching many sites for changes, on a schedule. Each individual check is low-value and easily retried, and the breadth of targets means contamination on any one site affects a small slice of the work.

Public data harvesting across many domains. Directories, listings, documentation, news, forums. Most of the web has no meaningful bot detection, and paying dedicated prices to scrape sites that don't check is straightforwardly wasteful.

Availability and uptime monitoring. Checking that things respond, from multiple network positions. Sharing is irrelevant when you're testing reachability rather than extracting data.

Search engine and SERP harvesting at low sophistication. Works for some engines and some volumes, though this is a target category where escalation to residential or a managed API is common.

Development and testing. Proving a pipeline works before spending on production infrastructure. This should be the default first step and shared pools are the cheapest way to do it honestly.

Price and catalogue monitoring on permissive retailers. Not every ecommerce site runs aggressive detection. Test before assuming you need residential — a meaningful fraction of retail targets are handled fine by shared datacenter addresses.

Backlink and SEO crawling. High volume, low per-request value, enormous domain diversity. A near-perfect fit.

Architecture Patterns That Work

Per-pair health state as the foundation. Not a nice-to-have. A table keyed by (address, domain) with success counts, failure counts, last-failure reason, and a quarantine timestamp. This single structure recovers most of the value that naive shared proxy usage throws away.

Automatic list refresh. Pull the pool from the provider's API on a schedule rather than pasting a static file once. Shared pools rotate addresses, and a list that was accurate in January will be substantially dead by March.

Subnet-aware selection. When choosing an address, prefer one from a subnet that hasn't recently failed on this target. If a /24 is being blocked, drawing another address from the same block wastes a request.

Circuit breakers per target. When a domain's failure rate crosses a threshold, stop, alert, and back off. Grinding a whole shared pool against a target that's range-blocking you burns addresses across every subnet you have.

Tiered escalation. Route everything through shared first; retry failures on residential; retry those on mobile. Most requests resolve at the cheapest tier and your blended cost per successful request collapses. This is the highest-leverage pattern in proxy work and almost nobody implements it.

Separate pools by burn rate. High-churn work like link checking should not share addresses with careful collection. Segment them so the burn side doesn't degrade the careful side.

Failure classification in telemetry. Log enough to distinguish address-specific, subnet-specific, target-specific, and universal failures. With shared infrastructure this classification is the diagnostic capability you'd otherwise be missing.

Troubleshooting

Symptoms and their usual causes:

A large fraction of the pool fails on one target simultaneously — range-level blocking. Check whether failures cluster by /24. One blocking decision, not pool collapse.
Address works on most targets, fails on one — normal shared behaviour. Another tenant burned it there. Quarantine the pair, keep using the address elsewhere.
Success rate declining gradually over weeks — your list is going stale as the provider rotates addresses. Refresh from their API.
Performance varies unpredictably — capacity contention with other tenants. If it's severe and persistent, the pool is oversold.
407 Proxy Authentication Required — credentials or a whitelisted IP that changed, not a sharing issue.
Rate limited constantly — your own concurrency, most likely. Shared pools should be used broadly and thinly, not narrowly and hard.
Everything fails on a target from every address — classification blocking rather than reputation. Sharing isn't the problem; the IP type is. Escalate to a different classification, not to dedicated.
Some addresses never work at all — dead entries in the list. Test and filter.
Results inconsistent across runs — different addresses drawn each time, with different histories. Expected. Log which address produced which result.
Works in curl, fails in your tool — configuration format, not sharing.

The diagnostic principle specific to shared proxies: before concluding that sharing is your problem, check whether the failure pattern is address-specific, subnet-specific, target-specific, or universal. Those four patterns have four different causes and only one of them is actually about sharing.

Testing a Shared Pool Before You Commit

Shared pools vary far more in quality than dedicated products, because the things that determine quality — diversity, refresh rate, tenant density — are invisible from the outside. A structured trial answers questions the marketing doesn't.

Measure diversity first. Before sending a single request, analyse the list itself. Count distinct /24 blocks, distinct ASNs, and distinct geographic locations. Compare those counts against the total address count. A pool with a thousand addresses across two hundred subnets is a genuinely different product from one with a thousand addresses across eight.

Test liveness. Establish what fraction of the list actually responds. A meaningful proportion of dead entries is normal on cheap pools and tells you something about refresh discipline.

Test against your real targets, per address. Not a sample of addresses against a sample of targets — every address against your primary target, with the result recorded per address. This produces the data you actually need: what fraction of the pool is usable for the work you're doing.

Look at the failure distribution. Do failures cluster by subnet? That's range-level blocking and it means your effective pool is much smaller than the address count suggests. Are they scattered randomly? That's individual reputation contamination, which is more tolerable and more recoverable.

Re-test after a week. Pool composition changes. Measuring twice tells you whether the provider is actively cycling addresses or letting the list decay.

Compare against a dedicated trial. Same targets, same day, same client configuration. Compute cost per successful request for both. This is the number that decides the purchase, and it's the one almost nobody calculates.

A shared pool that looks poor on a generic checker but delivers 85% success on your actual targets is an excellent purchase. One that passes every anonymity test and delivers 20% is worthless at any price. Only the second measurement predicts anything.

Common Mistakes

Buying dedicated to fix a classification block. The single most expensive misunderstanding in this space. If a target blocks hosting ranges, exclusive hosting addresses are blocked just as thoroughly. Sharing affects reputation; classification is a separate axis and needs a different product.

Treating a burned address as globally dead. Reputation is target-specific. Discarding an address because one site refused it throws away inventory that works everywhere else, and on a large pool this compounds into enormous waste.

Concentrating traffic on a few addresses. The entire advantage of a shared pool is breadth. Sending most of your requests through a small subset recreates the concentration problems you bought breadth to avoid.

Ignoring subnet structure. Judging a pool by address count alone. Twelve subnets is twelve meaningful chances regardless of how many addresses sit inside them.

Blaming sharing for fingerprint problems. If your client doesn't look like a browser, every proxy type fails — shared just fails faster because there's less margin. Fix TLS fingerprint, headers, and pacing before escalating.

Using a static list indefinitely. Pools rotate. A list pasted in once decays quietly, and the gradual success-rate decline gets attributed to the provider rather than to staleness.

Skipping the shared trial entirely. Starting at dedicated or residential because shared "obviously won't work" means never discovering that for a large fraction of targets it works fine at a fraction of the cost.

Running incompatible workloads on one pool. Link checking and delicate collection through the same addresses means the high-burn side degrades the pool for the careful side, and the resulting failures look like provider quality problems.

Evaluating a Shared Proxy Provider

Criteria that predict real-world performance:

Subnet and ASN diversity, which matters more than raw address count and is almost never advertised
Pool size, in context of that diversity
How many users per address, if the provider will say. Many won't
Refresh cadence — how often dead or burned addresses are cycled out
API access for list retrieval, so you can refresh automatically
Bandwidth policy — unmetered is standard on shared datacenter and worth confirming
Concurrent connection limits
Protocol support — HTTP(S) and SOCKS5 on the same credentials
Authentication flexibility — whitelisting and credentials
Geographic distribution of the underlying infrastructure
Whether semi-dedicated is available as a middle option
Trial terms, and whether you can test enough addresses to judge diversity

Test with your real targets. A shared pool that passes a generic proxy checker tells you nothing; the question is what fraction of it works on the specific sites you care about, and that number is only obtainable empirically.

Legal and Ethical Considerations

Shared proxies are ordinary infrastructure; legality depends on use
Your behaviour affects other people. Aggressive scraping through shared addresses burns them for every other tenant. This is a genuine externality and worth taking seriously as a matter of conduct, not just self-interest
You may inherit consequences for behaviour you didn't engage in. If an address is associated with abuse, you may find yourself blocked or challenged as a result
Data protection law applies to what you collect regardless of routing
Rate-limit yourself. On shared infrastructure this is both courtesy to the target and courtesy to your co-tenants
Don't use shared addresses for anything where attribution matters, since attribution is exactly what sharing removes

Not legal advice, and jurisdictions differ. Have a lawyer review commercial operations at scale.

Frequently Asked Questions

How many people share one address?

Varies enormously and most providers won't tell you. Semi-dedicated products specify a number, usually three. Fully shared pools are unspecified by design.

Are shared proxies more detectable than dedicated ones?

No. Sharing affects reputation and capacity, not classification. A shared datacenter address and a dedicated one are equally identifiable as hosting infrastructure.

Why do my shared proxies work on some sites and not others?

Because reputation is target-specific. Another tenant burned the address on one site and never touched the others. Track health per address-target pair and route around it.

Is it worth paying for semi-dedicated?

Sometimes. You get better reputation control and capacity predictability than fully shared, at a fraction of dedicated pricing. Worth testing when shared has visibly failed but dedicated seems excessive.

Can I use shared proxies for account management?

You shouldn't. Login attempts weight IP history heavily, and inheriting a stranger's reputation at that moment is a bad outcome. Use dedicated or ISP addresses.

How do I tell if a pool has good subnet diversity?

Count distinct /24 blocks in the list and compare against the total address count. Ask about ASN distribution. Low diversity means a single blocking decision takes out a large fraction of your pool.

My whole pool stopped working on one site. What happened?

Almost certainly range-level blocking. Check whether the failures cluster by subnet. That's one decision by the target, not a provider failure.

Does unmetered bandwidth on shared pools mean unlimited requests?

No. Bandwidth and request rate are different constraints. You can move unlimited data and still get rate limited by a target for requesting too often. Unmetered removes the data cost, not the pacing requirement.

Why is one provider a tenth the price of another for the same address count?

Usually tenant density, subnet diversity, or refresh discipline — the three things that cost money to do well and are invisible at purchase. Measure diversity and per-target success rate rather than comparing headline numbers.

Should I start with shared or dedicated?

Shared, essentially always. Prove the workload works on cheap infrastructure, measure the success rate, and escalate only where the evidence justifies it.

Where to Get Shared Proxies

If your workload suits broad, thin distribution across many addresses, ProxyScrape's shared proxies offer the low per-address pricing and large pool that bulk public-data collection depends on, with HTTP(S) and SOCKS5 support and unlimited bandwidth so high request volumes don't carry a data cost. If testing shows your target needs exclusive reputation control — account work, write operations, or whitelisted access — their dedicated proxies cover that case, and if the blocking turns out to be classification rather than reputation, residential is the escalation that actually addresses it.

→ Compare shared proxy plans and measure the success rate on your own targets

Shared proxies are the correct starting point for far more workloads than their reputation suggests, and the operators who use them well are the ones who understood that reputation is target-specific rather than global. Track health per address-target pair, spread your traffic broadly, fix your fingerprint before blaming the pool, and measure cost per successful request rather than cost per address. Most of the time, the expensive upgrade people reach for turns out to have been fixing a problem that better configuration would have solved for free.