Astro Cloudflare-Deployment: Kompletter Leitfaden – SSR-Konfiguration + 3× schnellerer Zugriff aus China

Letzte Woche habe ich einem Freund beim Deployment seines Astro-Blogs geholfen – und dabei ein interessantes Problem entdeckt. Nach dem Deploy auf Cloudflare Pages lud die Seite im Ausland blitzschnell. Freunde in China warteten fast 5 Sekunden – peinlich.

Cloudflare wirbt mit über 300 Rechenzentren weltweit, kostenlos und ohne Bandbreitenlimit – warum ist der Zugriff aus China so langsam? Viele Entwickler kennen den Begriff „Premium-IP“, sind sich aber unsicher: Wie geht das, gibt es Sperrrisiko, wie gut ist der Effekt wirklich?

In diesem Artikel führen wir Sie durch den kompletten Astro-Cloudflare-Deployment-Prozess – von der statischen Site über SSR bis zur Zugriffsoptimierung aus China. Aus eigener Erfahrung: viele Stolpersteine, hier die zusammengefassten Learnings.

Das lernen Sie:

• In 20 Minuten von null bis Live
• Die drei SSR-Adapter-Modi verstehen
• Drei Optimierungsansätze für den Zugriff aus China – Latenz um das Dreifache reduziert

Los geht’s.

Warum Cloudflare Pages

Cloudflare vs. Vercel: Vergleich kostenloser Hosting-Plattformen

Vercel oder Cloudflare? Kurz gesagt: Es hängt von Ihren Anforderungen ab.

Bandbreitenlimits sind der offensichtlichste Unterschied. Vercel Free: 100 GB/Monat, danach $40 pro 100 GB. Ein virales Projekt kann die Rechnung unerwartet in die Höhe treiben. Cloudflare Pages: unbegrenzte Bandbreite, kostenlos – für Einzelentwickler sehr entlastend.

Globale Performance: Cloudflare hat über 300 Rechenzentren. Tests in Europa, Asien und Amerika zeigen niedrige Latenz. Vercel ist ebenfalls gut, hat aber weniger Knoten – bei weltweit verteilten Nutzern ist Cloudflare oft im Vorteil.

Ein weiterer Pluspunkt: DDoS-Schutz. Im Free-Plan inklusive, ohne Extra-Konfiguration. Bei Angriffen greift Cloudflare automatisch ein. Vercel schützt primär das eigene Netzwerk, nicht Ihre Site in der Tiefe.

Vercel-Stärken: Build-Caching. Bei vielen Bildern und Abhängigkeiten oft nur 3–4 Minuten beim zweiten Build. Cloudflare Pages baut häufig von vorn – 15+ Minuten. Außerdem tiefe Next.js-Integration – für Next.js ist Vercel die beste Wahl.

Meine Empfehlung:

• Statischer Astro-Blog → Cloudflare Pages (großes kostenloses Traffic-Kontingent)
• Unvorhersehbares Traffic-Volumen → Cloudflare Pages (keine Überraschungsrechnung)
• Next.js-Power-User → Vercel (beste Erfahrung)
• Häufige Builds, schnelle Iteration → Vercel (schnelles Build-Caching)

Cloudflare Pages vs. Workers: Neuerungen 2025

Anfangs verwirrend: Cloudflare hat Pages und Workers – beide für Astro. Was wählen?

Kernunterschied: Workers ist die serverlose Edge-Plattform für JavaScript. Pages ist Workers + automatisiertes Build-Tooling. Pages läuft auf Workers, bietet Git-Integration und Auto-Deploy out of the box.

2025 empfiehlt Cloudflare neue Projekte teils Workers statt Pages – mehr Flexibilität. Für Astro-Nutzer ist das weniger kritisch.

Praxiserfahrung:

• Pages: GitHub verbinden, Push triggert Build – einfach. Für „schnell deployen, nichts Kompliziertes“.
• Workers: Wrangler CLI, wrangler.jsonc – feinere Kontrolle über Env-Vars, KV-Bindings.

Für Astro-Projekte:

• Rein statisch (output: 'static'): Pages + GitHub über Dashboard
• SSR (output: 'server' oder 'hybrid'): Beides möglich; Pages + Wrangler CLI empfohlen

Erstes Deployment: Pages Git-Integration – in Minuten live. Wrangler später, wenn nötig.

Astro Cloudflare: Kompletter Deployment-Ablauf

Statische Site deployen: 5-Minuten-Schnellstart

Bei rein statischen Astro-Projekten (Blog, Docs, Portfolio) ist das Deployment sehr einfach.

