Web Sitelerinde HTTP/3 (QUIC) Etkinleştirme Rehberi: Nginx + Cloudflare ile Daha Hızlı ve Dayanıklı Bağlantı

HTTP/3 Nedir ve Neden Önemli?

HTTP/3, web trafiğinin yeni nesil taşıma katmanı olarak TCP yerine UDP üzerinde çalışan QUIC protokolünü kullanır. Kulağa “sadece bir sürüm yükseltmesi” gibi gelse de etkisi pratiktir: bağlantı kurulumu daha hızlıdır, paket kaybı yaşandığında toparlanma daha akıllıdır ve aynı bağlantı üzerinde birden fazla istek gönderirken (multiplexing) TCP’nin “head-of-line blocking” sorununu önemli ölçüde azaltır. Mobil ağlar, Wi‑Fi’dan hücresel ağa geçiş gibi sık bağlantı değişimlerinin olduğu senaryolar ve yüksek gecikmeli hatlar HTTP/3’ten ciddi fayda görür.

Bu rehberde, HTTP/3’ü üretim ortamına yakın bir şekilde devreye almak için en pratik iki adımı ele alacağız: Cloudflare üzerinden hızlı aktivasyon ve Nginx tarafında doğru yapılandırma. Amaç, hem gerçek kullanıcı performansını artırmak hem de modern tarayıcıların sunduğu bağlantı optimizasyonlarından yararlanmak.

Ön Koşullar ve Kapsam

HTTP/3 etkinleştirmeden önce şunlara ihtiyacınız var: HTTPS (geçerli TLS sertifikası), alan adınızın DNS kontrolü ve tercihen CDN/Reverse Proxy katmanı. Cloudflare kullanıyorsanız süreç oldukça kolaylaşır çünkü HTTP/3 desteği edge katmanında sunulur. Nginx tarafında HTTP/3 doğrudan “klasik” paketlerle her dağıtımda aynı şekilde gelmeyebilir; bu nedenle burada daha çok doğru mantığı ve yapı taşlarını anlatacağım. Dağıtımınıza göre (Ubuntu, Debian, AlmaLinux vb.) paket isimleri ve sürümler değişebilir.

1) Cloudflare Üzerinden HTTP/3’ü Açma

En hızlı yol Cloudflare’dır: Cloudflare, istemci ile Cloudflare arasındaki bağlantıda HTTP/3’ü açar ve origin sunucunuza (Nginx/Apache) olan bağlantıyı ayrı şekilde yönetir. Böylece origin tarafında HTTP/3 hazır olmasa bile ziyaretçi tarafında kazanım elde edebilirsiniz.

Adımlar: Cloudflare paneline girin, ilgili alan adını seçin. Network (Ağ) sekmesinde HTTP/3 (with QUIC) seçeneğini bulun ve etkinleştirin. Ardından SSL/TLS kısmında modun en az “Full” (tercihen “Full (strict)”) olduğundan emin olun. HTTP/3, HTTPS olmadan zaten çalışmaz; bu adım kritik.

Bu noktadan sonra tarayıcılar, destekliyorsa Cloudflare edge ile HTTP/3 konuşmaya başlar. Ancak bazı durumlarda tarayıcının HTTP/3’e daha hızlı geçmesi için Alt-Svc duyurusu gerekir; Cloudflare bu başlığı genellikle otomatik yönetir.

2) Origin Sunucuda (Nginx) HTTP/3 Hazırlığı

Cloudflare kullanıyor olsanız bile origin tarafını modern tutmak iyi bir pratiktir. Özellikle Cloudflare’siz bir alt alan adı, özel bir edge senaryosu veya farklı CDN kullanımında origin’in HTTP/3 konuşabilmesi değerli olabilir. Nginx dünyasında HTTP/3 desteği, sürüme ve derleme seçeneklerine bağlıdır. Bazı dağıtımlar hazır paket sunarken, bazıları için HTTP/3 özellikli build gerekebilir.

Konsept olarak HTTP/3 için iki temel ihtiyaç vardır: UDP 443 portunun açık olması ve Nginx’in QUIC/HTTP/3 desteğiyle çalışması. Geleneksel HTTPS trafiği TCP/443’te kalırken, HTTP/3 UDP/443 üzerinden gelir. Bu yüzden güvenlik duvarınızda yalnızca TCP/443 açıksa HTTP/3 çalışmaz.

3) Güvenlik Duvarı ve Ağ Ayarları (UDP 443)

Sunucunuzun güvenlik duvarında UDP 443 trafiğine izin verin. Örnek olarak UFW kullanan bir sistemde mantık şudur: TCP 443 zaten açıktır, buna ek olarak UDP 443’ü de açmanız gerekir. Kurumsal ortamlarda load balancer, WAF veya güvenlik cihazlarının UDP trafiğini engellemediğinden emin olun. Aksi halde tarayıcı HTTP/3 denese bile geri düşerek HTTP/2 veya HTTP/1.1’e döner.

4) Nginx Konfigürasyonu: Dinleme ve Alt-Svc Mantığı

HTTP/3’ün “aktif” görünmesi için tarayıcıların bunu keşfetmesi gerekir. Bu genelde Alt-Svc başlığı ile yapılır. Mantık şudur: Sunucu, “aynı host için şu protokol ve port üzerinden de hizmet verebilirim” diye tarayıcıya duyuru yapar. Böylece tarayıcı sonraki isteklerde HTTP/3’e geçer.

Nginx tarafında (HTTP/3 destekli bir build varsayımıyla) tipik yaklaşım; TCP/443 üzerinde HTTP/2’yi açık tutarken aynı zamanda UDP/443 üzerinde QUIC/HTTP/3 dinlemektir. Konfigürasyonun detayı sürüme göre değişse de kontrol etmeniz gerekenler şunlardır: 443 portunda hem TCP hem UDP dinleme, TLS ayarlarının doğru olması, ve yanıt başlıklarında Alt-Svc duyurusunun bulunması. Alt-Svc örneği genellikle “h3=\":443\"; ma=...” gibi bir değer taşır; “ma” süresi tarayıcının bu bilgiyi ne kadar cache’leyeceğini belirler.

Ek olarak, HTTP/3 ile birlikte TLS 1.3 pratikte standarttır. Bu nedenle TLS yapılandırmanızın güncel olduğundan, eski şifre kümelerine bel bağlamadığınızdan ve sertifika zincirinizin doğru sunulduğundan emin olun.

