Warum sagt das Ergebnis "wahrscheinlich" statt "sicher"?

**Die Confidence spiegelt, wie viele unabhaengige Quellen uebereinstimmen.** "Sicher" braucht ein eindeutiges Signal: einen `CF-Ray`-Header (nur Cloudflare sendet ihn), ein `X-Amz-Cf-Id` (nur CloudFront), ein `X-Vercel-Id` (nur Vercel). **"Wahrscheinlich"** bedeutet eine starke Quelle, z. B. ein IP-Range-Match gegen `104.16.0.0/12` oder einen Server: cloudflare Header. **"Moeglich"** ist ein schwacher Hinweis, z. B. eine Server: nginx Zeile, die von jedem stammen koennte, der nginx betreibt. Das Label ist bewusst konservativ, keine falschen Versprechen.

Kann Cloudflare den Origin-Server wirklich verstecken?

**Ja, das ist der ganze Sinn** von Cloudflare im Proxy-Modus. Wenn der DNS-Record **orange wolkig** geschaltet ist, loest dein A-Record auf eine Cloudflare-IP auf (104.16.x.x oder 172.64.x.x), nicht auf deinen echten Server. Besucher reden mit Cloudflare, Cloudflare redet ueber einen Backchannel mit deinem Origin. **Wir haben keine Moeglichkeit, den echten Origin** aus einem oeffentlichen Detektor heraus aufzudecken, das wuerde den Schutz aushebeln. Typische Leaks (nicht-proxied Subdomain-DNS, alte SPF-Records, Mailserver-IPs) brauchen dedizierte OSINT, nicht dieses Tool.

Was ist ein WAF und warum ist die Confidence oft "wahrscheinlich"?

Ein **WAF (Web Application Firewall)** filtert HTTP-Traffic, bevor er deine App erreicht, und blockiert SQL-Injection, XSS, verdaechtige Bot-Muster. **Cloudflare WAF**, **AWS WAF**, **Imperva Incapsula**, **Sucuri**, **Akamai Kona** sind die grossen Namen. Die Erkennung ist selten "sicher", weil WAFs ueblicherweise **standardmaessig still** sind, sie senden nur dann verraeterische Header (`X-Sucuri-Id`, `X-Iinfo`, `__cf_bm`-Cookie), wenn eine Regel greift oder Bot-Management aktiv ist. Ein passiver Scan der Homepage provoziert das nicht zwingend, daher schreiben wir "wahrscheinlich WAF hinter Cloudflare" statt "100 % bestaetigt".

Wie funktioniert die Erkennung unter der Haube?

Vier parallele Checks gegen die Ziel-Domain: (1) **DoH (DNS over HTTPS)** zu Cloudflare 1.1.1.1, holt A- und NS-Records, (2) ein **HTTPS GET** auf den Root-Pfad mit einem Chrome-User-Agent, liest die Response-Header (CF-Ray, X-Amz-Cf-Id, Server, Via, X-Cdn, X-Powered-By, Set-Cookie-Muster), (3) ein **CIDR-Match** des A-Records gegen eingebettete Ranges der grossen CDNs, (4) ein **TLS-Handshake**, um den Zertifikatsaussteller auszulesen (Cloudflare Inc ECC CA-3 -> Cloudflare, Amazon -> AWS). Die Signale werden dann zusammengefuehrt: Einigkeit erhoeht die Confidence, Konflikte behalten die staerkere Quelle.

Warum erscheint Googles Site manchmal als "Cloudflare DNS"?

Weil **DNS-Provider und Hosting unabhaengig sind**. Du kannst Cloudflare DNS aus Komfort am Dashboard betreiben und gleichzeitig auf Google, AWS oder sonst wo hosten. Genauso ist eine Domain mit **Route-53-NS-Records** zwar AWS fuer DNS, kann aber durchaus hinter einer Vercel-Edge sitzen. Der Detektor meldet jede Schicht separat. Wenn du "DNS: Cloudflare, Hosting: AWS, CDN: CloudFront" siehst, ist das voellig in Ordnung, kein Widerspruch.

Warum zeigt GitHub Pages "GitHub Pages" als Hosting und "Fastly" als CDN?

Weil **das die Wahrheit ist**. GitHub Pages liefert dein Repo aus der GitHub-Infrastruktur aus, leitet den Traffic aber ueber **Fastly** als oeffentlich sichtbares CDN. Der Server-Header zeigt `GitHub.com`, der Via-Header verraet `varnish`, und die IP gehoert in den Fastly-Bereich. Dasselbe bei Shopify (Cloudflare ueber ihrer eigenen Infrastruktur), Netlify (Netlify Edge), Vercel (Vercel Edge Network). **Eine Schicht ist der Origin, die andere ist der Cache.**

Gibt es False Positives, die ich kennen sollte?