Voraussetzungen:

• Projekt auf GitHub
• Cloudflare-Konto (kostenlose Registrierung)

Schritte:

1. Cloudflare Dashboard öffnen
   dash.cloudflare.com → links Workers & Pages.

2. Neues Projekt erstellen
   Oben rechts Create application → Pages → Connect to Git.

3. GitHub-Repository verbinden
   Astro-Projekt auswählen. Beim ersten Mal Cloudflare-Zugriff auf GitHub autorisieren.

4. Build-Einstellungen
   Wichtig – falsche Werte führen zu Fehlern:

   • Framework preset: Astro (füllt Befehle automatisch)
   • Build command: npm run build
   • Build output directory: dist
   • Root directory: leer lassen oder Unterverzeichnis angeben

5. Deploy starten
   Save and Deploy – Cloudflare pullt Code, installiert Abhängigkeiten, baut und deployt.

Nach erfolgreichem Build erhalten Sie your-project.pages.dev. Jeder Push zu GitHub triggert automatisch einen neuen Build.

Häufige Probleme:

• Build-Fehler wegen Node.js-Version: .nvmrc oder .node-version mit 18 oder 20 im Projektroot.
• 404: Build output directory prüfen – oft dist, manchmal public oder build laut astro.config.mjs.
• Build-Timeout: Abhängigkeiten oder Netzwerk – erneut deployen, oft beim zweiten Versuch erfolgreich.

Eigene Domain binden (optional):

Unter Custom domains → Set up a custom domain, z. B. blog.yourdomain.com. Cloudflare liefert einen CNAME-Eintrag für Ihren DNS-Anbieter. Liegt die Domain bereits bei Cloudflare DNS, erfolgt die Konfiguration automatisch.

SSR-Site deployen: @astrojs/cloudflare Adapter im Detail

SSR wirkt anfangs komplex – die offizielle Doku ist verteilt. Hier der praktische Ablauf.

Wann brauchen Sie SSR?

• Echtzeitdaten: Kommentare, Statistiken, Login
• Server-Logik: API-Aufrufe, DB-Abfragen, Berechtigungen
• On-Demand-Rendering: Sehr große Inhaltsmengen ohne vollständiges Pre-Rendering

Reiner Markdown-Blog? Statisches Deployment reicht.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Schritt 1: @astrojs/cloudflare installieren

Im Projektroot:

npx astro add cloudflare

Das Kommando:

1. Installiert @astrojs/cloudflare
2. Passt astro.config.mjs an
3. Erstellt wrangler.jsonc

Danach sieht astro.config.mjs etwa so aus:

import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  output: 'server', // neu hinzugefügt
  adapter: cloudflare(),
});

Schritt 2: Rendering-Modus wählen (wichtig!)

Drei Optionen – hier die Erklärung:

1. output: 'server' – Vollständiges SSR

• Alle Seiten serverseitig gerendert
• Für datengetriebene Apps, häufig aktualisierte Inhalte
• Nachteil: Jeder Request rendert neu – etwas langsamer

2. output: 'hybrid' – Hybrid-Modus (empfohlen)

• Standard: statische Seiten
• Einzelne Seiten optional SSR
• Für Blogs mit wenigen dynamischen Features
• Vorteil: Maximale Flexibilität und Performance

3. output: 'static' – Rein statisch

• Kein Adapter nötig – statisches Deployment wie oben

Empfehlung: In 90 % der Fälle hybrid, außer Sie brauchen durchgängig SSR.

Hybrid-Beispiel:

// astro.config.mjs
export default defineConfig({
  output: 'hybrid', // auf hybrid setzen
  adapter: cloudflare(),
});

Für SSR-Seiten eine Zeile hinzufügen:

// src/pages/api/comments.js
export const prerender = false; // diese Seite wird SSR

export async function GET() {
  // Kommentare aus der Datenbank
  const comments = await fetchComments();
  return new Response(JSON.stringify(comments));
}

Alle anderen Seiten bleiben standardmäßig statisch.

Schritt 3: Cloudflare-Service-Bindings (optional)

Für KV, D1 oder R2 in wrangler.jsonc konfigurieren.

Beispiel KV für User-Sessions:

// wrangler.jsonc
{
  "name": "my-astro-app",
  "compatibility_date": "2024-01-01",
  "kv_namespaces": [
    {
      "binding": "MY_KV",
      "id": "your-kv-namespace-id"
    }
  ]
}

Zuerst KV-Namespace im Cloudflare Dashboard anlegen und ID eintragen.

Im Code:

// src/pages/api/session.js
export const prerender = false;

export async function GET({ locals }) {
  const { MY_KV } = locals.runtime.env;
  const sessionData = await MY_KV.get('user:123');
  return new Response(sessionData);
}

Schritt 4: Lokale Entwicklung und Tests

Wrangler CLI installieren:

npm install wrangler --save-dev

Lokal starten:

npm run build
npx wrangler pages dev ./dist

Simuliert die Cloudflare-Umgebung für SSR und Bindings.

Schritt 5: Live deployen

Variante 1: Wrangler CLI (empfohlen, feinere Kontrolle)

# Bei Cloudflare anmelden
npx wrangler login

# Projekt bauen
npm run build

# Deployen
npx wrangler pages deploy ./dist

Beim ersten Mal Projektnamen eingeben, danach ein Befehl.

Variante 2: Git-Integration

Wie beim statischen Deployment – Cloudflare erkennt @astrojs/cloudflare. KV-Bindings müssen im Dashboard manuell gesetzt werden.

Fehlerbehebung:

1. „Hydration completed but contains mismatches“
   Oft durch Auto Minify, das HTML verändert.
   Lösung: Dashboard → Domain → Speed → Optimization → Auto Minify für HTML, CSS, JS deaktivieren.

2. „Cannot find module ‘MY_KV’“
   Binding in wrangler.jsonc und Code müssen übereinstimmen.

3. 500 nach Deploy
   Dashboard → Workers & Pages → Projekt → Logs prüfen. Oft Zugriff auf ungebundene Ressourcen.

Umgebungsvariablen und Secrets

Env-Vars verwechseln viele – API-Keys gehören nicht ins Git.

Lokale Entwicklung:

.dev.vars im Projektroot:

# .dev.vars
DATABASE_URL=postgres://localhost:5432/mydb
API_KEY=your-secret-key-for-dev

Wichtig: .dev.vars in .gitignore!

Wrangler liest die Datei lokal. Im Code:

export const prerender = false;

export async function GET({ locals }) {
  const apiKey = locals.runtime.env.API_KEY;
  // API_KEY für Drittanbieter-API nutzen
}

Produktion:

Nicht .dev.vars, sondern Cloudflare Dashboard:

1. Workers & Pages → Projekt
2. Settings → Environment Variables
3. Add variable – Name und Wert
4. Umgebung wählen (Production oder Preview)

Sensible Daten als Secrets:

npx wrangler secret put API_KEY

Wert wird interaktiv eingegeben, nicht in der Shell angezeigt.

Empfehlung:

• DB-URL, API-Keys → Secrets
• Öffentliche Config (Site-Name, CDN-URL) → normale Env-Vars

Zugriffsgeschwindigkeit aus China: Praxis

Diagnose: Reale Geschwindigkeit aus China messen

Vor der Optimierung messen. Nicht jede Site braucht es – bei überwiegend internationalen Nutzern reicht die Cloudflare-Standardkonfiguration.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Online-Tools:

1. 17ce.com (empfohlen)
   17ce.com – Domain eingeben, „Website-Geschwindigkeitstest“. Messungen aus verschiedenen Provinzen und Providern. Antwortzeit unter 200 ms ist gut; über 300 ms lohnt Optimierung.

2. Chinaz Speedtest
   tool.chinaz.com/speedtest – ähnlich, detailliertere Routing-Infos.

Lokal testen (wenn Sie in China sind):

Chrome DevTools: F12 → Network → Seite neu laden → Time des ersten Requests.

Richtwerte:

• Latenz < 150 ms: sehr gut, keine Optimierung nötig
• 150–250 ms: akzeptabel, je nach Anspruch
• > 250 ms oder Ladezeit > 3 s: Optimierung empfohlen

Warum ist es in China langsam?

Cloudflare nutzt Anycast; das chinesische Routing ist speziell – Traffic kann Umwege nehmen (z. B. über Hongkong). Premium-IP und CNAME zielen auf direktere Routen.

Ansatz 1: Premium-IP (kostenlos, beste Wirkung)

In Tests Latenz von 280 ms auf ~70 ms. Etwas Aufwand und ein gewisses Risiko – siehe unten.

Was ist Premium-IP?

Cloudflare hat viele IPs für verschiedene Rechenzentren. Der Zugriff aus China variiert stark. Premium-IP bedeutet: schnelle IPs finden und die Domain direkt darauf auflösen.

Schritt 1: Premium-IP testen

Tool CloudflareSpeedTest auf GitHub: XIU2/CloudflareSpeedTest

Windows: CloudflareST.exe, Linux/Mac: entsprechende Version.