5) Doğrulama: HTTP/3 Çalışıyor mu?

Değişikliklerden sonra test etmek önemlidir. En pratik yöntemlerden biri Chromium tabanlı tarayıcılarda geliştirici araçlarıdır: Network sekmesinde ilgili isteğin “Protocol” alanında h3 veya benzeri bir ifade görmeniz beklenir. Alternatif olarak komut satırında HTTP/3 destekli bir istemci ile (örneğin h3 destekli curl varyantları veya özel test araçları) hedef URL’yi sorgulayabilirsiniz. Eğer HTTP/3 devreye girmiyorsa genellikle sorunlar üç noktada toplanır: UDP 443 kapalı, Alt-Svc duyurusu yok veya proxy/CDN katmanının ayarları.

6) Performans ve SEO Açısından Etkisi

HTTP/3 tek başına “SEO puanı” veren bir sihir değildir; ancak hız ve kararlılık üzerinden dolaylı katkı sağlar. Daha hızlı bağlantı kurulumu ve özellikle mobil ağlarda daha stabil veri akışı, Core Web Vitals metriklerine olumlu yansıyabilir. Ayrıca modern tarayıcılar HTTP/3’e geçebildiğinde, yoğun istekli sayfalarda kullanıcı deneyimi daha tutarlı hale gelir. Yine de unutmayın: asıl kazanç; görsel optimizasyonu, doğru cache stratejisi, sıkıştırma (Brotli), kritik CSS ve iyi bir CDN kurgusu ile birlikte gelir. HTTP/3 bu zincirin güçlü bir halkasıdır.

Sonuç

HTTP/3 (QUIC), özellikle mobil kullanıcıların yoğun olduğu sitelerde ve gecikmenin hissedildiği bölgelerde gerçek fayda sağlayan modern bir yükseltmedir. Cloudflare kullanıyorsanız birkaç tıkla devreye alabilir, Nginx tarafında ise UDP 443, doğru TLS yaklaşımı ve Alt-Svc duyurusunun mantığını kavrayarak kalıcı bir kurulum planlayabilirsiniz. İyi bir test ve ölçüm süreciyle HTTP/3’ün sitenize etkisini net şekilde görür, gerektiğinde HTTP/2 ile birlikte hibrit bir yapı kullanarak en geniş uyumluluğu korursunuz.

Android’de DNS over HTTPS (DoH) ile Reklam ve Takipçi Engelleme: AdGuard DNS Kurulumu ve Testi

DNS’i değiştirmek neden fark yaratır?

Akıllı telefonlarda reklam ve takipçi trafiğinin önemli bir kısmı, uygulamalar daha içerik yüklemeden önce DNS sorguları üzerinden başlar. DNS (Alan Adı Sistemi), bir alan adını (ör. example.com) IP adresine çeviren katmandır. Eğer reklam ağlarına ve bilinen takip alan adlarına giden DNS sorgularını daha baştan durdurursanız, hem tarayıcıda hem de uygulamalarda gereksiz istekler azalır; veri tüketimi ve pil kullanımı düşebilir.

Son yıllarda bu konuda öne çıkan yaklaşım DNS over HTTPS (DoH) oldu. DoH, DNS sorgularını HTTPS tüneli içinde taşıyarak operatör/yerel ağ seviyesinde “DNS dinleme ve yönlendirme” riskini azaltır. Android 9 ve sonrası sürümlerdeki Özel DNS özelliğiyle, ekstra uygulama kurmadan DoH/DoT tabanlı bir DNS sağlayıcısına bağlanmak mümkün.

Bu rehberde ne kuracağız?

Bu yazıda Android’in yerleşik “Özel DNS” ayarını kullanarak AdGuard DNS yapılandırmasını yapacağız. Hedef: reklamlara ve temel takipçilerin bir kısmına karşı sistem genelinde ek bir filtre katmanı eklemek. Bu yöntem, klasik reklam engelleyiciler gibi sayfa içi öğeleri “gizlemez”; reklam alan adını çözümleyemediği için içeriğin yüklenmesini engellemeye çalışır. Sonuç, çoğu senaryoda gözle görülür hızlanma ve daha temiz bir deneyimdir.

Gereksinimler

Android 9 (Pie) ve üzeri önerilir. Android 9+ cihazlarda “Özel DNS” ayarı standarttır. Ayrıca internet bağlantınızın olduğu bir anı seçin; DNS değişikliği sonrası bağlantı testi yapacağız.

Adım adım: Android’de AdGuard DNS (DoH/Özel DNS) kurulumu

1) Ayarlar uygulamasını açın ve arama kısmına Özel DNS yazın. Bazı cihazlarda yol şu şekilde olabilir: Ağ ve İnternet > Gelişmiş > Özel DNS.

2) Özel DNS sağlayıcı ana bilgisayar adı seçeneğini işaretleyin. Buraya DNS sağlayıcısının alan adını gireceğiz. AdGuard DNS için yaygın seçenek: dns.adguard.com.

3) Kaydedin ve bir iki saniye bekleyin. Android, arka planda bağlantıyı doğrular. “Bağlandı” benzeri bir durum görmüyorsanız bile kaydetme başarılıysa çoğu cihazda aktif hale gelir.

4) Uçak modunu aç/kapat yaparak ya da Wi‑Fi’ı kapatıp açarak DNS önbelleğini hızlıca tazeleyebilirsiniz. Bu şart değildir ama ilk kurulumda işe yarar.

Kurulumun çalıştığını nasıl test edersiniz?

1) Basit tarayıcı testi: Daha önce yoğun reklam gösteren bir haber sitesine girin. Sayfanın daha hızlı açıldığını veya bazı reklam alanlarının boş kaldığını gözlemleyebilirsiniz. Ancak unutmayın: DNS tabanlı engelleme “her şeyi” temizlemez; özellikle aynı alan adı üzerinden servis edilen (first-party) reklamlar yine gelebilir.

2) DNS sızıntısı ve DoH kontrolü: Tarayıcı üzerinden DoH testi yapan güvenilir sitelerle sorguların hangi DNS üzerinden gittiğini kontrol edebilirsiniz. Her test sitesi aynı sonucu vermeyebilir; bazıları tarayıcı DoH’unu, bazıları sistem DNS’ini ölçer. Buradaki amaç, “Özel DNS” sonrası sistem genelinde DNS sağlayıcısının değiştiğini teyit etmektir.

