Cloudflare Turuncu Bulut mu Gri Bulut mu? Hangi Kayıt Proxy'lenmeli

Alan adınızı Cloudflare'e taşıdınız. DNS ekranında kayıtların yanında gri bulut ikonları duruyor ve "madem Cloudflare'e geçtim, hepsi turuncu olsun, hepsi korunsun" diye düşünüp tek tek tıkladınız. Ertesi sabah iki şikâyet geliyor: müşterilerden gelen e-postalar ulaşmıyor, muhasebe FTP'ye bağlanamıyor. Sitenin kendisi gayet hızlı çalışıyor, dolayısıyla sorunun Cloudflare'den kaynaklandığı akla bile gelmiyor.

Bu, Cloudflare'e yeni geçen kurulumlarda en sık yapılan tek hamlelik hatadır ve sebebi basittir: turuncu bulut bir "koruma anahtarı" değil, bir "trafik yönlendirme" anahtarıdır. Turuncu yaptığınız kayıt artık sunucunuzun IP'sini değil Cloudflare'in anycast IP'sini döner. Cloudflare de yalnızca HTTP ve HTTPS trafiğini taşır. SMTP, IMAP, FTP, SSH gibi protokoller o IP'de karşılık bulmaz; bağlantı zaman aşımına düşer ya da reddedilir.

Aşağıda kayıt kayıt hangisinin turuncu hangisinin gri olması gerektiğini, kararın arkasındaki teknik sebebi ve turuncu bulutun gerçekten sağladığı güvenlik faydasının nerede bitip nerede yanılsamaya dönüştüğünü ele alıyoruz.

Turuncu Bulut ve Gri Bulut Arasındaki Gerçek Fark#

Cloudflare DNS ekranındaki bulut ikonu yalnızca A, AAAA ve CNAME kayıtlarında görünür ve tek bir soruyu yanıtlar: bu isim sorulduğunda hangi IP dönecek?

• Gri bulut (DNS only): Cloudflare yalnızca yetkili DNS sunucusu gibi davranır. dig sorgusuna sizin sunucunuzun gerçek IP'si döner. Ziyaretçi doğrudan sunucunuza bağlanır. Cloudflare arada hiçbir şey yapmaz — ne önbellek, ne WAF, ne DDoS filtresi, ne SSL sonlandırma.
• Turuncu bulut (Proxied): Cloudflare sorguya kendi anycast IP'sini döner (104.21.x.x, 172.67.x.x gibi). Ziyaretçi Cloudflare'e bağlanır, Cloudflare de arkada sizin sunucunuza gider. Bu sırada önbellekleme, WAF kuralları, bot filtreleri, sıkıştırma ve SSL sonlandırma devreye girer.

Yani turuncu bulut, o hostname için Cloudflare'i araya sokar. Araya girebilmesi için de o protokolü anlaması gerekir. İşte tüm mesele burada düğümlenir.

Bir kaydın gerçekten hangi modda olduğunu panele bakmadan da anlarsınız:

# Gri bulut: gerçek sunucu IP'si döner
dig ornek.com A +short
# 185.51.0.42

# Turuncu bulut: Cloudflare anycast IP'si döner
dig www.ornek.com A +short
# 104.21.63.18
# 172.67.142.90

Turuncu bulutlu bir isim tipik olarak iki IP döner ve bu IP'ler Cloudflare'in bilinen bloklarına aittir. Sorgu tekniklerinin ayrıntısı için dig ve nslookup ile DNS sorgulama yazısına bakabilirsiniz.

Proxy Sadece HTTP ve HTTPS Trafiğine Uygulanır#

Cloudflare'in ücretsiz ve standart planlarında proxy katmanı belirli portlarda dinler. Bu portların dışına çıkan hiçbir bağlantı, turuncu bulutlu bir isim üzerinden hedefe ulaşamaz:

Aşağıdaki portların hiçbiri bu listede yoktur ve turuncu bulutlu bir hostname üzerinden çalışmaz:

Bunu kendi kurulumunuzda basit bir port testiyle görebilirsiniz:

# Gri bulutlu bir mail hostname'inde 587 açık cevap verir
nc -zv mail.ornek.com 587
# Connection to mail.ornek.com 587 port [tcp/submission] succeeded!

