89 Kilobit über Glasfaser: Was Telekom-Kunden sehen, wenn Ihre Website hinter Cloudflare steht
Bekanntes Problem. Gibt es seit Jahren. Telekom und Vodafone bedienen laut dslweb.de Breitband-Report (Q3 2025) zusammen rund 80% der deutschen Festnetzanschlüsse – und bei beiden kommt Cloudflare-Traffic nur eingeschränkt an.
Was das für Ihre Website bedeutet
Egal wie schnell Ihr Server ist, egal wie optimiert Ihre Seite — wenn Besucher Telekom- oder Vodafone-Kunden sind und Ihre Site hinter einem kostenlosen Cloudflare-Account steht, ist die User Experience derzeit massiv beeinträchtigt. Nutzer berichten in Foren und sozialen Medien von Ladezeiten im zweistelligen Sekundenbereich – bei Paketverlust von über 19% im Free-Plan wenig überraschend.
Für E-Commerce-Shops bedeutet das verlorene Conversions und abgebrochene Warenkörbe. Für Lead-Generierung: Besucher, die abspringen bevor das Formular geladen hat. Für SaaS: Nutzer, die Ihren Support anrufen weil die App „kaputt" ist. Google Core Web Vitals registrieren das — mit Auswirkungen auf das Ranking.
Das ist kein Einzelfall und kein temporäres Problem. Es ist strukturell, seit Jahren bekannt, und hat sich Ende 2025 verschlechtert als Vodafone nachzog. Die technischen Hintergründe folgen unten — wer direkt zur Lösung will:
→ Direkt zu den Handlungsoptionen springen
Wer betroffen ist
Laut W3Techs (Stand Februar 2026) nutzen rund 20% aller Websites weltweit Cloudflare als Reverse Proxy. Unter den Websites, die überhaupt einen CDN- oder Reverse-Proxy-Dienst einsetzen, liegt Cloudflares Marktanteil bei knapp 80%. Fast die Hälfte der meistbesuchten eine Million Websites steht hinter Cloudflare. Rund 42 Millionen Websites nutzen den Dienst – davon haben laut Cloudflare Q2-2025-Finanzbericht nur rund 266.000 einen kostenpflichtigen Account. Der Rest, über 99%, läuft auf dem kostenlosen Plan.
Auf der anderen Seite: Telekom und Vodafone bedienen laut dslweb.de Breitband-Report (Q3 2025) zusammen rund 80% der deutschen Festnetzanschlüsse. Bei beiden kommt Cloudflare-Traffic nur eingeschränkt an.
Stand Februar 2026: Ein Fünftel des Internets hängt an Cloudflare. 80% der deutschen Festnetzanschlüsse hängen an zwei ISPs mit restriktivem Peering. Die Schnittmenge ist das Problem.
Was technisch passiert
Die Deutsche Telekom betreibt mit AS3320 eines der größten IP-Backbones der Welt. Cloudflare betreibt mit AS13335 das weltweit größte Reverse-Proxy-Netzwerk. Beide sind am DE-CIX in Frankfurt physisch präsent – dem größten Internetknoten der Welt.
Bei direktem Peering am selben Internet-Exchange liegt die Latenz unter 1 ms – oft bei Bruchteilen einer Millisekunde. Das ist der Standard, den jedes andere relevante Netzwerk am DE-CIX liefert.
Stattdessen passiert Folgendes: Die Telekom und Cloudflare haben kein settlement-free Peering am DE-CIX vereinbart – obwohl beide dort Ports haben. Die Telekom fordert Peering-Gebühren, Cloudflare lehnt ab. Traffic von Telekom-Kunden zu Cloudflare-Websites muss deshalb über Drittanbieter laufen – typischerweise GTT (AS3257) oder Telia (AS1299). Diese Transit-Wege sind zu Stoßzeiten regelmäßig überlastet.
Das Ergebnis: Statt unter 1 ms Latenz messen Telekom-Nutzer 150–260 ms zu Cloudflare. Paketverluste von über 30%. Download-Raten, die in den Kilobit-Bereich fallen. Bei kostenlosen Cloudflare-Accounts geht Cloudflare noch einen Schritt weiter: Traffic wird aktiv zum PoP in Newark, New Jersey (USA) umgeleitet – über den Atlantik und zurück. Ob bewusste Routing-Entscheidung oder technische Konsequenz der IP-Block-Zuweisung – das Ergebnis für Endnutzer ist dasselbe.
Zum Vergleich: Über Netzwerke mit offenem DE-CIX-Peering landen dieselben Cloudflare-Websites sofort in Frankfurt (FRA) – mit unter 2 ms Latenz und voller Geschwindigkeit. Das gilt für O2/Telefonica (AS6805), 1&1 Versatel (AS8881) und kleinere Carrier wie Zero Services (AS215197).
Die Telekom-Peering-Politik
Die Telekom-Position: Cloudflare liefert riesige Datenmengen ins Netz, dafür soll Cloudflare zahlen. Die Gegenposition: Telekom-Kunden zahlen monatlich für Internetzugang und fordern diese Daten an – die Telekom kassiert also doppelt. Kritiker nennen das Double-Dipping.
Die Koalition Netzbremse – Epicenter.works, Gesellschaft für Freiheitsrechte, Verbraucherzentrale Bundesverband und Prof. Barbara van Schewick (Stanford CIS) – hat im April 2025 formell Beschwerde bei der Bundesnetzagentur eingereicht. CISPE berichtete, dass ihre Mitglieder seit mindestens 2015 mit Qualitätseinbußen in Deutschland konfrontiert seien.
Vodafone zieht nach
Im November 2025 hat Vodafone Deutschland alle öffentlichen Internet-Exchanges verlassen – inklusive DE-CIX Frankfurt. Innerhalb von Tagen berichteten Vodafone-Kunden von massiven Einbrüchen: GitHub-Downloads unter 200 KB/s statt 67 MB/s, Steam und PyPI abends kaum nutzbar, Telegram-Videos brechen ein. Per VPN sofort volle Geschwindigkeit – der Beweis, dass das Problem am Peering liegt, nicht an der Leitung.
Chronologie
Free vs. Pro: Routing nach Preisklasse
Eine technische Analyse von Felix Wotschofsky untersuchte 6.527 Cloudflare-IP-Adressen: Sämtlicher Telekom-Traffic zu Free-Plan-Websites ging zum PoP in Newark (USA). Nicht Frankfurt, nicht Amsterdam. Nutzer im Cloudflare-Forum dokumentieren: Free-Plan = 19,2% Paketverlust, Pro-Plan = 0,0%. Cloudflare bestätigt: Je höher der Plan, desto besser das ISP-Peering.
Nachprüfbar über den cf-ray-Header in jeder HTTP-Antwort:
curl -sI https://ihre-website.com | grep cf-rayDie letzten drei Buchstaben zeigen den Standort: FRA = Frankfurt, AMS = Amsterdam, LHR = London, EWR = Newark (USA). Unsere Stichprobe vom 19. Februar 2026 – Telekom-FTTH (AS3320), Rhein-Main-Gebiet:
# Telekom-Festnetz (AS3320), 19.02.2026, 11:00 Uhr
# Free-Plan-Domains (gemeinsame IPs 188.114.96.3 / 188.114.97.3):
danluu.com → cf-ray: ...-LHR (London)
marco.org → cf-ray: ...-LHR
simonwillison.net → cf-ray: ...-LHR
jacobian.org → cf-ray: ...-LHR
alpinejs.dev → cf-ray: ...-LHR
wsky.dev → cf-ray: ...-LHR
# Pro-Plan-Domains (individuelle IPs 104.26.x.x / 172.67.x.x):
gerfficient.com → cf-ray: ...-AMS (Amsterdam)
js.org → cf-ray: ...-AMS
tailwindcss.com → cf-ray: ...-AMS
# Zum Vergleich – Anschluss mit DE-CIX-Peering (AS215197):
danluu.com → cf-ray: ...-FRA (Frankfurt)
gerfficient.com → cf-ray: ...-FRAFree und Pro werden über Telekom auf unterschiedliche PoPs geroutet – keiner davon Frankfurt, obwohl der Anschluss 20 km vom DE-CIX entfernt liegt. In den Abendstunden (19–22 Uhr) wurde wiederholt EWR (Newark) beobachtet. Seit dem 16. Februar 2026 meldet Cloudflare erhöhte Latenzen im Newark-Rechenzentrum – dem PoP, über den deutscher Free-Plan-Traffic läuft.
Was die Cloudflare-Pläne kosten
Preise laut Cloudflare Pricing-Seite (Stand Februar 2026), pro Domain:
| Plan | Preis/Monat | Routing für Telekom-Nutzer |
|---|---|---|
| Free | $0 | Nicht-lokaler PoP (Newark/London) – kein Frankfurt |
| Pro | $20 | Europa (Amsterdam/Frankfurt) – anderer IP-Block, andere Route |
| Business | $200 | Europa – priorisiertes Routing |
| Enterprise | auf Anfrage | Dedizierte Routen, SLA |
Was IP-Transit wirklich kostet
Um die Peering-Debatte einordnen zu können, helfen die Marktzahlen. IP-Transit hat sich massiv verbilligt:
| Anbieter | Preis/Mbps | Anmerkung |
|---|---|---|
| Tier-1-Carrier (GTT, Telia, Cogent, Lumen) | 0,03–0,40€ | Bei 100 GigE+ Commitments teils unter 0,05€/Mbps |
| Telekom (laut Branchenberichten) | Deutlich über Markt | Die Koalition Netzbremse spricht von „einem Mehrfachen des marktüblichen Niveaus“ |
Im Rechtsstreit Meta vs. Telekom (LG Köln, Mai 2024) zahlte Meta rund 6 Mio. Euro jährlich für 24 private Interconnection-Punkte mit 5.000 Gbps Kapazität. Als die Telekom bei der Vertragsverlängerung nur 16% Rabatt anbot, kündigte Meta die direkte Verbindung komplett.
Andere deutsche ISPs – O2, 1&1, NetCologne – bauen Peering-Kapazitäten bei Engpässen ohne zusätzliche Gebühren aus. Das ist internationaler Standard. Peering am gleichen Internet-Exchange verursacht reale Kosten: IXP-Portgebühren, Router-Hardware, Co-Location, Strom. Aber keine Per-Mbps-Gebühren an den Partner. Dass ein ISP darüber hinaus vom Gegenüber kassieren will, ist die Ausnahme – nicht die Regel.
Bei Private Peering – direkten physischen Verbindungen für extrem große Datenmengen – zahlen beide Seiten ihre eigene Hardware und Co-Location. Wenn ein Teilnehmer darüber hinaus einseitig Zahlung verlangt, verlässt man klassisches Peering und betritt das Terrain des bezahlten Transits – mit dem Unterschied, dass der Preis von einer marktdominanten Partei diktiert wird.
Was Website-Betreiber jetzt tun können
Option 1: Cloudflare-Upgrade auf Pro ($20/Monat)
Neue IP-Adressen, Traffic wird nach Europa geroutet. Innerhalb von Minuten spürbar. Aber: Sie bleiben abhängig von Cloudflares Verfügbarkeit – allein 2025 gab es fünf größere Ausfälle, darunter ein 6-Stunden-Ausfall im November (X, ChatGPT, Spotify nicht erreichbar) und ein weiterer 17 Tage später (LinkedIn, Zoom, Discord betroffen). Und als US-Unternehmen unterliegt Cloudflare FISA 702 und EO 12333 – die Rechtsgrundlage für US-Datentransfers (EU-US Data Privacy Framework) wird von NOYB und beim EuGH angefochten.
Option 2: CDN-Anbieter evaluieren
Wer ohnehin wechseln will, sollte auf drei Dinge achten: Eigenes Peering an den relevanten IXPs (nicht nur Transit-abhängig), Anycast-Architektur mit europäischen PoPs, und Jurisdiktion. Fastly-gehostete Dienste sind seit Vodafones IXP-Austritt im November 2025 ebenfalls betroffen (GitHub, Steam, PyPI) – ein CDN-Wechsel allein löst das Problem nicht, wenn der neue Anbieter dieselbe Transit-Abhängigkeit hat.
DSGVO-Risiko nicht unterschätzen: Im Free-Plan werden Telekom-Nutzer über US-Infrastruktur geroutet – IP-Adressen, Cookies, Session-Tokens durchlaufen amerikanische Server. Cloudflare bietet Data Localization nur für zahlende Kunden. Die portugiesische Datenschutzbehörde verurteilte 2022 das nationale Statistikinstitut INE zu 4,3 Mio. Euro – wegen Datentransfers über Cloudflare in die USA. Europäische Anbieter mit eigenem Backbone und DE-CIX-Peering umgehen dieses Problem strukturell – Daten bleiben in Europa, Peering-Streitigkeiten zwischen US-Konzernen und deutschen ISPs sind irrelevant.
Wir betreiben selbst ein europäisches Anycast-Netzwerk auf AS215197 mit direktem DE-CIX-Peering und Tier-2-Upstreams an jedem Standort. Bei Fragen zur Umsetzung oder einem Vergleich mit der bestehenden Infrastruktur: gerne melden.