Windows 11’de WSL2 ile Docker Desktop Kullanmadan Docker Kurulumu ve İleri Seviye Ayarlar

Docker Desktop’sız Docker: Neden ve Ne Kazandırır?

Windows 11 üzerinde Docker kullanmanın en popüler yolu Docker Desktop kurmaktır. Ancak kurumsal lisans politikaları, kaynak tüketimi, arka planda çalışan servislerin fazlalığı veya daha “Linux’a yakın” bir Docker deneyimi isteği, birçok geliştiriciyi alternatif arayışına itiyor. İyi haber şu: WSL2 sayesinde Docker Engine’i doğrudan Linux tarafında kurup, Windows’tan komut satırı ile yönetmek mümkün. Bu yöntem genellikle daha hafif çalışır, daha kontrol edilebilir bir yapı sunar ve özellikle terminal odaklı geliştiriciler için oldukça rahattır.

Bu yazıda, Windows 11’de WSL2 (Ubuntu örneğiyle) kullanarak Docker Engine kurulumunu, Windows terminalinden Docker komutlarını çalıştırmayı ve performans/depoma/ ağ ayarları gibi birkaç ileri seviye noktayı adım adım ele alacağım. Sonuçta Docker Desktop olmadan da modern konteyner geliştirme akışını sürdürebileceksiniz.

Ön Koşullar: WSL2 ve Ubuntu Kurulumu

Öncelikle sisteminizde WSL2 aktif olmalı. Windows Terminal veya PowerShell’i yönetici olarak açıp aşağıdaki komutu çalıştırabilirsiniz:

wsl --install

Kurulum tamamlandıktan sonra Microsoft Store üzerinden Ubuntu yükleyebilir ya da komutla kurabilirsiniz. Ardından Ubuntu’yu açıp kullanıcı adı/parola belirleyin. WSL sürümünü kontrol etmek için:

wsl -l -v

Ubuntu’nun VERSION sütununda 2 yazdığından emin olun. Değilse:

wsl --set-version Ubuntu 2

Adım 1: Ubuntu’da Docker Engine Kurulumu (Resmi Depo)

WSL içindeki Ubuntu terminalinde önce paketleri güncelleyin:

sudo apt update && sudo apt upgrade -y

Gerekli paketleri yükleyin:

sudo apt install -y ca-certificates curl gnupg

Docker’ın resmi GPG anahtarını ekleyin ve depo kaynağını tanımlayın:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Sonra Docker paketlerini kurun:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Adım 2: Docker Servisini WSL’de Çalıştırma

WSL2’de systemd artık destekleniyor; en temiz yöntem systemd’yi açmaktır. Ubuntu içinde /etc/wsl.conf dosyasını düzenleyin:

sudo nano /etc/wsl.conf

İçeriğe şunu ekleyin:

[boot]
systemd=true

Ardından Windows tarafında WSL’i kapatıp yeniden başlatın:

wsl --shutdown

Ubuntu’yu tekrar açınca Docker servisini başlatın ve durumunu kontrol edin:

sudo systemctl enable docker
sudo systemctl start docker
sudo systemctl status docker

Adım 3: Sudo’suz Docker Kullanımı (Geliştirici Konforu)

Her komutta sudo yazmamak için kullanıcıyı docker grubuna ekleyin:

sudo usermod -aG docker $USER

Değişikliğin uygulanması için oturumu kapatıp açın ya da Ubuntu terminalini kapatıp yeniden başlatın. Test:

docker run --rm hello-world

Windows Terminal’den Docker Komutlarını Yönetmek

Docker Engine WSL içinde çalıştığı için en basit yönetim biçimi, Windows Terminal’de doğrudan Ubuntu profilini kullanmaktır. Yani komutları Ubuntu sekmesinde çalıştırdığınızda her şey doğal şekilde ilerler. Eğer PowerShell’den tek satırla çalıştırmak isterseniz:

wsl -d Ubuntu -- docker ps

Bu yaklaşım, CI benzeri yerel script’lerde veya kısa kontrollerde oldukça işe yarar.

İleri Seviye Ayar 1: WSL Kaynak Sınırları (RAM/CPU)

WSL, varsayılan olarak sistem kaynaklarını dinamik kullanır. Docker build süreçleri ağırlaştığında RAM tüketimi artabilir. Bunu sınırlamak için Windows kullanıcı dizininize .wslconfig dosyası oluşturup örnek bir sınır koyabilirsiniz:

[wsl2]
memory=6GB
processors=4

