VDS’ye Nginx veya Apache ile Web Sunucusu Kurma

VDS üzerine web sunucusu kurmak, Ubuntu 24.04 LTS üzerinde yaklaşık yirmi dakikalık bir iştir: Nginx’i kurar, güvenlik duvarında 80 ve 443 portlarını açar, siteniz için bir sunucu bloğu tanımlar, PHP-FPM’i bağlar ve Let’s Encrypt ile ücretsiz SSL sertifikası alırsınız. Bu sayfa tüm zinciri sırayla, çalışan komutlarla anlatıyor.

Yazının omurgası Nginx üzerinden ilerliyor çünkü sıfırdan kurulan sunucuların çoğunda doğru tercih odur. Apache’yi göz ardı etmiyoruz: hangi durumda hangisinin daha mantıklı olduğunu karşılaştırma tablosuyla netleştiriyoruz. Sunucunuz yeni teslim edildiyse önce ilk ayarlar listesini bitirin — web sunucusu kurmadan önce SSH anahtarı ve güvenlik duvarı hazır olmalı.

Nginx mi Apache mi? Hangisi, Ne Zaman?#

İkisi de olgun, ikisi de güvenilir. Fark mimaride başlıyor. Apache klasik olarak her bağlantı için bir süreç ya da iş parçacığı ayırır; Nginx ise sabit sayıda işçi süreçle olay tabanlı çalışır ve binlerce bağlantıyı aynı süreç içinde yönetir. Pratikte bu, aynı RAM ile Nginx’in daha fazla eşzamanlı ziyaretçi taşıması demek.

Karar kuralı kısa: uygulamanız .htaccess’e bağımlı değilse Nginx. Yüksek trafikli siteler, API’ler, ters vekil senaryoları, sınırlı RAM’li paketler ve statik ağırlıklı içerik Nginx’i işaret eder. Apache’yi ise hazır kurulum betiği onu istiyorsa, eski bir uygulamayı taşıyorsanız ya da müşterilerinize dizin bazlı yapılandırma hakkı vereceğiniz bir barındırma kurgunuz varsa seçin. Kural dosyalarının nasıl çalıştığını merak ediyorsanız .htaccess kullanımı sayfası örneklerle anlatıyor.

Bir noktayı da açıkça söyleyelim: performans farkı, küçük ve orta ölçekli bir sitede ziyaretçinin hissedeceği bir şey değildir. Günde birkaç bin ziyaret alan bir sitede Apache de Nginx de rahat çalışır; sayfa hızını asıl belirleyen web sunucusu değil, veritabanı sorguları ve görsel boyutlarıdır. Fark, eşzamanlı bağlantı sayısı yükselip RAM sınıra dayandığında ortaya çıkar. Yani seçimi “hangisi hızlı” diye değil, “hangisi benim uygulamama uyuyor” diye yapın.

Bu arada üçüncü bir seçenek daha var: ikisini birlikte kullanmak. Nginx’i önde ters vekil olarak, Apache’yi arkada uygulama sunucusu olarak konumlandıran kurgular hala yaygındır. Ama tek sunuculu, tek siteli bir kurulumda bu karmaşıklığı üstlenmenin bir anlamı yok.

Ubuntu 24.04’te Nginx Kurulumu ve Dizin Yapısı#

Kurulum tek satır. Ardından servisin ayağa kalktığını ve açılışta otomatik başlayacağını doğrulayın:

sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx

# Servis durumu ve otomatik başlatma
sudo systemctl status nginx --no-pager
sudo systemctl enable --now nginx

# Sürümü ve derleme seçeneklerini gör
nginx -v
# nginx version: nginx/1.24.0 (Ubuntu)

# Dinlenen portlar
sudo ss -tulpn | grep nginx

Tarayıcıdan sunucunun IP adresini açtığınızda “Welcome to nginx!” sayfasını görüyorsanız kurulum tamamdır. Görmüyorsanız sorun büyük ihtimalle güvenlik duvarındadır; bir sonraki bölüm onu çözüyor.

Nginx dosyaları nerede?#

Dizin yapısını baştan öğrenmek, sonraki her adımı kolaylaştırır:

/etc/nginx/nginx.conf

Ana yapılandırma. Genel ayarlar (işçi süreç sayısı, server_tokens, günlük biçimi) buradadır.

