Node.js Sitenizi Cloudflare Arkasında Yayınlamak: Sertifikalar, Gerçek IP ve Önbellek
Node.js Sitenizi Cloudflare Arkasında Yayınlamak: Sertifikalar, Gerçek IP ve Önbellek
Bu site, ilk günden beri Cloudflare arkasında çalışıyor. Kurulum gerçekten de "ad sunucularını değiştir, turuncu bulutu aç" kadar basit başlıyor — ama ondan sonraki hafta, dokümanlarda pek anlatılmayan sürprizlerle geçiyor: loglarda bütün ziyaretçiler aynı IP'den görünmeye başlıyor, hız sınırlayıcınız masum kullanıcıları engelliyor, bir özellik sayfası tarayıcıda bozuk geliyor çünkü Rocket Loader inline betiğinizi yeniden yazmış. Bu yazıda, kendi kurulumumda tek tek çözdüğüm bu sorunları ve doğru yapılandırmayı anlatıyorum.
SSL modunu doğru seçin: Full (strict) dışındakiler tuzaktır
Cloudflare ile origin (kendi sunucunuz) arasındaki trafiğin nasıl şifreleneceğini SSL/TLS modu belirler:
- Flexible: Ziyaretçi-Cloudflare arası şifreli, Cloudflare-origin arası düz HTTP. Hem güvensizdir hem de sunucunuz HTTPS'e yönlendirme yapıyorsa meşhur "ERR_TOO_MANY_REDIRECTS" döngüsünü üretir.
- Full: Origin'e HTTPS ile bağlanır ama sertifikayı doğrulamaz.
- Full (strict): Origin'de geçerli bir sertifika ister. Doğru seçenek budur.
"Origin'e geçerli sertifika" için ücretli bir sertifikaya gerek yok: Cloudflare panelinden Origin Certificate üretin. Bu, yalnızca Cloudflare'in güveneceği, 15 yıla kadar geçerli ücretsiz bir sertifikadır. Node.js tarafında kullanımı standart HTTPS sunucusundan farksızdır:
const httpsServer = https.createServer({
cert: fs.readFileSync('cloudflare-origin-cert.pem'),
key: fs.readFileSync('cloudflare-origin-key.pem')
}, app);
Tek dikkat: bu sertifikaya yalnızca Cloudflare güvenir. Sunucunuza doğrudan IP ile gelen biri sertifika hatası görür — bu da aslında istediğiniz davranıştır; trafiğin tamamı Cloudflare üzerinden akmalıdır. Daha da sıkısı için sunucu güvenlik duvarında 443 portunu yalnızca Cloudflare'in yayınladığı IP aralıklarına açabilirsiniz.
Gerçek ziyaretçi IP'sini geri kazanın
Cloudflare devreye girdiği anda, uygulamanıza ulaşan her isteğin kaynak IP'si bir Cloudflare sunucusudur. Gerçek ziyaretçi IP'si CF-Connecting-IP başlığında taşınır. Ama bu başlığa körü körüne güvenmek de açıktır: Cloudflare'i atlayıp doğrudan sunucunuza istek atan biri bu başlığı istediği gibi sahteleyebilir.
Doğru yaklaşım iki adımlıdır:
function getClientIP(req) {
const remote = req.socket.remoteAddress;
// 1) İstek gerçekten Cloudflare IP aralığından mı geliyor?
if (isCloudflareIP(remote)) {
// 2) Öyleyse CF-Connecting-IP'ye güvenebiliriz
return req.headers['cf-connecting-ip'] || remote;
}
return remote; // değilse başlığa güvenme
}
Cloudflare, IP aralıklarını cloudflare.com/ips adresinde yayınlar; ben bu listeleri sunucuda tutup arada bir güncelliyorum. Bu kontrolü atlarsanız hız sınırlama, IP engelleme ve analitik gibi IP'ye dayanan her sisteminiz ya çalışmaz ya da kandırılabilir hâle gelir. Express kullanıyorsanız trust proxy ayarının da bu mimariye uygun olması gerekir; aksi hâlde req.ip her zaman Cloudflare'i gösterir.
Rocket Loader ve "sitem neden bozuldu" anları
Cloudflare'in hız özellikleri varsayılan olarak iyi niyetlidir ama agresiftir. Başıma geleni anlatayım: Rocket Loader, sayfadaki betikleri asenkron yüklemek için yeniden sıralar. Benim paylaşım sayfalarımda markdown'ı render eden inline betik, Rocket Loader'ın elinde "Unexpected identifier" hatasıyla çöktü ve sayfalar ham markdown göstermeye başladı.
Çözüm, kritik betikleri bu işlemden muaf tutmaktır:
<script data-cfasync="false">
// Rocket Loader bu betiğe dokunmaz
</script>
Benzer şekilde Auto Minify ve Email Obfuscation da nadiren ama gerçek sorunlar üretebilir. Önerim: bu özellikleri kapalı başlatın, siteniz sorunsuz çalışırken teker teker açın ve her açışta kritik sayfaları kontrol edin. Böylece bir şey bozulduğunda suçluyu hemen bilirsiniz.
Önbelleği bilinçli kullanın
Cloudflare varsayılan olarak yalnızca statik uzantıları (css, js, görseller) önbelleğe alır; HTML sayfalarınız her seferinde origin'e gider. Bu çoğu dinamik site için doğru davranıştır. İnce ayar gerekiyorsa:
- Cache Rules ile belirli yolları (örneğin
/uploads/*) uzun süreli önbelleğe alın. - HTML'i önbelleğe almayı denerseniz, oturumlu kullanıcılara başkasının sayfasını göstermemek için
Vary: Cookieya da "Bypass cache on cookie" kuralını unutmayın. Benim ana sayfam sunucu tarafında render edildiği için anonim ziyaretçilere kısa süreli (max-age=60) önbellek veriyorum; giriş yapmış kullanıcılarda iseno-storedönüyorum. - Dağıttığınız bir CSS/JS dosyasını güncellediğinizde eski sürümün dünyanın dört bir yanındaki uçlarda yaşadığını unutmayın; dosya adına sürüm eki (
style.v12.css) en sağlam çözümdür. Acil durumda panelden "Purge Cache" her zaman elinizin altında.
Küçük ama hayat kurtaran ayrıntılar
- WebSocket kullanıyorsanız (Socket.IO dahil) ek bir şey yapmanıza gerek yok; Cloudflare proxy'si destekler — ama uzun süre boşta kalan bağlantıların yaklaşık 100 saniyede kapatıldığını bilin ve istemcide yeniden bağlanma mantığını hazır tutun.
- Development Mode, geliştirme sırasında önbelleği 3 saatliğine kapatır; "değişikliğim neden görünmüyor" diye saç yolmadan önce bunu açın.
/cdn-cgi/altındaki yollar Cloudflare'e aittir; kendi rotalarınızla çakıştırmayın.- Sunucu loglarınızda hâlâ Cloudflare IP'leri görüyorsanız, log formatınızı gerçek IP fonksiyonunuzu kullanacak şekilde güncellemeyi unutmuşsunuz demektir — benim ilk hafta fark ettiğim şeylerden biri.
Sonuç
Cloudflare, küçük bir siteye büyük altyapı yetenekleri kazandırır: küresel CDN, DDoS koruması, ücretsiz sertifika. Ama "kur ve unut" bir hizmet değildir; araya giren her vekil gibi, IP, şifreleme ve önbellek varsayımlarınızı değiştirir. Özet reçete: SSL modunu Full (strict) yapın, origin sertifikası kurun, gerçek IP'yi doğrulayarak alın, Rocket Loader gibi sihirli özellikleri kontrollü açın ve önbellek kurallarınızı oturumlu kullanıcıları düşünerek yazın. Bu beş maddeyi doğru kurduğunuzda Cloudflare gerçekten görünmez ve sessiz bir güçlendirici olur.
Ek Görseller
