Cloudflare und erste Erkenntnisse.

Seit einigen Tagen habe ich Cloudflare als CDN bei mir im Einsatz und prompt kam es zu den ersten Problemen Erkenntnissen.
Vorweg sei gleich gesagt, daß die Schuld dafür nicht bei Cloudflare liegt, sondern an eher wenig fundierten Kenntnissen zwischen Keyboard und Stuhllehne beim Thema DNS. Der CDN-Dienst setzt zwar nur sehr wenige Vorkenntnisse voraus, allerdings gibt es einige kleine Stolperfallen mit großer Wirkung, die man kennen und vermeiden sollte.

WP-Admin vom Cloudflare-Caching ausschliessen.

Kurz nachdem der Dienst aktiv war, stellte ich ein etwas zickiges Verhalten im WordPress Adminbereich fest. Das Speichern von Entwürfen und der Beitragsvorschau funktionierten nur sporadisch. Ebenso gab es beim Login in den Adminbereich gelegentlich Probleme.
Der Verdacht, dass es an den neuen DNS Einträgen von Cloudflare liegen könnte lag nache, weshalb ich Cloudflare erstmal in eine Pause schickte. Das funktioniert ganz einfach über den Cloudflare Adminbereich.
Siehe da: Die Zickereien waren vorbei!

Eine kurze Rechere ergab, dass das wp-admin Verzeichniss und wp-login.php vom Caching ausgeschlossen werden sollten.
Dies funktioniert über Page Rules in der Cloudflare Oberfläche. Dort trägt man das URL-Pattern ein und kann darunter diverse Regeln oder Optionen einstellen, die für dieses Patter gelten sollen.

cloudflare_page_rules

Diese beiden Page Rules solltet ihr für euren Blog eintragen. Statt “example.com” tragt ihr natürlich eure Domain ein.
Wichtig: Vergesst nicht den Asterisk am Ende des Patterns! Dieser sorgt dafür, dass auch alle Unterverzeichnisse in  wp-admin und Parameterangaben hinter wp-login.php ebenfalls vom Caching ausgeschlossen werden.

Am besten schaltet ihr folgende Regeln ab:

Custom Caching: Bypass all Caching
Always Online: Off
Apps: Off
Performance: Off
Rocketloader: Off

Die anderen Optionen habe ich auf den Default-Wert belassen, ohne irgendwelche Auswirkungen.

Loopback Adresse der Datenbank-Hosts in wp-config.php eintragen.

Die größte Überraschung erlebte ich allerdings am Samstag Nachmittag als plötzlich der Aufruf des Blogs mit “Cannot connect to Database” quittiert wurde. Uppps! Wieder klickte ich den Pause-Button bei Cloudflare, doch diesmal ohne Erfolg.
Meinen Blog und meine Domains hoste ich seit über zehn Jahren sehr zufrieden auf einem Managed Host bei Domainfactory. Inkludiert sind bei mir auch 1000 MySQL-Datenbanken, die über eine Subdomain angesprochen werden können, also z.B. mit mysqlx.nsign.net.
Die Datenbankadresse war auch so mit ihrem Domainnamen in der wp-config.php eingetragen und da war letztlich auch das Probelm:
Durch den DNS-Wechsel zu Cloudflare konnte die interne Loopback-Adresse (127.0.0.x) vom neuen DNS nicht mehr aufgelöst werden und somit letztlich keine Verbindung zur Datenbank hergestellt werden.
Das bestätigte sich, als ich die Domain wieder komplett aus Cloudflare genommen hatte und die Nameserver von Daminfactory wieder eingetragen hatte. Allerdings dauerte die Umstellung über 30 (!) Stunden bis sie griff. Laut “dig” waren die Nameserver zwar schon nach 2 Stunden eingetragen, aber das Propagieren der neuen Nameserver kann schon mal auch 1-3 Tage dauern.

Vielen Dank an dieser Stelle auch an den Support von Domainfactory, der selbst zu später Stunde am Samstagabend geduldig, hilfsbereit und kompetent das Problem lokalisieren konnte!

Tipp: Generell ist es keine schlechte Idee, in Config-files die interne Loopbackadresse des Datenbank-Hosts einzutragen, da ihr dann nicht in  das geschilderte Problem lauft wenn ihr einen anderen DNS benutzt oder eure Domain umzieht.

Ich gestehe aber, da ich mit der Performance von Cloudflare recht zufrieden war, dass ich heute wieder auf Cloudflare umgezogen bin. Again what learned…;-)

 

Share:

Schreibe einen Kommentar