WordPress Sitesine Cloudflare Kurulumu: Doğru Ayarlar ve Tuzaklar

Cloudflare paneline giriyorsunuz ve alan adınızın yanında yeşil "Active" yazıyor. Nameserver değişimi tamamlanmış, site açılıyor, sayfalar biraz daha hızlı geliyor. Kurulum bitti gibi görünüyor.

Sonraki gün gelen şikayetler ise şöyle: sipariş bildirim e-postaları kimseye ulaşmıyor, bir müşteri "sepetimde başkasının ürünleri var" diyor, güvenlik eklentisinin panelinde yüzlerce başarısız giriş denemesi aynı IP'den görünüyor ve o IP'yi engellediğinizde siteye kimse giremiyor. Hiçbiri tesadüf değil; hepsi Cloudflare'in çalışma biçiminin doğrudan sonucu ve hepsinin ayrı bir ayarı var.

Bu rehber, "hesap açtım, nameserver'ları değiştirdim" adımını geçmiş kabul ediyor. Nameserver değişimini henüz yapmadıysanız önce nameserver değiştirme yazısına, Cloudflare'in DNS ve CDN tarafındaki genel mantığı için de Cloudflare DNS ve CDN yazısına bakın. Burada sonrasında yapılması gerekenleri ve en sık düşülen tuzakları ele alıyoruz.

Nameserver Aktifleşti, Sırada Ne Var?#

Cloudflare kurulumu tek adımlık bir işlem değil, birbirini etkileyen dört ayrı kararın toplamıdır:

1. SSL modu — Cloudflare ile sunucunuz arasındaki bağlantının nasıl şifreleneceği.
2. Proxy durumu — hangi DNS kaydının turuncu bulutla (proxy) hangisinin gri bulutla (sadece DNS) çalışacağı.
3. Önbellek kuralları — hangi adreslerin edge'de saklanıp hangilerinin her seferinde sunucudan çekileceği.
4. Gerçek ziyaretçi IP'si — sunucunuzun kimin bağlandığını nasıl öğreneceği.

Bu dördü yanlış bırakıldığında site "çalışıyor gibi" görünür, sorunlar günler sonra ve ilgisiz görünen şikayetler olarak geri döner. Sırayla gidelim.

SSL Modunu Neden Full (Strict) Yapmalısınız?#

Cloudflare'in SSL/TLS ayarında dört seçenek vardır ve bu seçim, ziyaretçi ile sizin aranızdaki değil, Cloudflare ile sunucunuz arasındaki bağlantıyı belirler:

Flexible modundan uzak durun. İki somut zararı var. Birincisi güvenlik: Cloudflare'den sunucunuza giden trafik şifresizdir, yani veri merkezleri arasındaki yolun tamamı korunmaz ve tarayıcıdaki yeşil kilit bunu yansıtmaz. İkincisi ise WordPress'e özel bir arıza: sunucunuz kendi tarafında HTTPS'e yönlendirme yapıyorsa, Cloudflare HTTP ile bağlanır, sunucu "HTTPS'e git" der, Cloudflare aynı isteği yine HTTP olarak gönderir ve döngü kapanmaz. Ziyaretçi ERR_TOO_MANY_REDIRECTS görür.

Full (Strict) modunun tek şartı, sunucunuzda geçerli bir sertifika bulunmasıdır. Zaten Let's Encrypt ya da ücretli bir sertifikanız varsa doğrudan Full (Strict) seçebilirsiniz. Yoksa Cloudflare'in ücretsiz Origin CA sertifikasını kullanabilirsiniz: SSL/TLS → Origin Server bölümünden 15 yıllık bir sertifika üretilir, sunucunuza kurarsınız. Bu sertifika yalnızca Cloudflare ile sunucunuz arasında geçerlidir — doğrudan IP'den erişildiğinde tarayıcı uyarı verir, çünkü tasarımı gereği öyledir.

Modu belirledikten sonra iki anahtarı daha açın:

• Always Use HTTPS — HTTP ile gelen isteği Cloudflare kendi katmanında HTTPS'e çevirir, sunucunuza hiç ulaşmadan.
• Automatic HTTPS Rewrites — sayfa içindeki http:// kaynak bağlantılarını uçarken düzeltir. Bu bir yama olduğunu unutmayın; kalıcı çözüm veritabanındaki URL'leri düzeltmektir. Detay için mixed content hatası ve WordPress'te HTTPS zorlama yazılarına bakın.

