Are free proxies safe? What a free list actually delivers

Are free proxies safe? Only for requests that carry nothing of value. A free proxy is a machine run by someone unknown, and measurement studies of public lists have caught proxies injecting scripts, swapping TLS certificates, modifying downloaded executables and forwarding the client’s real IP. Passwords, session cookies, API keys and payment data should never pass through one.

A free proxy list looks generous: thousands of IP and port pairs, sorted by country, refreshed every few minutes. Point a scraper at it and most requests time out. Point a browser at it and a more important question gets skipped: who runs the machine on the other end?

Are free proxies safe? The short answer

A free proxy is a machine run by someone the reader does not know, for reasons the reader cannot see. Some are misconfigured servers. Some are hijacked routers. Some exist on purpose, to log or rewrite the traffic that passes through. A public list does not say which is which.

That uncertainty is the root of every free proxy risk. A paid proxy is not honest by default, but it has an operator with a name, terms of service and a reason to keep customers. A free one has none of those, so the traffic pays in other ways.

Whether a free proxy is safe for a given job depends on three things: what travels through it, whether it is encrypted end to end with the certificate checked, and what it costs when a response fails or comes back altered.

What studies of free lists found

Two large measurement studies put numbers on free proxy risks.

Most listed proxies do not answer. A Georgetown University team tracked more than 107,000 listed open proxies and 13 million proxy requests over 50 days, and found that more than 92% of the proxies on aggregator sites were unresponsive (Mani et al., ACSAC 2018, arXiv June 2018). A longer study followed 640,693 proxies from 11 free providers for 30 months, April 2021 to October 2023. Only 34.5% passed its verification test even once, and an average of 3.36% worked on any given run (Mehanna et al., MADWeb 2024, arXiv March 2024).

Many that answer leak the client. Of the 13,740 proxies that reached the Georgetown team’s own web server, 66.08% added at least one header, most often X-Forwarded-For, that carried the client’s real IP address. The target sees the proxy and the machine behind it. Every one of them can also keep a log of who connected, when, and to which host.

Content injection has been measured. In the same 2018 study, 10.5% of requests for HTML pages came back with unexpected content, including JavaScript that mined cryptocurrency in the visitor’s browser. The 2024 study compared every response with the known body of its own test page and flagged 16,923 proxies that manipulated content.

Some tamper with downloads and TLS. In the 2018 data, 1.93% of proxies (413 of 21,385) maliciously modified a Windows .exe file at least once, and 1.06% of HTTPS-capable proxies (102 of 9,625) ran a TLS man-in-the-middle by presenting a substituted certificate.

Many sit on vulnerable devices. The 2024 study matched active proxies against known vulnerabilities and counted 4,452 distinct CVEs, and 42,206 of the proxies appeared to run on MikroTik routers. That pattern points to open or compromised routers, not services anyone chose to offer. Whether proxy use is legal depends on the country and the purpose, but consent is the narrower problem here: many of these devices carry traffic their owners never agreed to carry.

Small percentages still matter, because a scraper does not make one request. A job that rotates through 300 HTTPS-capable proxies from a list would, at the 2018 rate, meet about 3 that try a certificate swap (300 x 1.06% = 3.18). One is enough if the client accepts it.

What HTTPS hides and leaks

HTTPS protects what a request says through a free proxy, but not the record of who sent it where.

Plain HTTP is open to interception. A request to an http:// URL reaches the proxy as a complete message: URL, cookies, form fields, Authorization headers and the full response. The operator can read it, store it and change it before passing it on. Every script injection in the studies above works on this kind of traffic.

HTTPS through CONNECT hides content. For an https:// URL, the client sends the proxy a CONNECT host:443 request, and the proxy relays bytes in both directions. RFC 9110 (June 2022) defines this as a tunnel between two connections. The TLS session runs from the client to the target, so the proxy sees ciphertext, not pages or cookies, as long as the client verifies the certificate.

It does not hide metadata. The proxy still sees the client’s IP, the hostname in the CONNECT line, the time of every connection and how many bytes moved each way. The TLS handshake usually carries the hostname in clear text as well: RFC 9849 (March 2026), which standardises Encrypted Client Hello, describes the plaintext Server Name Indication as perhaps the most sensitive data TLS 1.3 leaves unencrypted. A free proxy operator can log which sites a client visited, and when, without breaking any encryption.