# Aynı isim turuncu bulutlu olduğunda
nc -zv mail.ornek.com 587
# nc: connect to mail.ornek.com port 587 (tcp) failed: Connection timed out

Buradaki hata mesajının "timed out" olması önemli bir ipucudur: Cloudflare o portta dinlemediği için paket sessizce düşer. Sunucunuz kapalı olsaydı genellikle "connection refused" alırdınız. Yani mail sunucunuz çalışıyor ama kimse ona ulaşamıyordur.

Kayıt Kayıt Karar Tablosu: Hangisi Turuncu, Hangisi Gri#

Aşağıdaki tablo, tipik bir paylaşımlı hosting veya kendi sunucunuz üzerindeki kurulum için doğrudan uygulanabilir. Sol sütundaki isimler alan adınızın önüne gelir.

Pratik kural şu şekilde özetlenebilir: tarayıcıdan açılan her şey turuncu, geri kalan her şey gri.

Neden mail Kaydını Proxy'lemek E-postaları Kesiyor?#

Bu, tablodaki en pahalı satırdır ve sebebini anlamak, benzer hataları önler.

Diyelim mail.ornek.com kaydını turuncu yaptınız. Artık mail.ornek.com sorgusuna sunucunuzun IP'si değil Cloudflare IP'si dönüyor. Şimdi size mail göndermek isteyen bir sunucunun izlediği yola bakalım:

1. Gönderen sunucu ornek.com için MX kaydını sorar, cevap 10 mail.ornek.com gelir.
2. mail.ornek.com isminin IP'sini sorar, cevap olarak Cloudflare anycast IP'sini alır.
3. O IP'nin 25. portuna SMTP bağlantısı açmaya çalışır.
4. Cloudflare o portta dinlemez. Bağlantı zaman aşımına düşer.
5. Gönderen sunucu birkaç saat boyunca yeniden dener, sonunda pes eder ve gönderene bir bounce mesajı yollar.

Kritik detay şudur: bu süreç sessizdir. Kendi kutunuzdan kendinize mail atarsanız çoğu zaman gider, çünkü mail sunucunuz kendi içinde teslim eder. Web siteniz de sorunsuz çalışmaya devam eder. Sorun yalnızca dışarıdan gelen maillerde ortaya çıkar ve genellikle "acaba spam'e mi düşüyor" diye günlerce yanlış yerde aranır. E-posta teslimatının diğer klasik sebepleri için e-postalarım gelmiyor: MX sorunu yazısı iyi bir kontrol listesi sunar.

Aynı hata gönderim tarafında da ortaya çıkar. Outlook veya Thunderbird mail.ornek.com sunucusuna 587 veya 465 portundan bağlanır; turuncu bulut bu portları da taşımadığı için istemci "sunucuya bağlanılamadı" hatası verir. Kullanıcı şifresini yanlış girdiğini sanıp defalarca dener ve çoğu zaman hesabını kilitler.

Teşhis için doğrudan SMTP el sıkışmasını deneyin:

# Gri bulutta sunucu kendini tanıtır
openssl s_client -connect mail.ornek.com:465 -quiet
# 220 mail.ornek.com ESMTP Postfix

# Turuncu bulutta bağlantı hiç kurulmaz
openssl s_client -connect mail.ornek.com:465 -quiet
# connect: Operation timed out

Çözüm tek tıklıktır: Cloudflare DNS ekranında mail kaydının yanındaki turuncu buluta tıklayıp gri hâle getirin. Değişiklik Cloudflare tarafında anında yayılır; ancak eski cevabı önbelleğe almış gönderen sunucular için TTL süresi kadar beklemek gerekebilir.

MX Kaydında Neden Bulut İkonu Yok?#

Yeni başlayanların takıldığı ikinci nokta budur: MX kaydını eklersiniz ama yanında turuncu/gri anahtarı görünmez.

Sebep, MX kaydının bir IP'ye değil bir isme işaret etmesidir. 10 mail.ornek.com şeklindeki bir MX kaydı yalnızca "mail sunucum şu isimde" der; o ismin hangi IP'ye çözüleceği ayrı bir A kaydının işidir. Dolayısıyla proxy kararı MX kaydında değil, MX'in gösterdiği A kaydında verilir.

Bunun pratik sonucu şudur: MX kaydı doğru olsa bile, hedef A kaydı turuncuysa mail çalışmaz. İki kaydı birlikte kontrol edin:

# 1) MX hangi ismi gösteriyor?
dig ornek.com MX +short
# 10 mail.ornek.com.

# 2) O isim hangi IP'ye çözülüyor?
dig mail.ornek.com A +short
# 104.21.63.18   <- Cloudflare IP'si, MAIL BOZUK
# 185.51.0.42    <- gerçek sunucu IP'si, DOĞRU

Buradan çıkan ikinci bir tuzak var: MX kaydı doğrudan kök alan adını gösteriyorsa. Bazı kurulumlarda MX değeri 10 ornek.com şeklindedir ve kök alan adı web sitesi için turuncudur. Bu durumda mail, web trafiğiyle aynı Cloudflare IP'sine yönlenir ve teslim edilemez. Çözüm, MX'i ayrı bir mail.ornek.com ismine yönlendirip o kaydı gri bırakmaktır. MX kaydının yapısı ve öncelik değerlerinin anlamı için MX kaydı nedir yazısına göz atın.

Aynı mantık SRV ve TXT kayıtları için de geçerlidir: bu tiplerde proxy kavramı yoktur. SPF, DKIM ve DMARC kayıtlarınız Cloudflare'e geçtikten sonra da aynen çalışır — yeter ki eski DNS sağlayıcınızdan taşınırken atlanmasınlar. Bu üçlünün doğru yazımı için SPF, DKIM ve DMARC yazısı referans alınabilir.

cpanel, webmail, ftp ve autodiscover Alt Alan Adları#

Bu dört isim, tabloda "gri" yazmasına rağmen en çok tartışılan satırlardır. Sebepleri ayrı ayrı ele almak gerekir.

cpanel ve whm#

Dikkatli bakarsanız cPanel'in 2083 ve WHM'in 2087 portları Cloudflare'in proxy'lediği HTTPS portları arasındadır. Yani teknik olarak proxy'lenebilirler. Buna rağmen pratikte gri bırakmak doğru tercihtir:

• cPanel oturum açtıktan sonra URL'ye bir oturum belirteci ekleyip yönlendirme yapar; proxy arkasında bu yönlendirmeler sık sık döngüye girer.
• Terminal ve dosya yöneticisi gibi bölümler WebSocket kullanır ve ek yapılandırma ister.
• AutoSSL doğrulaması, proxy'lenen bir hostname üzerinden beklendiği gibi çalışmayabilir. cPanel tarafındaki sertifika yenileme mantığı için AutoSSL nedir yazısına bakabilirsiniz.
• En önemlisi: bir yönetim paneli zaten halka açık olmamalıdır. Doğru yaklaşım proxy'lemek değil, cPanel IP engelleyici ile erişimi kendi IP'nize kısıtlamaktır.

webmail#

Webmail arayüzü 2096 portundan HTTPS ile çalışır ve cPanel ile aynı oturum mekanizmasını paylaşır. Ayrıca webmail genellikle mail ile aynı sunucuya işaret eder; birini turuncu diğerini gri yapmak kafa karışıklığı yaratır. Webmail'e erişim yöntemleri için webmail nasıl girilir yazısı işinizi görür.

ftp#

Tartışmasız gri. FTP, 21. portta kontrol bağlantısı kurar ve veri aktarımı için ayrı portlar açar. Cloudflare bu portların hiçbirini taşımaz. ftp kaydını turuncu yaptığınız anda FileZilla "sunucuya bağlanılamadı" der.

autodiscover ve autoconfig#

Bu kayıtlar 443 portunda HTTPS konuşur, dolayısıyla ilk bakışta proxy'lenebilir görünürler. Fark şuradadır: bu isimler çoğu kurumsal kurulumda başka birinin sunucusuna işaret eder — örneğin Microsoft 365 için autodiscover.outlook.com. Üçüncü taraf bir hedefe giden CNAME'i proxy'lediğinizde Cloudflare, hedef sunucuya kendi Host ve SNI değerleriyle gider; karşı taraf bu isteği tanımaz ve sertifika hatası ya da 404 üretir. Bu kayıtları gri bırakın.

Turuncu Bulutun Gerçek Güvenlik Faydası ve Sınırları#