3) Uygulama içi reklamlar: Ücretsiz bir oyunu veya reklamlı bir uygulamayı açın. Reklamların tamamen kaybolması garanti değil; fakat çoğu reklam çağrısı DNS seviyesinde bloke edildiğinde reklam yüklenemeyebilir ya da gecikebilir.

Performans, gizlilik ve olası yan etkiler

Performans: Daha az istek, daha az izleyici betiği ve daha düşük veri tüketimi bekleyebilirsiniz. Öte yandan bazı DNS sağlayıcıları belirli bölgelerde daha yavaş olabilir. Gecikme hissederseniz alternatif bir DoH/DoT sağlayıcısıyla kıyaslamak mantıklıdır.

Gizlilik: DoH, yerel ağdaki gözlemcilerin DNS trafiğinizi okumasını zorlaştırır; ancak tüm güveni DNS sağlayıcısına verirsiniz. Bu nedenle, hangi şirketin politikasına güvendiğinizi seçmek önemlidir.

Yan etkiler: Bazı bankacılık uygulamaları, içerik filtreleme tespit ettiğinde sorun çıkarabilir. Ayrıca bazı sitelerde giriş, ödeme veya yorum gibi servisler üçüncü taraf alan adlarına dayanır; bu alan adları engellenirse sayfanın bir bölümü çalışmayabilir. Böyle bir durumda “Özel DNS”i geçici olarak kapatıp sorunun DNS kaynaklı olup olmadığını hızlıca anlarsınız.

İleri seviye ipuçları

1) Hız ve tutarlılık için karşılaştırma: Aynı ağda (Wi‑Fi) bir hafta AdGuard DNS, bir hafta farklı bir sağlayıcı deneyerek pil, veri ve hız farkını gözlemleyin. Android’de “Özel DNS” değişimi hızlıdır; geri dönüş kolay.

2) Tarayıcı tarafını güçlendirin: DNS engelleme, “temel katman”dır. Daha temiz bir deneyim için tarayıcıda içerik engelleme eklentileri veya izleyici koruması olan bir tarayıcıyla birleştirmek, özellikle sayfa içi yerleşimler ve çerez banner’larında daha iyi sonuç verir.

3) Sorun giderme: İnternet tamamen kesilirse önce alan adını doğru yazdığınızı kontrol edin (dns.adguard.com). Ardından mevcut VPN/kurumsal profil/özel güvenlik uygulamalarının “Özel DNS” ile çakışıp çakışmadığını inceleyin.

Sonuç

Android’in yerleşik “Özel DNS” özelliğiyle AdGuard DNS kullanmak, ekstra uygulama yüklemeden sistem genelinde reklam ve takip trafiğinin bir kısmını azaltmanın pratik bir yoludur. DoH sayesinde DNS sorgularınız şifreli taşınır; bu da özellikle halka açık Wi‑Fi ağlarında ek bir güvenlik ve gizlilik katmanı sağlayabilir. Tam bir reklam engelleyici olmasa da, hızlı kurulum ve düşük bakım ihtiyacıyla günlük kullanımda fark edilir bir iyileştirme sunar.

Local AI Dönemi: Ollama ile Bilgisayarında LLM Çalıştırma ve Open WebUI ile ChatGPT Benzeri Arayüz Kurma

Yerelde LLM çalıştırmak neden yeniden gündemde?

Bulut tabanlı yapay zekâ servisleri hızlı ve pratik; ancak veri gizliliği, abonelik maliyetleri ve hız dalgalanmaları gibi konular yüzünden “yerel AI” tekrar yükselişte. Özellikle metin üretimi, kod yardımı, özetleme ve belge sorgulama gibi işlerde, bilgisayarında çalışan bir LLM (Large Language Model) çoğu senaryoda yeterli olabiliyor. Bu yazıda, Ollama ile yerel model çalıştırmayı ve Open WebUI ile tarayıcıdan erişilen modern bir sohbet arayüzü kurmayı adım adım anlatıyorum.

Ön koşullar: Donanım ve işletim sistemi

Ollama; macOS, Linux ve Windows üzerinde çalışabiliyor. Temel gereksinim RAM tarafında. Küçük modeller için 8 GB RAM ile başlanabilir; daha rahat kullanım için 16 GB ve üzeri önerilir. GPU şart değil, ancak güçlü bir GPU (özellikle NVIDIA) hız avantajı sağlar. Depolama tarafında ise model dosyaları birkaç GB’tan başlayıp çift haneli GB seviyelerine çıkabildiği için en az 20–30 GB boş alan iyi olur.

1) Ollama kurulumu

Ollama’nın amacı, yerel LLM çalıştırmayı “tek komut” kadar kolay hale getirmek. Kurulum yöntemleri işletim sistemine göre değişir; en güncel adımlar için Ollama’nın resmi sitesine göz atmak mantıklı. Kurulum tamamlandıktan sonra komut satırından Ollama’nın çalıştığını doğrulayabilirsiniz. macOS/Linux’ta genellikle Terminal, Windows’ta PowerShell kullanılır.

Kontrol adımı: Ollama servisinin arka planda çalıştığından emin olun. Bazı sistemlerde kurulumla birlikte servis otomatik başlar. Başlamadıysa Ollama uygulamasını/servisini çalıştırmanız gerekebilir.

2) İlk modeli indirme ve çalıştırma

Ollama’da mantık basit: Bir modeli indirir ve “run” ile sohbet başlatırsınız. Örnek olarak genel amaçlı bir model seçebilirsiniz. Aşağıdaki komut, modelin cihazınıza indirilmesini ve ardından etkileşimli sohbetin açılmasını sağlar:

Komut: ollama run llama3.1

İlk çalıştırmada indirme süresi internet hızınıza bağlıdır. Sohbet ekranı geldiğinde Türkçe de yazabilirsiniz. Eğer yanıtlar yavaşsa, daha küçük bir model deneyin veya bağlam (context) boyutunu düşük tutun. Yerel kullanımda performansı belirleyen ana etkenler; model boyutu, quantization seviyesi ve donanım kapasitesidir.

3) Open WebUI ile tarayıcıdan modern arayüz kurma