WordPress "http" Üretmeye Devam Ediyorsa#

Proxy arkasında WordPress bazen bağlantının şifreli olduğunu anlayamaz, çünkü $_SERVER['HTTPS'] değişkeni sunucuya boş gelir. Sonuç: yönetici paneli yarım yüklenir, stil dosyaları gelmez, karışık içerik uyarıları çıkar. Çözüm, wp-config.php dosyasında /* That's all, stop editing! */ satırından önce şu bloğu tanımlamaktır:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
     && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Cloudflare her proxy'li istekte X-Forwarded-Proto başlığını gönderir, bu blok da onu WordPress'in anlayacağı biçime çevirir.

Hangi DNS Kaydı Turuncu Bulut, Hangisi Gri Olmalı?#

Cloudflare DNS ekranında her kaydın yanında bir bulut simgesi vardır. Turuncu bulut trafiğin Cloudflare üzerinden geçtiğini, gri bulut ise Cloudflare'in yalnızca DNS cevabı verip araya girmediğini gösterir. Kurulum sırasında Cloudflare kayıtları içe aktarırken bazılarını kendiliğinden turuncuya çevirir ve asıl kaza burada olur.

Cloudflare'in proxy'si yalnızca belirli HTTP/HTTPS portlarını taşır — 80 ve 443 başta olmak üzere sınırlı bir liste. E-posta protokolleri (SMTP 25/587/465, IMAP 993, POP3 995) bu listede yoktur. Mail kaydınızı turuncu buluta alırsanız, mail istemcileri gerçek sunucu IP'sine hiç ulaşamaz ve e-posta akışı durur.

Kurulumdan hemen sonra DNS listesini yukarıdan aşağı gözden geçirin ve mail ile ilgili her kaydın gri olduğundan emin olun. Bu tek kontrol, "Cloudflare kurduk, mailler kesildi" vakalarının büyük çoğunluğunu önler.

Not: gri buluta aldığınız her kayıt sunucunuzun gerçek IP adresini dünyaya açar. Cloudflare'in koruma vaadi, saldırganın origin IP'yi bilmemesine dayanır; mail.siteniz.com gri olduğu sürece o IP herkesin erişimindedir. Bu yüzden sunucu güvenlik duvarınızın 80/443 portlarını yalnızca Cloudflare IP aralıklarına açması, kurulumun tamamlayıcı parçasıdır.

/wp-admin ve Giriş Sayfası İçin Önbellek Bypass Kuralı#

Burada yaygın bir yanlış anlama var: Cloudflare varsayılan ayarlarla HTML sayfalarını önbelleğe almaz. Yalnızca statik uzantıları (.css, .js, .jpg, .png, .woff2, .pdf gibi) saklar. Yani hiçbir şey yapmazsanız /wp-admin zaten güvendedir.

Sorun, hız için bir adım ileri gidip "Cache Everything" kuralı oluşturduğunuzda başlar. O andan itibaren Cloudflare HTML'i de saklamaya başlar ve WordPress'in oturum mantığı çöker: bir yöneticinin gördüğü panel sayfası önbelleğe girer ve sıradaki ziyaretçiye servis edilir, ya da tam tersi — giriş yapmış kullanıcıya çıkış yapmış hâli gösterilir. WooCommerce kullanıyorsanız sepet ve ödeme sayfaları da aynı riski taşır.

HTML önbellekleyecekseniz bypass kurallarını önce tanımlayın. Cloudflare kuralları yukarıdan aşağı değerlendirir ve ilk eşleşen kural kazanır; bypass kuralı Cache Everything kuralının altında kalırsa hiç çalışmaz.

Bypass edilmesi gereken adresler:

/wp-admin/*
/wp-login.php
/wp-json/*
/wp-cron.php
/*?preview=true
/*?s=*

WooCommerce varsa şunları da ekleyin:

/sepet*
/odeme*
/hesabim*
/cart*
/checkout*
/my-account*

Kuralı Cloudflare panelinde Caching → Cache Rules altında oluşturmak, eski Page Rules'a göre daha esnektir; ücretsiz planda Page Rules üç adetle sınırlıyken Cache Rules daha geniş bir kotayla gelir. Bir Cache Rules ifadesi şöyle kurulur:

(http.request.uri.path contains "/wp-admin")
or (http.request.uri.path eq "/wp-login.php")
or (http.request.uri.path contains "/wp-json")
or (http.cookie contains "wordpress_logged_in")

Eylem olarak Bypass cache seçin. Son satır özellikle değerlidir: WordPress giriş yapan her kullanıcıya wordpress_logged_in_... çerezi verir, bu koşul sayesinde oturum açmış hiç kimse önbellekten sayfa görmez — hangi adrese giderse gitsin.

HTML'i edge'de önbelleklemek istiyor ama bu kuralları elle yönetmek istemiyorsanız Cloudflare'in WordPress için sunduğu APO (Automatic Platform Optimization) hizmeti bu çerez mantığını kendisi kurar; resmi Cloudflare eklentisiyle birlikte çalışır ve ücretsiz planda ek ücretlidir. Sunucu tarafındaki önbellek katmanıyla nasıl birleştireceğinizi WordPress önbellek rehberi yazısında bulabilirsiniz.

Gerçek Ziyaretçi IP'si Neden Kaybolur?#

Proxy açıkken sunucunuza gelen her istek Cloudflare'in bir veri merkezinden gelir. Sunucu açısından bakıldığında REMOTE_ADDR değeri artık ziyaretçinin IP'si değil, Cloudflare'in IP'sidir. Bunun görünür sonuçları:

• Güvenlik eklentiniz başarısız giriş denemelerini tek bir IP'ye yazar; eşiği aştığında o IP'yi engeller ve bütün ziyaretçileri kapıda bırakır.
• Yorum spam filtreleri IP tabanlı kararlarını veremez.
• Ülke/şehir bazlı istatistikleriniz tek bir noktada toplanır.
• Sunucu erişim kayıtlarında (access.log) kimin ne yaptığı izlenemez hâle gelir.

Cloudflare gerçek IP'yi silmez, CF-Connecting-IP başlığında taşır. Yapılması gereken, sunucuyu ya da WordPress'i bu başlığı okuyacak biçimde yapılandırmaktır.

Yöntem 1: Web Sunucusu Seviyesinde (Tercih Edilen)#

En doğru çözüm budur; hem PHP hem erişim kayıtları hem de fail2ban gibi araçlar tek seferde düzelir.

Nginx için:

# Cloudflare IP aralıkları (kısaltılmış liste — tam listeyi indirin)
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

real_ip_header CF-Connecting-IP;

Apache için mod_remoteip modülü aynı işi yapar:

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/13

Güncel ve eksiksiz aralık listesini Cloudflare yayımlar:

curl -s https://www.cloudflare.com/ips-v4
curl -s https://www.cloudflare.com/ips-v6

Yöntem 2: WordPress Seviyesinde#

Sunucu yapılandırmasına erişiminiz yoksa (paylaşımlı hosting) resmi Cloudflare eklentisi bunu sizin için yapar; ayarlarında "Restore original visitor IP" seçeneği bulunur. Eklenti kullanmak istemiyorsanız wp-config.php içine şu blok da aynı işi görür:

if ( ! empty( $_SERVER['HTTP_CF_CONNECTING_IP'] ) ) {
    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];
}

Bu satırın önemli bir şartı var: sunucunuz yalnızca Cloudflare IP aralıklarından gelen bağlantıları kabul ediyor olmalı. Aksi hâlde saldırgan sunucunuzun gerçek IP'sini bulup doğrudan bağlanabilir ve CF-Connecting-IP başlığını istediği değerle gönderebilir — böylece IP tabanlı her engellemenizi ve giriş limitinizi atlar. Yani bu satır, güvenlik duvarınız Cloudflare dışına kapalı değilse bir korumayı düzeltmiyor, tam tersine bir açık yaratıyor.

Güvenlik duvarını daraltmak için (UFW örneği):

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  ufw allow proto tcp from $ip to any port 80,443
done
ufw deny 80/tcp
ufw deny 443/tcp

IP tabanlı giriş korumasını nasıl kurgulayacağınız konusunda WordPress giriş limitleme yazısı, artık gerçek IP'yi gördüğünüz varsayımıyla okunabilir hâle gelir.

Development Mode Ne Zaman Kullanılır?#

Cloudflare panelindeki Development Mode, önbelleği tamamen devre dışı bırakır ve tüm istekleri doğrudan sunucunuza iletir. Üç saat sonra kendiliğinden kapanır — bu otomatik kapanma, açık unutulmasını engellemek için tasarlanmıştır.

Kullanılacağı anlar:

• Tema veya CSS üzerinde çalışıyorsunuz ve değişikliklerin anında yansımasını istiyorsunuz.
• Bir hatanın Cloudflare kaynaklı mı yoksa sunucu kaynaklı mı olduğunu ayırt etmeye çalışıyorsunuz. Development Mode açıkken sorun devam ediyorsa suçlu Cloudflare değildir.
• Site taşıma sonrası ilk kontrolleri yapıyorsunuz.

Kullanılmayacağı an: trafik altındaki bir sitede performans testi. Development Mode açıkken her istek sunucunuza gider, ölçtüğünüz sayı normal koşulları yansıtmaz.

Sadece belirli bir dosyanın önbelleğini yenilemek istiyorsanız tüm önbelleği boşaltmak yerine Caching → Configuration → Purge by URL yolunu kullanın; toptan temizlik, edge'in yeniden dolması sırasında sunucunuza ani bir yük bindirir. Site erişilemez hâle geldiğinde bakılacak ilk yer ise Cloudflare'in hata kodlarıdır; 520, 521 ve 522 hataları doğrudan origin sunucunuzun cevap vermediğini söyler.

Kapatmanız Gereken Optimizasyon Anahtarları#

Cloudflare'in "hızlandırma" başlığı altında sunduğu bazı özellikler WordPress'te sorun çıkarır:

• Rocket Loader — JavaScript yüklemesini erteleyerek sıralamayı değiştirir. jQuery'ye bağımlı temalarda ve sayfa oluşturucu eklentilerinde kayan içerikler, çalışmayan menüler ve sepete eklenmeyen ürünler bu ayardan kaynaklanır. Sorun yaşıyorsanız ilk kapatacağınız anahtar budur.
• Email Address Obfuscation — sayfadaki e-posta adreslerini gizlemek için HTML'i değiştirir ve her sayfaya kendi JavaScript dosyasını ekler. Bunun iki maliyeti var: kritik yola fazladan bir istek girer ve kod bloklarının içindeki e-posta adresleri de bozulur — teknik içerik yayınlıyorsanız örnek yapılandırmalarınızda "[email protected]" yazısı belirir.
• Auto Minify — Cloudflare bu özelliği 2024 Ağustos'unda kullanımdan kaldırdı; ölçülen kazanç ağ genelinde %0,1'in altındaydı ve modern derleme araçları bu işi zaten yapıyor. Panelinizde hâlâ görünüyorsa güvenmeyin, sıkıştırmayı WordPress önbellek eklentiniz üzerinden yönetin.

Bu ayarları tek tek açıp siteyi gizli sekmede test etmek, hepsini birden açıp hangisinin ne kırdığını aramaktan çok daha hızlıdır.

Kurulum Sonrası Doğrulama Listesi#

Ayarları yaptıktan sonra beş dakikalık bir kontrol turu:

1. Proxy çalışıyor mu? Yanıt başlıklarında cf-cache-status ve server: cloudflare görünmeli.

curl -sI https://siteniz.com/ | grep -iE 'server|cf-cache-status|cf-ray'

2. Statik dosyalar önbelleğe giriyor mu? Bir CSS dosyasını iki kez isteyin; ikincide cf-cache-status: HIT beklenir.

curl -sI https://siteniz.com/wp-includes/css/dashicons.min.css | grep -i cf-cache-status

3. Panel önbelleğe girmiyor mu? /wp-admin/ için cf-cache-status ya DYNAMIC ya da BYPASS olmalı; HIT görüyorsanız kural sıralamanız yanlıştır.

4. Mail akıyor mu? Siteden bir test e-postası gönderin ve DNS'te mail kayıtlarının gri bulutta olduğunu bir kez daha teyit edin.

5. Gerçek IP geliyor mu? WordPress'te bir yorum bırakın ya da güvenlik eklentisinin log ekranına bakın; kayıtlı IP kendi adresiniz olmalı, 104.x ya da 172.6x ile başlayan bir Cloudflare adresi değil.

Bu beş maddenin hepsi geçtiğinde kurulum gerçekten tamamlanmış olur. Saldırı anında devreye alacağınız ek koruma için Cloudflare Under Attack modu yazısına, statik dosyaları farklı bir CDN üzerinden dağıtma seçenekleri için WordPress CDN kurulumu yazısına bakabilirsiniz.

Sıkça Sorulan Sorular#

Cloudflare kurunca e-postalarım neden kesildi?#

Neredeyse her zaman sebep, mail ile ilgili bir DNS kaydının turuncu buluta alınmış olmasıdır. Cloudflare'in proxy'si yalnızca belirli HTTP/HTTPS portlarını taşır; SMTP, IMAP ve POP3 portları bu listede yoktur. mail.siteniz.com gibi kayıtları gri buluta çevirin, MX kayıtlarının işaret ettiği hedeflerin de proxy'siz olduğundan emin olun. Değişiklik dakikalar içinde etkili olur.

Flexible SSL ile Full (Strict) arasındaki fark ziyaretçiye yansır mı?#

Ziyaretçinin tarayıcısında ikisi de yeşil kilit gösterir, görsel bir fark yoktur. Fark, Cloudflare ile sunucunuz arasındaki yolda: Flexible modunda bu bölüm şifresizdir. Ayrıca Flexible, sunucunuz kendi tarafında HTTPS yönlendirmesi yapıyorsa sonsuz yönlendirme döngüsü üretir. Full (Strict) kullanmanız için sunucunuzda geçerli bir sertifika yeterlidir; yoksa Cloudflare'in ücretsiz Origin CA sertifikasını kurabilirsiniz.

Cloudflare wp-admin sayfamı önbelleğe alır mı?#

Varsayılan ayarlarla hayır — Cloudflare HTML içeriğini kendiliğinden önbelleğe almaz, yalnızca statik dosyaları saklar. Risk, hız için "Cache Everything" tipi bir kural oluşturduğunuzda doğar. O durumda /wp-admin/*, /wp-login.php ve /wp-json/* için bypass kuralı yazmanız, üstelik bu kuralı önbellekleme kuralının üstüne koymanız gerekir; Cloudflare ilk eşleşen kuralı uygular.

Güvenlik eklentim tüm ziyaretçileri aynı IP'de görüyor, nasıl düzeltirim?#

Bu, proxy arkasında beklenen davranıştır: sunucunuz artık Cloudflare'in IP'sini görür. Gerçek adres CF-Connecting-IP başlığında taşınır. Sunucu yapılandırmasına erişiminiz varsa Nginx'te real_ip_header, Apache'de mod_remoteip ile kalıcı çözüm sağlarsınız. Paylaşımlı hostingde resmi Cloudflare eklentisinin ziyaretçi IP'sini geri yükleme seçeneği aynı işi görür.

Development Mode'u açık unutursam ne olur?#

Cloudflare bu modu üç saat sonra otomatik olarak kapatır, dolayısıyla kalıcı bir zarar oluşmaz. Ancak açık kaldığı süre boyunca hiçbir istek önbellekten karşılanmaz; tüm trafik doğrudan sunucunuza gider. Yoğun bir sitede bu, sunucu yükünün belirgin şekilde artması ve sayfa açılış sürelerinin uzaması anlamına gelir. Performans ölçümü yapacaksanız modun kapalı olduğundan emin olun.

Cloudflare kullanınca sunucumun IP adresi tamamen gizlenir mi?#

Hayır, bu bir varsayımdır ve çoğu kurulumda yanlıştır. Gri buluta aldığınız her kayıt — özellikle mail kayıtları — gerçek IP'nizi açığa çıkarır. Ayrıca eski DNS geçmişi kayıtları, sunucudan gönderilen e-postaların başlıkları ve sertifika şeffaflık günlükleri de aynı bilgiyi verebilir. Bu yüzden gerçek koruma, güvenlik duvarınızın 80 ve 443 portlarını yalnızca Cloudflare IP aralıklarına açmasıyla sağlanır.