Turuncu bulutun sağladığı en somut fayda, sunucunuzun gerçek IP adresinin DNS üzerinden görünmemesidir. Bunun pratik karşılığı ciddidir: saldırgan hedef IP'yi bilmediği sürece doğrudan sunucuya paket gönderemez, hacim tabanlı bir DDoS saldırısı Cloudflare'in ağında karşılanır. Uygulama katmanı saldırılarında da WAF kuralları ve bot filtreleri araya girer. Yoğun saldırı anında devreye alınan Under Attack modu da yalnızca proxy'lenen kayıtlar için anlamlıdır.

Ancak bu koruma, hemen yanı başındaki gri kayıtlar yüzünden pratikte sık sık delinir. Origin IP'nizin sızdığı klasik noktalar şunlardır:

Yani turuncu bulut, tek başına "sunucum artık gizli" anlamına gelmez. Bir alt alan adını gri bırakmak zorunda kaldığınız her yerde, aynı IP'yi kullanıyorsanız gizlilik faydası sıfırlanır.

Origin IP Sızıntısını Nasıl Kapatırsınız#

Gizliliğe gerçekten ihtiyaç duyuyorsanız üç adım gerekir ve üçü de DNS ekranının dışındadır.

1. Origin IP'yi değiştirin. Cloudflare'e geçmeden önce alan adınız hangi IP'yi göstermişse, o IP arşivlenmiştir. Hosting sağlayıcınızdan yeni bir IP talep edin; aksi hâlde saldırgan geçmiş kayıtlardan eski IP'yi bulur ve doğrudan bağlanır.

2. E-postayı ayrı bir IP'ye taşıyın. mail kaydı gri kalmak zorundadır, ama web sunucunuzla aynı makinede olmak zorunda değildir. Mail trafiğini ayrı bir sunucuya veya barındırılmış bir e-posta hizmetine taşırsanız, gri kaydın ifşa ettiği IP web sunucunuzun IP'si olmaz.

3. Sunucunuzu yalnızca Cloudflare IP'lerine açın. En etkili adım budur. Web portlarına gelen bağlantıları güvenlik duvarında sadece Cloudflare bloklarına izin verecek şekilde kısıtlarsınız; birileri origin IP'nizi bulsa bile doğrudan bağlanamaz.

# Cloudflare'in güncel IPv4 bloklarını çekip 80/443'e izin ver
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  ufw allow proto tcp from "$ip" to any port 80,443
done

# Ardından herkese açık erişimi kapat
ufw deny 80/tcp
ufw deny 443/tcp

Bu kısıtlamayı uygularken web sunucunuzun ziyaretçi IP'sini doğru görmesi için gerçek IP'yi geri yazması gerekir; aksi hâlde tüm log kayıtlarınız ve IP tabanlı kurallarınız Cloudflare adreslerini gösterir:

# nginx: ziyaretçinin gerçek IP'sini CF-Connecting-IP başlığından al
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... cloudflare.com/ips-v4 listesindeki tüm bloklar
real_ip_header CF-Connecting-IP;

Güvenlik duvarı kurallarını yazarken Cloudflare'in IP listelerinin zaman zaman güncellendiğini unutmayın; bu listeyi periyodik olarak yenileyen bir cron görevi kurmak, bir sabah tüm ziyaretçilerin engellendiğini görmenizi önler.

Değişikliği Doğrulama: Hangi Kayıt Gerçekten Proxy'de?#

Panelde ikonun rengine bakmak yeterli değildir; kaydı yeni değiştirdiyseniz önbellek eski cevabı taşıyor olabilir. İki komutla kesin sonuç alırsınız.

Web tarafında Cloudflare'in araya girip girmediğini yanıt başlıklarından anlarsınız:

curl -sI https://www.ornek.com | grep -iE "server|cf-ray|cf-cache-status"
# server: cloudflare
# cf-ray: 8f2a1c4d5e6b7890-IST
# cf-cache-status: HIT

cf-ray başlığı varsa istek gerçekten Cloudflare üzerinden geçmiştir. Bu başlık yoksa kayıt gri demektir, ikon ne gösterirse göstersin.

Mail tarafında ise doğru sonuç, MX hedefinin gerçek sunucu IP'sini döndürmesidir:

# Tüm mail zincirini tek seferde kontrol et
dig ornek.com MX +short
dig mail.ornek.com A +short
dig ornek.com TXT +short | grep spf