Komut satırı pratik olsa da günlük kullanım için web arayüzü daha konforlu. Open WebUI, Ollama ile çalışan ve ChatGPT benzeri bir deneyim sunan popüler bir seçenek. Kurulumun en temiz yolu çoğu sistemde Docker kullanmaktır. Docker yüklüyse, Open WebUI konteyneri birkaç komutla ayağa kalkar ve tarayıcıdan erişirsiniz.

Örnek Docker komutu (genel yaklaşım): Open WebUI konteynerini çalıştırıp Ollama’ya bağlayacak şekilde yapılandırın. Bu adımda, Ollama servisinin yerelde hangi adreste çalıştığı önemlidir. Aynı makinede çalışıyorsanız genellikle “localhost” üzerinden erişilir; ancak Docker ağ ayarları işletim sistemine göre farklılık gösterebilir.

Kurulum sonrası tarayıcıda Open WebUI’ye girip model seçebilir, sohbet geçmişini yönetebilir, sistem prompt’u tanımlayabilir ve farklı konuşma profilleri oluşturabilirsiniz. Bu, yerel LLM’yi sadece “denemelik” olmaktan çıkarıp günlük bir üretkenlik aracına dönüştürüyor.

4) İleri seviye ayarlar: Model seçimi, quantization ve bağlam

Yerel LLM’lerde “tek doğru model” yok. İhtiyacınıza göre seçim yapmalısınız. Kod yardımı için kod odaklı modeller, Türkçe metin üretimi için Türkçe başarımı iyi olan modeller daha uygun olabilir. Ayrıca quantization (ör. 4-bit/8-bit) modelin RAM kullanımını düşürür; genellikle küçük kalite kaybı karşılığında ciddi hız ve kapasite avantajı sağlar. Uzun dokümanlarla çalışıyorsanız bağlam penceresi (context window) büyüdükçe RAM ihtiyacı artar. Bu yüzden “uzun bağlam” ile “hız” arasında denge kurmak gerekir.

5) Güvenlik ve gizlilik: Yerelde çalıştırmanın gerçek avantajı

Yerel çalıştırmanın en büyük artısı, verinin cihazınızdan çıkmamasıdır. Özellikle müşteri notları, proje dokümanları, sözleşmeler veya şirket içi kodlar söz konusuysa, buluta veri göndermemek kritik olabilir. Yine de unutmayın: Yerelde bile çalışsanız, kullandığınız arayüzlerin eklenti/telemetri ayarlarını kontrol etmek ve makinenizi güncel tutmak önemlidir. Ayrıca Open WebUI’yi yerel ağda erişime açacaksanız parola/kimlik doğrulama ayarlarını mutlaka etkinleştirin.

6) Yaygın sorunlar ve hızlı çözümler

Yanıtlar çok yavaş: Daha küçük model deneyin, quantization kullanın, arka plandaki uygulamaları kapatın. GPU kullanımı mümkünse etkinleştirin.

RAM yetmiyor / sistem kasıyor: Model boyutunu düşürün, aynı anda tek model çalıştırın, bağlam penceresini küçültün. Swap kullanımı artıyorsa performans dramatik düşer.

Open WebUI Ollama’yı görmüyor: Docker ağ yapılandırmasını kontrol edin. Ollama servisinin çalıştığından ve doğru adrese/porta bağlandığınızdan emin olun.

Sonuç: Yerel AI’yı günlük akışa taşımak

Ollama + Open WebUI ikilisi, yerel LLM dünyasına giriş için en pratik yollardan biri. Bir yandan komut satırıyla esnek bir kullanım sunuyor, diğer yandan tarayıcı arayüzüyle ekip içi veya kişisel üretkenliği artırıyor. Doğru model seçimi ve donanımınıza uygun ayarlar ile; özetleme, e-posta taslağı, toplantı notu düzenleme, kod açıklama gibi işlerde bulut bağımlılığını azaltabilirsiniz. Yerel AI’nın asıl gücü, kontrolün sizde olması: hız, gizlilik ve özelleştirme bir araya geldiğinde ortaya gerçekten kullanışlı bir araç çıkıyor.

Docker Üzerinde Rootless Mod ile Güvenli Container Çalıştırma: Adım Adım Kurulum ve İnce Ayarlar

Rootless Docker Nedir ve Neden Önemli?

Docker, geliştiricilerin uygulamaları taşınabilir şekilde paketlemesini kolaylaştırdı; ancak klasik kurulumda Docker daemon (dockerd) genellikle root yetkileriyle çalışır. Bu da teorik olarak bir container kaçışı veya yanlış yapılandırma durumunda sistem genelinde daha büyük risk anlamına gelebilir. Rootless Docker, Docker’ı root yetkisi olmadan çalıştırarak saldırı yüzeyini azaltmayı hedefleyen güncel ve ileri seviye bir yaklaşımdır.

Rootless modda hem daemon hem de container süreçleri normal bir kullanıcı hesabıyla çalışır. Böylece “root” ayrıcalıklarına ihtiyaç duymadan container yönetimi yapılır. Bu yaklaşım özellikle paylaşımlı sunucularda, geliştirici makinelerinde veya güvenlik politikasının sıkı olduğu kurum ortamlarında ciddi avantaj sağlar.

Ön Koşullar: Sistem ve Kernel Gereksinimleri

Rootless Docker için güncel bir Linux dağıtımı önerilir (Ubuntu 22.04+, Debian 12, Fedora vb.). Temel olarak user namespace altyapısına ihtiyaç duyulur. Pek çok modern dağıtımda bu özellik varsayılan olarak hazır gelir; yine de aşağıdaki iki dosyanın doğru yapılandırılmış olması önemlidir: /etc/subuid ve /etc/subgid. Bu dosyalar, root yetkisi olmadan UID/GID eşlemesi yapabilmek için kullanılır.

Kısaca hedef şu: Kendi kullanıcı hesabınız (ör. ali) için belirli bir UID/GID aralığı atanır ve Docker bunu container içi “root”u, host tarafında ayrıcalıksız bir UID’ye map’leyerek gerçekleştirir.

Kurulum: Rootless Modu Etkinleştirme

Önce Docker’ın sisteminizde kurulu olması gerekir. Dağıtımınızın resmi Docker deposunu kullanmanız tavsiye edilir. Kurulum tamamlandıktan sonra rootless kurulumu için Docker’ın sağladığı script devreye girer. Çoğu sistemde şu komut yeterlidir:

dockerd-rootless-setuptool.sh install

Bu adım, kullanıcı düzeyinde bir systemd servisi oluşturur ve gerekli ortam değişkenleriyle birlikte rootless daemon’ı ayağa kaldırır. Ardından rootless daemon’ı başlatmak için genellikle şu komut kullanılır:

systemctl --user start docker

Otomatik başlaması için:

systemctl --user enable docker

Ortam Değişkenleri: Docker Client Doğru Daemon’a Bağlansın

Rootless modda Docker, varsayılan olarak kullanıcıya özel bir UNIX socket üzerinden hizmet verir. Bu nedenle terminal oturumunuzun doğru socket’e bağlanması gerekir. Çoğu kurulum aşağıdaki gibi bir öneri verir:

export DOCKER_HOST=unix:///run/user/1000/docker.sock

Buradaki 1000 değeri sizin kullanıcı UID’nizdir; id -u komutuyla öğrenebilirsiniz. Bu export satırını kalıcı yapmak için ~/.bashrc veya ~/.zshrc içine ekleyebilirsiniz.

Test: Rootless Çalıştığını Nasıl Anlarsınız?

Kurulum sonrası hızlı bir doğrulama için:

docker info

Çıktıda rootless ile ilgili ibareler ve “Security Options” altında user namespace benzeri detaylar görmeniz beklenir. Ayrıca basit bir container çalıştırarak da test edebilirsiniz:

docker run --rm hello-world

Bu komutun başarılı çalışması, client’ın rootless daemon’a bağlanabildiğini ve temel container akışının sağlıklı olduğunu gösterir.

İnce Ayar 1: Port Yönlendirme ve 1024 Altı Portlar

Rootless Docker’ın en çok kafa karıştıran noktası port yayınlama tarafıdır. Klasik Docker’da 80/443 gibi ayrıcalıklı portlara kolayca bind edilebilirken, rootless modda bu işlem sınırlıdır. Çünkü 1024 altı portlara bind etmek genelde root yetkisi ister.

Çözüm olarak uygulamanızı 8080/8443 gibi yüksek portlarda çalıştırıp ters proxy (ör. Nginx) ile yönlendirebilir veya sistemde setcap gibi yöntemlerle belirli ikili dosyalara sınırlı yetki verebilirsiniz. Güvenlik bakış açısıyla en temiz yaklaşım, servisleri yüksek portta çalıştırıp yönlendirme katmanını ayrıca yönetmektir.

İnce Ayar 2: Dosya İzinleri ve Bind Mount Davranışı

Rootless modun doğal sonucu olarak, host dosya izinleri daha belirleyici hale gelir. Bind mount yaptığınızda container içindeki kullanıcı ile host tarafındaki UID eşleşmesi farklı görünebilir. Özellikle CI ortamlarında veya “volume” olarak paylaşılan dizinlerde yazma izni sorunları çıkabilir.

Pratikte en iyi yöntem, proje dizininizin sahipliğini ve izinlerini net tutmak, gerekiyorsa container içinde çalışacak kullanıcıyı açıkça belirlemek ve “her şeyi 777 yapmak” gibi kötü alışkanlıklardan kaçınmaktır. Rootless, güvenliği artırırken disiplinli izin yönetimini de zorunlu kılar.

Rootless Docker Ne Zaman Mantıklı, Ne Zaman Değil?

Kişisel geliştirme ortamı, paylaşımlı sistemler ve güvenlik öncelikli senaryolarda rootless mod çok mantıklıdır. Buna karşılık, düşük portlara yoğun ihtiyaç, bazı sürücü/overlay kısıtları veya özel ağ/iptables beklentileri olan ortamlarda klasik kurulum daha az sürtünmeyle çalışabilir. Yine de güncel Docker sürümleriyle rootless olgunlaştı; güvenlik açısından “varsayılan tercih” olmaya giderek daha yakın.

Özetle: Eğer makinenizde container’ları “root gibi” çalıştırmak zorunda değilseniz, rootless Docker ile daha güvenli bir temel elde edersiniz. Kurulum birkaç adım sürer; kazandırdığı güvenlik kazanımı ise uzun vadede oldukça değerlidir.

Android 15’te Private Space (Özel Alan) Nasıl Kurulur ve Günlük Hayatta Nasıl Kullanılır?

Private Space Nedir ve Neden Önemli?

Android 15 ile birlikte gelen Private Space (Özel Alan), telefonda ikinci bir “gizli profil” gibi çalışan, ayrı bir uygulama alanı sunuyor. Bu alanın en büyük farkı, uygulamaların ve bildirimlerin ana ekrandan ve uygulama çekmecesinden kolayca görünmemesi; ayrıca kilitliyken arama sonuçlarına, bildirim gölgelerine ve bazı öneri panellerine sızmaması. Özellikle aynı telefonu iş ve kişisel kullanım için paylaşanlar, sosyal medya/mesajlaşma uygulamalarını ayrı tutmak isteyenler veya meraklı gözlerden uzak kalması gereken uygulamaları olanlar için pratik bir güvenlik katmanı sağlıyor.

Bu yazıda Android 15’te Özel Alan’ı sıfırdan kurmayı, kilitleme mantığını, uygulama taşıma/kurma yöntemlerini ve günlük kullanımda işinize yarayacak ayarları adım adım anlatacağım. Not: Menü isimleri üreticiye göre (Pixel, Samsung, Xiaomi vb.) küçük farklılıklar gösterebilir; ancak mantık aynı.

Kurulum Öncesi: Gereksinimler ve Kısa Notlar

Özel Alan özelliği Android 15 ile sunulsa da her modelde aynı hızda gelmeyebilir. Cihazınızın Android sürümünü Ayarlar > Telefon hakkında bölümünden kontrol edin. Ayrıca, Özel Alan’ı açtığınızda genellikle ayrı bir kilit yöntemi tanımlamanız istenir: desen, PIN ya da parola. Biyometrik doğrulama (parmak izi/yüz) bazı cihazlarda ek kolaylık olarak sunulabilir.

Özel Alan’ın amacı “tam kripto kasası” olmak değil; günlük gizlilik ve ayrıştırma sağlamak. Yine de doğru ayarlarla, ana profilde uygulama izlerinin minimuma inmesini sağlayabilirsiniz.

