• HOME
  • Cloudflare für WordPress einrichten: Nameserver, SSL, echte IP, WAF

2026年11月12日

  • シェア
  • ツイート

    • 2026年11月12日

    Cloudflare für WordPress einrichten: Nameserver, SSL, echte IP, WAF

    Dieser Artikel ist eine lokalisierte Fassung des japanischen Originals. Japanisches Original lesen

    Cloudflare für WordPress richten Sie in dieser Reihenfolge ein: ① Website bei Cloudflare hinzufügen und die Nameserver der Domain umstellen, ② den SSL/TLS-Verschlüsselungsmodus auf Full (strict) setzen, ③ die echte IP des Besuchers auf dem Server wiederherstellen, ④ die Login-Seite mit einer benutzerdefinierten WAF-Regel schützen. Auch im kostenlosen Tarif sind CDN, SSL, DDoS-Schutz und benutzerdefinierte Regeln (bis zu 5) verfügbar.

    Dieser Artikel erklärt die einzelnen Einstellungen und was Sie nach der Umstellung prüfen sollten. Namen und Anordnung der Cloudflare-Oberfläche können sich ändern; die Angaben hier folgen der offiziellen Dokumentation (developers.cloudflare.com) mit Stand November 2026.

    Was Sie vor der Einrichtung klären sollten

    • Die DNS-Verwaltung wechselt zu Cloudflare. Der Registrar Ihrer Domain bleibt derselbe, aber DNS-Einträge bearbeiten Sie künftig in der Cloudflare-Oberfläche.
    • DNS-Einträge für E-Mail (MX usw.) werden nicht über den Proxy geleitet. Über Cloudflare läuft nur der Web-Traffic (HTTP/HTTPS).
    • Prüfen Sie, ob der Origin (der Server, auf dem WordPress läuft) ein gültiges SSL-Zertifikat hat. Wenn HTTPS bereits mit Let's Encrypt o. Ä. funktioniert, passt das so.
    • Falls Sie beim Registrar DNSSEC aktiviert haben, deaktivieren Sie es vor der Umstellung der Nameserver. Ein verbliebener alter DS-Eintrag lässt die Namensauflösung fehlschlagen.

    Schritt 1: Website hinzufügen und Nameserver umstellen

    1. Legen Sie ein Cloudflare-Konto an und fügen Sie Ihre Domain im Dashboard hinzu. Als Tarif können Sie Free wählen.
    2. Cloudflare liest Ihre aktuellen DNS-Einträge aus und listet sie auf. Prüfen Sie, ob etwas fehlt. Manche Einträge werden nicht erkannt; vergleichen Sie daher mit Ihrer bisherigen DNS-Verwaltung und ergänzen Sie fehlende Einträge von Hand.
    3. Setzen Sie bei den A-Einträgen (oder AAAA/CNAME) der Website den Proxy-Status auf „an“ (orange Wolke). Bei MX und bei A-Einträgen für den Mailserver stellen Sie ihn auf „aus“ (nur DNS, graue Wolke).
    4. Cloudflare zeigt zwei Nameserver-Namen an. Sie haben die Form 〇〇.ns.cloudflare.com und werden pro Konto zugewiesen. Verwenden Sie die beiden Namen, die in Ihrer eigenen Oberfläche erscheinen, nicht die aus anderen Artikeln.
    5. Ändern Sie in der Verwaltung des Domain-Registrars die Nameserver auf diese beiden.

    Ob die Umstellung geklappt hat, prüfen Sie mit den folgenden Befehlen. Es kann einige Stunden dauern, bis sie wirksam wird.

    # Sind die Nameserver die zwei von Cloudflare?
dig NS example.com +short