Değişiklikten sonra wsl --shutdown yaparak yeniden başlatın. Bu ayar, özellikle dizüstü bilgisayarlarda fan ve pil performansını belirgin şekilde iyileştirir.

İleri Seviye Ayar 2: Dosya Performansı ve Proje Konumu

Kritik nokta şu: Docker konteynerleri WSL içindeki Linux dosya sisteminde daha hızlı çalışır. Projeyi /home/kullanici/proje altında tutmak genelde, projeyi /mnt/c üzerinden Windows dosya sisteminde tutmaktan daha performanslıdır. Özellikle Node.js bağımlılıkları, PHP vendor dizinleri veya çok sayıda küçük dosya içeren projelerde fark gözle görülür hale gelir.

İleri Seviye Ayar 3: Docker Compose v2 ve Buildx

Kurulumda gelen docker compose (v2) ve buildx eklentileri, modern geliştirme akışının temel parçaları. Örneğin çoklu servisli bir projeyi ayağa kaldırmak için:

docker compose up -d

Daha hızlı ve tekrar kullanılabilir build işlemleri için build cache’i etkin kullanan bir Dockerfile tasarlamak, WSL ortamında da doğrudan avantaj sağlar. Ayrıca buildx ile farklı platformlar için build almak (ör. linux/amd64 ve linux/arm64) ileri seviye senaryolarda elinizi güçlendirir.

Sık Karşılaşılan Sorunlar ve Hızlı Çözümler

Docker daemon çalışmıyor: systemd açık mı kontrol edin. cat /etc/wsl.conf ile doğrulayın, ardından wsl --shutdown ile yeniden başlatın.

Permission denied: Kullanıcınız docker grubunda olmayabilir. groups komutuyla kontrol edin, gerekirse usermod -aG docker adımını tekrarlayın.

Disk şişmesi: Konteyner ve imajlar büyüdükçe WSL sanal diski genişler. Düzenli olarak docker system prune kullanmak ve gereksiz imajları temizlemek iyi bir alışkanlıktır.

Sonuç

Docker Desktop kullanmadan, WSL2 üzerinde Docker Engine çalıştırmak Windows 11’de hem pratik hem de “Linux’a yakın” bir geliştirme ortamı sunuyor. Kurulum bir kez oturduğunda günlük kullanımda fark edilir bir hafiflik sağlıyor; kaynak yönetimi daha esnek oluyor ve terminal odaklı iş akışları daha akıcı ilerliyor. Eğer konteyner geliştirmeyi daha kontrollü ve minimal bir kurulumla sürdürmek istiyorsanız, bu yöntem kesinlikle değerlendirilmeye değer.

Docker ile Rootless (Yetkisiz) Container Çalıştırma: Güvenli Kurulum ve İnce Ayar Rehberi

Rootless Docker nedir ve neden önemli?

Docker çoğu sistemde varsayılan olarak root yetkisiyle çalışan bir “daemon” kullanır. Bu, günlük kullanımda pratik olsa da saldırı yüzeyi açısından risklidir: bir konteynerden kaçış (container escape) veya yanlış yapılandırılmış bir bind mount gibi senaryolarda etkiler büyüyebilir. Rootless Docker ise Docker’ı sistemde ayrıcalıklı (root) bir servis olarak çalıştırmadan, normal bir kullanıcı hesabı altında çalıştırmanıza imkân tanır. Böylece olası bir ihlal durumunda etki alanı, o kullanıcıyla sınırlı kalır.

Bu yazıda rootless Docker’ı kurup yapılandıracağız; ayrıca ağ, port yönlendirme, dosya izinleri ve performans tarafındaki kritik ayrıntıları netleştireceğiz. Anlatım Linux odaklıdır ve özellikle Ubuntu/Debian türevlerinde sorunsuz ilerler; Fedora ve benzerlerinde komutlar büyük ölçüde aynıdır.

Ön koşullar

Rootless Docker için çekirdek tarafında kullanıcı ad alanları (user namespaces) ve bazı yardımcı araçlar gerekir. Önce sisteminizde aşağıdakilerin yüklü olduğundan emin olun: uidmap (newuidmap/newgidmap), slirp4netns (rootless ağ), fuse-overlayfs (rootless overlay sürücüsü, her sistemde şart değil) ve mümkünse güncel bir Docker paketi.

Debian/Ubuntu için temel paketler: sudo apt-get update ardından sudo apt-get install -y uidmap slirp4netns fuse-overlayfs. Docker’ı dağıtımın deposundan veya Docker’ın resmi deposundan kurabilirsiniz; rootless mod için modern sürüm önerilir.

