VPS'te Nginx, Alan Adı ve HTTPS Kurulumu

Önce yayın yolunu netleştirin

Alan adınızın A kaydını VPS’nin IPv4 adresine yönlendirin. www alt alanını da kullanacaksanız onun için A veya uygun CNAME kaydı gerekir. IPv6 kullanmıyorsanız başka bir sunucuya giden eski AAAA kaydını bırakmayın. Tarayıcı veya sertifika doğrulayıcı IPv6’yı seçtiğinde yalnız bazı ziyaretçilerin hata görmesi bu yüzden olabilir.

DNS sağlayıcınız bir proxy/CDN sunuyorsa ilk doğrulamada hangi uç noktanın yanıt verdiğini bilin. Sertifika isteği, seçtiğiniz doğrulama yöntemine göre alan adından sunucuya ulaşabilmelidir. DNS yayılımı için tek sabit bekleme süresi varsaymayın; yetkili kaydı ve dış çözümleyicilerdeki yanıtı kontrol edin.

getent ahosts example.com
getent ahosts www.example.com

Nginx’i kurun ve önce HTTP yanıtını doğrulayın

Yeni test sunucusunda dağıtımın paketlerini kullanın. Bu işlem mevcut Nginx kurulumunu ve sitelerini devralmak için bir göç talimatı değildir. UFW etkinse önce SSH erişiminizin izinli olduğunu doğrulayın; sonra yalnız web portlarını ekleyin. Sunucuyu yönettiğiniz SSH oturumunu testler bitene kadar açık tutun.

sudo apt update
sudo apt install nginx
sudo install -d -m 0755 /var/www/example.com
printf '<!doctype html><html lang="tr"><meta charset="utf-8"><title>İlk yayın</title><h1>VPS yayında</h1></html>\n' | sudo tee /var/www/example.com/index.html >/dev/null
sudo ufw status
# Yalnız UFW kullanıyorsanız ve SSH kuralınız doğrulandıysa:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Aşağıdaki dosyayı /etc/nginx/sites-available/example.com adıyla kaydedin. root satırındaki dizin ile dosyanın yerini eşleştirin. Varsayılan siteyi silmek yerine alan adınıza ait server_name eşleşmesini test edin. IPv6 dinleme satırı IPv6 destekleyen normal Ubuntu kurulumları içindir.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com;
    index index.html;

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

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t
# Test başarılıysa:
sudo systemctl reload nginx
curl -I -H "Host: example.com" http://127.0.0.1/
curl -I http://example.com/

HTTP çalıştıktan sonra HTTPS sertifikasını alın

Certbot’un resmî Nginx yönergesi snap kurulumunu önerir. Mevcut bir Certbot kurulumu varsa apt ve snap yöntemlerini üst üste eklemek yerine mevcut kurulumun kaynağını ve yenileme görevini inceleyin. Aşağıdaki adımlar Certbot kurulmamış yeni Ubuntu 24.04 sunucusu içindir. Sertifika almak için yalnız yönlendirmesini yaptığınız ve erişilebilir alan adlarını ekleyin.

sudo apt install snapd
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo cp -a /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.before-tls
sudo certbot --nginx -d example.com -d www.example.com

Certbot’un e-posta ve kullanım koşulları sorularını yanıtlayın; HTTP’den HTTPS’e yönlendirme seçimini değerlendirin. www kaydı hazır değilse o adı komuta eklemeyin. Başarısız denemeleri hızlıca tekrarlamak yerine doğrulama hatasını çözün; sertifika otoritesinin istek sınırları vardır.

sudo nginx -t
curl -I https://example.com/
curl -I http://example.com/
sudo certbot certificates
sudo certbot renew --dry-run
systemctl list-timers --all | grep certbot

Başarılı dry-run, mevcut koşullarda yenileme provasının geçtiğini gösterir. DNS, güvenlik duvarı veya Nginx yönlendirmesi sonradan değişirse yenileme yine bozulabilir. Sertifika bitiş süresini dışarıdan izlemek ve yenileme günlüklerini kontrol etmek bakımın parçasıdır. Sertifikanın varlığı uygulamanın güvenli veya yedekli olduğu anlamına gelmez.

Hata mesajını doğru katmanda çözün

sudo systemctl status nginx --no-pager
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.log

Günlükleri destek için paylaşırken kullanıcı IP’lerini, oturum belirteçlerini ve URL içindeki özel bilgileri ayıklayın. Yeni bir site hatasında tüm sunucunun dosya izinlerini 777 yapmak veya güvenlik duvarını kapatmak sorunu kalıcı olarak çözmez; erişimi gereksiz yere genişletir.

Yayını tamamlayın ve geri dönüş yolunu koruyun

• Ana alan ve www için beklediğiniz HTTPS yanıtını ayrı ayrı açın; hangi adresin asıl adres olduğunu belirleyin.
• Var olmayan bir dosyanın gerçek 404 döndürdüğünü kontrol edin. Her hatayı ana sayfaya yönlendirmeyin.
• HTML içindeki canonical, iç bağlantılar ve sitemap aynı HTTPS adresini kullanmalı.
• Yeni yapılandırmayı nginx -t sonrasında yükleyin. Önceki dosyayı ve sertifika düzenini yedekleyin.
• Uygulama dosyaları ve veri için VPS dışında yedek alın; sertifika yenilemesi bir yedekleme yöntemi değildir.

Bu yapı statik site sunar. Node.js gibi çalışan bir uygulama için root dizini yerine reverse proxy gerekir; aşağıdaki ilgili Node.js rehberi bu modeli açıklar. Önbellek ve sıkıştırmayı eklemeden önce doğru içerik, durum kodu ve HTTPS davranışını doğrulayın. Küçük bir site için en düşük paket kaynak açısından yeterli olabilir; gerçek gereksinimi içerik boyutu, ziyaret yoğunluğu ve ek uygulamalar belirler.