Our free SSL/TLS Proxy Detector identifies CDN and proxy servers in your SSL connection path. Detects Cloudflare, Akamai, CloudFront, Fastly, and other reverse proxies by analyzing response headers, TLS fingerprints, and connection metadata.
How to Use
Enter the domain name to check for proxy or CDN services
Click "Run" to detect any proxy servers in the connection path
Review the detected proxy provider and connection metadata
Use Cases
•Identifying CDN providers protecting your target domains
•Traffic routing analysis for network troubleshooting
•Discovering origin server IP addresses behind reverse proxies
Frequently Asked Questions
The tool detects major CDN providers including Cloudflare, Akamai, Amazon CloudFront, Fastly, Google Cloud CDN, StackPath, and many others. Detection is based on response header signatures and TLS fingerprint analysis.
Reverse proxies terminate SSL connections and establish new ones to the origin server. This means the proxy holds the SSL certificate, which can affect certificate transparency, HSTS, and end-to-end security guarantees.
Knowing whether a domain is behind a CDN or proxy is important for security assessments, troubleshooting SSL issues, understanding traffic routing, and ensuring that security policies like HSTS and certificate pinning are properly configured.
Because it changes where the problems live. The certificate a visitor sees is the CDN's, the TLS is terminated at the edge, and the headers are set at the edge rather than by your application. So a configuration fix you make on the origin may have no effect until it is also made in the CDN's control panel, and a certificate problem may be resolved at the edge without your server changing at all. Knowing the layering is what tells you which system to go and change.
Yes, and that is worth knowing before treating a negative result as a finding. Anyone controlling the network path can strip identifying headers as easily as they can add them, and a deliberate intermediary has no reason to advertise itself. What is far harder to hide is the behaviour: certificate details that do not match the issuer, protocol behaviour, or timing characteristics all betray an interception even when the headers are clean.
Only if it terminates and re-encrypts, which is the normal case for a CDN but not for a layer that only forwards. The distinction matters because termination means the edge holds both halves of the connection: it is the certificate holder for the visitor and a client for you, and it sees your traffic in the clear in between. That is a legitimate and common design with well-understood risk, but it should be a decision rather than something discovered later.
Because the certificate belongs to the edge, not to your origin. The names, issuer and expiry you see belong to whoever terminates TLS, and they can differ from the certificate installed on your server — which may be expired, self-signed, or entirely absent. This regularly surprises people who inspect their origin directly, find a problem, and do not understand why the public site looks fine. Comparing what the edge presents with what the origin holds is a worthwhile check.
The major ones are, because each publishes a characteristic signature and other people depend on it. The long tail is not: a provider can change or drop a header between versions, and any product can add one at any time. Treat a detection as a prompt to look, not as a precise fingerprint of which product and version is in the path. If you need certainty about what is in front of you, the transport-layer evidence is stronger than anything a header can tell you.
How the Detection Works
Every reverse proxy and CDN leaves evidence in the response headers it adds, because something has to identify it to caches, clients and operators.
1Request the page over HTTPS and read the response headers as they arrive, without following the page into an asset that might be served from somewhere else.
2Match them against known provider headers, which are distinct enough to be reliable: the major CDNs and managed security products each publish a characteristic signature.
3List what was found, naming each header rather than reporting a bare yes or no, so you know which layer is involved.
Headers are trivially removed or forged by whoever sits in front of your server, so a negative result means nothing was disclosed rather than nothing is present. It is a useful signal, not a security control.
Tips & Best Practices
•Detect proxy servers that may affect TLS connection security
