Detecting a proxy that is logging your traffic
A proxy sits in the middle of every request you send through it. That’s the job. The question worth asking before you route anything sensitive through one is what “in the middle” actually means for that specific proxy: does it just forward bytes, or does it open them up and read them first.
I run proxy infrastructure for scraping work, so I think about this from both sides. When I stand up exit nodes, I know exactly what they can and can’t see, because I built the pipe. When I use someone else’s proxy, whether it’s a paid residential pool or a free list scraped off a forum, I have no such guarantee. Nobody hands you a log of what their proxy server does with your traffic. You have to check for yourself, and the checks are mostly protocol-level, not vibes-based.
What “logging” means at the protocol level
There are two very different cases, and mixing them up is where most confusion comes from.
For plain HTTP, a proxy sees everything by default. Headers, the full URL path, query parameters, and the request body if there is one, all pass through in clear text. Any proxy operator can log all of it without doing anything clever. This isn’t a hack, it’s just how an HTTP proxy works. If you’re sending API keys or session tokens over plain HTTP through a third-party proxy, treat that data as already exposed to whoever runs the proxy.
For HTTPS, the standard behavior is different. A client sends a CONNECT request to the proxy, the proxy opens a raw TCP tunnel to the destination, and the TLS handshake happens end to end between your client and the destination server. In this mode the proxy is a dumb pipe: it can see which host and port you connected to, and it can see how many bytes moved and when, but it cannot read the encrypted contents. That’s the trust boundary most people assume they’re operating inside when they route scraping traffic through HTTPS.
A malicious or badly-configured proxy breaks that boundary by doing TLS interception: it terminates your TLS connection itself, decrypts the traffic, logs or modifies it, then re-encrypts and forwards it to the real destination. For this to work without your HTTP client throwing a certificate error, the proxy has to present you with a certificate it controls instead of the destination’s real one, and something on your end has to be configured to trust that certificate. That second part is the detail that makes this detectable.
The certificate check
This is the single most reliable test. When your client connects through the proxy in tunnel mode, capture the certificate the server presents and compare it against what you get on a direct connection to the same host, or against known-good certificate details for that domain (issuer, serial number, public key fingerprint).
If the proxy is behaving correctly, the certificate you see through it is byte-for-byte the same one you’d see connecting directly, because the proxy never touched the TLS session. If the proxy is intercepting, you’ll see a certificate issued by something other than the domain’s real CA, often a self-signed cert or one chained to a private CA you’ve never heard of. Most HTTP client libraries let you inspect the peer certificate on the connection object; this is a few lines of code, not a specialized tool.
The reason this test works so well is that interception requires the proxy to actively substitute a certificate, and that substitution is visible unless your machine has already been configured to trust the interceptor’s CA. If you didn’t install a corporate or vendor root certificate yourself, and a proxy’s TLS session still validates against a certificate you don’t recognize, that’s a hard signal, not a maybe.
Checking your own trust store
Related to the above: if a proxy vendor asks you to install a root certificate on your machine or in your browser before their proxy will “work” with HTTPS sites, understand what you’re agreeing to. You are handing them the ability to decrypt every HTTPS session on that device, not just traffic to your scraping targets. This is standard practice for legitimate corporate MITM inspection tools deployed by IT departments on company-owned hardware with disclosure. It is a very different thing when a proxy reseller asks for it with no explanation. Check your system and browser certificate stores periodically for CAs you don’t remember adding.
Header and metadata tells
Even proxies that don’t intercept TLS can leave fingerprints in what they do touch. A proxy that adds a Via header, an X-Forwarded-For header carrying your real IP, or custom headers with tracking-looking values is telling you it’s actively modifying requests, not just tunneling them. That doesn’t prove logging on its own, plenty of legitimate proxies add standard headers for transparency reasons, but it does prove the proxy is inspecting and rewriting your traffic at the HTTP layer rather than passing it through untouched. Combine an unexpected header with unexplained TLS behavior and you have a pattern worth acting on.
Latency fingerprinting
TLS interception isn’t free. Decrypting a stream, inspecting or logging it, and re-encrypting it before forwarding takes measurable time, especially under load on a proxy handling many concurrent sessions. If you benchmark round-trip time to a known endpoint through a suspect proxy against round-trip time through a proxy you trust (or a direct connection), a consistent, disproportionate latency gap on HTTPS specifically, not on plain HTTP through the same proxy, is a secondary signal worth cross-checking against the certificate test. Latency alone is noisy and can be explained by a dozen other things, so don’t lean on it in isolation.
The canary test
This is the same technique used to catch data exfiltration generally, and it works well against proxies. Stand up an endpoint you control, one nobody else knows about, and send a request through the suspect proxy containing a unique, unused credential or a unique URL path that has never appeared anywhere else. Then watch your own server logs and, separately, watch for any unexpected access to that credential from an IP you don’t recognize. If a proxy is logging traffic and someone downstream is replaying captured credentials, a canary is often how it surfaces, sometimes days or weeks later. It’s a slow test, but it’s one of the few that catches logging done for later use rather than real-time interception.
DNS resolution and who sees your targets
Depending on the proxy protocol, DNS resolution for the destination hostname can happen on your client or on the proxy server. SOCKS5 proxies typically support remote resolution, meaning the proxy server does the DNS lookup, which means the proxy operator’s resolver, and anything logging that resolver’s queries, gets a record of every hostname you’ve targeted even before any request is sent. If you’re scraping something sensitive enough that the target list itself is confidential, remote DNS resolution through a third-party proxy is worth knowing about regardless of whether the proxy touches your payload at all.
Why free and low-accountability proxies carry more of this risk
I’m not going to tell you a specific provider is safe or a scam, that’s not a claim you can make without running these tests against that provider directly and looking at what actually comes back. What I can say from an operator’s seat is that running exit infrastructure costs money, in bandwidth, in IP acquisition, in maintenance. A proxy that’s offered for free, especially from an anonymous list with no support channel and no business behind it, has to be funded somehow. Sometimes that’s ad injection. Sometimes it’s traffic logging sold on. Sometimes it’s genuinely a hobby project with no bad intent. You can’t tell which from the price alone, which is exactly why the certificate check and the canary test exist: they measure behavior, not reputation.
If you find one logging your traffic
Stop routing anything through it immediately. Rotate any credentials, API keys, cookies, or session tokens that went through that proxy while you were using it, treat them as compromised rather than possibly compromised. If you were testing this on a proxy tied to a paid account, that’s useful evidence to bring to the provider or to stop paying them, but the technical fix on your end is the same either way: assume exposure and rotate.
None of these tests guarantee a clean bill of health for a proxy that passes them, and none of them are a substitute for controlling your own exit infrastructure when the traffic actually matters. They’re the checks I’d run before trusting a new proxy with anything beyond throwaway requests, and they’re grounded in how the protocols actually work rather than in trusting a vendor’s marketing page.
If you’re building out proxy-based scraping and want the rest of the operational picture, from choosing between residential, mobile, and datacenter proxies to running rotation without tripping rate limits, head back to the homepage for the full set of guides.
Get new guides and videos first — join the Telegram channel.