/etc/nginx/sites-available/

Site yapılandırmalarının durduğu klasör. Buraya yazmak siteyi aktif etmez.

/etc/nginx/sites-enabled/

Aktif siteler. İçindekiler sites-available’a verilen sembolik bağlantılardır.

/etc/nginx/snippets/

Tekrar kullanılan yapılandırma parçaları. fastcgi-php.conf burada durur.

/var/www/

Site dosyalarının kök dizini. Varsayılan sayfa /var/www/html içindedir.

/var/log/nginx/

Erişim ve hata günlükleri: access.log ve error.log.

# Aktif site listesi
ls -l /etc/nginx/sites-enabled/

# Varsayılan siteyi devre dışı bırak (kendi siteniz hazır olduğunda)
sudo unlink /etc/nginx/sites-enabled/default

# Yapılandırmanın tamamını çözümlenmiş hâliyle gör
sudo nginx -T | head -60

Güvenlik duvarında 80 ve 443 portlarını açma#

Nginx kurulduğunda UFW’ye kendi uygulama profillerini kaydeder. Elle port yazmak yerine bu profilleri kullanmak daha temizdir:

# Nginx'in tanımladığı profiller
sudo ufw app list
# Available applications:
#   Nginx Full
#   Nginx HTTP
#   Nginx HTTPS
#   OpenSSH

# 80 ve 443'ü birlikte aç
sudo ufw allow 'Nginx Full'

# SSH kuralını eklemeden UFW'yi ETKİNLEŞTİRMEYİN
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

# Elle yazmayı tercih ederseniz
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

Yalnızca 443’ü açıp 80’i kapatmak cazip gelebilir ama yapmayın: Let’s Encrypt doğrulaması 80 portu üzerinden çalışır ve HTTP’den HTTPS’e yönlendirme de o portu ister.

Sunucu Bloğu (Server Block) Tanımlama#

Sunucu bloğu, Nginx’e “şu alan adı geldiğinde şu klasörden cevap ver” diyen yapılandırmadır. Apache tarafındaki adı sanal host. Önce dizini ve dosyayı hazırlayın:

# Site kök dizini
sudo mkdir -p /var/www/ornekalanadi.com/public
echo '<h1>Site ayakta</h1>' | sudo tee /var/www/ornekalanadi.com/public/index.html

# Yapılandırma dosyasını oluştur
sudo nano /etc/nginx/sites-available/ornekalanadi.com

server {
    listen 80;
    listen [::]:80;

    server_name ornekalanadi.com www.ornekalanadi.com;
    root /var/www/ornekalanadi.com/public;
    index index.php index.html;

    access_log /var/log/nginx/ornekalanadi.com.access.log;
    error_log  /var/log/nginx/ornekalanadi.com.error.log;

    location / {
        try_files $uri $uri/ =404;
    }

    # PHP isteklerini PHP-FPM'e devret
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    # Nokta ile başlayan dosyalara erişimi kapat (.env, .git)
    location ~ /\. {
        deny all;
    }

    # Statik dosyalara uzun önbellek
    location ~* \.(jpg|jpeg|png|gif|webp|svg|css|js|woff2)$ {
        expires 30d;
        access_log off;
    }
}

# Siteyi etkinleştir: sembolik bağlantı ver
sudo ln -s /etc/nginx/sites-available/ornekalanadi.com \
           /etc/nginx/sites-enabled/

# Sözdizimini TEST ET, sonra uygula
sudo nginx -t
# nginx: configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

sudo systemctl reload nginx

Alan adının bu sunucuya bakması için DNS tarafında A kaydı gerekir. Kayıt tiplerini ve TTL mantığını DNS kayıtları rehberi anlatıyor; alan adınız henüz yoksa önce o işi bitirin. DNS yayılmadan SSL adımına geçemezsiniz, çünkü Let’s Encrypt doğrulaması alan adının gerçekten bu sunucuya çözümlendiğini kontrol eder.

Sunucu bloğu satır satır ne yapıyor?#

listen 80; hangi portun dinleneceğini, server_name hangi alan adlarına cevap verileceğini söyler. Nginx gelen isteğin Host başlığına bakıp eşleşen bloğu bulur; hiçbiri eşleşmezse default_server işaretli blok devreye girer. Kurulumdan sonra hâlâ varsayılan Nginx sayfasını görüyorsanız sebebi genelde budur: sizin bloğunuz eşleşmemiştir.