Subuid/subgid yapılandırması

Rootless modun kalbi, kullanıcıya ayrılmış UID/GID aralıklarıdır. Sistem, normal kullanıcının konteyner içinde farklı kimliklerle işlem yapabilmesi için bu aralıkları /etc/subuid ve /etc/subgid dosyalarında tutar. Çoğu dağıtımda kurulum sırasında otomatik eklenir; yine de kontrol etmek iyi fikir.

Örnek satır formatı şöyledir: kullanici:100000:65536. Eğer yoksa eklemek için root yetkisi gerekir. Değerler sisteminize göre değişebilir; önemli olan çakışmayan bir aralık olmasıdır. Bu aşamayı doğru yapmak, ileride “permission denied” türü gizemli hataları ciddi ölçüde azaltır.

Rootless kurulumu: dockerd-rootless-setuptool.sh

Docker’ın rootless kurulumu genellikle tek bir komutla yapılır. Normal kullanıcı hesabınızla oturum açtıktan sonra şu komutu çalıştırın: dockerd-rootless-setuptool.sh install. Bazı sistemlerde bu script PATH içinde değilse, Docker paketinin dokümantasyonundaki konuma göre çağırmanız gerekebilir.

Kurulum sonunda size genellikle iki kritik bilgi verilir: Docker soketinin bulunduğu yol ve ortam değişkeni önerisi. Rootless Docker çoğunlukla kullanıcı seviyesinde çalıştığı için soket yolu $XDG_RUNTIME_DIR/docker.sock benzeri bir konumda olur. Terminalinizde rootless bağlamı kullanmak için çoğu zaman export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock yeterlidir.

Servis olarak çalıştırma (systemd --user)

Sürekli kullanım için rootless Docker’ı kullanıcı servisi olarak çalıştırmak idealdir. Kurulum script’i çoğu zaman systemctl --user enable --now docker adımını önerir. Böylece sistem açıldığında, kullanıcı oturumu etkinleştiğinde Docker arka planda hazır olur.

Eğer “linger” etkin değilse, kullanıcı oturumu kapandığında servis durabilir. Sunucu senaryolarında bunun önüne geçmek için sudo loginctl enable-linger kullanici komutu işe yarar. Bu sayede kullanıcı oturumu kapalı olsa bile user-level servisler çalışmaya devam eder.

Port yönlendirme ve ağ kısıtları

Rootless modun en çok sorulan kısmı port yayınlamadır. Linux’ta 1024 altı “privileged port” sayılır ve root gerektirir. Rootless Docker’da -p 80:80 gibi bir eşleme çoğu sistemde doğrudan çalışmaz. Alternatif olarak uygulamanızı 8080 gibi bir porta alabilir veya sistem çapında bir ters proxy (Nginx/Traefik) ile 80/443 trafiğini root yetkisi olan servis üzerinden yönlendirebilirsiniz.

Ağ tarafında rootless genellikle slirp4netns ile kullanıcı alanında NAT benzeri bir yapı kullanır. Bu, güvenlik açısından avantajlıdır; ancak bazı yoğun ağ senaryolarında performans farkı görülebilir. Geliştirme ortamlarında çoğu kullanıcı için yeterlidir; yüksek bant genişliği ve düşük gecikme hedefliyorsanız ölçüm yapmanız önerilir.

Depolama sürücüsü ve dosya izinleri

Rootless Docker, dosya sistemi sürücüsü olarak çoğu zaman fuse-overlayfs veya uygun bir alternatif kullanır. Bu, klasik root modundaki overlay2 kadar “ham performans” vermeyebilir; ama güncel çekirdek ve SSD üzerinde günlük işler için genellikle sorun çıkarmaz. İmaj çekme, build ve volume kullanımlarında davranış farklılıkları olabileceği için CI/CD ortamlarınızda deneme yapmak akıllıca olur.

Volume tarafında kritik nokta şudur: Konteyner içindeki UID/GID eşlemeleri, hosttaki dosya sahipliğiyle farklı görünebilir. “Dosyalar yazılamıyor” sorunu yaşarsanız önce mount ettiğiniz klasörün izinlerini, ardından konteynerin çalıştığı kullanıcıyı ve gerekiyorsa --user parametresini kontrol edin.

Hızlı test: Rootless çalışıyor mu?