**Ja, einige typische.** (1) Der Server-Header ist **vom Anbieter kontrolliert**, eine Seite kann ihn als "nginx" faelschen, waehrend Apache laeuft, oder ihn komplett entfernen. (2) **Lets Encrypt** als TLS-Issuer sagt nichts ueber das Hosting aus (jeder kann es nutzen), daher klassifizieren wir Hosting nie rein aus einem Lets-Encrypt-Zertifikat. (3) IP-Range-Tabellen veralten: ein frisch gestarteter CDN-POP steht moeglicherweise nicht in unserer eingebetteten Liste, was zu "moeglich" statt "wahrscheinlich" fuehrt. (4) Seiten, die **auf eine andere Domain umleiten** (z. B. `example.com` -> `www.example.com`), werden einmal verfolgt, die finale Erkennung spiegelt also das Ziel, nicht den urspruenglichen Einstieg.

Funktioniert das fuer jede TLD oder nur fuer Mainstream-Domains?

**Jede TLD, die ueber oeffentliches DNS aufloest**, funktioniert: `.com`, `.dev`, `.io`, `.co.uk`, `.de`, moderne `.app`, `.cloud`. Wir blockieren **intern aussehende Suffixe** (`.local`, `.internal`, `.lan`, `.intranet`, `.corp`, `.home`, `.localhost`) als SSRF-Schutz, unser Server soll nicht das private Netzwerk von jemandem absondieren. Literale IPs werden ebenfalls abgewiesen: nutze eine Domain.

Wird die Anfrage geloggt?

**Nein.** Die Route laeuft im Node.js-Memory: sie holt DoH, ruft die Startseite ab, oeffnet einen TLS-Handshake und gibt das Ergebnis zurueck. Das Rate-Limiting (30 Requests pro Stunde pro IP) ist eine In-Memory-Map, die bei jedem Cold-Start zurueckgesetzt wird. **Nichts wird auf Disk oder in einer Datenbank persistiert.** Deine Anfragen sind keinem Account zugeordnet, weil es keinen Account gibt.

Cloud / CDN Detektor - kostenlos

Was dieser Detektor leistet

Dieses Tool zeigt dir, wer eine Website tatsaechlich betreibt: das Hosting (Origin-Server), das CDN davor, den DNS-Provider und einen wahrscheinlichen WAF (Web Application Firewall). Du gibst eine Domain ein, unser Server kombiniert vier unabhaengige Erkennungsquellen, und du bekommst ein einziges Panel mit einer Confidence-Angabe neben jedem Ergebnis.

Die genutzten Quellen: NS-Records ueber DNS over HTTPS, die HTTP-Response-Header der Live-Seite, die A-Record-IP abgeglichen mit bekannten CDN-Bereichen (Cloudflare, CloudFront, Fastly, Vercel) und der TLS-Zertifikatsaussteller. Wenn mehrere Quellen uebereinstimmen, springt die Confidence von "wahrscheinlich" auf "sicher".

So benutzt du es

Domain eingeben: nur der Hostname, kein Schema, kein Pfad. `vercel.com` funktioniert, `https://vercel.com/pricing` wird automatisch bereinigt.
Detect klicken. Der Server fuehrt vier parallele Checks mit einem 10-Sekunden-Budget aus.
Die vier Karten lesen: Hosting, CDN, DNS-Provider, WAF. Jede traegt eine Confidence: sicher (mehrere Quellen einig), wahrscheinlich (ein starkes Signal), moeglich (nur schwacher Hinweis).
Den Raw signals-Block oeffnen, um A- und NS-Records, Server-Header, Via-Header und TLS-Issuer zu sehen, die in die Erkennung eingeflossen sind.
Die Evidence-Liste oeffnen, um das genaue Tag zu sehen, das jedes Ergebnis ausgeloest hat, z. B. `CF-Ray: 7f...` oder `104.16.x.x in 104.16.0.0/12 (Cloudflare)`.
Die Beispiel-Chips ausprobieren (vercel.com, github.com, cloudflare.com, shopify.com), um zu sehen, wie ein sauberes Vercel-Deployment, eine GitHub-Pages-Seite, eine Cloudflare-gefrontete Seite und ein Shopify-Store jeweils unterschiedlich erscheinen.

Wann das nuetzlich ist

Konkrete Szenarien, in denen dieser Detektor seinen Platz verdient:

Wettbewerbsrecherche vor einem Infrastruktur-Pitch: sehen, ob dein Interessent Cloudflare davor, CloudFront oder einen nackten Origin laufen hat, an den du ein CDN verkaufen kannst.
Anbieter-Verifizierung, wenn eine Agentur dir sagt "wir hosten auf AWS": der TLS-Issuer plus die IP-Range bestaetigen oder widerlegen die Behauptung.
Incident Response bei einem Ausfall: ist der Origin down oder nur das CDN? Den Provider zu kennen sagt dir, welche Status-Page du oeffnen musst (status.cloudflare.com vs health.aws.amazon.com).
Migrationsplanung: bevor du DNS von Route 53 zu Cloudflare verschiebst, willst du einen Baseline-Stand der bisherigen Provider ueber jede Subdomain hinweg.
Security-Audits: bestaetigen, dass der WAF, den der Kunde zu haben behauptet ("wir nutzen Cloudflare"), tatsaechlich auf dem oeffentlichen Hostname Traffic ausliefert und nicht durch eine geleakte Origin-IP umgangen wird.
Preis-Argumentation: zu wissen, ob ein Wettbewerber auf Vercel vs AWS vs einem nackten VPS laeuft, hilft dir, das Gespraech um Kosten und Skalierung herum zu strukturieren.

Fragen und Antworten

Ein CDN (Content Delivery Network) ist ein globaler Cache zwischen deinen Besuchern und deinem Origin-Server. Beispiele: Cloudflare, AWS CloudFront, Fastly, Akamai, Vercel Edge Network. Die Erkennung ist wichtig, weil: (1) die oeffentliche IP der Seite die CDN-Edge ist, nicht dein echter Server, (2) die TLS-Terminierung an der Edge passiert, das sichtbare Zertifikat also dem CDN gehoert, (3) Caching-Regeln und WAF-Schutz am CDN sitzen, nicht am Origin. Ohne CDN-Check weisst du nicht, wo du eine 503 oder einen langsamen First Byte debuggen sollst.

Was dieser Detektor leistet

So benutzt du es

Domain eingeben: nur der Hostname, kein Schema, kein Pfad. `vercel.com` funktioniert, `https://vercel.com/pricing` wird automatisch bereinigt.

Detect klicken. Der Server fuehrt vier parallele Checks mit einem 10-Sekunden-Budget aus.

Die vier Karten lesen: Hosting, CDN, DNS-Provider, WAF. Jede traegt eine Confidence: sicher (mehrere Quellen einig), wahrscheinlich (ein starkes Signal), moeglich (nur schwacher Hinweis).

Den Raw signals-Block oeffnen, um A- und NS-Records, Server-Header, Via-Header und TLS-Issuer zu sehen, die in die Erkennung eingeflossen sind.

Die Evidence-Liste oeffnen, um das genaue Tag zu sehen, das jedes Ergebnis ausgeloest hat, z. B. `CF-Ray: 7f...` oder `104.16.x.x in 104.16.0.0/12 (Cloudflare)`.

Die Beispiel-Chips ausprobieren (vercel.com, github.com, cloudflare.com, shopify.com), um zu sehen, wie ein sauberes Vercel-Deployment, eine GitHub-Pages-Seite, eine Cloudflare-gefrontete Seite und ein Shopify-Store jeweils unterschiedlich erscheinen.

Wann das nuetzlich ist

Konkrete Szenarien, in denen dieser Detektor seinen Platz verdient:

Wettbewerbsrecherche vor einem Infrastruktur-Pitch: sehen, ob dein Interessent Cloudflare davor, CloudFront oder einen nackten Origin laufen hat, an den du ein CDN verkaufen kannst.
Anbieter-Verifizierung, wenn eine Agentur dir sagt "wir hosten auf AWS": der TLS-Issuer plus die IP-Range bestaetigen oder widerlegen die Behauptung.
Incident Response bei einem Ausfall: ist der Origin down oder nur das CDN? Den Provider zu kennen sagt dir, welche Status-Page du oeffnen musst (status.cloudflare.com vs health.aws.amazon.com).
Migrationsplanung: bevor du DNS von Route 53 zu Cloudflare verschiebst, willst du einen Baseline-Stand der bisherigen Provider ueber jede Subdomain hinweg.
Security-Audits: bestaetigen, dass der WAF, den der Kunde zu haben behauptet ("wir nutzen Cloudflare"), tatsaechlich auf dem oeffentlichen Hostname Traffic ausliefert und nicht durch eine geleakte Origin-IP umgangen wird.
Preis-Argumentation: zu wissen, ob ein Wettbewerber auf Vercel vs AWS vs einem nackten VPS laeuft, hilft dir, das Gespraech um Kosten und Skalierung herum zu strukturieren.

Fragen und Antworten

Cloud / CDN Detektor

Was dieser Detektor leistet

So benutzt du es

Wann das nuetzlich ist

Fragen und Antworten

Passende Tools

DNS-Lookup

SSL-Zertifikat-Inspector

WHOIS-Lookup

HTTP-Header Inspector

IP-Info / ASN-Lookup

Cloud / CDN Detektor

Was dieser Detektor leistet

So benutzt du es

Wann das nuetzlich ist

Fragen und Antworten

Passende Tools

DNS-Lookup

SSL-Zertifikat-Inspector

WHOIS-Lookup

HTTP-Header Inspector

IP-Info / ASN-Lookup