Android 15’te Private Space (Özel Alan) Nasıl Açılır?

1) Ayarlar menüsünü açın: Ayarlar uygulamasına girin.

2) Güvenlik ve gizlilik bölümünü bulun: Çoğu cihazda Güvenlik ve gizlilik ya da Gizlilik altında yer alır.

3) Özel Alan / Private Space seçeneğini açın: Menüde Private Space veya Türkçeleştirilmiş olarak Özel Alan seçeneğini göreceksiniz.

4) Kilit yöntemini belirleyin: Ana ekran kilidinizden farklı bir PIN/desen belirlemek, pratikte daha iyi ayrım sağlar. Aynı PIN’i kullanmak kolaylık sağlasa da, gizlilik hedefi açısından önerilmez.

5) Başlangıç ayarlarını tamamlayın: Android, Özel Alan’da bildirimlerin nasıl davranacağına dair bazı varsayılanları seçmenizi isteyebilir. “Kilitliyken bildirim gösterme” gibi seçenekleri dikkatle ayarlayın.

Uygulamaları Özel Alan’a Kurma ve Taşıma

Özel Alan’ın en güzel yanı, uygulamaları “ayrı bir kutu” gibi yönetebilmeniz. İki temel yöntem var:

Yöntem A: Özel Alan içinden yeni uygulama kurma — Özel Alan’ı açtıktan sonra içerideki uygulama çekmecesinden Play Store’a girip uygulamayı oradan kurabilirsiniz. Bu şekilde kurulan uygulama, ana alandaki aynı uygulamadan ayrı çalışır; ayrı hesapla giriş yapabilir, ayrı bildirim kuralları tanımlayabilirsiniz.

Yöntem B: Mevcut uygulamayı kopyalama/ayrı örnek oluşturma — Bazı arayüzler, ana alandaki uygulamayı Özel Alan’a “taşıma” yerine “ayrı bir örnek” olarak ekler. Bu, özellikle WhatsApp/Telegram gibi uygulamalarda ikinci bir hesap yönetmek isteyenler için idealdir. Eğer cihazınız izin veriyorsa, uygulama detay ekranında Özel Alan’a ekle benzeri bir seçenek görürsünüz.

Özel Alan’ı Kilitleme Mantığı: Bildirimler, Arama ve Son Uygulamalar

Özel Alan kilitliyken, hedeflenen şey şu: Özel Alan uygulamalarının varlığı olabildiğince az iz bıraksın. Bu yüzden aşağıdaki ayarlar kritik:

Bildirimler: Özel Alan uygulamalarının bildirimlerini kilitliyken göstermemek, hem içerik sızıntısını hem de “uygulama kullanılıyor” izini azaltır. Ayarlarda Özel Alan bildirimleri için “kilitliyken gizle” seçeneğini tercih edin.

Arama/Öneriler: Ana ekrandaki arama çubuğu veya uygulama çekmecesi araması bazen uygulama önerileri sunar. Özel Alan kilitliyken bu önerilerin kapalı olduğundan emin olun.

Son uygulamalar ekranı: Çoklu görev ekranında (son uygulamalar) Özel Alan uygulamalarının önizleme kartı görünüyorsa, ilgili gizlilik ayarlarından “önizlemeyi gizle” seçeneğini açın. Bazı cihazlarda bu, uygulama bazlı bir izin olarak yer alır.

Günlük Kullanım Senaryoları: Ne Zaman Gerçekten İşe Yarıyor?

İş/Kişisel ayrımı: Şirket e-postası, kurumsal mesajlaşma veya iki farklı Google hesabı kullanıyorsanız, Özel Alan’ı “iş profilinden daha hafif” bir çözüm gibi düşünebilirsiniz. Uygulamalar karışmaz, bildirim düzeni daha kontrol edilebilir olur.

Seyahat ve paylaşım: Telefonunuzu kısa süreliğine birine verirken (navigasyon, fotoğraf gösterme vb.) Özel Alan kilitli kalır; içerideki uygulamalar ve veriler daha az görünür olur.

İkinci hesap yönetimi: Sosyal medya veya mesajlaşmada ikinci hesap ihtiyacı olanlar için, uygulama klonlama araçlarına göre daha “sistem içi” ve güvenli bir yaklaşım sunar.

İpuçları ve Dikkat Edilecek Noktalar

1) Özel Alan kilidini unutmayın: PIN/desen unutulursa kurtarma süreci can sıkıcı olabilir. Mümkünse güvenli ama hatırlanabilir bir PIN seçin.

2) Yedekleme beklentisini yönetin: Bazı üreticiler Özel Alan’daki uygulama verilerini yedeklerken sınırlamalar koyabilir. Kritik uygulamalarda kendi bulut senkronizasyonunu (ör. not uygulaması, şifre yöneticisi) ayrıca etkinleştirin.

3) Şifre yöneticisi kullanın: Özel Alan’da ayrı hesap açıyorsanız, güçlü parolaları yönetmek için bir şifre yöneticisi şart. Böylece hem güvenlik artar hem de hesap karmaşası azalır.

4) Kilit otomasyonu: Eğer cihazınız destekliyorsa Özel Alan’ı belirli süre kullanılmadığında otomatik kilitleyin. Bu, günlük hayatta unutkanlığı telafi eder.

Sonuç

Android 15’in Private Space (Özel Alan) özelliği, üçüncü parti uygulama klonlama çözümlerine başvurmadan, sistem düzeyinde daha derli toplu bir gizlilik ve ayrıştırma sunuyor. Doğru kurulum ve bildirim/arama/önizleme ayarlarıyla, telefonunuzu hem daha düzenli hem de daha kontrollü kullanabilirsiniz. Özellikle iş-kişisel ayrımı yapanlar ve cihazını zaman zaman paylaşmak zorunda kalanlar için, Android ekosisteminde uzun zamandır beklenen “pratik gizlilik” araçlarından biri olduğunu söylemek mümkün.

Windows 11’de WSL2 ile Docker Kurulumu: Yerel Geliştirmede Hızlı ve Temiz Bir Linux Ortamı

WSL2 + Docker neden bu kadar popüler?