Certificate checks are the whole defence. A certificate swap only works against a client that accepts the fake certificate. Browsers stop with a full-page warning. Scraping code often does not: verify=False in Python requests, -k in curl and ignoreHTTPSErrors in Playwright all switch the check off, and each is a common quick fix for a stubborn SSL error.

There is a practical catch too. The 2024 study found that on average only 2.5% of the proxies that answered on its HTTP test endpoint also worked on its HTTPS endpoint. Most free proxies cannot carry HTTPS at all, which pushes people toward the one traffic type that is fully exposed.

When the free proxy is you

“Free” has a second meaning. Some free VPN and proxy apps are paid for with the user’s own connection: the app routes other people’s traffic through the phone or PC it runs on.

IPIDEA is the documented case. Google’s threat intelligence team described disrupting IPIDEA, which it called one of the largest residential proxy networks in the world (Google Threat Intelligence Group, January 28, 2026). Its operators enrolled devices through free VPN apps that joined devices to the network without clear disclosure, and through apps that promised money for “unused bandwidth”. Google found more than 600 apps with code that connected to IPIDEA’s command servers, and in one seven-day period in January 2026 more than 550 threat groups it tracks used IPIDEA exit nodes.

The FBI names the same routes. Its public service announcement names routes including free VPN services that may enroll devices without consent, compromised IoT devices on home networks, malware in free pirated games and video, and “passive income” bandwidth apps (FBI IC3, PSA I-031226-PSA, March 12, 2026). Its advice to individuals includes caution with free VPNs and unofficial app stores.

The device owner pays twice. Phishing, fraud and account takeover attempts can then arrive from the owner’s home IP, and that address gets flagged by the sites it touches. Google also warns that an enrolled device receives traffic its owner does not control, which opens a path to other devices on the same home network.

Two checks follow. On a personal device, remove any VPN or proxy app with no visible subscription model, and any app that shares the connection without having asked. For a business buying residential proxies, ask the provider how devices joined the pool and whether owners can leave. proxymint’s answer: its residential exits come from device owners who opted in and can opt out.

When are free proxies safe enough

The risk sits in what the traffic carries. A request that carries nothing has little to lose, and a few jobs fit that description:

• Checking how a public page renders from another country, with no login and no cookies from a real account.
• Learning how proxy settings work in curl, requests or a browser, against a public test page.
• A one-off check that a script reads its proxy configuration at all.

Even then, three rules hold. HTTPS only, with certificate checks on. No downloads of executables, packages or archives. And a fresh browser profile or container that shares nothing with real accounts.

The line is easy to find. Once a request carries a password, a session cookie, an API key, payment data or a file that will be run, the answer to “are free proxies safe” is no. The same goes for anything a business depends on: a pool where 3.36% of proxies work on an average run cannot hold a schedule.

Free proxies for scraping: the costs

Scraping is where a free proxy list gets tried most, and where it fails in the most expensive ways. For a data team the bigger public proxy danger is bad data that nobody notices.

Silent corruption. A proxy that injects a script or rewrites a price returns HTTP 200. The parser takes the page, the pipeline stores it, and the error surfaces weeks later in a report. Without a check on every response, a scraper cannot tell a clean page from a modified one.

Retry storms. With more than 92% of listed proxies unresponsive in the 2018 study, most of a job’s time goes into timeouts. Retries multiply request volume, so poor performance and reliability also make the traffic look more automated.

Burned addresses. A public list is public to everyone, including the anti-bot teams of the sites it gets pointed at. Every IP on it carries traffic from every other person using the same list, so its reputation is usually spent before the first request, the shared-address problem covered in dedicated vs shared proxies. The posts tagged proxy detection cover how targets score an address.

Leaked origin. When two thirds of reachable proxies forward the client’s IP in a header, the target can block the scraping server itself, and the proxy has achieved nothing.

Free proxies for scraping fail on reliability before security comes up. They trade a zero price for engineering hours spent on timeouts, validation and cleanup.

Test a free proxy list safely

For one particular free proxy list, the answer can be measured without putting real data at risk. The method below uses an endpoint the tester controls and sends nothing worth stealing.

1. Stand up an echo endpoint. A small server with two routes: /probe returns a fixed body with a known SHA-256 hash, and /headers returns the request headers it received as JSON. Serve both over HTTP and over HTTPS with a valid certificate.
2. Pull a sample. Take 200 proxies from one public list and note the time of download.
3. Probe every 15 minutes for 24 hours. For each proxy, record whether it answered, whether the body hash matched, which forwarding headers arrived (Via, X-Forwarded-For, Forwarded) and whether HTTPS through CONNECT passed certificate verification.
4. Send no credentials. No cookies, no auth headers, no real accounts. The test needs none.

