Cloudflare nedir?
Cloudflare, alan adınızın DNS yönetimini üstlenen ve ziyaretçi isteklerini kendi sunucu ağı üzerinden kaynak sunucunuza taşıyan bir ara katmandır. Teknik karşılığı ters proxy: ziyaretçi doğrudan sitenizin sunucusuna bağlanmaz, kendisine coğrafi olarak yakın bir Cloudflare veri merkezine bağlanır. İstek orada denetlenir, önbellekten karşılanabiliyorsa oradan karşılanır, karşılanamıyorsa sunucunuza iletilir.
Tek bir üründen değil, aynı panelden yönetilen üç işlevden söz ediyoruz: alan adınızın yetkili DNS sunuculuğu, statik dosyaları dağıtan içerik dağıtım ağı (CDN) ve gelen trafiği süzen güvenlik katmanı. Ağ 300'ü aşkın şehre yayılmış durumda, bu yüzden "yakın sunucu" ifadesi çoğu ülke için gerçekten yakın bir noktayı tarif eder.
Cloudflare bir barındırma hizmeti değildir. Site dosyalarınız kendi sunucunuzda durmaya devam eder; Cloudflare o sunucunun önüne yerleşen trafik katmanıdır. Alan adı eklemek ve ad sunucusu çevirmek siteyi Cloudflare'e taşımak anlamına gelmez.
Trafik Cloudflare üzerinden nasıl akar?
Akışı belirleyen tek şey DNS kayıtlarının proxy durumudur. Panelde her A, AAAA ve CNAME kaydının yanında bir bulut simgesi bulunur. Simge turuncuysa kayıt proxy altındadır: o ada yapılan DNS sorgusuna sunucunuzun gerçek IP adresi yerine Cloudflare'in anycast IP adresleri döner ve HTTP trafiği ağdan geçer. Simge griyse kayıt yalnızca DNS modundadır, sorguya kaynak IP adresiniz döner ve trafik Cloudflare'e hiç uğramaz.
Bu ayrım kurulumun en pratik kuralını doğurur: web trafiği taşıyan kayıtlar proxy altında olmalı, taşımayanlar olmamalıdır. Proxy altındaki kayıtlarda kaynak IP adresiniz gizlenir, güvenlik duvarı kuralları ve önbellek devreye girer. Yalnızca DNS modundaki her kayıt ise kaynak IP adresinizi sorgulayan herkese açık bırakır ve hedefli saldırılara karşı bir koruma katmanını kaldırır.
Önbellek tarafında yaygın bir yanlış anlama var. Cloudflare varsayılan olarak MIME tipine değil dosya uzantısına bakarak önbellekleme yapar ve HTML ile JSON içeriğini varsayılan ayarlarla önbelleğe almaz. Görseller, CSS, JavaScript, yazı tipleri, PDF ve arşiv dosyaları uç sunuculardan servis edilir; sayfa HTML'i her istekte sunucunuzdan çekilir. HTML'i de önbelleğe almak isterseniz bunu ayrı bir önbellek kuralıyla açmanız gerekir, ki bu kararın kendi bedelleri var: agresif önbellek ayarlarının nerede tersine döndüğünü ayrıca ele aldık.
Ücretsiz plan gerçekte neyi kapsıyor?
Ücretsiz plan bir deneme süresi değil, kalıcı bir katman. Kapsamında yetkili DNS hizmeti, ölçüsüz DDoS koruması, CDN, Universal SSL sertifikası ve ücretsiz yönetilen güvenlik duvarı kural seti bulunuyor. Kredi kartı istemez, süre sınırı yoktur.
Kapsam dışında kalanlar da nettir. Kayıpsız görsel optimizasyonu, genişletilmiş güvenlik kural setleri ve çalışma süresi taahhüdü ücretli katmanlara ayrılmış durumda. Pro planı yıllık ödemede aylık 20 dolar, aylık ödemede 25 dolar; Business planı yıllık ödemede aylık 200 dolar, aylık ödemede 250 dolar seviyesinde. Bu fark küçük ölçekli bir kurumsal site için genellikle gerekçelendirilemez. Makul yol ücretsiz planla başlamak, ihtiyaç somutlaştığında yükseltmektir.
Dikkat çeken bir ayrıntı: HTTP/3 desteği ücretli katmana bağlı değil, ücretsiz planda da panelden açılabilen bir ayar. Bu, protokol tarafındaki kazancı bütçeden bağımsız hale getiriyor. HTTP/3 ve QUIC'in ne değiştirdiğini ayrı bir rehberde anlattık.
Cloudflare kurulumu adım adım
Kurulum kod yazmayı gerektirmez; işin özü alan adının yetkili ad sunucularını Cloudflare'e devretmektir. Sıra şöyle işler:
- Cloudflare hesabı açın ve panelden alan adınızı kök haliyle ekleyin (www olmadan, alanadi.com biçiminde). Plan seçiminde Free yeterlidir.
- Otomatik tarama mevcut DNS kayıtlarınızı panele aktarır. Bu tarama tüm kayıtları bulmayı garanti etmez, bu yüzden listeyi eski sağlayıcınızdaki kayıtlarla tek tek karşılaştırın. Eksik kalan bir kayıt, devir tamamlandığı anda o servisin çözümlenmesini keser.
- Web trafiği taşıyan kayıtları proxy altında bırakın, e-posta ve alan adı doğrulama kayıtlarını yalnızca DNS modunda tutun.
- Alan adınızda DNSSEC etkinse ad sunucularını değiştirmeden önce kayıt firmanızın panelinden DNSSEC'i kapatın. Bu adım atlanırsa alan adı erişilemez hale gelebilir.
- Cloudflare'in verdiği iki ad sunucusu adını kayıt firmanızın panelinde eski ad sunucularının yerine yazın. Adların birebir kopyalanması gerekir, tek harflik fark çözümlemeyi bozar.
- Yayılmayı bekleyin. Cloudflare bu süre için 24 saate kadar bir pencere veriyor. Alan adı etkinleştiğinde panelde durum Active görünür ve hesabınıza bildirim e-postası gelir.
- Alan adı etkin duruma geçtikten sonra DNSSEC'i bu kez Cloudflare panelinden yeniden açın.
Devrin gerçekten tamamlandığını beklemeden görmek isterseniz kendi makinenizden sorgulayabilirsiniz:
dig ns alanadi.com @1.1.1.1
whois alanadi.comSorgu Cloudflare'in ad sunucularını döndürüyorsa delegasyon yerine oturmuştur. Tarayıcıdan çalışan DNS kontrol siteleri önbelleklenmiş sonuç gösterdiği için doğrudan sorgu daha güvenilir bir cevap verir.
SSL/TLS modu neden yanlış seçiliyor?
Cloudflare iki ayrı bağlantıyı aynı anda yönetir: ziyaretçi ile Cloudflare arasındaki bağlantı ve Cloudflare ile kaynak sunucunuz arasındaki bağlantı. Şifreleme modu ikincisinin nasıl kurulacağını belirler. Yeni alan adlarında varsayılan Automatic SSL/TLS'tir; Cloudflare sitenizi kendi denetleyicisiyle tarayıp uygun modu seçmeye çalışır.
Sorunlu olan mod Flexible. Bu modda Cloudflare kaynak sunucunuza şifresiz HTTP ile bağlanır. Sunucunuz HTTP isteklerini otomatik olarak HTTPS'e yönlendiriyorsa, ki çoğu modern kurulum yönlendirir, kapalı bir döngü oluşur: Cloudflare isteği HTTP'ye çevirir, sunucu HTTPS'e geri gönderir, tarayıcı bir süre sonra ERR_TOO_MANY_REDIRECTS hatası verir. Site aniden tamamen açılmaz hale gelir ve nedeni ilk bakışta Cloudflare'de aranmaz.
Çözüm iki yönlüdür: ya kaynak sunucudaki HTTPS yönlendirmesi kaldırılır ya da mod Full veya Full (strict) seviyesine çıkarılır. Cloudflare, kaynak sunucuya kötü niyetli bağlantıları engellemek için Full ya da Full (strict) kullanılmasını öneriyor; bu da sunucuda geçerli bir sertifika bulunmasını gerektiriyor. Aynı döngü ters yönde de mümkün: mod Full iken sunucu HTTPS isteklerini HTTP'ye yönlendiriyorsa hata yine çıkar. Kurulumdan sonra sertifikayı ve güvenlik başlıklarını uçtan uca kontrol etmek bu sınıftaki hataları erken yakalar.
E-posta kayıtları ve kaynak IP adresi
MX ve TXT kayıtları proxy altına alınamaz, Cloudflare bu tipleri her zaman yalnızca DNS modunda tutar. Yani panelde MX kaydının bulutunu turuncuya çevirme ihtimaliniz zaten yok. Asıl kırılma noktası başka yerde: MX kaydınızın işaret ettiği posta sunucusu adının (çoğunlukla mail.alanadi.com gibi bir alt alan adı) A kaydı proxy altına alınırsa o ad Cloudflare IP adreslerine çözülür ve posta trafiği hedefini bulamaz. Cloudflare'in kendi kurulum belgesi bu A kaydını yalnızca DNS modunda gösterir.
Bunun görünmeyen bir bedeli var. Yalnızca DNS modundaki her kayıt kaynak sunucunuzun gerçek IP adresini herkese açar. Posta sunucunuz web sunucunuzla aynı makinedeyse, saldırgan posta kaydından IP adresini bulup proxy katmanını atlayarak doğrudan sunucuya gidebilir. Posta trafiğini ayrı bir IP adresine veya harici bir posta sağlayıcısına taşımak bu açığı kapatır ve kurumsal sitelerde ihmal edilmemesi gereken bir adımdır.
SEO tarafında ne kazanılır ne riske girer?
Kazanç tarafının mekanizması açık. Statik dosyalar ziyaretçiye coğrafi olarak yakın bir uç sunucudan geldiği için yükleme süresi kısalır ve fark en çok sunucusu tek ülkede duran ama yurt dışından ziyaretçi alan sitelerde görünür. Google'ın tarayıcısı da bu tabloya duyarlıdır: site tutarlı ve hızlı yanıt verdikçe tarama hacmi yukarı gider. Sayfa hızıyla uğraşan ekipler için ağ katmanı, LCP süresini aşağı çekme çalışmasının altyapı ayağıdır.
Risk tarafı daha az konuşuluyor ve tamamı yapılandırma kaynaklı. Üç başlıkta toplanabilir.
Bot kurallarının aşırı sıkılaştırılması. Google'ın kendi belgeleri, site 5xx sunucu hataları veya HTTP 429 gibi hız sınırlama sinyalleri döndürdüğünde tarama hızının düşürüldüğünü söylüyor. Cloudflare tarafında yazacağınız agresif bir hız sınırı ya da özel güvenlik duvarı kuralı arama motoru tarayıcısına bu sinyalleri döndürürse taranma hacminiz sessizce daralır. Cloudflare doğrulanmış botları varsayılan bot yapılandırmalarının dışında tuttuğunu belirtiyor, dolayısıyla kutudan çıktığı haliyle sorun beklenmez. Risk, sizin elle yazdığınız kurallarda doğar.
Bot Fight Mode'un baypas edilemezliği. Ücretsiz planda açılabilen bu özellik, güvenlik duvarı özel kuralları veya sayfa kurallarıyla atlanamaz. Ayrı bir değerlendirme hattında çalıştığı için Skip ve Allow eylemleri ona işlemez ve API ile mobil uygulama trafiğine doğrulama sorusu gönderebilir. İstisna tanımlamanız gereken bir trafik varsa (kendi API istemcileriniz, izleme araçlarınız) kural motoru üzerinde çalışan Super Bot Fight Mode'a geçmek gerekir. Sitenizi dışarıdan izleyen bir servis kullanıyorsanız kesinti izleme aracınızın bu filtreye takılmadığını kurulumdan hemen sonra doğrulayın.
Yapay zeka bot politikaları. Cloudflare yapay zeka botlarını davranışa göre üç grupta ayırıyor: içeriğinizi sonradan soruları yanıtlamak için indeksleyen Search, kullanıcı adına gerçek zamanlı hareket eden Agent ve model eğiten Training. Her grup ayrı ayrı engellenebiliyor. Search grubunu engellemek, içeriğinizin yapay zeka yanıtlarında kaynak olarak kullanılma ihtimalini doğrudan keser; yalnızca eğitim amaçlı taramayı durdurmak isteyip yanlış kutuyu işaretlemek bu yüzden geri dönüşü olan ama fark edilmesi zor bir hatadır. Cloudflare 15 Eylül 2026 sonrasında eklenen yeni alan adlarında varsayılanı değiştireceğini duyurdu: Training ve Agent sınıfındaki botlar reklam gösteren sayfalarda engellenecek, Search sınıfı açık kalacak. Kurulumdan sonra bu ekranı görmeden bırakmayın.
Kimin Cloudflare'e ihtiyacı var kimin yok?
Açık ihtiyaç şu profillerde: ziyaretçilerinin önemli bölümü sunucusundan farklı bir ülkede veya kıtada olan siteler, saldırı yüzeyi geniş e-ticaret ve haber siteleri, tek sunucuda çalışan ve trafik zirvelerinde zorlanan projeler, kaynak IP adresini gizlemek isteyen kurumsal siteler. Bu profillerde ücretsiz plan bile ölçülebilir fark yaratır.
Gerek duymayanlar da var. Kendi dağıtım ağını hizmete dahil eden yönetilen bir platformda barınan siteler ikinci bir proxy eklediğinde önbellek davranışını gereksiz yere karmaşıklaştırır ve hata ayıklama zorlaşır. Ziyaretçisinin tamamı tek şehirde olan küçük bir tanıtım sitesinde hız kazancı fark edilir düzeyde olmayabilir. Kurumsal politikası gereği DNS yönetimini kendi kayıt firmasında tutmak zorunda olan yapılar için de ad sunucusu devri zorlama bir çözümdür.
Karar kriterini üç soruya indirebilirsiniz: ziyaretçi coğrafyanız yayılmış mı, sunucunuz tek mi, siteniz düzenli bot trafiği alıyor mu? En az birine evet diyorsanız katman kazandırır. Üçüne de hayırsa aciliyet yoktur ve mevcut kurulumu bozmamak daha akıllıcadır.
Sık sorulanlar
Cloudflare hosting yerine geçer mi?
Geçmez. Dosyalarınız kendi sunucunuzda kalır, Cloudflare o sunucunun önünde duran DNS ve trafik katmanıdır. İkisi birbirinin alternatifi değil tamamlayıcısıdır. Cloudflare'in uygulama çalıştırmayı sağlayan ayrı ürünleri bulunsa da alan adı eklemek bu ürünleri kullanmakla aynı şey değildir.
Cloudflare WARP siteme kurulur mu?
Kurulmaz, çünkü WARP site sahipleri için değil son kullanıcılar için tasarlanmış ayrı bir üründür. Telefona veya bilgisayara kurulur ve o cihazın internet trafiğini Cloudflare ağı üzerinden taşır. Marka adı ortak olduğu için sık karıştırılıyor. Sitenizin hızlanması ve korunması için WARP'a ihtiyacınız yok.
Ad sunucusu değişikliği sitede kesinti yaratır mı?
Kesinti riski değişimin kendisinden değil eksik kayıttan doğar. Cloudflare, doğru kayıtlar tanımlanmadan alan adı etkinleştirilirse ziyaretçilerin çözümleme hatası alabileceğini belirtiyor. Bu yüzden ad sunucusunu çevirmeden önce eski panelin kayıt listesinin ekran görüntüsünü almak ve yeni listeyi satır satır karşılaştırmak pratik bir sigortadır. İkinci risk DNSSEC: kapatılmadan yapılan devir alan adını tamamen erişilemez bırakabilir.
Cloudflare'den geri dönmek mümkün mü?
Mümkün ve işlem kurulumun tersidir. Kayıt firmanızın panelinde ad sunucularını eski değerlerine çevirirsiniz, yayılma tamamlandığında trafik Cloudflare'e uğramadan doğrudan sunucunuza gitmeye başlar. Dönüşten önce iki şeye bakın: DNS kayıtlarınızın güncel hali eski sağlayıcıda da tanımlı olmalı ve Cloudflare tarafında DNSSEC açıksa devirden önce kapatılmalı. Aksi halde alan adı geçiş süresince çözümlenemez.