Windows üzerinde yazılım geliştirirken bir yandan da “Linux gibi” çalışmak isteyenlerin sayısı arttı. Eskiden bunun için sanal makine kurmak, ayrı bir disk imajı yönetmek veya çift işletim sistemi kullanmak gerekiyordu. Windows 11 ile birlikte WSL2 (Windows Subsystem for Linux) olgunlaştı ve Docker’ı da bu altyapı üstünden kullanmak oldukça pratik hale geldi. Sonuç: daha az kaynak tüketen, daha hızlı açılan ve proje bağımlılıklarını daha tutarlı yöneten bir geliştirme ortamı.

Bu yazıda, Windows 11 üzerinde WSL2’yi etkinleştirip Ubuntu kuracak, ardından Docker’ı WSL2 motoruyla çalıştıracak şekilde yapılandıracağız. Amacımız “kuruluyor mu?” seviyesini geçip, günlük kullanımda sorun çıkaran detayları da doğru ayarlamak.

Ön koşullar ve kısa kontrol listesi

Başlamadan önce Windows 11’in güncel olduğundan emin olun. Ayrıca sisteminizde sanallaştırma (Virtualization) açık olmalı. Bunu görev yöneticisinde Performans > CPU bölümünde “Sanallaştırma: Etkin” şeklinde görebilirsiniz. Kapalıysa BIOS/UEFI üzerinden açmanız gerekebilir.

Kurulum için yönetici yetkisi olan bir Windows hesabı ve en az 8 GB RAM önerilir. Docker konteynerleri çalıştıracağımız için disk tarafında da rahat etmek adına en az 20 GB boş alan iyi olur.

1) WSL2’yi etkinleştirme ve Ubuntu kurulumu

Windows Terminal’i (PowerShell) yönetici olarak açın ve aşağıdaki komutu çalıştırın:

wsl --install

Bu komut WSL bileşenlerini yükler, varsayılan Linux dağıtımını (genellikle Ubuntu) kurar ve gerekli özellikleri aktif eder. Kurulumdan sonra sistem yeniden başlatma isteyebilir.

Kurulum tamamlanınca Ubuntu ilk açılışta sizden bir kullanıcı adı ve parola belirlemenizi ister. Bu parola Windows parolanız değildir; Linux içi yönetici işlemlerinde kullanılacak.

WSL sürümünüzü kontrol etmek için şu komutu kullanın:

wsl -l -v

Burada Ubuntu’nun “Version” sütununda 2 görünmesini hedefliyoruz. Eğer 1 görünüyorsa şu komutla WSL2’ye çevirebilirsiniz:

wsl --set-version Ubuntu 2

2) Docker Desktop kurulumu ve WSL2 entegrasyonu

Docker’ı Windows üzerinde en sorunsuz şekilde kullanmanın yolu çoğu senaryoda Docker Desktop kurmaktır. Kurulum sırasında “Use WSL 2 instead of Hyper-V” benzeri bir seçenek görürseniz WSL2’yi tercih edin. Kurulum tamamlandıktan sonra Docker Desktop’ı açın.

Docker Desktop içinde Settings bölümüne girin ve şu kontrolleri yapın:

General altında WSL2 tabanlı motorun açık olduğundan emin olun.

Resources > WSL Integration altında Ubuntu dağıtımınız için entegrasyonu etkinleştirin. Burada sadece kurduğunuz dağıtımı seçmeniz yeterli.

Bu noktadan sonra Docker komutlarını doğrudan Ubuntu terminalinde kullanabilirsiniz. Ubuntu içinde doğrulamak için:

docker version

Eğer sürüm bilgileri geliyorsa entegrasyon tamamdır.

3) Hızlı test: Basit bir konteyner çalıştırma

Kurulumun sağlıklı olduğundan emin olmak için klasik test imajını çalıştırın:

docker run --rm hello-world

Bu komut imajı indirir ve bir mesaj basıp çıkar. “Hello from Docker!” benzeri bir çıktı görmeniz gerekir. Bu aşamada hata alırsanız, Docker Desktop’ın çalıştığını ve Ubuntu entegrasyonunun açık olduğunu yeniden kontrol edin.

4) Geliştiriciler için kritik ayarlar: Dosya sistemi ve performans

WSL2 ile Docker kullanırken performansı en çok etkileyen konu proje dosyalarının nerede durduğudur. En iyi performans için kodlarınızı Windows tarafındaki C:\ altında değil, Ubuntu’nun kendi dosya sistemi içinde tutun. Örneğin Ubuntu terminalinde bir proje klasörü oluşturup burada çalışmak genellikle daha akıcı olur:

mkdir -p ~/projelerim/ornek

Windows dosyalarına Ubuntu’dan /mnt/c üzerinden erişebilirsiniz; ancak çok sayıda küçük dosyaya sahip Node.js, PHP Composer veya Python paketlerinde bu yol daha yavaş hissedilebilir.

5) İleri seviye ipuçları: Kaynak yönetimi ve ağ davranışı

WSL2, Linux çekirdeğini hafif bir sanallaştırma katmanında çalıştırır ve RAM kullanımını dinamik yönetir. Yine de yoğun konteyner kullanımında kaynak sınırlarını ayarlamak isteyebilirsiniz. Bunun için Windows kullanıcı dizininizde .wslconfig dosyası oluşturup örneğin RAM ve CPU limitleri belirlemek mümkün olur. Bu sayede “Docker çalışınca bilgisayar yavaşlıyor” şikâyetlerini azaltabilirsiniz.

Ağ tarafında ise konteyner portlarını Windows’a yönlendirmek genelde sorunsuzdur. Örneğin bir web servisini 8080 portunda ayağa kaldırdıysanız tarayıcıdan http://localhost:8080 ile erişebilirsiniz. Kurumsal ağlarda VPN veya güvenlik yazılımları bazen yerel port erişiminde sorun çıkarabilir; böyle bir durumda Windows güvenlik duvarı ve VPN bölünmüş tünelleme ayarları kontrol edilmelidir.

Sonuç: Windows üzerinde “temiz” Linux geliştirme deneyimi

WSL2 ile Docker’ı bir araya getirdiğinizde, Windows’un konforundan vazgeçmeden Linux araç zincirini neredeyse yerel hızda kullanabilirsiniz. Üstelik proje bağımlılıklarını konteynerlere taşıyarak “bende çalışıyor” tartışmalarını ciddi ölçüde azaltırsınız. Doğru dosya konumlandırması, WSL entegrasyonu ve temel kaynak ayarlarıyla bu kurulum uzun süre sorunsuz şekilde günlük iş akışınıza hizmet eder.