Kurulumdan sonra şu komutlarla doğrulama yapabilirsiniz: docker info çıktısında rootless ibaresini arayın. Ardından basit bir konteyner başlatın: docker run --rm hello-world. İmaj iniyor ve konteyner sorunsuz çalışıyorsa temel kurulum tamamdır.

Son olarak küçük bir web testi yapmak isterseniz: docker run --rm -p 8080:80 nginx deyip tarayıcıdan http://localhost:8080 adresini kontrol edin. Eğer port erişimi varsa rootless ağ zinciri de doğru çalışıyor demektir.

Ne zaman rootless, ne zaman klasik Docker?

Rootless Docker; geliştirici makineleri, çok kullanıcılı sunucular, güvenliği öncelikleyen laboratuvar ortamları ve “en az yetki” yaklaşımı için güçlü bir seçenektir. Buna karşın düşük portlara doğrudan bind ihtiyacı, bazı ağ sürücüleri (macvlan benzeri) veya belirli kernel özelliklerine bağımlı iş yükleri gibi durumlarda klasik (root) Docker hâlâ daha sorunsuz olabilir.

İyi haber şu: Rootless’a geçiş genellikle geri dönüşü zor bir karar değildir. Aynı makinede her iki yaklaşımı da senaryoya göre kullanabilir, kritik servisleri geleneksel olarak yönetirken geliştirme ve test süreçlerinizi rootless ile daha güvenli hale getirebilirsiniz.

Windows 11’de WSL 2 ile Docker Desktop Kullanmadan Docker Kurulumu ve Hızlandırma Rehberi

Giriş: Neden Docker Desktop’sız Docker?

Windows 11’de Docker kullanmanın en popüler yolu Docker Desktop olsa da, her senaryoda en iyi seçenek olmayabiliyor. Lisans politikaları, sistem kaynak tüketimi, kurumsal kısıtlar veya daha “çıplak” bir kurulum isteği gibi sebeplerle WSL 2 üzerinde doğrudan Docker Engine kurmak hem daha hafif hem de daha kontrol edilebilir bir yaklaşım sunuyor. Bu yazıda, Windows 11 üzerinde WSL 2 kullanarak Docker’ı Docker Desktop olmadan kurmayı, Windows ile entegrasyonu sağlamayı ve performansı iyileştirecek birkaç ileri seviye ayarı adım adım ele alacağım.

1) Ön Koşullar: WSL 2 ve Dağıtım Seçimi

Öncelikle WSL 2’nin etkin olduğundan emin olmalısınız. Windows 11’de çoğu sistemde WSL zaten sorunsuz çalışır; yine de güncel bir kurulum için PowerShell’i yönetici olarak açıp WSL’yi kurmak veya güncellemek iyi bir başlangıçtır. Ardından Ubuntu 22.04/24.04 gibi yaygın bir dağıtım seçmenizi öneririm; dokümantasyon ve topluluk desteği güçlü olduğu için sorun çözmek daha kolay olur.

Kontrol: WSL sürümünüzü görmek için Windows tarafında wsl -l -v komutunu kullanabilirsiniz. Dağıtımınızın sürümü “2” değilse WSL 2’ye yükseltmeniz gerekir. Ayrıca BIOS/UEFI’de sanallaştırma (Virtualization) açık olmalıdır; aksi halde WSL 2 beklenmedik şekilde yavaşlar veya hiç çalışmaz.

2) WSL İçinde Docker Engine Kurulumu

Docker Desktop kurmadan Docker çalıştırmanın ana fikri şu: Docker Engine, Linux ortamında çalışır; biz de bunu WSL 2 içindeki Ubuntu’da kurarız. Ardından Docker komutlarını aynı WSL ortamında kullanırız. Böylece arka planda ayrı bir GUI uygulaması değil, standart Linux servisleri devreye girer.

Adımlar: Ubuntu terminalini açın ve sisteminizi güncelleyin. Daha sonra Docker’ın resmi deposunu ekleyerek Docker Engine kurun. Depodan kurmak, dağıtım deposundaki eski sürümlere göre genellikle daha güncel bir Docker sürümü sağlar. Kurulumdan sonra Docker servisinin çalıştığını doğrulamak için docker version ve docker run hello-world komutlarını deneyebilirsiniz.

Kurulum sonrası sık yapılan bir ayar da kullanıcıyı “docker” grubuna eklemektir. Böylece her komutta sudo yazmanız gerekmez. Bu değişiklikten sonra WSL oturumunu kapatıp yeniden açmanız gerekir; aksi halde yetki değişimi görünmeyebilir.

3) systemd ile Servis Yönetimi (İleri Seviye ve Önerilen)