İkinci komutun çıktısı 104. veya 172.6 ile başlıyorsa kayıt hâlâ proxy'dedir ve düzeltilmesi gerekir.

Son bir kontrol noktası: turuncu buluta geçtikten sonra sitede 520, 521 veya 522 hataları görüyorsanız sorun proxy kararında değil, Cloudflare ile origin sunucunuz arasındaki bağlantıdadır. Bu hata kodlarının ayrıştırılması için Cloudflare 520, 521, 522 hataları yazısı doğrudan konuya girer. Cloudflare'in DNS ve CDN katmanının genel işleyişini ise Cloudflare DNS ve CDN kullanımı yazısında toparladık.

Sıkça Sorulan Sorular#

Cloudflare'i açtım, mail gitmiyor. İlk nereye bakmalıyım?#

Önce mail alt alan adının bulut durumuna bakın. Turuncuysa gri yapın. Ardından MX kaydınızın hangi ismi gösterdiğini ve o ismin hangi IP'ye çözüldüğünü kontrol edin: dig ornek.com MX +short ve dig mail.ornek.com A +short. İkinci komutun çıktısı Cloudflare IP'si dönüyorsa mail teslimatı tamamen kesilmiş demektir. MX'in doğrudan kök alan adını gösterdiği kurulumlar da aynı sonucu üretir.

Turuncu bulutu kapattığımda korumamı kaybeder miyim?#

O kayıt için evet. Gri bulutlu bir hostname'de Cloudflare hiçbir filtreleme yapmaz; trafik doğrudan sunucunuza gider. Ancak bu bir tercih değil zorunluluktur: mail, FTP ve SSH gibi protokoller proxy üzerinden zaten geçemez. Doğru yaklaşım, web trafiğini turuncu bırakıp bu servisleri sunucu tarafında güvenlik duvarı kuralları ve IP kısıtlamalarıyla korumaktır.

MX kaydının yanında neden turuncu bulut seçeneği yok?#

Çünkü MX kaydı bir IP'ye değil bir isme işaret eder. Proxy kararı IP döndüren kayıt tiplerinde, yani A, AAAA ve CNAME kayıtlarında verilir. MX yalnızca "mail sunucum şu isimde" der; o ismin hangi IP'ye çözüleceğini ilgili A kaydı belirler. Dolayısıyla proxy kararını MX'in gösterdiği hostname üzerinde vermeniz gerekir.

cpanel ve webmail alt alan adlarını turuncu yapabilir miyim?#

Teknik olarak mümkündür, çünkü 2083 ve 2096 portları Cloudflare'in proxy'lediği HTTPS portları arasındadır. Ancak pratikte önerilmez: cPanel'in oturum belirteçli yönlendirmeleri proxy arkasında döngüye girebilir, WebSocket kullanan bölümler ek yapılandırma ister ve AutoSSL doğrulaması beklendiği gibi çalışmayabilir. Bir yönetim panelini korumanın doğru yolu proxy değil, erişimi kendi IP adresinize kısıtlamaktır.

Turuncu bulut sunucumun IP adresini gerçekten gizler mi?#

DNS üzerinden evet, ama tek başına yeterli değildir. Gri bırakmak zorunda olduğunuz mail, ftp ve cpanel kayıtları aynı sunucuyu gösteriyorsa IP zaten görünür durumdadır. Ayrıca giden e-posta başlıkları, Cloudflare'e geçmeden önceki DNS geçmişi ve sertifika şeffaflık kayıtları da IP'yi ifşa edebilir. Gerçek gizlilik için origin IP'yi değiştirmek, maili ayrı bir sunucuya taşımak ve web portlarını yalnızca Cloudflare bloklarına açmak gerekir.

Bulut durumunu değiştirdim, ne kadar sürede etkili olur?#

Cloudflare tarafında değişiklik neredeyse anında yayılır, çünkü kayıt kendi yetkili sunucularında güncellenir. Gecikme, cevabı daha önce önbelleğe almış çözümleyicilerden kaynaklanır ve kaydın TTL süresi kadar sürer. Cloudflare varsayılan olarak proxy'li kayıtlarda kısa TTL kullandığı için bu genellikle birkaç dakikadır; gri kayıtlarda kendi belirlediğiniz TTL geçerlidir. Test ederken kendi DNS önbelleğinizi de temizlemeyi unutmayın.