Cloudflare Workers ile Edge’de JSON API Oluşturma ve JWT Doğrulama (Adım Adım)

Edge tarafında API fikri neden bu kadar popüler?

Klasik yaklaşımda bir JSON API’yi bir sunucuda (VPS, container, PaaS) çalıştırır, ölçekleme ve gecikme sorunlarını ayrı ayrı yönetirsiniz. Cloudflare Workers ise kodunuzu kullanıcıya daha yakın “edge” noktalarında çalıştırarak düşük gecikme, otomatik ölçeklenme ve yönetim kolaylığı sunar. Bu yazıda, güncel ve ileri seviye bir senaryo olarak Cloudflare Workers ile minimal bir JSON API kuracak, ardından JWT doğrulama ekleyerek endpoint’leri koruma altına alacağız.

Ön koşullar

Bu öğretici için bir Cloudflare hesabı, Node.js (tercihen LTS) ve Cloudflare’ın CLI aracı Wrangler gerekli. Ayrıca JWT üretmek için bir kimlik sağlayıcı (Auth0, Firebase, Keycloak vb.) kullanabilirsiniz; ancak burada doğrulama kısmını Workers üzerinde ele alacağız. Amaç, “Authorization: Bearer ...” başlığıyla gelen token’ı doğrulayıp yetkisiz istekleri reddetmek.

1) Projeyi oluşturma (Wrangler)

Yerel ortamda yeni bir Worker projesi başlatın. Wrangler, TypeScript ve modern Worker runtime’ı ile hızlı bir iskelet oluşturur. Terminalde proje klasörünü oluşturduktan sonra geliştirme sunucusunu ayağa kaldırarak endpoint’leri test edebilirsiniz. Buradaki kritik nokta: Worker kodu Node.js sunucusu gibi “stateful” değildir; tasarımınızı stateless düşünmek daha doğru sonuç verir.

2) JSON API: Basit bir route yapısı

Workers ortamında istekleri fetch handler’ı ile karşılarız. Birkaç route ile başlayalım: /health (servis kontrolü), /api/profile (JWT gerektiren örnek endpoint). Aşağıdaki örnek, JSON cevapları standartlaştırmak için küçük yardımcı fonksiyonlar kullanır.

Örnek Worker kodu (TypeScript mantığı):

Not: Kod örneğini kendi projenize göre uyarlayın; özellikle JWT doğrulama için kullanacağınız public key veya JWKS adresi değişecektir.

Route mantığı: /health herkese açık, /api/profile ise Bearer token ister. Token doğrulanırsa örnek bir profil JSON’u döner.

3) JWT doğrulama: HS256 yerine RS256/JWKS yaklaşımı

Güncel pratikte JWT doğrulamada iki ana yol var: paylaşılan gizli anahtar (HS256) veya asimetrik anahtar (RS256/ES256). Üretim ortamında, özellikle üçüncü parti kimlik sağlayıcıları ile, JWKS (JSON Web Key Set) üzerinden public key çekip doğrulama yapmak daha sürdürülebilir bir yöntemdir. Böylece anahtar rotasyonu kimlik sağlayıcı tarafında yönetilir ve Worker sadece güncel anahtarı kullanır.

Workers içinde JWKS kullanırken iki konu önem kazanır: cache ve performans. Her istekte JWKS çekmek gecikmeyi artırır. Bu yüzden JWKS yanıtını belirli bir süre cache’lemek gerekir. Cloudflare Workers, Cache API ile bu işi oldukça pratik hale getirir. Alternatif olarak KV ya da D1 gibi çözümler de kullanılabilir, fakat JWKS için Cache API genellikle yeterlidir.

4) Güvenlik kontrol listesi (pratik öneriler)

Audience (aud) ve issuer (iss) doğrulaması yapın. Sadece imza doğrulamak yetmez; token’ın kimin için üretildiğini ve hangi otorite tarafından imzalandığını da kontrol etmek gerekir. Ayrıca token süresi için exp kontrolü zorunludur. Saat kayması ihtimaline karşı küçük bir tolerans (clock skew) eklemek sahada hataları azaltır.

CORS konusu da sık atlanır. API’niz tarayıcıdan çağrılacaksa doğru origin’leri whitelist ederek “*” kullanımını sınırlayın. Workers, preflight (OPTIONS) isteklerini yönetmek için idealdir. Ek olarak rate limit için Cloudflare’ın WAF ve Rate Limiting özellikleri veya uygulama seviyesinde basit limit mekanizmaları kullanılabilir.

5) Deploy ve test

Geliştirme tamamlanınca Wrangler ile deploy alırsınız. Ardından uç noktaları curl veya Postman ile test edin. İlk test olarak /health çağrısının 200 dönmesi beklenir. Sonra /api/profile’a token olmadan istek atarak 401 aldığınızı doğrulayın. Son adımda geçerli bir JWT ile çağrı yapıp JSON yanıtı alın. Hata durumlarında özellikle Authorization header formatı (Bearer boşluk) ve token’ın doğru issuer/audience değerleri kontrol edilmelidir.

Sık karşılaşılan hatalar ve çözüm ipuçları

“Invalid signature”: Yanlış public key, yanlış JWKS endpoint’i veya token’ın farklı bir kid ile imzalanması. JWKS’ten doğru anahtarı seçtiğinizden emin olun. “Token expired”: exp geçmiş olabilir; sistem saatini ve clock skew toleransını gözden geçirin. CORS hataları: OPTIONS isteklerine 200 dönmeyi ve gerekli Access-Control-Allow-* başlıklarını eklemeyi unutmayın.

Sonuç: Neyi kazandınız?

Bu rehberle Cloudflare Workers üzerinde edge’de çalışan, gecikmesi düşük ve otomatik ölçeklenen bir JSON API kurmanın mantığını kurdunuz. Üstüne JWT doğrulama ekleyerek gerçek hayattaki “korumalı endpoint” ihtiyacını da çözdünüz. Buradan sonra loglama için Workers Analytics, veri katmanı için D1/KV, daha gelişmiş yetkilendirme için role-based kontrol ve rate limiting gibi adımlarla mimariyi büyütebilirsiniz.