Eskiden WSL’de servis yönetimi daha zahmetliydi; ancak modern Windows 11 ve güncel WSL sürümlerinde systemd desteği bulunuyor. Docker Engine’i düzgün bir Linux makinesindeki gibi yönetmek istiyorsanız systemd oldukça kritik. Böylece Docker servisi WSL oturumu açıldığında otomatik başlar ve kapanışta düzgün durur.

systemd’yi etkinleştirmek için WSL içindeki yapılandırma dosyasına ilgili ayarı eklemeniz gerekir. Değişiklikten sonra Windows tarafında wsl --shutdown çalıştırıp WSL’yi yeniden başlatmak gerekir. Ardından Ubuntu içinde systemctl status docker ile servisin durumunu kontrol edebilirsiniz.

4) Windows Terminal ve VS Code ile Akıcı Geliştirme

Bu kurulumun pratik tarafı, geliştirme araçlarıyla birleştiğinde ortaya çıkar. Windows Terminal üzerinden Ubuntu profilinizi açıp Docker komutlarını doğrudan çalıştırabilirsiniz. Eğer Visual Studio Code kullanıyorsanız, Remote - WSL eklentisi ile projenizi WSL dosya sistemi içinde açıp konteyner build/run süreçlerini Linux tarafında yürütebilirsiniz. Bu, özellikle Node.js, Python ve Go projelerinde dosya izinleri ve satır sonu farklılıklarından kaynaklı problemleri ciddi şekilde azaltır.

Önemli not: Proje dosyalarınızı mümkünse WSL dosya sisteminde tutun (ör. /home/kullanici/proje). Windows sürücüsü üzerinden (ör. /mnt/c/...) çalışmak, özellikle çok sayıda küçük dosya içeren projelerde I/O performansını düşürebilir.

5) Performans İyileştirmeleri: .wslconfig ile Kaynak Sınırları

Docker konteynerleri CPU ve RAM tüketimini hızla artırabilir. WSL 2, varsayılan olarak sistem kaynaklarını dinamik kullanır; bu iyi olsa da bazı durumlarda RAM şişmesi veya disk kullanımının kontrolsüz büyümesi can sıkabilir. Windows kullanıcı dizininizde yer alan .wslconfig dosyasıyla WSL’nin kullanacağı kaynakları sınırlayabilirsiniz.

Örneğin RAM’i 8 GB ile sınırlamak, CPU sayısını belirlemek veya swap boyutunu ayarlamak mümkündür. Bu ayarlar özellikle aynı anda tarayıcı, IDE ve birkaç konteyner çalıştıran geliştiriciler için sistemin tepkiselliğini korur. Ayarlardan sonra wsl --shutdown ile WSL’yi yeniden başlatmayı unutmayın.

6) Ağ ve Port Yayınlama Mantığı: “localhost” Gerçeği

WSL 2, kendi sanal ağ katmanına sahip olduğu için “localhost” konusu zaman zaman kafa karıştırır. İyi haber şu: Güncel Windows 11 sürümlerinde WSL ile Windows arasında “localhost” üzerinden port yönlendirme çoğu senaryoda otomatik çalışır. Yani WSL içinde 8080 portunu yayınlayan bir konteyneri, Windows’ta tarayıcıdan http://localhost:8080 ile açabilirsiniz.

Yine de kurumsal güvenlik yazılımları veya özel firewall kuralları port erişimini engelleyebilir. Böyle bir durumda Windows Firewall izinlerini kontrol etmek, konteynerin gerçekten port yayınladığını docker ps ile doğrulamak ve WSL’nin IP adresini kullanarak test yapmak işe yarar.

7) Artılar, Eksiler ve Ne Zaman Tercih Etmeli?

Artılar: Daha az arka plan bileşeni, daha düşük kaynak tüketimi, daha “Linux’a yakın” bir Docker deneyimi ve kurulum üzerinde daha fazla kontrol. Ayrıca bazı kullanıcılar için Docker Desktop’ın getirdiği ekstra katmanlar yerine doğrudan Engine kullanmak daha öngörülebilir.

Eksiler: GUI yönetim paneli yoktur, bazı entegrasyonlar (Kubernetes tek tıkla aç/kapat gibi) Docker Desktop kadar hazır gelmez. Ayrıca birden fazla WSL dağıtımı kullanıyorsanız Docker’ın hangi dağıtımda kurulu olduğu ve nereden çalıştırıldığı konusunu iyi yönetmeniz gerekir.

Sonuç