root dosyaların diskteki yerini, index ise klasör istendiğinde hangi dosyanın açılacağını belirler. try_files satırı ise şunu yapar: önce istenen dosyayı arar, bulamazsa aynı adda bir klasör dener, o da yoksa 404 döndürür. WordPress gibi güzel URL kullanan uygulamalarda bu satırın sonundaki =404 yerine /index.php yönlendirmesi gelir; aksi hâlde ana sayfa dışındaki her adres 404 verir.

PHP-FPM Kurulumu ve Nginx’e Bağlama#

Nginx PHP çalıştırmaz; PHP kodunu ayrı bir sürece devreder. Ubuntu 24.04 deposundaki sürüm PHP 8.3’tür:

sudo apt install -y php8.3-fpm php8.3-mysql php8.3-curl \
  php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl

sudo systemctl enable --now php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager

# Soketin gerçekten oluştuğunu doğrulayın
ls -l /run/php/
# srw-rw---- 1 www-data www-data 0 Ağu 26 10:12 php8.3-fpm.sock

php -v
php -m | head -20

Soket adı ile sunucu bloğundaki fastcgi_pass satırının birebir aynı olması gerekir. Bu iki değerin uyuşmaması, “502 Bad Gateway” hatasının bir numaralı sebebidir — özellikle internetteki eski rehberlerden kopyalanan php8.1-fpm.sock ya da php8.2-fpm.sock satırları yüzünden.

PHP’nin çalıştığını doğrulamak için geçici bir test dosyası oluşturun, gördükten sonra hemen silin:

echo '<?php phpinfo();' | sudo tee /var/www/ornekalanadi.com/public/test.php
curl -s http://localhost/test.php | grep -o 'PHP Version [0-9.]*' | head -1
# PHP Version 8.3.6

# Gördükten sonra sil - sunucu bilgilerini dışarıya açar
sudo rm /var/www/ornekalanadi.com/public/test.php

Site başına ayrı PHP-FPM havuzu#

Birden fazla site barındıracaksanız hepsini varsayılan www-data havuzunda çalıştırmayın. Her siteye kendi havuzunu ve kendi kullanıcısını verin:

; /etc/php/8.3/fpm/pool.d/ornekalanadi.conf
[ornekalanadi]
user = web1
group = web1

listen = /run/php/php8.3-fpm-web1.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500

php_admin_value[open_basedir] = /var/www/ornekalanadi.com:/tmp
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/php-web1-error.log

Ardından sunucu bloğundaki fastcgi_pass satırını yeni sokete çevirip sudo systemctl restart php8.3-fpm çalıştırın. Bu ayrım, bir sitedeki güvenlik açığının diğer sitelerin dosyalarına uzanmasını engeller.

pm.max_children değerini rastgele seçmeyin. Kaba hesap şöyle: tek bir PHP sürecinin ortalama bellek kullanımını ölçün (WordPress için genelde 40–80 MB arası), PHP’ye ayırmak istediğiniz belleği bu değere bölün. 8 GB’lık bir sunucuda veritabanına ve işletim sistemine pay ayırdıktan sonra PHP’ye 3 GB kalıyorsa, 60 MB’lık süreçlerle sınır kabaca 50 olur. Değeri gereğinden yüksek vermek daha kötüdür: yoğun anda sunucu takasa düşer ve site tamamen kilitlenir.

Let’s Encrypt ile Ücretsiz SSL#

HTTPS artık isteğe bağlı değil. Sertifika ücretsiz, kurulum tek komut. Certbot’u snap üzerinden kurmak, Let’s Encrypt’in önerdiği ve en güncel sürümü veren yoldur:

sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -sf /snap/bin/certbot /usr/bin/certbot

# Sertifikayı al ve Nginx yapılandırmasını otomatik düzenle
sudo certbot --nginx -d ornekalanadi.com -d www.ornekalanadi.com

# Otomatik yenilemenin çalıştığını test et
sudo certbot renew --dry-run

# Kurulu sertifikaları ve bitiş tarihlerini listele
sudo certbot certificates
sudo systemctl list-timers | grep certbot

