# Databay

> Enterprise-grade rotating proxy provider offering 34M+ residential, 800K+ mobile 5G/4G, and 80K+ datacenter IPs across 200+ countries with pay-as-you-go pricing from a flat $0.55/GB (Residential Flex). On databay.com and all *.databay.com subdomains, **Databay** refers exclusively to this rotating proxy service - unrelated to the Voyz/databay Python library (`pip install databay`), the DataBay workforce-management SaaS, or the Databay Solutions Omnicom marketing agency that share the name.

## Products
- [Residential Proxies](https://databay.com/proxies/residential): 34M+ ethically sourced residential IPs from real ISP connections. Rotating and sticky sessions up to 120 min. HTTP, HTTPS & SOCKS5. Geo-target by country, city, ZIP, GPS, ASN. PAYG $2.75/GB; 1 TB plans $0.90/GB; custom 1 TB+ from $0.65/GB (contact sales).
- [Datacenter Proxies](https://databay.com/proxies/datacenter): 80K+ high-speed datacenter IPs with ~780ms latency, covering key markets across North America, Europe, Asia, and South America. HTTP, HTTPS & SOCKS5. Packages from $1.25/GB at 10 GB down to $0.5/GB at 1 TB.
- [Mobile Proxies](https://databay.com/proxies/mobile): 800K+ shared rotating 4G/5G carrier-network IPs in 155+ countries with country and continent targeting. The combined pool does not offer carrier or radio-generation selection. Plans from $2.5/GB (512 GB); PAYG $3.55/GB.
- [Residential Flex Proxies](https://databay.com/proxies/residential-flex): 9M+ rotating residential IPs in 90+ countries. Budget tier - country-only targeting, sticky sessions up to 30 min. HTTP, HTTPS & SOCKS5. Flat $0.55/GB. Order range 25–5120 GB, 31-day data validity.

## Pricing
- [Residential Pricing](https://databay.com/proxies/residential/pricing): Pay As You Go is $2.75/GB. Volume tiers: 10GB ($2.25/GB), 50GB ($1.75/GB), 150GB ($1.40/GB), 500GB ($0.95/GB), 1TB ($0.90/GB), custom 1TB+ from $0.65/GB (contact sales). No monthly commitment.
- [Datacenter Pricing](https://databay.com/proxies/datacenter/pricing): One-time packages from $1.25/GB at 10 GB down to $0.5/GB at 1 TB. No monthly commitment.
- [Mobile Pricing](https://databay.com/proxies/mobile/pricing): PAYG $3.55/GB; plans from $2.5/GB at 512 GB. No monthly commitment.
- [Residential Flex Pricing](https://databay.com/proxies/residential-flex/pricing): Flat $0.55/GB. No monthly commitment. Order from 25 GB to 5120 GB.

## Comparisons
- [Residential vs Datacenter Proxies](https://databay.com/proxies/residential-vs-datacenter): Side-by-side comparison of pool size, speed, detection resistance, pricing, and best use cases.
- [Residential vs Mobile Proxies](https://databay.com/proxies/residential-vs-mobile): Compare residential and mobile proxies for trust level, 5G/4G network coverage, and cost-effectiveness.
- [Datacenter vs Mobile Proxies](https://databay.com/proxies/datacenter-vs-mobile): Compare speed-focused datacenter proxies with high-trust mobile proxies.

## Documentation
- [API Reference](https://api.databay.com/swagger/index.html): REST API for proxy management, user creation, and usage tracking.
- [Developer Docs](https://docs.databay.com): Integration guides for Python, Node.js, Go, PHP, Java, and C#.
- [FAQ](https://databay.com/faq): 27 frequently asked questions covering proxies, billing, technical setup, and accounts.

## Use Cases
- [Web Scraping](https://databay.com/proxies/use-cases/web-scraping): Collect data at scale with rotating IPs and geo-targeting.
- [Ad Verification](https://databay.com/proxies/use-cases/ad-verification): Verify ad placements and creatives across geos and devices.
- [Market Research](https://databay.com/proxies/use-cases/market-research): Gather competitive intelligence and pricing data globally.
- [SEO Monitoring](https://databay.com/proxies/use-cases/seo-monitoring): Track search rankings from any location without personalization bias.
- [E-commerce](https://databay.com/proxies/use-cases/ecommerce): Monitor prices, stock levels, and product availability worldwide.
- [Social Media](https://databay.com/proxies/use-cases/social-media): Manage multiple accounts and gather social intelligence.
- [Amazon Scraping](https://databay.com/proxies/use-cases/amazon-scraping): Collect product catalog, pricing, and review data from Amazon at scale.
- [Sneaker Bots](https://databay.com/proxies/use-cases/sneaker-bots): High-trust residential and mobile IPs for limited-release checkouts.
- [Instagram 4G Proxies](https://databay.com/proxies/use-cases/instagram-automation): Compare residential and shared rotating 4G/5G carrier routes for accounts you own or are authorized to manage; no account-trust or platform-access guarantees.
- [Reviews Monitoring](https://databay.com/proxies/use-cases/reviews-monitoring): Track product, seller, and brand reviews across marketplaces.
- [Website Monitoring](https://databay.com/proxies/use-cases/website-monitoring): Monitor uptime, latency, and geo-specific content rendering.
- [Travel Aggregation](https://databay.com/proxies/use-cases/travel): Compare flight and hotel prices across booking platforms from any geo.
- [Cybersecurity](https://databay.com/proxies/use-cases/cybersecurity): Test network defenses and detect vulnerabilities.
- [Brand Protection](https://databay.com/proxies/use-cases/brand-protection): Compare authorized regional observations of public listings, sellers, and trademark use while preserving reproducible evidence for human review.

## Resources
- [Free Proxy List](https://databay.com/free-proxy-list): Live list of HTTP, HTTPS, SOCKS4 and SOCKS5 proxies, verified every 5 minutes on a rolling window. Each record carries ip, port, country name + ISO code, protocol flags, HTTPS/SSL support (strict/loose/none), anonymity level (elite/anonymous/transparent), Google-compatibility flag, latency in milliseconds, lifetime uptime percentage, and last-checked timestamp. Machine-readable files: https://databay.com/free-proxy-list.txt, https://databay.com/free-proxy-list.csv, https://databay.com/free-proxy-list.json. API filters at https://databay.com/api/v1/proxy-list support protocol, country, ssl, google, speed, limit, page and format=json/csv/txt.
- [Free SOCKS5 Proxy List](https://databay.com/free-proxy-list/socks5): SOCKS5-only subset of the free proxy list.
- [Free SOCKS4 Proxy List](https://databay.com/free-proxy-list/socks4): SOCKS4-only subset of the free proxy list, lightweight TCP-only tunnel for legacy clients.
- [Free HTTP Proxy List](https://databay.com/free-proxy-list/http): HTTP-only subset of the free proxy list.
- [Free HTTPS Proxy List](https://databay.com/free-proxy-list/https): Free proxies that tunnel encrypted HTTPS traffic.
- [Free Elite Proxy List](https://databay.com/free-proxy-list/elite): High-anonymity subset - proxies that hide both your IP and proxy usage.
- [Free Anonymous Proxy List](https://databay.com/free-proxy-list/anonymous): Anonymous subset - proxies that hide your IP but may announce proxy usage via headers (permanent filter page).
- [Free Transparent Proxy List](https://databay.com/free-proxy-list/transparent): Transparent subset - proxies that forward your real IP, for caching/testing (permanent filter page).
- [Free Proxy List Directory](https://databay.com/free-proxy-list/directory): A-Z directory of every country-specific free proxy list with live IP counts.
- Plain-text hotlink (stable URL, no params, 5-min refresh, CORS-open): https://databay.com/free-proxy-list.txt - variants: /free-proxy-list/http.txt, /free-proxy-list/https.txt, /free-proxy-list/socks4.txt, /free-proxy-list/socks5.txt, /free-proxy-list/{country}.txt (e.g. /free-proxy-list/united-states-of-america.txt). Static full-list CSV/JSON: https://databay.com/free-proxy-list.csv and https://databay.com/free-proxy-list.json. One IP:PORT per line in TXT; safe to hardcode in scripts and tutorials.
- [Blog](https://databay.com/blog): 43 technical guides on web scraping, proxy usage, anti-detection, and data collection. Atom feed: https://databay.com/blog/feed.xml
- [Proxy Locations](https://databay.com/proxies/locations): Coverage across 200+ countries with per-country IP counts.

## Authors
Every guide and study on databay.com ships under one collective byline; the methodology behind every published number is documented at https://databay.com/trust.
- [Databay Research Team](https://databay.com/trust#research-team): Engineering & Research. The engineering and research group that operates the Databay proxy network, its probe pipelines, and the free proxy list dataset.

## Free Proxy List API Examples
- Full pool as JSON: `curl 'https://databay.com/free-proxy-list.json'`
- SOCKS5 in Germany: `curl 'https://databay.com/api/v1/proxy-list?protocol=socks5&country=DE'`
- Plain-text IP:port pairs: `curl 'https://databay.com/free-proxy-list.txt'`
- Fast Google-reachable: `curl 'https://databay.com/api/v1/proxy-list?google=true&speed=fast&format=csv'`
- Python: `import requests; proxies = requests.get('https://databay.com/api/v1/proxy-list').json()`
- Rate limit: 60 requests/minute per IP (search & AI crawlers exempt). Response cache: 10 s. No API key required.

## Key Guides
- [What Is a Proxy Server?](https://databay.com/blog/what-is-a-proxy-server): Complete beginner's guide to proxy servers, types, protocols, and use cases.
- [How Residential Proxies Work](https://databay.com/blog/how-residential-proxies-work): Technical deep dive into residential proxy architecture, routing pipelines, and IP assignment.
- [Residential vs Datacenter Proxies](https://databay.com/blog/residential-vs-datacenter-proxies): Detailed comparison across trust level, speed, detection rates, ASN classification, and pricing.
- [Web Scraping with Proxies](https://databay.com/blog/web-scraping-with-proxies-guide): Production guide for building reliable, scalable scraping pipelines with proxy rotation.
- [Are Proxies Legal?](https://databay.com/blog/are-proxies-legal-compliance-guide): Legal compliance guide citing Van Buren v. United States, hiQ v. LinkedIn, and CFAA case law.
- [HTTP vs SOCKS5 Proxies](https://databay.com/blog/http-vs-socks5-proxies): Protocol comparison covering speed, authentication, UDP support, and use case recommendations.
- [Ethical Web Scraping Guide](https://databay.com/blog/ethical-web-scraping-guide): Best practices for responsible data collection including robots.txt, rate limiting, and legal frameworks.
- [Static vs Rotating Proxies](https://databay.com/blog/static-vs-rotating-proxies): When to use sticky sessions vs per-request rotation for different scraping scenarios.
- [Proxy vs VPN](https://databay.com/blog/proxy-vs-vpn-differences): Technical differences between proxies and VPNs for privacy, speed, and data collection.
- [TLS Fingerprinting and Proxy Detection](https://databay.com/blog/tls-fingerprinting-proxy-detection): Why a residential IP doesn't save your scraper if your client's JA3 hash says python-requests. First-party JA3/JA4 captures with reproducible methodology.
- [Headless Browser Detection in 2026](https://databay.com/blog/how-sites-detect-headless-browsers): First-party 9-library × CreepJS matrix showing what stealth libs still leak in 2026. CDP-direct and different-engine spoofing outperform all patch-based stealth libraries tested.
- [Residential Proxy IP Reputation in 2026](https://databay.com/blog/residential-ip-reputation-leaderboard): 1,000 residential IPs across 25 of the world's largest residential ASNs, run through six free reputation databases plus a Cloudflare-Free cross-verification origin. The malice-focused feeds (Tor exit list, Spamhaus DROP, ASN drop) returned 0% across all 1,000 IPs. Spamhaus ZEN flagged 80.3% of the IPv4 sample, dominated by PBL response codes (the residential-policy designation). Cloudflare Free's legacy cf.threat_score returned 0 for every capture, confirming the reputation logic moved entirely into the paid Bot Management product. Includes a /24-redacted CSV at /data/residential-ip-reputation-2026-05.csv.
- [Integrations](https://databay.com/integration): Integration guides for Puppeteer, Selenium, Playwright, Scrapy, and more.
- [What Is My IP](https://databay.com/what-is-my-ip): Free tool to check your current IP address and location.

## Company
- [About Databay](https://databay.com/about): Company overview, who writes this site, compliance stance, and contact methods.
- [Trust & Methodology](https://databay.com/trust): IP sourcing ethics, consent model, IP-reputation research, compliance and status links.
- Founded: 2022
- Legal entity: WATTENNE INTERNATIONAL LLC
- Registered address: 30 N Gould St Ste N, Sheridan, WY 82801, USA (Wyoming registered-agent address)
- Contact: support@databay.com (customer service), sales@databay.com (enterprise)
- Languages: English, French, Spanish, Russian

## Legal & Compliance
- [Legal Hub](https://databay.com/legal): Index of every Databay legal document - terms, privacy, refund, SLA, AML and KYC policies.
- [Privacy Policy](https://databay.com/legal/en-us/privacy-policy): What data Databay collects, how it is used, and your rights.
- [Terms of Use](https://databay.com/legal/en-us/terms-of-use): The service agreement governing every Databay account.
- [Acceptable Use Policy](https://databay.com/legal/en-us/acceptable-use-policy): The acceptable-use rules enforced across the proxy network.
- [Report Abuse](https://databay.com/legal/abuse): How to report misuse of Databay infrastructure; abuse reports are investigated and acted on.

## Optional
- [Status Page](https://status.databay.com): Real-time network status and uptime monitoring.
- [Trustpilot](https://www.trustpilot.com/review/databay.com): Customer reviews.
- [G2](https://www.g2.com/products/databay/reviews): Enterprise software reviews.

## Key Facts
- Free proxy list refresh cadence: every 5 minutes (rolling window). Entries older than 6 hours are auto-dropped.
- Free proxy list pool size: typically 5,000-7,000 live verified proxies across 100+ countries.
- Free proxy list protocols: HTTP, HTTPS, SOCKS4, SOCKS5.
- Free proxy list machine-readable fields: ip, port, country, iso, protocol, ssl (strict/loose/none), anonymity (elite/anonymous/transparent), google, latency, uptime, lastChecked.
- Free proxy list API base: https://databay.com/api/v1/proxy-list
- Free proxy list hotlinks (stable, no params, CORS-open): https://databay.com/free-proxy-list.txt, https://databay.com/free-proxy-list.csv, https://databay.com/free-proxy-list.json, /free-proxy-list/http.txt, /free-proxy-list/https.txt, /free-proxy-list/socks4.txt, /free-proxy-list/socks5.txt, /free-proxy-list/{country}.txt
- Paid network: 34M+ residential IPs, 800K+ mobile 5G/4G IPs, 80K+ datacenter IPs across 200+ countries.
- Paid pricing: flat $0.55/GB residential Flex; datacenter from $1.25/GB at 10 GB (volume floor $0.5/GB at 1 TB); $2.75/GB residential Pay As You Go (custom 1TB+ residential from $0.65/GB, contact sales); $2.5/GB mobile.

## Full text: blog articles

Complete plain-text content of every published article on https://databay.com/blog, newest first. Markup, code samples, and interactive labs are reduced to text; each article links its canonical URL.

### Ad Verification With Proxies: A Controlled QA Workflow
URL: https://databay.com/blog/how-to-do-ad-verification-with-proxies
Author: Databay Research Team. Published: 2026-08-09. Updated: 2026-08-09.

Run authorized ad verification with proxies using platform previews, one controlled regional variable, a reviewable record, and clear stop conditions.

#### Start With the Question a Proxy Can Answer
To do ad verification with proxies safely, define one authorized regional question, use the advertising platform's own preview and reporting tools first, and add a proxy only when network origin is the remaining variable. A suitable question is, "What did this approved test surface return from the requested network region under these recorded conditions?" It is not, "What did every person in that location see?"
A proxy can change the apparent network origin of a request. It does not set physical location, audience membership, auction eligibility, account history, consent, device identity, app state, budget, frequency caps, or experiments. It also cannot guarantee that an ad will serve. If the unresolved task is choosing a network class and evaluating a provider, use the broader ad verification proxy guide; this tutorial concentrates on executing and documenting one controlled QA run.

#### Write the Authorization and Expected Result Before Testing
Give every run a named owner and a written scope. Record the campaign, creative, publisher or platform surface, approved markets, permitted test account or logged-out state, test window, data-retention period, and escalation contact. State whether the team owns the campaign and destination or has explicit authorization from the advertiser, agency, publisher, or platform partner.
Define the expected result before opening a browser: creative ID, language, currency, offer, landing domain, permitted redirect domains, device class, and market. A test with no expected result can collect screenshots, but it cannot distinguish a valid variant from a defect. Confirm campaign status, targeting, budget state, creative approval, and publisher configuration in primary platform records before attributing a difference to geography.
Regional ad QA preflight recordDecisionRecord before the runDo not proceed when
AuthorityOwner, approval reference, surfaces, accounts, and marketsOwnership or permission is unclear
Expected deliveryCampaign, creative, language, offer, currency, and destinationNo primary record defines the expected result
InteractionPreview, sandbox, test creative, or direct owned destinationThe plan requires a live ad click or manufactured engagement
EvidenceAllowed fields, screenshot policy, storage, reviewers, and deletion dateSensitive data would be collected without a defined need
Request budgetSmall source-wide limit shared by every worker and exitThe plan treats each proxy IP as a separate quota

#### Use the No-Click Evidence Ladder
Use the least invasive source that can answer the question. Google's Ad Preview and Diagnosis tool can show and diagnose eligible Search ads without a normal live search; Google says this avoids accumulating ad impressions and affecting performance statistics. For supported public-ad research, Meta documents its Ad Library. Publisher previews, campaign reports, ad-server logs, SDK telemetry, sandboxes, and test creatives are also stronger starting evidence than an uncontrolled public render.
No-click evidence ladder for an authorized campaign checkOrderMethodQuestion it can answerOutput
1Campaign and publisher configurationWhat was configured, approved, and scheduled?Primary expected-result record
2Platform preview or diagnosisWhat can the platform preview or explain without a live search?Preview and diagnostic evidence
3Transparency library or publisher previewWhat supported public creative or placement record exists?Platform-controlled observation
4Sandbox, test creative, or direct owned destinationDoes the approved creative and landing path render correctly?Controlled functional result
5Bounded proxy-routed test surfaceDoes one authorized surface vary when only network origin changes?Regional network observation

Stop as soon as a higher rung answers the question. A no-click rule does not imply that loading any live ad is consequence-free: a render can still create an impression or other platform event. Google lists clicks and impressions from automated tools, bots, spiders, and crawlers among forms of invalid traffic. Use a live surface only when the owner has provided an approved test method; never click an ad, generate engagement, or automate live impressions for realism.

#### Change One Variable in a Controlled Matrix
A regional comparison is interpretable only when the test changes one declared variable. Pin the campaign, source surface, direct URL, browser and device profile, language, time window, account state, consent state, and expected creative. Then request the required proxy region or network class and record the exit that was actually observed. Do not add stealth plugins, fingerprint spoofing, synthetic accounts, or invented user behavior.
Controlled-variable matrix for one regional comparisonVariableControlEvidence to retainInterpretation limit
Campaign and creativeKeep fixedCampaign ID, creative ID, approval and active stateAuction or experiment logic may still return a variant
Surface and URLKeep fixedPreview, test surface, or direct owned URLDifferent publishers are not a regional control pair
Time windowKeep narrowUTC timestamps and campaign scheduleBudget and auction conditions can change between runs
Browser and device profileKeep fixedClient and version, viewport, operating-system classA browser profile is not a complete real device
Account and consentKeep fixedApproved test-account or logged-out state and consent choiceDo not clone a person's identity or private state
Language and currency settingsKeep fixed unless they are the hypothesisRequest headers and application settingsIP region does not set every localization input
Proxy network originChange only as definedRequested region, observed region, network class, and ASN where neededGeolocation is an estimate, not proof of physical presence
OutcomeMeasureRendered variant, status, redirect path, final URL, and classificationOne result is not a population estimate

#### Run One Bounded Regional Sample
Assign the test ID. Link it to the authorization reference, owner, approved surface, market, and deletion date.
Confirm the primary evidence. Recheck campaign state and the platform preview, report, sandbox, or publisher test result.
State the remaining hypothesis. Proceed only if network origin is the unresolved variable.
Prepare one declared client profile. Use the approved account or logged-out state, language, consent, device class, and direct test URL. Keep credentials outside code, screenshots, and logs.
Verify the route separately. Confirm the requested and observed exit region through a provider diagnostic or an endpoint the team controls, without involving the advertising surface.
Open the approved test surface. Use a preview, sandbox, test creative, or direct owned destination. Do not click a live ad or traverse an unapproved tracking link.
Capture the evidence record. Store the status, rendered variant, permitted redirect sequence, final URL, timestamp, context, and classification.
Stop after the predefined sample. If one small corroborating run is authorized, repeat with the same controls. Do not keep changing exits until the expected creative appears.

Apply the request budget to the destination and logical test, not independently to each proxy address. Rotation is not an authorization mechanism, a new quota, or a remedy for a denied request. The objective is a reviewable observation, not maximum request volume.

#### Copy the Evidence Record Before the Run
Create the record before testing so inconvenient fields are not omitted after the result is known. Use internal identifiers rather than personal names, redact credentials and tracking parameters, and store screenshots or response hashes only when the campaign owner permits them.
{
"testId": "qa-2026-08-09-001",
"authorizationRef": "owner-ticket-or-contract-reference",
"campaignId": "campaign-id",
"creativeId": "creative-id",
"surface": "platform-preview-or-approved-test-surface",
"targetMarket": "country-or-city-in-scope",
"expectedResult": {
"creative": "approved-variant",
"language": "expected-language",
"currency": "expected-currency",
"landingDomain": "owned.example"
},
"testContext": {
"requestedProxyRegion": "requested-region",
"observedExitRegion": "observed-region",
"proxyClass": "residential-mobile-or-datacenter",
"deviceProfile": "declared-profile-and-version",
"accountState": "approved-test-account-or-logged-out",
"consentState": "declared-state",
"timestampUtc": "2026-08-09T00:00:00Z"
},
"observation": {
"status": 200,
"redirects": [],
"finalDomain": "owned.example",
"renderedVariant": "observed-variant",
"evidenceRef": "restricted-screenshot-or-hash-reference"
},
"classification": "expected-variant-missing-challenged-or-inconclusive",
"reviewerNote": "bounded interpretation without personal data",
"retentionUntil": "approved-deletion-date"
}
A screenshot alone cannot show the requested proxy setting, observed exit, account and consent context, status, redirects, or expected campaign configuration. Store the record and evidence together so another authorized reviewer can reproduce the conditions without receiving raw proxy credentials, session cookies, or personal data.

#### Classify the Result Without Overclaiming
Use a small fixed taxonomy rather than converting every difference into a targeting failure. Redirects should be recorded hop by hop with their status and permitted domain. RFC 9110 defines HTTP response and redirection semantics, but an HTTP status cannot establish whether an advertising outcome is commercially correct, fraudulent, or representative.
Five-state regional ad observation taxonomyClassificationMeaningNext action
ExpectedThe approved test returned the predefined variant under the recorded conditionsClose the test; do not generalize it to every eligible user
VariantA different but complete creative, offer, language, or path appearedCheck experiments, auction rules, campaign reports, and publisher evidence
MissingNo ad or expected creative appeared on the approved test surfaceReview eligibility, budget, schedule, targeting, and primary platform diagnostics
ChallengedA block, CAPTCHA, login wall, rate limit, or other access control replaced the observationStop; do not rotate or change client identity to continue
InconclusiveThe controls, route, evidence, or expected result were incompleteCorrect the test design before any authorized rerun

Escalate a material variant only after corroborating it with campaign configuration, platform or ad-server reporting, publisher evidence, and another permitted controlled observation where appropriate. Report what the test received, not what an entire market supposedly saw.

#### Know What Proxy Evidence Cannot Establish
The IAB Guidelines for the Conduct of Ad Verification address a broader measurement discipline than regional network sampling. A proxy observation can contribute evidence about one approved request path, but it cannot establish viewability, human attention, audience identity, reach, conversion validity, or whether a click or impression was fraudulent.
It does not prove physical location. The requested region and an IP-geolocation result describe network routing and a database estimate, not the position of a person or device.
It does not reproduce a real user. Account history, cookies, consent, audience membership, device identifiers, app state, experiments, and auction conditions remain separate.
It does not turn a carrier route into a phone test. A mobile proxy does not supply a handset, advertising ID, app installation, GPS state, or SDK telemetry.
It does not guarantee serving. An eligible campaign may not appear in one sample, and a returned creative may be one valid auction or experiment outcome.
It does not prove fraud or viewability. Those findings require appropriate platform and ad-server logs, event and device evidence, measurement controls, and qualified review.

Use the narrow sentence, "This approved test received this result under these recorded conditions." Keep uncertainty and alternative explanations in the report.

#### Minimize Data and Set a Deletion Date
Collect only what the stated QA decision needs. Keep proxy usernames and passwords, session cookies, authorization tokens, personal identifiers, complete tracking parameters, and unrelated page content out of the evidence record. Restrict raw screenshots and redirect details to reviewers who need them, because creatives, URLs, account state, and page content can expose confidential campaign information or personal data.
Document where evidence is stored, who can access it, whether encryption is required, when it will be deleted, and how a campaign owner can request correction or removal. Redact or hash identifiers when the full value is unnecessary, and never put secrets in a URL, filename, analytics event, or shared ticket. Keep the workflow within the campaign owner's policies, applicable platform and publisher rules, and Databay's Acceptable Use Policy. Obtain qualified privacy or legal review when the test could involve personal data, regulated markets, cross-border transfers, or contractual uncertainty.

#### Stop on Controls, Ambiguity, or Unapproved Interaction
Write the stop policy into the test ticket and automation before the first request. Stop when ownership or authorization is unclear; the only path requires a live ad click or manufactured impression; the observed exit does not match the requested test condition; a 401, 403, 429, CAPTCHA, login wall, block, or publisher objection appears; unexpected personal or sensitive data is exposed; the source-wide request budget is exhausted; or the evidence cannot be stored under the approved retention plan.
Do not respond by rotating exits, changing accounts, disguising the client, replaying an ambiguous interaction, or increasing volume. A different IP does not repair permission, reset a destination's source-wide limit, or make an invalid test valid. Classify the result as challenged or inconclusive, preserve the minimum diagnostic record, notify the named owner, and use the platform, publisher, or contractual support path.

#### Turn a Successful Run Into a Measurable Pilot
If the no-click evidence ladder leaves a legitimate regional network question and the bounded run succeeds, pilot only the network origins and locations the campaign actually requires. Measure observed exit match, usable authorized observations, latency, challenged and inconclusive rates, complete transferred bytes, review time, and cost per accepted evidence record. Do not select a plan from pool size or a promise of universal destination access.
Residential, mobile, and datacenter routes represent different network origins, not progressively more authentic users. Choose from the documented hypothesis and measured results, keep the same stop policy at scale, and rerun the source and privacy review when the campaign, publisher, market, account state, or data fields change. The ad verification proxy workflow explains the network-choice criteria and how to evaluate Databay after platform evidence has been exhausted.

#### FAQ
Q: How do you do ad verification with proxies?
A: Define an authorized regional question and expected result, use platform previews and primary reports first, hold the client and campaign context fixed, change only the required proxy network origin, capture a complete evidence record, and stop after the approved sample.
Q: Can I check a Google Search ad without adding normal impressions?
A: Google says its Ad Preview and Diagnosis tool is preferable to conducting a live search because it can show and diagnose ads without accumulating impressions or affecting performance statistics. Use it before any proxy-routed test.
Q: Should an ad verification test click a live ad?
A: No. Use a platform preview, sandbox, publisher test mode, test creative, or direct owned destination. Do not create clicks, impressions, or other engagement to make a test resemble a real user.
Q: Can an ad verification proxy prove click or impression fraud?
A: No. A proxy can contribute one regional network observation. Fraud or invalid-traffic findings require appropriate platform and ad-server logs, event and device evidence, measurement controls, and qualified review.
Q: Does a proxy IP prove that the test was physically in the target location?
A: No. It records a requested network route and an observed IP-geolocation estimate. It does not prove the physical position, identity, device, or audience membership of a person.
Q: Which variables should stay fixed during regional ad QA?
A: Keep the campaign, creative expectation, test surface, direct URL, time window, browser and device profile, language, account state, and consent state fixed. Change only the declared proxy region or network class, then record the observed exit.
Q: What should an ad verification evidence record contain?
A: Record the authorization reference, test and campaign IDs, expected result, surface, requested and observed region, proxy class, UTC time, client and account context, status, permitted redirects, final domain, rendered variant, evidence reference, classification, reviewer note, and deletion date.
Q: When should proxy-based ad verification stop?
A: Stop on unclear authorization, required live interaction, an exit mismatch, 401, 403, 429, CAPTCHA, login wall, block, publisher objection, unexpected sensitive data, an exhausted request budget, or an evidence-retention conflict. Do not rotate to continue.

### Rotating Proxy Free Trials: Buyer Test Checklist
URL: https://databay.com/blog/rotating-proxy-free-trial-checklist
Author: Databay Research Team. Published: 2026-08-09. Updated: 2026-08-09.

Use a controlled proxy-trial scorecard to test rotation, sticky sessions, usable responses, billing, support, and stop conditions before buying.

#### The Short Answer: Test the Service You Would Buy
A useful rotating proxy free trial should let you test the same pool, gateway, targeting, session controls, protocols, and support path that the paid plan uses. If the trial is a separate pool, hides its traffic cap, excludes the locations you need, or cannot reproduce the intended session mode, a successful test does not establish production fit.
Write the pass criteria before creating an account. Test only systems you own or are explicitly authorized to assess. Keep one destination-level request budget across every exit, and treat a block, challenge, login boundary, or unapproved rate limit as a stop signal rather than a reason to rotate. The result should be a decision record, not a collection of screenshots showing that one request worked.
Fast trial qualificationQuestionAcceptable evidenceReject or clarify when
Is the trial production-representative?Written confirmation of the pool, gateway, protocols, targeting, session controls, and service protectionsThe provider calls it representative but will not identify material differences
Can it test the real workload?Enough traffic and time for a small, bounded sample with the intended response sizesThe cap supports only an IP-check page or expires before normal variance can be observed
Are failures diagnosable?Client logs, status classes, exit observations, usage records, and a reachable support pathEvery failure is described as a bad IP with no hop-level evidence
Are the commercial terms visible?Paid price, minimum, expiry, billing unit, overage, cancellation, and refund terms captured on the test datePayment details appear only after the test or conflict across pages

#### A Free Trial and a Small Paid Pilot Answer Different Questions
A free trial lowers the cost of initial qualification, but the word free says nothing about representativeness. A provider may use a limited pool, fewer countries, lower concurrency, a different traffic cap, or a short expiry. A small paid pilot costs money but can be more informative when it uses the real plan and the same support and billing systems.
Free trial versus paid pilotDimensionFree trialSmall paid pilot
Cash costZero if no card, deposit, or automatic conversion is requiredKnown entry purchase
Production parityMust be verified; restrictions can make it a different productUsually stronger when the purchased package is the production product
Time and trafficOften capped tightly; record bothDefined by the purchased quota and validity period
Billing evidenceMay not expose metering, invoices, overage, or expiry behaviorCan verify the real usage ledger and purchase flow
RiskAutomatic conversion, card authorization, or unclear cancellation can create costEntry spend and refund restrictions are known before testing

Do not treat a public free proxy list as a commercial product trial. Public endpoints can have unknown operators, authorization, logging, capacity, and maintenance. They do not demonstrate the sourcing, controls, support, or performance of a managed rotating service.

#### Capture the Trial Contract Before Sending Traffic
Save the offer page and current terms before the test begins. Record the provider, product name, test start and end, included traffic, countries, protocols, rotation rule, sticky duration, concurrency or request limits, account requirements, support channel, paid-plan price, minimum order, automatic conversion, cancellation path, data retention, and refund rule. A trial that asks for a card is not necessarily deceptive, but the conversion date, amount, and cancellation mechanism must be explicit.
Ask whether uploads, response headers, failed responses, retries, browser assets, and protocol overhead count toward the traffic cap. Ask whether the same usage meter will exist in production and how quickly it updates. If a location or network class is critical, confirm that it is in the trial rather than assuming that a global pool label includes it.
Production-parity question: list every material difference between this trial and the paid plan we would purchase. If the provider cannot answer in writing, label the result as a trial-only observation.

#### Build a Bounded Test Around One Authorized Workload
Use the smallest sample that can disprove the design. Do not spread a tiny allowance across many unrelated destinations, because the result will explain none of them. Choose an endpoint you control or may test, one real client, one region, representative payloads, and the intended concurrency range.
State the job. Write the destination, authorization basis, logical task, expected response, region, session requirement, and maximum source-wide request budget.
Pin the client path. Record the client and version, proxy protocol, gateway, authentication, DNS mode, TLS verification, timeout, connection reuse, and retry policy.
Measure a direct baseline. Capture status, response identity, connect time, TLS time, time to first byte, total time, and complete request-plus-response bytes without the proxy.
Run a low-concurrency proxy sample. Log a redacted task ID, timestamp, observed exit, country estimate, ASN, status, timings, bytes, and validation outcome for every logical task.
Increase only to intended load. Use bounded stages and stop when errors or latency materially change. A stress test is not authorized merely because the provider allows more connections.
Exercise one safe transient failure. On an endpoint you control, verify that a replay-safe request follows the documented retry cap and backoff. Do not manufacture failures against a third party.
Reconcile the meter. Compare client-observed complete bytes with the provider usage ledger and document the billing convention.

The Databay proxy checker can make a point-in-time liveness, protocol, latency, and exit observation. It cannot establish future availability or replace a test in the production client.

#### Verify Rotation and Sticky Sessions Separately
Rotation and stickiness are different service behaviors. A rotating gateway can choose an exit per new connection, request, time window, or provider rule. HTTP connection reuse can keep several requests on one connection, so repeated exits do not by themselves prove that rotation failed. A sticky session requests temporary continuity; it is not a dedicated or permanently static address.
For rotation, open a documented sequence of new connections to a diagnostic endpoint you control and record the observed exit each time. Report both the number of requests and the number of distinct exits; do not promise uniqueness. For stickiness, use one session token, verify the exit at the beginning and during the intended flow, then test the documented boundary without forcing an outage. Record whether the same exit persisted, whether connections changed, and what happened after the session expired or the exit became unavailable.
The static versus rotating proxy guide separates exit persistence from cookies, application state, allocation, and connection reuse. A trial score should not award points for rapid IP changes when the real workflow needs stable state.

#### Score Usable Outcomes, Not Raw HTTP Success
An HTTP status alone is not the business result. A 200 response can contain an error template, stale content, the wrong region, a consent page, or an incomplete payload. Validate the expected record or action and classify every other outcome.
Rotating proxy trial scorecardMetricHow to calculate itEvidence to keep
Usable-response rateValidated outputs divided by logical tasksValidation rule plus raw counts for usable, invalid, blocked, challenged, and transport-failed tasks
Latency distributionMedian, p95, and p99 for connect, TLS, first byte, and total timeAll attempts, including failure timeouts; never calculate only from successes
Exit coverageObserved valid exits by required country and network classIP, ASN, geolocation source, timestamp, and requested target
Session continuityFlows completed without unintended exit change divided by attempted flowsSession token hash, exit sequence, connection reuse, and expiry behavior
Billable efficiencyComplete billable GB divided by validated outputsClient bytes, provider meter, retries, failures, and billing convention
Support resolutionIssues correctly classified and resolved inside the required windowRedacted ticket, first response, diagnosis, remedy, and unresolved questions

cost per usable output = complete billable cost / validated outputs + engineering and support cost per output
Publish the sample size and test window next to any percentage. A ten-request trial is evidence about ten requests under recorded conditions, not a universal provider success rate.

#### Classify Failures Before Retrying
A rotating pool must not turn a small retry allowance into a new budget for every exit. RFC 9110 defines HTTP semantics and warns intermediaries against automatically retrying non-idempotent requests. RFC 6585 defines 429 Too Many Requests and permits a Retry-After field. When an intermediary sends it, RFC 9209 defines Proxy-Status details for classes such as DNS, connection, and timeout failures.
Failure boundary for a safe trialSignalLikely boundaryTrial action
Proxy 407Gateway authentication or account policyStop and fix credentials; a different exit cannot repair authentication
DNS, connect, or TLS failure before a destination responseClient, proxy, network route, or destination transportClassify the hop; retry only replay-safe work inside one small total budget
429Destination rate policyHonor Retry-After and the source-wide quota; never rotate around it
401, 403, challenge, or account restrictionAuthorization or destination controlStop and use the official permission, recovery, or support path
Ambiguous non-idempotent resultThe request may have taken effectDo not replay automatically; reconcile application state first

#### Compare the Paid Plan With the Same Workload
Translate the trial result into the paid plan before declaring a winner. Use the quoted price and minimum that apply to the expected volume, not the lowest headline tier. Include billable uploads and downloads, invalid responses, permitted retries, plan minimums, traffic expiry, location fees, support, taxes, and engineering time. If a trial used a different pool or cap, keep that uncertainty visible.
Compare providers on cost per usable output at the same workload. A lower price per GB can lose when more billable traffic, validation failures, or engineering time are required. A higher price can also lose when the route adds no evidence or capability over the direct or official path. The procurement decision should name the required network origin, locations, protocols, session behavior, service protections, data handling, support window, and maximum all-in cost.

#### Databay Disclosure: There Is No Free Trial
Databay does not offer a free trial, and the free proxy list is not a trial of the paid network. The smallest standard residential order is 1 GB at $2.75/GB with 186-day validity. The smallest mobile order is 1 GB at $3.55/GB with 31-day validity. The datacenter entry package is 10 GB at $1.25/GB with 31-day validity. These are one-time purchases rather than subscriptions.
Use the relevant residential, mobile, or datacenter pricing page to confirm the current package before paying. Databay's Refund Policy is narrow: it describes a seven-day request window, a 100 MB usage cap for the contractual exception, technical verification, and exclusions including third-party blocks. Read the live policy rather than treating a paid pilot as risk-free.
A Databay pilot should follow the same scorecard as a free trial: one authorized workload, precommitted limits, complete usage measurement, explicit stop conditions, and a scale decision based on usable outputs. The absence of a free trial is a commercial difference, not evidence that the service will or will not fit the workload.

#### Make a Buy, Reject, or Retest Decision
End the trial with one of three decisions. Buy only when the tested product is production-representative and meets every required threshold inside the full paid cost. Reject when a mandatory location, protocol, session behavior, security control, support requirement, or cost threshold fails. Retest only when a specific evidence gap can be closed with a bounded test; do not extend a trial indefinitely until a favorable result appears.
Decision recordFieldWhat to write
Authorized workloadDestination, permission basis, logical task, volume, and retention
Required service propertiesNetwork origin, locations, protocol, session mode, capacity, security, support, and data handling
Observed evidenceSample size, time window, usable outcomes, latency distribution, exit behavior, bytes, failures, and tickets
Production differencesEvery known difference between the trial and proposed paid plan
All-in economicsMinimum order, price tier, billable usage, expiry, operations, and cost per usable output
Decision and ownerBuy, reject, or one scoped retest; approver and review date

Keep the test within the destination's rules and Databay's Acceptable Use Policy. A trial is permission to evaluate a provider account, not permission to test any third-party system.

#### FAQ
Q: What should a rotating proxy free trial include?
A: It should disclose the traffic and time limits and let you test the paid plan's pool, gateway, protocols, locations, rotation rule, sticky sessions, usage meter, service protections, and support path. Record every material difference from production.
Q: How many requests are enough for a proxy trial?
A: There is no universal count. Use the smallest bounded sample that can disprove the design for one authorized workload, and report raw sample sizes with usable-response rates and latency distributions. Do not increase traffic merely to make a percentage look stable.
Q: How do I test whether rotating proxies actually rotate?
A: Open a documented sequence of new connections to a diagnostic endpoint you control, then record the observed exit for each. Account for HTTP connection reuse and the provider's stated rotation boundary; repeated exits do not automatically mean failure, and every request need not be unique.
Q: Should a rotating proxy trial retry a 403 or 429 with another IP?
A: No. Stop on 401, 403, challenges, and account restrictions. For 429, honor Retry-After and the source-wide quota. A new exit does not create authorization or a fresh request allowance.
Q: Is a free proxy list the same as a rotating proxy free trial?
A: No. A public list can contain endpoints with unknown operators, authorization, logging, capacity, and maintenance. It does not test a managed provider's paid pool, controls, sourcing, support, metering, or contractual terms.
Q: Does Databay offer a rotating proxy free trial?
A: No. Databay offers one-time paid packages instead of a free trial. The smallest standard residential and mobile orders are 1 GB, while the datacenter entry package is 10 GB. Confirm current prices, validity, and refund terms on the product and legal pages before purchasing.
Q: What is the most useful proxy trial metric?
A: Cost per validated output is more useful than raw success or price per GB. Calculate it from complete billable traffic, usable-response rate, permitted retries, plan minimums, and the engineering and support effort needed to produce a correct result.

### Shared vs Dedicated Proxies: Allocation, Control, and Cost
URL: https://databay.com/blog/shared-vs-dedicated-proxies
Author: Databay Research Team. Published: 2026-08-09. Updated: 2026-08-09.

Compare shared and dedicated proxies by allocation, persistence, network origin, measured performance, and normalized workload cost.

#### The Short Answer: Allocation Is the Difference
A shared proxy is an outbound address or pool that more than one authenticated customer may use. A dedicated proxy is allocated to one customer under the provider's contract. Those labels describe allocation, not whether an address rotates, which network announces it, which client protocol reaches it, or whether a destination will accept it.
Start with a shared service when permitted requests are independent, a provider-managed pool fits the job, and measured cost per usable result is acceptable. Require a dedicated allocation when a system you control must allowlist a known source, one customer must be accountable for the address, or written capacity and replacement terms are operational requirements. Neither model is the universal winner: the correct answer comes from the requirement, contract, and a controlled pilot.
Fast allocation decisionRequirementStarting candidateEvidence required before purchase
Independent authorized observations with no fixed-IP dependencyShared poolUsable-response rate, latency distribution, exit coverage, contention at intended load, and billable traffic
Owned endpoint allowlists one auditable source addressDedicated static allocationWritten exclusivity, replacement notice, failover address, capacity, and routing behavior
Short workflow needs one exit temporarilySticky session may be sufficientObserved continuity window and behavior after exit failure; stickiness is not dedication
Official API, feed, export, or direct route already satisfies the taskNo proxy firstDocumented interface, quota, authorization, and total operating cost

#### Shared and Dedicated Are Product Labels, Not Protocol Standards
The Internet standards that define proxy-related HTTP behavior do not create commercial categories called "shared proxy" and "dedicated proxy." RFC 9110 defines HTTP semantics and intermediary roles, including proxies and tunnels. RFC 9112 defines HTTP/1.1 messaging and connection persistence. Neither standard promises customer exclusivity, an address lifetime, a pool size, a performance level, or a billing model.
The provider's current contract and technical documentation therefore control the allocation meaning. Ask whether "dedicated" applies to the public exit address, a port, a gateway, a subnet, or only an account entitlement. Ask whether other customers can send traffic through the same exit, whether the address can change after failure or review, and whether upstream capacity is reserved. For a shared service, ask how the provider authenticates customers, schedules capacity, handles unhealthy exits, reports incidents, and applies service protections.
Procurement rule: treat an allocation adjective as a claim to verify, not as a protocol feature. Record the exact resource, allocation period, replacement rule, and evidence the provider will supply.

#### Separate Allocation, Persistence, Origin, and Protocol
A useful comparison keeps four independent axes in the decision record. Collapsing them into one label creates false conclusions such as "dedicated means static residential" or "shared means rotating HTTP." Both statements can be wrong.
Four independent proxy propertiesAxisQuestion it answersExample valuesWhat it does not prove
AllocationWho may use the resource?Shared among authenticated customers; dedicated to one customer; unspecifiedAddress persistence, network origin, protocol, speed, or destination acceptance
PersistenceHow long should the exit remain the same?Per connection, rotating, time-bound sticky, static until replacementWhether another customer may also use it
Network originWhich network announces the exit?Datacenter, ISP, residential, mobileAllocation or session duration
Client protocolHow does the client reach the proxy?HTTP forwarding, HTTP CONNECT, SOCKS5Who owns the exit or where DNS runs in every client

The static versus rotating proxy guide covers persistence and session state. The HTTP versus SOCKS5 comparison covers client-to-proxy protocol and DNS behavior. Allocation remains a separate contractual question.
Application state is separate again. RFC 6265 describes cookies exchanged between an origin and a user agent. Two customers using a shared exit do not thereby share browser cookie jars, account tokens, or local storage; those remain client and destination state. Conversely, buying a dedicated address does not erase or isolate application state unless the client and application architecture do so.

#### A Shared Proxy Is Not Automatically Free or Public
"Shared" says that multiple customers may use a managed resource. It does not mean that anyone on the internet can connect without authentication. A commercial shared service can require an account, credentials, payment, plan limits, abuse controls, published support channels, and contractual data-handling terms.
A free or public proxy is a different risk question. Its operator, authorization to relay traffic, logging, capacity, maintenance, and security controls may be unknown. The free-proxy safety guide explains how to verify ownership and behavior before sending any traffic. Do not send credentials, personal data, private source material, or business-sensitive requests through an unverified intermediary.
Nor does paid sharing create a confidentiality guarantee by itself. Review how credentials are protected between client and gateway, whether destination TLS validation remains enabled, what metadata the operator retains, who can access it, and when it is deleted. The allocation model is only one line in that review.

#### Compare Measurable Tradeoffs, Not Universal Claims
A shared pool can expose a workload to changing exits, variable address history, and capacity used by other customers. A dedicated allocation can make address ownership, allowlisting, incident review, and route continuity easier to reason about. None of that proves that every shared proxy is slower or that every dedicated proxy has better reputation.
Observed performance depends on the gateway, exit, route distance, upstream capacity, destination, payload, client, DNS mode, connection reuse, concurrency, time window, and provider operations. Address treatment also depends on the destination's policy and evidence beyond the source IP. A dedicated address can begin with poor classification or acquire a history from the customer's own traffic. A well-operated shared pool can perform consistently for a compatible workload. Measure both under the same permitted test.
Metrics for a comparable proxy pilotMetricHow to record itWhy the average alone is insufficient
Usable-response rateValidated outputs divided by logical tasks, with failures classifiedAn HTTP 200 can contain an error page, stale result, or wrong region
LatencyMedian, p95, and p99 connect, TLS, first-byte, and total timeA mean hides tail delays and failure timeouts
Exit behaviorObserved IP, ASN, region estimate, reuse, and replacement timestampsA plan label does not prove uniqueness or continuity
CapacityUsable results and latency at several bounded concurrency levelsA single-request speed test does not reveal saturation
Error phaseGateway authentication, DNS, connect, TLS, intermediary, destination, or validationChanging the address cannot repair every failure class
Billable workloadComplete upload and download bytes, including permitted retries and failed responsesPayload size alone understates traffic cost

When an intermediary emits Proxy-Status, RFC 9209 defines structured details for errors such as DNS, connection, and timeout failures. Use the field when present, but do not assume every intermediary implements it or that its report replaces client and destination logs.

#### What Dedicated Control Can and Cannot Buy
A dedicated public exit is valuable when exclusivity itself satisfies a documented requirement. An owned service may allowlist it. A security team can associate outbound events with one customer. An incident process can quarantine one address without affecting unrelated customers. A contract may reserve capacity or define replacement and notification.
Exclusivity still has boundaries. The gateway hostname can be shared even when the public exit is dedicated. Routers, transit links, hosting infrastructure, and upstream providers remain shared systems. A static address can be replaced after maintenance, abuse review, routing change, or failure. A dedicated address does not guarantee unlimited concurrency, destination acceptance, anonymity, low latency, a particular geolocation, or immunity from blocks.
Before relying on the allocation, obtain written answers to these questions:
Is the public exit address exclusive to one customer, and for what period?
Can the provider or an upstream party originate other traffic through it?
Is the address fixed, and what events permit replacement?
How are replacement and failover communicated before an allowlist breaks?
What bandwidth, concurrency, port, protocol, and destination restrictions apply?
Are traffic, failed responses, uploads, setup, replacement, and support billed separately?
Which logs prove allocation and incidents, and how long are they retained?

#### Run a Controlled Pilot Before Choosing
Test the smallest workload that can disprove the proposed design. Use systems you own or are explicitly authorized to assess. Keep the client, destination, region, payload, connection policy, concurrency schedule, timeout, and validation rules the same for every candidate.
Write the requirement first. State whether the job needs exclusivity, a fixed allowlisted address, temporary continuity, a particular network origin, or simply usable independent requests.
Record the commercial terms. Capture the quoted allocation, billing unit, minimum order, included traffic, validity, replacement, support, and cancellation terms on the test date.
Pin the client path. Record client and version, proxy protocol, DNS mode, TLS verification, gateway, authentication method, connection reuse, and session settings.
Establish a direct baseline. Against an authorized endpoint, record response identity, status, connect and TLS timing, first byte, total time, and bytes without the proxy.
Exercise representative load. Run bounded stages rather than a burst. Measure several concurrency levels, include actual response sizes, and preserve one total retry budget for each logical task.
Observe the exit. The proxy checker can provide a point-in-time liveness, latency, protocol, and exit observation. Reproduce the result in the production client because one checker request cannot establish future availability or workload performance.
Test declared boundaries. Verify sticky expiry or documented replacement on a non-sensitive endpoint. Use synthetic failures to confirm that authentication errors, blocks, challenges, and rate limits stop the workflow instead of triggering identity rotation.
Compare usable outcomes. Validate the business output, classify every failure, and calculate complete cost per accepted output.

Apply one destination-level request budget across every exit. A block, CAPTCHA, login boundary, source objection, or unapproved 429 retry is a stop or review signal, not a reason to change addresses. Keep the pilot and production workload within the destination's rules and Databay's Acceptable Use Policy.

#### Normalize Cost Around the Same Usable Workload
Shared pools are often sold by transferred gigabyte, request, port, or plan. Dedicated addresses are often sold per address and billing period, sometimes with included traffic and overage. Comparing only $/GB with $/IP-month does not identify the cheaper design.
Start with the same monthly workload. Estimate logical tasks, complete round-trip bytes per task, and a separately capped retry allowance. Then replace estimates with pilot measurements. The example below uses decimal units: 1 KB is 1,000 bytes and 1 GB is 1,000,000,000 bytes. Substitute the provider's documented billing convention when it differs. Use these normalization formulas:
monthly traffic GB = logical tasks × measured round-trip KB ÷ 1,000,000

shared all-in cost = plan minimum or billable GB cost
+ targeting and overage
+ engineering, validation, and incident cost

dedicated all-in cost = required addresses × price per address-period
+ traffic or overage
+ setup, replacement, failover, and operations

cost per usable outcome = all-in cost ÷ validated business outputs
Inputs that belong in the cost worksheetInputSourceCommon omission
Logical task volumeApproved production forecastCounting every retry as a new business result
Round-trip bytesPilot request and response measurementsIgnoring uploads, headers, failures, and browser assets
Usable-response rateContent or operation validationTreating all 2xx responses as usable
Required addressesAllowlist and redundancy designBuying extra addresses without a documented requirement
Minimums and expiryDated provider quote and termsComparing a volume-tier headline with entry usage
Operational effortEngineering and incident recordsTreating monitoring, replacement, and validation as free

A shared pool may win at one volume and lose after validation or engineering cost. A dedicated allocation may be economical for a small fixed allowlist and wasteful for independent bandwidth-heavy tasks. Publish the assumptions, time window, exclusions, and sensitivity range with the result.

#### Use Requirement-First Decision Logic
Choose by eliminating models that cannot satisfy a required property, then compare the remaining candidates by evidence.
Authorization: confirm the destination, data, account, purpose, volume, retention, and downstream use are permitted. If not, no allocation model is appropriate.
Official path: prefer an API, feed, export, direct integration, preview tool, or license when it meets the requirement.
Exclusivity: if an owned endpoint must bind events or an allowlist to one customer's public address, require a written dedicated allocation.
Continuity: if the need is only temporary route stability, test a sticky session before paying for long-term dedication. If a fixed address is required, document replacement and failover.
Origin: select datacenter, ISP, residential, or mobile only when that network origin is a real variable. Do not infer origin from allocation.
Protocol: choose HTTP or SOCKS5 from client and transport requirements, independently of allocation.
Pilot: reject candidates that miss required region, continuity, capacity, validation, security, or support thresholds.
Economics: choose among surviving designs by all-in cost per usable outcome, not a headline unit price.

Invalid decision rule: buying dedicated addresses to obtain guaranteed access, or buying more shared exits to continue after a destination refuses the workflow. Neither allocation creates permission or overrides a source control.

#### Databay Product Disclosure: A Shared Rotating Datacenter Pool
Databay's shared datacenter proxies are a provider-managed rotating pool with 80,000+ published addresses. Multiple authenticated customers can use the pool; a customer does not receive a permanent or exclusive public IP. The product supplies country and continent targeting through the gateway and bills transferred bandwidth rather than individual addresses.
The published entry package is 10 GB at USD 1.25 per GB. The stated 1 TB tier is USD 0.5 per GB, and purchased data is valid for 31 days. Those price constants were last verified in the shared fact registry on June 10, 2026; current dashboard availability, plan terms, live exits, and service protections still control an order.
This product is a candidate for authorized independent requests when a hosting-network origin and rotating shared allocation fit the requirement. It is not a dedicated or fixed-IP service. If an owned system requires an exclusive allowlisted address, do not treat a sticky session or observed exit reuse as a contractual substitute. Benchmark a bounded workload and confirm exact product terms before purchase.

#### Keep a Reviewable Allocation Decision Record
The final artifact should let another reviewer reproduce why the allocation was chosen. Store no raw proxy password, full credential URL, sensitive response body, or unnecessary personal data.
Shared-versus-dedicated decision recordFieldWhat to record
Authorization and ownerApproved systems, purpose, source rules, accountable owner, review date, and escalation contact
Required propertiesAllocation, persistence, origin, protocol, locations, allowlists, capacity, and security constraints
Provider claimDated contract or documentation for exclusivity, replacement, billing, logs, and support
Pilot configurationClient version, protocol, DNS, TLS, gateway, redacted plan, session mode, concurrency, timeout, and test window
Measured evidenceValidated outputs, error classes, latency percentiles, observed exits, traffic, capacity, and incident notes
Normalized economicsAll-in monthly cost, cost per usable outcome, assumptions, exclusions, and sensitivity range
Decision and expiryChosen model, rejected alternatives, residual risks, approver, and date the evidence must be reviewed again

Revisit the decision after a provider changes allocation terms, gateway behavior, pricing, network coverage, retention, or replacement policy; after the destination changes its approved interface; or when measured traffic and usable-response rates leave the tested range. A product name is not permanent evidence.

#### FAQ
Q: What is the main difference between shared and dedicated proxies?
A: Shared and dedicated describe allocation. Multiple authenticated customers may use a shared address or pool, while a dedicated resource is allocated to one customer under the provider's contract. The labels do not by themselves specify rotation, network origin, protocol, speed, or destination acceptance.
Q: Is a shared proxy the same as a free or public proxy?
A: No. A commercial shared proxy can require authentication, payment, plan limits, support, and service protections while serving multiple customers. A free or public proxy may be open to unknown users and may not disclose its operator, authorization, logging, or security controls.
Q: Is a dedicated proxy always static?
A: No. Dedicated describes who may use the resource; static describes expected address persistence. A dedicated address can be replaced after failure or review, and a static address can be shared. Verify both allocation and replacement terms in writing.
Q: Are shared proxies always slower than dedicated proxies?
A: No universal speed result follows from allocation. Performance depends on the gateway, exit, route, capacity, destination, client, payload, connection reuse, concurrency, and test window. Compare latency percentiles and usable outputs at representative load.
Q: Do dedicated proxies always have better IP reputation?
A: No. Exclusivity can make address history and incident ownership easier to manage, but it does not guarantee a destination's classification or acceptance. Verify the initial address, monitor treatment, and avoid claims of guaranteed access.
Q: How should I compare shared per-GB pricing with dedicated per-IP pricing?
A: Model one monthly workload. Measure complete round-trip traffic and usable-response rate, then include minimums, overage, required addresses, included traffic, setup, replacement, support, validation, and engineering. Compare all-in cost per validated business outcome.
Q: Does Databay sell dedicated datacenter IPs?
A: The Databay datacenter product described here is a rotating shared pool billed by transferred bandwidth, not a permanent or exclusive IP allocation. Check the current product page and dashboard before ordering because availability and terms can change.
Q: When should I use neither shared nor dedicated proxies?
A: Use neither when the task is unauthorized, an official API or direct route already satisfies the requirement, or the design depends on changing addresses after a block, challenge, quota, or source objection. Allocation does not create permission.

### 403 Forbidden Error: What It Means and How to Fix It
URL: https://databay.com/blog/403-forbidden-error
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

A 403 Forbidden error means the server understood your request and refused it. What causes it, and the fix for visitors, developers, and site owners.

#### What a 403 Forbidden Error Means
A 403 is a decision, not a malfunction. RFC 9110 defines it as the server refusing to authorize a request it understood, and MDN's 403 reference says the same plainly. Everything that has to work for you to receive a 403 already worked: the name resolved, the connection opened, TLS completed, the request was parsed, a rule was evaluated, and software chose to say no.
That is why connectivity advice does nothing here. Restarting the router or flushing DNS treats a broken path, and the path is not broken. What matters is which layer decided, and the page itself usually tells you: a refusal styled like the rest of the site came from the application, a bare nginx or Apache page from the web server, a branded interstitial with an incident or ray ID from a CDN or firewall at the edge. Identify that layer first, because each is fixed by a different person.
The distinction worth learning is 403 against 401, because they ask for opposite reactions.
403 and the status codes it gets confused withStatusWhat the server is sayingWhat changes the outcome
401 UnauthorizedNot authenticated, or the credentials were rejected; a WWW-Authenticate challenge is includedValid credentials. Sign in, then repeat the request
403 ForbiddenThe request was understood and refused; credentials are irrelevant here or insufficientAuthorization: a permission, a scope, an owner's grant, or the operator's rule
404 Not FoundNothing is served at that path. RFC 9110 also lets a server answer 404 rather than confirm a forbidden resource existsA correct URL, or access that makes the resource visible
429 Too Many RequestsA request-rate threshold was crossed; the counter resets on a scheduleTime. Wait out the window, honoring Retry-After

A 401 means try again with credentials. A 403 means credentials are not the variable in play: you were understood, and you are still not permitted.

#### Read the Refusal Before You Change Anything
Spend one request on evidence before touching a setting. Capture the whole response with curl -sS -i or your browser's network panel, then read two things in it. The status line confirms it is really a 403 and not a redirect to a sign-in page, and the Server header, with vendor identifiers such as Cf-Ray or X-Amz-Request-Id, says whether the origin or an edge in front of it refused you. Scope narrows it further: one path refusing while the rest of the site loads points at a permission on that resource, and every page refusing points at a rule keyed to the requester instead.
The lab behind this guide is a loopback origin that refuses one path outright and gates another on a single request property. Four checks, all passing, on Node v24.14.0. The refusal arrived in 17 milliseconds carrying a complete JSON body: nothing timed out, so the server answered and the path to it is healthy. The identical request repeated five times returned 403 every time, so persistence is not a variable. The same path with the authorization condition satisfied returned 200, isolating the only variable that mattered. And unlike a 429, the response carried no Retry-After header, the protocol's way of saying that time is not the fix.
curl -sS -i http://127.0.0.1:8114/allowlisted

HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error":"forbidden","reason":"not on the allowlist"}
That reason string is the whole game, and real services fill it in: cloud APIs name the denied action, firewalls return a rule or incident ID, and web servers write the exact file into their error log.
One thing this guide does not do. A 403 is an authorization decision made by whoever operates the resource. Reshaping requests until an access control stops firing is not troubleshooting, and against a system you do not own it is unauthorized access. The productive question is which authorization is missing and who can grant it.

#### Fix a 403 Forbidden Error as a Visitor
Ordered by how often each is the real cause.
First, the site or the CDN in front of it refused the address you arrived from. This is the most common visitor case by a wide margin. Whole ranges get refused: hosting and VPN exits, carrier pools, an office where hundreds share one address, or a country rule. The address diagnostic shows what a site actually sees. Identifying the rule is where your side of this ends: if a site refuses your region, it has answered, and only its operator can change that.
Second, something on your device altered the request before it left. Security suites that inspect HTTPS, corporate filtering clients, and privacy extensions rewrite or strip parts of a request, and some sites refuse the result. The common advice is to switch your security software off, which is half right: test once in a clean profile with extensions disabled, then add an exception for that one site rather than leaving yourself unprotected. If another device on the same network is refused too, the cause is not your machine.
Third, a stale session. Sites that gate content by session answer 403 when your cookie refers to a login the server already discarded. This is the one case where clearing cookies genuinely helps: clear cookies and site data for that single domain, then sign in again. It changes nothing for an address rule or a permission you do not have.
Fourth, the URL is not yours to open: a document nobody shared with you, a subscriber-only article, an admin path. There is no client-side fix, so ask whoever owns the resource.
Neither your browser nor your phone changes that list. Chrome never generates a 403, it renders one the server sent, and its own failures carry ERR_ names instead; the Chrome-specific step worth taking is a reload with the cache disabled, to rule out a cached error page. On Android an app is just another HTTP client, usually showing the response in a WebView, so an outdated app sending an API version the backend rejects, a wrong device clock that invalidates signed requests, or a system-wide VPN or private DNS can each produce one.

#### 403 From an API, a Bucket, or a Platform
A 403 from an API is a contract answer, not a puzzle. The service accepted the request and told you the caller lacks the permission the endpoint requires, and the body almost always names which one. Log the whole response before touching code: AWS returns an access-denied error naming the action and the resource, Google APIs return a reason such as PERMISSION_DENIED or accessNotConfigured, and Firebase reports a security-rules denial.
Ranked by how often each is the answer. The credential is valid but narrower than the call: an API key restricted to certain referrers, addresses, or APIs; an OAuth token issued without the scope the endpoint documents; a service account never granted the role. Regenerating the key accomplishes nothing, because the key was accepted. Next, a policy denial inside a cloud permission system, where an explicit deny in a resource policy or an organization guardrail overrides the allow you can see in the console; Amazon's S3 guide to 403 errors walks that evaluation order, and the shape repeats on every platform. Next, the project itself: an API never enabled, or billing never configured, surfaces as a 403 surprisingly often.
Then the transport problems that impersonate permission problems. A dropped Authorization header is the classic, because most clients, curl included, strip credentials when a redirect crosses to another host, so a call that worked last week fails after a URL change. Signed URLs expire, and because the expiry is part of what was signed, an expired link answers 403 rather than 401. Preflight requests cost the most hours: a browser sends OPTIONS without credentials, so an endpoint that demands authentication on every method refuses the preflight and the real request never happens.
Finally, separate a real 403 from a cross-origin failure, because the console blurs them. A 403 on the network entry means the server refused. A CORS message with no status means the server may have answered normally and the browser then blocked your script from reading it.

#### When Your Own Server Returns 403
From the operator's side, work in one order: reproduce the request, find the log line it produced, identify the layer that wrote it, then change that one rule. If the origin's access log holds no entry for the refused request, the edge answered, and its security event log names the rule that fired.
On nginx and Apache the origin causes are unglamorous. Filesystem permissions come first: the worker process needs read access to the file and execute access on every directory above it, so one directory without it refuses the whole tree, logged as open() ... failed (13: Permission denied). On RHEL-family systems the mode can be correct while the SELinux context is wrong. Directory indexing is second: a request for a directory with no index file answers 403 rather than 404 when automatic listings are off, which is the default, and nginx logs directory index of ... is forbidden. Its autoindex module documents the switch, the Apache equivalent is Options -Indexes, and usually the fix is adding the index file rather than exposing the listing. Third are explicit deny rules: a deny directive, an Apache Require line, or a forgotten .htaccess in a parent directory. WordPress concentrates here, where a security plugin rewrites .htaccess to guard wp-login.php, XML-RPC, or wp-admin and catches the owner too.
Edge rules are where 403s turn mysterious. Managed rule sets, country and network conditions, hotlink protection keyed on Referer, and bot management all answer before the origin is reached, so a rule written for one abuse incident ages into refusing your uptime monitor. Cloudflare's custom rules documentation is a good model for scoping them narrowly. Fix the rule rather than loosening the layer, and never widen file permissions to 777 to make a permission error disappear. Blunt country and network rules refuse paying customers and search crawlers too, so audit them on a schedule. If your own monitoring keeps getting refused, bot management is scoring signals beyond the address, and how detection systems read a connection explains which ones.
After adding a regional rule you cannot see from your own desk what a visitor inside that region receives. For properties you operate, managed regional egress fetches your own pages from that region. It grants no authorization, will not turn anyone else's 403 into a 200, and is not an answer to a refusal from a site you do not run.

#### How Long a 403 Lasts, and When to Stop
Sometimes a 403 does mean a site blocked you. More often the resource is simply not yours to open, and both arrive as the same status code.
A 403 has no expiry semantics. The lab response carried no Retry-After, which is normal: the protocol gives a 403 no way to say when to come back, because waiting is not what clears it. Reputation-driven and rate-triggered edge blocks are the shortest lived and often clear within hours. Explicit rules, a country or network block, an address on a deny list, persist until an operator changes them. Permission-based refusals last until somebody grants the permission, and a paywalled article is not a block at all, so it never ages out. A permanent ban is the rare case, and repeated attempts improve none of them.
The escalation path is people, not requests. If a refusal looks wrong, use the site's contact or appeal channel and quote the timestamp plus any incident or ray ID from the error page, which is what support needs to find the rule. On a school, workplace, or other managed network the filtering is that operator's policy, and your administrator can permit a destination for a legitimate reason.
The same holds for automated clients. Download tools, scripts, and collectors that start returning 403 have met a source that does not accept automated access, or accepts it only through a channel they are not using. Here the difference between 403 and 429 decides the correct behavior: a 429 is a pacing signal, so slow down and come back, while a 403 is a stop condition. Halt the job and resolve access through the source's API, its published terms, or written permission. Rotating exits, accounts, or user agents changes nothing about the decision. The responsible collection framework covers scoping work so refusals stay rare, and the compliance guide covers authorization and terms before traffic starts.
Whatever produced your 403, the lab named the variable that decides it. Not persistence, not waiting, only authorization.

#### FAQ
Q: Does a 403 Forbidden error mean I am blocked?
A: Sometimes. A 403 means the server refused to authorize the request, which covers both a rule aimed at your address or region and a resource that was never yours to open. The error page tells you which: a branded interstitial with an incident or ray ID came from a firewall, while a refusal styled like the rest of the site came from the application.
Q: Is a 403 error a permanent ban?
A: Usually not. Reputation-driven and rate-triggered edge blocks often clear within hours. Explicit country, network, or address rules persist until an operator changes them, and permission-based refusals last until the permission changes. Nothing in the protocol makes a 403 expire, so waiting is not a strategy; the site's contact channel or your network administrator is.
Q: Can clearing cookies fix a 403 error?
A: Only when the refusal is session-based, meaning the site gates content by session and your cookie refers to a login the server has already discarded. Clearing cookies and site data for that one domain, then signing in again, resolves it. If the URL also refuses in a private window, cookies are not involved and clearing them just signs you out elsewhere.
Q: How do I fix a 403 forbidden error on Google Chrome?
A: Chrome does not create 403 errors, it displays one the server sent, so the fix is never in the browser's settings. Reload with the cache disabled to rule out a cached error page, then open the URL in a fresh profile with extensions off, since privacy extensions and HTTPS-inspecting security tools alter requests. If it still refuses, the decision belongs to the site.
Q: Why do I get a 403 forbidden error in Android apps?
A: An Android app is an ordinary HTTP client, usually showing the response inside a WebView, so test the same URL in a browser to confirm it is not app-specific. Common causes are an outdated app sending an API version the backend no longer accepts, a device clock wrong enough to invalidate signed requests, and a system-wide VPN or private DNS that changes the address the service sees.
Q: What is the difference between 401 and 403?
A: A 401 means authentication is missing or was not accepted, and the response includes a challenge naming the scheme, so presenting valid credentials can succeed. A 403 means authentication is not the missing piece: the caller is understood and still not permitted. Retrying a 403 with the same identity returns the same status every time, as five identical lab requests confirmed.
Q: Why does nginx return 403 Forbidden?
A: Three causes dominate. The worker process cannot read the file or traverse a parent directory, which the error log records as a permission-denied line on open(). Or the request targets a directory with no index file while autoindex is off, logged as directory index is forbidden. Explicit deny rules in the server block are the third. Read the log line before changing any permissions.
Q: Why does Cloudflare return 403 instead of the website?
A: Because the request was refused at the edge and never reached the origin. A custom rule, a managed rule set, a country or network condition, or bot management can each end a request there. The block page carries a ray identifier, and the site's operator can look up the exact rule that fired from that value in their security events.

### 429 Error Code (Too Many Requests): How to Fix It
URL: https://databay.com/blog/429-error-code
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-08-04.

HTTP 429 means you sent requests faster than the server allows. What triggers it, how long it lasts, and the fix for users, developers, and site owners.

#### What the 429 Error Code Means
The 429 status code, defined in RFC 6585 as Too Many Requests and catalogued in MDN's HTTP status reference, means one specific thing: the server counted your requests over some window of time, you went over its threshold, and it is refusing to process more until the window resets. The practice is called rate limiting, and the response is a deliberate answer from software that is working correctly, not a crash. The same response may come from the application itself, from an API gateway in front of it, or from a CDN or web application firewall the site owner configured, which is why you can see a 429 on a site whose own servers never produced one.
Limits are counted against different things: an IP address, an account or API key, a session, or one specific endpoint. Which one applies decides which fixes below can work at all, so it is worth reading the response body and headers before reacting. A 429 is temporary by definition; the counter it reflects resets on schedule. It is also easy to confuse with neighboring status codes that ask for a different reaction.
Status codes that get mixed up with 429StatusWhat the server is sayingCorrect reaction
429You exceeded a request-rate threshold; the block expires on its ownSlow down and retry after the window resets
403The request is refused for authorization or policy reasonsRetrying does not help; resolve access properly
503The server itself is overloaded or in maintenanceWait and retry; the problem is on the server side
Cloudflare 1015An edge rate-limiting rule triggered before your request reached the originSame as 429: back off, then retry

That last row is worth its own page: when a site sits behind Cloudflare, the same refusal arrives branded as error 1015, produced at the edge before your request reaches the site's own servers.

#### Read the Response Before You Retry
A well-behaved 429 tells you exactly how long to wait. The Retry-After reference allows two formats: a whole number of seconds, or an HTTP date after which you may try again. Many APIs add quota headers alongside it. The names vary: RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset on newer APIs, the same names with an X- prefix on older ones, and fully custom conventions elsewhere, so the provider's documentation is the authority. This is what the throttled response looks like in the loopback lab this guide is built on, requested with curl after five rapid requests used up the window:
curl -sS -D - -o /dev/null http://127.0.0.1:8095/resource

HTTP/1.1 429 Too Many Requests
Retry-After: 10
RateLimit-Limit: 5
RateLimit-Remaining: 0
Content-Type: application/json

{"error":"rate_limit_exceeded","retry_after":10}
Two habits make every later fix easier. First, capture the full response once with curl -i or your client's logging rather than reacting to the status code alone; the headers usually name the quota you hit. Second, log your own request timestamps. Sustained rates are easy to estimate and easy to get wrong: a client that averages fifty requests per minute can still burst thirty requests in two seconds, and per-second thresholds only see the burst.

#### Fix a 429 Error as a Visitor
Fixes ordered by how often they are the real one. First, stop and wait. If the page or app shows a retry time, honor it; if not, a few minutes is a sensible default. Refreshing in a loop is the one guaranteed way to make things worse, because every reload spends more of the same budget and can keep extending the block.
Second, find the client that is actually spending the budget. Duplicate tabs of the same dashboard, a background sync client, an auto-refreshing page you forgot about, or a browser extension calling the same service all count against the same limit as your foreground clicks. Close the duplicates, then wait once.
Third, if the message names your account, plan, or API key, the limit is a usage quota rather than a traffic filter. Waiting still works when the quota window is short, but the durable fix lives in the provider's usage dashboard: spread the workload out, or move to a plan sized for it.
Fourth, consider who shares your public address. On office, campus, hotel, and mobile networks, address translation puts many people behind one public IP, and an IP-keyed limit counts all of them together. That is why you can be throttled while doing very little yourself. The browser IP diagnostic shows the address a site actually sees; if colleagues on the same network hit the same wall, you have found the cause, and the fix belongs to whoever runs the network, not to your browser.
Last, and only when a support page says the limit is session-keyed: clear cookies and site data for that site. It rarely helps elsewhere, and a genuinely IP-keyed or account-keyed limit does not care about your cache.

#### Fix 429 in Your Code
The contract for clients is simple: treat 429 as a signal, not an obstacle. When the response includes Retry-After, that value wins over anything your own code would invent; the server knows when its window resets and your algorithm does not. When the header is missing, fall back to exponential backoff with jitter: double the delay after each throttled attempt, cap it, and add a small random component so a fleet of clients does not resynchronize into simultaneous retry waves. Cap the attempt count as well and surface a real error when it is exhausted.
async function fetchWithBackoff(url, maxAttempts = 5) {
for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
const response = await fetch(url);
if (response.status !== 429) return response;
const retryAfter = Number.parseInt(response.headers.get('Retry-After') ?? '', 10);
const delayMs = Number.isInteger(retryAfter)
? retryAfter * 1000
: Math.min(1000 * 2 ** attempt, 16000) * (1 + Math.random() * 0.1);
await new Promise((resolve) => setTimeout(resolve, delayMs));
}
throw new Error('rate limited: retries exhausted');
}
In the lab, the retry that honored Retry-After: 10 succeeded on its first attempt after the wait, while an immediate retry inside the window was throttled again; the schedule the fallback produces stayed monotonic and capped at sixteen seconds. Retrying is only half the job, though. The stronger fix is not sending the burst in the first place: throttle at the client with a queue or token bucket sized under the published quota, cache responses that do not change between calls, use batch endpoints instead of per-item loops, and start scheduled jobs at a random offset rather than on the minute boundary every other cron job uses. Two details save real debugging time later: only auto-retry requests that are safe to repeat, attaching idempotency keys to writes, and remember that one quota is shared by every worker you run, so each instance needs its share of the budget, not a full copy of it. During development, React's StrictMode intentionally double-invokes effects, which doubles your API calls and trips tight limits early; deduplicate in-flight requests and cancel stale ones instead of turning StrictMode off.

#### How Long Does a 429 Error Last?
When Retry-After is present, that is the answer, in seconds or as a date. Without it, the duration follows the window that was exceeded. Per-second and per-minute thresholds clear in seconds to about a minute; hourly or daily quotas refuse requests until the period resets, sometimes on a rolling basis and sometimes at a fixed clock boundary; throttles raised by a firewall's abuse rules typically hold for a few minutes and can extend if violations continue. The one universal rule is that hammering a throttled endpoint never shortens the wait, and against infrastructure that escalates on repeated violations it lengthens it.
Fallback backoff schedule when no Retry-After is sent (1 s base, 16 s cap, up to 10% jitter)AttemptWait before retry
1~1 second
2~2 seconds
3~4 seconds
4~8 seconds
5~16 seconds, then stop and report

If a limit still refuses requests long after any plausible window, stop guessing: check the provider's status page and documentation, because a stuck 429 is sometimes a provider-side incident or a quota accounting issue rather than anything your client did.

#### 429 in Web Scraping and Data Collection
For collection work, rate limits are the source's published contract, and 429 is the source enforcing it. The workable response is architectural, not reactive. Set one request budget per source and enforce it across everything you run: every worker, every account, every region, every proxy exit. Distributing traffic across addresses does not reduce the aggregate load you place on the source, so the budget has to be counted where the requests originate, as the responsible collection framework lays out. Inside that budget, the same client techniques apply at fleet scale: jittered backoff on transient failures, capped retries, conditional requests, response caching, and deduplication so the same URL is not fetched twice for nothing.
A 429 from a source is a backoff signal, full stop. It is never a reason to switch exits, accounts, or fingerprints to keep the same traffic flowing; treating it that way violates the contract the limit expresses, and persistent refusals are a reason to stop and use an approved channel instead. Where managed proxy infrastructure legitimately fits is in how authorized workloads are built: stable regional egress for measurement and QA of your own properties, session-pinned exits so per-session state survives a whole workflow, and parallel regional coverage where each stream is paced within the budget on its own. The static versus rotating guide covers when each exit model fits a workload, the Python requests integration guide shows pacing and sessions in client code, and the proxy checker verifies an exit before production traffic. For paced, authorized collection at scale, managed residential and datacenter networks provide accountable egress; they do not expand any quota, and rotation is not a response to a 429.

#### When Your Own Site Returns 429
Seen from the operator's side, a 429 your users or Google report is usually a rate rule you or your stack configured. The common causes, roughly in order: a CDN or WAF rate-limiting rule scoped too broadly, so one page view with dozens of images or API calls trips a per-IP threshold on asset paths; a security or login-protection plugin with aggressive defaults; a hosting plan's platform-level limiter; and only then an application limiter you wrote yourself. Genuine abuse also exists, which is why the goal is scoping, not deletion.
Diagnose by finding out which layer produced the response. If the origin's logs never recorded the throttled requests, the block came from the edge; the CDN's security event log will name the rule. Reproduce with curl -i against the affected URL and, when the edge is suspected, test once with the CDN temporarily bypassed for a low-traffic hostname to confirm the origin behaves. Then fix the scope: exempt static asset paths from per-IP page rules, size thresholds from real traffic percentiles rather than guesses, verify search-engine crawlers by the vendor's published verification method instead of trusting user-agent strings, and send an accurate Retry-After so well-behaved clients pace themselves.
Search impact is the quiet cost. Persistent 429s slow Googlebot's crawl of your site, and URLs that keep answering with them can be dropped from the index, as covered in Google's HTTP status guidance; watch Search Console's crawl stats after any rate-rule change. Reference documentation for scoping edge rules properly lives in Cloudflare's rate limiting rules, and equivalents exist for every provider. A limit that protects login endpoints while exempting your CSS is doing its job; one that throttles your own image directory is a bug you can fix in an afternoon.

#### FAQ
Q: How do I fix a 429 error quickly?
A: Stop sending requests and wait out the window: honor a Retry-After value when one is shown, otherwise give it a few minutes. Close duplicate tabs and background clients that share the same account or address, then retry once. If the message names your API key or plan, check the provider's usage dashboard, because the limit is a quota rather than a traffic filter.
Q: Can I bypass a 429 error?
A: No. The counter is enforced on the server, so nothing on your side removes it, and working around it by switching addresses, accounts, or fingerprints violates the limit the operator set and usually the terms you agreed to. The durable fixes are reducing request rate, caching, batching, and asking the provider for a higher quota when the workload justifies it.
Q: Why does my React app keep hitting 429 in development?
A: React's StrictMode intentionally runs effects twice in development, so every data fetch fires twice, and hot reloads re-fire them again. Against a tight API quota that alone trips 429s. Deduplicate in-flight requests, cancel stale ones with an abort controller, cache results, and add backoff; the production build does not double-invoke.
Q: What is error 429 on Chrome?
A: Chrome is only displaying a response the website or its CDN sent; it is not a browser fault. It usually means your address or session exceeded the site's request threshold, sometimes because extensions or prefetching multiplied requests. Test the same page in another browser profile with extensions off before blaming the site.
Q: Why am I rate limited when I barely sent any requests?
A: The limit is probably not counting only you. Shared networks put many users behind one public address, so an IP-keyed threshold counts everyone together, and background clients on your own devices spend the same budget silently. Occasionally the provider is having an incident and returns 429 broadly, which their status page will confirm.
Q: Does a 429 error hurt SEO?
A: A brief throttle is harmless. Persistent 429s served to Googlebot cause it to slow its crawl, and URLs that keep refusing requests can eventually be dropped from the index. If a rate rule ever caught your pages or assets, rescope it, then watch crawl stats and the affected URLs in Search Console until they stabilize.

### What Is Captive.apple.com? Apple's Wi-Fi Check Explained
URL: https://databay.com/blog/captive-apple-com
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

Captive.apple.com is how Apple devices detect Wi-Fi login pages. Why it pops up, what the Success page means, and fixes when portals stick.

#### A Canary Page, Not a Website
Captive.apple.com is the hostname Apple devices use to answer one question every time they join a network: is this Wi-Fi actually connected to the internet, or is a login page standing in the way? The mechanism is a probe. On joining, the device requests a tiny page, most visibly /hotspot-detect.html, and compares what comes back against the fixed answer it expects. In the recorded check behind this article, that answer is a 69-byte page whose content is simply the word Success, served with no cookies.
Receiving the expected Success tells the device the path to the internet is clear, and nothing visible happens. Receiving anything else, typically a hotel or airport login page that the network injected in place of the real answer, tells the device a captive portal is intercepting traffic, and that is precisely when the login window titled captive.apple.com pops up on an iPhone or Mac. The domain also publishes its own probe configuration at captive.apple.com/probe-info, listing the hostname and refresh intervals the system uses.
So the short answer to the search that brought most readers here: it is legitimate Apple infrastructure, one purpose-built endpoint, and seeing it in a popup, a router log, or a browser history entry means a device on the network was checking its connectivity, nothing more. The interesting details, and the fixes for when the mechanism misbehaves, are the rest of this guide.

#### Why It Keeps Popping Up
The probe runs far more often than people expect, and every appearance in logs or on screen has the same innocent trigger: the device just evaluated a network. Joining any Wi-Fi fires it. Waking from sleep fires it. Roaming between access points on the same network, or briefly losing and regaining signal, fires it again, because each re-association is a fresh chance for a portal to be in the way. On portal networks specifically, the popup returns whenever the portal's session expires, which hotels commonly set to hours or a day, so a multi-night stay re-triggers the login window daily by design.
A popup with no portal network in sight usually has one of three causes. Weak signal at the edge of coverage makes the device re-associate repeatedly, re-running the probe each time. A home or office network whose router briefly loses upstream connectivity makes probes fail during the outage, and the device keeps re-checking until the path clears. And network-side filtering that interferes with the probe itself, covered in the admin section below, convinces every Apple device in the building that something is wrong with a perfectly working network.
Frequency alone is never the signal of a problem: a household of Apple devices legitimately generates a steady stream of these requests all day. What matters is only whether the checks succeed, and whether the popup appears when no login page should exist.

#### Interceptable on Purpose: How the Probe Works
The design looks backwards until the purpose clicks: the probe is fetched over plain HTTP precisely so that a captive portal CAN hijack it. A portal works by intercepting a visitor's first unencrypted request and answering with its own login page; an encrypted request cannot be rewritten that way without triggering certificate errors. The recorded lab confirms both halves of the design: the plain-HTTP probe answers 200 Success normally, and the same endpoint also serves the identical content over HTTPS for contexts that want the authenticated variant. The interceptable half exists to be hijacked; the hijack IS the detection.
Every consumer operating system runs the same trick against its own endpoint. Apple devices probe captive.apple.com, Android and Chrome request an empty 204 from a Google endpoint per Chromium's portal-detection notes, and Windows probes a Microsoft connect-test host. The newer, cleaner path is RFC 8910, where the network itself announces its portal via DHCP instead of waiting to be caught intercepting; support is growing, and until it is universal, the probe dance remains how every device learns the truth.
One privacy note belongs here because the domain appears in device traffic constantly: the probe is a fixed page, the recorded response sets no cookies, and the request carries the usual connection metadata any HTTP request carries. It is a connectivity canary, not a browsing log.

#### When the Portal Sticks: Fixes That Work
The mechanism's one common failure is the stuck portal: the network wants a login, but the window never appears, shows blank, or loops. The fix ladder, in the order worth trying. First, force the probe by hand: open a browser and go to captive.apple.com directly, or any plain-HTTP page; on a portal network the interception will grab that request and serve the login page in a full browser, which renders complex portal pages more reliably than the popup webview. Second, forget and rejoin the network, which resets the association and re-runs detection from scratch; it is the standard cure for a portal session wedged half-open.
Third, turn off the privacy layers for the duration of the login. VPNs and encrypted-tunnel apps block the portal's ability to intercept anything, so the login can never appear until the tunnel is down; connect to the portal first, then bring the tunnel up, a sequencing quirk explained in the proxy versus VPN comparison. The same applies to encrypted-DNS settings and, on Apple devices, per-network options like Private Relay and address rotation: temporarily disabling them for the portal network removes the interference, and iOS exposes exactly these toggles per network for this reason.
Fourth, if the portal page loads but its buttons do nothing, the portal itself is broken in a way only the venue can fix; the front desk resetting your session, or a different network, are the honest remaining options. Custom DNS servers configured on the device deserve a final mention: they can break detection entirely by answering the probe hostname wrongly, which presents as endless popups on working networks.

#### On Your Network's Logs and Filters
Administrators meet this domain from the other side: as a permanent presence in DNS and firewall logs, one entry per Apple device per network event, all day. That volume is the mechanism working. The actionable rule is simple: let the probes through untouched. Blocking, filtering, or DNS-rewriting captive.apple.com does not make Apple devices trust the network more; it convinces every one of them that a portal or a fault stands between them and the internet, producing spurious login popups, "no internet" banners on working Wi-Fi, and helpdesk tickets that describe exactly the Cisco-forum classic: Success pages popping up on every network join.
Three specific interactions cause most enterprise incidents. DNS filtering that answers the probe hostname with a filter page converts every join into a false portal detection. TLS-inspecting middleboxes that touch the HTTPS variant break the authenticated check with certificate errors the devices rightly distrust. And overly broad ad-block lists occasionally include connectivity-check hosts, with the same false-portal result; the cure is an explicit allow for the probe endpoints of every OS family your users carry, Apple's alongside the Google and Microsoft equivalents.
For actual captive-portal deployments, the modern advice is to announce the portal via the DHCP option from RFC 8910 as well as intercepting, which gives compliant devices a clean, race-free signal and reduces the webview weirdness your guests experience. The probe hosts remain the fallback for everything older.

#### Verify It Yourself
Every claim above reproduces with one command from any network without a portal:
curl -s -D - -A "your-lab/1.0" http://captive.apple.com/hotspot-detect.html

HTTP/1.1 200 OK
Content-Type: text/html

<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
A 200 with that tiny Success body, and no Set-Cookie header, is the healthy answer the devices expect; the recorded run measured it at 69 bytes. Run the same command on a fresh portal network before logging in and you will see the hijack live: a redirect or a full login page in place of Success, which is the exact observation an iPhone turns into its popup.
The lookalike rule from elsewhere in this cluster applies here unchanged: the legitimate hostname ends in apple.com, full stop. Phishing kits love borrowing connectivity-check names because users have been trained to type credentials into portal pages, so a login page served from any domain that merely contains the word captive deserves suspicion, and a portal asking for anything beyond the venue's access credentials, such as email passwords or payment card numbers for free Wi-Fi, deserves refusal. On the genuine article there is nothing to log into at all: as the probe-info file shows, the real endpoint's whole vocabulary is one word, Success.
Seen in a device's website data or history, the entry is the popup webview having done its job, and clearing it is harmless. Seen thousands of times in a router log, it is a healthy fleet checking its connectivity, exactly as designed.

#### FAQ
Q: What is captive.apple.com?
A: It is Apple's connectivity-check endpoint. Every iPhone, iPad, and Mac requests a tiny fixed Success page from it when joining a network; receiving the page means the internet path is clear, and receiving a login page instead means a captive portal is intercepting, which is what makes the login window appear. It is legitimate Apple infrastructure, not malware.
Q: Why does captive.apple.com keep popping up?
A: Each popup means the device just re-checked a network and something intercepted the probe: a portal session expired, the signal dropped and re-associated, or the network's upstream briefly failed. On portal networks, daily re-logins are normal because venues expire sessions on purpose. Constant popups on a working private network usually point at DNS or filtering interfering with the probe.
Q: Is captive.apple.com safe, or is it tracking me?
A: The endpoint serves a fixed 69-byte Success page and sets no cookies, per the recorded check behind this article. Like any web request, it exposes ordinary connection metadata, and nothing more. The realistic risk is lookalikes: a login page on a domain that merely resembles the name, or any portal demanding passwords or payment details, deserves refusal.
Q: How do I force the Wi-Fi login page to appear?
A: Browse to captive.apple.com directly, which hands the portal a plain-HTTP request to intercept in a full browser window. If that fails, forget the network and rejoin, and disconnect VPNs, encrypted DNS, and per-network privacy features until after login, because they block the interception the portal needs. A portal that loads but does not work is the venue's to fix.
Q: Can I block captive.apple.com on my network?
A: You can, and every Apple device will conclude the network is broken or portaled: spurious login popups, no-internet warnings on working Wi-Fi, and support tickets follow. Connectivity probes should be allowed through untouched, alongside the Google and Microsoft equivalents. If you run an actual portal, announce it via the DHCP captive-portal option too, rather than relying on interception alone.
Q: Why will the hotel Wi-Fi portal not load on my iPhone?
A: Something is blocking the interception the portal depends on: a VPN that auto-connects, encrypted DNS, or a wedged half-open session. Disable the tunnel and private DNS temporarily, forget and rejoin the network, then visit captive.apple.com in Safari to hand the portal a fresh request. If its page appears but the login itself fails, only the venue can reset it.

### Checking the Proxy and the Firewall: Fix the Chrome Error
URL: https://databay.com/blog/checking-the-proxy-and-the-firewall
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

Chrome shows this when a configured proxy fails. Find whether a proxy is set, remove leftovers you never wanted, and fix the one you actually need.

#### What the Message Actually Means
The line "checking the proxy and the firewall" is one of the suggestions Chrome prints under a "This site can't be reached" page, most often together with error codes like ERR_PROXY_CONNECTION_FAILED, ERR_TUNNEL_CONNECTION_FAILED, or ERR_TIMED_OUT, all listed in Chrome's connection-error help. Despite the phrasing, Chrome is not asking you to do anything yet; it is naming the two network layers most likely to have eaten your request.
The meaning is specific when a proxy is involved: your browser was told to send web traffic through an intermediary server, and that hop failed. Either the proxy could not be reached, refused the connection, spoke the wrong protocol for what the browser asked of it, or timed out. Nothing about the destination site has been tested at that point, which is why a perfectly healthy site becomes unreachable behind a broken proxy hop. The loopback lab later in this guide reproduces each of those failures and shows the raw socket errors Chrome dresses up in friendlier words.
The message splits into two very different situations, with different fixes. Either you never knowingly configured a proxy and something set one for you, in which case the fix is removal, or you rely on a proxy deliberately, in which case the fix is finding which link in the chain broke. The next section tells you which situation you are in, in about a minute.

#### First, Learn Whether a Proxy Is Configured at All
Chrome, Edge, and Opera do not keep their own proxy settings; per Chromium's network-settings notes, they use the operating system's, which is why the same error and the same fix apply to all Chromium browsers on a machine.
On Windows, open Settings, then Network & internet, then Proxy. Three things can be active there: automatic detection, a setup script (a PAC file URL), and a manual proxy with an address and port. Note what is on before changing anything. The command-line view of the system-wide WinHTTP proxy is also worth a look:
netsh winhttp show proxy

Current WinHTTP proxy settings:
Direct access (no proxy server).
On macOS, check System Settings under Wi-Fi or Ethernet, Details, Proxies, or list the same from a terminal with networksetup -getwebproxy "Wi-Fi" and networksetup -getsecurewebproxy "Wi-Fi".
Interpret what you find against what you expect. Everything off and the error still appearing means the proxy half of the message is a red herring for you; skip to the firewall section. A manual proxy or setup script you do not recognize is the trail to follow in the next section. A proxy you configured on purpose, for work or for a data workflow, sends you to the section after it.

#### Fix It When You Never Wanted a Proxy
Unexpected proxy settings come from a short list of sources, ordered here by how often they turn out to be the answer. First, leftovers: VPN clients, privacy suites, and some antivirus products set a system proxy while active and occasionally fail to clean it up after uninstall or a crashed session, leaving the browser pointed at a proxy that no longer exists. Second, a stale setup script: a PAC URL from an old network or tool that no longer resolves, which stalls every connection while the browser tries to fetch instructions. Third, adware or malware that quietly set a proxy to inspect or redirect your traffic. Fourth, a work-managed machine that expects a corporate network it currently cannot reach; on those, the setting is policy-managed, and the fix belongs to your IT team rather than this page.
For the first three, the repair is the same: in the proxy settings you just inspected, turn off the manual proxy and the setup script, then clear the WinHTTP layer for good measure:
netsh winhttp reset proxy
Restart the browser and retry the page.
Then do one more thing: check the settings again after the next reboot. A proxy that keeps coming back after you disable it is the classic sign that software on the machine is reasserting it, and if no legitimate tool of yours explains it, that is the point to run a full malware scan and review recently installed programs and browser extensions.

#### Fix It When You Do Need the Proxy
When the proxy is intentional, work outward from the server. Start by testing the proxy itself rather than restarting the browser again: the proxy checker verifies an endpoint is alive, reachable, and answering, which separates "my proxy is down" from "my machine is misconfigured" in one step.
If the endpoint is alive, the usual culprits are, in order: a wrong port, a scheme mismatch, authentication, and a firewall in the path. Port and scheme travel together, because sending HTTP proxy requests to a SOCKS port or vice versa fails in ways that look like the server is broken; the proxy-port guide covers which ports carry which protocols, and the HTTP versus SOCKS5 guide explains the two protocol families the settings dialog is asking you to choose between. Authentication failures announce themselves with status 407 responses when you test outside the browser. Egress firewalls matter on locked-down networks: common proxy ports such as 8080, 3128, or 1080 are sometimes blocked outbound on purpose, and the section below covers how to see that.
Two habits prevent most of these dead ends. Generate client configuration instead of typing it: the proxy config generator emits the exact strings for browsers, curl, and language clients, which eliminates scheme and port typos. And when a managed proxy service is the intended path, confirm the credentials and endpoint against the provider's dashboard rather than memory; rotated passwords and retired gateways produce exactly this error page.

#### Reproduce the Failure in 60 Seconds
Every cause named above reduces to a handful of socket-level outcomes, and all of them reproduce on loopback with no risk to anything. The recorded lab behind this article starts a tiny origin server and a minimal forward proxy, then performs four checks. A request configured to use a proxy port where nothing listens fails instantly with connection refused, which is the raw event behind ERR_PROXY_CONNECTION_FAILED. The same request through the live proxy relays cleanly and returns the origin's page. A CONNECT tunnel request, the method browsers use for HTTPS through a proxy as defined in the HTTP CONNECT specification, is answered with 501 by this deliberately HTTP-only proxy, reproducing the wrong-proxy-type failure. And a direct request to the origin succeeds throughout, proving the destination was healthy while the proxy path failed.
You can run the same experiment against any proxy with curl's -x option, which reports the underlying error Chrome summarizes:
curl -x http://127.0.0.1:8099 http://example.test/
curl: (7) Failed to connect to 127.0.0.1 port 8099: Connection refused

curl -x http://127.0.0.1:8098 http://127.0.0.1:8097/page
origin ok: /page
Connection refused points at a dead or wrong proxy address. A hang until timeout suggests a firewall silently dropping packets. An immediate protocol-level error suggests the scheme mismatch from the previous section. That one-line diagnosis is usually the whole investigation.

#### The Firewall Half of the Message
The firewall named by the error is any layer that can silently drop or intercept your connection: the operating system's own firewall, a third-party security suite, or filtering on the network between you and the destination.
Windows Defender Firewall is rarely the cause for browsers; its default outbound policy allows web traffic, so suspect it mainly if someone hardened the machine with custom outbound rules. Third-party antivirus deserves a closer look for a different reason: many implement web protection by running a local filtering proxy on the machine and routing browsers through it. A proxy entry pointing at 127.0.0.1 on a high port usually is that feature rather than malware. If the security suite crashed or half-uninstalled, its local proxy stops listening and every page load fails with exactly this error; briefly disabling the web-protection module, or reinstalling the suite cleanly, isolates the fault fast. Re-enable protection when the test is done.
Managed networks are the remaining case. Offices, schools, and some public Wi-Fi block outbound ports or force traffic through their own gateway by policy. The symptom is that direct browsing works while your configured proxy times out, or the reverse. On a network you do not administer, that filtering is policy, and the correct paths are the network administrator or a network you control, such as a phone hotspot, for confirming where the fault lives. Filtering decisions on managed networks are theirs to make; this guide diagnoses, it does not route around policy.

#### Still Broken: a Five-Minute Elimination Checklist
When the sections above have not produced the answer, five comparisons corner it. Test in Firefox: it keeps its own proxy settings independent of the system, so if Firefox loads the page while Chrome fails, the system proxy configuration is guilty. Test another site: one unreachable site with others fine points at the destination or its infrastructure, not your proxy. Test another network, such as a phone hotspot: if everything works there, the original network's filtering or its assigned proxy is the variable. Test by error code: ERR_NAME_NOT_RESOLVED is a DNS problem wearing similar clothes, and the proxy suggestion under it is usually noise. And test with curl using the exact proxy string from your settings, because its one-line errors beat the browser's summary page every time.
One outcome deserves a plain statement: sometimes the answer is that the destination refuses your network's address. That presents as one site failing from your network while working elsewhere, with your proxy blameless. What to do about it depends on your relationship with the site, and the honest options are the site's support, your network operator, or accepting the refusal; a block is the operator's decision about their own service. For the fundamentals behind everything this page touched, the proxy fundamentals guide walks the whole request path from client to destination, hop by hop.

#### FAQ
Q: How do I check the proxy and the firewall?
A: On Windows, open Settings, Network and internet, Proxy, and note whether automatic detection, a setup script, or a manual proxy is on; run netsh winhttp show proxy for the system-wide view. On macOS, check Proxies under your network service's details. Then check your security suite's web-protection module and, on managed networks, ask whether outbound filtering applies.
Q: How do I reset proxy settings completely?
A: Turn off the manual proxy and any setup script in the OS proxy settings, then run netsh winhttp reset proxy from an elevated prompt on Windows. Restart the browser afterward. If a proxy entry returns on its own after a reboot, software is reasserting it, which is the signal to audit installed programs, extensions, and run a malware scan.
Q: What is the difference between a proxy and a firewall?
A: A proxy is an intermediary that carries your traffic and speaks on your behalf to destinations, while a firewall is a filter that allows or blocks traffic according to rules. Chrome names both in one suggestion because either a broken proxy hop or a blocking filter produces the same visible result: the page never arrives.
Q: How do I fix this error on Windows 10?
A: The steps match Windows 11 with slightly different menus: Settings, Network and Internet, Proxy, then disable Use a proxy server and Use setup script unless you rely on them, and run netsh winhttp reset proxy. The legacy dialog at inetcpl.cpl, Connections, LAN settings, controls the same values on both versions.
Q: Why does Chrome mention a proxy when I never set one up?
A: The suggestion appears on generic unreachable errors even when no proxy is configured, and software can set one without asking: VPN clients, security suites with web protection, corporate policy, or in the worst case adware. Check the OS proxy settings first; if everything is off, the proxy half of the message does not apply to your case.
Q: Is the fix the same in Edge and Opera GX?
A: Yes. Chromium-based browsers, including Edge and Opera GX, use the operating system's proxy settings rather than their own, so the same inspection and the same removal or repair steps fix the same error in all of them. Firefox is the exception, with independent proxy settings, which is what makes it useful as a comparison test.

### curl Error 7 and 56: Exit Codes Explained and Fixed
URL: https://databay.com/blog/curl-error-codes
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

curl exit code 7 is a connection failure, not a timeout. What codes 6, 7, 28 and 56 each prove about a request, and how to fix each.

#### What a curl Exit Code Actually Tells You
curl does not fail vaguely. When a transfer does not complete, curl exits with a number that names the phase of the request that broke. Every request runs four phases in order: resolve the hostname, open a TCP connection, wait for an answer, transfer the body. Each phase owns an exit code, so the number is already a diagnosis.
The lab behind this article provokes each failure on purpose with system curl 8.17.0 (libcurl/8.17.0, Schannel), against a loopback origin, a reserved .invalid name, and an address in the documentation range RFC 5737 keeps off the public internet. All six checks passed on 2026-07-29, including the healthy baseline at exit 0.
curl exit codes by request phase, with message text recorded in the labExitlibcurl namePhase that failedMessage curl printed
6CURLE_COULDNT_RESOLVE_HOSTResolvecurl: (6) Could not resolve host: databay-lab.invalid
7CURLE_COULDNT_CONNECTConnectcurl: (7) Failed to connect to 127.0.0.1 port 8128 after 2020 ms: Could not connect to server
28CURLE_OPERATION_TIMEDOUTWaitcurl: (28) Connection timed out after 2015 milliseconds
56CURLE_RECV_ERRORTransfercurl: (56) Recv failure: Connection was reset

Now the correction, the most repeated mistake about these numbers. Exit 7 is not a timeout. An answer still circulating on hosting forums says code 7 means the connection timed out, which sends you off raising limits that were never involved. curl's own libcurl error list defines 7 as CURLE_COULDNT_CONNECT, "Failed to connect() to host or proxy", and 28 as CURLE_OPERATION_TIMEDOUT.
The myth is sticky because the exit 7 message reports elapsed milliseconds, so it reads like a limit. It is not one. That figure is how long the attempt took, and it moves: the lab's closed-port check printed 2020 ms, and five re-runs of the identical command printed values between 2017 ms and 2038 ms. Deadlines do not wander.

#### Read curl's Own Diagnosis Before Changing Anything
Two flags turn guessing into reading, both documented in the curl manual. -v prints the phase trace: every asterisk line is curl narrating what it is doing, and the last one before it gives up names the phase that failed. These are the asterisk lines from the lab's closed-port check:
curl -sSv -o out.txt http://127.0.0.1:8128/

* Trying 127.0.0.1:8128...
* connect to 127.0.0.1 port 8128 from 0.0.0.0 port 64941 failed: Connection refused
* Failed to connect to 127.0.0.1 port 8128 after 2023 ms: Could not connect to server
Read it downward. curl printed Trying with an address, so resolution had already succeeded, and the connect attempt came back refused. There is no request line and no response header, because HTTP never started. That rules out every fix above the socket: URL paths, headers, cookies, authentication, TLS certificates and the server's application log cannot be involved in an exit 7, because none of them had happened yet.
-w gives the same conclusion in one line, which is what you want in a script or a health check. Each timing variable covers one phase, so a phase that never ran reports zero. Three runs against the same lab:
curl -sS -o out.txt -w 'exit=%{exitcode} dns=%{time_namelookup} connect=%{time_connect}\n' URL

healthy origin exit=0 dns=0.000033 connect=0.000730
closed port exit=7 dns=0.000051 connect=0.000000
unresolvable name exit=6 dns=0.000000 connect=0.000000
On the healthy request both timers populate. On exit 7, DNS finished in 51 microseconds and connect time is flat zero, because no connection was ever established. On exit 6 even the DNS timer is zero. Find the first zero from the left and you have the failing phase.

#### Exit 7: the Connection Was Never Established
Exit 7 has a narrow meaning: curl asked the operating system to open a TCP connection to one address and one port, and got back no connection. Nothing was ever open, so nothing HTTP-shaped happened. Read the address and port in the message first, every time. curl names exactly what it tried, that is not always what you typed, and a disagreement is the bug.
Causes, ordered by how often they turn out to be real.
Nothing is listening on that port. The service is stopped, crashed, still starting, or exited on a config error. This is the majority case, and the machine will tell you: ss -ltnp on Linux, netstat -ano on Windows.
The port is wrong. The URL names a port nothing serves, or the scheme and the port disagree, such as an https URL aimed at a plain HTTP listener. Outbound filtering has a signature: every https host fails while plain HTTP on port 80 keeps working, which points at your network or hosting plan closing outbound 443.
A firewall is rejecting rather than dropping. A reject rule answers immediately and produces exit 7. A drop rule stays silent and produces exit 28. The code tells you which kind of rule you met.
A container boundary sits in between. Inside a container, 127.0.0.1 means that container, not the host and not a sibling. Reach siblings by service name, and confirm the port is published, not merely exposed.
A proxy is set in the environment and curl is dutifully using it. Common enough, and invisible enough, to get its own section next.

If the rule refusing you belongs to a network you do not run, that is policy, and the way forward is its administrator rather than another attempt. ERR_CONNECTION_REFUSED is the browser's name for the explicit-refusal case, and its triage transfers directly.

#### The Proxy Variable That Explains Most of the Rest
This is the cause almost nobody names, and in PHP applications, CI runners and container images it explains a large share of reported curl error 7. curl reads proxy settings from its environment with no flag involved. If http_proxy, HTTPS_PROXY or ALL_PROXY is set in the process running curl, the request goes to that proxy instead of your target, exactly as if you had passed --proxy. Read the official text for code 7 again: failed to connect to host or proxy. The number does not distinguish the two.
When that proxy is gone, wrong, or unreachable from where curl runs, the result is exit 7, and the message names the proxy rather than your target. That is the tell: if the host and port in the error are not in your URL, stop debugging the destination. The variable is usually set somewhere you are not looking: a Dockerfile ENV line, a systemd unit's Environment=, /etc/environment, a CI base image, or a shell profile your service manager never reads.
One precision detail catches people out: the HTTP variable is accepted in its lower case form only, http_proxy, while the others are read in either case, for CGI security reasons set out in curl's proxy environment reference. Two commands settle it:
env | grep -i _proxy
curl -v --noproxy '*' https://example.com/
If the second succeeds where the plain request failed, the environment is the cause, and the fix belongs where the variable is set, not in your code. NO_PROXY is the documented escape hatch and stronger than it looks: hostnames or domains, IP networks in CIDR notation since curl 7.86.0, and a single asterisk meaning every host. Listing internal names and loopback addresses there fixes a machine that reaches the internet but not its neighbors.

#### cURL Error 7 in PHP, WordPress and Containers
PHP's curl extension is libcurl, so the numbers are identical. curl_errno() returns the error number for the last operation, and 7 there is exactly the failure above. WordPress relays it into Site Health and update checks as cURL error 7: Failed to connect. A socket did not open, and the CMS is quoting what it was handed.
Proving which layer owns the fault saves the most time, and one command does it: run the same request from a shell, as the same user, on the same host or in the same container.
sudo -u www-data curl -sSv --max-time 10 https://api.example.com/
echo "exit=$?"
Three outcomes. If the shell command fails the same way, the CMS is innocent and you are debugging the host's networking. If it succeeds as your login user but fails as the web server's user, the difference is that user's environment or a policy scoped to it. If it works on the host but fails inside the container, the boundary is the container.
The ranking differs in this lane. First, outbound filtering on the host or hosting plan, which stops the web server reaching port 443 while your SSH session is fine; that belongs to the provider's support queue, not to a plugin setting. Second, proxy variables the pool inherited, or WP_PROXY_HOST in wp-config.php, because PHP-FPM does not inherit your SSH session: read the pool config, the systemd unit and the image. Third, the container boundary, which is also why WordPress loopback requests for WP-Cron and the REST API fail. Fourth, SELinux with httpd_can_network_connect off on RHEL-family systems, which refuses outbound connections from the web server alone and logs nothing.
If this started right after a PHP upgrade, look at what else the upgrade replaced: a new base image brings a new environment, and its proxy variables or egress rules are likelier than the runtime.

#### Exit 6, 28 and 56: the Other Three Phases
Exit 6 is DNS, and it happens before the network is touched. The lab's unresolvable name failed with every timer at zero. curl sent no packet to any server, so no firewall, port or certificate can be involved. Check the spelling, then the resolver in the context curl runs in: a name that resolves on your laptop but not on a server means split-horizon DNS, an internal zone, or a container using a different resolver. The browser-side version is ERR_NAME_NOT_RESOLVED.
Exit 28 is silence. The lab hit 28 against the unroutable documentation address with --connect-timeout 2: nothing answered, and the deadline expired. Two deadlines report as 28. --connect-timeout limits the connection phase, --max-time the whole transfer. A 28 during connect points at a packet-dropping firewall, a dead route, or an address nobody answers for; a 28 after the connection succeeded points at a slow or stuck server, and %{time_connect} tells you which. Raising the limit only helps the second. The browser equivalent is ERR_CONNECTION_TIMED_OUT.
Exit 56 proves you got through. The lab's origin sent headers, wrote part of the body, then reset the socket, and curl printed the partial body followed by curl: (56) Recv failure: Connection was reset. That sequence is the diagnosis: resolve, connect and request all succeeded, which eliminates every cause on the exit 7 list. Something tore down a working connection. In order: the server process died mid-response, often an out-of-memory kill or a worker restart; an idle timeout closed a pooled keep-alive connection your client then reused; a middlebox objected in flight; or plain HTTP was sent to a TLS port. Retrying once separates the keep-alive case, because a fresh connection works. The browser name is ERR_CONNECTION_RESET.

#### Using curl Through a Proxy Deliberately
Plenty of readers meet these codes while pointing curl at a proxy on purpose, for regional QA or authorized collection. The flag is -x, also spelled --proxy, taking a scheme, a host and a port. Credentials belong in -U rather than in the URL, and socks5h:// rather than socks5:// makes the proxy resolve the hostname, which takes exit 6 out of your local resolver's hands.
The codes keep their meanings but change subject. With -x in play, an exit 7 names the first hop: curl could not connect to the proxy itself, usually a wrong port, a stopped gateway, or an endpoint your own network filters. Once -v shows the tunnel established, later failures belong to the destination. The proxy configuration generator produces the exact invocation for an endpoint and protocol, and the proxy checker confirms an endpoint is alive before you debug against a dead gateway.
One thing deserves saying plainly. A proxy changes the route a request takes. It does not grant access to anything. If a server answered with a refusal, a block page, a 403 or a 429, that was a deliberate decision by whoever runs it. The response is to stop and take it up with the site, or on a managed network with the administrator who wrote the rule. Switching exits, addresses or accounts to push refused traffic through is not a fix, and this guide will not help you do it. Turning a proxy or a VPN off to find out whether it caused your exit 7 is legitimate diagnosis. Turning one on to get past a rule that already said no is a different act.

#### FAQ
Q: What does curl error 7 mean?
A: curl could not establish a TCP connection to the address and port shown in the message. The name resolved, but no connection came back: the far end refused it, or the attempt failed some other way before anything was open. In practice that is a service not listening, a wrong port, a firewall rejecting the connection, a container boundary, or a proxy set in the environment that curl dutifully tried to use.
Q: Is curl error 7 a connection timeout?
A: No, and this is the most repeated mistake about these codes. Exit 7 is CURLE_COULDNT_CONNECT, a failure of the connect operation. The timeout is exit 28, CURLE_OPERATION_TIMEDOUT. The confusion comes from the message, which reports how many milliseconds the attempt took. That is elapsed time, not a limit: the same lab check printed 2020 ms on one run and values between 2017 ms and 2038 ms on five more, while a real deadline does not move.
Q: How do I fix curl error 7 on port 443?
A: Confirm the destination really serves TLS on 443, then confirm your side can reach it. Run the request with -v and see whether curl gets past the Trying line. If nothing on the machine can open outbound 443 while port 80 still works, the network you are calling from is filtering it, which is common on shared hosting and corporate networks, and that change belongs to whoever administers it. If only one application fails, check its environment for proxy variables first.
Q: What causes cURL error 7 in PHP or WordPress?
A: The same socket failure, surfaced through a CMS. PHP's curl extension is libcurl, so curl_errno returns the identical number. Usual causes: outbound filtering that blocks the web server but not your SSH session, a container boundary where 127.0.0.1 means the container itself, proxy variables inherited by PHP-FPM or set as WP_PROXY_HOST in wp-config.php, and SELinux with httpd_can_network_connect disabled. Reproduce the request in a shell as the web server's user to find out which.
Q: What is the difference between curl error 6 and curl error 7?
A: They are consecutive phases. Exit 6 means the hostname never became an IP address, so curl sent nothing to anyone and DNS is the only thing to investigate. Exit 7 means the address was known and the connection to it failed, so DNS worked and the problem is the port, the listener, a firewall, or an intermediary. Reading which of the two you got saves you from debugging the wrong layer.
Q: What does curl error 56 mean?
A: Exit 56 is CURLE_RECV_ERROR: the connection was established and then broke while curl was receiving data. The lab recorded it as Recv failure: Connection was reset. Because it proves the connect phase succeeded, it rules out everything on the exit 7 list. Look instead at a server process that died mid-response, an idle timeout closing a reused keep-alive connection, an appliance inspecting traffic in the path, or plain HTTP sent to a TLS port.
Q: Does curl return the HTTP status code as its exit code?
A: No. A 404 or a 500 is a completed transfer, so curl exits 0 and writes the error page into your output. That surprises people writing scripts. Add the fail flag to turn HTTP errors into a non-zero exit, or print the status explicitly with the write-out option, and keep exit codes for transport problems, which is what they describe.
Q: Will using a proxy fix curl error 7?
A: Rarely, and a proxy set by accident is itself a leading cause of exit 7 rather than a cure, since curl obeys proxy environment variables with no flag involved. A proxy changes the path a request takes; it does not grant access. If a server deliberately refused your request, that refusal is the answer, and the next step is the site owner or your network administrator. Turning an existing proxy off to test whether it is the trigger is the useful move.

### ECONNREFUSED: Meaning, the localhost Trap, and Fixes
URL: https://databay.com/blog/econnrefused
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

ECONNREFUSED means a reachable machine answered no. Read the address and port fields, rule out the localhost dual-stack trap, then fix the listener.

#### What ECONNREFUSED Actually Means
ECONNREFUSED is the code your operating system hands your program when a TCP connection attempt is answered with an explicit refusal. Your client dialed an address and a port, a machine there found no socket listening, and replied with a reset. RFC 9293 states the rule: if the connection does not exist, a reset is sent in response to any incoming segment except another reset.
The load-bearing word is answered. The name resolved, a route existed, and the host's stack replied, so everything up to the port worked. Either nothing is listening at that address and port, or a rule rejects connections to it. Your request was never seen: the kernel answered before any server process was involved, so there is no status code and no access log line to hunt for.
The reply also arrives at the speed of a round trip, not at the end of your connect deadline. Upvoted forum answers still claim this error means your request is timing out. It means the opposite: a timeout is silence, which is why raising timeouts and adding retries are wasted here.
ECONNREFUSED and the codes it gets confused withCodeOn the wireWhat it proves
ECONNREFUSEDAnswered with a resetReachable address, nothing serves that port
ETIMEDOUTNo answer before the deadlineDropped packets or an unreachable host: the timeout guide
ENOTFOUNDDNS returned no addressA wrong hostname or resolver: the name resolution guide
ECONNRESETAn open connection was torn downSomething objected after it existed: the reset guide

Browsers label the same event differently, so ERR_CONNECTION_REFUSED in Chrome and ECONNREFUSED in your terminal are one diagnosis.

#### Read the Error Object Before You Change Anything
Node attaches the operating system's own details to the thrown object, and the system error reference names the fields: code, errno, syscall, address and port. The recorded lab captured them on Node v24.14.0 against a loopback port with nothing listening, and this one-liner reproduces them:
node -e "require('node:net').connect(8124, '127.0.0.1').on('error', e => console.log(e.code, e.errno, e.syscall, e.address, e.port))"

ECONNREFUSED -4078 connect 127.0.0.1 8124
Read address and port first. They report where your process actually dialed rather than where you believe it dialed, which ends most investigations on the spot. An address of ::1 against a server that bound 127.0.0.1 is the dual-stack section below. A port of 3000 against a dev server that moved to 3001 is already solved.
syscall confirms the socket broke while opening rather than during a later read or write. errno is the field to ignore: it is the platform's own number, recorded as -4078 on the Windows machine that ran this lab and different on other systems. Branch on code, never on errno or the wording of message.
Wrappers push all of it one level down. fetch rejects with a TypeError whose message is only "fetch failed", and the lab confirmed the identical code sits in cause:
const error = await fetch('http://127.0.0.1:8124/').catch((e) => e);

error.message // 'fetch failed'
error.cause.code // 'ECONNREFUSED'
error.cause.port // 8124
Log the object, not the message.

#### Ask the Operating System Who Is Listening
Two observations split every remaining cause. First, ask the operating system what is bound, instead of trusting a terminal you read five minutes ago.
# Windows
netstat -ano | findstr :3000

# Linux
ss -ltnp | grep :3000

# macOS
lsof -nP -iTCP:3000 -sTCP:LISTEN
Read the address column, not just the port. 127.0.0.1:3000 is the IPv4 loopback only, [::1]:3000 is the IPv6 loopback only, and rows for 0.0.0.0:3000 and [::]:3000 together mean every interface.
Second, probe that exact address with curl in verbose mode: it prints the address it dialed, and exits with status 7.
curl -v http://127.0.0.1:8124/
* Trying 127.0.0.1:8124...
* connect to 127.0.0.1 port 8124 from 0.0.0.0 port 63101 failed: Connection refused
Each pairing rules something in. Nothing bound to the port means the service is not running or died at startup, so read its logs. A listener on another port means your client is wrong, or the service moved because its preferred port was taken. A listener whose address differs from the one curl printed is the bind trap below. A listener that matches while connections still fail means something sits in between: a proxy, a container boundary, or a firewall rule. That last case has a tell, because a rule that rejects sends the reset you are reading, while a rule that drops leaves you waiting on a timeout.

#### The localhost Dual-Stack Trap
Two things are true at once here: the server is unambiguously running, and the connection is unambiguously refused.
A listening socket owns one address and one port, not a port by itself. localhost is a name that maps to two addresses on any machine with IPv6 enabled, ::1 and 127.0.0.1. Your client picks one, your server picked one when it bound, and when the picks disagree the kernel sees a port with no listener.
The lab measured that in both directions on Node v24.14.0, five checks of five passing. A server bound to 127.0.0.1 accepted a connection at 127.0.0.1. That same server, still running and still bound, refused a connection to ::1 with ECONNREFUSED. A server bound to ::1 then refused 127.0.0.1, again with ECONNREFUSED. The trap runs both ways, and neither refusal hints that a healthy listener sits one address over.
So read the error as "nothing is listening at the address I asked for", not "the service is down". It also explains the intermittency: Node's net module has enabled address family autodetection by default since v20, the autoSelectFamily option, so a bare fetch to localhost often recovers while a Postgres driver handed an explicit literal cannot.
Two fixes cover nearly all of it. In development, dial 127.0.0.1 instead of the name, in every config file and connection string. Or bind the address you dial: passing a host to listen binds that address alone, while omitting it binds the unspecified address, which the same reference notes may also accept IPv4 on most systems.

#### The Ports People Get Wrong
When ECONNREFUSED names a well-known service port, there are only three answers: nothing is listening there, the service is listening somewhere else, or the port moved.
Default ports and why a connection to them is refusedServicePortUsual cause of the refusal
MySQL, MariaDB3306bind-address pinned to loopback, or a Unix client given localhost using a socket file instead of TCP
PostgreSQL5432listen_addresses left at localhost, or an upgrade leaving a second cluster on 5433
MongoDB27017bindIp still at the shipped loopback default, or mongod is not running
Redis6379a bind directive pinned to loopback
Node, Next, Vite3000, 5173the port was busy at startup, so the process moved and the URL did not
Django, Flask8000, 5000the development server binds 127.0.0.1 only

Databases ship bound to loopback on purpose, so the first connection from another machine or container is refused by design. The fix is a deliberate bind change on the server plus a matching firewall rule, never a client-side tweak.
A port you never chose can also appear, because a URL without an explicit port falls back to its scheme's default: https://localhost/api dials 443, where your dev server on 3000 is not listening.
Transfer clients hit the same wall through protocol confusion instead. FTP is 21, implicit FTPS is 990, and SFTP is a subsystem of SSH on 22, so a host offering only SFTP refuses 21 immediately.

#### Containers: Inside a Container, localhost Is the Container
Containers multiply the addresses in play, and they are the largest single source of ECONNREFUSED in modern stacks. Four mistakes account for almost all of it.
First and most common: inside a container, localhost is that container. A process dialing localhost:5432 asks its own loopback for Postgres, and the database is a different container with its own network namespace. Containers on a user-defined network reach each other by container name, as Docker's networking documentation describes, so the string is postgres:5432. The host is a separate case with its own name, host.docker.internal on Docker Desktop.
Second, a port that is not published is not reachable from the host. EXPOSE documents intent and publishes nothing, while -p 5432:5432, or a ports entry in Compose, creates the mapping. In docker ps, a real mapping shows both sides; a bare 5432/tcp means nothing was published.
Third, and this catches people who did the first two correctly: a service that binds 127.0.0.1 inside the container is refused even when the port is published, because published traffic arrives on the container's network interface, not its loopback. Listen on 0.0.0.0 instead.
Fourth, a container that is up is not a service that is ready. Compose's depends_on waits for the container to start, not for the process inside to accept connections, so an app that connects during boot is refused for the first seconds.

#### When Postman Refuses and the Browser Works
A URL that loads in your browser and fails in Postman or a database GUI is not producing the same connection, and the usual difference is a proxy.
Desktop API clients carry their own proxy settings and can also inherit the system proxy, and many command line tools and SDKs read HTTP_PROXY, HTTPS_PROXY and NO_PROXY from the environment. With any set, the tool dials the proxy instead of your service, so the refusal is the proxy's address, or a proxy declining a loopback destination it has no route to. Your error object settles it: if address is not the host you typed, you are looking at a proxy hop.
The diagnosis is one step: turn the tool's proxy off and retry. If it is already off, check the operating system's proxy settings and those variables, then exempt localhost and 127.0.0.1 so development traffic stops leaving the machine. The proxy and firewall checklist walks those settings, and a proxy that answers but fails to open the tunnel is a different failure. A VPN or a security suite changes the route too, so switching one off briefly is a legitimate way to test it.
If the refusal comes from a managed network's gateway, that is a policy your organization set: diagnose it, then take the evidence to whoever runs the network. Reconfiguring a client to route around a rule that refused you on purpose is not a fix.

#### Handling ECONNREFUSED in Code
Branch on the code, not the message. error.code === 'ECONNREFUSED' is stable across platforms and runtime versions, while message strings and errno values are not, and under fetch the code lives at error.cause.code.
Then decide what a refusal means for that dependency, because there are only two honest answers. If the service should already be running, fail immediately and loudly, with the address and port in the error you raise: cannot reach postgres at 127.0.0.1:5432 ends the investigation, while "database unavailable" costs the next person an hour. If it is expected to be starting, wait within a bound: a few attempts, backoff, a ceiling, then a real failure a supervisor can act on. Never retry in a tight loop, because a refusal is a complete answer that arrives at once.
const probe = (host, port) =>
new Promise((resolve, reject) => {
const socket = net.connect({ host, port });
socket.on('connect', () => { socket.end(); resolve(); });
socket.on('error', reject);
});

export async function waitForListener(host, port, attempts = 8) {
for (let i = 0; i < attempts; i += 1) {
try { return await probe(host, port); }
catch (error) {
if (error.code !== 'ECONNREFUSED') throw error;
await new Promise((go) => setTimeout(go, Math.min(200 * 2 ** i, 5000)));
}
}
throw new Error(`no listener on ${host}:${port} after ${attempts} attempts`);
}
A port that accepts a connection is still not a service ready to work, so where it matters probe what the dependency needs: a query, or a health endpoint your readiness check calls.

#### FAQ
Q: What does ECONNREFUSED mean?
A: A machine at the address you dialed answered your connection attempt with an explicit refusal instead of accepting it. Nothing is listening on that port, or a rule rejects connections to it. The name resolved and the host is reachable, so the problem is narrower than it looks: it lives at the port, not along the path.
Q: Is ECONNREFUSED the same as a timeout?
A: No, and this is the most common misreading. A timeout is silence, reported as ETIMEDOUT after your client waits out its full deadline. ECONNREFUSED is an immediate answer. That is why raising timeouts or enlarging a connection pool never helps: the refusal repeats identically until the listener or the rule behind it changes.
Q: Why do I get ECONNREFUSED on localhost when my server is running?
A: Almost always because the name and the bind address disagree. localhost maps to both ::1 and 127.0.0.1, and a server bound to one refuses connections to the other. The recorded lab reproduced that in both directions on Node v24.14.0. Dial 127.0.0.1 explicitly, or bind the address you actually connect to.
Q: What is errno -4078?
A: It is the platform specific number that accompanied ECONNREFUSED in the recorded lab run on Windows. The identical refusal carries a different number on other operating systems, which is why errno is the wrong field to branch on. Use error.code, then read address and port for the detail that solves the case.
Q: Why does Postman get ECONNREFUSED when my browser loads the same URL?
A: The two are not making the same connection. Desktop API clients have their own proxy settings and can also inherit the system proxy or the HTTP_PROXY variables, so the tool dials a proxy rather than your service. Turn the tool's proxy off and retry. Browser based clients are a separate case: they need a local agent before 127.0.0.1 is reachable.
Q: How do I fix ECONNREFUSED connecting to MongoDB, MySQL, or PostgreSQL?
A: Check that the service is running, then what address it bound, then the port: 27017, 3306 and 5432 respectively. All three ship bound to loopback, so connections from a container or another machine are refused by design. Watch for a Postgres upgrade leaving a second cluster on 5433.
Q: Why does my Docker container get ECONNREFUSED to localhost?
A: Because inside a container, localhost is that container, not your host and not another container. Use the container or service name for traffic between containers, and host.docker.internal to reach the host on Docker Desktop. Then confirm the port is published rather than merely exposed, and that the service inside listens on 0.0.0.0.
Q: Should my code retry on ECONNREFUSED?
A: Only when you know the target is still starting up. A refusal is a final answer, so a tight retry loop repeats it thousands of times a second while burning CPU and filling logs. For startup ordering use a bounded wait: a few attempts, exponential backoff, a ceiling, then fail with the address and port in the message.

### ERR_CONNECTION_REFUSED: What It Means and How to Fix It
URL: https://databay.com/blog/err-connection-refused
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-08-04.

ERR_CONNECTION_REFUSED means the server answered no, instantly. What refusal tells you, the localhost case, and ranked fixes for each side.

#### What ERR_CONNECTION_REFUSED Actually Means
ERR_CONNECTION_REFUSED is Chrome's name for one precise network event: your machine asked a server to open a TCP connection, and the other end answered with an explicit no. In TCP terms, defined in RFC 9293, the connection attempt was answered with a reset instead of an acceptance. That distinguishes it from its sibling errors: a refusal is an answer, while a timeout is silence, and the difference is diagnostic gold. In the recorded lab behind this article, connecting to a loopback port with nothing listening failed in 3 milliseconds with the explicit code ECONNREFUSED; a timeout, by contrast, burns its full deadline hearing nothing.
Only a few things produce that explicit no. Nothing is listening on the port you asked for, because the service is down, crashed, or bound to a different address. A firewall along the path is configured to actively reject the connection rather than silently drop it. Or the address your machine resolved is simply the wrong place, pointing at a host that has no such service, which is common right after DNS changes.
The refusal itself carries no HTML, no status code, and no explanation; the server-side software never saw the request at all. That is why the browser can only tell you the connection was refused, per Chrome's connection-error help, and why fixing it means finding out which machine said no and why, rather than staring at the error page.

#### First Split: One Site or Everything?
Thirty seconds of triage halves the search space. Open two or three unrelated sites. If everything is refused, the cause is on your side: a proxy setting pointing at a dead intermediary, a security suite whose filtering component crashed, a broken DNS answer for everything, or, on a managed network, policy. If exactly one site is refused, the cause is that site's side or specific to the path between you: their server is down, their DNS points at the wrong address, or something between you and them rejects that destination.
Two refinements sharpen the split. Try the failing site from another network, most easily a phone on mobile data: refused there too means the site itself is down for everyone, and third-party down-detector pages will usually agree. And try another browser: Chromium browsers share the operating system's proxy configuration, so a leftover proxy entry refuses connections identically in Chrome and Edge, while Firefox, with its own independent settings, sails through. That exact pattern, everything refused in one browser family and fine elsewhere, points at connection settings rather than at any website.
One special address deserves its own section below: when the refused site is localhost or 127.0.0.1, you are not debugging the internet at all, you are debugging your own machine, and the checklist is different.

#### Fixes for a Normal Website, Ranked by Likelihood
Work down this list in order; each step is cheap and each result narrows the cause. First, confirm it is not simply the site being down: test from a second network or a status checker, because no client-side setting fixes a server that is off. Second, check the operating system's proxy settings. A dead or leftover proxy is the classic everything-refused cause, since every request goes to an intermediary that no longer exists; the fix is removing the manual proxy and setup script, exactly as covered in the proxy and firewall guide. Third, flush stale DNS. If a site recently moved servers, your machine can keep connecting to the old address whose machine rightly refuses: ipconfig /flushdns on Windows or a router restart clears it, and switching the resolver is the durable version of the fix.
Fourth, disable browser extensions, especially anything that filters, redirects, or secures traffic, and retry in a clean profile. Fifth, look at your security suite: web-protection modules interpose themselves as local intermediaries, and a half-crashed one refuses everything the browser sends it. Temporarily disabling the module, or reinstalling the suite, isolates that in minutes.
What does not belong on the list: hammering reload, which changes nothing about a refusal, and clearing cookies, which lives one layer above the socket that got refused. The error happens before HTTP exists, so HTTP-level cleanup cannot touch it.

#### The Localhost Case Developers Hit Daily
ERR_CONNECTION_REFUSED on 127.0.0.1 or localhost is the most self-contained version of the error, and the lab reduces it to one sentence: the moment a listener existed on the previously refused port, the identical connect succeeded. Everything on this checklist is a variation of "nothing is listening where you are knocking".
The dev server is not running, exited on a compile error, or is still starting. The port is wrong: the app moved to 3001 because 3000 was busy, and the browser tab still says 3000. The bind address does not match the hostname: a server bound to a container-internal address or a specific interface — Node's net documentation covers how listen() picks its host — will refuse connections to 127.0.0.1, and there is a subtler split between localhost resolving to the IPv6 loopback while the server listens only on the IPv4 one, or the reverse. Inside containers, the port simply is not published to the host. And an HTTPS URL pointed at a plain-HTTP dev port, or vice versa, produces refusals and protocol errors that look identical from the browser.
The two commands that settle it: ask the OS who is listening, with netstat -ano | findstr :3000 on Windows or lsof -i :3000 elsewhere, and probe the socket directly with curl:
curl -v http://127.0.0.1:3000/
* Trying 127.0.0.1:3000...
* connect to 127.0.0.1 port 3000 failed: Connection refused
If netstat shows nothing on the port, start or fix the server. If it shows a listener on a different address or port, correct whichever side is wrong. That is the entire debugging loop.

#### Refused Through a Proxy: Which Hop Said No?
When traffic is configured to flow through a proxy, a refusal has two possible authors, and fixing the wrong one wastes an afternoon. Either the proxy itself refused your connection, or the proxy connected fine and the destination refused the proxy. The error page looks the same; the wire does not.
Test the hops separately. First, verify the proxy endpoint is alive and answering with the proxy checker, which separates "my intermediary is down" from everything else in one step. If the proxy is healthy, run the same request through it verbosely with curl's proxy flag and read where the failure lands: a refusal during the initial connection to the proxy address means the proxy hop, while an error after the tunnel is established means the destination side. Port and scheme mistakes cluster on the first hop, because sending HTTP proxy syntax to a SOCKS port gets rejected at the door; the proxy-port guide maps which ports speak which protocol.
Two proxy-specific causes round it out. Credentials: some gateways close unauthenticated connections outright rather than answering 407, which presents as a refusal. And provider-side changes: a retired gateway hostname or a rotated port refuses everything until the client configuration catches up with the provider's current documentation, so confirm the endpoint against the dashboard rather than memory before debugging deeper.

#### When Your Own Server Refuses Users
From the operator's chair, ERR_CONNECTION_REFUSED reports are good news wearing a scary name: refusals are explicit, immediate, and usually one configuration line away from the fix. The causes rank cleanly.
The service is not running: it crashed, failed to start after a deploy, or a health-checkless restart left nothing bound. The bind address is wrong: a server listening on the loopback interface serves itself perfectly and refuses the internet, the classic works-on-the-box failure; listening on all interfaces, or the correct public one, fixes it. The port disagrees with the client: TLS traffic aimed at the plain port, or a load balancer forwarding to a backend port nobody listens on. And the firewall layer: a rule that rejects a port answers exactly this error, and here the distinction between reject and drop matters operationally, because a reject rule produces instant, explicit refusals while a drop rule produces timeouts. Your users' error message tells you which rule they are hitting.
The diagnostic sequence mirrors the developer one, run from the server itself: check the process is alive, check what address and port it actually bound, then probe locally and from outside. A local success paired with an outside refusal isolates the firewall or the load balancer in one contrast. Refusals in this situation are also invisible to the application logs, because the kernel answered before the application existed in the conversation; absence of log lines is itself the clue.

#### Refused vs Timed Out vs Reset: the 10-Second Triage
Chrome's connection errors form a family, and telling the members apart is most of the diagnosis. The recorded lab makes the contrast concrete: the refused connect failed explicitly in 3 milliseconds, while silence burns the whole deadline before the client gives up.
Connection-error triage by wire behaviorErrorWhat happened on the wireWhat it tells you
ERR_CONNECTION_REFUSEDThe target answered the connection attempt with an explicit resetA machine is reachable but nothing serves that port, or a firewall actively rejects it
ERR_CONNECTION_TIMED_OUTNo answer of any kind before the deadlineThe path is broken, the host is gone, or a firewall silently drops packets
ERR_CONNECTION_RESETThe connection opened, then was torn down mid-conversationSomething objected after the connection existed: the server, a middlebox, or a filter

The refusal is the friendliest of the three, because it is fast and definite: you know the address was reachable and you know the port was closed to you. Use that. If a request that used to be refused starts timing out instead, a firewall changed from rejecting to dropping; if a refusal appears where pages loaded yesterday, a service died or a port moved. For the wider picture of how requests travel and where intermediaries sit in the chain, the proxy fundamentals guide walks the full path hop by hop.

#### FAQ
Q: What does ERR_CONNECTION_REFUSED mean?
A: Your machine reached out to a server and the target answered the connection attempt with an explicit refusal instead of accepting it. In practice: nothing is listening on that address and port, a firewall is actively rejecting the connection, or you are connecting to the wrong address entirely. It is an answer, not a hang, which is what separates it from a timeout.
Q: How do I fix ERR_CONNECTION_REFUSED quickly?
A: Check whether it affects one site or everything. One site: it is usually down or mid-migration, so test from another network and wait or contact the site. Everything: check the operating system's proxy settings for leftovers, flush DNS, disable filtering extensions, and test your security suite's web protection. Reloading harder and clearing cookies do not touch this error.
Q: Can I bypass ERR_CONNECTION_REFUSED?
A: There is nothing to bypass: the machine you contacted is not offering the service, so no client-side trick makes it appear. If a firewall on a network you use is rejecting the destination deliberately, that is the operator's policy decision, and the correct paths are the administrator or a network you control. If it is your own server, fix the listener or the rule.
Q: Why do I get ERR_CONNECTION_REFUSED on localhost?
A: Because nothing is listening where you are connecting. The dev server is not running or crashed, it moved to another port, it bound a different interface or only one of the IPv4 and IPv6 loopbacks, or the container did not publish the port. Ask the OS what is listening on the port, then start or rebind whichever side is wrong.
Q: Why does my phone show the error when my computer loads the site?
A: The two devices differ in resolver answers, network path, or configured intermediaries. A phone on mobile data uses a different network entirely, and a stale DNS answer or a filtering profile on one device produces a refusal the other never sees. Comparing the two, plus a third network if available, is the fastest way to localize which link is broken.
Q: Does ERR_CONNECTION_REFUSED mean I am blocked?
A: Sometimes. A firewall configured to reject connections produces exactly this error, and some networks reject specific destinations by policy. But the mundane causes, a down service, a wrong port, or a stale address, are far more common. A block you need lifted is a conversation with whoever runs the network or the site, not a technical workaround.

### ERR_CONNECTION_RESET: What It Means and How to Fix It
URL: https://databay.com/blog/err-connection-reset
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

ERR_CONNECTION_RESET means the connection opened and was then killed by a TCP reset. How to tell who sent it, and the fix that follows.

#### A Reset Means the Connection Was Alive
Every guide ranking for this error prescribes the same ritual: restart the router, switch DNS resolvers, clear the cache, reset the browser. Those steps address failures that happen before a connection exists, and this error reports the opposite. ERR_CONNECTION_RESET is Chrome's name for one precise wire event: a TCP segment carrying the RST flag arrived on a connection that already existed. Name resolution worked, the handshake completed, your request went out. Then something ended it.
Under RFC 9293 a reset aborts a synchronized connection immediately: no orderly shutdown, no guarantee that data in flight was delivered. Chromium's network error list defines -101 as a connection reset corresponding to a TCP RST, against -100 for a clean close corresponding to a TCP FIN.
That single fact carries the diagnosis. Sending a reset your system accepts means being party to the connection, with its exact addresses, ports, and sequence state, so a bystander cannot do it. The sender was the server, or something in the path holding one end.
Chrome connection errors by phaseChrome errorOn the wirePoints at
ERR_CONNECTION_TIMED_OUTNo answer to the handshakeDropped packets; host unreachable
ERR_CONNECTION_REFUSEDRefused before a connection existedNothing listening, or a firewall rejecting
ERR_CONNECTION_RESETA reset on an established connectionA server or middlebox killed it
ERR_CONNECTION_CLOSEDA clean close mid-requestOrderly ending, not an abort

Read that by phase, not by symptom. The first two rows are failures to establish; the last two happen after setup succeeded, which makes them a decision rather than an absence. A closed port also answers with a reset, but before any connection exists, so your system calls it a refusal.

#### What a Reset Does to a Half-Sent Response
The symptom people describe in forum threads, a page that renders halfway, an image that stops in a band of grey, a download that dies at eighty percent, is this mechanism showing through: a reset can land after the response starts.
A loopback lab reproduces the whole set against one server. Recorded on Node v24.14.0 on 2026-07-29:
node scripts/verify-connection-reset-lab.mjs

PASS baseline request → 200 complete (outcome=complete)
PASS accepted connection reset before response → ECONNRESET (outcome=ECONNRESET)
PASS reset mid-response → 200 headers received, then ECONNRESET (headers=200, outcome=ECONNRESET, bodyBytesKept=44)
PASS closed port → ECONNREFUSED, a different error at a different phase (outcome=ECONNREFUSED)

checks passed: 4/4
Read the third line. The response genuinely started: status 200, headers delivered, a declared body of 1000 bytes. Then the reset arrived, the client kept 44 bytes, and the other 956 never came. The line above is the same server resetting before it wrote anything, which yields no status at all; the line below is a port with nothing listening, failing earlier with a different code. Same client, same host, same second: only the peer changed.
How much survives is not fixed, because a reset can make the receiving system discard data it buffered but never handed to the application, so the same URL fails at a different point each time. Get that detail on the site failing you with curl -v, documented in the curl manual: read which line is the last successful one, and whether it fails every time or intermittently.

#### Cause One: Software Inside Your Connection
Start with the participant you can inspect: software on your own machine. On personal devices this is the most common cause, and the one the popular guides never name. The two community answers that actually solved this error landed here, on a VPN client's web-protection feature and on a service running on a restricted network. Neither was a router or DNS fault.
Security products cannot read HTTPS from the side. An antivirus suite with web protection, a VPN client's threat-blocking module, or a corporate gateway installs its own root certificate, terminates your TLS session, and opens a second one to the real server. That is structurally the position a proxy server occupies: two connections, one intermediary holding both ends, which is exactly what lets it reset you.
Three things make it use that ability. A rule matches on category, reputation, or signature, and the product ends the connection instead of serving a block notice. Or it cannot handle what it sees: a certificate chain it refuses, an unfamiliar TLS extension, an unimplemented protocol version. Or it broke in an update, which is why resets that start on one date trace so often to a security product release.
Test it without leaving yourself exposed. Pause the HTTPS-scanning module rather than the whole product, load the one page, then switch it straight back on. If the page loaded while it was paused, the durable fix is an exception rule or a vendor update, not running unprotected. An intermediary you configured yourself is a participant too: verify its exit with the proxy checker, and the proxy versus VPN comparison covers what each sits inside.
If the inspector belongs to your employer or school, stop at the diagnosis: that inspection is deliberate policy on equipment you do not administer, and the reset is the policy working. Send IT the URL and timestamp.

#### Four Comparisons That Narrow It Fast
Change one variable at a time before you change any setting.
One site or all sites. Resets everywhere point at something on your machine or network that touches every connection. Resets on one site while the rest of the web loads point at that site, its edge, or a rule naming it.
One browser or all browsers. Chrome, Edge, Brave, and Opera are all Chromium and all read the operating system's proxy configuration by default, so they tend to fail together, while Firefox keeps its own connection settings and certificate store. Failing everywhere puts the cause below the browser. Failing across the Chromium family while Firefox works points at the system proxy configuration, or at an installed root certificate. Failing in one browser alone makes it that profile: retest in a fresh profile with extensions off.
One network, or one device. Put the same laptop on a phone hotspot: working there moves the investigation onto the failing network's equipment and its policy. If a phone on that same Wi-Fi loads the page, your machine's software owns the problem.
Then fix in order of likelihood: inspecting software first, then a stale system proxy entry an uninstalled VPN or security tool left pointing at nothing, then the network. Cache clearing, DNS changes, and browser resets belong last, because none of them changes who sends a reset.

#### The IPv6 Path That Resets While IPv4 Works
A dual-stack machine has two routes to any site publishing both an A and an AAAA record, and they fail independently. RFC 8305, Happy Eyeballs v2, protects you from a broken IPv6 path by giving IPv6 a short head start and racing IPv4 behind it, so a v6 attempt that fails or stalls costs a fraction of a second.
The gap is that the race only covers setting the connection up. RFC 8305 says so: it handles initial connection failures at the IP layer, while other failures can still affect the connection it picked. If the IPv6 handshake succeeds and the reset arrives afterwards, from a tunnel endpoint, a transition relay, or a firewall that filters v6 differently from v4, no fallback is left. Hence the signature complaint: a few sites reset consistently on one network while everything else is fine.
Two commands settle it, using curl's address-family flags:
curl -4 -sSI https://example.com/
curl -6 -sSI https://example.com/
If IPv4 returns headers and IPv6 resets, you have found the layer, and the IP diagnostic confirms which family a site saw.
Then repair the path, not the symptom. Windows turns on 6to4 tunneling by default whenever an interface holds a public IPv4 address, and Microsoft's IPv6 configuration guidance covers switching those tunnel interfaces off. The same page says disabling IPv6 itself is not recommended, because Windows components depend on it, and points instead at a prefix policy preferring IPv4. Advice that disables a networking service does the same thing indirectly, and repairs nothing.

#### Wi-Fi, Mobile Data, and the Network Reset Ritual
Two unrelated mechanisms get filed under one complaint on wireless links.
The first is connection state that stopped existing. Routers, office firewalls, and mobile carriers keep a table mapping your connection to a public address, and those entries expire. When one is reaped while your connection sits idle, or your laptop roams and its address changes, your next packet reaches a device with no record of that conversation. The standard answer to a segment matching no connection is a reset. That is why long downloads, video calls, and websockets break on a weak link while ordinary page loads look fine.
The second is other people's equipment. Carrier networks, hotel and airport Wi-Fi, and guest networks commonly run transparent filters and captive portals, which is the previous section again on premises you do not control. An unfinished captive portal sign-in is the most common version, and loading any plain HTTP page usually pulls its screen into view.
That mix is why resetting network settings sometimes appears to work. It clears saved networks, a stale lease, a manual proxy or DNS entry, an on-device VPN, and any configuration profile at once, so if one of those was the cause the symptom vanishes and you never learn which. If none was, you have lost every saved Wi-Fi password for nothing. Do the targeted version first: switch off any VPN or ad-blocking app for one request, since many run as a local VPN by design, then check the network's manual proxy setting, which on Android lives under the saved network's advanced options.

#### localhost and Development Resets
On 127.0.0.1 there is no ISP, no router, and no CDN. There are two participants and you wrote one, which makes this the most solvable version.
First, the server died mid-response, which is exactly what the lab's third check reproduces. An out-of-memory kill, a dev server restarting on a file change, or a process manager recycling a worker after a request limit all abort connections in the middle of answering. Read process exit codes and restart timestamps rather than the request log, because the request rarely got far enough to be logged.
Second, protocol mismatch. Plain HTTP sent to a TLS port, or an https:// URL aimed at a plaintext listener, hands the listener bytes it cannot read as a handshake, and many servers abort instead of answering. If one scheme works on a port and the other resets, that was it. The port and protocol guide covers which listener expects which conversation.
Third, the keep-alive race, the intermittent one that costs teams days. Your client holds a pooled connection open and the server closes it on its own idle timeout. If your client picks that connection at the moment the server's timer fires, the request lands on a socket the server has already discarded. It clusters in quiet periods, when connections idle long enough to time out. Set your client's idle timeout below the server's, and below any proxy between them, then retry an idempotent request once.
Any dev proxy, tunnel, or container port forward is one more participant that can reset, so test the service directly first.

#### When Your Own Site Resets Visitors
Resets you cause usually leave nothing in the application log. The connection died below your framework or was killed by a layer in front of it, so as far as your code is concerned the request never finished or never existed. The missing line tells you which layer to inspect. Count connection-level failures separately from status codes, because a reset never becomes one.
In rough order of frequency. Workers dying mid-response: out-of-memory kills, a process manager recycling on a request cap, or a deploy that restarts without draining connections in flight. That shows up as a steady small percentage of failures rather than an outage, and the evidence sits in kernel and process-manager logs.
Then TLS termination and limits: a load balancer sending decrypted traffic to a backend that expects TLS or the reverse, an SNI mismatch, a minimum protocol version that cuts off older clients, or a request-size limit that drops the connection instead of returning a status code. The tell for the first three is failure confined to a subset of clients.
Last, a decision rather than a fault. Firewall and anti-abuse products usually let a rule either serve a block response or drop the connection, and dropping is worse for both sides: your visitor gets an unexplained browser error with nothing to act on, and you get no status code to count. If you filter traffic, answer with a status code and a short page naming the policy and a contact.

#### FAQ
Q: What does ERR_CONNECTION_RESET mean?
A: It means your browser connected successfully and the connection was then aborted mid-conversation by a TCP reset. That is different from a refusal, where no connection was ever made, and from a timeout, where nothing answered at all. Only a participant in a live connection can send a reset, so the sender was the server or something inspecting the traffic in between.
Q: Can a VPN or antivirus cause ERR_CONNECTION_RESET?
A: Yes, and on personal devices it is the most common cause. Products that inspect HTTPS terminate your connection themselves and open a second one to the server, which puts them in position to reset you on a rule match, a certificate they reject, or a protocol they cannot parse. Pause the web-protection module alone, load the page once, then re-enable it.
Q: Does changing DNS to a public resolver fix ERR_CONNECTION_RESET?
A: Almost never. DNS runs before any connection exists, and this error happens after one was established, so the name resolved correctly by definition. Changing resolvers is standard advice because it is harmless and easy, not because it addresses the mechanism. Spend the same two minutes on a verbose curl run, which tells you exactly which phase failed.
Q: Why does the error appear in Chrome but not Firefox?
A: Two differences explain most cases. Chromium browsers read the operating system's proxy configuration while Firefox keeps its own, so a leftover system proxy entry breaks Chrome, Edge, and Brave together and leaves Firefox working. They also ship different TLS libraries, so an inspecting middlebox that mishandles one browser's handshake and not the other produces exactly this pattern.
Q: How do I fix ERR_CONNECTION_RESET on Android or Chrome mobile?
A: Test the same page on mobile data with Wi-Fi off, then on Wi-Fi. If only one network fails, that network is the fault rather than the phone. Then check for a VPN, ad blocker, or filtering app, since many run as a local VPN and sit inside every connection. Keep resetting network settings for last: it rebuilds everything but erases your saved Wi-Fi networks and VPN profiles.
Q: Why does localhost reset the connection?
A: Your own server ended it. The usual causes are a process that crashed or was recycled while responding, a protocol mismatch such as plain HTTP sent to a TLS port, a request body over a configured size limit, and keep-alive races where your client reuses a pooled connection just as the server's idle timer closes it.
Q: Does ERR_CONNECTION_RESET mean I am blocked?
A: Sometimes. A filter or firewall configured to cut connections rather than serve a block page produces exactly this error, and that is a deliberate policy decision by whoever runs the network or the site. Treat it as a stop signal. If you need the access for legitimate work, the route is the network administrator or the site owner, not a technical workaround.

### ERR_CONNECTION_TIMED_OUT: What It Is and How to Fix It
URL: https://databay.com/blog/err-connection-timed-out
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-08-04.

ERR_CONNECTION_TIMED_OUT means pure silence before the browser gave up. How silence differs from refusal and the fixes that match each cause.

#### Timed Out Means Nobody Answered at All
ERR_CONNECTION_TIMED_OUT is the browser reporting silence. It sent the connection attempt, waited, retransmitted per the TCP rules in RFC 9293, and heard nothing back before its patience ran out: no acceptance, and crucially no refusal either. Chrome's page for the error, listed in its connection-error help, appears after roughly half a minute of that.
The recorded lab behind this article stages the contrast that makes the error readable. A connection aimed into the TEST-NET documentation range, which RFC 5737 reserves precisely so packets go nowhere, produced nothing for a full three seconds until the client's own deadline fired. The identical attempt at a closed local port failed in about a millisecond with an explicit refusal. Same error page family in a browser, opposite meanings on the wire: refusal proves a machine answered you, silence proves nothing did.
Here is that recorded run, exactly as the lab printed it:
$ node verify-connection-timeout-lab.mjs # Node v24.14.0
PASS connect to unroutable TEST-NET address → pure silence until the deadline (outcome=TIMEOUT after 3008ms)
PASS closed local port → immediate ECONNREFUSED, not a timeout (outcome=ECONNREFUSED after 1ms)
PASS server accepts, then stays silent → response-phase timeout (outcome=RESPONSE_TIMEOUT)

checks passed: 3/3
Silence has only a few honest sources. The packets never reach the destination, because a route is broken or the address points at nothing, which the lab's unroutable range models exactly. The destination is off. Or, very commonly on filtered networks, a firewall is configured to drop traffic silently rather than reject it, which manufactures timeouts on purpose. Every fix below is about working out which of those silences you are hearing.

#### One Site or Everything: the First Fork
As with every connection-family error, thirty seconds of scoping halves the problem. If every site times out, your machine's path to the internet is broken at the first hops: the Wi-Fi link, the router, the modem, or the upstream provider. If exactly one site times out while the rest of the web loads, your general connectivity is fine and something specific to that destination, or to the path between you and it, is eating packets.
The everything case has an honest, boring fix ladder and it starts at the router. Restart it, and restart the modem if separate, because consumer routing gear genuinely does wedge in states where some or all flows silently die. Test wired if you can, or from another device on the same network: two devices failing identically moves the blame from your computer to the network gear, one device failing alone moves it onto that device's stack or its security software.
The one-site case earns the sharper tools. Test the site from a phone on mobile data: loading fine there means the site is up and the silence lives on your network's path to it or in its treatment of your network's address; timing out on mobile data too means the site or its infrastructure is down for everyone, and waiting beats fiddling. The "for one website" variant of this error is common enough that the cause deserves naming: it is usually a filter, a broken route, or the destination itself, and never your cookies.

#### Visitor Fixes, Ranked by Hit Rate
First, the router and modem restart described above; it is ranked first because it is free and genuinely fixes the everything-times-out case more often than anything else. Second, check for leftover network middlemen on your machine: an OS proxy entry pointing at a dead intermediary makes requests wait on something that will never answer, and a VPN client that lost its tunnel but kept its routes sends traffic into a black hole, both producing exactly this silence. Turning those off, or fixing their configuration, restores the direct path.
Third, the resolver. A DNS answer pointing at a stale or wrong address sends your connection attempts to a machine that may silently ignore them; flushing the local cache with ipconfig /flushdns and, more durably, switching to a resolver you trust removes that class. Fourth, security software: firewall and web-protection layers that hang mid-inspection convert working connections into timeouts, and briefly disabling the web-protection module isolates that in minutes; re-enable it after the test either way.
Fifth and often skipped: the network you are on may be filtering silently by policy. Offices, schools, and some public Wi-Fi drop traffic to whole categories of destinations, and a drop-based filter presents as timeouts rather than block pages. The diagnostic is the mobile-data comparison; the remedy on a network you do not run is the administrator, not a workaround, exactly as with every managed-network case in this cluster.

#### The Drop vs Reject Distinction
Firewalls end conversations in one of two configured styles, and the error you see is the configuration leaking through. A reject rule answers unwanted traffic with an explicit refusal, which surfaces as ERR_CONNECTION_REFUSED in milliseconds. A drop rule discards the packets and says nothing, which surfaces as this error after the browser exhausts its patience. Same policy intent, opposite wire manners.
Read diagnostically, that distinction is a gift. A destination that used to refuse instantly and now times out means a rule changed from reject to drop, or a new silent filter appeared on the path. A timeout that afflicts exactly one port while others on the same host answer, for example the proxy port hanging while the web port loads, means something between you and that port is dropping selectively; the proxy-port guide covers why nonstandard ports attract exactly that treatment on managed networks. And a timeout that appears only from one network while every other network connects fine is as close as networking gets to a signed confession from that network's filtering.
Operators choose drop deliberately because silence is cheaper and reveals less to scanners, which is their right on their own edge. The flip side belongs in this guide's usual boundary: on networks you do not administer, silent filtering is policy, and the legitimate responses are asking the administrator, using a network you control, or accepting the restriction. Reading the silence is diagnosis; routing around someone's firewall is not a fix this site teaches.

#### Accepted, Then Silence: the Server-Side Hang
The lab's third check stages a subtler failure that users experience identically: a server that accepts the connection and then never says a word. The TCP handshake succeeds, so the connection phase is fine, and then the response never comes; the client's response deadline, not its connection deadline, is what finally fires. In the recorded run the connect succeeded instantly and the silence began afterward, per the socket semantics in the Node.js net documentation.
For a site operator, that shape is a different diagnosis from the pure connection timeout. Connections that never arrive point at routing, DNS, or filtering in front of the machine. Connections that arrive and hang point at the machine itself: an application server with every worker busy, a backend waiting forever on a database or upstream API without its own deadline, or a process wedged after a deploy. The fixes are correspondingly internal: health checks that watch response time rather than port openness, deadlines on every upstream call the application makes, and worker pools sized against real concurrency so overload sheds load quickly instead of hanging everyone.
The general lesson the lab makes concrete: a timeout is not one error but a family, and where the silence begins, before the handshake or after it, tells you which half of the world to debug. Clients that record connect time and first-byte time separately hand you that distinction for free, which is exactly why the collection-pipeline section below insists on both deadlines.

#### Timeouts in Data Collection Pipelines
For automated clients, timeouts are not an anomaly to eliminate but a budget line to engineer. Every request needs two explicit deadlines, connect and response, because the lab's two silences are different events: a connect timeout flags path or filtering problems, while a response timeout flags an overloaded or hung source. Cap retries, back off with jitter between attempts, and log the two timings separately so a shift in where the silence starts shows up in your metrics rather than in a 3 a.m. investigation.
Three pipeline-specific rules keep timeout handling honest. First, a timeout is not a rotation trigger: switching exits because a source went silent multiplies load against something that is struggling or filtering, and the stop-or-back-off discipline that applies to explicit refusals applies to silence at least as strongly. Second, timeouts consume budget: a request that burns a 10-second deadline costs more wall-clock than a fast failure, so sources that develop chronic slowness deserve a raised deadline and lowered concurrency, not more parallel attempts. Third, verify the infrastructure before blaming the source: when traffic flows through a proxy, test the exit itself with the proxy checker, because a dead or overloaded exit produces the same silence as a dead destination, and confusing the two wastes a debugging session.
For the wider map of who sits between a client and a destination, and therefore where silence can be born, the proxy fundamentals guide walks the whole chain.

#### FAQ
Q: What does ERR_CONNECTION_TIMED_OUT mean?
A: The browser sent a connection attempt and heard nothing at all before giving up: no acceptance, no refusal. That silence means the packets never reached the destination, the destination is off, or a firewall along the path drops traffic without answering. It is the opposite of ERR_CONNECTION_REFUSED, which is an explicit, near-instant no.
Q: How do I fix ERR_CONNECTION_TIMED_OUT in Chrome?
A: If every site times out, restart the router and modem, test another device, and check for leftover VPN or proxy configuration. If one site times out, compare on mobile data: working there points at your network's path or filtering, failing there means the site itself is down. Flushing DNS and briefly testing with security-suite web protection off cover the rest.
Q: Why does only one website time out?
A: Your connectivity is fine and something specific is silent: the site is down, a route between you and it is broken, or a filter on your network drops that destination without answering. The mobile-data comparison settles it in one test. Cookies, cache, and browser settings are almost never involved in a pure connection timeout.
Q: Can a VPN or proxy cause this error?
A: Yes, and it is one of the most common desktop causes. A VPN that lost its tunnel but kept its routes, or an OS proxy entry pointing at a dead intermediary, sends traffic somewhere that will never answer, which is exactly this silence. Disable or repair the middleman and the direct path usually returns immediately.
Q: How long does Chrome wait before showing the error?
A: On the order of half a minute for the connection phase, during which the operating system retransmits the attempt several times. Automated clients should not copy that patience: explicit connect and response deadlines of a few seconds, with capped retries and backoff, give the same information faster and without hanging a pipeline on a silent source.
Q: Is a timeout the same as being blocked?
A: Sometimes it is a block wearing silence: firewalls configured to drop rather than reject manufacture timeouts on purpose, and managed networks often filter that way. But broken routes, dead servers, and wedged routers produce the identical symptom. Where it is policy on a network you do not run, the answer is the administrator, not a workaround.

### ERR_NAME_NOT_RESOLVED: What It Means and How to Fix It
URL: https://databay.com/blog/err-name-not-resolved
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

ERR_NAME_NOT_RESOLVED means DNS returned no address, so your browser never connected. Two commands that localize it, then the fixes that matter.

#### What ERR_NAME_NOT_RESOLVED Actually Means
ERR_NAME_NOT_RESOLVED is Chromium's name for a failure that happened before any connection existed. In Chromium's network error list it is error -105, the host name could not be resolved. Your browser asked the system to turn a hostname into an IP address, and the answer came back with no address in it. So there was nothing to connect to: it never opened a socket, never sent a packet toward the site, and never learned whether that site is up, down, or refusing you. The error describes a lookup, not a website.
That one fact reorders every fix list you will read elsewhere. Reloading retries nothing at the site, because nothing reached it. Checking whether the site is down answers a question the error never asked. The lab behind this guide records it exactly: a request to a name guaranteed never to resolve failed with ENOTFOUND underneath, and no connection was attempted.
Chrome sometimes shows DNS_PROBE_FINISHED_NXDOMAIN instead, the narrower case. NXDOMAIN, the Name Error response code described in RFC 9499, is an authoritative statement that the name does not exist. ERR_NAME_NOT_RESOLVED is the wider bucket, covering a resolver that failed, refused, or never answered; Chromium files that case separately as ERR_NAME_RESOLUTION_FAILED, error -137.
One line of on-screen text is worth naming, because people search for it. Under the code, Chrome prints suggestions that begin with checking the connection and checking the proxy, firewall, and DNS configuration. That is generic text attached to a family of network errors, not tests Chrome ran. If other sites load, your connection is fine.

#### Prove It in Sixty Seconds: Name Versus Address
Two questions separate every cause: does the name have an address, and can you reach the host without using a name. Substitute your own hostname.
# 1. Ask the resolver this machine is actually using.
nslookup shop.example.com

# 2. Ask a second resolver: does the name exist anywhere?
nslookup shop.example.com 1.1.1.1

# On macOS or Linux, ask for each address family separately.
dig +short shop.example.com A
dig +short shop.example.com AAAA

# 3. Skip DNS: pin an address step 2 returned, then connect.
curl -sSI --resolve shop.example.com:443:203.0.113.10 https://shop.example.com/
Step three is the one nobody else tells you to run, and --resolve is the right form of it: you supply the address while the request still carries the real hostname, so virtual hosting and TLS behave normally.
The lab for this guide records that split as four checks on Node v24.14.0, built around a name in the .invalid top-level domain that RFC 2606 reserves so it can never exist:
PASS reserved .invalid name -> ENOTFOUND (no address, ever) (outcome=ENOTFOUND)
PASS fetch to the unresolvable name -> ENOTFOUND underneath (no connect attempted) (cause=ENOTFOUND)
PASS localhost resolves (contrast: resolution succeeds) (address=::1)
PASS IP literal connects with no DNS involved (the DNS-vs-connectivity test) (outcome=response)

checks passed: 4/4
Read those four lines as your template. The name had no address, a fact about DNS and not about any server, and the client never attempted a connection, exactly as your browser did not. A name that does exist resolved in the same run, and an address with no name still reached a live service: that pair is the DNS-versus-connectivity test.
One caveat: nslookup and dig ask your machine's resolver. Software configured to use a proxy may hand the hostname to the proxy instead, so a name can fail in one application and resolve fine in your shell. The proxy server guide traces which side resolves what.
What each observation rules in or outWhat you observeWhat it meansWhere the fix lives
Name fails, the host answers on a pinned addressResolution alone is broken; path and server are fineYour resolver, your caches, or the zone
Name fails, the pinned address is unreachable tooConnectivity, not just DNSThe local network first, then the route
Fails on your resolver, resolves on anotherYours cannot see the name, or will not answer for itResolver choice, VPN or secure DNS, or operator policy
Fails on every resolver and every networkThe name has no address at allSpelling, or the domain's own records
The shell resolves it, Chrome alone failsChrome's own host cache or its secure DNS settingChrome, not the network
Fails on mobile data but not on Wi-FiPer-network resolver, private DNS, or an IPv6-only pathThat network's DNS settings

#### The Most Likely Cause: the Name Has No Address
Ranked honestly, the most frequent cause is the least technical: the name does not exist. A typo is invisible to you and total to a resolver, which does no spell checking and no guessing. A lapsed domain stops resolving the day its records are withdrawn. A staging host or a retired API name disappears the moment its record is deleted, while the parent domain keeps working and makes the failure look like a partial outage.
The lab's first check is that case in pure form. A name in the reserved .invalid top-level domain can never exist, and the lookup returned ENOTFOUND. Say the consequence plainly, because most pages about this error imply the opposite: no browser setting, cache flush, resolver change, router reboot, or reinstall invents an address for a name that has none. If the second resolver also comes back empty and the name fails from a phone on mobile data, this is your case, and the fix is the correct spelling or it belongs to whoever owns the domain.
One variant catches experienced people: internal hostnames resolve only on the network or VPN that carries their private zone, so away from it the name genuinely has no public address and the error is correct rather than broken. Container and service-discovery names behave the same way.

#### Chrome Keeps a DNS Cache of Its Own
Chrome does not ask the operating system every time. It keeps its own in-process host cache and can perform its own encrypted lookups, so Chrome and the rest of your machine can hold different answers for the same name at once. That is the whole explanation for the most reported symptom here: the site loads in Firefox, the name resolves at the command line, and Chrome alone refuses.
So clear both caches, not one. The system resolver cache goes first:
# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
resolvectl flush-caches
None of those touch Chrome's copy. For that, open chrome://net-internals/#dns and clear the host cache, then chrome://net-internals/#sockets and flush the socket pools, because a pooled connection can outlive a cleared cache. Clearing one side and not the other is why a name keeps failing after a flush that looked successful.
Secure DNS is the second Chrome-only cause and now the more common one. The setting at chrome://settings/security can send lookups to a DNS-over-HTTPS provider of Chrome's own instead of the resolver your network handed out. One unreachable from the network you just joined, or one that knows nothing about your employer's internal names, breaks Chrome and nothing else. Set it to your system resolver and Chrome asks what the rest of the machine asks.
Third, extensions holding proxy or network permissions, VPN add-ons especially, can route Chrome's lookups down a path of their own. Open a guest window, which runs with no extensions: if the site loads there, the fault is that profile, not DNS.

#### Resolver-Level Causes, Ranked
If the name resolves somewhere but not for you, the fault is in the resolver path, in rough order of likelihood.
First, your ISP's resolver having a bad moment. Partial failures are ordinary, often hit only a subset of names, and usually clear within hours. The tell is step two: empty from your resolver, fine on a second one. Restarting the home router helps here for a real reason: it is the DNS forwarder your devices were handed, and its cache is what went bad.
Second, a resolver that answers this way deliberately. Filtering resolvers run by an ISP, a security suite, or your own network-wide blocker return NXDOMAIN or a sinkhole address for listed names. Your hosts file does the same one step earlier, since it is read before DNS: a stale line pointing a name at 0.0.0.0 breaks a site on one machine only.
Third, a VPN or corporate client that replaced your resolver. A tunnel pushes its own DNS servers so internal names resolve while it is connected, and split-tunnel or DNS-scope settings can just as easily send public names to a resolver that will not answer them. Disconnect and retest. If it fails only with the tunnel up, that setting belongs to the client, or to whoever administers a managed device. The proxy and VPN comparison covers why the two relocate resolution differently.
Fourth, a proxy set to the wrong resolution mode. Your client either resolves the hostname itself or passes it along for the proxy to resolve, which in a curl proxy URL is socks5 against socks5h. Resolving locally for a name only the proxy's network can see fails the lookup for a reachable host. The HTTP and SOCKS5 comparison explains which mode resolves where.
Fifth, filtering on a network you do not run. Schools, workplaces, hotels, and guest Wi-Fi commonly express their acceptable-use policy in the resolver, and many block queries to other resolvers as well, so even the second-resolver test times out. That combination is itself the diagnosis: the operator is withholding the name on purpose, and the browser is reporting a configured answer correctly. Treat it the way you would treat a 403. It is a decision, not a fault, and the next step is the administrator who set it. This guide does not cover changing resolvers to get a different answer on a network someone else administers.

#### Phones, Wi-Fi, and the Dual-Stack Trap
Every network hands a phone its own resolver, which is why this error is usually network-specific there: it fails on one Wi-Fi and works on the next. When it follows the network rather than the device, you have localized it.
When it follows the device, one Android setting causes most reports. Private DNS, under Network and internet, points the whole phone at a DNS-over-TLS provider by hostname, so when the Wi-Fi you just joined cannot reach that provider, every lookup fails at once while the phone still looks connected. It survives reboots and reinstalls, which is why the error looks permanent; set it back to automatic on a phone you own and retest. On iPhone, look at the per-network Configure DNS screen, any profile installed by an employer or school, and iCloud Private Relay.
The dual-stack case is the one almost nobody names. The lab's third check resolved localhost to ::1, the IPv6 loopback, on a machine that also has 127.0.0.1: a name resolves to whichever address family is on offer, and IPv4 is not a default. Mobile networks increasingly run IPv6-only paths that depend on DNS64, specified in RFC 6147: the network's own resolver synthesizes an IPv6 answer for a destination that publishes only an A record. Replace that resolver with a public one through Private DNS and the synthesis stops, so IPv4-only sites resolve to nothing usable on cellular while working normally over Wi-Fi. The same shape appears from the other end when nameservers answer A queries but fail on AAAA: IPv6-only clients get no address while dual-stack clients never notice. The IP diagnostic shows which family your network used.

#### When the Name Is Yours: the Zone Owner's Checklist
If the failing name is one you publish, resolvers got no usable answer, and there are only a few ways to produce that. Test from outside your network, because your caches are not what visitors have.
The first is a missing record. A hostname needs an A record, an AAAA record, or a CNAME, and without one your DNS provider correctly answers that there is nothing there, the “no A, AAAA or CNAME record found” message that fills support forums. Check the apex and the www host separately, and check any subdomain that shows in a hosting or CDN panel but was never written into the served zone.
The second is delegation, and it explains most reports of adding a record hours ago with nothing changing. Your registrar publishes a set of nameservers for the domain, and only the zone on those nameservers is ever queried. Records added in a panel whose nameservers are not the ones the registrar lists are real, correct, and consulted by nobody. dig +trace example.com walks the delegation down from the root and shows where queries land.
The third is negative caching, where the usual intuition is backwards. Nothing propagates. Resolvers cache, and they cache absence too: when a name does not exist, RFC 2308 has the authoritative server return the zone's SOA record so resolvers know how long to remember that, with the lifetime drawn from the SOA minimum field. A generous minimum keeps other people's resolvers calling your new hostname nonexistent for hours after you created it, and nothing makes them forget early. Lower it, and the record TTLs, a day before a launch.
One cause hides from every propagation checker: a DNSSEC mismatch, typically a DS record left at the registrar after moving providers, makes validating resolvers refuse to return an answer at all, so the name works on some resolvers and fails on others.

#### FAQ
Q: What does ERR_NAME_NOT_RESOLVED mean?
A: It means DNS returned no address for the hostname you asked for, so your browser never opened a connection and never contacted the site. The error describes a failed name lookup, not a failed website. Because nothing was sent, the browser learned nothing about whether that site is up, down, or working perfectly for everyone else.
Q: How do I fix ERR_NAME_NOT_RESOLVED?
A: Retype the address by hand first, since typos and dead names are the most common cause. Then look the name up on a second resolver to learn whether it exists anywhere. If it exists everywhere but not for you, flush the system DNS cache and Chrome's own host cache, then retest with secure DNS set to your system resolver and any VPN disconnected.
Q: How do I bypass ERR_NAME_NOT_RESOLVED?
A: There is nothing to bypass. In the common case the name simply has no address, and no client-side change creates one. In the other case a resolver is deliberately withholding it, which is a policy set by whoever runs that network, so the answer is the administrator rather than a workaround. Diagnose which of the two you have, then act accordingly.
Q: Why does the site load in Firefox but not in Chrome?
A: Chrome keeps its own host cache separate from the operating system's, and it can send lookups to its own DNS-over-HTTPS provider instead of the resolver your network supplied. Either can hold a failing answer while the rest of the machine is fine. Flushing only the system cache leaves Chrome's copy untouched, which is why the page keeps failing after ipconfig /flushdns.
Q: Why do I get err_name_not_resolved on Android or iPhone?
A: Phones change resolvers every time they change networks, so the error usually follows the network rather than the device. When it follows the device, check Android's Private DNS setting under Network and internet, and on iPhone check the per-network Configure DNS screen, any installed configuration profile, and any VPN app left half-connected.
Q: Why does it start when I connect to a VPN?
A: A VPN or corporate client normally replaces your DNS servers while connected so that internal names resolve. Depending on split-tunnel and DNS-scope settings, public names can end up at a resolver that will not answer them, so names that worked a minute earlier stop. Disconnect and retest to confirm, then check that client's DNS settings or ask whoever administers the device.
Q: Is ERR_NAME_NOT_RESOLVED the same as DNS_PROBE_FINISHED_NXDOMAIN?
A: They overlap. NXDOMAIN is the authoritative answer that a name does not exist, so that code is the specific case of a name with no records anywhere. ERR_NAME_NOT_RESOLVED is the wider bucket and also covers a resolver that failed, refused, or never answered. Both mean no address came back, so both start with the same test.

### ERR_TOO_MANY_REDIRECTS: How to Break a Redirect Loop
URL: https://databay.com/blog/err-too-many-redirects
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

The browser gave up on a redirect loop. Fix it as a visitor in two minutes, see the loop with curl, and repair the server rules causing it.

#### What ERR_TOO_MANY_REDIRECTS Means
A redirect is a normal, healthy instruction: the server answers with a 3xx status and a Location header, and the browser goes where it points, as specified in the HTTP redirection semantics. ERR_TOO_MANY_REDIRECTS appears when following those instructions never ends: page A sends the browser to page B, B sends it back to A, and after roughly twenty hops the browser concludes no content is coming and gives up. Chrome, Edge, and Firefox all enforce a limit in that neighborhood, and HTTP clients do the same; the recorded lab behind this article watched a plain fetch abort a two-URL loop with a redirect-count error while a normal three-hop chain resolved fine.
That distinction is the whole mental model: redirects are not the problem, circles are. Sites legitimately redirect from HTTP to HTTPS, from the bare domain to www, from old URLs to new ones, and each hop costs one round trip but arrives somewhere. The error fires only when two or more redirect rules disagree about the final destination and keep handing the visitor to each other forever.
Who can fix it depends on where the circle lives. A loop conditioned on your cookies is fixable from your chair in two minutes, and the next section does exactly that. A loop baked into the site's redirect rules or its CDN configuration loops for every visitor on Earth, and no amount of cache clearing on your side will change what the server keeps answering.

#### Fix It as a Visitor: the Two-Minute Version
Start with the test that tells you whether you can fix it at all: open the same URL in a private or incognito window. Incognito starts with no cookies for the site, so if the page loads there, the loop is conditioned on stale state in your normal profile and you can clear it; if it loops in incognito too, the site is broken for everyone and your only moves are waiting or telling the owner.
When incognito works, clear cookies for that one site rather than nuking your whole browser history. In Chrome, the tune icon left of the address bar leads to site settings and a per-site delete; the browser's clear-data dialog also accepts a single domain. The lab shows mechanically why this works: its login route answers with a self-redirect for as long as a stale session cookie is presented, and returns 200 the moment the cookie is gone. Expired or contradictory session state is exactly what real sites loop on, and deleting the site's cookies replaces the poisoned state with a clean first visit. Expect to be signed out of that site afterward; that is the fix working, not a side effect to avoid.
Two lesser causes round out the visitor list. Extensions that rewrite requests, force HTTPS, or manage cookies can fight a site's own rules, so retry with extensions off before blaming the site. And check the URL you actually typed or bookmarked: an old bookmark pointing at a retired hostname can enter a redirect pair the site no longer maintains coherently.

#### See the Loop Yourself
You do not have to guess what the loop looks like; two tools print it. The quickest is curl with a small redirect budget, which follows the chain and shows every hop:
curl -sIL --max-redirs 8 https://example.test/a

HTTP/1.1 302 Found
Location: /b

HTTP/1.1 302 Found
Location: /a

curl: (47) Maximum (8) redirects followed
Read the Location lines top to bottom: the moment a URL repeats, you are holding the circle in your hands, and the pair of rules that disagree are named right there. The lab's manual-mode check records the same thing programmatically: /a answers 302 toward /b, /b answers 302 toward /a, and no content ever arrives.
In the browser, DevTools' Network tab with "Preserve log" enabled shows the same chain as a stack of 301 and 302 rows before the error page. Two details are worth reading off it. The status codes matter: 301 responses are cached aggressively by browsers, so a fixed site can keep looping for returning visitors until they clear cache, one more reason a loop that survives your fix attempt may still be repaired server-side. And the cookie column tells you whether each hop is setting or expecting state, which is the signature of the login-loop family from the previous section.

#### Site-Owner Causes, Ranked
On the server side, almost every loop is two well-intentioned rules disagreeing, and the ranking is stable across stacks. The champion is the CDN SSL-mode conflict described in Cloudflare's too-many-redirects guide: the CDN fetches from your origin over plain HTTP while your origin forces HTTPS, so the origin redirects every CDN fetch back to HTTPS, forever. The fix is making the CDN-to-origin leg encrypted (full SSL mode with a certificate on the origin) instead of stacking more redirects.
Second place: canonicalization rules fighting across layers. The CDN redirects www to the bare domain while the origin redirects the bare domain to www, or one layer strips trailing slashes while another adds them. Each rule is fine alone; together they are a tennis match. Decide each canonical form in exactly one layer.
Third: application-level HTTPS enforcement that cannot see it is already behind a TLS-terminating layer, covered in its own section next. Fourth: authentication flows that bounce between a login page and a protected page whose session validation disagrees, the server-side twin of the visitor cookie loop. And fifth: geo, language, or A/B redirects whose conditions overlap so two variants claim the same visitor. The repair discipline is the same for all of them: enumerate every layer that can redirect (CDN, load balancer, web server, framework, plugin), list each rule's condition and target, and make one layer own each decision, per the general model in MDN's redirections guide.

#### The X-Forwarded-Proto Trap
One server-side cause earns its own section because it hides in plain sight on every stack that sits behind a CDN, load balancer, or reverse proxy. The TLS-terminating layer talks to your application over plain HTTP, so from the application's point of view every request is insecure. If the application enforces HTTPS by inspecting its own connection, it redirects every request to HTTPS, the proxy fetches the HTTPS version by making another plain-HTTP request to the app, and the circle is complete without any rule looking wrong in isolation.
Intermediaries announce the original scheme in a forwarded header, most commonly X-Forwarded-Proto, and the fix is teaching the application to trust it instead of the socket it sees. Every serious framework has the switch: trusted-proxy settings that make request-is-secure checks read the forwarded header, a one-line change that ends the loop. Cloud platforms and WordPress installs behind CDNs hit this constantly, which is why plugin-stacked HTTPS enforcement plus a CDN so reliably reproduces the error.
Two cautions come with the switch. Trust the header only when a proxy you control sets it, because trusting arbitrary client-supplied forwarded headers lets visitors lie about their scheme and address. And after the fix, remove the now-redundant redirect from the layer that should not own it, so the decision lives in exactly one place. For the wider picture of what intermediaries change about a request on its way through, the proxy fundamentals guide traces the full path.

#### Redirect Budgets in Code and Collection Pipelines
Everything above also applies when the client is your own software rather than a browser, with one addition: you choose the redirect budget. Fetch in Node and browsers gives up after about twenty hops, curl's --max-redirs flag sets the cap explicitly, and Python's requests library defaults to thirty. The lab's first check is exactly this behavior: the client followed the loop until its budget ran out, then failed with a redirect-count error rather than hanging forever. That is the correct design to copy: a finite budget, a loud error naming the last URLs, and no retry, because a loop retried is just the same loop again.
For data-collection pipelines, redirect handling is quietly a correctness and budget issue. Every hop is a full round trip that counts against your per-source request budget, so a source whose URLs all bounce through a canonicalization hop costs double until you collapse the chain and store final URLs instead of entry URLs. Logging the chain per fetch pays for itself the first time a source restructures: a spike in hops per page is an early warning that entry URLs went stale. And a sudden appearance of loops on a source that worked yesterday usually means your stored session state went stale, the pipeline twin of the visitor cookie fix, so clearing the cookie jar for that source belongs in the standard remediation list before anything heavier.
One boundary stays firm: when a redirect loop guards authentication, the fix is valid session handling through the source's sanctioned flow, never crafting state to slip past it.

#### FAQ
Q: How do I fix ERR_TOO_MANY_REDIRECTS?
A: Test the page in an incognito window first. If it loads there, clear cookies for that specific site and retry; stale session cookies are the classic visitor-side cause. If it loops in incognito too, the site's own redirect rules are circular, and only the site owner can repair that, most often a CDN SSL-mode or www-versus-bare-domain conflict.
Q: What causes ERR_TOO_MANY_REDIRECTS?
A: Two or more redirect rules that disagree about the final destination and keep handing the request to each other: HTTPS enforcement fighting a TLS-terminating proxy, www and bare-domain rules in different layers, expired session cookies bouncing between login and protected pages, or overlapping geo and language redirects. The browser follows about twenty hops, then gives up.
Q: Does clearing cookies for the site log me out?
A: Yes, for that site only. Clearing a single site's cookies discards its session state, which is precisely the point: the loop was conditioned on stale state the server kept rejecting. You sign back in once and the fresh session works. Your other sites, passwords, and history are untouched if you clear per-site rather than the whole browser.
Q: Why does the error mention Cloudflare so often?
A: Because the most common server-side loop is a CDN SSL-mode conflict: the CDN fetches the origin over plain HTTP while the origin forces HTTPS, so every fetch gets redirected back at itself. Cloudflare fronts a large share of the web, so its flexible-SSL misconfiguration shows up constantly. The owner-side fix is encrypting the CDN-to-origin leg, not adding more redirects.
Q: Why does a streaming or shopping app show a redirect error?
A: App webviews carry their own cookie stores, so the same stale-state loop happens inside the app. Clearing the app's storage or cache, or signing out and back in, is the app equivalent of clearing site cookies. If every device and account loops at once, the service's own redirect rules broke, and waiting is the only client-side option.
Q: Are redirects bad for performance or SEO?
A: Chains cost one round trip per hop, so collapsing multi-hop chains to a single redirect is worth doing on both counts. Loops are simply broken: crawlers abandon them the way browsers do, and pages behind a loop drop out of search once recrawled. Keep necessary redirects, one hop each, each decision owned by exactly one layer.

### ERR_TUNNEL_CONNECTION_FAILED: Causes and How to Fix It
URL: https://databay.com/blog/err-tunnel-connection-failed
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-08-04.

ERR_TUNNEL_CONNECTION_FAILED means a proxy would not open the CONNECT tunnel HTTPS needs. What a tunnel is, and fixes ranked by the real cause.

#### What a CONNECT Tunnel Is, and What Failed
Chrome, Edge, Opera, Brave, and Chrome on Android all show ERR_TUNNEL_CONNECTION_FAILED for one event: your browser asked a proxy to open a tunnel, and the proxy did not open one. Every useful fix follows from knowing what that tunnel is.
Plain HTTP can be relayed by reading it: the proxy receives your request and forwards it. HTTPS cannot work that way, because the point of TLS is that nothing in the middle can read the exchange. So the client asks for something else first. It sends the CONNECT method, defined in RFC 9110 section 9.3.6 and documented in MDN's CONNECT reference, naming a host and a port:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443

HTTP/1.1 200 Connection Established
That is not a request for a page. It is a request for a pipe. A willing and able proxy opens its own TCP connection to that host and port, answers 200 Connection Established, and stops speaking HTTP. RFC 9110 describes what it becomes: a tunnel "acts as a blind relay between two connections without changing the messages."
Only then does your browser run its TLS handshake, with the destination, through the pipe. The certificate it validates belongs to the destination and the keys are known to those two ends alone, which is why a correctly behaving proxy carries ciphertext it cannot read. Hold on to that property: the most common cause of this error is software that breaks it on purpose.
The error name is scoped to that setup step and nothing else. Chromium's network error list records it as -111, "a tunnel connection through the proxy could not be established." Nothing had reached the website yet, so the site being down, DNS, and the destination's certificate are ruled out before you start. Two questions remain: is a configured proxy server supposed to be in the path at all, and what did it answer?

#### The Four Answers a Proxy Can Give
A CONNECT request has four possible outcomes, and which one you got decides what to fix. The lab behind this guide builds three proxies and one dead port on loopback and records all four on Node v24.14.0, verified 2026-07-29:
node scripts/verify-tunnel-failure-lab.mjs

PASS CONNECT to an HTTP-only proxy → 501 (wrong proxy type for HTTPS) (status=501)
PASS CONNECT to a policy-restricted proxy → 403 (tunnel denied by rule) (status=403)
PASS CONNECT to a tunnel-capable proxy → 200 Established, bytes relay end to end (status=200)
PASS CONNECT to a dead proxy port → ECONNREFUSED (the PROXY_CONNECTION_FAILED sibling) (error=ECONNREFUSED)

checks passed: 4/4
The proxy that relays plain HTTP but implements no tunneling answered 501: the endpoint is alive, it simply does not tunnel, the signature of a wrong proxy type or port. The one that forbids tunneling by rule answered 403: nothing there is broken, a policy matched the request and refused it. The tunnel-capable proxy answered 200, and a request written into that socket came back carrying the origin's body, origin through tunnel, untouched.
The fourth line costs people hours. With nothing listening at the proxy address there is no HTTP conversation at all: TCP is refused before a CONNECT can be sent, and Chromium reports that as ERR_PROXY_CONNECTION_FAILED, error -130, whose source comment explicitly excludes failures during the actual CONNECT method. One sentence keeps the pair apart. ERR_PROXY_CONNECTION_FAILED means you never reached the proxy; ERR_TUNNEL_CONNECTION_FAILED means you reached it and it would not open the pipe.
The four recorded CONNECT outcomesWhat the proxy answeredWhat the browser showsWhat is actually wrongYour move
501 Not ImplementedERR_TUNNEL_CONNECTION_FAILEDDoes not tunnel: wrong proxy type, or a plain relayCorrect the scheme, port, or proxy type
403 ForbiddenERR_TUNNEL_CONNECTION_FAILEDCan tunnel; a rule refused this one: host or port not permittedA decision, not a fault: ask whoever runs the gateway
200 Connection EstablishedThe page loadsNothing. TLS runs end to end through a blind relayNo action
No HTTP reply, TCP refusedERR_PROXY_CONNECTION_FAILEDNothing listening there: a dead or leftover settingRemove the leftover entry, or correct the address

#### Fixes Ranked by What Is Usually Wrong
On one computer, on ordinary sites, on a network you control, the cause is almost always software you installed.
First and most often, security software that inspects encrypted connections. A module sold as HTTPS scanning, encrypted connections scanning, or web shield cannot work through a tunnel, because the tunnel exists to make that traffic unreadable. So these products break the property on purpose: they intercept the connection locally, terminate TLS with a root certificate they installed on your machine, read the plaintext, and re-originate the request onward. That machinery fails predictably: the product is older than your browser, its local root is expired, a filtering driver is wedged after an update, or two products are inspecting the same connection at once. When any of that breaks, tunnel setup dies with it.
Fix it in this order. Identify the product: a security suite, an endpoint agent, or a parental filter. Turn off its encrypted-connections scanning only, not the whole product, and reload once; that is a diagnostic, not a fix. If the page loads, update the product first, because a stale scanner against a current browser is the most common pairing of all. If that does not settle it, add the browser executable to the product's own exclusion list, then switch scanning back on. Leaving inspection off permanently trades one working page for a real loss of protection.
Second, two intermediaries competing for the same connection. A VPN client, a browser VPN extension, and a system proxy each want to own your traffic, and privacy clients often install a local proxy that survives the client disconnecting. Disconnect everything, reload, then reintroduce one component at a time; the proxy versus VPN comparison covers why the two do not layer cleanly. Opera has its own variant: the built-in browser VPN and a third-party scanner both want that connection, and Opera's setting for scanning encrypted connections decides which one gets it.
Third, a proxy nobody configured on purpose.

#### The Proxy Nobody Configured
Plenty of software writes an operating-system proxy entry and never cleans it up: VPN clients, ad filters, tuning utilities, local intercepting proxies, old work configurations. Uninstall it, or let it crash, and the setting outlives it. Your browser then dutifully asks a dead intermediary for a tunnel on every HTTPS page. The signature is unmistakable: every site fails, it fails instantly rather than after a wait, and it follows the browser rather than the network.
Inspect the setting instead of guessing. On Windows, open Settings, then Network and internet, then Proxy, and read both halves of that screen as Microsoft's proxy documentation describes them: Automatic proxy setup, covering Automatically detect settings and Use setup script, and Manual proxy setup, naming an address and a port. Turn off anything you did not deliberately configure, and note what was there first, because on a work device it may belong to your employer. A setup script that is unreachable, stale, or names a host that no longer exists aims every HTTPS request at a phantom.
On macOS the same choices live under System Settings, Network, your active service, Details, then Proxies, where CONNECT uses Secure web proxy (HTTPS). On Android the proxy is stored per saved Wi-Fi network rather than per device: open the saved network, modify it, expand the advanced options, and set Proxy to None. That explains most Android reports, where the error follows one Wi-Fi network while mobile data is fine.
Chromium browsers, meaning Chrome, Edge, Opera, and Brave, read the system configuration and keep no list of their own, which is why they fail together. Firefox keeps the choice in its own connection settings, so it makes a clean control: set Firefox to No proxy, reload, and you have separated a system proxy problem from everything else. On a managed device, open chrome://policy, where a proxy pushed by administrative policy appears, overrides the settings screen, and is not yours to change.

#### Ask for the Tunnel Yourself with curl
The browser tells you a tunnel failed. It does not tell you what the proxy said. curl does. Name the proxy with -x and add -p, which the curl manual defines as "establish a tunnel to the destination through a PROXY that uses the HTTP CONNECT method." These are the lab's proxies with curl 8.17.0, verbose output trimmed to the CONNECT exchange:
$ curl -v -p -x http://127.0.0.1:8112 http://127.0.0.1:8109/
> CONNECT 127.0.0.1:8109 HTTP/1.1
< HTTP/1.1 200 Connection Established
* CONNECT tunnel established, response 200
origin through tunnel

$ curl -v -p -x http://127.0.0.1:8111 http://127.0.0.1:8109/
< HTTP/1.1 403 Forbidden
curl: (56) CONNECT tunnel failed, response 403

$ curl -v -p -x http://127.0.0.1:8110 http://127.0.0.1:8109/
< HTTP/1.1 501 Not Implemented
curl: (56) CONNECT tunnel failed, response 501

$ curl -v -p -x http://127.0.0.1:8116 http://127.0.0.1:8109/
curl: (7) Failed to connect to 127.0.0.1 port 8109 via 127.0.0.1
Against a real proxy, substitute your host and port, use an https:// URL, and drop -p: curl tunnels automatically for HTTPS. Exit code 56 means you reached a proxy and it declined, and the status beside it maps onto the table above. Exit code 7 means you never reached a proxy at all: the sibling error. One reading trap in that last line: on exit 7, curl's message names the destination (port 8109) "via" the proxy host. The connection that actually failed is to the proxy's port 8116; untrimmed -v output reports it on the preceding connect line (connect to 127.0.0.1 port 8116 failed: Connection refused). That message shape is curl's own, re-verified against curl 8.17.0, not a typo in the capture. The most informative result is the one that contradicts the browser: if curl tunnels cleanly while Chrome still fails through the same proxy, the proxy is innocent and something local is intercepting the browser.
When you configured the proxy yourself, three mistakes cover nearly all of it. Scheme: a SOCKS5 endpoint in an HTTP proxy field can never establish a CONNECT tunnel, because SOCKS negotiates in its own protocol and never sees an HTTP CONNECT line, and the HTTP versus SOCKS5 comparison covers which clients speak which. Credentials: a proxy wanting authentication answers 407, and clients that mishandle it surface a generic tunnel error. Host and port: a stale endpoint gives you the refused connection instead.
Get the endpoint right before rebuilding the client. A proxy grants access to nothing: it changes the route a request takes, and a destination that refuses you is not fixed by changing exits. Once the tunnel is up, a 403 or a block page is the site answering you, and the right response is to slow down or stop. For authorized work inside an approved budget, confirm an exit answers with the proxy checker and emit client settings with the proxy configuration generator, so what you write matches what the endpoint speaks.

#### Managed Networks Refuse Tunnels on Purpose
On a corporate, campus, or guest network, the lab's 403 row is what you are looking at: a gateway perfectly capable of tunneling is choosing not to tunnel this one. That is configuration, not breakage, and the decision belongs to the operator.
The version nobody explains to a general audience is the destination port allowlist. Forward proxies and cloud secure web gateways commonly permit CONNECT only to a short list of destination ports, in practice 443 and sometimes 8443, because an unrestricted CONNECT is an unrestricted outbound tunnel. The symptom looks site-specific and is not: every ordinary site works, then one service on 8443, 9443, or a vendor-specific port fails for everyone at once. Compare a plain https://host/ request with the same host on the explicit odd port. If 443 works and the other does not, the cause is a rule about ports, not anything about that site, and proxy ports explained covers why intermediaries treat ports as a policy surface. Check this first whenever the failing address carries a port number.
Other gateway shapes produce the same browser string: a blocked destination or category, TLS inspection at organization scale, which is why personal devices and certificate-pinning apps fail where managed laptops work, and an expired proxy authentication session answered with 407.
Your move is diagnosis, then a request. Collect the facts that make a ticket answerable: the destination host and port, the CONNECT response code from the curl test above, whether other sites work, and whether that host answers on 443. That turns a vague report into a log lookup, because the gateway recorded your CONNECT and the rule that matched it. Then ask for a scoped exception with the business reason attached.
Do not try to route around the control. A refusal is a decision by the people who run the network, not a defect, and adding an intermediary of your own does not create authorization. If the destination is a service you run, publish it on 443 behind a hostname, the shape every allowlist is built around.

#### FAQ
Q: What does ERR_TUNNEL_CONNECTION_FAILED mean?
A: Your browser asked a proxy to open a CONNECT tunnel, which is how HTTPS travels through an HTTP proxy, and the proxy did not deliver one. Chromium records it as error -111. It says nothing about whether the website is up, because the browser never got far enough to contact it. Something is acting as a proxy in the path, either because you configured one or because software on the machine did.
Q: How do I fix ERR_TUNNEL_CONNECTION_FAILED in Chrome or Edge?
A: Work in this order. Turn off your security software's encrypted-connections scanning for one minute and reload; if that clears it, update the product, add an exclusion, and switch scanning back on. Disconnect any VPN client and any VPN extension and reload. Then open your operating system's proxy settings and remove any manual proxy or setup script you did not deliberately configure. Chrome and Edge share a network stack and the same system settings, so a fix for one applies to the other.
Q: What is the difference between ERR_TUNNEL_CONNECTION_FAILED and ERR_PROXY_CONNECTION_FAILED?
A: ERR_PROXY_CONNECTION_FAILED means the browser never reached the proxy, so the address is wrong, stale, or nothing is listening there. ERR_TUNNEL_CONNECTION_FAILED means the proxy answered and then declined to open the tunnel. In the lab, a dead proxy port produced a refused TCP connection, while the live proxies returned 501 and 403 to the CONNECT request. The first is fixed by correcting the endpoint, the second by addressing whatever refused.
Q: Can antivirus cause ERR_TUNNEL_CONNECTION_FAILED?
A: Yes, and it is the leading cause on personal machines. Products that scan encrypted connections have to terminate TLS locally and re-originate the request, which is the opposite of what a tunnel provides, so any failure in that interception kills tunnel setup. Update the product first, then exclude the browser or the specific site in the product's own settings rather than leaving HTTPS scanning switched off.
Q: Why do I get this error only when my VPN is connected?
A: Two intermediaries are competing for the same connection. Many VPN clients install a local proxy or a filtering driver, and a browser VPN extension sets a proxy for that profile alone, so stacking them breaks tunnel setup. Disconnect everything, reload, then reintroduce one component at a time. If it reproduces with one specific client and nothing else running, that vendor's support channel is the right escalation.
Q: How do I fix ERR_TUNNEL_CONNECTION_FAILED on Android?
A: Android stores a proxy per saved Wi-Fi network rather than per device, so open that network, modify it, expand the advanced options, and set Proxy to None unless someone set it deliberately. Then check installed VPN and filtering apps. Testing the same site on mobile data tells you whether the Wi-Fi configuration is responsible; if that network belongs to an employer or a school, the difference confirms policy and the next step is its administrator.
Q: Why does the site load in Firefox but not in Chrome, Edge, or Opera?
A: Chromium browsers read the operating system's proxy configuration and keep no independent list of their own, so a bad system proxy takes all of them down together. Firefox has its own connection settings and can be pointed elsewhere, which makes it a useful control rather than a fix. If Firefox set to No proxy loads the page, the system proxy configuration is the thing to correct.
Q: Should I use a proxy or VPN to reach a site my workplace gateway refuses?
A: No. A refused tunnel on a managed network is a policy decision by the people who run that network, and routing around it breaks the terms you accepted, is normally logged on a managed device, and does not resolve the underlying need. Bring the destination host, the port, and the business reason to your IT team and request a scoped exception. This is general technical information, not legal advice.

### Error 1015: You Are Being Rate Limited (How to Fix It)
URL: https://databay.com/blog/error-1015
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-08-04.

Error 1015 is Cloudflare enforcing a site's rate limit at the edge. Why you tripped it, how long it lasts, and fixes for visitors and owners.

#### What Error 1015 Means
Error 1015, with its one-line explanation "You are being rate limited", is Cloudflare's block page for a rate-limiting rule that the website's owner configured. The site sits behind Cloudflare's edge; the owner wrote a rule along the lines of "no more than N requests per time window per visitor" using Cloudflare's rate limiting rules; your address crossed the threshold; the edge served you the block page instead of the site. Underneath the branding it is the same mechanism as the generic HTTP 429 status, defined in RFC 6585: a counter, a window, and a temporary refusal once you exceed it.
Two properties define everything else in this guide. First, the block happens at the edge, before the request ever reaches the website's own servers. The recorded lab behind this article models exactly that architecture with an origin that logs what it sees behind a rate-limiting edge: during a burst of eight page requests, the origin's log recorded only the five that were allowed, and the three blocked ones never existed from the origin's point of view.
The recorded run, exactly as the lab printed it:
$ node verify-rate-limit-edge-lab.mjs # Node v24.14.0
PASS burst of 8 page requests → 5×200 then 3×block page (200×5, blocked×3)
PASS origin log holds exactly the 5 served requests (origin saw 5 page requests)
PASS asset request during the block → 200 (rule scoping) (status=200)
PASS after Retry-After elapses → 200 again (temporary, not a ban) (status=200)

checks passed: 4/4
Second, the rule and its thresholds belong to the site owner, not to Cloudflare and not to you, which is why every honest fix is either waiting, sending fewer requests, or talking to the owner.
It is also temporary by construction: the counter resets when the window ends. In the lab, the same request that was blocked answered normally again the moment the advertised wait elapsed.

#### How Long Error 1015 Lasts
The block lasts until the rule's mitigation window expires, and the owner chose that window when writing the rule. In practice most rules clear in seconds to a few minutes, which matches the lab model, where the block page carried a Retry-After of a few seconds and the first request after that wait returned 200. A minority of rules, especially on login and API endpoints, use longer mitigation periods, and some services layer their own account lockouts on top with waits measured in hours; when a site's own help pages name a specific number, that number wins.
Two behaviors decide whether you experience the minimum wait or much more than it. Requests sent during the block can keep the pressure visible: the fastest exit is to stop entirely, wait out the window once, then return at a calmer pace. And repeat offenses matter, because a visitor who trips the same rule every few minutes looks exactly like the automation the rule exists to manage, while one clean wait followed by normal browsing looks like the false positive it probably was.
To the recurring question, no, error 1015 is not permanent and it is not a ban. It shares a surface with genuinely different Cloudflare pages, though: error 1020 means an access rule matched you (a block by criteria, not by rate), and challenge loops are their own topic. If the page says 1015, it is a timer, and the timer ends.

#### Fix It as a Visitor
The ranked list is short because the mechanism is simple. First, stop and wait: close the tab or leave the page alone for a few minutes, then try once. Refreshing during the block is counted traffic on some rule configurations and, more importantly, it resets nothing; a single clean retry after the window is the fastest path back in every time. Second, find what else on your side is spending the same budget: duplicate tabs of the same dashboard, an auto-refreshing page, a browser extension polling the site, or an app on your phone syncing against the same service all count toward one visitor's rate as the rule sees it. Close the duplicates before the retry, or the fresh window fills up again immediately.
Third, consider who shares your public address. Office, campus, hotel, and mobile networks put many people behind one address through shared network translation, and a per-address rule counts the whole crowd as one very busy visitor. That is the classic "1015 for no reason" case: it was not you, it was everyone behind your address combined. The browser IP diagnostic shows the address the site actually sees; when colleagues on the same network hit the block simultaneously, you have confirmed it, and the wait is unavoidable from that network.
Fourth, if the block recurs on a service where you are a paying or logged-in user, report it with timestamps. Owners tune thresholds from exactly these reports, and a legitimate user tripping a rule during normal use is information the owner wants.

#### Can You Bypass Error 1015?
No, and the reasons are worth stating plainly because the question is the most-asked one on this error. The counter lives on the server side of the edge; nothing in your browser, cache, cookies, or settings holds any piece of it, so no client-side cleanup clears a rate limit. The block page is not a malfunction to repair but a policy the site owner deliberately configured, and the limit is part of the site's terms of access in the most literal sense: it is the owner stating, in configuration, how fast they are willing to be visited.
Address-switching schemes, whether via VPNs, proxies, or hopping networks, do change which counter you hit, and this site sells proxies and still will not dress that up as a fix: presenting as a new visitor to continue traffic the owner just throttled is working around their stated limit, it violates most terms of service, and against per-path or account-keyed rules it does not even work. A block is a stop signal, not a routing suggestion; that principle holds across this entire cluster and it holds here.
What legitimately shortens your wait: sending fewer requests, spacing them out, closing the duplicate clients spending your budget, and, where you have a genuine need for higher volume, asking the owner. Sites with APIs publish quotas and paid tiers precisely for that conversation, and "we hit your rate limit doing X, can we get a sanctioned path" succeeds far more often than people expect.

#### Fix It as the Site Owner
When your own users report 1015, the rule is doing what you told it to do to the wrong people, and the repair is scoping, not deletion. The lab's checks map the three moves. First, scope by path: its edge rule counted page requests but exempted asset paths, so during a block the exempt request still returned 200. Real rules want the same shape, protecting login, search, and API endpoints while exempting static assets, because one image-heavy page can otherwise spend a whole per-address budget in a single load, which is exactly how galleries and dashboards lock out their own visitors.
Second, size thresholds from measured traffic rather than instinct: your analytics know how many requests a real page view costs and how fast your busiest legitimate users click, and the rule should sit above the honest percentiles with room to spare, then descend as evidence justifies. Remember shared addresses while sizing: a per-address threshold that fits one home user is five times too tight for a small office behind one address. Third, use the edge's own visibility: because blocked requests never reach the origin, your origin logs cannot show the problem, and the security event log at the edge is where matched rules, matched paths, and affected addresses are recorded. The lab's origin-log check is that lesson in miniature.
Last, verify legitimate crawlers by the search engines' published verification methods and exempt them properly, rather than either blanket-trusting user-agent strings or letting a tight rule quietly throttle indexing, which surfaces weeks later as unexplained search decline.

#### Error 1015 in Data Collection
For collection work, a 1015 is the source's contract enforced in configuration, and the correct engineering response is identical to the 429 discipline it inherits from the underlying status code: honor the wait, back off with jitter, cap retries, and treat repeated blocks as a stop condition rather than an obstacle course. One request budget per source, enforced across every worker, account, region, and exit you run, remains the aggregate rule, because distributing traffic across addresses does not reduce the load you place on the source; the responsible collection framework is the full statement of that discipline.
Rotation deserves its own sentence in this specific context: rotating exits in response to a rate-limit block is identity-switching to continue refused traffic, and it is exactly what this cluster's stop-condition rule prohibits. The static versus rotating guide covers what rotation is legitimately for, and "outrunning the counter" is not on the list. Where managed proxy infrastructure legitimately fits is the same place as always: accountable regional egress for authorized workloads that are paced within the source's published limits from the start, with session-pinned exits so per-session state survives a workflow, and budgets set so the edge rule never fires at all.
The most useful habit is treating first-1015 as a design review trigger: measure what rate tripped it, halve your pace, widen your caching, and check whether the source offers an API or export that makes the whole question moot. A pipeline that never sees the block page is cheaper than one that handles it well.

#### FAQ
Q: How do I fix error code 1015?
A: Stop requesting the site, wait out the window, then try once. Close duplicate tabs, auto-refreshing dashboards, and apps polling the same service first, because they spend the same per-address budget. If you are on a shared network, the whole network's traffic counts as you, and waiting is the only client-side option. Recurring blocks during normal use are worth reporting to the site.
Q: How long does the 1015 error last?
A: Until the rule's mitigation window expires, which the site owner configured: usually seconds to a few minutes, longer on login and API endpoints. Hammering during the block only makes you look like the traffic the rule targets. One clean wait followed by a single retry is the minimum-time exit, and the block is temporary by construction.
Q: Is error 1015 permanent or a ban?
A: No. It is a timer attached to a rate counter, and it resets when the window ends. Permanent-feeling repeats mean something on your side keeps refilling the counter, most often background tabs, extensions, or a busy shared address. A criteria-based block is a different page, error 1020, and account lockouts by specific services follow those services' own rules.
Q: How do I bypass Cloudflare error 1015?
A: You do not. The counter is server-side, so no cache or cookie clearing touches it, and switching addresses to continue traffic the owner just throttled works against their stated limits and usually their terms. Send fewer requests, spread them out, or ask the owner for a sanctioned higher-volume path such as an API plan. A rate limit is policy, not a puzzle.
Q: Why do I get error 1015 without doing anything?
A: Because the rule counts your public address, not your intentions. Shared networks put many users behind one address, background tabs and apps generate traffic you do not see, and browser prefetching can multiply requests. Occasionally the site's rule is simply too tight for its own pages, which is the owner's bug; reporting it with timestamps helps them fix the scoping.
Q: Does a VPN fix error 1015?
A: It changes which address the counter sees, which is not a fix: the limit still stands, the site's terms usually forbid evading it, and per-account or per-path rules ignore the address change anyway. If a shared address caused a false positive, the durable options are the site owner tuning the rule or your network operator, not routing around the site's stated capacity.

### Error 1020 Access Denied: Causes and How to Fix It
URL: https://databay.com/blog/error-1020
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

Error 1020 means a site's own firewall rule refused your request at the edge. Why you matched it, and the one thing that actually resolves it.

#### What Error 1020 Means
Error 1020 means access denied by a firewall rule. Someone who runs the website wrote a rule about who may reach it, your request matched it, and Cloudflare refused you on the owner's behalf. Cloudflare's error 1020 reference states it in one line: access is denied by a Cloudflare firewall rule, because a client or browser is blocked by a customer's rules. It is not a Cloudflare policy, not a browser fault, and not a defect you can repair from your side.
Underneath the branded page it is an ordinary HTTP 403. Cloudflare's rules language actions reference gives the block action's status as 403 for most security features, or 429 for rate limiting rules. That is why your network panel reports 403 while the page says 1020: one is the status code, the other is the reason.
Where the decision happened matters more. The refusal is made at the edge, in the data center that answered you, so the site's own servers are never contacted. The lab behind this article models that on loopback, seven checks passing on Node v24.14.0: when the rule matched, the edge produced the refusal itself and never reached the origin.
One consequence follows. When you tell the site's support that their pages refuse you, their application logs show no trace of your visit, because your request never arrived. They are not brushing you off. The record exists in the edge's security event log, and reaching it takes one piece of information already on your screen.

#### Read the Block Page Before You Change Anything
Before you change any settings, reproduce the refusal outside the browser. Run curl -sS -i against the URL that refused you and read the status line, the cf-ray header, and the body. If curl is refused exactly as your browser was, the rule is keyed to your network rather than your browser, since curl shares little with Chrome beyond the address it comes from. Here is the refusal as the lab's edge returned it to curl, transport headers omitted:
curl -sS -i http://127.0.0.1:8123/gated

HTTP/1.1 403 Forbidden
Content-Type: text/html

<html><body>Error 1020 (model): access denied by an edge rule</body></html>
Two recorded details do the diagnostic work. There is no Retry-After header on that response, and a real 1020 carries none either, because time is not what the rule matched on. The refusal was also identical on every attempt, so reloading changes nothing, and code that retries it as a transient failure is waiting out a window that does not exist.
The number itself is a diagnosis, and its neighbors ask for opposite reactions.
Four refusals that get mistaken for one anotherWhat you seeWho decidedWhat it meansWhat resolves it
Error 1020The owner's access rule, at the edgeYou matched criteria the owner chose to refuseThe Ray ID, sent to the site's support
Error 1015The owner's rate limiting ruleYou sent requests faster than the thresholdWait out the window, then return slower
Error 522Nobody. The edge could not reach the originThe origin is down or too slow to answerOnly the owner can fix it
A plain 403 pageThe application, behind the edgeThe server understood the request and refused to process itFix the permissions, path, or credentials

The lab makes that split mechanical. Failing the access rule's criterion produced the refusal while satisfying it returned 200, so the outcome depended on the visitor. With the origin unreachable, the edge answered 522 for everyone, including a visitor who satisfied the rule. A 1020 is about who you are. A 522 is about the site.

#### Why Your Request Matched, Ranked by Likelihood
Rules match on attributes of a request: the address, the country inferred from it, the network that owns the range, headers, path, method. A handful account for nearly every 1020, in rough order of likelihood.
A VPN or hosting network address. Consumer VPN exits and cloud servers sit in ranges that are easy to identify in bulk as non-residential, and many owners refuse them wholesale. The VPN and proxy comparison explains why a device-level VPN sends every request from one shared exit, which is all the rule sees.
A country or region rule. Plenty of sites serve one market or license content regionally, and the country is inferred from your address. This is why a site works at home and refuses you on a business trip. The page never says it does not serve your region. It says 1020.
An address range with a history. Residential and mobile addresses are recycled constantly, and rules are often written against whole ranges rather than single addresses, so you can inherit a block earned by whoever held that address last month. This is the accurate version of the forum answer that your range has seen abuse.
A request shape that looks automated. Extensions that rewrite headers, HTTP libraries sending their default user agent, and browsers that do not present a normal handshake all give a rule something to match.
A shared corporate or campus exit. Hundreds of people leave through one address, and one of them, or a security appliance opening links on their behalf, earns the whole building a rule.
A rule broader than its author intended. More common than owners admit: a narrow intent expressed as a country block, or a rule added during an incident and never removed. Rules written to stop one attack outlive it by years.
You cannot tell which applies from the outside. Only the firewall's own event log knows.

#### The Ray ID Is What Actually Resolves a 1020
Every request that passes through Cloudflare is stamped with a Ray ID, as the Cloudflare Ray ID reference describes. It appears near the bottom of the block page and in the cf-ray response header: a hexadecimal string, a dash, then a three-letter code for the data center that handled you. It works in one direction. You hand it to the site, and the site looks up why you were refused.
Cloudflare's own instructions to owners explain why nothing you do locally can substitute. The owner takes the screenshot from the customer, searches the Security Events log for the Ray ID or the client IP address from the error message, converting the error's UTC timestamp to their local time zone, then assesses the cause and either updates the rule or allows that address. The log names the rule that fired and the action it took. Clearing caches and reinstalling browsers cannot produce that answer: the reason lives in the owner's configuration and nowhere else.
So screenshot the whole block page, which is what Cloudflare tells blocked visitors to send, and write to the site's support with four things: the Ray ID, the date and time with your time zone, the exact URL, and the public address the page displayed. If you are a paying customer, say so: a legitimate user tripping a rule during ordinary use is precisely the report an owner wants.
One sourced caveat separates a ticket that resolves from one that stalls: Cloudflare notes that Ray IDs are not guaranteed to be unique for every request, so the timestamp and URL beside it make the lookup unambiguous. Capture all four while the block page is still in front of you.

#### Self-Checks That Identify the Trigger
Each check below identifies which attribute the rule matched, so your report says something useful. None is an attempt to make a refused request succeed.
First, if a VPN or a system-wide proxy is switched on, turn it off and load the page again. This is the highest-yield check, because the largest category of 1020 rules targets VPN and hosting ranges. If the page loads, the rule targets that network. If it refuses you both times, the cause is your own address, your region, or your request. The proxy and firewall checklist shows where a forgotten system proxy hides.
Second, try one other network you already control, most easily your phone on mobile data with Wi-Fi off. Refused on both means the rule is not keyed to a single address. Refused on one confirms it is address-based.
Third, check what address the site actually sees with the browser IP diagnostic. Fourth, retry in a clean browser profile with extensions disabled: if the page loads, an extension was altering your requests. Fifth, clear cookies, but only if the block began mid-session or affects one account. An address or country rule does not read your cookie jar.
There is a line worth stating once, because the most upvoted advice on this topic crosses it. Turning a VPN or proxy off to learn whether it is the trigger is diagnosis, and we recommend it. Reconnecting through a different exit, account, or fingerprint until the same request stops matching is a different act: the rule refused you deliberately, and presenting a new identity so it stops applying works around the owner's access policy instead of resolving anything. Databay sells proxy infrastructure and this page still says so; the compliance guide sets out where authorized use ends. The route back is the site's support with your Ray ID.

#### Error 1020 on Android, Windows 11, and Managed Networks
No operating system produces this error, so nothing on your device is broken. The platform matters only because the intermediary that got you matched sits in a different place on each.
On Android, an app showing 1020 inside its own web view is displaying the same block a browser would. Look for a device-wide VPN, indicated by the key icon in the status bar, then for ad-blocking apps, which commonly run as a local VPN service and send your traffic out through their own exit, then for a Private DNS entry. Turn off what you control and retry. Carriers also place many subscribers behind a small pool of public addresses, so a phone can inherit a rule aimed at someone else.
On Windows 11, open Settings, then Network and internet, then Proxy, and look for a manual proxy or an automatic setup script left behind by software you removed. Then check for a VPN client and for security agents that route traffic through an inspection service. Chromium browsers use the system proxy configuration, so a stale entry refuses identically in Chrome and Edge while Firefox, which keeps its own settings, is unaffected. That asymmetry identifies the cause without changing anything.
On a school, office, or hotel network, the exit address is not yours and the rule may have nothing to do with your behavior. Two policies apply and neither is yours to set: the network belongs to its administrator, the rule belongs to the site. Report the Ray ID to the site, and if the block follows your organization's address everywhere, raise it with whoever runs the network.

#### When Your Own Site Returns Error 1020
From the owner's chair, a 1020 report means a rule you deployed matched a customer. The repair is scoping, not deletion. Country rules top the causes, because country is inferred from an address and traveling customers, carriers that egress abroad, and VPN users all break that inference. Next come rules against hosting ranges, which catch uptime monitors, messaging-app link previews, and partner integrations. Then rules added during an incident and never removed. Give every rule you write under pressure an owner and an expiry date.
Know which layer refused before you tune anything. Managed rulesets are Cloudflare's own pre-configured rules, maintained by their security team against known exploit patterns. A custom rule is one you or a predecessor wrote, evaluated exactly as written. Custom rules run in an earlier phase than managed rules, so a terminal action from your own rule means the managed ruleset was never reached. Teams lose days tuning a managed ruleset for a block their own forgotten custom rule produced.
Run the same lookup described above from your side: find the customer's Ray ID in your security events and read the matched rule, the matched field, and the action. Fix the rule's scope rather than adding a one-off exception, because the next hundred people the same rule matches will not write to you. They will leave, and you will never learn why.
Two habits prevent most of these tickets. Deploy new rules in log mode for a day and read what they would have blocked before promoting them. And prefer a challenge to an outright block for ambiguous traffic: a challenge lets a real browser prove itself, while a block ends the request for everyone the expression matches, including the customers you meant to keep. Certainty deserves a block. Suspicion deserves a challenge.

#### FAQ
Q: What does error code 1020 mean?
A: It means access denied by a firewall rule. The website's owner configured a rule about who may reach the site, your request matched it, and Cloudflare refused you at the edge before the site's own servers saw anything. The page is branded 1020, but the underlying HTTP status is 403. It is a deliberate decision about your request, not an outage and not a fault on your device.
Q: How do I fix error code 1020?
A: Screenshot the block page for the Ray ID, the timestamp, and the address it displays, then send those to the site's support with the exact URL and ask which rule matched. Before you write, turn off any VPN or system proxy and retry, and test one other network you control, so you can tell them whether the refusal follows your address. Reloading, clearing the cache, and reinstalling the browser change nothing.
Q: Can I bypass error 1020?
A: No, and the framing is worth rejecting. The rule lives in the site owner's configuration, so nothing on your side removes it, and presenting from a different address or identity so that you stop matching a rule that deliberately refused you works around the owner's access policy rather than fixing anything. The productive route is the site's support with your Ray ID.
Q: How long does error 1020 last?
A: There is no timer. Unlike a rate-limit block, an access rule carries no Retry-After header, which the recorded lab confirmed, because time is not the remedy. The refusal lasts until the rule changes or until the attribute it matched changes. If your block page mentions being rate limited, you are looking at error 1015 instead, and that one does expire on its own.
Q: Does a VPN cause error 1020?
A: It often does. VPN and hosting ranges are the most frequently targeted category in access rules, because they are easy to identify in bulk, and every user of one exit looks identical to the rule. Turning the VPN off and retrying is a legitimate test that tells you whether the rule targets that network. Switching to a different server so that the refusal stops applying is working around the owner's access policy, not diagnosing anything.
Q: Why does the site say they cannot find my request?
A: Because it never reached them. The block is produced at the edge, so the request stops there and the site's application logs stay empty, which the lab reproduced by never contacting the origin once the rule matched. Their firewall event log does hold the record, and the Ray ID from your block page is the key that finds it.
Q: What is the difference between error 1020 and error 1015?
A: 1020 is a criteria block: something about your request matched a rule, and it will match again on the next attempt. 1015 is a rate block: you sent requests faster than the site allows, and it clears when the window resets. Waiting fixes 1015 and does nothing for 1020, which is why the presence or absence of a retry timer is the fastest way to tell them apart.

### Error 522: Connection Timed Out and Whose Fault It Is
URL: https://databay.com/blog/error-522
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-08-04.

Error 522 means a CDN edge could not get a usable connection to the site's origin. Why it is almost never the visitor's fault, and the owner's real fixes.

#### What Error 522 Actually Means
Error 522 is an edge server reporting that it could not get a usable connection to the origin. Everything else follows from that one sentence.
A site behind a CDN is served by two machines, not one. The edge, a reverse proxy in front of the site, accepts your request, then opens its own connection to the origin, the server that actually holds the website. When that second connection never becomes usable, the edge has nothing to relay, so it writes an error page itself and returns 522. Cloudflare's own definition is shorter: the error occurs when Cloudflare times out contacting the origin web server.
The detail most other pages gloss over is authorship. The origin did not send this error, and in most 522s it never saw your request at all. That is why a site's access logs can be empty during an outage its visitors are watching in real time, and why "nothing in the logs" is a clue rather than a mystery. In the recorded lab behind this article, with the origin stopped, the edge answered 522 by itself and the visitor received nothing the origin had written, because it had written nothing.
The recorded run, exactly as the lab printed it:
$ node verify-edge-refusal-lab.mjs # Node v24.14.0
PASS healthy origin → 200 through the edge (status=200)
PASS origin down → edge answers 522 (the visitor never sees an origin error) (status=522)
PASS origin accepts then stalls → 522 at the edge deadline (status=522 after 1015ms)
PASS access rule matched → 1020-style refusal produced at the edge (status=403)
PASS 1020-style refusal carries no Retry-After (unlike 1015) (Retry-After absent)
PASS criterion satisfied → 200 (the rule, not the visitor, is the variable) (status=200)
PASS 522 is visitor-independent (same result with the rule satisfied) (status=522)

checks passed: 7/7
Two things follow. A site's custom error pages cannot appear during a 522, because the application is not in the conversation, and no edge setting repairs it either. One cleanup: 522 is a vendor number, not a standard HTTP status, so a "522" in a spreadsheet or a reader app is an unrelated product reusing three digits.

#### Is Error 522 Your Fault?
The short answer has two halves: if you are visiting, almost never; if you run the site, almost always.
If you are a visitor, there is nothing on your machine to fix. A 522 is decided between the edge and the origin, on a connection your device is not part of. The lab makes that mechanical rather than merely reassuring: the failing request was repeated with the visitor's headers changed, and the answer was the same 522. No cookie, address, or browser version takes part in the hop that broke.
If you run the site, then yes, and Cloudflare's documented cause list sits entirely on the origin side. The useful version is more precise than "statistically the origin". Here "the origin" means everything between the edge and your application, and the failure is more often a firewall, a security appliance, or a load balancer in front of the web server than the web server itself. The gap between a healthy server and a reachable server is where most debugging time on this error is lost.
If you are calling the site from code, it is not your client either. A 522 is upstream unavailability, not a rejection of your request, so no header or credential you send changes it.

#### What Visitors and API Clients Can Do
The honest list is short. Wait a minute and reload once, then come back in ten minutes, because most 522s accompany an outage somebody is already being paged about. If it persists, report it to the site and quote the reference identifier printed on the error page, which lets support find that exact request.
What does not work, roughly in the order the internet recommends it: clearing the cache, flushing DNS, changing resolvers, disabling extensions, reinstalling the browser, and switching a VPN on. Every one of those acts on the connection between you and the edge, and that connection demonstrably worked. You are reading an error page the edge delivered to you.
That also answers the question people ask next, which is how to get around it. There is nothing to get around. A 522 is not a refusal aimed at you, it is a report that two other machines could not reach each other, and no change on your side puts them back in contact. Changing networks, exits, or identities does not make an unreachable origin reachable.
If you are calling the site from code, treat 522 as transient upstream unavailability and retry with capped exponential backoff and jitter, never a tight loop that piles load onto an origin the moment it recovers. If the browser hangs and never shows a page at all, that is a different failure, and the connection timeout guide covers it.

#### Two Failure Shapes Behind One Number
One number covers two mechanically different failures, and they take different fixes, so separate them before changing anything.
In the first shape no connection ever forms: the edge sent a connection request and heard nothing back. Cloudflare's documented threshold is no SYN+ACK returned within 19 seconds. That figure is the one number the rest of the internet quotes, and it is half the mechanism. The second shape is the other half: the connection is established and then stops being usable, with a documented window of 90 seconds for the origin to acknowledge the request. Something at the origin is alive and accepting, but the exchange never finishes, which is why the server looks healthy from its own console while every visitor sees an error.
The lab reproduces both on loopback against a deliberately short connect deadline of 1000 milliseconds. With the origin stopped, the edge answered 522. With an origin that accepted the TCP connection and then never completed the exchange, the edge still answered 522, but only once its own deadline expired: 1015 milliseconds on the recorded run, just past the 1000-millisecond deadline. That lag is the finding: the error is timed to the edge's deadline rather than to anything the origin said, because the origin said nothing.
Two corrections, because both send owners to the wrong layer. A slow application is usually not a 522: an origin that accepts the connection and does eventually answer, only too late, produces Cloudflare's 524, listed as "a timeout occurred" in its 5xx error index, so tuning a slow page will not clear a 522. And an origin that actively refuses the edge is not a 522 either, because refusal is 521, "web server is down" in the same index. At the TCP layer a rule that rejects sends a reset while a rule that drops sends nothing, the distinction the connection refused guide works through. A reject produces 521. A drop produces 522. The number already tells you whether anything answered.

#### Origin Causes, Ranked by How Often They Are It
The origin firewall is dropping the CDN's addresses. Cloudflare names allowing all of its IP ranges as the most common cause. It happens without anyone editing a rule: once a site sits behind an edge, all its traffic arrives from a small set of addresses, so a security plugin or cloud security group sees thousands of requests per address and reacts as designed. Dropping rather than rejecting is why the symptom is a timeout. The scoped fix is to permit the ranges published on Cloudflare's IP ranges page, which calls itself the definitive source. Do not switch origin security off to make the error disappear, because that trades an outage for an exposure.
The origin is unreachable or the web server is stopped. Powered off, mid-reboot, or behind a broken route. Apply the discriminator above: if the host is up and only the web server process died, the kernel usually answers with a reset and visitors see 521, so a clean 522 points at the network layer rather than the process.
The origin is overloaded and its accept queue never drains. The process is up, the port is open, connections are accepted, and the exchange never finishes inside the edge's window. Almost nobody names this one, because from outside it is indistinguishable from a firewall drop while from inside the server looks fine. What proves it: an accept queue sitting at its limit, load matching the minute of failure, and intermittent rather than total failures. The fix is capacity.
Keepalives are disabled at the origin. The edge reuses connections, and an origin that closes every one forces a fresh handshake for every object. Cloudflare lists this explicitly, and it is the classic intermittent 522 nobody can reproduce, because it only fails under real traffic.
The origin address is stale. Cloudflare lists an origin address that no longer matches the provisioned one, the classic leftover from a migration: a DNS record aimed at a machine that stopped serving the site, or a load balancer pointed at a dead backend.
Resource exhaustion below the web server. Worker pool saturation, file descriptor limits, ephemeral port exhaustion, or a full disk, any of which stops new sockets being created while the service looks alive. These track traffic peaks and clear on their own, which is why they get misfiled as CDN flakiness.

#### Confirm the Cause in Minutes
Every cause above is selected by an observation. Three checks, in this order, pick one.
First, ask your origin the question the edge is asking, with the edge out of the path. Pin the hostname to the origin address so virtual hosting and TLS still behave, using the --resolve option from the curl manual:
curl -sS --resolve www.example.com:443:203.0.113.10 \
-o /dev/null -w 'code=%{http_code} connect=%{time_connect}\n' \
https://www.example.com/
Read the connect time, not only the status. An instant refusal means nothing is listening on that port, the 521 shape. A hang that ends in curl's own timeout means packets are being discarded silently: a firewall, a security group, or a full accept queue. A fast connect means the origin is healthy from where you stand. Run it from the origin and from a machine outside your network: a local success with an outside hang isolates the path in one contrast.
Second, check whether the origin logged the failing request at all. This is the check that decides everything and the one most guides skip, because it produces nothing worth a screenshot. No line in the access log means the request never arrived, and every application level theory dies at once: not the framework, not the database, not a slow query. Absence of a log line is evidence, not missing evidence.
Third, read the firewall's counters rather than its configuration. A rule listing shows what somebody intended; counters show what is being discarded now. On Linux, iptables -L -n -v and nft list ruleset print per-rule packet counts, and a managed host can tell you what their protection did. Look for drops from the CDN's published ranges timestamped to the outage. ss -ltn reports the accept queue depth and its limit per listening socket, which catches the overload case that looks like a firewall from outside. One warning on the way past: pausing the CDN publishes your origin address, so it is a diagnostic rather than a resting state.

#### 522 Compared With 1015, 1020 and 504
These five arrive from roughly the same place and mean entirely different things. Reading the number correctly keeps you from fixing the wrong layer.
Edge and gateway errors that get mistaken for each otherWhat you seeWhat actually happenedWho can resolve it
522The edge could not get a usable connection to the originThe site owner, at or in front of the origin
1015A rate limiting rule counted your requests and refused for a windowSlow down; the window expires on its own
1020An access rule matched your request and refused it on criteriaThe site owner, whose policy it is
403The origin was reached, answered, and refused the requestAuthorization or policy, at the application
504A gateway got no response from upstream in timeWhoever operates the upstream that went quiet

The pair that genuinely confuses people is 522 and 1020, because both arrive as a full page error branded by the same network. One tell settles it: a 1020 is about you specifically, so a colleague on another network loads the page normally, while a 522 refuses everyone identically. The lab separated the two on one edge: with the access rule's criterion satisfied the gated path returned 200, while the dead origin path still returned 522 for that same request, and the refusal carried no Retry-After, because time is not the remedy for a policy decision. That is a diagnostic distinction and not an instruction: a rule that deliberately refused you is the site's decision, and the way forward is its administrator.

#### FAQ
Q: How do I fix error 522?
A: It depends which side of the edge you are on. As a visitor there is nothing to fix: wait a few minutes, retry once, and report it to the site with the reference identifier from the error page if it persists. As the site owner, confirm the CDN's published address ranges are allowed through your origin firewall first, since that is the most common cause, then check the origin is reachable from outside and whether the failing requests appear in its access log at all.
Q: Is error 522 my fault?
A: If you are visiting the site, essentially never, and nothing on your device changes it. The error is generated by the CDN edge on the separate connection between the edge and the website's own server, which your machine is not part of. If you run the site, it is almost always the origin or something in front of it: a firewall dropping the CDN's addresses, an unreachable host, an overloaded server, or a stale origin address left over from a migration.
Q: Is error 522 permanent?
A: No. It reflects the state of a connection at the moment of the request, so it disappears as soon as the origin is reachable again, and most clear within minutes because they accompany an outage or a firewall change somebody notices quickly. Unlike a rate limit it carries no timer and no Retry-After, so there is no window to wait out. Something has to be fixed at the origin.
Q: How do I bypass Cloudflare error 522?
A: There is nothing to bypass. The error is not a block aimed at you, it is a report that a site's own network could not reach the site's server, so no browser setting, network change, or different exit makes an unreachable origin reachable. The lab behind this article recorded exactly that: the same request failed identically no matter what the visitor sent. Waiting and reporting it is the complete visitor list.
Q: Does a VPN fix error 522?
A: No. The failing connection is between the CDN and the origin, and a VPN only changes how your traffic reaches the CDN, which was already working well enough to hand you the error page. Turning a VPN or proxy off is a sensible diagnostic habit for errors that depend on your address, but 522 is not one of them, because it reproduces identically for every visitor.
Q: What is error 522 on Discord?
A: The same thing it means anywhere else. Discord is served through a CDN, so a 522 means the edge could not reach Discord's own servers at that moment. It is not your client, your connection, or your account, and reinstalling the app does not touch it. The service status page is the fastest confirmation, and the fix belongs to Discord.
Q: Why does my site show 522 when the server is running fine?
A: Because a healthy server and a reachable server are different things. The usual version is a firewall or security appliance silently dropping the CDN's address ranges, so your server keeps serving you over loopback and SSH while the edge waits for a handshake that never lands. The tell is the access log: if it holds no line for the failing requests, they never arrived at all.
Q: Does error 522 hurt SEO?
A: A short incident does not. Sustained 522s do, because crawlers see a server error, reduce their crawl rate, and can eventually drop URLs that keep failing. Treat repeated 522s as an availability defect rather than a cosmetic one, fix origin reachability, then watch crawl stats and the affected URLs in Search Console until they recover.

### What Is Msftconnecttest.com and Why Does It Redirect?
URL: https://databay.com/blog/msftconnecttest-com
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

Msftconnecttest.com is how Windows checks for internet access. Why it is not malware, why the redirect tab opens, and the fixes that work.

#### What Msftconnecttest.com Actually Is
Msftconnecttest.com is not a site anyone chooses to visit. It is the endpoint Windows contacts on its own to answer one question every time the network changes: does this connection reach the internet, or is something standing in the way? The component asking is the Network Connectivity Status Indicator, written NCSI, and Microsoft's NCSI documentation calls what it sends an active probe.
The sequence is short. Windows resolves www.msftconnecttest.com, sends a plain HTTP GET to http://www.msftconnecttest.com/connecttest.txt, and checks that the body of that file is the exact text it expects. Windows 10 also resolves dns.msftncsi.com; from Windows 11 the HTTP probe is what decides. In the recorded lab behind this article, that file answered 200 with the body Microsoft Connect Test, exactly 22 bytes, and set no cookies.
Comparing the body is the entire mechanism, and it is what separates this from a ping. Reachability proves nothing on its own: a hotel network cheerfully answers every request with 200 and its own sign-in page. So Windows does not ask whether the file arrived, it asks whether the file is the right file. Microsoft's captive-portal rule is exactly that: a probe sent outside a known proxy, a response received, a payload that did not match. That is the no-internet warning in the tray and the sign-in prompt.
The probe travels unencrypted for the same reason: a portal cannot rewrite an HTTPS response without producing certificate errors, so a check designed to be intercepted has to be interceptable. Every major platform ships a version of it.

#### Is It Malware? Run the Check Yourself
No, and you do not have to take that on trust. Two requests reproduce the whole basis for the answer. Run them from Command Prompt, or type curl.exe in PowerShell so you get the real binary rather than a shell alias.
curl.exe -sS -i http://www.msftconnecttest.com/connecttest.txt
curl.exe -sS -i http://www.msftconnecttest.com/redirect
The recorded run on 2026-07-29, from a network with no portal and no filtering, produced this:
connecttest.txt status 200, body Microsoft Connect Test, 22 bytes, no Set-Cookie
/redirect status 302
Location: http://go.microsoft.com/fwlink/?LinkID=219472&clcid=0x409
Three details carry the rest of this article. The body is the literal string Windows compares against, 22 bytes with no trailing newline, which leaves nowhere to hide a payload or a tracker. The response set no Set-Cookie header, so the probe stores nothing and follows nothing. And /redirect, the URL behind the mystery tab, is a plain 302 into go.microsoft.com, Microsoft's own link-forwarding service.
Now the caveat, because reassurance is not evidence. The guarantee attaches to the registered domain, the two labels immediately before the first slash: anything can be placed in front of a dot, and near-miss spellings are cheap to register. Judge the page by what it asks for as well. This endpoint's entire vocabulary is 22 bytes of text and one redirect: no login form, no password prompt, no download, nothing for sale. A page that wants credentials, a card number, or an installer is the portal of the network you just joined, or something worse. Neither is Microsoft.

#### Why a Tab Opens by Itself and Lands on MSN
Windows opens a browser window for two different reasons, and conflating them is why most advice on this subject misfires.
The first is the feature working. When a network requires a sign-in, the probe comes back wrong, Windows concludes a portal is in the way, and it opens your default browser so you can authenticate. Microsoft records that behavior as by design: it replaced a small notification users kept missing.
The second explains the MSN tab on a network with no portal at all. When the active probe cannot complete, Windows opens http://www.msftconnecttest.com/redirect deliberately. Microsoft's support article describes the resulting network trace precisely: a connection to that URL followed by a connection to the MSN portal, opened, in Microsoft's phrasing, for the benefit of the passive probe process, and if the page loads then NCSI concludes that the computer has internet access. Windows is not confused and not advertising at you: it is borrowing your browser as a second opinion, because a browser can often reach what the probe could not. Nothing intercepts that request on a portal-free network, so it reaches Microsoft, returns the 302 recorded above, and forwarding carries you to MSN.
The triggers explain the timing. Active probes fire on interface or network condition changes, proxy detection, and hotspot detection: joining a network, waking from sleep, roaming between access points, a link that flaps, a VPN connecting and rewriting the routing table.
One tab after joining hotel Wi-Fi is the system working. A tab that returns several times a day on your own network means the probe keeps failing, and the fault sits upstream of the browser.

#### What the Probe's Answer Rules In
A status code on its own settles nothing here. Match what came back against the table and the fault narrows to one layer.
What each probe answer rules inWhat comes backWhat it meansWhere the fix lives
200 with the exact probe textThe probe path is healthy right nowNot NCSI: check VPNs, tunnels, link stability
200 with another body, or a 302 elsewhereSomething answered in Microsoft's place: a portal is interceptingSign in through that network's portal
403A proxy on the path refused the probeProxy or PAC configuration
The hostname does not resolveA resolver problem, the most common causeDNS settings on the device or the network
Nothing: it hangs or is refusedPort 80 is blocked or droppedFirewall rules on the path

The second row is the one people misread: a captive portal returns a perfectly valid 200, so a browser looks satisfied while Windows correctly concludes the opposite. Microsoft's taxonomy names it a hotspot-detected probe failure, a 200 whose payload is not the expected text or a non-200 in its place. If that page belongs to a network you do not run, the probe worked as designed: sign in, or ask its operator.
For the machine's own verdict, read the Microsoft-Windows-NCSI channels in Event Viewer, where every connectivity change records a reason. The NCSI FAQ decodes them: a DNS probe failure, an HTTP probe that failed after the name resolved, or no route on the interface, the case a forced-tunnel VPN produces. One triage rule saves hours: applications insisting there is no internet while your browser loads pages normally is an NCSI fault rather than an outage, because Office and others ask Windows through a connectivity API instead of testing the network. If you cannot browse either, the fault is the network itself and none of this applies.

#### Fixes, in the Order That Works
Ranked by how often each is the real cause, not by how easy it is to type. First, sign in if the network wants you to; if the login page will not load, disconnect any VPN and turn off encrypted DNS until you have, because both prevent the interception the portal depends on.
Second, and usually the answer on a network that otherwise works, DNS. Microsoft lists resolution failures for the NCSI lookup names among the reasons a probe fails, and notes they are most often intermittent rather than missing records, which is what a tab appearing twice a day looks like. Run ipconfig /flushdns, then resolve both names yourself:
nslookup www.msftconnecttest.com
nslookup dns.msftncsi.com
The FAQ gives 131.107.255.255 as the expected answer for the second name; anything else, a filter page, or no answer at all has found your fault, with no registry key touched. On equipment you control, fix the resolver; on a managed network it is the operator's.
Third, rejoin: forget the Wi-Fi and reconnect, or disable and re-enable the adapter, which reruns detection from scratch. Restarting the router only helps when the router is broken.
Fourth, VPNs, tunnels, and filtering software. A forced-tunnel VPN rewrites the routing table at connect time, and security suites that inspect HTTP sometimes catch connectivity-check hosts, as do broad blocklists. Turn one off at a time and watch; the proxy versus VPN comparison covers why a device-wide tunnel changes what the local network can see.
Fifth, on a managed machine, the proxy. Microsoft's list is specific: a proxy not yet discovered, a proxy unreachable when the probe runs, and a PAC file that does not map www.msftconnecttest.com to the correct proxy. One that refuses the probe answers 403. The proxy server guide covers why the system's proxy scope is not your browser's, and the proxy checker confirms an exit reaches the internet. That allowlist belongs to the network, not to the laptop.

#### The EnableActiveProbing Switch and Its Cost
Nearly every page on this subject, and Google's own AI summary, ends on the same instruction: open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet, set EnableActiveProbing to 0, restart. It works by switching off the detection instead of repairing what the detection found, and that cost is almost never stated.
Microsoft states that cost three times. The NCSI overview warns against disabling active probing to resolve an NCSI issue, because passive polling alone cannot determine all connectivity issues. The support article is blunter: several operating system components and applications rely on NCSI, and it names Outlook unable to reach a mail server and Windows unable to download updates on a computer that is online. The managed Connectivity policy agrees that with active tests off, NCSI runs neither test, which may reduce the ability of NCSI and other components to determine internet access.
Priced honestly, you trade one browser tab for three things: captive-portal detection, so hotel Wi-Fi hands you a connection that looks healthy and carries nothing; an accurate answer for every application that asks Windows instead of testing the network itself; and the input NCSI feeds into the profile that decides which Windows Firewall profile applies.
That does not make the switch illegitimate. On a managed fleet permanently behind a proxy, where the probe can never succeed and the tabs carry a real support cost, it is defensible. Make it deliberately: back up the registry first, as Microsoft instructs, and prefer the supported policy under Computer Configuration, Administrative Templates, System, Internet Communication Management, Internet Communication settings, which writes NoActiveProbe instead. A policy is auditable and reversible without visiting machines one at a time; a hand edit is neither, and it outlives whoever typed it. What the switch is not is a repair. It silences a working alarm and leaves the fault the alarm was reporting.

#### If You Run the Network
Two rules, and they are opposites, which is why guest networks get this wrong.
On a network with no captive portal, let the probes through untouched. Blocking msftconnecttest.com, sinkholing it in a DNS filter, or catching it in a broad blocklist does not make Windows machines trust your network; it convinces every one of them that your network is broken, with no-internet icons on working Ethernet and a tab opening at the redirect URL on every join. Allow the hosts by name, not by address: Microsoft moved the public probe servers to Akamai on 20 June 2023 and address-pinned rules broke that day, which is why the standing recommendation is that NCSI rules should not be IP-based. Allow plain HTTP on port 80, the port the probe uses rather than the one your proxy stack listens on, as the proxy ports guide explains. Do the same for the Apple and Android equivalents.
On a network with a captive portal the rule inverts: the probe hosts must be intercepted before sign-in, not allowlisted. Working correctly, the mechanism does your job: the client probes, your portal intercepts, the check fails, and your login page is what Windows opens. Guests landing on msftconnecttest.com/redirect instead means the portal missed that request. The usual cause is the pre-authentication walled garden: an administrator adds the probe hosts to it to stop no-internet complaints, so the one request the portal needed sails through to Microsoft, returns the 302 recorded earlier, and delivers the guest to MSN. After sign-in, allow the hosts fully.
Longer term, stop relying on interception alone. RFC 8910 defines a DHCP and router-advertisement option that tells a client it is behind a portal and where the portal lives, so a compliant client is informed instead of inferring it. And never advise a guest to switch off connectivity checking: that hides the prompt they need in order to sign in. The goal is making the legitimate login appear on the first try.

#### FAQ
Q: What is msftconnecttest.com?
A: It is the endpoint Windows uses to test whether a network really reaches the internet. The Network Connectivity Status Indicator downloads a tiny text file from it after joining or re-evaluating a network and checks that the body is the exact phrase it expects. A match means the path is clear, and anything else means something is intercepting, which is how Windows knows to show a sign-in prompt. It is Windows infrastructure, not a program someone installed.
Q: Is msftconnecttest.com a virus?
A: No. In the recorded check it returned a fixed 22-byte text file, set no cookies, and its redirect endpoint answered 302 into a go.microsoft.com forwarding link. Microsoft documents the hostname as a Windows connectivity endpoint and tells enterprises to allow it. The realistic risk is a lookalike name, so check that the registered domain is exactly msftconnecttest.com, and remember that the genuine endpoint never asks for a password, a payment, or a download.
Q: Why does msftconnecttest.com/redirect keep opening in my browser?
A: Because the connectivity probe keeps failing, and Windows opens that URL on purpose when it does. On a network with a captive portal the request is intercepted and you get the venue's login page. On a network without one it reaches Microsoft, gets redirected, and you land on MSN, which Microsoft describes as Windows opening the page for the benefit of its passive probe. Repeated tabs mean repeated probe failures, usually DNS, a VPN, or a proxy.
Q: How do I stop the msftconnecttest redirect?
A: Fix the probe rather than the tab. Sign in if the network wants a login, then check DNS, since resolution failures for the probe names are the most common cause on a network that otherwise works and are also what produces the site cannot be reached variant. Flush the resolver cache, replace a filtering or dead DNS server on equipment you control, rejoin the network, and disable VPNs and HTTP-filtering software one at a time to find the interference.
Q: Should I set EnableActiveProbing to 0 in the registry?
A: Only as a deliberate fleet decision, never as a first fix. Microsoft advises against disabling active probing and names the consequences, including Outlook failing to reach a mail server and Windows failing to download updates on a machine that is online. You also lose captive-portal detection, so Windows stops telling you when hotel or airport Wi-Fi needs a sign-in. If it is genuinely required, back up the registry first and apply the supported Group Policy that sets NoActiveProbe instead of hand-editing machines.
Q: Why does Windows say no internet access when the internet works?
A: The tray icon reports NCSI's verdict, not your actual connectivity, so a probe that cannot complete produces the warning on a working connection. On managed machines the usual culprit is proxy configuration: a PAC file that does not map the probe hostname to the right proxy, a proxy unreachable at probe time, or a proxy returning 403. A forced-tunnel VPN that leaves the interface with no route when the probe runs does the same thing.
Q: Can I block msftconnecttest.com on my network?
A: You can, and every Windows device will then conclude your network is broken: no-internet icons on working links, applications that trust that verdict refusing to work, and tabs opening on every join. Allow the probe hosts on port 80, along with the Apple and Android equivalents, and allow them by hostname rather than IP address, because Microsoft moved the probe servers in June 2023 and address-based rules broke when it did.
Q: Why does my guest Wi-Fi land on msftconnecttest.com instead of my login page?
A: Your portal did not intercept that request. The usual cause is the probe hostnames sitting in the pre-authentication walled garden, so the request the portal needed reaches Microsoft, receives the documented redirect, and ends at MSN. Other causes are interception scoped to HTTPS or to ports that exclude plain HTTP on 80, and clients using encrypted DNS. Intercept the probe before sign-in, allow it fully afterwards, and advertise the portal over DHCP as RFC 8910 describes.

### What Is Doubleclick.net? Google's Ad and Tracking Domain
URL: https://databay.com/blog/what-is-doubleclick-net
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

Doubleclick.net is Google's ad serving and measurement domain. Why it loads on sites you visit, whether it is malware, and what limiting it costs.

#### What Doubleclick.net Is, and Who Runs It Now
Doubleclick.net is an advertising domain. Its job is to deliver ads into pages you visit and to measure what happened next: whether the ad loaded, how often you have already seen it, and whether a click led anywhere. Serving and measuring ads requires identifiers, so this is not a passive file host, and answers that treat it as one skip the part you asked about.
The name is older than its owner. DoubleClick was an independent ad-serving company through the 1990s and 2000s, and Google acquired it in 2008. The products were folded into Google's advertising stack and renamed, into what is sold today as Google Ad Manager, Campaign Manager 360, and Display & Video 360. The brand went away and the domain did not, for an unglamorous reason: doubleclick.net hostnames are written as literal strings into publisher ad tags, click-through URLs, video players, and corporate blocklists across a very large number of sites. A name embedded that widely costs more to move than to keep.
Google's own documentation confirms the domain is current rather than legacy. Its page on how Google uses cookies in advertising names doubleclick.net as one of the domains its advertising cookies may be set from, alongside google.com, googlesyndication.com, and googleadservices.com.
So the honest answer runs to two clauses. Doubleclick.net is legitimate infrastructure operated by Google, and it is advertising and measurement infrastructure. Both are true at once, and you can verify the first half yourself in a minute.

#### Verify the Operator in One Handshake
Two questions sit behind most searches for this domain: is this really Google, and who told my browser to contact it. A TLS certificate answers the first, because it is issued to a verified domain holder and names the operator of the host you reached.
The lab behind this article resolves hostnames and reads certificates, nothing else. It sends no HTTP request that could be counted as an ad impression: we are not measuring an ad network by generating traffic for it. Run on 2026-07-29 under Node v24.14.0, all three checks passed. The recorded output, verbatim:
PASS doubleclick.net resolves to at least one address (6 address(es), first family IPv4)
PASS doubleclick.net certificate is issued by Google Trust Services (issuer O=Google Trust Services, CN=WR2, subject CN=*.doubleclick.net)
PASS stats.g.doubleclick.net presents a Google-issued certificate (issuer O=Google Trust Services, SAN sample=DNS:*.g.doubleclick.net, DNS:*.invitemedia.com)

checks passed: 3/3
Read what that settles. The issuing organization is Google Trust Services, Google's own certificate authority, and the subject covers *.doubleclick.net. That rules out a whole category of worry: not a lookalike, not a hijacked name, not something malware registered to blend into a log. It rules out nothing about what the domain does.
One detail in the third line is a fossil. The certificate served by stats.g.doubleclick.net carries *.invitemedia.com among its subject alternative names, a domain from an advertising company Google acquired after DoubleClick. Certificates keep that kind of history, which is why they beat a brand name as evidence.
Reproduce the certificate half without our script:
openssl s_client -connect doubleclick.net:443 -servername doubleclick.net </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject
Then answer the second question in your browser. Open developer tools, select the network panel, filter for doubleclick, and reload. The Initiator column names the script that made the request, turning "why is this on my machine" into "this page's ad tag asked for it".

#### Why It Loads When You Never Visited It
Nobody types doubleclick.net into an address bar. You reach it because a page you opened instructed your browser to, before you clicked anything.
When a publisher sells space on a page, they place an ad tag in it: markup or JavaScript that runs while the page renders and asks an ad server to fill the slot. Google's publisher tag documentation tells publishers to load its library from https://securepubads.g.doubleclick.net/tag/js/gpt.js, so one documented copy-paste makes every visitor's browser contact the domain. That request goes to a host other than the one in your address bar, which makes it a third-party request your browser sends automatically. A single news article can touch dozens of third-party hosts this way.
The subdomain tells you which part of the machinery you caught.
securepubads.g.doubleclick.net: the publisher-side tag library that finds the ad slots on a page and requests fills for them.
googleads.g.doubleclick.net: the ad request and the creative that comes back, the fetch that produces what you actually see.
stats.g.doubleclick.net: measurement and reporting traffic rather than visible creative. It shows up on pages counting something, including pages with embedded media and no visible banner.
ad.doubleclick.net: the long-serving delivery and click-redirect host, which is why some links travel through it toward an advertiser's page.

That explains why it turns up in the browser status bar, developer tools, router logs, DNS query logs, and website data on a phone, all of them normal. On an iPhone, an entry under Safari's website data records pages you loaded. Nothing was installed to produce it, which answers the usual fear that seeing the name means something got in.

#### Is Doubleclick.net Malware? Both Halves Are True
The popular answers split into two camps, each wrong by half: one says it is spyware you should delete, the other says it is just Google, ignore it.
It is not malware. The check above names the operator and shows a certificate issued by that operator's own authority for this exact name. It is also not software on your computer: there is nothing to uninstall, and an antivirus scan will never find it, because a domain is not a file. Advice to delete doubleclick.net is really advice to delete a cookie or a history row, records of pages you loaded rather than a program that runs. Cleanup tools that flag a doubleclick cookie are applying a tracking-cookie category, not detecting code.
And it is advertising and measurement infrastructure, so tracking here is not an accusation, it is the function. Calling that harmless is as inaccurate as calling it a virus. Whether you want it running is a preference to act on deliberately, not a security incident.
A third risk is real, separate, and routinely confused with the other two. Ad slots accept creatives from many buyers, and ad networks have repeatedly been abused to deliver malicious or deceptive ones, an attack called malvertising. That risk lives in the ad supply chain rather than in the domain being counterfeit, and it is the strongest practical argument for a content blocker even if personalized advertising does not bother you.
The case that does deserve alarm is a hostname that merely contains the string. Anything ending in doubleclick.net is the real domain. A registration that only borrows the word, or buries doubleclick inside an unfamiliar domain, is not, and the certificate check settles it in one command.

#### What an Ad and Measurement Domain Actually Does
Ad delivery is not one action. It is four, and each leaves a different trace.
Selection comes first: a page has a slot, a request goes out describing the context, something gets chosen. Recognition comes second, and it is the part readers care about. A cookie set on the ad domain, or a mobile advertising ID inside an app, lets the ad system recognize the same browser on a different site later. MDN's third-party cookie reference describes the mechanism: a cookie whose domain and scheme differ from the page you are looking at, readable again on every other page that loads that same third-party domain.
The other two are on Google's advertising cookies page linked earlier: capping, described there as stopping you from seeing the same ad over and over again, and measuring the effectiveness of ads, along with detecting and stopping click fraud. That page also documents Google's personalization and data practices, which change over time and belong at the source rather than restated here.
One diagnostic falls out of that. Browsers do not treat third-party cookies alike, which is why two people comparing notes disagree about whether they are tracked. Per MDN, Firefox enables Total Cookie Protection by default and Safari applies its tracking prevention policy by default; Chrome does not block them except in Incognito or when you set it to. WebKit is blunter: Intelligent Tracking Prevention "by default blocks all third-party cookies. There are no exceptions to this blocking." What every host observes regardless of cookie policy is connection metadata: the address a request came from and the user agent that sent it, which the what-is-my-IP diagnostic shows directly.

#### Gstatic Versus Doubleclick: How to Read a Domain
The most valuable thing here is not a fact about one domain, it is the ability to classify the next one. Two Google domains out of the same log make that concrete, and our guide to gstatic.com reaches a genuinely different conclusion about its subject, because the two do different jobs.
Two Google domains, two different jobsQuestiongstatic.comdoubleclick.net
What it deliversStatic assets: fonts, images, stylesheets, scriptsAds, and the measurement traffic that reports on them
IdentifiersCookieless by design; responses set no cookiesNamed by Google as an advertising-cookie domain
Why your browser contacts itA page embedded Google Fonts, Maps, or reCAPTCHAA page sells advertising through Google's ad stack
What blocking costsBroken fonts, failed reCAPTCHA logins, missing map tilesNo ads, no measurement, dead click-redirect links, blocker prompts on some sites
Sensible defaultLeave it aloneA real choice, made deliberately

Four questions classify almost any unfamiliar hostname. Read the registered domain first, the rightmost labels rather than the left edge, because everything to the left is chosen by whoever controls the registration: googleads.g.doubleclick.net ends in doubleclick.net and is that domain, while doubleclick.net.example-cdn.tld ends somewhere else entirely. Read the certificate second, issuer organization and subject, with the command earlier in this guide. Read the subdomain third, since these names are usually literal: fonts, stats, ads, pubads. Then ask what the domain is for, because purpose predicts behavior: an asset host has no reason to set cookies, an ad host has every reason to.
The same reading settles the connectivity-check hostnames that fill router logs, such as captive.apple.com, which look alarming and are not. It also warns you about blocklists: Google names googlesyndication.com and googleadservices.com in that same official list, so blocking doubleclick.net alone leaves plenty of advertising traffic running.

#### How to Limit It, and What Each Option Costs
Start by naming what you want, because two levers get confused. Turning off ad personalization changes which ads you see. Blocking requests changes whether the ad code runs at all. Picking the wrong one is why people conclude nothing works.
A browser content blocker is the most precise tool if the requests are what you object to. It stops the request before it is made and can be switched off per site when something breaks. Its cost is social rather than technical: some publishers detect blocking and ask you to disable it or subscribe, which is their decision about their own pages, so the honest options are comply or read elsewhere.
Third-party cookie settings target recognition rather than delivery: pages still render and ads still load, but the cross-site identifier goes, at the cost of sign-in widgets, embedded comment systems, and some checkout flows that use it.
My Ad Center changes something different: it turns personalized ads on or off and manages the activity that feeds them. That changes which ads you get, not whether ads are served, and a setting tied to a signed-in account does not follow you to a browser you are not signed in to. Right tool for targeting, wrong tool for the traffic.
DNS-level blocking, with Pi-hole, NextDNS, or a hosts file, covers every device on the network including apps that ignore browser settings. It is also the bluntest, because the symptom depends on what your resolver answers: an NXDOMAIN reply surfaces as ERR_NAME_NOT_RESOLVED, while a sinkhole pointing at 0.0.0.0 surfaces as ERR_CONNECTION_REFUSED. The consequence nobody warns you about is click redirects: links routed through an ad server toward their destination, common in newsletters, land nowhere when that host is unreachable, and get reported as a broken link on a site that works perfectly.
On iPhone and iPad the same two levers are Safari's cross-site tracking prevention, the ITP mechanism above, and a content blocker from the App Store.
Two situations are not yours to configure. On a work, school, or other managed network, ad and tracker filtering is the administrator's policy, and questions belong with them. If a site declines to serve you while a blocker runs, that refusal is the site's choice about its own content: accept it, or go elsewhere.

#### FAQ
Q: Why is doubleclick.net tracking me?
A: Because that is what an ad and measurement domain does. A page you opened carried an ad tag, the tag contacted the domain, and identifiers such as third-party cookies let the ad system recognize the same browser on other sites for frequency capping and measurement. You never chose it, the publisher did, and nothing was installed on your device. Your browser's third-party cookie setting decides how much of that recognition still works.
Q: How do I stop doubleclick.net from tracking me?
A: Pick the lever that matches your goal. Google's My Ad Center turns off personalized ads while ads and requests continue as before. A content blocker stops the requests entirely and is the stronger option, at the cost of layout gaps and, on some sites, a request to turn the blocker off. Blocking third-party cookies sits in between and occasionally breaks embedded logins or checkout widgets.
Q: How do I get rid of doubleclick.net?
A: There is nothing on your device to remove. Clearing the cookie and the history entry deletes the record of pages you already loaded, and the next page carrying ad tags writes a new one. Durable change comes from blocking the requests in your browser or on your network rather than from cleaning up after them, and blocking one hostname leaves other advertising domains serving.
Q: Is doubleclick.net a virus or spyware?
A: Neither. It is Google-operated advertising infrastructure, and the certificate shows it: the recorded check returned an issuer organization of Google Trust Services with a subject of *.doubleclick.net, so there is nothing infected to clean. It is still advertising infrastructure that participates in tracking, which is a preference question rather than a security incident. The genuine security issue attached to ad networks is malvertising, where attackers slip malicious creatives into legitimate ad supply.
Q: What is doubleclick.net used for on iPhone?
A: The same thing as everywhere else. Pages you open in Safari, or inside an app's built-in browser, carry ad tags that request ads and send measurement traffic, and the entry you found under Website Data is the record of those page loads rather than something installed on the phone. Safari's cross-site tracking prevention and a content blocker from the App Store are the controls on the iPhone side.
Q: Is doubleclick.net owned by Google?
A: Yes. Google acquired the DoubleClick company in 2008 and folded its technology into its own advertising products, retiring the brand while keeping the domain, which was already embedded in publisher tags and allowlists everywhere. Google still names doubleclick.net in its own documentation as a domain its advertising cookies may be set from, and the certificate the domain serves today is issued by Google Trust Services.
Q: Is doubleclick.net the same kind of domain as gstatic.com?
A: No, and telling them apart is the useful skill. Gstatic.com is a cookieless static-asset host for fonts, images, scripts, and connectivity checks, and blocking it mostly breaks rendering and logins. Doubleclick.net serves and measures ads and is named by Google as an advertising-cookie domain. Same owner and same certificate authority, opposite purposes.

### What Is Gstatic.com? Google's Static Content Domain
URL: https://databay.com/blog/what-is-gstatic-com
Author: Databay Research Team. Published: 2026-07-29. Updated: 2026-07-29.

Gstatic.com is Google's cookieless domain for static files like fonts and scripts. What it does, why devices ping it, and what breaks if you block it.

#### A Google Domain That Serves Files, Not Pages
Gstatic.com is a domain Google owns and uses to deliver static content: font files, images, stylesheets, JavaScript, and other assets that do not change per user. There is no website to visit; browsing to it directly returns nothing useful, because the domain exists to be loaded by other pages. Google services such as Search, Maps, YouTube, Meet, and reCAPTCHA pull their fixed assets from it, and millions of third-party sites reach it indirectly by embedding Google Fonts, Maps widgets, or reCAPTCHA challenges.
Google separates these assets onto a dedicated domain for two practical reasons. The first is performance: static files can be pushed to CDN edge servers near users and cached aggressively, because the same bytes serve everyone. The second is that the domain is deliberately cookieless. Requests to it do not carry Google account cookies, which keeps every asset request smaller and keeps session state away from servers that only hand out fixed files. In the recorded check behind this article, responses from gstatic.com set no cookies at all.
So the short answer to the question in the title: gstatic.com is legitimate Google infrastructure, one of several such domains (googleusercontent.com and googleapis.com are cousins with different jobs), and seeing it in your logs is normal. The longer answer, including the cases where caution is justified, takes the rest of this guide.

#### Where Gstatic Shows Up and Why
Most people meet gstatic.com in one of four places: the browser status bar while a page loads, the network tab of DevTools, a router or firewall log, and mobile-device connection lists. It appears so widely because very different Google systems share the domain, each on its own subdomain.
Common gstatic.com subdomains and what they serveSubdomainWhat it servesWhere you notice it
www.gstatic.comCore static assets for Google services, reCAPTCHA resources, and the generate_204 connectivity endpointAlmost any Google page load; device connectivity checks
fonts.gstatic.comThe font files behind Google FontsAny third-party site using Google Fonts
ssl.gstatic.comStatic assets for Google product pages and embedded widgetsGmail, Docs, and sign-in flows
maps.gstatic.comStatic map images and Maps interface assetsPages with embedded Google Maps
csi.gstatic.comPerformance-measurement reporting used by Google servicesPrivacy tools sometimes flag this one

The practical consequence: you do not need to use any Google product deliberately to generate gstatic traffic. Opening an unrelated news site that embeds Google Fonts, or a login form protected by reCAPTCHA, is enough, and on phones the operating system itself contacts the domain during connectivity checks, which the generate_204 section below covers.

#### Is Gstatic.com Safe? Is It a Tracker?
The domain itself is safe in the sense that matters: it is owned and operated by Google, it serves static files, and it does not set cookies. That last claim is checkable rather than a promise; the recorded requests behind this article received no Set-Cookie header, matching the domain's design as a cookieless asset host.
Calling it a tracker requires more precision than most warnings bother with. A request to any CDN necessarily reveals connection metadata to its operator: your IP address, user agent, and the fact that some page needed an asset at that moment. That is true of gstatic.com exactly as it is true of every asset host on the internet, and what address a site sees is easy to inspect with the what-is-my-IP diagnostic. What the domain does not do is carry Google account cookies, which is precisely why Google splits it from google.com. One subdomain deserves its own mention: csi.gstatic.com receives performance measurements from Google services, which is why some privacy blocklists single it out while leaving the asset subdomains alone.
The genuine risk carries the name without being the domain. Malware and phishing kits register lookalike domains such as gstatic-cdn followed by an unrelated ending, or bury gstatic as a subdomain of a domain they control, borrowing the familiar name to look harmless in a process list or log. The verification section at the end of this guide shows how to tell the real domain from a costume: check the registered domain exactly, then check the certificate.

#### Should You Block Gstatic.com?
You can, and the web will misbehave in specific, predictable ways. Sites that load Google Fonts fall back to system fonts after a delay, shifting layouts as they do. reCAPTCHA stops working, which quietly breaks logins, signups, and checkout forms on sites you may need, because the challenge assets never arrive. Embedded Google Maps lose tiles and interface graphics, and Google's own products degrade in assorted ways since their static assets all live there. Corporate environments that filter traffic generally have to allow gstatic.com for Google services to function at all.
Blocking it is also a weak privacy lever. The requests it receives are asset fetches without account cookies; cutting them mostly breaks rendering while the pages that embed Google services continue to make their own choices about what they load. If the goal is fewer third-party requests, two targeted moves achieve more than a blanket block: sites you control can self-host fonts instead of loading them from fonts.gstatic.com, and browser content blockers can be scoped to measurement endpoints such as csi.gstatic.com rather than the asset subdomains that pages need to render.
One block is outright counterproductive: filtering www.gstatic.com at the network level makes phones and laptops on that network misjudge their own connectivity, because of one small endpoint the next section explains.

#### The generate_204 Endpoint Your Devices Keep Pinging
The single most common gstatic.com entry in firewall logs is a request to /generate_204, repeated by every Android phone, Chromebook, and Chrome browser on the network. It is a connectivity check. The endpoint does exactly one thing: it answers status 204 No Content with an empty body, as described in Chromium's portal-detection design notes. In the recorded run behind this article it returned status 204 with zero body bytes, and that emptiness is the feature.
Devices use it to answer a question DNS alone cannot: is this network actually routing traffic to the internet, or is it a captive portal that intercepts everything until you sign in? If the device requests generate_204 and receives the expected empty 204, the path is clear. If it receives anything else, typically a login page injected by hotel or airport Wi-Fi, the device knows a portal is in the way and shows the sign-in prompt.
Two log patterns follow from this. First, the requests recur constantly, on connect, on wake, and periodically, from every Google-ecosystem device you own; frequency is not evidence of malware. Second, blocking the endpoint produces confusing symptoms: devices report no internet or limited connectivity on a network that otherwise works, because their canary request never comes back. When a network filters gstatic.com and Wi-Fi indicators start lying, this endpoint is usually the reason.

#### Connectivitycheck.gstatic.com: the Other Constant Visitor
One more hostname deserves its own answer because it fills router logs under a different name: connectivitycheck.gstatic.com. It is the same connectivity-check mechanism as generate_204, running against a dedicated hostname that Android builds and some Chrome variants use for their portal probes. The request pattern is identical: the device asks for an empty 204 answer, receives it when the path to the internet is clear, and receives an injected login page when a captive portal is in the way, which is exactly how the device knows to show the sign-in screen.
Everything said about generate_204 transfers unchanged. The entries recur on every join, wake, and periodic re-check, from every Android device on the network, and the frequency is the design working rather than an infection to hunt. Blocking or DNS-filtering the hostname convinces those devices the network is broken or portaled: the symptom is Android phones showing the no-internet exclamation mark, or a sign-in notification, on Wi-Fi that works perfectly for everything else. Networks that filter by list should allow the connectivity-check hosts of every device family they serve, this one alongside the Apple and Microsoft equivalents.
Seen from the other direction, the hostname is also the fastest manual probe when Wi-Fi feels half-broken: requesting it from a browser and getting the blank 204 (shown as an empty page) says the path is clear, while getting a login page or a filter page names the interceptor.

#### What Developers Use Gstatic For
For web developers, the domain mostly means one thing: fonts. Google Fonts serves its stylesheet from fonts.googleapis.com, and that stylesheet points at font files on fonts.gstatic.com, per the Google Fonts documentation. Because the font files live on a different origin than the stylesheet, the standard embed warms the connection early with a preconnect hint:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap" rel="stylesheet">
The crossorigin attribute on the second hint matters: font fetches are CORS requests, so the preconnected socket must match, or the browser opens a second connection and the hint bought nothing.
The cookieless design is worth copying even if you never touch Google's version. Serving static assets from a domain that never sees session cookies keeps every asset request slimmer, removes a whole class of cache-safety questions, and lets caches and CDNs treat the files as what they are: identical bytes for everyone, cacheable for a long time under immutable-style policies.
The main decision point is whether to use fonts.gstatic.com at all. Self-hosting fonts removes a third-party dependency and a privacy disclosure, at the cost of maintaining the files and losing nothing else of substance on modern HTTP. Regulated environments increasingly choose self-hosting; either choice is defensible when made deliberately.

#### Verify It Yourself
Every load-bearing claim in this guide reproduces with two commands. First, the connectivity endpoint:
curl -sS -D - -o /dev/null -A "your-lab/1.0" https://www.gstatic.com/generate_204

HTTP/2 204
cross-origin-resource-policy: cross-origin
content-length: 0
Status 204, no body, and no Set-Cookie header anywhere in the response: the cookieless claim, verified in one request.
Second, the certificate. The recorded check connected to www.gstatic.com on port 443 and read the TLS peer certificate: the subject alternative names cover *.gstatic.com and gstatic.com, and the issuer organization is Google Trust Services, Google's own certificate authority. You can see the same with openssl or by clicking the padlock when a gstatic asset loads in DevTools. Certificate inspection is the definitive test for lookalikes, and it is the same layer of the connection covered from the server's perspective in the TLS fingerprinting guide.
The rule that settles every suspicious sighting: read the registered domain, not the left edge of the hostname. fonts.gstatic.com and www.gstatic.com end in gstatic.com and are Google. Anything that merely contains the string, a gstatic subdomain of an unfamiliar domain or a registration like gstatic plus extra words, is not this domain and deserves the suspicion the name was borrowed to avoid. If such a hostname also fails the certificate check, treat the device that contacted it as worth a malware scan.

#### FAQ
Q: What is the use of gstatic.com?
A: Google uses it to serve static content: fonts, images, stylesheets, scripts, and other fixed assets for Google services and for third-party sites that embed Google Fonts, Maps, or reCAPTCHA. Keeping these files on a separate cookieless domain makes them faster to cache and keeps account cookies out of asset requests.
Q: Is gstatic.com a tracker?
A: It is an asset host, not a cookie-based tracker; its responses set no cookies. Like any CDN, it necessarily sees the IP address and user agent of requests, and its csi subdomain receives performance measurements, which is why some blocklists flag that one endpoint while leaving the rest alone.
Q: Is gstatic.com a virus?
A: No. The domain is owned by Google and serves legitimate static files. Malware does borrow the name through lookalike registrations or subdomains of unrelated domains, so verify the registered domain ends in exactly gstatic.com and that the certificate is issued by Google Trust Services before worrying.
Q: Should I block gstatic.com?
A: Usually not. Blocking it breaks Google Fonts rendering, reCAPTCHA-protected logins and forms, embedded Maps, and device connectivity checks, while gaining little privacy since the domain is cookieless. If you want fewer third-party requests, self-host fonts on your own sites and scope blocking to measurement endpoints.
Q: Why does my phone connect to gstatic.com constantly?
A: Android phones, Chromebooks, and Chrome check connectivity by requesting www.gstatic.com/generate_204, which returns an empty 204 response. The check runs when the device connects, wakes, or periodically, so the entries recur on every Google-ecosystem device. Frequent requests to this endpoint are normal, not an infection.
Q: Why is gstatic in my iPhone or browser website data?
A: Any site you visited that embeds Google Fonts, Maps, or reCAPTCHA caused your browser to fetch assets from gstatic.com, and the browser records the domain alongside the sites themselves. Its presence in website data reflects pages you loaded, not software installed on the device, and clearing it is harmless.

### Proxy Ports Explained: Why the Number Is Convention
URL: https://databay.com/blog/proxy-ports-explained
Author: Databay Research Team. Published: 2026-07-28. Updated: 2026-08-04.

A proxy port number is a convention, not a promise. Learn what 8080, 3128, and 1080 mean and how to tell a wrong-port error from a wrong-protocol one.

#### A Port Is a Door Number, Not a Protocol
When a provider hands you gateway.example:7000, the 7000 is a TCP port: a 16-bit number, 1 to 65535, that tells the operating system which listening program on that host should receive the connection. That is all a port is. It does not declare what language the program behind it speaks, whether it wants HTTP proxy requests or a SOCKS5 handshake, or whether anything is listening at all. Two facts have to line up for a proxy to work, and the port is only one of them: the right program must be listening on that port, and your client must speak the protocol that program expects.
This is the single most common source of proxy configuration pain. A setting labelled "port" sits next to a setting labelled "type" or "protocol," and it is easy to get the number right and the protocol wrong, or to assume a well-known number implies a particular protocol. It does not. The conventions exist and they are useful, but they are habits, not rules the network enforces. The rest of this guide separates the conventions worth knowing from the mismatches worth recognizing, and then reproduces both with a local proxy you can run.

#### The Numbers You Will Actually See
A handful of port numbers recur across proxy documentation because tools and providers copied each other for decades. Knowing them saves time, as long as you remember they predict a likely protocol, never a guaranteed one. The IANA service-name registry assigns some of these formally and leaves others as pure convention.
Conventional proxy ports and what they usually meanPortUsual associationWhat it actually guarantees
8080HTTP proxy (and HTTP servers generally)Nothing; it is the most overloaded port in the list
3128HTTP proxy (Squid's default)Nothing; a habit inherited from Squid
1080SOCKS proxyNothing; the historical SOCKS convention
8888HTTP proxy (many gateways, debuggers)Nothing; popular alternate
80 / 443Plain HTTP / HTTPSThe web ports; some providers front proxies here to survive restrictive firewalls
Provider-specific (7000, 10000, ...)Whatever the provider documentsOnly what the provider's own documentation says

The practical takeaway: read the provider's documentation for the pairing of port and protocol, and treat the conventional numbers as a memory aid rather than a contract. A gateway can serve HTTP proxying on 1080 or SOCKS5 on 8080 if its operator chose to, and some deliberately use 80 or 443 so the traffic looks like ordinary web browsing to a firewall. The HTTP versus SOCKS5 guide covers how the two protocols differ once you are speaking the right one to the right port.

#### Run the Lab: One Port, Two Protocols, Two Failures
The clearest way to internalize "port is not protocol" is to watch one live port accept the right protocol and reject the wrong one, with a third case where the conventional port has nothing behind it. This harness starts a small HTTP forward proxy on the conventional HTTP-proxy port 3128 and drives it with the system curl; it was verified with Node v24.14.0 and curl 8.17.0. The three commands change only the -x proxy argument:
# 1. HTTP protocol to the live HTTP-proxy port: works.
curl -s -x http://127.0.0.1:3128 http://127.0.0.1:8091/inventory
# -> origin saw GET /inventory (curl exit 0)

# 2. SOCKS5 protocol to the SAME live port: wrong protocol.
curl -s -x socks5://127.0.0.1:3128 http://127.0.0.1:8091/inventory
# -> curl: (97) Received invalid version in initial SOCKS5 response

# 3. SOCKS5 to the conventional SOCKS port 1080, nothing listening.
curl -s -x socks5://127.0.0.1:1080 http://127.0.0.1:8091/inventory
# -> curl: (7) Failed to connect to 127.0.0.1 port 1080
Trial 2 is the instructive one. The port is alive and a proxy is genuinely listening, but curl spoke the SOCKS5 opening handshake and the HTTP proxy answered with an HTTP response. curl reports invalid version in initial SOCKS5 response because it expected a SOCKS version byte and got the letter H from HTTP/1.1. Trial 3 never gets that far: nothing is on 1080, so the connection itself fails. Same family of symptom ("my proxy does not work"), two entirely different causes, distinguishable by the error alone.

#### Read the Error: Wrong Port or Wrong Protocol
Once you have seen the two failures side by side, the error message becomes a diagnosis rather than a dead end. When the browser is the client, those same two failures surface as Chrome's proxy and firewall suggestion. The distinction is always the same: did the connection fail to open, or did it open and then break during the protocol conversation?
Mapping the symptom to the causeSymptomMost likely causeFirst thing to check
Connection refused / failed to connect / timeoutNothing is listening on that host and port, or a firewall dropped itThe host and port themselves: is the service up, is the number right, is egress allowed
"invalid version in initial SOCKS5 response," or a proxy that returns HTML/errors when you expected a tunnelThe port is live but you are speaking the wrong protocol to itThe protocol setting: HTTP vs SOCKS5, and http vs https vs socks5 vs socks5h in the client
407 Proxy Authentication RequiredRight port, right protocol, missing or wrong proxy credentialsProxy username and password, and that they went to the proxy not the origin
Works with curl, fails in one appThat application ignores the proxy, uses its own setting, or does not support the schemeThe application's own proxy configuration and NO_PROXY

The curl exit codes make this concrete: exit 7 is a connection failure (check the port), exit 97 in the lab is a SOCKS protocol failure (check the protocol). Other clients use different numbers for the same two conditions, so read the words, not only the code. When a single exit is up but you want to confirm its liveness, protocol result, and headers at a point in time, the proxy checker runs exactly that probe; it inspects one connection rather than proving a whole configuration, so it complements this port-versus-protocol reasoning.

#### Configure It Right the First Time
Every mismatch above is avoidable by treating the provider's documentation as the source of truth for the port-and-protocol pair, and by making the protocol explicit in the client rather than trusting a default. In curl the scheme in the -x value is the protocol: http://, https:// (TLS to the proxy itself), socks5:// (local DNS), or socks5h:// (proxy-side DNS). An https:// destination through an http:// proxy is carried inside a CONNECT tunnel, defined in RFC 9110. Most libraries have the same distinction under a different surface.
# Be explicit about protocol and port; keep the password out of the URL.
curl -x http://GATEWAY:PORT --proxy-user 'USER:PASS' https://example.com/
curl -x socks5h://GATEWAY:PORT --proxy-user 'USER:PASS' https://example.com/
Before blaming the network, confirm four things in order: something is listening on that host and port; you are speaking the protocol that listener expects; your credentials reached the proxy; and the specific application you care about actually honors the setting. A proxy changes the route your traffic takes; it never changes what you are authorized to reach, and a port or protocol that finally connects is not permission to bypass a control the destination enforces. For the protocol decision itself, the HTTP versus SOCKS5 comparison goes deeper; for what a proxy is doing to the connection underneath the port, the proxy fundamentals guide traces the full path; and when you need a maintained gateway whose documented ports and protocols simply match what you configured, that is what managed networks are for.

#### FAQ
Q: What port do proxies use?
A: There is no single proxy port. Common conventions are 8080, 3128, and 8888 for HTTP proxies and 1080 for SOCKS, but these are habits, not rules. A proxy can listen on any port its operator chooses, including 80 or 443, so always use the port the provider documents.
Q: Does the port number tell me if a proxy is HTTP or SOCKS5?
A: No. The port predicts a likely protocol by convention but guarantees nothing. A gateway can serve HTTP proxying on 1080 or SOCKS5 on 8080. Confirm the protocol from the provider's documentation and set it explicitly in your client.
Q: Why does my proxy connect on the right port but still fail?
A: Usually a protocol mismatch. If the port is live but you speak the wrong protocol, the handshake breaks, for example curl reports 'invalid version in initial SOCKS5 response' when it sends a SOCKS greeting to an HTTP proxy. Check the protocol setting, not just the port.
Q: What is the difference between a connection error and a protocol error?
A: A connection error (curl exit 7, 'failed to connect') means nothing is listening on that host and port, or a firewall blocked it, so check the port. A protocol error means the port is live but the client and server disagree on the protocol, so check HTTP versus SOCKS5.
Q: Can a proxy run on port 443?
A: Yes. Some providers deliberately serve proxies on 80 or 443 so the traffic resembles ordinary web browsing and passes restrictive firewalls. The port being 443 does not make it HTTPS-only or a web server; it is still whatever proxy protocol the operator configured.

### What Are Backconnect Proxies? One Gateway, Many Exits
URL: https://databay.com/blog/what-are-backconnect-proxies
Author: Databay Research Team. Published: 2026-07-28. Updated: 2026-08-04.

A backconnect proxy is one gateway address in front of a rotating pool of exits. See the architecture demonstrated on a local gateway.

#### One Address You Configure, Many Addresses the Site Sees
"Backconnect" is a vendor word for an architecture, not a protocol you will find in an RFC. A backconnect proxy gives you a single, stable entry point, one hostname and port, that you put into your client once and never change. Behind that entry point the provider operates a pool of exit addresses, and the connection your destination actually sees comes from one of them. The name captures the inversion: instead of you connecting out to a specific proxy IP, you connect to a gateway that connects back out through whichever exit it selects.
This is why the same service is marketed as a "rotating proxy," a "proxy gateway," or a "backconnect network": those are three names for the same delivery model. The word tells you how addresses are delivered (through a gateway, from a pool) and nothing about protocol, network origin, or legitimacy. A backconnect gateway can front residential, datacenter, ISP, or mobile exits; those describe where the exits live, while backconnect describes how you reach them.
Backconnect versus a single fixed proxy endpointQuestionFixed proxy endpointBackconnect gateway
What you configureOne proxy IP and portOne gateway host and port
Source address the destination seesThat one proxy IPAn exit chosen from a pool
To change exitReconfigure the client with a different IPChange nothing; the gateway rotates, or a credential parameter pins
Pool size visible to you?N/ANo; the gateway hides it

The rest of this guide takes that architecture apart on a gateway small enough to read, because the mechanism is easier to trust when you have watched one address turn into several.

#### Run the Lab: One Gateway, Two Exits
This gateway binds only to loopback and relays to a lab origin you also run. It sends each request out through a different local source address using the Node.js socket localAddress option, which is the smallest honest stand-in for "egress through a different network address." It uses absolute-form request targets exactly as a real HTTP proxy does. Save it as backconnect-lab.mjs; it was verified with Node v24.14.0.
// backconnect-lab.mjs: one gateway address, two exits behind it.
// Loopback only. Point it at nothing except the lab origin.
import http from 'node:http';

const EXITS = ['127.0.0.2', '127.0.0.3'];
let turn = 0;

http.createServer((request, response) => {
console.log(`[origin] ${request.url} from ${request.socket.remoteAddress}`);
response.end('ok\n');
}).listen(8091, '127.0.0.1');

http.createServer((request, response) => {
let target;
try { target = new URL(request.url); } catch {
response.statusCode = 400;
return response.end('absolute-form target required\n');
}
if (target.hostname !== '127.0.0.1' || target.port !== '8091') {
response.statusCode = 403;
return response.end('lab gateway relays to the lab origin only\n');
}
const exit = EXITS[turn++ % EXITS.length];
http.get({ host: target.hostname, port: target.port, path: target.pathname, localAddress: exit }, (upstream) => {
response.writeHead(upstream.statusCode ?? 502);
upstream.pipe(response);
}).once('error', () => { response.statusCode = 502; response.end('exit failed\n'); });
}).listen(8090, '127.0.0.1', () => console.log('gateway on 127.0.0.1:8090'));
Start it with node backconnect-lab.mjs, then send four requests to the same gateway address and watch the origin's log:
for i in 1 2 3 4; do curl -s -x http://127.0.0.1:8090 http://127.0.0.1:8091/request-$i; done
The client configuration (-x http://127.0.0.1:8090, curl's documented proxy flag) is identical on every call, yet the origin recorded four connections from two alternating addresses:
[origin] /request-1 from 127.0.0.2
[origin] /request-2 from 127.0.0.3
[origin] /request-3 from 127.0.0.2
[origin] /request-4 from 127.0.0.3
That is the whole trick. One gateway, a pool behind it, rotation on the provider's side. The committed verification harness extends this to three exits and adds the sticky-session behavior described next; its recorded run is in the evidence file linked from this article's brief.

#### Rotation Policy Lives in the Credentials
A gateway that rotated on every single request would be unusable for any task that needs continuity: a multi-step form, a paginated result set, a login that sets a cookie. So backconnect providers expose rotation policy as a parameter, and the near-universal convention is to encode it in the proxy username rather than in a separate setting. You authenticate to the gateway with Proxy-Authorization, and the username carries session and geo instructions the gateway parses.
In the verification harness a username containing session-abc123 pinned three consecutive requests to a single exit, while a different token, session-zz9, mapped to a different one. Requests with no session token rotated per request. The exact grammar differs by provider (some use sticky-, some append a TTL, some take a country code), but the shape is consistent:
# Rotate every request: no session token
curl -x http://user:pass@gateway.example:7000 https://example.com/

# Sticky: the same session id reuses one exit until it expires
curl -x http://user-session-abc123:pass@gateway.example:7000 https://example.com/
Two consequences follow. First, "sticky" is not permanent: a pinned exit is held for a provider-defined window or until it fails, then the session moves. Second, session identifiers are your control surface for continuity and your responsibility for isolation, one identifier per logical workflow, never shared across jobs that must not correlate. The static versus rotating guide works through the session-design decisions this exposes: how long to hold a session, when to rotate deliberately, and how retry policy interacts with a moving exit.

#### What Backconnect Does Not Tell You
Because backconnect describes only the delivery model, most of the questions that decide whether a service fits your job are left unanswered by the label, and a pool that hides its own size can hide its own quality. Judge the network, not the architecture.
The label is silent on all of theseWhat actually mattersWhy the backconnect label does not settle it
Network origin of the exitsA gateway can front residential, datacenter, ISP, or mobile addresses; each has different sourcing and consent questions
Pool size and freshnessHidden by design; a small or stale pool rotates you into recently-used addresses
How exits are sourced and consentedA separate due-diligence question, especially for residential and mobile supply
Protocol supportHTTP, HTTPS via CONNECT, and SOCKS5 are per-service; the gateway model implies none of them
Session TTL and geo controlsProvider-specific parameter grammar, not part of "backconnect"

Two clarifications kill the most common confusions. A backconnect gateway does not make traffic anonymous: the destination still observes cookies, accounts, TLS behavior, and everything catalogued in the proxy fundamentals guide, and a rotating source address changes none of it. And rotation is not a way around a control: if a destination returns a 403, 429, CAPTCHA, or account restriction, a fresh exit is a signal to stop and check authorization, not a lever to pull. A proxy changes the route, never the permission.

#### Verify the Gateway Before You Trust It
Two checks separate a working backconnect service from a marketing claim, and both use tools you already have. First, confirm rotation is real: send several requests with no session token and read back the exit each time. Second, confirm stickiness holds: send several with one session token and confirm the exit stays put. Use an endpoint you are authorized to hit that echoes the source address, such as Databay's own IP echo.
# Does the gateway rotate? Expect different values.
for i in 1 2 3; do \
curl -s -x http://USER:PASS@GATEWAY:PORT \
https://databay.com/what-is-my-ip/json; done

# Does a session stick? Expect one repeated value.
for i in 1 2 3; do \
curl -s -x http://USER-session-test01:PASS@GATEWAY:PORT \
https://databay.com/what-is-my-ip/json; done
Record the observed exits, the session grammar the provider documents, and whether protocol support (HTTP, CONNECT for HTTPS, SOCKS5) matches what you configured. For a point-in-time liveness and header read on any single exit, the proxy checker is the companion diagnostic; it inspects one connection rather than proving pool behavior, so run it alongside these loops, not instead of them.
When the requirement is a maintained gateway with a documented session grammar and named accountability for how the pool is sourced, that is what managed residential and datacenter networks provide. Backconnect is the shape of the service; the quality is in the exits behind it and the operator who stands behind those.

#### FAQ
Q: What is a backconnect proxy?
A: It is a single gateway address in front of a pool of exit addresses. You configure one stable host and port, and the destination sees a connection from an exit the gateway selects. The same model is also marketed as a rotating proxy or proxy gateway.
Q: What is the difference between backconnect and rotating proxies?
A: They usually name the same service. Backconnect describes the architecture (one gateway, a pool behind it); rotating describes the behavior (the exit changes). A backconnect gateway is how rotation is typically delivered, and it also supports pinned sticky sessions.
Q: Do backconnect proxies change IP on every request?
A: By default many do, but you control it. A session token in the proxy username pins requests to one exit for a provider-defined window, so a multi-step workflow can hold a stable address while other jobs rotate.
Q: Are backconnect proxies more anonymous?
A: No. Rotating the source address changes one signal. The destination still observes cookies, accounts, TLS and HTTP behavior, and timing, and the gateway operator sees your traffic. Backconnect is a delivery model, not an anonymity guarantee.
Q: Does backconnect tell me whether the proxies are residential?
A: No. A backconnect gateway can front residential, datacenter, ISP, or mobile exits. The label describes how addresses are delivered, not their network origin, which is a separate sourcing and due-diligence question.

### What Is a Web Proxy? How URL-Based Browsing Works
URL: https://databay.com/blog/what-is-a-web-proxy
Author: Databay Research Team. Published: 2026-07-28. Updated: 2026-07-28.

A web proxy is a website that fetches pages for you and rewrites every link. See exactly what it changes, what breaks, and what its operator can read.

#### A Website That Browses on Your Behalf
A web proxy is a website with a URL box. You paste an address, the proxy's server fetches that page itself, rewrites the links inside it so they point back through the proxy, and serves you the result. Nothing is installed and no browser or system setting changes; the whole exchange is an ordinary visit to the proxy's own site. Older documentation calls the same idea a CGI proxy, and consumer services often market it as an “anonymizer” or “free web proxy.”
That deployment model is the defining difference from the proxies covered in the rest of this cluster. A configured proxy server is an address your client software is told to use, and it relays connections; a web proxy is a destination you browse to, and it fetches documents. The distinction sounds small and changes almost everything: who opens the connection to the destination, where TLS ends, which security boundaries the browser applies, and why pages break.
Three tools that get called “a proxy,” comparedQuestionWeb proxy (this page)Configured proxy serverVPN
How you use itVisit a website, paste a URLSet it in an application, script, or OS policyInstall a client or profile at the OS layer
What it carriesPages its rewriter understands, one document at a timeConnections from every application configured to use itNormally all traffic from the device or tunnel scope
Who contacts the destinationThe proxy's web server, with its own HTTP clientThe proxy service, relaying your client's connectionYour applications, through an encrypted network path
Where TLS to the destination endsAt the proxy site, by designAt your client when tunneled with CONNECTAt your client
Typical failureRewriting misses a URL and the page breaksMisconfigured client, DNS, or authenticationRouting, DNS, or kill-switch policy

Like every intermediary, a web proxy changes the route a request takes. It does not grant permission to reach anything, it does not make you anonymous to the operator in the middle, and whether it may be used at all is governed by the network you are on and the destination's terms.

#### One Page Load, Two HTTP Conversations
When you browse through a web proxy there are two separate HTTP conversations. The first is between your browser and the proxy site: a normal HTTPS website visit, carrying your cookies for that site, your user agent, and the target URL as a query parameter. The second is between the proxy's server and the destination: a fresh request made by the proxy's own HTTP client, from the proxy's network address, with whatever headers the operator's software chooses to send.
In the lab this guide is built on, the client requested the page with User-Agent: lab-client/1.0 and a cookie named client-secret. The origin's log recorded something else entirely:
[origin] GET / ua=webproxy-lab/1.0 cookie=none
The visitor's user agent and cookie never crossed. That is not a privacy promise, it is an implementation detail: the proxy simply did not copy them. A different operator could forward your user agent, your language headers, or an X-Forwarded-For field naming your address, and from the outside you cannot verify which choice was made. The destination, meanwhile, sees the proxy's exit address as the network peer for the fetch, which is the one property web proxies are usually used for.
Keep the two-conversation picture in mind for the rest of this guide. Every capability and every failure of a web proxy comes from the same fact: your browser never talks to the destination. Something in the middle reads the page first, and everything you see afterward is its retelling.

#### URL Rewriting Is the Entire Mechanism
Fetching one document is easy. The hard part is what happens next: every link, form, image, stylesheet, and script reference inside that document still points at the destination. If the proxy served the page unchanged, your very next click would leave the proxy and connect directly. So the proxy parses the HTML and rewrites addressing attributes to point back into itself. In the lab, the origin's page contained an absolute link, a relative link, a form, and an image; the proxied copy came back with all four rewritten:
<!-- served by the origin -->
<a href="/docs">Relative link</a>

<!-- served by the web proxy -->
<a href="/browse?url=http%3A%2F%2F127.0.0.1%3A8091%2Fdocs">Relative link</a>
Following the rewritten link keeps the session inside the proxy: the lab's second origin request, for /pricing, again arrived from the proxy's client rather than the visitor's browser. Navigation only stays proxied because the rewriter caught the URL.
Cookies need the same treatment. Under RFC 6265, a cookie belongs to the site the browser actually talked to, and the browser talked to the proxy. A destination's Set-Cookie: session=origin-value cannot live on its own origin any more, so the lab proxy re-namespaced it before passing it on:
Set-Cookie: wp__127.0.0.1_8091__session=origin-value; Path=/; HttpOnly
Every site you visit through one web proxy shares that proxy's cookie space, separated only as well as the operator's namespacing discipline. Your logged-in sessions, if you create any, are stored by and addressable to the proxy site, not to the services they belong to.

#### Run the Lab: a 40-Line Web Proxy on Loopback
The fastest way to understand a web proxy is to run one against a page you control. This miniature version binds only to 127.0.0.1, refuses every destination except its own lab origin, and uses the built-in Node.js http module. It was written and verified with Node v24.14.0; save it as web-proxy-lab.mjs and do not point it at third-party sites.
// web-proxy-lab.mjs: a deliberately minimal URL-rewriting web proxy.
// Loopback only. Point it at nothing except the lab origin.
import http from 'node:http';

const ORIGIN = 'http://127.0.0.1:8091';

http.createServer((request, response) => {
console.log(`[origin] ${request.method} ${request.url}`,
`ua=${request.headers['user-agent']}`,
`cookie=${request.headers.cookie ?? 'none'}`);
response.setHeader('Set-Cookie', 'session=origin-value; Path=/');
response.setHeader('Content-Type', 'text/html; charset=utf-8');
response.end(`<h1>Origin ${request.url}</h1>
<a href="/docs">Relative link</a>
<script>fetch('/api' + '/quote').catch(() => {});</script>`);
}).listen(8091, '127.0.0.1');

http.createServer(async (request, response) => {
const url = new URL(request.url, 'http://127.0.0.1:8090');
const target = url.searchParams.get('url');
if (url.pathname !== '/browse' || !target || !target.startsWith(ORIGIN)) {
response.statusCode = 403;
return response.end('this lab proxy only serves the lab origin');
}
const upstream = await fetch(target, { headers: { 'user-agent': 'webproxy-lab/1.0' } });
const html = (await upstream.text()).replace(
/(href|src|action)="([^"]+)"/g,
(_, attr, value) => `${attr}="/browse?url=${encodeURIComponent(new URL(value, target).href)}"`,
);
const cookie = upstream.headers.get('set-cookie');
if (cookie) response.setHeader('Set-Cookie', `wp__origin__${cookie}`);
response.setHeader('Content-Type', 'text/html; charset=utf-8');
response.end(html);
}).listen(8090, '127.0.0.1', () => {
console.log('browse: http://127.0.0.1:8090/browse?url=' + encodeURIComponent(ORIGIN + '/'));
});
Start it with node web-proxy-lab.mjs, then request the origin through the proxy from a second terminal, posing as a client with a secret cookie:
curl -s -i -A "lab-client/1.0" -b "client-secret=1" \
"http://127.0.0.1:8090/browse?url=http%3A%2F%2F127.0.0.1%3A8091%2F"
Three observations to verify against your own run: the origin's console line shows ua=webproxy-lab/1.0 cookie=none, so nothing identifying the client crossed; the response HTML has the link rewritten onto /browse?url=; and the response's Set-Cookie arrives renamed with the wp__origin__ prefix. Then look at what was not rewritten, because that is the next section.

#### Why Modern Sites Break Inside One
The lab origin's page ends with a script that assembles its request target at runtime: fetch('/api' + '/quote'). The proxied copy of the page contains that script byte for byte, unrewritten. The rewriter never had a chance: the string /api/quote does not exist in the document, it is created inside a JavaScript engine after delivery. When the browser runs it, the request goes to the proxy's origin, where no such API exists, or to wherever an absolute runtime URL points, escaping the proxy entirely.
That is the structural blind spot, and modern sites are built almost entirely inside it. Single-page applications construct API endpoints from configuration, bundlers emit dynamic imports, and scripts fetch JSON, media segments, and further scripts from URLs that only exist at runtime. A production rewriter can try to intercept more surfaces than the lab's regex does, and the serious ones inject client-side shims that patch browser APIs, but each uncovered channel is a broken feature: a login that loops, a search box that does nothing, a video that never starts, an upload that dies.
The browser's own security model adds a second layer of breakage. Under the same-origin policy, storage, script access, and service workers are partitioned by the origin the browser sees, and through a web proxy that origin is the proxy site, for every destination at once. Sites that depend on origin-scoped state (local storage, IndexedDB, workers, OAuth redirect flows that compare origins) are running under an identity they were not written for. WebSocket, streaming, and upload endpoints each need their own dedicated relay support in the proxy, so whether they work at all varies by implementation. None of this is fixable by the visitor; it is the cost of the retelling.

#### The Operator Terminates TLS by Design
The padlock you see while using a web proxy describes your connection to the proxy site. Under TLS 1.3, the server that is authenticated is the one you connected to, and that is the proxy. When the destination is an HTTPS site, the proxy's server opens its own separate TLS session to fetch the page. Between those two encrypted legs, inside the operator's process, the content exists as plaintext; that is precisely where the rewriting from earlier sections happens. The lab's proxy recorded handling the origin's full page body on every fetch, because it had to read it to rewrite it.
This is not an accusation about any particular service; it is the architecture. Whoever operates a web proxy is positioned to read every page you view through it, every form value you submit, every credential you type, and every re-scoped session cookie it stores on your behalf, and to alter any of it in transit. Whether an operator logs, retains, sells, or injects into that stream is a policy you generally cannot audit from the outside.
Treat the decision like handing your browsing to a stranger's browser, because mechanically that is what it is. Before using one for anything beyond a disposable public page: identify who operates it, find a retention statement you actually believe, understand how a free service pays for its bandwidth, and never authenticate to another site through it. A configured proxy differs here in a specific, checkable way: when a client tunnels HTTPS with CONNECT, the intermediary relays encrypted bytes and your TLS session terminates at the destination. The configured proxy guide traces that boundary hop by hop.

#### When a Web Proxy Fits, and When It Cannot
A web proxy is a reasonable tool for understanding intermediaries (the lab above exists for exactly that) and for a disposable, unauthenticated look at a public page when installing nothing matters more than fidelity, on a network whose rules permit it. It is the wrong tool for anything repeatable, authenticated, sensitive, or professional, and it grants no permission: destination terms and the policy of the network you are on continue to apply, and this guide does not cover routing around either. If a school, workplace, or platform restriction is the obstacle, the answer is authorization, not an intermediary.
For real work, pick the tool whose boundary matches the job. If an application needs a controlled network path with credentials, session control, and end-to-end TLS, use a configured proxy and verify the exit with the proxy checker before production traffic. If the goal is device-wide coverage rather than one application, the proxy versus VPN comparison walks the decision. If the question is whether a collection workflow is permitted at all, the risk-based compliance guide covers authorization, terms, and data duties before any traffic starts. And when the requirement is a maintained egress network with named accountability rather than an anonymous free site, that is what managed residential and datacenter networks are for.
The durable takeaway is the mechanism. A web proxy is a website that fetches on your behalf, rewrites what it can see, and retells the result from its own origin. Everything else (the convenience, the breakage, the operator's total visibility) follows from that one design.

#### FAQ
Q: What does a web proxy do?
A: It is a website that fetches another page for you. Its server requests the target with its own HTTP client, rewrites the links and references inside the response so navigation stays on the proxy site, and serves you the rewritten copy. The destination is contacted by the proxy's server, not by your browser.
Q: Is it safe to log in to a site through a web proxy?
A: Treat it as unsafe. The proxy terminates TLS by design, so credentials and session cookies pass through the operator's process as plaintext, and re-scoped session cookies are stored under the proxy's origin. Only authenticate through infrastructure you control or have a contractual reason to trust.
Q: Why do sites break inside a web proxy?
A: Rewriters can only rewrite URLs that exist in the delivered document. URLs assembled by JavaScript at runtime are invisible to them, and the browser's same-origin policy scopes storage and workers to the proxy's origin instead of the destination's. Dynamic applications depend on both, so features fail.
Q: Does a web proxy hide my IP address?
A: The destination sees the proxy's address for requests the proxy makes, but runtime-generated requests can escape the rewriter and go direct, and the operator sees your real address, your target URLs, and the full content. Which of your headers the proxy forwards is the operator's choice and is not verifiable from outside.
Q: What is the difference between a web proxy and a VPN?
A: A web proxy carries single documents it can successfully rewrite, with TLS terminating at the proxy site. A VPN moves the whole device's traffic at the network layer, with TLS still ending at your client. They differ in scope, trust model, and failure modes rather than being interchangeable.
Q: Is using a web proxy legal?
A: The software category is ordinary networking technology, but a specific use is governed by the destination's terms, the policy of the network you are on, and local law. An intermediary never converts a prohibited access into a permitted one. This is general information, not legal advice.

### Free Proxy List Benchmark: 2,911 Proxies Tested
URL: https://databay.com/blog/free-proxy-list-benchmark
Author: Databay Research Team. Published: 2026-06-11. Updated: 2026-07-20.

Results from a June 11, 2026 test of 2,911 entries across seven free proxy lists, covering availability, HTTPS, latency, stability, and study limits.

#### What the June 11 Snapshot Found
This benchmark compared 2,911 entries captured from seven provider-published free proxy lists on June 11, 2026. Each fixed IP:port snapshot was tested in three rounds from one runner. Across the three rounds, Databay's list had the highest average availability in this sample at 63.9%, followed by ProxyScrape at 36.7%. The remaining lists averaged between 2.5% and 20.3%.
Those figures describe one dated snapshot, not a permanent ranking or a promise about what a reader will receive later. Public relays change quickly, and a different capture time, runner location, destination, timeout, or scoring rule can change the order. Databay also operated the benchmark and was one of the compared sources. The frozen inputs, harness, raw round files, and aggregation code are published in the free-proxy-list-benchmark repository so readers can inspect the exact run rather than relying on the headline.
ListEntriesAliveHTTPSGoogleAmazonMedian latency
databay.com49763.9%36.9%32.4%16.8%1,067 ms
proxyscrape.com50036.7%23.5%17.5%9.9%1,825 ms
floppydata.com31420.3%15.3%11.9%3.8%1,220 ms
proxiware.com50012.9%5.8%3.8%1.6%1,320 ms
nodemaven.com5007.7%3.8%2.5%1.5%2,214 ms
roundproxies.com1004.7%3.0%2.3%1.7%2,442 ms
geonode.com5002.5%1.8%1.6%0.9%2,160 ms

#### The Published Inputs and Run Window
The committed snapshot contains 497 Databay entries, 500 ProxyScrape entries, 500 Geonode entries, 314 FloppyData entries, 100 RoundProxies entries, 500 NodeMaven entries, and 500 Proxiware entries. The loader removes duplicate IP:port entries within each source before testing. Protocol labels come from the source files: HTTP, HTTPS, SOCKS4, or SOCKS5.
The run metadata records a start at 02:29:01 UTC and completion at 02:53:11 UTC on June 11. The three probe rounds began at 02:36:06, 02:44:38, and 02:53:11 UTC. All 2,911 entries appear once in each raw round file. Holding the input fixed across rounds lets the report distinguish initial availability from short-window persistence.
The repository does not include the separate collection program that fetched each provider's list. It does include the captured list files and source descriptions. This means readers can verify exactly what was tested and recalculate the results, while the claim that every provider snapshot represented its freshest possible output still depends on the documented collection process.

#### How Each Endpoint Was Tested
A relay was marked alive when it completed at least one of the benchmark's basic HTTP or HTTPS reachability checks. HTTPS capability records whether the route completed a TLS tunnel. The Google check required https://www.google.com/generate_204 to return HTTP 204; the Amazon check required https://www.amazon.com/robots.txt to return HTTP 200. Latency is the fastest successful round trip recorded for an alive result.
The harness also compared the observed exit address with the runner's public address. A separate best-effort HTTP header reflection check classified results as elite, anonymous, transparent, or unknown. That classification is less complete than the reachability metrics because many free relays could not reach the reflection service before the deadline.
A successful control request proves only that the relay completed that specific request at that time. It does not prove authorization, account safety, browser compatibility, destination acceptance, or access to another host. A failed Google or Amazon check can reflect relay failure, protocol handling, rate limiting, destination policy, or a transient network error.

#### Availability Across Three Rounds
Databay's 497-entry snapshot returned 320, 315, and 318 alive results across the three rounds: 64.4%, 63.4%, and 64.0%. ProxyScrape returned 191, 171, and 188 alive results from 500 entries. FloppyData returned 64, 67, and 60 from 314.
The largest short-window change was NodeMaven: 81 of 500 entries were alive in round one, followed by 15 and 20. The benchmark's stability metric asks what share of round-one survivors remained alive in every round. On that definition, Databay recorded 73.4%, FloppyData 64.1%, Proxiware 55.7%, ProxyScrape 46.1%, RoundProxies 33.3%, Geonode 28.6%, and NodeMaven 16.0%. Small survivor counts make the lower-volume percentages especially uncertain.

#### The Composite Score Is a Chosen Summary, Not Ground Truth
The repository calculates a 0–100 composite using 30% availability, 20% Google, 15% Amazon, 10% HTTPS, 10% IP-hidden, and 15% latency. Latency falls linearly from a score of one at zero milliseconds to zero at 5,000 milliseconds. On those weights, the published scores are Databay 50.0, ProxyScrape 31.5, FloppyData 23.9, Proxiware 17.8, NodeMaven 12.6, RoundProxies 10.6, and Geonode 10.1.
The weights express one preference: basic reliability first, followed by two destination checks. A reader who cares primarily about SOCKS support, a specific geography, or a different destination should not use that composite unchanged. The raw metrics are more informative than the rank, and the aggregation code deliberately keeps the weights in one editable definition.

#### Overlap Does Not Explain Quality by Itself
The report calculates Jaccard overlap between source snapshots. Geonode and Proxiware had the largest measured overlap at 0.322, representing 243 shared IP:port entries. Geonode and RoundProxies followed at 0.200 with 100 shared entries. Databay and ProxyScrape overlapped at 0.126 with 106 entries, while most source pairs were below 0.10.
Overlap shows that providers sometimes publish the same public endpoints. It does not establish why one list performed better. Collection timing, checking cadence, protocol labels, source selection, and relay churn can all affect both overlap and availability. The data supports reporting the shared counts; it does not support claiming that overlap caused failure or that a low-overlap list necessarily came from a superior pipeline.

#### Recalculate the Report From the Repository
The repository separates inputs, observations, and outputs. The lists/ directory holds the fixed provider snapshots. results/proxies.json records the loaded endpoint set. results/raw/round_1.jsonl through round_3.jsonl contain endpoint-level observations. results/run_meta.json records timestamps and probe configuration. The analyzer produces summary.csv, per_round.csv, report.md, and charts from those raw rows.
Install the declared Python dependencies, then run python analyze_results.py --in results to regenerate the aggregate report without making new proxy requests. Running python run_benchmark.py probes the committed endpoints again, but a later network run should be treated as a new observation because public relays and destination behavior change. Preserve the commit hash, UTC time, runner region, dependency versions, and output manifest when comparing runs.

#### Safety, Ethics, and Study Limits
Free proxies are operated by unknown parties. Do not send passwords, payment data, private documents, session cookies, or other sensitive information through them. HTTPS protects content between a correctly validated client and destination, but an untrusted route can still log connection metadata, fail unpredictably, redirect plain HTTP, or present a certificate error that must never be ignored.
This study has several limits: one capture date, one runner region, a short three-round window, unequal source sizes, source-supplied protocol labels, incomplete header-reflection coverage, and a composite designed by Databay. Databay's list was evaluated by Databay, creating a commercial conflict even though the inputs and calculations are public. No result authorizes requests to a third-party site or predicts that site's future treatment.
Use this benchmark as a dated reliability sample and a reusable measurement method. For operational work, prefer an official API, feed, or controlled proxy service with documented ownership, authentication, support, and acceptable-use terms.

#### FAQ
Q: Which list performed best in this benchmark?
A: Databay had the highest measured availability and composite score in the June 11, 2026 snapshot. That is a result from one Databay-run comparison, not a permanent or independent claim that it is always the best free proxy list.
Q: Can I reproduce the published calculations?
A: Yes. The repository includes the fixed list snapshots, exact loaded endpoints, three raw result files, run metadata, analyzer, CSV summaries, report, and charts. Re-running the analyzer recalculates the published aggregates. Re-probing later creates a new network observation.
Q: Why will a later run produce different results?
A: Public relays appear, disappear, change operators, or become blocked quickly. Runner location, DNS, destination policy, timeout, and network conditions also change. Record a new timestamp and compare it as a separate run.
Q: Does a Google or Amazon pass mean a proxy will work elsewhere?
A: No. It proves only that one control request returned the expected status during that round. Another destination can apply different network, client, account, rate, and authorization rules.
Q: Are free proxies safe for accounts or sensitive data?
A: No. Treat every unknown free relay as untrusted. Do not send credentials, payments, private data, or valuable sessions through it, and never bypass certificate validation.
Q: Why not rely only on the composite score?
A: The composite uses chosen weights. Review availability, protocol, latency, geography, stability, and destination-specific measurements separately, then apply criteria that match an authorized workload.

### Residential IP Reputation: 1,000 Published Observations
URL: https://databay.com/blog/residential-ip-reputation-leaderboard
Author: Databay Research Team. Published: 2026-05-07. Updated: 2026-07-20.

What 1,000 redacted route observations across 25 ASNs show about DNSBL labels, Tor and DROP checks, network classification, and dataset limits.

#### Start With the Downloadable Artifact
The public residential IP reputation CSV contains 1,000 rows associated with 25 claimed residential ASNs. The rows comprise 624 IPv4 observations and 376 IPv6 observations. IPv4 addresses are represented as /24 network prefixes and IPv6 addresses as /48 prefixes, so the file does not disclose full exit addresses.
The artifact supports recalculating counts for its populated columns. It does not support independently replaying the original capture because it omits full addresses, per-row timestamps, raw DNS or API responses, software versions, resolver details, failed candidate attempts, and the capture harness. The correct unit is therefore a published route observation, not a publicly verifiable unique full IP. The file contains 981 distinct redacted prefixes; multiple full addresses can legitimately share one prefix.

#### What the CSV Directly Shows
All 1,000 rows have a claimed ASN, carrier, country, redacted prefix, address family, Cloudflare-observed ASN and country, legacy Cloudflare threat score, and known-bot boolean. The applicable Spamhaus DROP column is populated for each address family, and the ASN-level DROP and Tor fields are populated for every row.
Published observationCountInterpretation
Rows1,000Published route observations
Claimed ASNs2540 rows per claimed ASN
IPv4 / IPv6624 / 376Address-family split
Tor exit matches0No published row matched the captured Tor list result
Applicable Spamhaus DROP matches0No published row is marked true
ASN DROP matches0No claimed ASN is marked true
Non-empty DNSBL labels501494 Spamhaus ZEN labels and 7 DroneBL labels
Claimed/observed ASN agreement96896.8% of rows
Claimed/observed country agreement99899.8% of rows

#### A DNSBL Label Is Not a General Web-Reputation Score
The dnsbl_listed_in column is non-empty for 501 of the 624 IPv4 rows: 494 contain spamhaus_zen and 7 contain dronebl. That is 80.3% of the IPv4 sample. The CSV does not publish the raw DNS answers or individual Spamhaus subzone return codes, so it cannot show which ZEN component produced each label.
This distinction matters because Spamhaus ZEN aggregates several email-oriented lists, including the Policy Block List. Consumer broadband can be listed for SMTP policy reasons without being classified as malicious web traffic. A combined ZEN label should not be converted into a universal “bad IP” verdict or used to predict whether a website will accept an HTTP request.
The zero DROP results answer a different question: none of the published rows is marked as belonging to an applicable DROP network in this snapshot. They do not prove that an address was safe, authorized, household-operated, or free from destination-specific restrictions.

#### Four Reserved Enrichment Columns Are Empty
The CSV includes columns named ip2location_proxy_type, abuseipdb_confidence, ipinfo_hosting, and greynoise_class. Every value in those four columns is blank across all 1,000 rows. They are placeholders, not completed measurements, and they are intentionally excluded from this page's Dataset variableMeasured list.
A blank value does not mean zero, clean, residential, benign, or unknown according to the named provider. It means the public file contains no result. Any comparison involving those services requires a new, authorized capture using their current APIs or licensed datasets, with the response fields and timestamps preserved.

#### How to Read the Cloudflare Fields
The CSV records cf_threat_score=0 and cf_client_bot=false for every row. Cloudflare's current documentation states that cf.threat_score is now always zero, so this field has no variance and cannot rank the routes. It should not be presented as proof that Cloudflare considered an address trustworthy.
cf.client.bot indicates whether a request came from a known good bot or crawler. A value of false does not mean human, safe, or accepted; it only means the request was not identified through that known-bot field. Cloudflare Bot Management's granular 1–99 score is a separate Enterprise feature and is not present in this CSV.
The destination-side ASN and country fields are more useful here. They agree with the claimed ASN in 968 rows and claimed country in 998 rows. Those are classification comparisons for this capture, not guarantees about later routes or every geolocation database.

#### This Dataset Does Not Produce a Best-ASN Leaderboard
Forty rows are associated with each claimed ASN, but the populated fields do not measure destination success, latency, abuse history, consent, session quality, or long-term stability. DNSBL coverage is dominated by an email-policy aggregate, while the Tor and DROP columns are uniformly false. Ranking ASNs from those fields would create a score without a defensible outcome variable.
The dataset can support narrower questions: address-family mix, whether the applicable published lists marked a row, how often claimed and Cloudflare-observed ASN or country agreed, and which fields are absent. It cannot establish which carrier is “best” for scraping, accounts, advertising, purchasing, or any other third-party workflow.

#### Recalculate the Published Aggregates
A reader can reproduce the counts above from the CSV without contacting any proxy or third-party reputation service. Count rows by ip_version; count distinct asn_claimed; filter non-empty dnsbl_listed_in; compare asn_claimed after removing its AS prefix with cf_asn_observed; and compare the two country columns.
Preserve the downloaded file and record its SHA-256 hash before analysis. Treat blank strings as missing, not false. Apply spamhaus_drop_v4 only to IPv4 rows and spamhaus_drop_v6 only to IPv6 rows. Do not infer full-address uniqueness from redacted prefixes.
Reproducing the original network capture would require additional materials that are not distributed: the full addresses under appropriate access controls, capture timestamps, raw lookup responses, resolver and software configuration, candidate-selection records, retry logic, and a versioned harness.

#### Responsible Use and Practical Meaning
Reputation sources answer different questions. Tor lists identify published exits. DROP lists identify networks Spamhaus recommends dropping. DNSBLs are largely designed for messaging abuse and policy. ASN and country databases classify network origin. Bot-management products evaluate a request using additional client, account, sequence, and behavior signals.
Use the source designed for the decision you need to make, document its timestamp, and avoid turning a missing or unrelated field into a broad trust score. For systems you operate, combine narrowly relevant signals with rate limits, authentication, monitoring, and a review path. For third-party data access, prefer official APIs, feeds, licenses, and written authorization.

#### FAQ
Q: Does the CSV publish 1,000 full IP addresses?
A: No. It publishes 1,000 rows with IPv4 /24 or IPv6 /48 prefixes. The full addresses and per-row timestamps are not distributed.
Q: Were AbuseIPDB, GreyNoise, IPinfo, and IP2Location measured?
A: No published values are present. All four reserved columns are blank across every row, so they are excluded from the Dataset measurement list.
Q: Why are 501 IPv4 rows labeled by a DNSBL?
A: The combined field contains 494 Spamhaus ZEN labels and 7 DroneBL labels. Because raw DNS response codes are not published, the CSV cannot decompose ZEN into its individual components. A ZEN label is not a universal web-risk score.
Q: Does cf_threat_score zero mean Cloudflare trusted the route?
A: No. Cloudflare documents that the legacy cf.threat_score field is now always zero. It cannot distinguish these rows or represent an Enterprise Bot Management score.
Q: Does cf_client_bot false mean the request was human?
A: No. The field identifies known good bots or crawlers. False means that known-bot designation was not present; it does not prove a human or predict acceptance.
Q: Can the original capture be reproduced from the CSV alone?
A: No. The aggregates can be recalculated, but replaying the capture requires full addresses, timestamps, raw responses, resolver and software details, candidate records, and the harness.

### Headless Browser Detection Signals: Defensive Testing
URL: https://databay.com/blog/how-sites-detect-headless-browsers
Author: Databay Research Team. Published: 2026-05-06. Updated: 2026-07-20.

How sites combine browser, rendering, network, session, and behavior signals—and how to test them defensively without treating a fingerprint as identity.

#### Headless Detection Is a Multi-Signal Decision
A site cannot reliably identify every automated browser from one property. Modern systems combine signals from the browser runtime, rendered output, request metadata, TLS and HTTP behavior, navigation history, cookies, account state, rate, and interaction patterns. A defensive system can use the combined evidence to protect logins, checkout, inventory, forms, and APIs, but each signal has legitimate exceptions.
navigator.webdriver is an explicit automation indicator when present, yet its absence does not prove a human. A canvas or WebGL difference can reflect a virtual machine, accessibility configuration, privacy tool, remote desktop, driver update, or real hardware. A rare TLS fingerprint can belong to a legitimate application. Responsible detection therefore uses layered evidence, calibrated thresholds, monitoring, and a recovery path for false positives.

#### JavaScript and Runtime Signals
JavaScript can inspect browser-exposed properties such as navigator.webdriver, languages, plugins, permissions, screen values, user-agent data, WebGL parameters, fonts, media capabilities, and prototype descriptors. Automation frameworks can also leave differences in error stacks, object ownership, function serialization, Chrome-specific namespaces, or the timing of injected scripts.
No individual value is universally suspicious. Plugin counts vary by browser and version. Permission behavior differs across operating systems. Privacy-focused browsers deliberately reduce or alter entropy. Enterprise policies and extensions modify APIs. The useful signal is consistency: do the claimed browser, operating system, rendering engine, feature set, and observed behavior agree with each other?
Defenders should record which checks contributed to a decision and measure their false-positive rate against real users. Avoid rules that block solely because one API is missing or unusual.

#### Rendering, Graphics, and Environment Consistency
Canvas, WebGL, font metrics, emoji rendering, audio processing, CSS media queries, and screen geometry expose properties of the rendering environment. Headless or containerized sessions can produce combinations that are rare in ordinary traffic: a claimed desktop browser with no expected fonts, a GPU description inconsistent with the platform, fixed viewport values repeated across every session, or a timezone and locale that do not match the rest of the profile.
These are probabilistic signals, not identity proofs. Cloud desktops, browser isolation, thin clients, test labs, assistive technology, and hardened privacy configurations can look unusual for legitimate reasons. A diagnostic should report the inconsistency it observed rather than label the person behind it. Repeat tests across supported operating systems and accessibility configurations before enforcing a rule.

#### Automation APIs and Patch Side Effects
Playwright, Puppeteer, Selenium, and Chrome DevTools Protocol clients are legitimate tools for testing and administration. Their default configurations can expose automation state, while third-party patch libraries attempt to change selected browser properties. A patch can remove one obvious marker yet introduce a descriptor, prototype, timing, or cross-frame inconsistency of its own.
Because browsers and automation libraries release frequently, results tied to one browser binary become stale quickly. A defensible test records the exact framework version, browser build, operating-system build, launch flags, extensions, profile state, and dependency lockfile. It should include an unmodified browser control and rerun after browser upgrades. Avoid permanent claims such as “undetectable” or “always detected”; the observed result belongs to the recorded configuration and date.

#### Network, Session, and Behavioral Context
Browser JavaScript is only one layer. The destination can also observe TLS and HTTP characteristics, header order, protocol negotiation, connection reuse, IP network, cookie history, navigation sequence, request rate, and account behavior. A perfectly ordinary JavaScript environment does not erase contradictory network or session evidence, and an unusual browser signal does not automatically make a request abusive.
For account and transaction protection, sequence often matters more than a static fingerprint. Examples include a new session jumping directly to a sensitive action, many accounts sharing one identical client profile, impossible geographic transitions, or repeated failures at machine-like intervals. Use these signals to protect systems you operate, with documented retention, access controls, and appeal or step-up verification for legitimate users.

#### What CreepJS Can and Cannot Tell You
CreepJS is an open-source browser-fingerprinting and privacy research project. It inspects high-entropy APIs, prototype tampering, browser lies, resistance features, and inconsistencies. That makes it useful for studying what a browser exposes and whether a modification created detectable contradictions.
A CreepJS percentage is not the probability that Cloudflare, Akamai, DataDome, or a particular website will block a visit. It is not a human-versus-bot probability and does not measure account, rate, navigation, or server-side history. Different CreepJS commits, browser builds, hardware, and page state can change the output. Record the diagnostic commit and raw output, and describe it as a fingerprinting observation rather than a production acceptance rate.

#### Build a Reproducible Defensive Lab
Use systems and accounts you control. Define the question before running the test: which signal changed, which browser configuration caused it, and what legitimate users could share it? Pin the operating system, browser binary, framework, dependencies, extensions, flags, locale, timezone, display mode, and hardware or virtual-machine profile.
Run an ordinary supported browser as a control. Repeat every configuration enough times to distinguish stable attributes from random or session-dependent ones. Save raw diagnostic JSON, screenshots, console output, network metadata, UTC timestamps, failures, and the exact aggregation code. Use a versioned manifest with file hashes. If a diagnostic is external, record its commit or retrieval hash because the hosted page can change between runs.
Test false positives with supported accessibility tools, privacy settings, enterprise policies, remote desktops, and low-powered devices. A detector that recognizes a lab configuration but blocks many legitimate users is not a successful production control.

#### Interpret Results Without Overclaiming
Report observations at the level the test supports. “This property differed from the control in browser build X” is defensible. “This library is detectable everywhere” is not. Separate a fingerprint inconsistency from a destination decision, and separate a destination decision from proof of malicious intent.
Use counts and uncertainty rather than a single winner. State the number of repetitions, failures, environments, and dates. If several configurations share the same result, do not infer that the diagnostic used the same underlying signal. If a score is undocumented, avoid reverse-engineering a precise meaning from its display label alone.
For public research, publish the harness and sanitized outputs when doing so does not expose user data or weaken a live control. Otherwise describe the evidence boundary clearly and avoid numerical rankings that readers cannot inspect.

#### Responsible Use
Browser diagnostics are appropriate for QA, fraud prevention, account security, accessibility testing, privacy research, and monitoring systems you own or are authorized to assess. They should not be used to bypass a third party's access controls, conceal prohibited automation, or continue after a site has denied access.
If an authorized integration is blocked, use the provider's API, feed, allowlist, service account, test environment, or written support channel. On the defensive side, minimize collected data, document the purpose, retain it only as long as needed, and provide a lower-friction recovery path when legitimate users are challenged.

#### FAQ
Q: Does navigator.webdriver prove that a visitor is a bot?
A: It is an explicit automation signal when present, but one property should not determine intent or enforcement by itself. Combine it with consistent, documented evidence and measure false positives.
Q: Does a low fingerprinting score mean a browser is undetectable?
A: No. A public diagnostic covers only the signals it implements. A destination may use different client, network, account, rate, and behavioral evidence.
Q: Can CreepJS results be compared across dates?
A: Only when the diagnostic commit, browser build, operating system, hardware, configuration, and raw output are recorded. A hosted diagnostic or browser update can change the result.
Q: Why can a real browser look unusual?
A: Privacy settings, extensions, accessibility tools, enterprise policies, remote desktops, virtual machines, drivers, locale, and hardware can all produce uncommon combinations.
Q: What should a reproducible browser test publish?
A: Publish the versioned harness, dependency lockfile, browser and OS builds, launch configuration, raw outputs, timestamps, repetitions, failures, aggregation code, and a file-hash manifest.
Q: How should a site respond to uncertain automation signals?
A: Prefer rate limits, step-up verification, scoped challenges, monitoring, and appeal paths over irreversible blocking based on one ambiguous fingerprint.

### TLS Fingerprinting Through Proxies: JA3, JA4, Tunnels
URL: https://databay.com/blog/tls-fingerprinting-proxy-detection
Author: Databay Research Team. Published: 2026-05-06. Updated: 2026-07-20.

How JA3 and JA4 summarize TLS clients, when proxies preserve or replace a ClientHello, and how to test a path without treating a hash as identity.

#### What a TLS Client Fingerprint Represents
Before an HTTPS request is sent, the client and server negotiate TLS. The client's ClientHello advertises protocol capabilities such as supported cipher suites, extensions, groups, signature algorithms, and application protocols. Libraries and browsers build that message differently, so selected fields can be summarized into a fingerprint.
A fingerprint helps group similar handshakes. It is not proof of a person, device, browser authenticity, intent, or safety. Many clients can share one fingerprint, and one client can produce different values after an update or configuration change. Servers commonly combine TLS information with HTTP, IP, cookie, account, rate, and behavior signals.

#### Whether a Proxy Changes the Handshake Depends on Architecture
With an HTTP CONNECT tunnel or a pass-through SOCKS route, the client normally establishes TLS end to end with the destination through the tunnel. In that design, the destination observes the client's ClientHello; the proxy changes the network path and source address but does not terminate the TLS session.
A TLS-intercepting corporate gateway, debugging proxy, malware scanner, translating relay, or other terminating intermediary behaves differently. It accepts one TLS connection from the client and creates another toward the destination. The destination then fingerprints the intermediary's outbound TLS stack. A reverse proxy or CDN also terminates the visitor connection and may use a different upstream handshake to the origin.
Do not infer behavior from the word “proxy” alone. Inspect the certificate chain, product documentation, tunnel method, packet capture, and destination-side observation for the actual route.

#### JA3: Ordered ClientHello Fields With GREASE Removed
JA3 builds a string from the TLS version, ordered cipher suites, ordered extensions, elliptic curves or supported groups, and point formats, then hashes that string with MD5. The hash is a compact label; the unhashed field string is more useful when explaining why two clients differ.
Standard JA3 implementations explicitly ignore GREASE values. GREASE reserves placeholder values so implementations continue to tolerate new protocol options, as specified in RFC 8701. Removing those reserved values prevents their randomized selection from creating a different JA3 on each connection. If a reflector reports changing JA3 values solely because it retained GREASE, it is not applying the standard normalization described by the JA3 project.
JA3 can still vary because a client changes cipher or extension order, supported groups, TLS configuration, library version, or handshake path. MD5 is used as a compact fingerprint label here, not as a security proof.

#### JA4: More Structured TLS Grouping
JA4 reorganizes TLS client characteristics into a readable prefix and hashed components. Among its design choices, it sorts selected ClientHello extensions, reducing variation among modern browser handshakes and making partial comparisons possible. The broader JA4+ family defines separate methods for server responses, HTTP clients, certificates, SSH, TCP, and other protocols.
JA4 is not a unique identity and should not be treated as one. A value can be missing, shared, or changed by protocol, version, configuration, session resumption, or intermediary behavior. Record the raw handshake context and implementation version when using it for diagnostics. Also review the licensing terms for JA4+ components; JA4 itself and other family members do not all use identical licensing.

#### A Different Exit IP Does Not Automatically Change JA3 or JA4
When the same client opens pass-through tunnels through residential, mobile, or datacenter exits, the destination can observe different source networks while receiving the same client-generated TLS fields. In that specific architecture, changing the exit is an IP-origin change, not a TLS-client change.
The result must be measured rather than assumed. A gateway update, TLS termination, HTTP/3 conversion, upstream proxy, custom transport, or destination-side normalization can change what is observed. Likewise, a stable JA3 or JA4 does not mean the entire connection is identical: TCP behavior, HTTP/2 settings, headers, cookies, timing, and account context may still differ.

#### How Cloudflare Describes JA3, JA4, and Bot Scores
Cloudflare documents JA3 and JA4 as TLS-client identifiers available to Enterprise Bot Management customers. Its documentation notes that fingerprints can be missing, including for non-encrypted traffic, some Worker paths, skipped Bot Management processing, and session resumption. Cloudflare also combines fingerprints with additional signals rather than treating one hash as a verdict.
Cloudflare's Bot Score ranges from 1 to 99: lower values are more likely automated, while 30 through 99 are grouped as likely human. Granular scores require Enterprise Bot Management. They are available through Cloudflare rules, Workers, analytics, and logs for configured customers; they are not a universal public response header that any requester can read.
A known or unusual fingerprint can contribute to a decision, but public documentation does not support a universal claim that one JA3 or JA4 always produces a particular score or block.

#### Run an Authorized, Reproducible Path Test
Test a destination and network path you own or have permission to assess. Hold the client binary and configuration constant, then compare direct and proxied paths one variable at a time. Record the proxy protocol, whether TLS is pass-through or terminated, destination certificate, DNS path, exit network, TLS version, ALPN, raw ClientHello, JA3 field string, JA3 hash, JA4 value, UTC timestamp, and failures.
Use a packet capture at a point where collection is authorized and a destination-side reflector you control. Preserve raw artifacts, commands, dependency lockfiles, operating-system and binary versions, proxy settings, and a SHA-256 manifest. Repeat each path so random or session-specific behavior is not mistaken for a structural difference.
Do not publish credentials, private traffic, session tokens, or full third-party user addresses. If the gateway is managed by another organization, obtain permission before capturing or probing it.

#### Use Fingerprints as Evidence, Not Identity
For defenders, TLS fingerprints can help group traffic, investigate a sudden client change, or add context to rate, account, and behavior controls. Build rules from observed good and bad traffic on the system you operate, monitor false positives, and allow fingerprints to age as software updates.
For client developers, consistency matters: the claimed application, TLS behavior, HTTP protocol, headers, and runtime should reflect the software actually being used. If an authorized integration is rejected, use the destination's API, allowlist, service account, test environment, or support process rather than attempting to conceal the client.
Network origin and TLS behavior answer different questions. Choose a proxy because an authorized workload needs that route or location, not because a product promises that changing an IP will make an unrelated client indistinguishable from a browser.

#### FAQ
Q: Does a proxy change a TLS fingerprint?
A: Sometimes. A pass-through CONNECT or SOCKS tunnel normally preserves the client-generated handshake. A TLS-terminating or translating intermediary creates its own outbound handshake and can change the observed fingerprint.
Q: Does GREASE make standard JA3 change every connection?
A: No. The JA3 project explicitly removes GREASE values before constructing the fingerprint so randomized reserved values do not create a new JA3.
Q: What is the main difference between JA3 and JA4?
A: JA3 hashes ordered TLS fields into an MD5 label after removing GREASE. JA4 uses a structured format and sorts selected extensions to reduce modern-browser variation and support partial comparisons.
Q: Is a JA3 or JA4 value a unique device identity?
A: No. Many clients can share a value, one client can change after updates or configuration changes, and fingerprints may be missing or altered by intermediaries.
Q: Can any requester read a Cloudflare bot score in a response header?
A: No universal public bot-score header is documented. Granular scores are an Enterprise Bot Management feature exposed to configured customers through rules, Workers, analytics, and logs.
Q: How do I compare direct and proxied TLS correctly?
A: Use an authorized destination, hold the client constant, vary one path setting at a time, save raw handshakes and configuration, repeat runs, and record timestamps, versions, failures, and file hashes.

### Proxy Anonymity Levels: Elite vs Anonymous vs Transparent
URL: https://databay.com/blog/proxy-anonymity-levels-explained
Author: Databay Research Team. Published: 2026-04-12. Updated: 2026-07-19.

What common proxy anonymity labels measure, how header-based tests work, and why no label proves privacy, safety, authorization, or undetectability.

#### What the Labels Actually Measure
Free-proxy lists often use three labels: Elite, Anonymous, and Transparent. The labels usually describe what a particular HTTP header test observed. They are not a standardized security certification, and different checkers can examine different headers.
In the common taxonomy, an Elite result means the checker did not observe tested proxy-identifying or client-IP headers. An Anonymous result means it observed evidence of an intermediary but not the tested client IP. A Transparent result means a tested header exposed the client IP. These results do not describe TLS, DNS, browser leaks, logging, malware, destination authorization, or every way an intermediary can be inferred.

#### Headers Used by Common Tests
A checker may inspect Via, standardized in current HTTP semantics, plus Forwarded, X-Forwarded-For, X-Real-IP, and other non-standard fields. Via can document intermediaries; Forwarded can carry information about the client-facing side of a proxy. X-Forwarded-For is widely used but is not a trustworthy identity signal unless every intermediary in the chain is controlled and validated.
A public reflection service reports only the request that reached that service. Absence of a tested header does not prove that the path is direct, private, safe, or impossible to classify by other means.

#### Elite or High-Anonymity
An Elite classification normally means the specific test did not find a client-IP leak or a recognized proxy marker in the inspected HTTP fields. The destination still sees the exit address and can evaluate address ownership and history, TLS and HTTP behavior, cookies, browser data, account state, timing, and request patterns.
Read “Elite” as “no tested header leak observed at this time,” not “undetectable.” The result can change when the proxy, client, destination, or checker changes. It does not authorize collection or allow a user to ignore a block.

#### Anonymous
An Anonymous classification usually means the checker observed an intermediary marker but did not see the tested client IP. That may be appropriate for a managed corporate gateway, cache, or debugging proxy where declaring the intermediary is intentional.
The label is not a privacy guarantee. The operator can still see connection metadata and may be able to observe unencrypted traffic, while browsers or applications can expose information through channels the header check never examines.

#### Transparent
A Transparent classification means the test observed the client's address in a field such as Forwarded or X-Forwarded-For. That behavior can be intentional inside a trusted reverse-proxy or enterprise chain because downstream services need the original address for logging or policy.
For a user who expected IP masking, the result means that expectation was not met for the tested request. Do not route sensitive, authenticated, or high-stakes activity through an unknown public proxy, regardless of its label.

#### How to Verify a Proxy Safely
Use a reflection endpoint you control or a reputable diagnostic service and send only disposable, non-sensitive traffic. Compare the direct client address with the apparent source and inspect returned headers. Repeat because public exits and configurations change.
curl -x http://PROXY_IP:PORT https://httpbin.org/headers
A single response is evidence about that request, not a permanent property of the address. Record the timestamp, destination, protocol, client configuration, apparent source, and fields inspected. Never include passwords, session cookies, tokens, private data, or a production account in the test.

#### Choosing a Tier
For testing infrastructure you control, choose the header behavior the test needs. For regional QA, confirm the apparent network location independently and remember that locale, account, device, and personalization can still change the response. For authorized public-data work, prefer an API or licensed feed, minimize traffic, and stop on blocking or challenge responses.
For anonymity-critical, credential-bearing, payment, health, legal, or safety-sensitive activity, an unknown public proxy is the wrong control. Obtain threat-model-specific security advice and use infrastructure with documented ownership, security, retention, and accountability.

#### FAQ
Q: Does Elite mean a proxy is undetectable?
A: No. It usually means a particular checker did not observe the headers it treats as a client-IP leak or proxy marker. Network ownership, TLS and HTTP behavior, browser data, cookies, account history, rate, and timing remain available signals.
Q: Why would a proxy reveal a client IP?
A: A gateway may be configured for a trusted internal chain where forwarding the original address is intentional, or it may simply be misconfigured. A public user cannot infer intent from the result and should treat an unexpected leak as a failed control.
Q: Are paid proxies Elite by default?
A: Do not assume so. Provider labels and checker definitions differ. Test the exact product and client configuration, review the provider's security and logging documentation, and repeat the check over time.
Q: Can a destination learn my address through other channels?
A: Possibly. DNS resolution, WebRTC, IPv6 routing, browser behavior, prior account activity, and application configuration can expose or correlate information independently of proxy-added HTTP headers. The outcome depends on the complete client and network path.
Q: What is the difference between Anonymous and Elite for authorized collection?
A: It is primarily the tested header behavior. Neither tier changes a source's rules, expands the permitted request budget, or guarantees a response. Choose from the authorized technical requirement and stop on an access control.

### Free Proxy List Methodology and Coverage Limits
URL: https://databay.com/blog/free-proxy-list-methodology
Author: Databay Research Team. Published: 2026-04-02. Updated: 2026-07-30.

Definitions for the fields Databay publishes, the freshness and filtering rules in the website code, and limits on what those observations can prove.

#### What This Page Can Substantiate
The Databay website consumes proxy records produced by an upstream checking service and publishes recent rows in HTML and machine-readable formats. The website code filters required country fields and uses a six-hour freshness window, with a narrower primary window for preferred rows. It exposes the record's last-check timestamp rather than claiming that every address is tested at the exact moment a visitor loads the page.
The upstream checker's complete acquisition list, probe infrastructure, raw request logs, geographic probe distribution, and source code are not part of this website repository. Therefore this page does not claim an independently reproducible count of probes, candidate sources, scan rate, or internal retry behavior.

#### Published Record Fields
The public API can return IP address, port, country and ISO code, protocol, SSL state, anonymity label, Google-passed flag, latency, uptime, and last-checked timestamp. These values are observations supplied by the checker and selected by the website; they are not certifications.
Country is a geolocation estimate. Protocol and SSL fields describe the observed test. Anonymity is a header-judge classification. Google-passed describes a previous probe result. Latency and uptime depend on the checker's route, time, endpoint, and history. Last checked is the timestamp attached to that record.

#### Freshness and Availability
Databay describes the list as refreshed every 5 minutes. That is a rolling service target, not a guarantee that each visible address is rechecked exactly every 5 minutes. Use the per-record timestamp to judge a row, and expect addresses to disappear, change behavior, or fail between the recorded probe and your request.
A country page may have no current rows. Empty pages are labeled as availability pages and are not presented to search engines as live proxy datasets.

#### Downloads and API
The list is available as server-rendered HTML, JSON, CSV, and plain text. API filters can select fields such as protocol, country, SSL, anonymity, Google result, speed, limit, and page. The file routes and API are subject to current server limits and can return an empty or partial result.
All formats are views of the same application data at request time, but requests made at different times can have different hashes because the dataset changes. Consumers should store retrieval time, parameters, status, content type, and hash.

#### What Is Not Verified
Databay does not verify the identity, consent, security, logging, retention, intent, ownership, or legal status of each unknown public proxy operator. A working tunnel does not prove throughput, stability, safety, destination acceptance, or future behavior. A Google-passed result does not predict access to Google or another service from a different place or time.
The list does not test every destination, client, protocol feature, IPv6 path, browser leak, or threat scenario. Treat every endpoint as untrusted and unsuitable for credentials, sessions, personal data, private research, payments, or downloads.

#### How to Reproduce a Consumer-Side Check
Retrieve a record and then make one disposable request to a diagnostic endpoint you own or are authorized to use. Keep certificate validation enabled. Record the list retrieval time and hash, row timestamp, apparent source, destination, response status, elapsed time, and inspected headers.
Your result can differ from Databay's record because routing, endpoint behavior, address ownership, and proxy configuration change. Report the difference as a time- and route-specific observation, not proof that either measurement is universally correct.

#### FAQ
Q: Is every row exactly five minutes old or newer?
A: No. The refresh phrase describes a rolling service target. Use each row's last-checked timestamp; website selection permits a wider freshness window and live state can change immediately.
Q: Does Google-passed guarantee Google access?
A: No. It records an upstream probe result for a particular route and time. Destination policy and proxy state can change, and your client and region can receive a different response.
Q: Does Databay verify public proxy operators?
A: No. Operator identity, consent, security, logging, retention, and intent are not established by the published checks.
Q: Why can my result differ?
A: The address, route, destination, client, and time differ, and public endpoints are volatile. Preserve all of those variables when comparing observations.
Q: Is the list safe for production?
A: No safety or reliability guarantee exists. Use accountable infrastructure for production, credentials, personal data, or any workflow where failure or tampering matters.

### Are Proxies Legal? A Risk-Based Compliance Guide
URL: https://databay.com/blog/are-proxies-legal-compliance-guide
Author: Databay Research Team. Published: 2026-03-11. Updated: 2026-07-30.

Proxy software is not a blanket permission or prohibition. This source-linked guide explains why legality depends on authorization, data, and jurisdiction.

#### Scope: There Is No Universal Yes-or-No Answer
A proxy is a networking intermediary; what it changes at the connection level is a route, never a permission. Its use can be routine, restricted, contractually prohibited, or unlawful depending on the facts. Relevant questions include who owns the target, whether access is authorized, whether a login or technical control is crossed, what data is collected, how much load is imposed, which contracts apply, where people and systems are located, and how the data is used afterward.
This article is general technical and compliance information, not legal advice. It does not claim attorney review or provide a safe harbor. Laws and platform terms change; obtain advice from qualified counsel for the actual jurisdictions and workflow.

#### United States: What Van Buren Did and Did Not Decide
The US Computer Fraud and Abuse Act, 18 U.S.C. § 1030, addresses access without authorization and exceeding authorized access. In Van Buren v. United States (2021), the Supreme Court interpreted “exceeds authorized access” in a case involving a person who had access to a law-enforcement database but used it for an improper purpose. The decision rejected one broad, purpose-based reading of that phrase.
Van Buren did not decide that all access to public websites is lawful, that terms never matter, or that automated collection cannot trigger other federal or state claims. “Without authorization,” contract, copyright, privacy, trespass, unfair-competition, and state-law questions can remain. Do not turn this database-access holding into a universal web-scraping rule.

#### hiQ v. LinkedIn Is Important but Fact-Specific
In hiQ Labs v. LinkedIn (9th Cir. 2022), the Ninth Circuit considered a preliminary injunction and the CFAA “without authorization” language in the context of publicly visible LinkedIn profiles. The court concluded that hiQ had raised serious questions and that public website areas differ from private systems where permission is required.
The opinion is from the Ninth Circuit, arose at a preliminary stage, and does not create a worldwide or fact-free right to scrape. It does not erase contract, copyright, privacy, state-law, or later-use risks. A cease-and-desist letter or technical block is a reason to stop and obtain counsel, not a cue to rotate IPs around the control.

#### Terms, Authentication, and Technical Controls
Read the source's current terms, API conditions, robots controls, and published rate guidance before collection. Contract formation and remedies depend on notice, assent, parties, and jurisdiction, so neither “terms are always criminal” nor “terms are only civil and harmless” is reliable advice.
Do not bypass authentication, paywalls, membership checks, CAPTCHAs, IP blocks, or other access controls. Use an official API, feed, licensed source, or written permission. A proxy changes network origin; it does not grant authorization.

#### Ticket Purchasing and the US BOTS Act
The Federal Trade Commission's BOTS Act page links the statute and enforcement materials. The Act addresses specified circumvention of a ticket issuer's security measures, access-control systems, or ticket-purchasing rules used to enforce posted limits, along with certain sale of tickets obtained in violation. The FTC's April 2025 compliance refresher explains why businesses must assess acquisition and resale practices.
Do not use a proxy or automation to evade a ticket queue, verification step, security measure, or purchase limit. Platform terms, state laws, and other obligations can apply independently. A venue or issuer conducting authorized QA should use written scope, sandbox or non-transactional flows, explicit request budgets, and stop conditions rather than testing a live sale.

#### EU and UK Data Protection: Public Data Can Still Be Personal Data
The General Data Protection Regulation requires a lawful basis and applies other duties when personal data falls within its scope. Public visibility does not by itself remove those duties. Article 6 lists several possible lawful bases; legitimate interests under Article 6(1)(f) is not automatic and requires necessity and balancing against people's rights and interests.
Depending on the facts, a controller may also need transparency, purpose limitation, minimization, retention controls, security, data-subject rights processes, international-transfer safeguards, and a data protection impact assessment. UK and EU regimes and regulator positions can diverge. Do not assume that a product price and a public profile create the same risk, or that every B2B collection passes a legitimate-interest test.

#### Copyright, Database Rights, and Republication
Facts may receive different copyright treatment from original expression, but that distinction does not automatically authorize copying, extraction, or republication. Product descriptions, photographs, articles, reviews, and a database's selection or arrangement may be protected; EU database rights can add a separate analysis. Trademarks, passing off, and consumer confusion may also matter.
Collect the minimum permitted fields, preserve source and timestamp, avoid republishing protected expression, and obtain a specific license or legal analysis when the business model depends on reproducing or substituting for the source. Internal use is not an automatic copyright defense.

#### Robots.txt Is a Technical Standard, Not a Complete Legal Test
The Robots Exclusion Protocol is standardized in RFC 9309. It communicates crawler preferences, but it does not itself decide every question of authorization, contract, privacy, or copyright. Likewise, an allowed robots rule does not guarantee that collection is lawful or within terms.
Respect robots controls by default, alongside source terms and rate guidance. If a planned exception is genuinely necessary, obtain documented source permission or legal approval before traffic starts.

#### Residential Proxy Sourcing Is a Separate Due-Diligence Issue
Proxy type does not determine whether a downstream action is lawful, but residential and mobile networks create sourcing, consent, privacy, security, and supply-chain questions. Ask a provider how participants are informed, what they consent to, how consent is withdrawn, what traffic is prohibited, how abuse is investigated, and what independent evidence supports those answers.
Databay states on its Trust page that its residential supply uses opt-in participants. That is a first-party representation, not an independent legal conclusion in this article. Customers evaluating residential, datacenter, or mobile networks should request the documentation their own risk program requires and should not assume that using a named provider removes downstream responsibility.

#### A Practical Pre-Collection Review
This review is the working artifact of this guide: twelve items, each with the evidence to record before launch and the condition that routes the design to qualified counsel instead of production. Fill it in writing, keep it with the project, and treat an unanswered row as a blocker rather than a footnote.
Pre-collection review: document each row before any traffic startsItemDocument before launchEscalate to counsel when
Source and ownershipThe target, its operator, and a named internal business owner for the collectionThe operator has challenged access in any form: letter, block, or notice
Official alternativesAPI, feed, export, or license options and why they do or do not fit the jobAn official route exists but its conditions would be avoided rather than met
Scope of collectionExact URLs, fields, and volumes; the documented minimum, nothing moreThe scope includes protected expression you intend to reuse or republish
Access boundaryWhich areas are public and which sit behind accounts or technical controlsAny authentication, paywall, CAPTCHA, or block stands between you and the data
Terms and robotsThe current terms, API conditions, and robots rules, with the date reviewedThe terms are ambiguous about automated access for your purpose
AuthorizationWritten permission where relied on, including its scope and expiryPermission is verbal, implied, or granted by someone who may lack authority
JurisdictionsCountries of the actor, infrastructure, target, and data subjects, and the laws engagedThe project spans jurisdictions the team has not previously assessed
Data classificationWhether personal, sensitive, or regulated-sector data is in scopePersonal or sensitive data is involved, or the target operates in a regulated sector
Load and rateRequest budget, concurrency ceiling, and automatic stop conditionsThe collection is large enough to affect the service
IdentificationHow requests identify their operator and how the source can make contactNobody can state, in writing, who is making the requests
Security and retentionStorage protection, retention period, and the deletion pathRetention or reuse would exceed the documented purpose
Downstream useEvery recipient of the data and their permitted useThe business model depends on republishing or substituting for the source

Re-run the review whenever the source, method, data, law, or purpose changes. The table is a living record kept with the project, not a one-time signature, and it does not replace counsel for the situations in its right-hand column.

#### Bottom Line
Do not ask only whether proxies are legal. Ask whether this actor is authorized to make these requests, to this source, for this purpose, at this rate, in these jurisdictions, collecting and using these fields. Prefer official APIs and licenses, honor controls, minimize data and load, preserve provenance, and document uncertainty. No proxy provider or court citation can replace that fact-specific review.

#### FAQ
Q: Is it legal to use a proxy server?
A: There is no universal answer for every country and use. Proxy software is ordinary networking infrastructure, but a particular use can violate access laws, contracts, privacy, copyright, or other rules. Review the exact workflow and jurisdiction.
Q: Can I be sued for web scraping with proxies?
A: Yes, litigation and other claims are possible. Risk depends on authorization, terms, technical controls, server impact, data type, copyright or database rights, privacy, competition, jurisdiction, and reuse. Public visibility alone is not a safe harbor.
Q: Does Van Buren make Terms of Service irrelevant?
A: No. Van Buren interpreted part of the CFAA in a database-access case. It did not eliminate contract claims or decide every question of automated web access, authorization, state law, copyright, or privacy.
Q: Does GDPR apply to public personal data?
A: It can. Public availability does not by itself remove GDPR obligations. A controller needs an applicable lawful basis and may have transparency, minimization, rights, security, transfer, and impact-assessment duties.
Q: Are residential proxies automatically lawful to use?
A: No blanket conclusion is possible. Review how the network is sourced and consented, and separately assess what the customer will access, collect, and do with the data. Provider due diligence does not replace use-case review.
Q: Can a proxy or bot be used to bypass ticket-purchase limits?
A: Do not use a proxy or automation to evade a queue, security measure, verification step, or posted purchase limit. The US BOTS Act covers specified ticket-control circumvention and related resale conduct, while platform terms and other federal or state laws may impose additional constraints.

### Proxies for Authorized Social Media Management
URL: https://databay.com/blog/social-media-management-proxies
Author: Databay Research Team. Published: 2026-02-20. Updated: 2026-07-20.

A security- and compliance-first guide to stable network access, official platform tools, client separation, and regional public-content QA.

#### Use Official Account and API Workflows First
Use platform business managers, delegated roles, approved schedulers, and official APIs for publishing, moderation, analytics, messaging, and advertising. They provide documented permissions and audit trails. A proxy is not a substitute for platform authorization and cannot make fake accounts, spam, manufactured engagement, or prohibited automation acceptable.

#### Written Client Authorization and Access Governance
Keep written authority for every client account, define staff roles, require multifactor authentication, store credentials in a password manager, log access, and revoke access promptly when staff or contracts change. Account ownership and recovery contacts should remain with the client. Do not conceal who is operating an account.

#### When a Stable Proxy May Be Relevant
A remote agency may need a consistent egress region for an account it is authorized to manage. A static or sticky proxy can keep that network signal stable during an approved session. It does not guarantee fewer security prompts, and platforms can evaluate device, authentication, account history, and behavior. Stop rather than rotate around a security challenge.

#### Keep Client Sessions Isolated
Use separate company-managed browser or device profiles to prevent credentials, cookies, storage, and drafts from crossing between clients. Apply accurate locale and timezone settings for operational consistency, not to impersonate a person. Anti-detect fingerprint spoofing and fabricated device identities create compliance and security risk.

#### Regional Public-Content and Campaign QA
A country-targeted proxy can add one regional network sample for public campaign, localization, or brand-listening QA when the platform permits the method. It does not reproduce a local person's feed because account, language, device, consent, experiments, and personalization also matter. Preserve the test state and use official previews and platform reports as primary evidence.

#### Public Data Collection Boundaries
Prefer official APIs and licensed providers. If permitted public pages are collected directly, honor terms, robots controls, and source-level rate limits, cache unchanged responses, and stop on blocking or challenges. Do not collect login-gated or private data, and do not distribute traffic across IPs to evade a platform limit.

#### Choose Residential or Mobile by Network Requirement
Residential and mobile proxies provide ISP and carrier network origins with different cost and availability. Neither has a universal trust score or guaranteed platform outcome. Use mobile only when a carrier-network variable is required; otherwise compare the authorized workflow empirically and choose the simpler, lower-risk architecture.

#### Run a Controlled Pilot and Budget From Evidence
Before comparing residential and mobile routes, define the authorized accounts, official-tool baseline, countries, session duration, bandwidth, support events, observation window, and stop conditions. Test a small, low-risk sample while holding other inputs constant, and stop on any security challenge. Report raw counts and uncertainty rather than attributing a multi-factor platform outcome to the IP type alone.
Estimate cost from measured traffic, current published pricing, minimum orders, plan validity, support, and engineering time. Do not infer bandwidth from account count or claim that a network route prevents account loss. Validate live country and carrier availability, session behavior, sourcing and consent, privacy terms, abuse controls, support, and refund conditions before purchasing volume.

#### Operational Checklist
Before launch, document account owners, authorization, official tool support, staff roles, MFA, session separation, network region, publishing permissions, source limits, incident handling, logs, retention, and offboarding. Databay's Acceptable Use Policy prohibits spam, deceptive engagement, fake accounts, and unauthorized access.

#### FAQ
Q: Do social media managers need proxies?
A: Not necessarily. Official platform account tools and APIs should come first. A proxy is relevant only when an authorized team has a documented stable-network or regional-QA requirement.
Q: Should each account have a dedicated IP?
A: There is no universal platform-approved rule. Separate authorized clients for security and auditability, and choose a stable network design based on real operational needs rather than detection avoidance.
Q: Are mobile proxies safer for social media?
A: No safety guarantee or universal trust score exists. A mobile proxy provides a carrier-network origin; platform rules, authorization, account security, and behavior still govern risk.
Q: Can proxies verify regional social content?
A: They can vary the network-location signal for an approved public-content test. Results can still depend on account, device, language, consent, experiments, and personalization.
Q: Do anti-detect browsers improve authorized management?
A: Do not use them to spoof people or bypass controls. Use managed browser or device profiles for legitimate client separation, with accurate settings, MFA, access controls, and audit logs.
Q: How should an agency compare residential and mobile routes?
A: Use a small authorized pilot with the same accounts, observation window, workload, and stop conditions. Measure availability, latency, traffic, support events, and cost; do not treat account actions as proof that one IP class is universally safer.

### Are Free Proxies Safe? A Practical Threat Model
URL: https://databay.com/blog/are-free-proxies-safe
Author: Databay Research Team. Published: 2026-02-18. Updated: 2026-07-30.

Unknown public proxies have no dependable identity, security, retention, or availability commitment. Learn what HTTPS protects and when not to use one.

#### The Short Answer
Treat every unknown public proxy as untrusted infrastructure. You generally cannot verify who operates it, whether the machine owner consented, how it is configured, what it logs, whether another party controls it, or how long it will remain available. A successful test proves only that one request was relayed at that time.
Do not use a free public proxy for logins, session cookies, payments, personal or regulated data, work systems, software downloads, private research, or any activity where confidentiality, integrity, attribution, or reliable availability matters.

#### What an Operator Can Observe or Change
For plain HTTP, an intermediary can read and modify request and response content. That includes headers, cookies sent without appropriate protection, form data, scripts, and downloads. For HTTPS carried through a valid CONNECT tunnel, TLS normally protects application content from a passive intermediary, provided the client validates the destination certificate and no trusted interception certificate is installed.
HTTPS is not a complete safety guarantee. The proxy still handles connection metadata, can deny or redirect connections, may learn destination information from DNS or TLS metadata, and can log timing and volume. A compromised client, malicious browser configuration, certificate-warning override, local DNS leak, or hostile destination changes the threat model.

#### Labels Do Not Establish Trust
“Elite,” “anonymous,” and “transparent” usually describe a limited header-reflection test. They do not certify ownership, consent, logging, malware status, TLS safety, DNS behavior, legal authorization, or future configuration. Likewise, a country label is a geolocation estimate, not proof of physical location.
Public lists also change quickly. Addresses are reassigned, ports close, software is reconfigured, and a previously working endpoint can be replaced. Recheck immediately before a disposable diagnostic use and preserve the timestamp and test method.

#### Lower-Risk Diagnostic Uses
A free proxy can be useful for a small, disposable test against a system you own or are expressly authorized to assess—for example, checking whether your public page is reachable from another apparent network origin. Send no credentials, identifiers, private content, or valuable cookies. Use a separate, updated client; validate certificates; keep the request count low; and assume the result may be incomplete or wrong.
That is “lower risk,” not “safe.” Free proxies are unsuitable whenever an incorrect result, leaked metadata, modified response, or failed request could harm a person or business.

#### Do Not Rotate to Hide Activity
Changing public proxies can expose the same workflow to more unknown operators and does not prevent browser, account, timing, or behavioral correlation. It must not be used to bypass a destination's quota, block, CAPTCHA, licensing rule, authentication boundary, or purchase limit.
For authorized automation, apply one source-level request budget across every address, cache unchanged responses, identify traffic when required, back off on errors, and stop on an access control. Prefer an official API, bulk download, licensed feed, or written permission.

#### When to Use Accountable Infrastructure
Use a provider or infrastructure arrangement with verifiable ownership, security contacts, acceptable-use enforcement, retention terms, data-processing commitments, sourcing and consent documentation, service limits, and incident handling when the work has business value. Validate those commitments; a paid label alone does not prove them.
For high-stakes anonymity or personal safety, obtain advice based on the actual threat model. A generic web proxy—free or paid—is not a substitute for an audited security design.

#### FAQ
Q: Can a free proxy read my password?
A: It can read plain-HTTP content. With correctly validated HTTPS through a tunnel, application content is normally encrypted between client and destination, but configuration errors, certificate-warning overrides, malicious software, metadata logging, and other leaks remain. Do not send credentials through an unknown public proxy.
Q: Does HTTPS make a free proxy safe?
A: No. HTTPS protects application content under specific conditions; it does not establish the proxy operator's identity, prevent metadata logging or denial, guarantee correct DNS and client behavior, or make the service reliable.
Q: Is an Elite proxy trustworthy?
A: No. Elite normally means that one header test did not observe a tested leak or proxy marker. It is not a security, ownership, consent, retention, or availability certification.
Q: Is using a free proxy legal?
A: Legality depends on authorization, source rules, technical controls, data, purpose, contracts, and jurisdiction. A proxy does not grant permission. This is general information, not legal advice; obtain qualified advice for the actual workflow.
Q: What should I use for sensitive work?
A: Use accountable infrastructure selected through a documented security and privacy review. For anonymity or safety-critical work, obtain threat-model-specific guidance rather than relying on a public proxy list.

### Static vs. Rotating Proxies: Session Design & Cost Lab
URL: https://databay.com/blog/static-vs-rotating-proxies
Author: Databay Research Team. Published: 2026-02-18. Updated: 2026-08-04.

Choose a static, sticky, or rotating proxy from the state your authorized workflow must preserve. Model continuity, retries, and cost before you buy.

#### The Short Answer: Persist Only What the Job Requires
Use a static proxy when a system you control needs a known source IP for an allowlist, audit trail, or long-lived connection. Use a sticky session when several permitted requests must keep one exit for a short workflow. Use rotation when requests are independent and the source permits distributed regional sampling.
The choice is not a contest between "stable" and "anonymous." It is a state-design decision. Rotation does not create permission, increase a quota, erase cookies, or guarantee a unique exit. Static does not automatically mean dedicated, trusted, fast, or permanently available.
Fast session-mode decisionUser requirementStart withState that must persistReject the design when
Approved endpoint allowlists one sourceStatic addressSource IP and audit identityFailover can silently replace the IP or allocation is unclear
Short public flow needs temporary continuitySticky sessionClient cookies plus one exit mappingThe flow exceeds the supported window or crosses a restricted boundary
Each permitted observation stands aloneRotating poolOnly the source-wide budget and task recordThe plan depends on rotating around a block, challenge, or quota
Official API, feed, export, or preview existsOfficial method firstDocumented API credentials and quotasA proxy would duplicate a supported, safer access path

#### Separate Persistence, Allocation, Network Origin, and Protocol
Several proxy properties are often compressed into one marketing label. Treat them as separate axes:
Static versus rotating describes whether the exit address is expected to remain stable or can be reassigned.
Sticky describes a time- or session-bound mapping inside a rotating pool.
Dedicated versus shared describes allocation: one customer or multiple customers can use the resource.
Residential, mobile, ISP, and datacenter describe the network source and operational model, not session duration.
HTTP and SOCKS5 describe the client-to-proxy protocol, not whether the exit rotates.

A static address can be shared. A dedicated address can be replaced after failure. A sticky residential exit remains part of a rotating pool even while the mapping holds. An HTTP or SOCKS5 gateway can expose either a static address or pool logic behind the same endpoint.
Properties to record separately in a production designPropertyExample valuesWhy it changes the design
Exit persistencePer request, per connection, 15-minute sticky, static until replacementDetermines whether consecutive requests should observe one source
AllocationShared, dedicated, exclusive port, unspecifiedAffects contention, reputation variance, and ownership assumptions
Network originDatacenter, ISP, residential, mobileAffects supply, route, latency, pricing, and consent questions
Client protocolHTTP forward, HTTP CONNECT, SOCKS5Affects client support, DNS choice, authentication, and transport capability
Billing unitGB, IP-month, port, request, committed tierDetermines the correct cost formula

For the protocol decision itself, use the HTTP-versus-SOCKS5 wire-level guide. Session mode and proxy protocol are adjacent choices, not substitutes. For a provider-managed allocation example, review how Databay's shared datacenter proxy pool is billed and how it differs from a dedicated static address.

#### A Proxy Session Does Not Own Your Application State
A sticky proxy session usually maps a provider-specific session identifier to an exit address. It does not store a browser's cookies, an API token, a shopping cart, a database transaction, or the destination's account state.
The HTTP cookie standard, RFC 6265, describes an origin sending Set-Cookie and a user agent returning matching cookies later. That state belongs to the user agent and origin interaction. Changing the exit does not clear it; keeping the exit does not preserve it if the client discards the cookie jar.
State ownership in a proxy-assisted requestStateTypical ownerWhat a proxy-mode change does
Cookies and browser storageBrowser or HTTP clientNormally nothing; the client still sends state according to its rules
Authorization tokenClient and destinationDoes not revoke, refresh, or authorize the token
Sticky session identifierClient configuration and proxy gatewaySelects a mapping according to provider policy
Source-IP allowlistDestination ownerA changed exit can break access even when client credentials remain valid
Quota or rate counterDestination or intermediaryMay use account, cookie, IP, resource, or several signals; rotation does not reset permission

Design rule: carry application state explicitly in the approved client, and treat the exit address as one network input. Never rely on IP rotation to impersonate separate users or evade a destination control.

#### How Rotation Actually Appears in a Request Sequence
A rotating gateway chooses an exit according to its pool, targeting, health, allocation, connection, and session rules. "Per-request rotation" is therefore an instruction or service behavior, not proof that every response came from a unique address. This one-address-many-exits packaging is what providers sell as backconnect; the backconnect gateway guide demonstrates per-request rotation and credential-pinned sticky sessions on a loopback pool you can run yourself.
Persistent HTTP connections can carry more than one request. RFC 9112 defines HTTP/1.1 connection persistence, while HTTP/2 and HTTP/3 can multiplex requests. A provider might bind selection to a connection, a gateway request, a session credential, or another implementation boundary. If uniqueness or continuity matters, verify the observed exit and timestamps; do not infer them from the product name.
What to log for each controlled test requestFieldPurposePrivacy boundary
Logical task IDGroups requests that are allowed to share stateUse a random internal ID, not a customer name or credential
Proxy session ID hashConfirms which configuration requested continuityNever log the raw username, password, or complete proxy URL
Observed exit IP and ASNTests persistence and network classificationRestrict retention and access; an IP can be personal data in some contexts
Connection-reuse flagSeparates gateway selection from a reused transportRecord a boolean or connection ID, not packet contents
Status and failure phaseDistinguishes proxy auth, connect, TLS, destination, and timeout failuresDo not capture response bodies containing private data

Use the proxy checker for a point-in-time liveness and exit observation, then reproduce the result in the exact client that will run the workload.

#### Three Safe Production Patterns
Pattern 1: independent regional observations. Give each permitted public observation its own task ID. Enforce one request budget across the entire pool, preserve the destination's published rate limits, and store the observed region and exit with the result. Rotation is useful for sampling; it is not a reason to increase volume.
Pattern 2: short stateful quality-assurance flow. Keep one client cookie jar and one sticky session identifier for the approved steps. Set the proxy window slightly longer than the measured p95 flow time, but shorter than the provider maximum and operational need. Databay supports sticky residential sessions for up to 120 minutes. If the flow can exceed the window, split it only at a valid application boundary or choose an approved static source.
Pattern 3: allowlisted service you control. Use a static address, verify whether it is dedicated, and document replacement and failover. Test the primary and any preapproved secondary address before deployment. Monitor the public exit separately from the gateway hostname so a replacement cannot silently break the allowlist.
State and stop conditions by patternPatternKeep stableMeasureStop condition
Independent samplingSource-wide budget and test definitionCoverage, success rate, exit distribution, duplicate results403, 429 without an approved wait, challenge, or unclear source permission
Short stateful QAClient state, session token, region, approved account contextFlow duration, session expiry, exit changes, step failuresAuthentication boundary, challenge, account restriction, or session expiry mid-step
Allowlisted serviceSource address, destination policy, client identityExit drift, connect/TLS latency, replacement eventsUnapproved failover address or unexplained route change

#### Retry the Failure You Understand, Not the Identity
A retry policy belongs to the logical task, not to each exit. Otherwise a rotating pool can multiply a small retry count into an uncontrolled request burst.
RFC 9110 defines safe methods and warns that a proxy must not automatically retry non-idempotent requests. RFC 6585 defines 429 Too Many Requests and allows a Retry-After field; the 429 error guide covers how to read and honor it. The source can count by resource, server, credentials, cookie, or other criteria, so a new exit is not evidence that the limit no longer applies.
Bounded retry policySignalActionExit behavior
Proxy 407Stop and fix proxy credentials or account policyDo not rotate; another exit cannot repair gateway authentication
Connect failure before any destination responseFor a replay-safe task, retry at most the documented limit with backoff and jitterUse the configured session policy; record whether the exit changed
502, 503, or 504Classify the failing hop, honor Retry-After when supplied, then use a small capped retry budgetDo not assume rotation is the remedy
429Honor Retry-After and the source-wide quota; stop if no approved retry window existsNever rotate to bypass the limit
401, 403, challenge, or account restrictionStop and review authorization, official access paths, and destination support guidanceNever change exits to continue
Unsafe or non-idempotent request with an ambiguous outcomeDo not automatically replay; reconcile application state firstKeep the incident auditable

// Policy outline for understood, replay-safe work only
const delayMs = Math.min(capMs, baseMs * 2 ** attempt) + randomJitterMs;

if (response.status === 429 && response.headers.has("retry-after")) {
waitUntilApproved(response.headers.get("retry-after"));
} else if ([502, 503, 504].includes(response.status) && attempt < maxAttempts) {
await sleep(delayMs);
} else {
stopAndClassify(response.status);
}
If the intermediary emits Proxy-Status, RFC 9209 defines structured error details such as DNS, connection, and timeout failures. Treat that field as diagnostic evidence, not as a guarantee that every intermediary reports it.

#### Compare Cost With the Same Monthly Workload
Static and rotating services often use different billing units. Comparing a per-IP sticker price with a per-GB price without estimating workload produces a meaningless winner.
The calculator above uses decimal gigabytes: traffic GB = monthly requests × average round-trip KB ÷ 1,000,000. The rotating estimate is traffic GB × quoted $/GB. The static address estimate is IP count × quoted $/IP/month. When both rates are present, the simple break-even volume is static address cost ÷ rotating $/GB.
That is only a normalization step. Add uploads, headers, failed responses, bounded retries, plan minimums, targeting fees, traffic included with static addresses, overage, concurrency limits, commitment term, taxes, replacement policy, and support. A cheaper line item can be the wrong design if it cannot preserve the required state or introduces unaudited failover.
Cost worksheet beyond the calculatorInputHow to obtain itCommon omission
Monthly request countProduction forecast plus a separately bounded retry allowanceMultiplying retries independently for every exit
Round-trip bytesMeasure request headers/body and response headers/body on representative trafficCounting only downloaded payload
Required address countAllowlist and approved redundancy designAdding addresses to evade source controls
Usable success rateControlled pilot using the real client and destination you own or may testComparing latency only among successes
Operational costMonitoring, replacement, support, incident handlingTreating pool management as free

Verify current product terms on the residential pricing page; the calculator intentionally does not embed a competitor price or pretend that one billing model covers every plan.

#### Validate the Session Design Before Production
Run the smallest controlled test that can falsify the design. Use a destination you own or have explicit permission to test, and keep credentials outside source code and logs.
Pin the client and proxy configuration. Record library, browser, or cURL version; proxy protocol; gateway; targeting; session mode; timeout; and connection-reuse policy.
Measure the direct baseline. For an authorized destination, record DNS, connect, TLS, first-byte, total time, status, and response identity without the proxy.
Run six requests in the intended pattern. Log a redacted task ID, timestamps, observed exit, country estimate, ASN, status, and failure phase.
Test the boundary deliberately. For sticky mode, wait past the configured window using a non-sensitive endpoint. For static mode, use the provider's documented replacement test or support process; do not force an outage.
Test one safe transient retry. Use a controlled synthetic 503 or connection failure. Confirm the total task retry budget, delay, and exit behavior.
Test every stop condition. A synthetic 403, 429, or challenge must halt the workflow rather than trigger rotation.
Reconcile cost from measured bytes. Replace estimates in the lab with the pilot's complete round-trip volume and quoted plan terms.

Evidence boundary: a six-request lab can verify one client, configuration, time window, and endpoint. It cannot prove future pool availability, destination acceptance, legal compliance, operator logging, or a universal performance advantage.

#### Questions to Ask Before Buying or Deploying
Request written answers when session continuity is operationally important:
Does rotation occur per request, per new connection, on time expiry, on failure, or through a session token?
Is the exit shared or dedicated, and is the gateway itself static even when exits rotate?
What is the minimum, default, and maximum sticky duration? Does activity extend it?
What happens when an exit disappears during a sticky session?
Can static failover change the address? How is replacement announced and audited?
Are bandwidth, uploads, failed responses, and retries billed?
Which locations and network classifications are actually available for this plan?
What logs are retained, for how long, and who can access them?
Which uses are prohibited by the provider and the destination?
Which error fields or support traces distinguish gateway, DNS, connect, TLS, and upstream failures?

Avoid vendors that promise "undetectable" traffic, guaranteed access, unlimited rotation around controls, or certainty about how a destination will classify an address. Those claims collapse network routing, reputation, client behavior, account state, and destination policy into something a proxy cannot guarantee.

#### Continue From the Question You Actually Have
Use the next resource that matches the unresolved part of the design:
Deliberate next stepsIf you still need to know...Next resourceWhy
Which connections a proxy changesTrace a proxy request pathSeparates client, proxy, DNS, destination, and reverse-proxy roles
How to configure the real clientChoose a tested integration guideClient behavior determines credentials, DNS, pooling, and errors
Whether one endpoint is alive and what exit it presentsRun the proxy checkerProduces a point-in-time liveness, latency, protocol, and exit observation
Which managed network fits the approved workloadCompare proxy network typesReviews residential, mobile, datacenter, and flexible options after the state requirement is known

After deployment, verify the application path independently with What Is My IP and client logs. A product setting is an intention; the observed route is the evidence.

#### FAQ
Q: What is the main difference between static and rotating proxies?
A: A static proxy is expected to keep one exit address until replacement, while a rotating service can select exits from a pool per request, connection, time window, or session rule. The exact boundary is provider-specific, so verify the observed exit in your real client.
Q: Is a sticky proxy the same as a static proxy?
A: No. A sticky session temporarily maps a session identifier to an exit in a rotating pool. A static service is intended to keep an address for a longer allocation period. Neither term proves that the address is dedicated.
Q: Does changing a proxy IP clear cookies or login state?
A: No. Cookies and authorization state normally remain in the browser or HTTP client and at the destination. Changing the network exit does not clear them, and keeping one exit does not preserve them if the client discards its state.
Q: Should a rotating proxy retry after a 403 or 429?
A: Do not rotate around either response. A 403, challenge, or account restriction is a stop condition. For 429, honor Retry-After and the source-wide quota; the destination may count by credentials, cookies, resource, IP, or several signals.
Q: Are static proxies always dedicated or faster?
A: No. Static describes persistence, not allocation or performance. A static address can be shared, and speed depends on the network, route, proxy implementation, destination, client, connection reuse, and workload.
Q: How do I compare per-GB and per-IP pricing?
A: Estimate complete monthly traffic from request count and round-trip bytes, multiply it by the quoted per-GB rate, and compare it with the required address count times the per-IP monthly rate. Then add minimums, included bandwidth, overage, targeting, commitments, failures, and operational cost.

### How to Test a Free Proxy Safely
URL: https://databay.com/blog/how-to-use-a-free-proxy
Author: Databay Research Team. Published: 2026-02-03. Updated: 2026-07-19.

Use unknown public proxies only for disposable, non-sensitive diagnostics against systems you are authorized to test. Never disable certificate validation or rotate around a refusal.

#### Threat Model Before Setup
An unknown public proxy has no dependable operator identity, consent, integrity, logging, retention, or availability commitment. Do not send credentials, cookies, tokens, personal data, private URLs, payment details, work traffic, or software downloads through it.
Limit use to a disposable diagnostic against a system you own or are expressly authorized to assess. Use an updated, isolated client and assume the response and location label may be wrong.

#### A Minimal cURL Check
Use documentation-only addresses in saved examples and replace them with a current test endpoint at runtime:
curl --fail --show-error --max-time 10 \
--proxy http://203.0.113.5:8080 \
https://httpbin.org/ip
Keep certificate verification enabled. Do not use -k or --insecure. Record the timestamp, apparent address, response status, and endpoint; one success does not establish future availability or safety.

#### Python With Bounded Failure
The example below sends no secret and makes one bounded request:
import requests

proxy = 'http://203.0.113.5:8080'
response = requests.get(
'https://httpbin.org/ip',
proxies={'http': proxy, 'https': proxy},
timeout=10,
)
response.raise_for_status()
print(response.json())
Do not set verify=False or suppress certificate warnings. For SOCKS, socks5h:// asks compatible clients to resolve DNS through the proxy, but verify the actual client behavior rather than assuming there are no leaks.

#### Browser Automation Is Usually the Wrong Test
A browser sends more metadata, runs active content, stores state, and increases exposure to an unknown intermediary. Prefer a minimal command-line client and an endpoint you control. If an authorized browser QA test is genuinely required, use a fresh isolated profile, no real account, no stored secrets, correct certificate validation, and one documented request path.
Do not use a public proxy to log in, test checkout, solve a CAPTCHA, or imitate another person or device.

#### Handle Failures Without Bypassing Controls
A connection refusal or timeout means the diagnostic did not complete. A 407 means the intermediary requires authentication. A certificate error means stop and investigate; never disable validation. Unexpected or injected content means terminate the test and treat the response as untrusted.
A destination 401, 403, 429, CAPTCHA, or other access control means stop or back off. Do not try another address to obtain access the source refused. For an authorized production workflow, use accountable infrastructure and an approved API, feed, license, or written permission.

#### Using Databay's Public List
The Databay free proxy list publishes recently verified observations and download formats. Verification describes past behavior from Databay's probe network; it is not an operator, safety, consent, destination-access, or future-availability certification. Empty countries and protocols can occur.
Review the methodology and safety guide. Use the data only for low-risk authorized diagnostics and recheck the actual endpoint immediately before use.

#### FAQ
Q: Should I disable certificate verification for a free proxy?
A: No. A certificate error is a stop signal. Disabling verification removes protection against interception and makes the result unsuitable even for a routine diagnostic.
Q: Should I rotate after a 403 or CAPTCHA?
A: No. Stop or back off and review the destination's rules and your authorization. Do not change identity to bypass a control.
Q: Can I use a free proxy for a login?
A: No. Do not send credentials, cookies, tokens, or valuable account traffic through an unknown public proxy.
Q: Does a successful verification mean a proxy is safe?
A: No. It proves only the tested behavior for a particular request and time. Operator identity, consent, logging, integrity, and future behavior remain unknown.
Q: What is a suitable use?
A: A small, disposable, non-sensitive diagnostic against a system you own or are expressly authorized to test, where failure or an incorrect result causes no material harm.

### Responsible Web Data Collection: Authorization and Controls
URL: https://databay.com/blog/ethical-web-scraping-guide
Author: Databay Research Team. Published: 2026-01-10. Updated: 2026-07-30.

A practical control framework for authorized web data collection: source rights, robots.txt, privacy, load, provenance, and stop conditions.

#### Start With Rights and Purpose
Before collection, document the source owner, business purpose, exact URLs and fields, public or account-gated boundary, access method, terms review date, license or written permission, reuse rights, personal or protected data, retention, deletion process, and people responsible for review. Prefer an official API, export, bulk download, feed, or data partnership.
Technical accessibility is not permission. A proxy changes network origin; it does not grant a license, expand a quota, waive contract, or make copying lawful. This guide is operational information, not legal advice.

#### Treat robots.txt as Crawl Guidance, Not Legal Clearance
RFC 9309 standardizes the Robots Exclusion Protocol and explicitly says its rules are not access authorization. Fetch and cache the current file, apply the record for the crawler's actual product token, and retain the retrieval time and parser version.
An allow rule does not settle terms, copyright, privacy, authentication, or technical-access questions. A disallow rule is a strong reason to stop and seek an approved source unless the owner has provided specific written authorization for the workflow.

#### Set One Source-Level Load Budget
Do not invent a universal requests-per-second number from site size or brand. Use published quotas, Retry-After, API limits, owner guidance, written scope, and measured service health. Begin with the minimum needed, cache unchanged resources, deduplicate URLs, use conditional requests where supported, apply jittered exponential backoff for transient failures, and cap retries.
Enforce the budget per source across every worker, account, region, and proxy exit. Distributing traffic across IPs does not reduce aggregate load. Stop on persistent errors, latency degradation, 401, 403, 429, CAPTCHA, or another access control.

#### Do Not Cross Authentication or Control Boundaries
Never bypass login, paywall, CAPTCHA, purchase limit, queue, rate limit, IP block, or other technical control without the system owner's explicit written authorization for that exact test. Do not replace accounts, fingerprints, payment details, or proxy exits to continue after a refusal.
US computer-access law is fact-specific. Van Buren v. United States and the Ninth Circuit's hiQ opinion address particular CFAA questions; neither is blanket permission to scrape public pages or ignore other claims, jurisdictions, contracts, or later facts. Obtain counsel for consequential collection.

#### Apply Privacy Law to Public Data Too
Public availability does not remove personal-data obligations. Under GDPR Article 6, processing needs a lawful basis; other duties can include transparency, purpose limitation, minimization, accuracy, retention limits, security, rights handling, and transfer controls. Sensitive, children's, location, biometric, employment, and account data can require stricter review.
Inventory fields before collection, remove unnecessary identifiers, restrict access, encrypt storage, define deletion, and maintain a way to correct or erase records when applicable. Consult qualified privacy counsel for the people and jurisdictions in scope.

#### Preserve Provenance and Data Quality
Store source URL, retrieval time, response status and hash, relevant headers, parser and schema version, authorization reference, market and account state, extraction result, and validation status. Quarantine partial pages, challenges, unexpected templates, and outliers rather than treating them as valid data.
Measure freshness, missingness, duplicate rate, parse failures, match confidence, confirmed errors, and deletion compliance. Keep protected expression out of downstream products unless reuse is licensed; facts and expressive content require different analysis.

#### Identify and Secure the Collector
Where appropriate and accepted by the source, use an accurate product token and a monitored contact page or address. Do not impersonate a browser or person to conceal unauthorized automation. Keep credentials in a secret manager, minimize permissions, rotate them through the approved process, redact logs, and separate development from production.
Unknown public proxies are unsuitable for authenticated, personal, or private data. If regional routing is authorized, use accountable infrastructure and log the observed exit.

#### Operate a Reviewable Policy
Maintain a source register with owner, purpose, data rights, fields, robots and terms review, privacy assessment, request budget, stop signals, retention, deletion, incident contact, and next review date. Require approval for new sources and for material changes in purpose, scale, fields, or access boundary.
Audit logs and samples regularly. Suspend a source when its rules change, authorization expires, quality drops, complaints arrive, or controls appear. A sustainable program can explain why every field was collected and remove it when the justification ends.

#### FAQ
Q: Is collection ethical if a site's terms prohibit it?
A: Do not treat public visibility as permission. Stop, seek an approved API, feed, license, or written authorization, and obtain legal advice for consequential use.
Q: Can I use proxies to avoid a block?
A: No. A block, 429, CAPTCHA, or other control is a stop or backoff signal. Do not switch exits or identities to continue; review authorization and use an approved access method.
Q: Does GDPR apply to publicly available personal data?
A: It can. Public availability does not itself remove the need for a lawful basis or the other applicable GDPR duties. Obtain privacy review for the actual data, purpose, people, and jurisdictions.
Q: What request rate is responsible?
A: There is no universal number. Use published quotas, Retry-After, owner guidance, written scope, measured health, caching, and the minimum request volume needed. Apply one budget across all workers and exits.
Q: Should a collector identify itself?
A: Where the source accepts automated access, an accurate product token and monitored contact can improve accountability. Identification does not replace permission, and a false browser or person identity is not appropriate.

### How to Use Proxies for Ecommerce Price Monitoring
URL: https://databay.com/blog/ecommerce-price-monitoring-proxies
Author: Databay Research Team. Published: 2025-11-28. Updated: 2026-08-09.

Learn how to use proxies for ecommerce price monitoring: choose an authorized source, normalize offers, vary one network signal, and score a bounded pilot.

#### The Short Answer: Start With the Source, Then Add One Network Variable
To use proxies for ecommerce price monitoring, begin with an approved API, merchant feed, export, licensed dataset, or written permission. Define a complete price observation, then add a proxy only when the approved question genuinely requires a different network origin or region.
A proxy changes the route from which a request reaches a source. It does not set the delivery address, tax location, customer account, membership, device, cookie history, consent state, or experiment assignment. It also does not create authorization, raise a quota, guarantee access, or prove that one response represents every shopper.
The implementation sequence is therefore:
Define the business decision and authorized source.
Write the normalized observation contract.
Decide whether network origin is a required variable.
Select the least complex route and session mode that can vary that variable.
Enforce one source-level request budget and explicit stop conditions.
Validate product, offer, market, and response content.
Run a small representative pilot and complete the scorecard.
Promote only a workflow that meets its predeclared gates.

Outputs from the ecommerce price-monitoring workflowStageRequired outputDo not continue when
SourceRecorded permission, interface, fields, quota, and reuse rulesThe source or permitted method is unclear
ObservationA schema that preserves the full offer and market contextA bare price cannot be matched or compared
RouteA written reason that network origin mattersA delivery, account, or device variable is being mistaken for IP location
PilotUsable-record, freshness, quality, route, and cost evidenceThe design depends on continuing after a refusal or challenge

#### Step 1: Define the Decision and an Authorized Source
Write the decision before choosing a proxy: for example, review an approved reseller catalog, compare your own regional offers, audit feed quality, or inform an analyst about a documented competitor set. Name the decision owner, products, markets, freshness requirement, permitted recipients, retention period, and the action an observation may support.
Then build a source register. Amazon documents its Selling Partner Product Pricing API for eligible, authorized Selling Partner API applications. Google's Merchant API product guide documents how a merchant adds and manages structured product data in its Merchant Center account. These interfaces have different scopes; neither is a blanket feed of every competitor's public storefront. Use only the operations, accounts, fields, markets, quotas, and downstream rights available to your approved application.
Prefer the official or contracted interface when it supplies the needed fields. A public page should fill only a documented gap under an approved collection plan, not duplicate an available feed because the HTML looks convenient.
Source register for each monitored marketplaceFieldWhat to recordWhy it matters
Source owner and interfaceAPI operation, merchant feed, export, licensed dataset, partner report, or approved page setPrevents one access method from being silently substituted for another
Authorization evidenceAccount scope, agreement, permission owner, review date, and contactMakes the permitted boundary reviewable
Available dataIdentifiers, seller, price components, stock, region, timestamps, and change signalsShows whether a proxy-routed page adds any necessary information
Operating limitsQuota, schedule, caching, retention, privacy, and reuse rulesSets the collector's total budget and storage policy
Stop pathWhat happens when permission, schema, quota, or access changesPrevents automatic fallback to an unapproved method

#### Step 2: Write the Normalized Price Observation Contract
A price is comparable only when its product, seller, fulfillment, promotion, delivery, and market context are comparable. Define the record before writing a collector so every source maps into the same explicit contract.
Normalized ecommerce price-observation schemaGroupRequired fieldsValidation question
Product identitySource, marketplace, stable product ID, GTIN or SKU when available, exact variant, pack size, quantity, and conditionIs this the same sellable item rather than a similar title?
Offer identityOffer ID, seller, fulfillment method, stock state, and delivery promiseIs the seller and fulfillment context preserved?
Price componentsList price, displayed price, coupon or membership condition, shipping, tax treatment, mandatory fees, total, and currencyCan another analyst reconstruct the compared amount?
Market contextRequested and observed market, delivery assumption, language, device class, account state, consent state, and UTC timestampWhich shopper variables were controlled, varied, or unknown?
RouteSource method, proxy class if used, requested proxy location, observed route result, and session modeDid the route vary the network signal the test required?
ProvenanceAPI operation or URL, response status, permitted evidence reference or hash, parser version, and retrieval timeCan the observation be audited without retaining unnecessary data?
ValidationUsable, incomparable, missing, stale, partial, challenged, or refused; reason; reviewer stateWas a non-price response kept out of downstream decisions?

A compact implementation can preserve those groups without pretending that every field will be populated:
{
"product": { "sourceId": null, "variant": null, "quantity": null },
"offer": { "seller": null, "fulfillment": null, "stock": null },
"price": { "displayed": null, "shipping": null, "tax": null, "currency": null },
"market": { "requested": null, "observed": null, "deliveryAssumption": null },
"route": { "sourceMethod": null, "proxyClass": null, "sessionMode": null },
"evidence": { "retrievedAtUtc": null, "parserVersion": null, "status": null },
"validation": { "state": null, "reason": null }
}
Use null for unknown values and a named validation state for unusable responses. Do not turn a missing tax, unmatched variant, challenge page, or empty response into zero.

#### Step 3: Decide Whether the Approved Workflow Needs a Proxy
Ask which variable the business question needs to change. If the authorized API already returns the required market and offer fields, use it directly. If an approved public-page study specifically needs to compare network-origin regions while other known variables remain fixed, a geo-targeted proxy can supply that one input.
Proxy requirement decisionQuestionCorrect starting pointReason
The official source exposes the required regional price and seller fieldsNo proxyThe supported interface already answers the question with defined identifiers and quotas
An approved page test must compare responses from two network regionsProxy may be relevantNetwork origin is the declared experimental variable
The result depends on delivery postcode, account tier, membership, cart, tax nexus, or consentControl that state through an approved methodAn IP address does not reproduce those inputs
The result depends on a mobile app, carrier path, or device-only flowDefine a separate authorized mobile testA mobile IP alone does not reproduce an app or device
The source returns a block, CAPTCHA, login wall, or objectionStop and review the approved source pathA different exit is not permission to continue

Document the hypothesis in one sentence: "Holding product, seller, fulfillment, delivery assumption, language, account state, device class, and collection time within their stated controls, compare the response observed through approved network regions A and B." If the sentence cannot name what is fixed and what is varied, the result will be difficult to interpret even if every request succeeds.

#### Step 4: Choose the Network Route and Session Mode
Choose from the approved source and required signal, not from a universal ranking. Datacenter, residential, and mobile proxies describe different network origins; rotating and sticky describe assignment behavior; shared and dedicated describe allocation. Those axes should be recorded separately.
Route-selection worksheetOptionUse it whenDo not infer
Direct or datacenter routeAn approved API, feed, or page accepts the route and no consumer-network signal is requiredThat it will be accepted by every source or region
Residential routeAn authorized public-page comparison explicitly requires an ISP-origin regional sampleThat it represents every resident, address, account, or shopper
Mobile routeCarrier-network origin is a required and approved variableThat it reproduces a phone, app, GPS position, or mobile identity
Rotating sessionEach permitted observation is independent and the assignment is part of the sampling designThat every request receives a unique exit or a larger source quota
Sticky sessionA short authorized flow needs route continuityThat cookies, account state, inventory, or cart state live in the proxy

For the pilot, record protocol, gateway, target market, session rule, timeout, connection reuse, observed route, and total billed traffic. Compare usable records, completeness, latency, location fulfillment, security requirements, support, and cost. No proxy class guarantees a response, catalog coverage, or a particular destination classification.

#### Step 5: Build One Bounded Request Path
Put authorization, scheduling, caching, a source-wide request budget, logging, validation, and stop handling ahead of every worker. The number of exit addresses must not multiply the volume a source agreed to receive.
Review published source instructions, including robots rules where they apply. RFC 9309 standardizes the Robots Exclusion Protocol, but a robots rule is not an authorization grant or a complete statement of contract, privacy, copyright, database, or reuse obligations. Keep those reviews separate and documented. Every workload must also remain within Databay's Acceptable Use Policy.
for (const task of approvedTasks) {
await sourceWideBudget.take(task.source);
const response = await requestApprovedSource(task, task.declaredRoute);

if ([401, 403, 429].includes(response.status) || isAccessChallenge(response)) {
stopSourceAndOpenReview(task.source, response.status);
continue;
}

const record = normalizePriceObservation(response, task.contract);
if (!passesContentValidation(record)) quarantine(record);
else storeWithPermittedProvenance(record);
}
Treat proxy authentication failures as configuration problems, transient transport failures as bounded retry candidates only when the operation is replay-safe, and destination refusals or challenges as stop signals. Do not change exits, accounts, headers, or client identity to continue after a control. Cache unchanged data, omit assets the observation does not require, redact credentials, minimize personal data, and retain evidence only as long as the approved purpose requires.

#### Step 6: Validate the Offer, Not Just the HTTP Response
A successful HTTP status can still contain a challenge, empty shell, wrong product, stale price, different seller, unavailable variant, or unexpected market. Validate the response before it becomes a price record.
Content gates for a usable observationGatePass conditionFailure state
Product matchStable identifier, variant, quantity, and condition match the monitoring contractIncomparable
Offer matchSeller, fulfillment, stock, and delivery promise are identifiedPartial or incomparable
Price completenessCurrency and every required price component or condition are presentPartial
Market contextRequested region, observed route, delivery assumption, language, account, and device state are recordedUnknown context
FreshnessRetrieval time falls inside the decision's predefined maximum ageStale
Response integrityThe expected product content is present and no access control or challenge was receivedChallenged or refused

Quarantine failures and preserve the reason. Confirm consequential differences through the approved source, another authorized observation, or human review. A regional response is evidence of what one controlled request received; it does not establish why the source produced it, prove a seller policy violation, or represent all customers in that location.

#### Step 7: Run a Small Pilot and Complete the Scorecard
Choose the smallest representative pilot that can disprove the design: one authorized source, the important product and offer shapes, only the regions needed for the decision, and one frozen client and parser version. Predeclare the maximum observation age, required fields, acceptable location fulfillment, retry budget for replay-safe transport failures, stop signals, review owner, and cost ceiling.
Run the official or direct approved method as the baseline where available. Add one proxy configuration at a time so route, parser, product mix, and schedule do not change together. Do not invent a success threshold after seeing results.
Fill-in pilot scorecard; no benchmark values are assumedMetricFormula or evidencePredeclared gatePilot result
Authorization coverageApproved planned tasks / all planned tasks100%Enter result
Route fulfillmentObservations with the required confirmed route / routed attemptsOwner-defined for the required marketsEnter result
Usable-record rateValidated comparable records / eligible planned observationsOwner-defined from decision needsEnter result
Offer completenessUsable records with every required field / usable recordsOwner-defined from the schemaEnter result
Freshness complianceUsable records inside maximum age / usable recordsOwner-defined from decision latencyEnter result
Stop-condition handlingRefusals or challenges followed by further attempts0 continued attemptsEnter result
Review rateRecords requiring human review / collected recordsOwner-defined from staffing and riskEnter result
LatencyMedian and p95 for usable records, with failures reported separatelyOwner-defined from delivery windowEnter result
Cost per usable recordSource + proxy + compute + storage + review cost / usable recordsOwner-defined business ceilingEnter result
Corroborated disagreementMaterial differences not confirmed by an authorized check / reviewed differencesOwner-defined evidence toleranceEnter result

Keep failures in the denominator that matches the decision. Reporting latency only for successful responses or traffic price without validation and review cost can make a weak route appear efficient. Publish the pilot window, source, product mix, regions, exclusions, client version, parser version, gates, and uncertainty with the result.

#### Step 8: Promote Only a Workflow That Passes Its Gates
Before production, require an accountable owner to approve the source register, observation schema, network-signal justification, source-wide budget, cache and schedule, secret handling, stop behavior, validation rules, retention, deletion, incident response, human-review thresholds, and re-review date. Version the parser and contract so a field or source change cannot silently alter historical comparisons.
Monitor authorization coverage, observation age, usable-record rate, missing and partial states, challenge and refusal signals, route fulfillment, bytes, retries, cost per usable record, and reviewer load. Pause the source when its interface, permission, schema, controls, or expected content changes. Reassess whether an official or licensed source now answers the question without a proxy.
When the approved workflow truly requires a regional network sample, use the ecommerce proxy selection and pilot guide to compare network types, evidence limits, cost inputs, and current Databay options. Keep the ownership split clear: this tutorial implements an authorized monitoring process; the use-case page evaluates whether and which proxy service fits it.

#### FAQ
Q: Do I always need proxies for ecommerce price monitoring?
A: No. Start with an authorized marketplace API, merchant feed, export, licensed dataset, or partner report. Add a proxy only when the approved question requires a network-origin or regional variable that the supported source does not supply.
Q: Which proxy type should I use for ecommerce price monitoring?
A: Choose from the approved source and required signal. Datacenter can fit APIs, feeds, and permitted endpoints where consumer origin is unnecessary; residential can fit an authorized ISP-origin regional sample; mobile belongs only where carrier origin is an explicit variable. Measure the real workflow because none guarantees access or completeness.
Q: Does a residential proxy show the exact price every local shopper sees?
A: No. It changes one network-origin signal. Delivery address, tax, account, membership, cookies, device, consent, inventory, promotions, and experiments can also affect an offer. Record those variables and describe unknowns.
Q: How often should ecommerce prices be checked?
A: Set frequency from the authorized source quota, business decision, product volatility, cache policy, required freshness, and review capacity. Use one total source budget across every worker and exit; more proxy addresses do not grant more permitted requests.
Q: What should a price monitor do after a 403, 429, CAPTCHA, or login wall?
A: Stop or back off, record the control, and review the approved API, feed, quota, license, or permission path. Do not change exits, accounts, headers, or client identity to continue.
Q: What fields belong in an ecommerce price observation?
A: Preserve product and variant identity, seller, condition, fulfillment, stock, every required price component, currency, delivery assumption, requested and observed market, account and device context, route, time, source, parser version, evidence reference, and validation state.
Q: How should I evaluate a proxy pilot for price monitoring?
A: Predeclare gates, then measure authorization coverage, required-route fulfillment, usable and complete records, freshness, stop-condition handling, latency with failures, reviewer load, and total cost per usable record. Publish the pilot scope and uncertainty rather than treating one run as a universal benchmark.

### Web Scraping With Proxies: An Authorized, Reliable Workflow
URL: https://databay.com/blog/web-scraping-with-proxies-guide
Author: Databay Research Team. Published: 2025-11-12. Updated: 2026-07-30.

Design authorized data collection around APIs, source rules, a domain-level budget, stop conditions, and quality checks; a proxy is only a network input.

#### Start With the Data Source, Not the Proxy
Use an official API, bulk download, licensed feed, or direct data partnership whenever available. Before requesting a page, document the source owner, exact fields and URLs, public or account-gated boundary, terms and robots review date, written authorization, personal or protected data, reuse rights, and retention.
A proxy changes network origin. It does not grant access, expand a quota, make collection lawful, or entitle a crawler to continue after a block.

#### Define One Source-Level Request Budget
Set concurrency and request frequency for the destination as a whole, regardless of the number of workers or exit addresses. Cache unchanged responses; use conditional requests where supported; collect only required fields and assets; deduplicate URLs; and schedule around source guidance.
There is no universal safe requests-per-second figure. Begin below a documented quota or agreed limit, observe latency and errors, and reduce load when the source degrades. A pool must never multiply the traffic a source agreed to receive.

#### Choose a Network Origin
Datacenter, residential, and mobile proxies provide hosting, ISP, and carrier network origins. Choose only when the approved workflow has a documented routing or regional-sampling requirement. Compare live location fulfillment, latency, usable-response rate, sourcing and consent, security, retention, support, and current cost.
No network type has a universal trust score or success rate. A destination can evaluate address history, protocol and browser data, cookies, account state, rate, timing, and behavior. Do not switch address classes to route around a control.

#### Sessions, Retries, and Stop Conditions
Use a sticky session only when an authorized public flow requires short-term continuity. Connection reuse means a rotating gateway may keep one exit for several requests; log the observed address if it matters.
Retry an idempotent request only for a transient transport or server error, with capped exponential backoff and a global attempt budget. Treat 401, 403, 407 from the destination, 429, CAPTCHA, login, paywall, consent wall, cease-and-desist notice, or another access control as a stop or review signal. Never change identity to bypass it.

#### Data Quality and Provenance
Store source URL, retrieval timestamp, apparent region, response status, content hash, parser version, and any missing or challenge state with each observation. Preserve raw evidence only as long as permitted, and separate facts from derived classifications.
Validate schemas, units, currency, tax and shipping treatment, product identity, duplicates, stale pages, and personalization. Confirm consequential findings with another authorized source or a human review. A successful HTTP response does not prove that the content is complete or representative.

#### A Minimal Technical Pattern
Centralize authorization, caching, request budgets, and logging ahead of workers. A scheduler should emit only approved tasks; workers should respect the shared source limiter; a validator should quarantine incomplete or challenged responses; and a storage layer should retain provenance and deletion controls.
Keep credentials outside code, validate TLS certificates, restrict outbound destinations, minimize logs, redact secrets and personal data, and monitor source load and error classes. The proxy credential belongs in that controlled transport layer, not scattered through scraping code.

#### Review Before Launch
Confirm: the approved source and access method; permitted fields and reuse; robots and terms review; privacy basis; request budget; cache and freshness plan; session need; stop and escalation conditions; destination allowlist; secret handling; provenance; retention and deletion; owner; and incident response.
Re-review whenever the source, method, data, law, purpose, volume, or recipient changes. If the workflow depends on looking like different people or preserving access after a refusal, replace it with an approved API, license, or written permission.

#### FAQ
Q: How many proxies do I need for web scraping?
A: There is no responsible formula based on per-IP limits. Start with the source's authorized total request budget and required regional samples. More addresses do not permit more traffic.
Q: Should I rotate on every request?
A: Only if independent authorized samples require it. Connection reuse may prevent literal per-request changes. Apply one destination-level budget and never rotate around a refusal.
Q: What should I do after a CAPTCHA or 403?
A: Stop or back off, review authorization and source rules, and use an approved API, feed, license, or permission path. Do not retry through another identity merely to bypass the response.
Q: Are residential proxies required?
A: No. Use a proxy type only when an authorized workflow requires that network origin or location control. Compare measured availability, latency, quality, sourcing, and cost; none guarantees access.
Q: Does robots.txt decide legality?
A: No. It communicates crawler preferences under RFC 9309, but authorization, contract, privacy, copyright, database rights, and other rules remain separate. Respect it alongside the complete source review.

### HTTP vs SOCKS5 Proxies: DNS, TLS, UDP & Client Tests
URL: https://databay.com/blog/http-vs-socks5-proxies
Author: Databay Research Team. Published: 2025-10-17. Updated: 2026-08-04.

Choose HTTP or SOCKS5 from the client behavior you need, not an OSI-layer slogan. Compare handshakes, DNS location, TLS, authentication, and UDP limits.

#### The Short Answer: Choose the Client Behavior, Not the Label
Use an HTTP proxy when the workload is HTTP or HTTPS and the client has mature HTTP-proxy support. Use SOCKS5 when a SOCKS-aware client needs a generic TCP relay, an explicit choice between local and remote hostname resolution, or a documented UDP association.
Neither protocol is automatically faster, safer, more anonymous, or harder to detect. Those outcomes depend on the proxy operator, exit address, route, client, TLS validation, DNS mode, destination, and workload. Start with the control surface your application actually exposes.
Fast protocol decisionRequirementStart withWhat to verify
HTTP APIs, browsers, crawlers, or HTTPS sitesHTTP proxyCONNECT support, proxy authentication, certificate validation, connection reuse
Non-HTTP TCP applicationSOCKS5The application is SOCKS-aware and the gateway permits the destination
Hostname must resolve from the proxy networkEither can workFor SOCKS5, select a remote-DNS client mode such as socks5h; do not infer it from the protocol name
UDP is a real workload requirementSOCKS5 candidateBoth client and gateway implement UDP ASSOCIATE; verify with the intended UDP exchange
System-wide traffic routingNeither by defaultUse an approved OS, VPN, or network policy control; application proxy settings cover only participating clients

#### What Changes on the Wire
An HTTP forward proxy and a SOCKS5 server receive different first messages. That difference matters more than saying one sits at “Layer 7” and the other at “Layer 5.” OSI shorthand does not tell you where DNS runs, whether UDP is implemented, how credentials are protected, or whether your client supports the mode.
For plain HTTP, a client normally sends an absolute request target such as GET http://example.test/report HTTP/1.1. The proxy can process the HTTP message and create the upstream request. For HTTPS through an HTTP proxy, the client usually sends CONNECT example.test:443 HTTP/1.1. RFC 9110 says a successful 2xx response switches the connection to tunnel mode; the client can then negotiate TLS with the destination through that tunnel.
A SOCKS5 client first offers authentication methods, then sends a command. RFC 1928 defines CONNECT, BIND, and UDP ASSOCIATE, plus IPv4, domain-name, and IPv6 address types. The request itself reveals whether the client supplied a name or an already resolved address.

#### DNS Location Is a Client Decision
“SOCKS5 uses remote DNS” is incomplete. RFC 1928 lets a client put either a domain name or an IP address in the request. If the client sends a domain, the SOCKS server has the name and can resolve it. If the client resolves first and sends an IP, the lookup happened elsewhere.
HTTP proxy behavior is also client-specific, but a proxy receiving an absolute HTTP target or a CONNECT authority normally resolves that destination. Browser features such as secure DNS, proxy bypass lists, prefetching, extensions, service workers, and direct fallback can create other lookups or connections, so verify the complete application rather than one request.
Documented DNS controls in common clients, reviewed July 27, 2026ClientHTTP proxySOCKS5 local DNSSOCKS5 remote DNSImportant caveat
cURL 8.21.0--proxy http://host:portsocks5:// or --socks5socks5h:// or --socks5-hostnameProxy bypass environment variables can silently select a direct route; inspect verbose output
Python Requests 2.32.5 + PySocks 1.7.1http:// in the proxies mappingsocks5://socks5h://SOCKS requires the requests[socks] extra; per-request mappings avoid environment overrides
PlaywrightDocumented proxy.server optionHTTP and SOCKS schemes are documented, but no portable local/remote DNS switch is promisedThe browser engine owns the network stack; test each pinned engine and version
Node.js with UndiciEnvHttpProxyAgent documents HTTP and HTTPS proxy environment variablesNo SOCKS mode is documented by that agentBuilt-in fetch and an installed Undici package can differ; pin the implementation you test

#### Authentication and Encryption Are Separate Questions
Proxy authentication decides whether the gateway accepts the client. It does not automatically protect the client-to-proxy connection. HTTP proxy credentials can be sent using a supported proxy-authentication scheme. SOCKS5 negotiates a method before the relay request; the widely used username/password method is specified separately by RFC 1929, which states that its password is carried in cleartext by that subnegotiation.
Application encryption is a different layer. When an HTTPS client opens an HTTP CONNECT or SOCKS5 TCP relay and validates the destination certificate, TLS normally protects the HTTP content end to end between that client and destination. The intermediary still sees connection metadata, including the client connection, destination address or authority, timing, duration, and byte volume. Managed TLS interception changes the trust boundary and should be visible in the certificate chain and organizational policy.
What each mechanism does and does not provideMechanismIt can provideIt does not prove
HTTP proxy authenticationGateway access controlEncrypted client-to-proxy transport or destination authorization
SOCKS5 username/passwordGateway access control after method selectionCredential confidentiality; RFC 1929 does not encrypt the subnegotiation
TLS to an HTTPS destinationServer authentication and content protection when certificates are validated correctlyThat the proxy operator is safe, the source address has permission, or all device traffic uses the tunnel
“Elite” or “anonymous” checker resultOne observation about headers and addresses in one probeFuture behavior, operator logging, DNS coverage, or application-wide privacy

#### What We Reproduced Locally
On July 27, 2026, we ran cURL 8.21.0 on Windows and Python 3.13.14 with Requests 2.32.5 and PySocks 1.7.1 against local capture servers. The harness never contacted the named destination: an HTTP listener returned a synthetic response, while a minimal SOCKS5 listener recorded the greeting and request before returning a controlled failure.
The HTTP listener received an absolute-form request for a plain HTTP target. With socks5h://, both clients sent a SOCKS5 domain-name address. With socks5://, they resolved localhost first and sent an IP address. Those observations confirm the documented scheme distinction for those exact versions; they are not a performance benchmark or a promise about other clients.
Local capture observationsClient and settingCaptured destination representationConclusion limited to this test
cURL --proxy http://127.0.0.1:PORTAbsolute HTTP target containing the hostnameThe local HTTP proxy received the destination name and full unencrypted request line
cURL --proxy socks5h://127.0.0.1:PORTSOCKS5 ATYP 03 domain nameThe proxy was asked to resolve the name
cURL --proxy socks5://127.0.0.1:PORTSOCKS5 IP address typecURL resolved the test hostname before the relay request
Requests with socks5h://SOCKS5 ATYP 03 domain namePySocks passed the name to the proxy
Requests with socks5://SOCKS5 IP address typePySocks resolved the test hostname locally

Test boundary: a local capture proves what one client wrote to one listener. It does not prove that a commercial provider supports the same commands, that a destination accepts the resulting connection, or that no other application traffic bypasses the proxy.

#### Copy-Ready Configurations With Safe Failure Limits
Use documentation-only hosts below, replace the proxy endpoint through a protected configuration source, and test against a non-sensitive destination you control. Avoid placing production passwords in shell history, process arguments, screenshots, logs, or a repository.
cURL: HTTPS through an HTTP proxy
curl --proxy http://proxy.example:8080 \
--proxy-user "$PROXY_USER:$PROXY_PASSWORD" \
--connect-timeout 10 --max-time 30 \
--fail-with-body --show-error \
https://example.test/report
cURL: SOCKS5 with remote hostname resolution
curl --proxy socks5h://proxy.example:1080 \
--proxy-user "$PROXY_USER:$PROXY_PASSWORD" \
--connect-timeout 10 --max-time 30 \
--fail-with-body --show-error \
https://example.test/report
Python Requests: make DNS location explicit
import os
import requests

proxy = os.environ["PROXY_URL"] # e.g. socks5h://host:port
proxies = {"http": proxy, "https": proxy}

with requests.Session() as session:
response = session.get(
"https://example.test/report",
proxies=proxies,
timeout=(10, 30),
)
response.raise_for_status()
print(response.status_code)
Install SOCKS support with a pinned dependency such as python -m pip install 'requests[socks]==2.32.5', then record the resolved PySocks version in the lockfile. Requests warns that session proxy values can be overwritten by environment proxies, so the example passes the mapping on the request.
Playwright: use the documented proxy object
import { chromium } from 'playwright';

const browser = await chromium.launch({
proxy: {
server: process.env.PROXY_SERVER!,
username: process.env.PROXY_USER,
password: process.env.PROXY_PASSWORD,
},
});
Playwright documents HTTP and SOCKS server schemes, but authenticated SOCKS behavior and hostname resolution can vary by engine. Test Chromium, Firefox, and WebKit separately if the workflow depends on those details. Do not set ignoreHTTPSErrors to hide a certificate problem.

#### Diagnose the Boundary That Failed
A protocol switch is useful only when the protocol is the failing boundary. Preserve the first concrete error and work outward instead of rotating endpoints at random. Two of the cheapest misconfigurations to rule out first, a dead port and a live port speaking the other protocol, produce distinct curl exit codes; the proxy-port guide reproduces both against a local gateway.
Failure-source mapSignalLikely boundaryFirst useful checkDo not conclude
Name-resolution error before any proxy handshakeClient DNS or proxy-bypass pathCompare the configured scheme, verbose trace, and whether the client sent a domain or IPThat the proxy is dead
HTTP 407HTTP proxy authenticationCredential source, encoding, supported auth scheme, clock or account statusThat destination credentials failed
SOCKS reply 02SOCKS rulesetGateway policy, destination and account permissionThat another SOCKS command should bypass the policy
SOCKS reply 07Command supportWhether the gateway implements CONNECT, BIND, or UDP ASSOCIATEThat every SOCKS5 service supports UDP
Certificate hostname or issuer errorTLS trust or interceptionRequested hostname, certificate chain, system time, approved trust storeThat disabling verification is an acceptable fix
HTTP 403, 429, challenge, or account restrictionDestination policy or quotaStop, confirm permission, rate limits, API options, and destination support pathThat changing protocol authorizes continued requests
Timeout after a successful handshakeUpstream route, destination, workload, or idle timeoutSeparate connect, TLS, first-byte, and total time; compare a direct authorized baselineThat SOCKS5 is universally faster or slower

#### Choose by Workload and Maintained Client Support
For HTTP collection, APIs, browser automation, and most web QA, mature client support usually makes an HTTP proxy the simpler starting point. CONNECT carries HTTPS without asking the intermediary to decrypt it. A SOCKS5 relay becomes useful when a supported application needs a non-HTTP TCP connection, explicitly remote hostname resolution, or a verified UDP association.
Do not choose SOCKS5 to become “undetectable.” A destination can evaluate the exit address, TLS fingerprint, HTTP behavior, cookies, account state, request rate, navigation pattern, and many other signals regardless of relay protocol. Do not choose HTTP because it is always faster; an HTTP tunnel and a SOCKS5 CONNECT can carry similar TLS traffic, and implementation and route effects usually dominate a few handshake bytes.
Workload-oriented choiceWorkloadPractical starting pointReasonExit condition
HTTPS API clientHTTP proxyBroad CONNECT, authentication, timeout, and pooling supportMove only if the maintained client or network requirement calls for SOCKS
Browser automationThe protocol best supported by the pinned browser engineBrowser networking behavior matters more than an abstract feature listStop on challenges, account boundaries, quotas, or unclear permission
SSH or another approved TCP applicationSOCKS5 when the application supports itSOCKS5 is not limited to HTTP messagesVerify destination policy and that every required connection follows the relay
UDP applicationSOCKS5 only after an implementation checkRFC 1928 defines UDP ASSOCIATEReject the option if either side lacks documented and tested support
Unknown public proxyNeither for sensitive dataProtocol capability does not establish operator trustUse a named provider or an environment you control

#### Run a Fair HTTP-vs-SOCKS5 Benchmark
Do not compare one HTTP endpoint with a different SOCKS5 endpoint and attribute the result to protocol. Hold the gateway, exit policy, destination, client version, request set, concurrency, timeout, region, and time window constant. Warm and cold connections should be reported separately because connection reuse can outweigh handshake differences.
Record success rate before latency. Excluding failures can make an unreliable path look fast. For successful samples, report median, p90, and p95 for connect time, TLS time, time to first byte, and total time. Include the sample count and failure categories. Repeat across more than one window if the decision affects production.
Benchmark worksheetFieldHTTP proxy runSOCKS5 runWhy it matters
Client and exact versionRecordRecordProxy, DNS, pooling, and timeout behavior change by implementation
Gateway and exit policySameSamePrevents provider or route differences from masquerading as protocol effects
DNS modeRecordLocal or remoteResolution location can change both address selection and latency
Connection policyCold and reusedCold and reusedSeparates handshake cost from steady-state traffic
Requests attempted / succeededCount bothCount bothLatency percentiles without failures are incomplete
Connect, TLS, TTFB, totalp50 / p90 / p95p50 / p90 / p95Shows where any difference enters the path
Failure taxonomyDNS / auth / tunnel / TLS / HTTP / timeoutDNS / auth / command / TLS / HTTP / timeoutPoints to an actionable boundary rather than a protocol myth

#### A Reproducible Verification Sequence
Pin the client. Record the runtime, library, browser engine, operating system, and proxy dependency versions.
Use a destination you control. Return the observed source address, hostname, request identifier, and a small response. Never use an access-controlled third party as a test fixture.
Establish a direct baseline. Record DNS, connect, TLS, first-byte, and total timing without the proxy.
Verify the handshake. Use verbose client output or a local capture harness to confirm absolute HTTP, CONNECT, SOCKS5 domain, or SOCKS5 IP behavior.
Verify the observed exit. Compare the destination record with an IP diagnostic or run the endpoint through the proxy checker. One observation is not a safety certificate.
Exercise the real workload at small scale. Keep permission, rate limits, and a stop condition explicit.
Measure failures and percentiles. Do not publish a single “X ms faster” number without the full worksheet.
Retest after upgrades. A client or browser update is a reason to rerun the protocol and DNS checks, not merely change the article date.

#### The Decision Rule to Keep
HTTP and SOCKS5 are relay choices, not trust grades. Use the protocol your maintained client supports cleanly for the required traffic. Make DNS location explicit. Keep TLS validation on. Verify authentication transport, gateway command support, exit behavior, and destination permission. Then benchmark the two modes only if both remain viable.
If the job is ordinary HTTP or HTTPS, an HTTP proxy is usually the lowest-friction start. If the approved application needs generic TCP relay, explicit SOCKS hostname handling, or genuinely implemented UDP support, test SOCKS5. If the requirement is device-wide encrypted tunneling, this is the wrong comparison—start with the proxy versus VPN decision guide.

#### FAQ
Q: Is SOCKS5 better than an HTTP proxy?
A: Not universally. HTTP proxies usually have mature support in web clients. SOCKS5 is useful for SOCKS-aware non-HTTP TCP applications, explicit hostname handling, or verified UDP support. The better choice is the one that meets the workload and client requirements with fewer unverified assumptions.
Q: Is SOCKS5 faster than HTTP?
A: The standards do not imply a universal speed advantage. Gateway implementation, route, exit, destination, DNS, TLS, connection reuse, congestion, and client behavior can matter more. Compare success rate and timing percentiles with the same gateway, destination, client, workload, and time window.
Q: Does SOCKS5 always use remote DNS?
A: No. RFC 1928 allows a client to send a domain name, IPv4 address, or IPv6 address. In cURL and Python Requests with PySocks, socks5 uses local resolution while socks5h sends the hostname to the proxy. Other clients need their own documented and tested setting.
Q: Does SOCKS5 encrypt traffic or passwords?
A: SOCKS5 does not itself guarantee content encryption. Use TLS or another end-to-end encrypted application protocol. The RFC 1929 username/password method carries the password in cleartext within that subnegotiation, so the client-to-proxy trust and transport still matter.
Q: Can an HTTP proxy carry HTTPS?
A: Yes, when the client and proxy support CONNECT. A successful 2xx response opens a tunnel, after which the client normally negotiates TLS with the destination and validates its certificate.
Q: Does SOCKS5 guarantee UDP support?
A: No. RFC 1928 defines UDP ASSOCIATE, but clients, gateways, firewalls, and commercial products can omit or block it. Verify documented support on both ends and run the intended UDP exchange.
Q: Which proxy protocol should Playwright use?
A: Playwright documents HTTP and SOCKS proxy server schemes. Choose a mode supported by the pinned browser engine, then test authentication, hostname resolution, bypass rules, TLS validation, and every required request type. Do not assume behavior is identical across Chromium, Firefox, and WebKit.
Q: Can changing from HTTP to SOCKS5 bypass a 403, 429, CAPTCHA, or account restriction?
A: A protocol change does not grant permission or override destination policy. Stop, confirm authorization and rate limits, and use the official API, export, allowlist, support path, or licensed source where available.

### How Residential Proxies Work: Architecture and Routing
URL: https://databay.com/blog/how-residential-proxies-work
Author: Databay Research Team. Published: 2025-10-06. Updated: 2026-07-30.

A network-layer explanation of ISP-origin proxy routing, gateway selection, session continuity, consent, and the signals a destination still sees.

#### What a Residential Proxy Changes
A residential proxy relays an authorized request through an address announced by a consumer internet provider. A datacenter proxy normally uses an address announced by a hosting network. The destination sees the exit address as the network origin, but that is only one signal: it may also evaluate protocol details, browser and device data, cookies, account state, request rate, and behavior.
Residential routing does not make traffic indistinguishable from a person, grant access, or override a destination's terms or controls. Its legitimate value is providing an ISP-network or regional sample when that variable is part of an authorized test.

#### Address Allocation and Classification
Regional Internet Registries allocate address space to network operators, and Border Gateway Protocol announcements associate routes with Autonomous System Numbers. Commercial intelligence services combine routing, registry, geolocation, and observed-use data to classify an address. Those classifications differ by vendor, can be stale or wrong, and do not prove that an individual request came from a household.
Some consumer addresses change over time, while others remain stable for long periods. There is no universal 24-hour or 72-hour reassignment rule. A proxy user should treat country, city, ASN, and address-type labels as estimates and validate the fields important to the work.

#### Consent and Network Sourcing
Providers can source ISP-origin capacity through several arrangements, including direct network partnerships and software that lets a device owner share bandwidth. A responsible arrangement requires informed, revocable consent, clear disclosure, safeguards for resource use, and controls against prohibited traffic. The exact sourcing model and protections are provider-specific; a buyer should request the current policy and evidence rather than infer ethics from the phrase “residential proxy.”
Databay publishes its current sourcing and compliance commitments on the Trust Center. Product-level pool counts describe published network capacity, not the number of exits guaranteed to be available in a particular place or instant.

#### Request Path Through a Gateway
A typical request has four stages:
Client. An authorized application connects to the proxy gateway and sends credentials and any documented targeting flags.
Gateway. The service authenticates the request and selects an eligible live exit according to network, location, and session constraints.
Exit. The selected node opens or relays the destination connection using its network address.
Return path. Response bytes travel back through the service to the client.

The destination normally observes the exit address at the network layer. It can still infer or identify proxy use from other signals. Connection failure, live capacity, and destination policy can prevent a requested location or session from being fulfilled.

#### HTTP Tunneling and SOCKS5
For an HTTPS destination reached with HTTP CONNECT, the client asks the proxy to open a TCP tunnel and then performs TLS with the destination through that tunnel. If certificate validation succeeds and no managed TLS interception is configured, application content remains encrypted between client and destination. The proxy still handles connection metadata, and client configuration or a hostile endpoint can change the threat model.
SOCKS5 is an application-independent proxy protocol for relaying network connections. DNS may be resolved locally or remotely depending on the client and configuration, so SOCKS5 alone does not guarantee protection from DNS or WebRTC leaks. Verify the behavior of the actual client rather than relying on the protocol label.

#### Rotating and Sticky Sessions
A rotating gateway may select another live exit when a new proxy connection is created. Connection reuse means “one request” does not always equal “one new IP.” A sticky session asks the gateway to keep selecting the same exit for a limited period, subject to node availability; it is not a dedicated device and cannot guarantee continuity after a disconnect.
Use stickiness only when an authorized workflow needs short-term network continuity. Apply a single destination-level request budget across every exit. A 403, 429, CAPTCHA, or other access control is a stop or backoff signal, not a reason to rotate identities.

#### Performance and Measurement
Residential routing adds gateway, exit, and access-network hops, so latency and throughput vary with both geography and the live node. No universal latency range applies to every destination. Measure representative requests, publish the percentile and sample period, cap concurrency, reuse connections where appropriate, cache unchanged responses, and omit assets only when they are outside the approved scope.
Evaluate a provider with the variables that matter to the job: observed availability in required locations, response latency, error classification, consent and abuse controls, support, and total cost. A headline pool size cannot establish those outcomes by itself.

#### What Residential Routing Does Not Do
An ISP-origin address does not make automation human, anonymous, lawful, or welcome. It does not hide account identifiers, browser characteristics, TLS behavior, cookies, payment records, request patterns, or data supplied by the user. It also does not guarantee a precise physical location or a particular response.
Start with official APIs, bulk downloads, licensed feeds, or written permission. For permitted public-page collection, minimize fields and traffic, follow published controls, preserve provenance and timestamps, and disclose missing data. The proxy is one network input inside that compliance and quality system.

#### FAQ
Q: How do residential proxies differ from VPNs?
A: Both can change the address a destination sees. A consumer VPN commonly routes device traffic through provider-operated servers; a residential proxy relays selected application connections through an ISP-origin exit. Products vary, so compare the actual routing, logging, DNS, protocol, and consent documentation. Neither category guarantees anonymity.
Q: Why can residential proxies be slower than datacenter proxies?
A: They commonly add an access-network exit and more routing hops, and the live exit may have variable capacity. Geography, destination behavior, connection reuse, and congestion all matter, so measure the real workflow instead of relying on a universal speed figure.
Q: Can a website detect residential proxy traffic?
A: Yes. IP classification is only one signal. A website may consider address history, TLS and HTTP behavior, headers, browser data, cookies, account history, request rate, and interaction patterns. Residential routing does not make those signals disappear.
Q: What does a backconnect gateway do?
A: It authenticates a client and selects an eligible live exit according to documented pool, location, and session rules. It may also manage connection health and session affinity. Exact retry and failover behavior is provider-specific and should be verified in current documentation.
Q: How large must a residential proxy pool be?
A: There is no reliable universal threshold. Required capacity depends on authorized request volume, locations, concurrency, live availability, source limits, and data freshness. Measure fulfilled requests and location coverage rather than treating an advertised pool total as a success guarantee.

### What Is a Proxy Server? Trace Every Connection Step
URL: https://databay.com/blog/what-is-a-proxy-server
Author: Databay Research Team. Published: 2025-10-02. Updated: 2026-08-04.

A proxy server accepts one connection and creates or relays another. Trace HTTP, CONNECT, SOCKS5, DNS, TLS, and reverse-proxy paths in a reproducible lab.

#### The Shortest Accurate Definition
A proxy server is an intermediary that receives a connection or request on one side and creates or relays a connection toward another system. The important word is intermediary: the proxy becomes a participant in the route, with its own address, policy, logs, failures, and trust boundary.
For a forward proxy, your browser, script, or operating policy chooses the intermediary. The destination normally receives a connection from the proxy's exit, not directly from your application. For a reverse proxy, the service operator places the intermediary in front of its origin servers. Visitors may never know which origin handled the request.
Two meanings of “proxy server” that solve different problemsQuestionForward proxyReverse proxy
Who deploys it?The client, network administrator, or egress providerThe destination or application operator
What does it represent?A client-side application or network making an outbound requestOne or more origin services receiving inbound traffic
Common jobsControlled egress, allowlists, policy, caching, authorized regional QALoad balancing, routing, TLS termination, caching, access control
What does the next hop see?Usually the forward proxy's source addressUsually the reverse proxy's source address

A proxy changes a route; it does not make the user anonymous, authorize access, or guarantee a location. Accounts, cookies, device state, TLS behavior, request history, and proxy-added fields can all remain observable. The useful question is therefore not “am I hidden?” but “who opens each connection, who resolves each name, and what can each participant observe?”
One packaging deserves separate treatment: a web proxy is a website that performs the forward-proxy role inside a browser tab, fetching pages for you and rewriting their links. It needs no client configuration, and it has different capabilities and failure modes than the protocol-level proxies traced below.

#### One Request Becomes Two Connection Contexts
A direct HTTPS request is easy to picture: the client resolves a destination, opens a network connection, negotiates TLS, and sends the HTTP request. Add a proxy and there are at least two contexts to record: client to proxy and proxy to destination. They can use different source addresses, protocols, certificates, DNS resolvers, timeouts, and connection pools.
This distinction explains several otherwise confusing results. A proxy can authenticate the client successfully and still fail to resolve the destination. The proxy can reach the origin while the origin refuses the proxy's exit. A TLS error can occur while connecting securely to an HTTPS proxy, while negotiating TLS with the final destination through CONNECT, or while the proxy connects to an HTTPS backend. “The proxy failed” is not a diagnosis until the failing segment is named.
Draw two arrows before debugging: client → proxy, then proxy → destination. Put DNS, TLS, authentication, and timeout ownership on the arrow where each operation happens.
The interactive explorer above models five common paths. It is deliberately a model rather than a live test: clients can override defaults, managed inspection can terminate TLS, and multi-hop services can contain more than one internal intermediary.

#### HTTP Forwarding Sends a Different Request Target
For an ordinary HTTP request sent directly to an origin, an HTTP/1.1 client normally sends the path and query as the request target. When sending the request to an HTTP proxy, RFC 9112 requires absolute-form: the target includes the scheme and authority so the proxy knows where to forward it.
# Direct to the origin
GET /status?region=eu HTTP/1.1
Host: example.com

# Sent to an HTTP forward proxy
GET http://example.com/status?region=eu HTTP/1.1
Host: example.com
The proxy can read the HTTP method, target, headers, and body because it is processing a plain HTTP message. It can enforce policy, cache eligible responses, add or remove fields, select an upstream connection, or generate its own response. It also normally resolves the destination hostname found in the absolute URI. This is different from resolving the proxy's own hostname, which the client still has to do before it can connect to the proxy.
RFC 7239's optional Forwarded field can carry for, by, host, and proto information that proxying would otherwise lose. It is not a trustworthy client identity by itself: any untrusted participant can send or alter the field. A service should discard client-supplied forwarding fields at its trust boundary and accept only values written by an explicitly trusted proxy tier.

#### HTTPS Through CONNECT Has a Setup Phase and a TLS Phase
An HTTPS URL cannot be forwarded like plain HTTP without exposing the encrypted request to the proxy. Instead, a client commonly asks an HTTP proxy to open a byte tunnel using CONNECT.
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: [credential sent to the proxy only]

HTTP/1.1 200 Connection Established

[the client now starts a TLS handshake with example.com through the tunnel]
The exchange has two phases. First, the client connects to and authenticates with the proxy; the proxy evaluates example.com:443, resolves it when necessary, and opens an outbound TCP connection. Second, after a successful 2xx response, the proxy switches to forwarding bytes in both directions. The client normally negotiates TLS with example.com, so HTTP paths, headers, and content remain encrypted from the client to the destination.
The proxy is not blind. It knows the client connection, requested authority, connection time, volume, and outcome. The destination sees the proxy-facing source address and its own TLS session with the client. Managed TLS inspection is a different architecture: an authorized enterprise intermediary terminates TLS and issues a substitute certificate trusted by managed devices. If the certificate issuer is unexpected, stop; do not disable certificate verification to make the error disappear.

#### SOCKS5 Makes DNS a Client Decision
SOCKS5 is not HTTP. After method negotiation and any method-specific authentication, the client sends a command such as CONNECT with a destination port and one of three address types: IPv4, domain name, or IPv6. That small choice determines where destination-name resolution happens.
The DNS decision is encoded in what the SOCKS5 client sendsClient sendsWho resolved the destination?Practical consequence
IPv4 or IPv6 addressThe client or a resolver available to itThe SOCKS server receives an address, not the original hostname in the destination field.
Domain-name addressThe SOCKS server must resolve or otherwise route the nameThe client's normal resolver need not receive that destination lookup.

This is why a checkbox labelled “SOCKS5” is not enough to predict DNS behavior. In curl, for example, --socks5 resolves the destination locally, while --socks5-hostname or a socks5h:// proxy URL passes the hostname to the proxy.
# Local destination lookup before the SOCKS request
curl --socks5 proxy.example:1080 https://example.com/

# Send the domain name to the SOCKS5 server
curl --socks5-hostname proxy.example:1080 https://example.com/
SOCKS5 defines CONNECT, BIND, and UDP ASSOCIATE, but software and providers may implement only a subset. The base protocol is a relay and authentication framework; it does not promise encrypted application content. Continue to use TLS for HTTPS and verify the actual client's DNS, IPv6, and UDP behavior.

#### A Reverse Proxy Represents the Service, Not the Visitor
A reverse proxy sits on the destination side of the relationship. Public DNS may direct www.example.com to an edge or load balancer. That intermediary accepts the visitor connection, applies service policy, selects an origin, and creates a separate upstream connection. Common products can terminate TLS, cache responses, normalize requests, enforce access controls, or keep private origins off the public internet.
The origin therefore normally sees the reverse proxy as its network peer. If the application needs the original client signal, the operator must define a trusted channel such as a platform-specific connection property or a correctly managed Forwarded field. Reading the leftmost address from any user-supplied X-Forwarded-For value is unsafe: a client can create that header before it reaches the proxy.
Forward and reverse proxies can appear in the same route. A browser may use a corporate forward proxy to reach a CDN acting as the destination's reverse proxy, which then connects to an application gateway and origin. “The IP the server sees” depends on which server and which hop you mean.

#### What Changes, What Remains Visible
A forward proxy normally changes the network source seen on the destination-facing connection. That single fact is useful for a controlled egress allowlist or an authorized regional test, but it is only one line in the destination's observation.
Observation ledger for an application using a forward proxyObserverCan normally observeDoes not learn automatically
Local network or ISPA connection to the proxy, timing, volume, and often proxy DNSHTTPS content carried through a correctly validated tunnel
Proxy operatorClient identity or address, authentication, target, timing, volume, and routing resultEnd-to-end TLS content unless it terminates or intercepts TLS
DestinationProxy exit, TLS and HTTP behavior, headers, cookies, accounts, timing, and requested resourcesThe direct client address unless another trusted signal provides it
Application ownerIts own configuration, credentials, logs, retries, and client stateWhether every protocol followed the intended route without testing

Header-based labels such as Elite, Anonymous, or Transparent describe the output of a particular check, often the presence of Via, Forwarded, or legacy forwarding fields. An “Elite” result does not prove that the connection is undetectable or safe. It says nothing conclusive about DNS, TLS, browser state, malware, logging, consent, or authorization. Use the separate anonymity-level guide to interpret those classifications without turning them into privacy guarantees.

#### Diagnose the Failing Hop Before Retrying
Proxy failures are evidence about a stage of the route. Retrying with a different identity before locating that stage can hide a configuration defect and can cross a destination's access boundary.
Failure-source map: status alone is not enoughSignalLikely owner to inspect firstNext check
407 Proxy Authentication RequiredClient-to-proxy authenticationCredential scope, encoding, selected auth method, and whether the client sent it to the proxy rather than the origin
SOCKS reply “connection not allowed by ruleset”SOCKS policyPermitted command, destination, address family, and account policy
502 Bad GatewayAn intermediary or gatewayDestination DNS, TCP/TLS handshake, upstream protocol, and proxy-specific diagnostics
504 Gateway TimeoutAn intermediary waiting upstreamWhich timeout fired, origin health, network path, and connection-pool saturation
403, 429, or a challengeCould be proxy policy or destination policyResponse headers, documented quota, authorization, and whether the response was generated by an intermediary

RFC 9209 defines Proxy-Status so an intermediary can report errors such as dns_error, connection_timeout, or http_request_denied and distinguish its response from one received upstream. Not every proxy emits it, and detail can be intentionally limited for security. Preserve request IDs and timestamps, but never log proxy passwords, session tokens, or sensitive response bodies just to diagnose a route.

#### Run a Reproducible Route Verification
This lab answers a narrow question: did this particular curl invocation use the expected network exit? It does not prove anonymity, safety, or permission. Use credentials from your own account, test only destinations you are authorized to reach, and stop when a destination returns an access-control or quota signal.
# 1. Record the direct baseline.
curl --fail --silent --show-error \
https://databay.com/what-is-my-ip/json

# 2. Keep the password out of the proxy URL and shell history.
PROXY_SERVER='http://gw.databay.co:8888'
PROXY_USER='YOUR_DOCUMENTED_USERNAME'
read -s PROXY_PASS

# 3. Record the HTTP/CONNECT route.
curl --fail --silent --show-error \
--proxy "$PROXY_SERVER" \
--proxy-user "$PROXY_USER:$PROXY_PASS" \
https://databay.com/what-is-my-ip/json

# 4. For a SOCKS5 service, make DNS ownership explicit.
curl --fail --silent --show-error \
--proxy 'socks5h://YOUR_SOCKS_HOST:1080' \
--proxy-user "$PROXY_USER:$PROXY_PASS" \
https://databay.com/what-is-my-ip/json

unset PROXY_PASS
Run at least three times and record UTC time, curl version, proxy protocol, gateway, expected exit region, observed IP and IP family, HTTP status, total duration, and whether the result matched the design. Repeat separately for every application that matters; a curl result does not prove how a browser, mobile app, background updater, or UDP client routes.
If the direct and proxied observations are identical, check NO_PROXY, application-specific settings, unsupported proxy schemes, direct fallback, and whether you tested a cached response. If the route works but the region is unexpected, remember that IP geolocation is an estimate and databases disagree. Confirm the provider's live allocation and record the lookup source rather than claiming a physical location.

#### Choose a Proxy from the Requirement Outward
A proxy is a good fit when the requirement is application-scoped and falsifiable: one test runner needs an allowlisted egress, an authorized monitor needs a repeatable network sample, or a permitted collection job needs separate budgets and sessions. A VPN is usually the better starting point when policy must cover several applications or reach a private network at the operating-system layer.
Before selecting a proxy, write down: the applications and protocols in scope; destinations and authorization; client-to-proxy transport; target DNS ownership; IPv4 and IPv6 policy; TCP and UDP requirements; proxy authentication and credential rotation; gateway and exit regions; connection reuse; timeout and retry budget; direct-fallback policy; logs and retention; incident owner; and a test that proves the expected exit.
Then evaluate the operator. Ask who owns the service, how network capacity is sourced, what consent model applies, which records exist, how long they remain, how access is controlled, and how compromised credentials and abuse reports are handled. Residential, datacenter, ISP, and mobile describe network origins; none makes automation human, lawful, anonymous, or guaranteed to be accepted.
If the goal is to bypass authentication, a paywall, CAPTCHA, block, quota, purchase limit, or platform enforcement, stop. A proxy changes the route, not the permission. Use an official API, licensed feed, delegated account tool, allowlist, support channel, or written authorization instead.

#### FAQ
Q: What does a proxy server do?
A: It accepts a client connection or request and creates or relays another connection toward a destination. A forward proxy represents a client-side route; a reverse proxy represents one or more destination-side origins.
Q: Does a proxy hide my IP address?
A: The destination normally sees the proxy's exit address as its network peer, but that is not complete anonymity. The proxy knows the client connection, and destinations can observe accounts, cookies, TLS and HTTP behavior, headers, timing, and other signals.
Q: Does a proxy server encrypt traffic?
A: Not by category alone. HTTPS can protect content between the client and destination through CONNECT when certificate validation succeeds. Plain HTTP and base SOCKS5 do not themselves add end-to-end content encryption.
Q: Who resolves DNS when I use a proxy?
A: It depends on the protocol and client. An HTTP proxy normally resolves a hostname in an absolute request target or CONNECT authority. A SOCKS5 client can resolve locally and send an IP, or pass a domain name for the SOCKS server to resolve. The client still has to locate the proxy itself.
Q: What is the difference between a forward proxy and a reverse proxy?
A: A forward proxy is selected on the client side and represents outbound traffic. A reverse proxy is deployed by a service operator in front of origins and represents inbound service infrastructure. They can appear in the same end-to-end route.
Q: Why does a proxy return 407?
A: HTTP 407 means the proxy requires valid authentication for the client-to-proxy connection. Check credential scope, encoding, supported authentication method, and that the proxy credential was not mistakenly sent to the destination.
Q: Is using a proxy server legal?
A: A proxy is a general networking tool. Legality and permission depend on the destination, contract, authorization, data, purpose, rate, reuse, and jurisdiction. A proxy does not grant access rights; this is general information, not legal advice.

### Proxy vs VPN: A Practical Routing, Encryption & Trust Test
URL: https://databay.com/blog/proxy-vs-vpn-differences
Author: Databay Research Team. Published: 2025-09-25. Updated: 2026-07-30.

Choose between a proxy and VPN by tracing which apps, DNS requests, and IP routes each one changes. Includes a route map and a verification lab.

#### The 30-Second Decision
A proxy is usually the smaller routing tool: one configured application sends supported connections through a relay. A VPN is usually the broader routing tool: the operating system sends selected network traffic through a tunnel to a gateway. That distinction matters more than the labels “privacy” or “security.”
Start with the narrowest tool that satisfies a documented, authorized requirement. If one test runner needs a particular egress route, a proxy is often easier to isolate and audit. If a managed laptop must reach a private company network or protect multiple applications on an untrusted local network, a VPN is usually the better control point.
Decision matrix: begin with traffic scope, then validate the exceptionsRequirementLikely starting pointReason to verify
One browser, script, or API client needs a controlled egress routeProxyOther apps can remain direct, but DNS and protocol support depend on the client.
Most traffic on a managed device must enter a private networkVPNSplit tunneling, local routes, IPv6, and DNS policy can still create exclusions.
Regional QA for a site you ownProxy or VPNChoose the one that preserves a clean test baseline and record the observed exit.
Protecting several apps on untrusted Wi-FiVPN plus HTTPSThe VPN protects the hop to its gateway; HTTPS still protects content to the destination.
High-risk anonymity or personal safetyNeither by category aloneAccount identity, browser state, payments, logging, endpoints, and operator trust require a specific threat model.

#### Where Traffic Actually Changes Path
The original route map below shows the practical difference. With an application proxy, only a configured client is guaranteed to ask the proxy to relay a supported connection. With a VPN, an operating-system routing policy decides what enters the encrypted tunnel. Neither path proves that every packet follows the advertised route.
HTTP’s CONNECT method asks a proxy to establish a tunnel to a destination and then forward data in both directions. SOCKS5 defines a general relay interface with IPv4, domain-name, and IPv6 address forms. By contrast, the IPsec architecture describes protection at the IP layer between hosts or security gateways. Real products can combine these mechanisms, so configuration—not the product category—determines the route.
A useful mental model is to mark three boundaries: where traffic enters the new route, where that route ends, and what remains outside it. If those three facts are not written down, “the proxy is on” or “the VPN is connected” is not a sufficient test result.

#### Encryption: Separate the Local Hop from the Destination
A VPN normally encrypts traffic between the device and VPN gateway. It does not replace end-to-end HTTPS: after traffic leaves that gateway, TLS is still what protects application content to an HTTPS destination. A basic HTTP proxy does not automatically encrypt the client-to-proxy hop. When HTTPS is carried through CONNECT and certificate validation succeeds, the TLS session is normally between the application and destination while the proxy relays encrypted bytes.
Protection and visibility by network segmentQuestionApplication proxyVPN
What receives the original connection?The configured proxy client connects to the proxy gateway.The device connects to a VPN gateway through a tunnel protocol.
Is the local-network hop protected?Only if the proxy transport or application protocol protects it; HTTPS content can remain encrypted through CONNECT.Selected traffic is normally encrypted from device to VPN gateway.
Who can observe connection metadata?The proxy operator can observe gateway connections and routing metadata.The VPN operator can observe tunnel and post-gateway routing metadata.
Who protects content to an HTTPS site?TLS certificate validation and endpoint security; neither service should be treated as a replacement.
Does the tool guarantee anonymity?No. Accounts, cookies, browser state, payments, logs, endpoints, and behavior can identify or correlate a user.

For plain SOCKS5, the protocol supplies relaying and optional authentication; it does not add content encryption. For an HTTP proxy over an unprotected local connection, avoid sending plain HTTP or secrets. In both categories, the operator becomes a meaningful trust dependency. Review ownership, security controls, logging and retention language, jurisdiction, abuse handling, and incident history.

#### DNS, IPv6, WebRTC, and Split-Tunnel Failure Modes
Most route surprises happen outside the happy-path IPv4 web request. A browser may resolve a hostname locally before handing an address to a proxy, or it may pass the hostname for remote resolution. A VPN client may install a DNS resolver for tunneled traffic while leaving split-tunneled domains or local-network queries elsewhere. IPv6 can take a different route from IPv4. Browser real-time communication can also expose additional network candidates, although modern browser behavior and enterprise policy vary.
Do not reduce this to a generic “leak test.” Define the expected result for each channel first:
DNS: Which resolver should receive queries for public names and private company names?
IPv4 and IPv6: Should both use the new egress, should IPv6 be intentionally direct, or is it unavailable?
UDP: Does the selected proxy protocol and client support it, or should the application avoid it?
Local subnets: Should printers, development services, and private ranges remain reachable?
Browser communication: Are WebRTC features required, disabled by policy, or expected to use a managed route?
Failure behavior: If the gateway disappears, should traffic stop, retry, or fall back to a direct route?

A direct fallback can be convenient for low-risk testing and unacceptable for a managed security boundary. Treat that as an explicit design choice, not an implementation detail.

#### A Reproducible Ten-Minute Route Verification Lab
This lab does not benchmark providers and does not prove anonymity. It answers a narrower, repeatable question: which route did this specific client use at this time? Run it only with an account and endpoints you are authorized to test. Keep the password out of command history by reading it interactively.
# 1. Record the direct route.
curl --fail --silent --show-error https://databay.com/what-is-my-ip/json

# 2. Set non-secret proxy values from your own dashboard.
DATABAY_PROXY_SERVER='http://gw.databay.co:8888'
DATABAY_PROXY_USER='YOUR_DOCUMENTED_USERNAME'
read -s DATABAY_PROXY_PASS

# 3. Record the proxied route without placing the password in the URL.
curl --fail --silent --show-error \
--proxy "$DATABAY_PROXY_SERVER" \
--proxy-user "$DATABAY_PROXY_USER:$DATABAY_PROXY_PASS" \
https://databay.com/what-is-my-ip/json

unset DATABAY_PROXY_PASS
For a VPN, capture the direct result, connect the VPN using your organization’s approved client, then run the same request again. Repeat the comparison separately for every application and protocol that matters; one browser result says nothing about a background updater, native database client, IPv6 connection, or DNS path.
Route verification worksheet—copy one row per application and network conditionModeApplicationObserved IPIPv4/IPv6DNS path checked?Expected exclusionsUTC time
Direct baselinecurlRecord resultRecord familyYes / NoNoneRecord
Proxycurl or target clientRecord resultRecord familyYes / NoUnconfigured appsRecord
VPNTarget appRecord resultRecord familyYes / NoDocument split routesRecord

If results differ from the design, stop and inspect routing tables, client proxy settings, name resolution, and protocol support. Do not “fix” a block or challenge by changing identity; a destination refusal is an access-control signal, not evidence that routing is broken. The browser IP diagnostic and proxy checker provide additional controlled checks.

#### Performance: Measure the Workload, Not the Category
There is no responsible universal answer to “is a proxy faster than a VPN?” Both add a route and processing step. Results change with gateway distance, congestion, protocol, connection reuse, DNS, packet loss, the destination, and whether a browser opens many parallel resources. A datacenter proxy near the destination can outperform a distant VPN for one HTTP workload; a well-peered VPN can outperform a congested proxy on another.
Build a small authorized benchmark with a fixed client, fixed destination set, fixed region, and fixed concurrency. Capture at least connection success, DNS time, TCP/TLS connection time, time to first byte, total duration, bytes transferred, and retry count. Report medians and a tail percentile such as p95 rather than publishing a single best run. Change only one routing variable at a time.
Minimum performance record for an honest proxy-versus-VPN comparisonFieldWhy it matters
Client, version, and protocolDifferent stacks pool connections and resolve names differently.
Client, gateway, and destination regionsDistance and peering can dominate the result.
Concurrency and connection reuseA warm pooled connection is not comparable to a new tunnel.
Median and p95 over repeated runsTail latency exposes intermittent route or capacity problems.
Failure and retry policyDropping failures makes a route appear artificially fast.

#### When a Proxy Fits—and When a VPN Fits
A proxy fits best when routing is intentionally application-scoped: an approved test runner needs a stable egress allowlist, a synthetic monitor needs a documented regional sample, or a permitted data workflow needs a supported network origin. Per-client configuration can make ownership, budgets, and logs easier to separate. Residential, mobile, ISP, and datacenter proxies describe different network origins; they do not create permission to access a source.
A VPN fits best when the network policy belongs at the device or site boundary: employees need authenticated access to private company services, a managed device needs an encrypted route to an organization’s gateway, or multiple applications must share the same controlled egress. Split tunneling can preserve local or high-bandwidth routes, but every exclusion needs a reason and an owner.
Sometimes neither is the right starting point. A private link, service mesh, API gateway, SSH tunnel, destination allowlist, licensed feed, or direct API can provide a smaller and more accountable trust boundary. Choose from the requirement outward rather than purchasing a category and inventing a use for it.

#### Provider Trust and Production Readiness Checklist
Once the route works, evaluate the operator and operating model. Marketing claims such as “no logs,” “anonymous,” or “military-grade” are not architectures. Ask what data exists, which systems create it, how long each record remains, who can access it, and what happens during an incident.
Ownership: Identify the legal operator, infrastructure model, subprocessors, and jurisdictions relevant to the service.
Authentication: Prefer scoped credentials, rotation, revocation, least privilege, and IP allowlisting where appropriate.
Logging: Separate billing totals, authentication logs, destination metadata, support logs, and application content; they have different risk.
Failure policy: Decide whether a route outage must fail closed or may fall back to direct access.
Observability: Record gateway region, request ID, result class, timing, and retry without logging passwords, tokens, or sensitive payloads.
Abuse controls: Confirm how the provider responds to complaints, compromised credentials, and destination blocks.
Change control: Pin client versions, test upgrades, and keep a rollback path for routing-policy changes.

For high-stakes anonymity, personal safety, regulated data, or privileged credentials, obtain security advice for the real threat model. A generic comparison page cannot establish that either category is safe for those circumstances.

#### The Final Selection Worksheet
Write one sentence for each item before selecting a product: the applications in scope; destinations you are authorized to reach; required TCP or UDP protocols; expected DNS behavior; IPv4 and IPv6 policy; gateway and destination regions; local-network exclusions; failure behavior; operator visibility; retention limits; identity and access controls; performance target; request budget; incident owner; and exit plan.
If the scope is one application and you can prove unsupported traffic stays outside the design, test a proxy first. If the policy must cover several applications or reach a private network, test a VPN first. If the reason is “be anonymous,” “get around a block,” or “make the destination think I am someone else,” the requirement is not ready: revisit authorization and the threat model before choosing either tool.
Keep the completed route worksheet beside the system diagram and re-run it after client, browser, operating-system, DNS, or gateway changes. That turns a vague privacy claim into a falsifiable network control.

#### FAQ
Q: Is a VPN more private than a proxy?
A: A VPN can cover and encrypt more device traffic to its gateway, but broader scope is not the same as anonymity. Privacy depends on routing exclusions, DNS, applications, account identity, endpoint security, logging, operator trust, and the specific threat model.
Q: Does a proxy encrypt traffic?
A: Not inherently. HTTPS can protect application content end to end through a correctly validated CONNECT tunnel, while plain HTTP remains readable to intermediaries. SOCKS5 supplies relaying and authentication options but does not itself encrypt application content.
Q: Can a proxy and VPN be used together?
A: Yes, but the route and trust model become harder to reason about. The proxy connection may itself travel through the VPN, adding another operator, failure point, and source of latency. Draw the route, document DNS behavior, and verify each hop before using the combination.
Q: Which is better for authorized regional QA?
A: Use the smallest accountable route that supplies the required regional network sample and lets you hold browser, account, language, time, and test data constant. Record the observed exit and disclose that IP is only one location signal.
Q: Which is faster, a proxy or VPN?
A: Neither category is always faster. Gateway distance, peering, protocol, connection reuse, congestion, DNS, destination behavior, and client configuration can dominate. Benchmark the exact authorized workload and report repeated median and tail-latency results.
Q: Can either tool bypass a block or CAPTCHA?
A: It should not be used that way. A block, quota, authentication boundary, or challenge is a stop-or-review signal. Use an approved API, allowlist, license, permission route, or support channel instead of changing network identity.
Q: Which is better on public Wi-Fi?
A: A correctly configured VPN can encrypt selected traffic from the device to its gateway, while HTTPS protects application content to destinations. Device security, certificate validation, DNS policy, exclusions, and operator trust still matter.

### Residential vs Datacenter Proxies: Evidence-Based Comparison
URL: https://databay.com/blog/residential-vs-datacenter-proxies
Author: Databay Research Team. Published: 2025-09-18. Updated: 2026-07-30.

Compare ISP-origin and hosting-network proxy routes by measurable origin, location controls, session behavior, latency, sourcing, and cost.

#### The Difference Is Network Origin
Datacenter proxy addresses are normally announced by hosting or cloud networks. Residential proxy exits use addresses announced by consumer internet providers. Commercial classification databases combine routing, registry, geolocation, and observed-use data, and their labels can differ or become stale.
Network origin is one signal, not a verdict about a request. A destination can also evaluate address history, protocol behavior, browser data, cookies, account state, rate, and interaction patterns. Neither class guarantees acceptance.

#### Performance Must Be Measured
Datacenter routes often begin with stable, high-capacity infrastructure. Residential routes add a consumer-network exit with variable capacity. Actual results depend on gateway region, requested location, destination, payload, connection reuse, concurrency, and origin response time.
Test representative authorized requests and report median and tail latency, usable-response rate, error classes, fulfilled locations, sample period, and cost. Generic speed or success percentages cannot be transferred reliably to another target.

#### Side-by-Side Comparison
FactorDatacenterResidential
Address originHosting or cloud networkConsumer ISP network
LatencyOften less variable; measure the real routeOften more variable; measure live exits
LocationDepends on published facility and product coverageDepends on live ISP exits and published controls
SessionsStatic or rotating behavior is product-specificRotating and sticky behavior is product-specific
Sourcing reviewAddress ownership and allocationExit ownership, consent, resource controls, and allocation
Best fitAn authorized workload that accepts hosting-network originAn authorized workload that specifically needs ISP-network origin

#### Location and Session Requirements
Use the location controls published for the exact product and verify results independently. An IP country or city is an estimate and does not reproduce every local user's language, account, device, currency, taxes, inventory, or personalization.
Use a static address when a system you control needs an allowlist or stable audit source. Use a sticky session only when an authorized workflow needs short-term continuity. Apply a single destination-level request budget across all exits and never change addresses to bypass a block, quota, CAPTCHA, or other control.

#### Cost and Capacity
Billing models vary by provider and product: traffic, ports, allocated addresses, minimum orders, validity periods, and location features can all affect total cost. Compare current published prices with representative bandwidth and usable responses. Do not import industry-wide price ranges into a purchasing decision without a dated source.
A larger advertised pool may offer more potential exits, but it does not guarantee live availability in a required location or better data. Measure fulfillment, diversity, latency, and failure modes for the approved job.

#### Decision Framework
First document authorization, source rules, official API or feed options, required network origin, locations, request budget, stop conditions, session continuity, data sensitivity, retention, and cost ceiling. Then test the smallest representative workload against systems you control or are allowed to access.
Choose datacenter when hosting-network origin satisfies the requirement and measured reliability and cost are acceptable. Choose residential only when ISP-network origin or its published location controls are a real requirement. A block is a reason to stop and review access, not to escalate to another address class.

#### FAQ
Q: Are residential proxies always better than datacenter proxies?
A: No. They provide a different network origin and often different location controls, with different variability and cost. Choose from the authorized requirement and measurements; neither type has a universal success advantage.
Q: Can I use datacenter proxies for a public website?
A: Only when the access is authorized and the source accepts the method and rate. If it blocks or challenges the request, stop or back off and use an approved API, feed, license, or written permission rather than rotating around the response.
Q: Why can residential traffic cost more?
A: Provider sourcing, live-exit availability, routing, support, and product design differ. Review the provider's current price and sourcing documentation; there is no universal cost formula.
Q: Should I use rotating or sticky sessions?
A: Use rotation for independent, authorized samples and stickiness only for short-term continuity the permitted workflow actually needs. One source-level budget and the same stop conditions apply to the entire pool.
Q: Can browser data identify automation independently of IP type?
A: Yes. Browser and protocol signals, cookies, account history, timing, rate, and behavior remain separate from address classification. Use accurate settings and do not attempt to conceal unauthorized automation.