Windows 11’de WSL 2 üzerinde Docker Engine kurup Docker Desktop kullanmadan çalışmak, özellikle geliştirici odaklı ve performans hassasiyeti olan kullanıcılar için güçlü bir alternatiftir. Doğru yapılandırma ile servis yönetimi systemd üzerinden düzenli çalışır, proje dosyalarını WSL içinde tutarak I/O performansı korunur ve .wslconfig ile sistem kaynakları kontrol altına alınır. Eğer hedefiniz “hafif, hızlı ve kontrol edilebilir” bir Docker ortamıysa bu yöntem, günlük geliştirme akışınıza beklediğinizden daha rahat uyum sağlayacaktır.

Windows 11’de WSL2 ile Docker Desktop Kullanmadan Docker Kurulumu ve Performans Ayarları

WSL2 ile “hafif” Docker fikri neden mantıklı?

Windows 11 üzerinde Docker çalıştırmanın en popüler yolu Docker Desktop. Ancak bazı senaryolarda (kurumsal lisans politikaları, kaynak tüketimi, arka planda çalışan servisler, ekstra arayüz katmanı) Docker Desktop yerine doğrudan WSL2 içinde Docker Engine kurmak daha temiz bir çözüm olabiliyor. Bu yazıda, Docker Desktop kullanmadan WSL2 üzerinde Docker’ı kuracağız; ardından performans ve disk kullanımını iyileştiren birkaç kritik ayarı yapacağız.

Ön koşullar

Gerekenler: Windows 11, yönetici yetkisi, WSL2 desteği ve bir Linux dağıtımı (Ubuntu önerilir). Windows tarafında WSL2 etkin değilse önce etkinleştirmeniz gerekir. Ayrıca BIOS/UEFI’de sanallaştırmanın açık olması, WSL2’nin stabil çalışması için önemlidir.

Adım 1: WSL2 ve Ubuntu kurulumu

PowerShell’i yönetici olarak açıp aşağıdaki komutu çalıştırın. Bu komut WSL’yi kurar ve varsayılan olarak Ubuntu’yu indirip kurabilir:

Komut: wsl --install

Kurulumdan sonra bilgisayarınızı yeniden başlatın. Ardından Ubuntu ilk açılışta kullanıcı adı/şifre oluşturmanızı ister. Mevcut WSL dağıtımlarınızı görmek için:

wsl -l -v

Burada dağıtımınızın Version 2 olduğundan emin olun. Değilse:

wsl --set-version Ubuntu 2

Adım 2: WSL2 içinde Docker Engine kurulumu

Ubuntu terminalini açın ve sistemi güncelleyin:

sudo apt update && sudo apt upgrade -y

Docker’ın resmi deposunu eklemek güncel sürüm için daha sağlıklıdır. Sırasıyla şu komutları çalıştırın:

sudo apt install -y ca-certificates curl gnupg

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

Şimdi Docker Engine ve gerekli bileşenleri kurun:

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Adım 3: Docker’ı root’suz kullanmak (sudo derdini bitirin)

Geliştirici deneyimi açısından en önemli adım: kullanıcıyı docker grubuna eklemek. Böylece her komutta sudo yazmanız gerekmez.

sudo usermod -aG docker $USER

Değişikliğin uygulanması için Ubuntu oturumunu kapatıp açın ya da şu komutla kabuğu yenileyin:

newgrp docker

Docker’ın çalıştığını doğrulamak için:

docker run --rm hello-world

Adım 4: WSL2’de Docker servisini otomatik başlatma

WSL, klasik Linux gibi her zaman systemd ile açılmayabilir. Windows 11 ve güncel WSL sürümlerinde systemd desteği var. Etkinleştirerek Docker’ın açılışta başlamasını sağlayabilirsiniz.

WSL içinde /etc/wsl.conf dosyasını düzenleyin:

sudo nano /etc/wsl.conf

İçerik şu şekilde olsun:

[boot] systemd=true

Ardından Windows tarafında WSL’yi yeniden başlatın:

wsl --shutdown

Ubuntu’yu tekrar açınca Docker servisini başlatıp kalıcı hale getirebilirsiniz:

sudo systemctl enable --now docker

Adım 5: Performans için kritik ayar: proje dosyalarını nereye koymalısınız?

WSL2’de en sık yapılan hata, proje klasörünü /mnt/c gibi Windows dosya sistemi altında tutup Docker build ve bind mount işlemlerini burada yapmak. Bu kullanım çalışır ama dosya erişimi katmanı nedeniyle özellikle Node.js, PHP, Python gibi çok sayıda küçük dosya okuyan projelerde performans düşebilir.