Certbot işini bitirdiğinde sunucu bloğunuza 443 dinleyen bir bölüm ekler ve 80 portundan gelen istekleri HTTPS’e yönlendirir. Yönlendirme satırı şuna benzer:

server {
    listen 80;
    listen [::]:80;
    server_name ornekalanadi.com www.ornekalanadi.com;
    return 301 https://$host$request_uri;
}

Sertifika 90 gün geçerlidir ve certbot bıraktığı systemd zamanlayıcısıyla otomatik yeniler. Sertifika türleri, zincir yapısı ve karışık içerik (mixed content) sorunları için SSL sertifikası kurulumu sayfasına bakabilirsiniz. Sitenizin önünde Cloudflare gibi bir vekil katman varsa SSL modunun “Full (strict)” olması gerektiğini unutmayın; “Flexible” modu vekil ile sunucunuz arasındaki trafiği şifresiz bırakır ve sertifikanız olmasına rağmen zinciri kırar.

İzinler ve Kullanıcı Ayrımı#

Bu bölüm atlanmaya en müsait, sonuçları en pahalı bölüm. Site dosyalarının sahibi root olmamalı, PHP root ile çalışmamalı ve web sunucusu ihtiyacından fazla yetkiye sahip olmamalı.

# Siteye özel, giriş yapamayan bir sistem kullanıcısı
sudo adduser --system --group --home /var/www/ornekalanadi.com web1

# Dosya sahipliği kullanıcıya, okuma yetkisi Nginx'e
sudo chown -R web1:web1 /var/www/ornekalanadi.com
sudo usermod -aG web1 www-data

# Dizinler 750, dosyalar 640
sudo find /var/www/ornekalanadi.com -type d -exec chmod 750 {} \;
sudo find /var/www/ornekalanadi.com -type f -exec chmod 640 {} \;

# Yükleme klasörü gibi yazılabilir olması gereken yerler
sudo chmod 770 /var/www/ornekalanadi.com/public/uploads

sudo systemctl reload nginx
ls -la /var/www/ornekalanadi.com/

Dikkat edilecek üç nokta var. Birincisi, 777 izni hiçbir zaman doğru cevap değildir; bir sorunu chmod 777 ile çözdüyseniz sorunu çözmediniz, ertelediniz. İkincisi, yükleme klasörlerinde PHP çalıştırmayı kapatın — saldırganın yüklediği bir dosyanın çalıştırılabilmesi en yaygın ele geçirme yoludur. Üçüncüsü, .env ve .git gibi dosyalar sunucu bloğundaki location ~ /\. kuralıyla zaten kapalı olmalı.

# Yükleme klasöründe PHP çalıştırmayı tamamen kapat
location ^~ /uploads/ {
    location ~ \.php$ { deny all; }
}

Temel Sertleştirme: server_tokens, Dizin Listeleme ve Başlıklar#

Varsayılan Nginx kurulumu güvenli sayılır ama üç şeyi kapatmadan üretime almayın. Hepsi birer satır.

# /etc/nginx/nginx.conf içindeki http { ... } bloğunun içine

    # Sürüm numarasını hata sayfalarında ve başlıklarda gizle
    server_tokens off;

    # Dizin listelemesi (Nginx'te varsayılan kapalı, açıkça belirtin)
    autoindex off;

    # Yükleme boyutu sınırı
    client_max_body_size 32m;

    # Yavaş istemci saldırılarına karşı zaman aşımları
    client_body_timeout 12s;
    client_header_timeout 12s;
    send_timeout 10s;

    # Güvenlik başlıkları
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

sudo nginx -t && sudo systemctl reload nginx

# Sürüm bilgisi gerçekten gizlendi mi?
curl -sI https://ornekalanadi.com | grep -i server
# server: nginx          <-- sürüm numarası yok, doğru

# Güvenlik başlıkları geliyor mu?
curl -sI https://ornekalanadi.com | grep -iE 'x-frame|x-content|referrer'

Küçük bir not: Nginx’te dizin listeleme zaten varsayılan olarak kapalıdır, buna karşılık Ubuntu’nun hazır Apache yapılandırmasında /var/www için Options Indexes açık gelir. Yani Apache kuruyorsanız bu maddeyi elle kapatmanız gerekir; Nginx’te sadece niyetinizi açıkça yazmış olursunuz.