import hashlib
import requests

ECHO = "ECHO_HOST"            # a server the tester controls
EXPECTED_SHA256 = "KNOWN_HASH"  # sha256 of the fixed /probe body

def probe(proxy_url):  # proxy_url = "http://IP:PORT" from the list
    proxies = {"http": proxy_url, "https": proxy_url}
    result = {"proxy": proxy_url}
    try:
        r = requests.get(f"http://{ECHO}/probe", proxies=proxies, timeout=10)
        result["alive"] = True
        result["body_ok"] = hashlib.sha256(r.content).hexdigest() == EXPECTED_SHA256
        h = requests.get(f"http://{ECHO}/headers", proxies=proxies, timeout=10).json()
        result["forwarding"] = {k: v for k, v in h.items()
                                if k.lower() in ("via", "x-forwarded-for", "forwarded")}
    except (requests.RequestException, ValueError):
        result["alive"] = False
        return result
    try:
        requests.get(f"https://{ECHO}/probe", proxies=proxies, timeout=10)  # verify stays on
        result["https"] = "ok"
    except requests.exceptions.SSLError:
        result["https"] = "certificate failed"
    except requests.RequestException:
        result["https"] = "no CONNECT"
    return result

Read the output as four numbers: the share alive at the first probe, the share still alive after 24 hours, the share that forwarded the tester’s IP, and the share that altered the body or failed the certificate check. Going by the studies above, expect the first two to be low and the last to be small but not zero.

Free vs paid proxies, compared

A paid proxy does not remove trust from the equation. The provider still sees the same metadata a free operator sees: client IP, target hostnames, timing and volume. What changes is who that party is, whether the address is shared, and whether anyone answers for it when it breaks. Read the provider’s privacy policy for what it logs; proxymint’s is on its privacy page.

The probe script above works on a paid proxy too, and a provider’s claims should survive it, along with the rest of a proxy provider security review. On proxymint’s per-GB gateway, measured in September 2026, no Via or Forwarded header reached the target; HTTPS requests go through CONNECT, which relays encrypted bytes, so no X-Forwarded-For can be added to them. Names sent through HTTP CONNECT or socks5h:// were resolved on the proxy side (our US test exits used US public resolvers); with plain socks5:// the client’s own resolver does the lookup. The same gateway answers a plain http:// request with a 301 to the https:// URL, so read the HTTPS result there.

The entry paid tier at proxymint is datacenter proxies: dedicated IPv4 ports assigned to one customer, with username and password access and no bandwidth cap under normal use.

Datacenter is not the right answer everywhere; the guide to datacenter proxies covers where it fits. Social platforms, strict retail and marketplaces behind anti-bot vendors classify hosting ASNs on sight, so those targets call for a residential or ISP origin. Free vs paid proxies is a comparison made per job.

Free proxy or free VPN

A VPN encrypts everything between the device and the VPN server, so the local network sees nothing useful. A proxy only relays, and plain HTTP stays readable to its operator. But the VPN operator then sees what a proxy operator sees, and a free VPN has the same funding problem as a free proxy, plus the enrolment risk above. For personal privacy, a paid VPN with a named operator beats both free options. For scraping or geo-testing at volume, a VPN is the wrong tool: a handful of exit addresses, shared with every other subscriber, as the proxy vs VPN comparison sets out.

Legitimate free proxy services

Several paid providers offer a free trial or a small free tier. That is a different product from a public list: a named operator, credentials, terms of service, and addresses not published to the world. Of the safer alternatives to a free list, it is the one for testing a provider before paying, with the same caveat as any paid proxy: the provider still sees the metadata.

Free or paid, by the job

The right proxy comes down to what the request carries and what a failure costs:

• The request carries nothing (a public page, a config test): a free proxy is acceptable over HTTPS with certificate checks on. Use it once and drop it.
• Bulk collection from lenient targets, API polling or uptime checks: datacenter proxies are the fastest paid option, billed per port per month.
• The target scores hosting ranges: rotating residential proxies exit through home connections. The sourcing question above applies to every residential pool.
• The job logs into accounts or holds a session for days: static ISP proxies keep one ISP-registered address for the whole term.

Whichever tier fits, keep certificate verification on; that rule holds for paid proxies too.