Öneri: Kodunuzu WSL2 Linux dosya sistemi içinde (ör. /home/kullanici/proje) tutun. Windows’tan erişmek için de Dosya Gezgini’ne \\wsl$ yazarak Ubuntu dizinlerine ulaşabilirsiniz. Bu sayede Docker build süreleri ve canlı geliştirme (hot reload) daha stabil hale gelir.

Adım 6: Disk şişmesini kontrol etme ve temizlik

Docker kullanırken imajlar ve kullanılmayan katmanlar zamanla disk alanını şişirir. Düzenli aralıklarla temizlik yapmak iyi bir alışkanlık:

docker system df

docker system prune -a

Eğer sadece kullanılmayan container’ları ve dangling imajları temizlemek isterseniz daha güvenli bir yaklaşım seçebilirsiniz. Ancak prune -a tüm kullanılmayan imajları da siler; tekrar gerektiğinde yeniden indirmek zorunda kalırsınız.

Sık karşılaşılan sorunlar

“Cannot connect to the Docker daemon”: Docker servisi çalışmıyor olabilir. Systemd etkinse sudo systemctl status docker ile kontrol edin. Değilse geçici olarak sudo dockerd ile daemon başlatılabilir, fakat kalıcı çözüm systemd’yi aktif etmektir.

Port çakışmaları: Windows’ta aynı portu kullanan bir servis varsa container ayağa kalksa bile erişim sorunları yaşayabilirsiniz. netstat ile Windows tarafında portu kim kullanıyor bakın ve compose dosyanızdaki portları değiştirin.

Ağ erişimi: WSL2 ağ katmanı NAT üzerinden çalışır. Yerel ağdan WSL2 içindeki bir servise erişmek bazen ekstra yönlendirme gerektirebilir; çoğu geliştirme senaryosunda ise localhost yeterlidir.

Sonuç

Docker Desktop olmadan WSL2 üzerinde Docker Engine kurmak, daha az arka plan bileşeniyle daha “Linux’a yakın” bir deneyim sunar. Özellikle performans hassas projelerde dosyaları Linux tarafında tutmak ve systemd ile Docker’ı otomatik başlatmak günlük kullanım konforunu ciddi şekilde artırır. Bu kurulumla hem docker compose kullanabilir hem de modern buildx özelliklerinden faydalanabilirsiniz.

Docker ile Yerel LLM Çalıştırma: Ollama + Open WebUI Kurulumu ve İnce Ayarları

Yerelde Yapay Zekâ: Neden Ollama?

Bulut tabanlı yapay zekâ servisleri pratik olsa da her proje için ideal değil. Gizlilik, maliyet, gecikme ve internet bağımlılığı gibi konular devreye girdiğinde yerel (local) LLM çalıştırmak çok daha mantıklı hale geliyor. Bu yazıda, güncel ve popüler bir yöntemle Ollama üzerinden bir dil modelini yerelde çalıştırmayı, ardından da Open WebUI ile web arayüzü ekleyerek kullanımı “ChatGPT benzeri” bir seviyeye taşımayı adım adım anlatacağım. Kurulumun odağı Docker olacak; böylece sisteminizi kirletmeden, taşınabilir bir kurulum elde edeceksiniz.

Gereksinimler ve Kısa Hazırlık

Bu rehber, Windows 11 + WSL2, macOS veya Linux üzerinde uygulanabilir. Docker yaklaşımı sayesinde dağıtım farklılıkları minimuma iner. İhtiyacınız olanlar: Docker (Docker Desktop veya Engine), en az 8 GB RAM (14B ve üzeri modellerde 16–32 GB daha rahat), yeterli disk alanı (model boyutuna göre 5–20 GB arası) ve tercihen modern bir CPU. NVIDIA GPU’nuz varsa hız artışı mümkün, ancak bu yazı CPU odaklı ve genel bir kurulum sunuyor.

1) Docker ile Ollama Kurulumu

Önce Ollama’yı bir konteyner olarak ayağa kaldıralım. Aşağıdaki komut, Ollama servisini 11434 portunda yayınlar ve model verisini kalıcı tutmak için volume kullanır:

Komut:

docker run -d --name ollama -p 11434:11434 -v ollama:/root/.ollama ollama/ollama

Kurulum tamamlandıktan sonra çalıştığını doğrulamak için:

docker logs -f ollama