# Doppelklick oder Kommandozeile
CloudflareST.exe

Testet hunderte IPs in 5–10 Minuten. Beispielausgabe:

IP-Adresse        Latenz   Download
104.16.160.10     68ms     15.2MB/s
172.64.32.5       75ms     14.8MB/s
104.23.240.28     82ms     13.9MB/s

Erste IP (niedrigste Latenz) notieren.

Schritt 2: DNS anpassen

Voraussetzung: DNS nicht bei Cloudflare, sondern bei anderem Anbieter (Alibaba Cloud, DNSPod usw.). Bei Cloudflare DNS greift Anycast – A-Record-Änderung wirkt nicht.

Konfiguration (Beispiel DNSPod):

1. DNS-Anbieter öffnen

2. A-Record hinzufügen/ändern:

   • Host: @ oder www
   • Typ: A
   • Wert: 104.16.160.10 (Ihre Premium-IP)
   • TTL: 600

3. Speichern, 5–10 Minuten warten

Schritt 3: Wirkung prüfen

Nach DNS-Propagation erneut mit 17ce.com messen.

Risikohinweis:

Seit Januar 2025 verschärfte Cloudflare-ToS zu „Missbrauch“. Premium-IP ist nicht explizit genannt, Risiko besteht.

Empfehlung:

• Persönlicher Blog, kleines Projekt: üblicherweise vertretbar
• Kommerziell, hohes Traffic: vorsichtig – Ansatz 2 oder 3
• Regelmäßig prüfen: IP kann ungültig werden, alle 1–2 Monate neu testen

Häufige Probleme:

1. DNS wirkt nicht

   • Browser-Cache leeren oder Inkognito
   • nslookup yourdomain.com prüfen

2. Premium-IP wird wieder langsam

   • Neue IP testen und DNS aktualisieren

3. Regional unterschiedlich

   • Telekom/Unicom/Mobile haben unterschiedliche optimale IPs – Ansatz 3 hilft

Ansatz 2: Premium-CNAME-Domain (kostenlos, stabiler)

Wenn Sie IPs nicht selbst testen wollen oder diese oft ungültig werden: öffentliche Premium-CNAME-Domains. Hinter ihnen pflegen andere die IPs.

Prinzip:

Entwickler oder Communities betreiben Domains mit regelmäßig aktualisierten Premium-IPs. Ihre Domain CNAME darauf – Beschleunigung ohne eigene IP-Pflege.

Schritt 1: Öffentlichen CNAME wählen

Beispiele (vor Nutzung selbst testen):

• cdn.cloudflare.quest
• cf.xiu2.xyz

Hinweis: Öffentliche CNAMEs können ausfallen – Communities oder Telegram-Gruppen für Updates nutzen.

Schritt 2: DNS anpassen

DNS nicht bei Cloudflare. Beispiel DNSPod:

1. DNS-Anbieter öffnen

2. CNAME-Record:

   • Host: @ oder www
   • Typ: CNAME
   • Wert: cdn.cloudflare.quest
   • TTL: 600

3. Speichern, warten

Schritt 3: Möglichen 403-Fehler beheben

CNAME kann 403 Forbidden auslösen, wenn die Domain nicht in Cloudflare registriert ist, aber über Cloudflare-IPs erreichbar ist.

Lösung:

1. DNS von Cloudflare migrieren (falls noch dort)
2. Site im Cloudflare Dashboard löschen
3. Minuten warten, erneut testen

Schritt 4: Wirkung prüfen

nslookup yourdomain.com – Auflösung auf CNAME prüfen, dann Speedtest.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Vor- und Nachteile:

• Vorteile: kein IP-Test, Wartung durch Dritte, etwas geringeres Risiko als direkte Premium-IP
• Nachteile: Abhängigkeit von Dritten, evtl. langsamer als eigene optimale IP

Empfehlung: Für „Optimierung ohne viel Aufwand“ – gutes Preis-Leistungs-Verhältnis.

Ansatz 3: Regionale DNS-Auflösung (kostenpflichtiger DNS, beste Gesamtwirkung)

Beste Erfahrung, geringe Kosten – für viele Nutzer in China und im Ausland.

Kernidee:

Je nach Region unterschiedliche IPs:

• Telekom China → Telekom-Premium-IP
• Unicom China → Unicom-Premium-IP
• Ausland → Cloudflare-Standard oder your-project.pages.dev

Benötigte Tools:

DNS mit intelligenter Auflösung, z. B.:

• DNSPod (Tencent, Basis-Funktionen im Free-Plan)
• Alibaba Cloud DNS (kostenpflichtig, umfangreich)
• Cloudflare DNS (keine china-spezifischen Leitungen – hier ungeeignet)

Konfiguration (Beispiel DNSPod):

1. Premium-IPs pro Provider testen

   Mit CloudflareSpeedTest in Telekom-, Unicom- und Mobile-Netzen testen. Oder typische Segmente (eigen testen ist genauer):

   • Telekom: 104.16.160.0/24
   • Unicom: 104.23.240.0/24
   • Mobile: 172.64.32.0/24

2. Regionale Records anlegen

   Mehrere A-Records mit unterschiedlicher „Leitung“:

   Record 1:
   - Host: @
   - Typ: A
   - Leitung: Telekom
   - Wert: 104.16.160.10
   
   Record 2:
   - Host: @
   - Typ: A
   - Leitung: Unicom
   - Wert: 104.23.240.5
   
   Record 3:
   - Host: @
   - Typ: A
   - Leitung: Mobile
   - Wert: 172.64.32.8
   
   Record 4 (Standard, Ausland):
   - Host: @
   - Typ: CNAME
   - Leitung: Standard
   - Wert: your-project.pages.dev

3. Speichern, warten

Wirkung:

Inland je Provider optimale Knoten, Ausland natives Cloudflare.

Kosten:

• DNSPod Personal: kostenlos (Basis-Leitungen)
• DNSPod Pro: ~20 Yuan/Monat (feinere Regionen)
• Alibaba Cloud DNS: nach Abfragen, kleine Sites wenige Yuan/Monat

Empfehlung: Ab ~10.000 Besuchen/Monat lohnt sich die Investition deutlich.

Optimierungsvergleich und Monitoring

Vorher/Nachher (Blog-Test, Peking Telekom):

Optimierung bringt 3–5× schnellere Ladezeiten – spürbar bessere UX.

Langzeit-Monitoring:

IPs können ungültig werden – regelmäßig prüfen.

Empfohlene Tools:

1. UptimeRobot (uptimerobot.com)

   • 50 Sites kostenlos
   • Ping alle 5 Minuten, E-Mail bei Ausfall
   • Antwortzeit-Trends

2. Cloudflare Analytics

   • Im Dashboard, kostenlos
   • Herkunft, Bandbreite, Fehlerrate
   • Keine detaillierte China-Latenz

3. Better Uptime (betteruptime.com)

   • Paid mit Free-Tier
   • Öffentliche Statusseite

Wann Premium-IP wechseln:

Alle 1–2 Monate:

1. 17ce.com – Latenz gestiegen?
2. Über 200 ms → CloudflareSpeedTest, neue IP
3. DNS aktualisieren

Erfahrungsgemäß alle 2–3 Monate spürbare Schwankungen – rechtzeitig wechseln.

Fazit

Deployment: Cloudflare Pages für Astro ist einfach. Statisch: GitHub verbinden, Minuten bis live. SSR: npx astro add cloudflare, hybrid oder server – statisch wo möglich, dynamisch wo nötig.

SSR-Kernpunkte:

• 90 % der Fälle: hybrid
• KV/D1/R2 über wrangler.jsonc-Bindings
• Lokal .dev.vars, Produktion im Dashboard
• Hydration-Fehler: Auto Minify deaktivieren

Zugriff aus China:

• Ansatz 1 (Premium-IP): beste Wirkung, kostenlos, Wartung und Risiko
• Ansatz 2 (öffentlicher CNAME): wenig Aufwand, mittlere Wirkung
• Ansatz 3 (regionale Auflösung): beste Gesamterfahrung, geringe Kosten

Empfehlung:

• Persönlicher Blog, wenig Traffic → Ansatz 1 oder 2
• Mehr Traffic, hohe Ansprüche → Ansatz 3
• Kommerziell → Premium-IP vorsichtig, Ansatz 3 bevorzugen

Nächste Schritte:

1. Cloudflare-Konto anlegen, statisches Deployment testen
2. Bei langsamem Zugriff aus China mit 17ce.com messen
3. Nach Optimierung Erinnerung für IP-Checks setzen

Weiterführend:

• Workers KV: Key-Value für Cache, Sessions
• D1: SQLite am Edge
• R2: Objektspeicher, Alternative zu AWS S3
• Pages Functions: Serverless in Pages

Nahtlose Astro-Integration – Schritt für Schritt erkunden.

Hat Ihnen der Artikel geholfen? Teilen Sie Ihre Deployment-Erfahrungen oder Stolpersteine in den Kommentaren.