# Läuft der Traffic über Cloudflare? (server: cloudflare und cf-ray werden zurückgegeben)
curl -sI https://example.com | grep -iE '^(server|cf-ray):'

    Wenn der Status der Domain in Cloudflare auf aktiv (Active) steht, ist die Umstellung abgeschlossen.

    Schritt 2: SSL/TLS auf Full (strict) setzen

    Für SSL/TLS gibt es bei Cloudflare Modi, die festlegen, wie die Verbindung zwischen Besucher und Cloudflare sowie zwischen Cloudflare und Origin verschlüsselt wird.

    Modus Zwischen Cloudflare und Origin Einsatz bei WordPress
    Off Keine Verschlüsselung Nicht verwenden
    Flexible HTTP (unverschlüsselt) Nicht verwenden. Ursache für Weiterleitungsschleifen und Mixed Content
    Full HTTPS (Zertifikat wird nicht geprüft) Übergangslösung, bis ein Zertifikat vorliegt
    Full (strict) HTTPS (Zertifikat wird geprüft) Diesen Modus wählen

    Die Einstellung ändern Sie im Cloudflare-Dashboard auf der Seite SSL/TLS Overview. Die Voreinstellung „Automatic SSL/TLS“ wählt automatisch einen sicheren Modus, soweit der Origin ihn unterstützt. Wenn Sie Full (strict) selbst wählen, läuft die Verbindung nicht versehentlich in einem unerwünschten Modus. Als Origin-Zertifikat eignet sich ein Zertifikat einer öffentlichen Zertifizierungsstelle (z. B. Let's Encrypt) oder ein von Cloudflare ausgestelltes Origin-CA-Zertifikat.

    Warum Sie Flexible meiden sollten: Bei Flexible erreicht die Anfrage den Origin per HTTP. WordPress oder der Server antwortet dann mit „kam per HTTP, also nach HTTPS weiterleiten“, und Cloudflare holt die Seite wieder per HTTP vom Origin. So entsteht eine Endlosschleife (im Browser erscheint ERR_TOO_MANY_REDIRECTS). Bei Full (strict) erreicht die Anfrage den Origin ebenfalls per HTTPS, sodass Sie in WordPress keinen zusätzlichen Code brauchen, der X-Forwarded-Proto auswertet und $_SERVER['HTTPS'] umschreibt.

    Prüfen Sie außerdem unter „Einstellungen“ → „Allgemein“ (Settings → General) in WordPress, ob „WordPress-Adresse (URL)“ und „Website-Adresse (URL)“ mit https:// beginnen. Bleiben Bilder o. Ä. bei http://, finden Sie die Lösung unter Mixed Content beheben.

    Schritt 3: Die echte IP des Besuchers wiederherstellen

    Wenn der Traffic über Cloudflare läuft, ist die Quelle der Verbindung (REMOTE_ADDR), die den Server erreicht, eine IP-Adresse von Cloudflare. So behandeln Zugriffslog, Kommentar-IPs und Plugins, die Login-Versuche begrenzen, alle Besucher als Cloudflare-IP. Cloudflare übergibt die IP des Besuchers im Header CF-Connecting-IP; richten Sie die Konfiguration so ein, dass dieser Header nur dann vertraut wird, wenn die Verbindung von Cloudflare stammt.

    Wenn Sie REMOTE_ADDR anhand des Headers umschreiben, ohne die Quelle zu prüfen, kann jeder, der den Origin direkt an Cloudflare vorbei aufruft, im Header eine beliebige IP vortäuschen. Verwenden Sie deshalb nicht den Code aus älteren Artikeln, der nur „wenn HTTP_CF_CONNECTING_IP vorhanden ist, in REMOTE_ADDR übernehmen“ macht.

    Die Liste der Cloudflare-IP-Adressen ist unter https://www.cloudflare.com/ips/ veröffentlicht. Sie kann sich ändern, prüfen Sie sie daher regelmäßig.

    Bei Nginx

    Verwenden Sie ngx_http_realip_module. Führen Sie im http- oder server-Block alle Cloudflare-Bereiche auf.

    # IP-Bereiche von Cloudflare (Stand November 2026. Aktuelle Liste unter cloudflare.com/ips prüfen)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header CF-Connecting-IP;
    sudo nginx -t && sudo systemctl reload nginx

    Bei Apache (Debian / Ubuntu)

    Verwenden Sie mod_remoteip. Legen Sie /etc/apache2/conf-available/remoteip.conf an und führen Sie die Cloudflare-Bereiche unter RemoteIPTrustedProxy auf.

    RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22
RemoteIPTrustedProxy 2400:cb00::/32 2606:4700::/32 2803:f800::/32 2405:b500::/32
RemoteIPTrustedProxy 2405:8100::/32 2a06:98c0::/29 2c0f:f248::/32
    sudo a2enmod remoteip
sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

    Damit das Zugriffslog die echte IP enthält, ersetzen Sie in /etc/apache2/apache2.conf beim LogFormat (combined) das %h durch %a.

    Wenn Sie die Serverkonfiguration nicht ändern können (wp-config.php)

    Wenn Sie die Webserver-Konfiguration nicht anfassen können, z. B. bei einem Mietserver, nehmen Sie dieselbe Prüfung in wp-config.php vor. Platzieren Sie den Code vor der Zeile require_once ABSPATH . 'wp-settings.php';. Der Wert von CF-Connecting-IP (sofern er eine gültige IP-Adresse ist) wird nur verwendet, wenn die Verbindungsquelle in einem Cloudflare-Bereich liegt.

    <?php
// CF-Connecting-IP nur bei Zugriff über Cloudflare als IP des Besuchers verwenden
$cf_ranges = [
    '173.245.48.0/20', '103.21.244.0/22', '103.22.200.0/22', '103.31.4.0/22',
    '141.101.64.0/18', '108.162.192.0/18', '190.93.240.0/20', '188.114.96.0/20',
    '197.234.240.0/22', '198.41.128.0/17', '162.158.0.0/15', '104.16.0.0/13',
    '104.24.0.0/14', '172.64.0.0/13', '131.0.72.0/22',
    '2400:cb00::/32', '2606:4700::/32', '2803:f800::/32', '2405:b500::/32',
    '2405:8100::/32', '2a06:98c0::/29', '2c0f:f248::/32',
];

function cf_ip_in_range(string $ip, string $cidr): bool
{
    [$net, $bits] = explode('/', $cidr);
    $ip_bin  = inet_pton($ip);
    $net_bin = inet_pton($net);
    if ($ip_bin === false || $net_bin === false || strlen($ip_bin) !== strlen($net_bin)) {
        return false;
    }
    $bits  = (int) $bits;
    $bytes = intdiv($bits, 8);
    if ($bytes > 0 && substr($ip_bin, 0, $bytes) !== substr($net_bin, 0, $bytes)) {
        return false;
    }
    $rest = $bits % 8;
    if ($rest === 0) {
        return true;
    }
    $mask = (0xFF << (8 - $rest)) & 0xFF;
    return (ord($ip_bin[$bytes]) & $mask) === (ord($net_bin[$bytes]) & $mask);
}

if (!empty($_SERVER['HTTP_CF_CONNECTING_IP']) && !empty($_SERVER['REMOTE_ADDR'])) {
    foreach ($cf_ranges as $range) {
        if (cf_ip_in_range($_SERVER['REMOTE_ADDR'], $range)) {
            $visitor = filter_var($_SERVER['HTTP_CF_CONNECTING_IP'], FILTER_VALIDATE_IP);
            if ($visitor !== false) {
                $_SERVER['REMOTE_ADDR'] = $visitor;
            }
            break;
        }
    }
}

    In wp-config.php steht <?php schon von Anfang an. Übernehmen Sie daher das <?php der ersten Zeile nicht, sondern fügen Sie ab der zweiten Zeile ein. Legen Sie vor dem Einfügen eine Sicherungskopie von wp-config.php an.

    Schritt 4: Die Login-Seite mit benutzerdefinierten WAF-Regeln schützen

    Im kostenlosen Tarif können Sie bis zu 5 benutzerdefinierte WAF-Regeln von Cloudflare anlegen und andere Aktionen als Log wählen (Block, Managed Challenge usw.). Öffnen Sie dazu im Dashboard die Seite Security rules, wählen Sie über „Create rule“ den Eintrag „Custom rules“, geben Sie Bedingung (Field, Operator, Value) und Aktion an und klicken Sie auf „Deploy“.

    Beispiel 1: Login und Admin-Bereich nur für die eigene IP öffnen

    Dieses Beispiel gilt, wenn Sie zu Hause oder in der Firma eine feste IP haben. Als Ausdruck sieht es so aus (203.0.113.10 und 198.51.100.0/24 ersetzen Sie durch Ihre eigenen IPs).

    (http.request.uri.path eq "/wp-login.php" or starts_with(http.request.uri.path, "/wp-admin/"))
and http.request.uri.path ne "/wp-admin/admin-ajax.php"
and not ip.src in {203.0.113.10 198.51.100.0/24}

    Als Aktion wählen Sie Block. /wp-admin/admin-ajax.php ist aus der Bedingung ausgenommen, weil Funktionen öffentlicher Seiten wie Kontaktformulare oder Endlos-Scrollen es auch ohne Login aufrufen können.

    Beispiel 2: Ohne feste IP nach Land und mit Managed Challenge eingrenzen

    (http.request.uri.path eq "/wp-login.php" or http.request.uri.path eq "/xmlrpc.php")
and not ip.src.country in {"JP"}

    Für die Länderprüfung verwenden Sie ip.src.country (2-stelliger Code nach ISO 3166-1). Das in älteren Artikeln genannte ip.geoip.country ist veraltet. Wählen Sie als Aktion zunächst Managed Challenge, prüfen Sie in den Sicherheitsereignissen, ob legitime Zugriffe hängen bleiben, und wechseln Sie bei Bedarf zu Block. Auch die Cloudflare-Dokumentation empfiehlt dieses Vorgehen. xmlrpc.php wird von Jetpack oder beim Veröffentlichen per Smartphone-App verwendet; nehmen Sie es erst in die Bedingung auf, wenn Sie geprüft haben, ob Sie es nutzen.

    Eine Länderbeschränkung ist nur eine Zusatzmaßnahme, die sich mit VPN u. Ä. umgehen lässt. Kombinieren Sie sie mit Zwei-Faktor-Authentifizierung und Begrenzung der Login-Versuche. Wie Sie das Land auf Nginx-Seite bestimmen, erklärt Nginx GeoIP2: Zugriff nach Ländern beschränken.

    Schritt 5: Standardverhalten des Caches und Purge bei der Veröffentlichung

    Cloudflare cacht standardmäßig kein HTML. Gecacht werden statische Dateien, die an ihrer Dateiendung erkannt werden, etwa Bilder, CSS, JavaScript und Schriftarten. Auch Antworten mit dem Header Set-Cookie werden nicht gecacht. Ohne weitere Einstellungen werden Admin-Bereich und Login-Seite daher nicht von Cloudflare gecacht.

    Wenn Sie auch HTML cachen wollen, erweitern Sie den Umfang mit Cache Rules. Dann müssen Sie jedoch /wp-admin/, /wp-login.php, Vorschauen und die Ansicht eingeloggter Benutzer ausnehmen. Bei falschen Ausnahmen kann eine Admin-Ansicht anderen Personen angezeigt werden; wenn Sie sich unsicher sind, belassen Sie es bei der Voreinstellung.

    Wenn Sie CSS oder Bilder ausgetauscht haben und die Anzeige sich nicht ändert, leeren (Purge) Sie den Cache in den Cache-Einstellungen des Dashboards. Möchten Sie bei jeder Veröffentlichung oder Aktualisierung eines Beitrags automatisch leeren, rufen Sie die Cloudflare-API auf. Erstellen Sie dazu in Cloudflare ein API-Token, das nur die Berechtigung „Cache Purge“ hat, und tragen Sie es zusammen mit der Zonen-ID (auf der Übersichtsseite der Domain angezeigt) als Konstanten in wp-config.php ein.

    define( 'CF_ZONE_ID', 'Zonen-ID' );
define( 'CF_API_TOKEN', 'API-Token' );

    Den folgenden Code legen Sie in der functions.php eines Child-Themes oder in einem kleinen eigenen Plugin ab (auch Code Snippets o. Ä. ist möglich).

    <?php
// Wenn ein Beitrag veröffentlicht oder aktualisiert wird, den Cache für diesen Beitrag und die Startseite bei Cloudflare löschen
function cf_purge_urls(array $urls): bool
{
    if (!defined('CF_ZONE_ID') || !defined('CF_API_TOKEN')) {
        return false;
    }

    $response = wp_remote_post(
        'https://api.cloudflare.com/client/v4/zones/' . CF_ZONE_ID . '/purge_cache',
        [
            'headers' => [
                'Authorization' => 'Bearer ' . CF_API_TOKEN,
                'Content-Type'  => 'application/json',
            ],
            'body'    => wp_json_encode(['files' => array_values($urls)]),
            'timeout' => 15,
        ]
    );

    if (is_wp_error($response)) {
        error_log('Cloudflare purge failed: ' . $response->get_error_message());
        return false;
    }

    $result = json_decode(wp_remote_retrieve_body($response), true);
    return !empty($result['success']);
}

add_action('publish_post', function (int $post_id): void {
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }
    cf_purge_urls([get_permalink($post_id), home_url('/')]);
});

    publish_post wird ausgelöst, wenn ein Beitrag veröffentlicht oder ein bereits veröffentlichter Beitrag aktualisiert wird. Die API purge_cache kennt neben files (Angabe von URLs) auch purge_everything zum Löschen von allem. Da dabei aber auch alle statischen Dateien neu geholt werden müssen, nutzen Sie es nicht bei jeder Veröffentlichung eines Artikels.

    Was Sie nach der Umstellung prüfen sollten

    • Im Ergebnis von curl -sI stehen server: cloudflare und cf-ray, und im Browser erscheint das Schloss-Symbol
    • Sie können sich im Admin-Bereich anmelden, Beiträge speichern und Medien hochladen
    • In neuen Kommentaren und im Zugriffslog steht die IP des Besuchers statt einer Cloudflare-IP
    • E-Mails aus dem Kontaktformular kommen an (der MX-Eintrag läuft nicht über den Proxy)
    • Wenn Sie benutzerdefinierte WAF-Regeln angelegt haben, öffnen Sie wp-login.php über einen nicht erlaubten Anschluss (z. B. Mobilfunk am Smartphone) und prüfen, dass Block oder Challenge erscheint

    Häufige Probleme

    ERR_TOO_MANY_REDIRECTS erscheint

    Prüfen Sie, ob der SSL/TLS-Modus auf Flexible steht. Installieren Sie ein Zertifikat auf dem Origin und wechseln Sie zu Full (strict), dann verschwindet der Fehler.

    Der Zugang zum Admin-Bereich ist nicht mehr möglich

    Möglicherweise enthält die Bedingung der benutzerdefinierten WAF-Regel Ihre IP oder Ihr Land nicht. Deaktivieren Sie die Regel vorübergehend im Cloudflare-Dashboard, prüfen Sie in den Sicherheitsereignissen, an welcher Regel Sie hängen geblieben sind, und korrigieren Sie dann den Ausdruck.

    Alle Zugriffe scheinen von derselben IP zu kommen

    Die Wiederherstellung der echten IP aus Schritt 3 funktioniert nicht. Prüfen Sie bei Nginx den Bereich von set_real_ip_from und real_ip_header, bei Apache, ob remoteip aktiviert ist.

    Fazit

    • Stellen Sie die Nameserver auf die zwei Ihrem Konto zugewiesenen um und leiten Sie E-Mail-Einträge wie MX nicht über den Proxy
    • SSL/TLS auf Full (strict). Flexible verursacht Weiterleitungsschleifen und Mixed Content
    • Die echte IP stellen Sie nur dann über CF-Connecting-IP wieder her, wenn die Verbindung aus einem Cloudflare-Bereich stammt
    • Schränken Sie die Login-Seite per WAF-Regel nach IP oder Land ein und beobachten Sie sie zunächst mit Managed Challenge
    • HTML wird standardmäßig nicht gecacht. Das Purge bei der Veröffentlichung erledigen Sie mit einem API-Token, das nur die Berechtigung „Cache Purge“ hat

    Ähnliche Artikel

    Quellen: Restoring original visitor IPs (Cloudflare), Encryption modes (Cloudflare), Custom rules (Cloudflare WAF), Default cache behavior (Cloudflare)

    Views: 4

    Fragen zu WordPress? Der Betreiber dieser Seite sitzt in Japan und antwortet auf Japanisch. Kontakt (Japanisch)

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