Log akışı sorunsuzsa bir sonraki adım modele karar vermek. Ollama’nın güçlü yanı, modeli tek satır komutla indirip çalıştırabilmesi. Örneğin hafif ve hızlı bir başlangıç için:

docker exec -it ollama ollama run llama3.1

Bu komut, model yoksa indirir ve ardından etkileşimli sohbet başlatır. İndirme süresi internet hızınıza ve model boyutuna bağlıdır.

2) Open WebUI ile Web Arayüzü Eklemek

Terminalde konuşmak tamam, ama günlük kullanımda web arayüzü büyük rahatlık. Open WebUI, Ollama ile çok iyi çalışan modern bir arayüz sunuyor. Aynı makinede çalışacak şekilde şu komutu kullanabilirsiniz:

docker run -d --name open-webui -p 3000:8080 -e OLLAMA_BASE_URL=http://host.docker.internal:11434 -v open-webui:/app/backend/data ghcr.io/open-webui/open-webui:main

Linux üzerinde host.docker.internal her zaman hazır gelmeyebilir. Böyle bir durumda iki pratik seçenek var: (1) Ollama ve Open WebUI’yi aynı Docker ağına almak, (2) Ollama’yı doğrudan makinenin IP’si üzerinden çağırmak. En temiz yöntem, iki servisi aynı ağda koşturmaktır. Örneğin:

docker network create llm-net

docker network connect llm-net ollama

docker rm -f open-webui

docker run -d --name open-webui --network llm-net -p 3000:8080 -e OLLAMA_BASE_URL=http://ollama:11434 -v open-webui:/app/backend/data ghcr.io/open-webui/open-webui:main

Ardından tarayıcıdan http://localhost:3000 adresine giderek arayüzü açın. İlk girişte kullanıcı oluşturmanız istenir. Sonrasında “Models” bölümünden Ollama’da hazır olan modeli seçerek sohbet edebilirsiniz.

3) Performans ve Kalite İçin İnce Ayarlar

Yerel LLM deneyimini iyi yapan şey sadece kurulum değil; doğru model ve doğru ayarlar. Öncelikle model seçimi: Hafif kullanım için 7B–8B sınıfı modeller, kod üretimi için “code” odaklı varyantlar, daha yüksek kalite için 14B ve üzeri tercih edilebilir. RAM sınırlıysa daha küçük modelle başlayın; aksi halde sistem “swap” kullanmaya başlar ve hız dramatik biçimde düşer.

İkinci kritik konu: context (bağlam) uzunluğu. Daha uzun bağlam daha iyi “hatırlama” sağlar, fakat RAM tüketimini artırır. Open WebUI tarafında model ayarlarından bağlam ve üretim parametrelerini (örneğin temperature) dengeli seçmek önemli. Örneğin teknik dokümantasyon, özetleme gibi işlerde daha düşük temperature daha tutarlı sonuç verir.

Üçüncü konu: veri kalıcılığı. Burada hem Ollama hem Open WebUI için volume kullandığımızdan, konteyneri silseniz bile modeller ve sohbet geçmişi (kurulumunuza bağlı olarak) korunur. Bu, Blogger okurları için pratik bir detay: “kur-düşür-kur” senaryolarında zaman kaybetmezsiniz.

4) Basit Bir Sorun Giderme Listesi

Port çakışması: 11434 veya 3000 doluysa, komutlarda host portunu değiştirin (ör. 3001:8080). Model inmiyor: Docker’ın internet erişimini ve disk alanını kontrol edin. Open WebUI model görmüyor: OLLAMA_BASE_URL değerinin doğru olduğundan emin olun; aynı ağdaysa “http://ollama:11434” kullanın. Performans düşük: Daha küçük modele geçin, bağlam uzunluğunu azaltın veya arka planda ağır uygulamaları kapatın.

Sonuç: Yerel LLM ile Kontrol Sizde

Ollama + Open WebUI kombinasyonu, yerelde LLM çalıştırmayı şaşırtıcı derecede erişilebilir hale getiriyor. Docker ile kurulum hem temiz hem de taşınabilir; üstelik gizlilik ve maliyet avantajları da cabası. İster kişisel notlarınızı özetlemek, ister kod fikirleri almak, ister kapalı ağda çalışan bir asistan kurmak isteyin, bu yapı sağlam bir temel sunuyor. Bir sonraki adım olarak farklı modelleri deneyip, Open WebUI’de sistem yönergeleri (system prompt) ve şablonlarla kendi kullanım senaryonuza göre ince ayar yapabilirsiniz.

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.