Sertleştirmenin bir sonraki adımı, başarısız giriş ve saldırı denemelerini otomatik engellemektir. Fail2ban Nginx günlüklerini de izleyebilir ve tekrarlayan 4xx yağmuru üreten IP’leri güvenlik duvarında keser.

Günlük Dosyaları ve Sorun Giderme#

Bir şey çalışmadığında bakılacak yer bellidir: /var/log/nginx/error.log. Tahmin yürütmeden önce günlüğü okuyun.

# Canlı hata takibi
sudo tail -f /var/log/nginx/error.log

# Siteye özel günlükler
sudo tail -n 100 /var/log/nginx/ornekalanadi.com.error.log

# Servis seviyesindeki hatalar (başlatma sorunları burada)
sudo journalctl -u nginx -n 50 --no-pager
sudo journalctl -u php8.3-fpm -n 50 --no-pager

# Hangi HTTP durum kodu kaç kez döndü?
sudo awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# En çok istek yapan 10 IP
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Erişim günlüğünün varsayılan biçimi her satırda sırasıyla şunları tutar: istemci IP’si, zaman damgası, istek satırı, HTTP durum kodu, gönderilen bayt, yönlendiren adres ve tarayıcı kimliği. Yukarıdaki awk örneklerindeki birinci ve dokuzuncu alanlar da buradan gelir. Durum kodu dağılımına bakmak çoğu zaman ilk ipucunu verir: 404 sayısı bir anda patladıysa ya bir bağlantı kırılmıştır ya da biri sunucunuzda açık dosya tarıyordur.

Günlükler dönmezse disk dolar. Ubuntu’da Nginx için hazır bir logrotate tanımı gelir (/etc/logrotate.d/nginx) ama siteye özel günlük dosyaları eklediyseniz o tanımın onları da kapsadığını doğrulayın. Günlük boyutlarını haftada bir kontrol etmek iyi bir alışkanlıktır; şişmiş bir erişim günlüğü hem yer yer hem yazma yükü üretir.

Kurulumdan Sonra: Site Yayında, Sırada Ne Var?#

Yığın ayakta. Bundan sonrası içerik ve dayanıklılık.

• Uygulamanızı kurun. WordPress kuracaksanız veritabanı oluşturma ve wp-config.php adımları için WordPress kurulumu sayfasına geçin.
• Yedekleme kurun. Site dosyaları ve veritabanı her gece sunucu dışına çıkmalı. Snapshot bu işi görmez.
• Hız optimizasyonu yapın. Gzip/Brotli sıkıştırma, önbellek başlıkları ve görsel boyutları için site hızlandırma rehberi.
• İzleme ekleyin. Sitenin düştüğünü ziyaretçiden öğrenmeyin.

Kaynak tarafında pratik bir ölçü: birkaç düşük trafikli site 8 GB RAM ve NVMe diskli bir pakette rahat çalışır; trafik büyüdükçe darboğaz genelde PHP-FPM havuz sınırında ve veritabanında ortaya çıkar. 156 TL’den başlayan VDS paketleri arasında geçiş yapmadan önce ölçüm almanız işinizi kolaylaştırır. Kurulumda takıldığınız bir yer olursa destek talebi açabilirsiniz.

Özetle#

Ubuntu 24.04 üzerinde web sunucusu kurmanın sırası şu: apt install nginx, güvenlik duvarında Nginx Full profilini açma, sites-available altında bir sunucu bloğu yazıp sites-enabled’a bağlama, php8.3-fpm kurup fastcgi_pass unix:/run/php/php8.3-fpm.sock; satırıyla bağlama ve certbot --nginx ile SSL alma. Her yapılandırma değişikliğinden sonra nginx -t, sonra reload.

Nginx ile Apache arasındaki seçim de tek soruya iner: uygulamanız .htaccess istiyor mu? İstemiyorsa Nginx daha az bellekle daha fazla bağlantı taşır. Kurulum bittikten sonra atlanmaması gereken iki iş kalır — site başına ayrı kullanıcı ve PHP-FPM havuzu tanımlamak, bir de server_tokens off ile başlayan üç satırlık sertleştirme. Bunlar herşey yolundayken beş dakika sürer; bir sorun çıktıktan sonra ise geri dönüşü olmayabilir.