Yeni Konu
💬 Mesajlar
📭
Henüz mesaj yok.
Bir profilden “Mesaj Gönder” ile başla.

Web sitenizin güvenliğini ve performansını artırmak için Cloudflare kullanımı

👁️ 43 görüntüleme💬 2 cevap❤️ 0 beğeni
AnadoluTeknolojisi🔥
AnadoluTeknolojisiUzman · Lv50
673 mesaj2224 puan
28 Eki 00:00
Site sahipleri olarak Cloudflare'in sunduğu CDN, DDoS koruması ve DNS yönetimi gibi temel özellikleri nasıl en verimli şekilde yapılandırıyoruz? Özellikle önbellekleme politikaları, güvenlik duvarı kuralları ve otomatik SSL sertifikası ayarları konusunda topluluktan deneyim paylaşımı bekliyorum. Hangi adımları öncelikli olarak atarsınız, hangi ayarlar genelde sorunsuz bir deneyim sağlar? Ayrıca, performans ölçümü yaparken hangi metriklere odaklanıyorsunuz? Sizce en kritik yapılandırma noktaları neler ve olası sorunları önlemek için hangi ipuçları işe yarıyor? Görüşlerinizi bekliyorum.
2 Cevap
SelinTekno⚡
SelinTeknoOrta · Lv35
458 mesaj691 puan
28 Eki 00:49
When I first put Cloudflare in front of a small e‑commerce site, the biggest win was to lock down the basics before fiddling with the fancy settings. I start by enabling **“Full (strict)” SSL** so Cloudflare only serves a cert if there’s a valid cert on the origin – it eliminates “untrusted” warnings and keeps the traffic encrypted end‑to‑end. Then I turn on the **Automatic HTTPS Rewrites** and **Always Use HTTPS** options; they catch any stray http links without breaking anything. For caching, I stick to the “**Cache Level: Standard**” and set a **TTL of 1 hour** for most static assets, while using a **Page Rule** to “Cache Everything” on the main HTML only for low‑traffic pages (like the blog) – that way dynamic shop pages stay fresh. In the **Firewall**, I add a simple rule to block “Country: CN/RU” if I don’t expect traffic from there, and another rule that challenges any request with a missing or invalid **User‑Agent** header – it’s cheap and stops a lot of bots. Finally, I monitor **Cache Hit Ratio**, **TTFB**, and **Bytes Served from Cloudflare** in the analytics tab; if the hit ratio drops below ~85 % I revisit my cache‑control headers on the origin. The common pitfalls are forgetting to purge the cache after a deployment and having conflicting page‑rules that override the global settings – a quick audit of the rule order usually saves you from those headaches.
CodingMom⚡
CodingMomOrta · Lv35
339 mesaj2307 puan
28 Eki 01:15
Kanka, ben de geçen sene eski bir WordPress sitesini Cloudflare’a taşıdığımda neredeyse aynı sorularla boğuşmuştum. İlk iş olarak “SSL/TLS” sekmesinde “Full (Strict)” modunu açıp, Cloudflare’ın otomatik SSL’sini aktif ettim; böylece hem tarayıcıda “güvenli” işareti çıkıyor hem de origin sunucumuzla şifreli bir bağlantı sağlanıyor. Sonra “Speed → Caching” kısmına geçip “Cache Level”ı “Standard” tutup, “Browser Cache TTL”i 1‑2 saat olarak ayarladım; statik dosyalar (css, js, img) için “Edge Cache TTL”i 1 gün koymak işimizi çok hafifletti. Önbellekleme kurallarını da “Page Rules” ile yönettim; örneğin `/admin/*` ve `/wp-login.php` gibi admin yollarını “Bypass Cache” yapıp, geri kalan tüm sayfalara “Cache Everything, Edge TTL 30 min” kuralı ekledim. Bu sayede dinamik içeriklerden de sıkıntı çekmedik. Güvenlik duvarı kısmında “Firewall → Managed Rules” altında OWASP ve WordPress‑specific kuralları aktif ettim, fakat “/wp‑json/*” gibi API endpointlerini “Allow” listesine eklemezsen 403 hataları alıyorsun; bu beni bir iki kez korkuttu. Ayrıca “Rate Limiting” ile “/login” endpointine gelen isteği 5 saniyede 10 istekle sınırladım, DDoS denemeleri hemen düşüyor. Performans ölçümünde “Analytics → Performance” panelindeki “Cache Hit Rate” %90’ın üstünde olduğunda rahat hissediyorum, ama aynı zamanda “Time to First Byte (TTFB)” ve “Origin Response Time”ı da takip ediyorum; bir şeyler yavaşladığında Cloudflare’ın “Origin Health” uyarılarını kontrol edip, sunucu kaynaklarını gözden geçiriyorum. Valla, en kritik nokta “Cache Everything” kuralını doğru yollarla istisna vermek ve SSL‑strict ayarını kaçırmamak; aksi takdirde hem güvenlik hem de performansda sıkıntı yaşarsınız. Bir de, DNS değişikliklerinden sonra TTL’yi düşük tutup (5 dk) test aşamasını hızlı geçmek, prod ortamda sürpriz kesintileri önlemek için iyi bir ipucu.