Nginx Kurulumu Nasıl Yapılır? Adım Adım Yapılandırma Rehberi

Nginx kurulumu nedir ve hangi adımlardan oluşur?
Nginx kurulumu, açık kaynaklı Nginx web sunucusunu bir Linux sunucuya paket yöneticisiyle yükleyip servis olarak çalıştırma ve site için ilk yapılandırmayı yazma sürecidir. Paketi kurarsınız, servisi etkinleştirirsiniz, bir server bloğu tanımlarsınız, ayarı nginx -t ile test edersiniz ve son olarak SSL, log ve güvenlik ayarlarını tamamlarsınız.
Bu rehberi Talha Aslan ve ekibi olarak resmi belgelere dayanarak hazırladık. Biz bir hosting firması değiliz; dijital pazarlama, web tasarım ve yazılım ekibiyiz. Bu nedenle komutları kendi sunucu işletme iddiamıza değil, nginx.org, Ubuntu ve Certbot belgelerine dayandırıyoruz. Sürüm numarası vermiyoruz; her zaman dağıtımınızın ya da nginx.org deposunun güncel kararlı sürümünü kullanmanızı öneriyoruz.
Süreci kabaca dört aşamaya ayırabilirsiniz:
- Kurulum: dağıtım deposundan ya da resmi nginx.org deposundan paketi yüklemek.
- Servis yönetimi: systemctl ile başlatmak, açılışta etkinleştirmek ve durumunu izlemek.
- Yapılandırma: nginx.conf yapısını anlamak, ilk server bloğunu yazmak ve test etmek.
- Sağlamlaştırma: SSL, güvenlik başlıkları, sürüm gizleme, log takibi ve güvenlik duvarı.
Nginx ne işe yarar ve hangi durumlarda tercih etmelisiniz?
Nginx hem web sunucusu hem de ters vekil (reverse proxy) olarak çalışan bir yazılımdır. Resmi başlangıç rehberine göre bir ana (master) süreç yapılandırmayı okur, işçi (worker) süreçler ise istekleri olay tabanlı bir modelle işler. Böylece az bellekle çok sayıda eş zamanlı bağlantıyı yönetebilir.
Pratikte Nginx'i şu işler için kurarsınız:
- HTML, CSS, JavaScript ve görsel gibi statik dosyaları hızlı sunmak.
- PHP uygulamalarını PHP-FPM üzerinden çalıştırmak.
- Node.js, Python ya da Go uygulamalarının önünde ters vekil olarak durmak.
- SSL sonlandırma, yönlendirme ve basit yük dengeleme yapmak.
Öte yandan her proje için en iyi seçim Nginx olmayabilir. Örneğin paylaşımlı hostingde sunucu yazılımını zaten siz seçmezsiniz. Panel tabanlı bir kurulum istiyorsanız OpenLiteSpeed gibi alternatifleri de değerlendirin; iki sunucunun farklarını OpenLiteSpeed ve Nginx karşılaştırması yazımızda ayrıntılı anlattık, burada tekrar etmiyoruz.
Nginx kurulumu öncesinde neleri hazırlamalısınız?
Kuruluma başlamadan önce birkaç temel hazırlığı tamamlarsanız sonraki adımlar çok daha sorunsuz ilerler. Özellikle alan adı ve DNS tarafı, SSL aşamasında sık takılan noktadır.
- sudo yetkili bir kullanıcı ve SSH erişimi olan, güncel bir Linux sunucu.
- Sunucunun genel IP adresini gösteren bir alan adı (A ve gerekirse AAAA kaydı).
- 80 ve 443 numaralı portlara dışarıdan erişim izni.
- Sitenin dosyalarını koyacağınız dizin için net bir plan.
- Değişiklikten önce aldığınız bir yedek ya da sağlayıcı anlık görüntüsü.
Sunucuyu sıfırdan hazırlıyorsanız önce Ubuntu Server kurulumu ve ilk yapılandırma adımlarını tamamlayın. Ayrıca alan adınızın doğru IP adresine gidip gitmediğini DNS sorgulama aracı ile kontrol edebilirsiniz. DNS yayılmadan Certbot doğrulaması başarısız olur, bu yüzden bu kontrolü atlamayın.
Son olarak sunucuda başka bir web sunucusunun 80 portunu kullanıp kullanmadığına bakın. Örneğin önceden Apache kurduysanız Nginx kurulumu bitse bile servis başlamaz, çünkü iki yazılım aynı portu dinleyemez. sudo ss -tlnp komutu, hangi sürecin hangi portu dinlediğini gösterir.
Ubuntu ve Debian'da Nginx kurulumu için hangi komutları kullanırsınız?
En kolay yol, dağıtımın kendi deposundaki paketi kullanmaktır. Ubuntu Server belgeleri kurulumu iki komutla tarif ediyor:
sudo apt update
sudo apt install nginx
Ubuntu'da paket kurulunca servis genellikle kendiliğinden başlar. Durumunu şu komutla kontrol edersiniz:
sudo systemctl status nginx
Çıktıda "active (running)" ifadesini görüyorsanız Nginx çalışıyor demektir. Ardından tarayıcıda sunucunun IP adresini açın; Nginx karşılama sayfası geliyorsa ilk aşama tamamdır. Sayfa açılmıyorsa sorun büyük olasılıkla güvenlik duvarındadır; bu konuya aşağıda ayrıca değiniyoruz.
Debian ve Ubuntu paketinde site dosyaları için sites-available ve sites-enabled düzeni gelir. Varsayılan belge kökü ise /var/www/html dizinidir. Bu düzen, birden fazla siteyi ayrı dosyalarda yönetmenizi kolaylaştırır. Ayrıca bir siteyi kapatmak için yalnız bağlantısını kaldırmanız yeterli olur.
AlmaLinux, Rocky Linux ve RHEL'de Nginx kurulumu nasıl farklılaşır?
RHEL ailesinde paket yöneticisi dnf'dir ve Nginx paketi dağıtım deposundan gelir. Kurulum komutu şöyledir:
sudo dnf install nginx
sudo systemctl enable --now nginx
Debian tarafından farklı olarak bu dağıtımlarda servis kurulumdan sonra kendiliğinden başlamaz; enable --now hem açılışta başlatmayı etkinleştirir hem de servisi hemen çalıştırır. Yapılandırma düzeni de farklıdır: site dosyalarını /etc/nginx/conf.d dizinine .conf uzantısıyla koyarsınız.
Bu ailede dikkat etmeniz gereken ikinci konu SELinux'tur. Siteyi standart dışı bir dizine koyarsanız ya da Nginx'i bir arka uç uygulamaya bağlarsanız SELinux erişimi engelleyebilir. Bu durumda dosya izinleri doğru görünse bile 403 ya da 502 hatası alırsınız. Dağıtım seçimi aşamasındaysanız Rocky Linux mu AlmaLinux mu yazımız karar vermenize yardımcı olur.
Resmi nginx.org deposundan kurulum ne zaman mantıklıdır?
Dağıtım paketleri, dağıtımın test ettiği ve uzun süre desteklediği sürümleri sunar; ancak bazen daha eski bir dalda kalır. Daha yeni bir özelliğe ihtiyacınız varsa nginx.org'un resmi Linux paket deposunu kullanabilirsiniz. Depo iki dal sunar: stable ve mainline. Ubuntu için resmi sayfadaki adımları özetle şöyle uygularsınız:
sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring
curl -fsSL -o nginx_signing.key https://nginx.org/keys/nginx_signing.key
gpg --dearmor < nginx_signing.key | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg
Son komutun çıktısındaki parmak izini nginx.org Linux paketleri sayfasındaki değerle karşılaştırın; eşleşmiyorsa devam etmeyin. Ardından depo satırını ekleyip kurulumu tamamlarsınız:
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update
sudo apt install nginx
Resmi sayfa, dağıtım paketi yerine nginx.org paketinin seçilmesi için /etc/apt/preferences.d altında bir sabitleme (pinning) dosyası da öneriyor. RHEL ailesinde ise /etc/yum.repos.d/nginx.repo dosyasını oluşturursunuz. Ayrıntılar sürekli güncellendiği için komutları her zaman resmi sayfadan kopyalayın.
Dağıtım paketi mi, nginx.org paketi mi seçmelisiniz?
İki kaynak da güvenilirdir; fark, güncellik ile dağıtım uyumu arasındaki dengededir. Aşağıdaki tablo, kararı resmi belgelerdeki bilgilere göre özetliyor.
| Ölçüt | Dağıtım deposu (apt/dnf) | nginx.org stable | nginx.org mainline |
|---|---|---|---|
| Kurulum kolaylığı | Tek komut | Anahtar ve depo eklemek gerekir | Anahtar ve depo eklemek gerekir |
| Sürüm güncelliği | Dağıtımın dondurduğu sürüm | Güncel kararlı dal | En yeni özellikler |
| Güvenlik yamaları | Dağıtım güncellemeleriyle gelir | nginx.org paketleriyle gelir | nginx.org paketleriyle gelir |
| Site dosyası düzeni | Debian/Ubuntu: sites-available; RHEL: conf.d | conf.d | conf.d |
| Kime uygun | Çoğu web sitesi ve küçük işletme | Yeni özelliğe ihtiyaç duyan ekipler | Yeniliği test eden deneyimli ekipler |
Kısacası, özel bir modül ya da yeni bir yönerge ihtiyacınız yoksa dağıtım paketiyle başlamanızı öneriyoruz. Böylece güvenlik güncellemelerini işletim sistemiyle birlikte tek akışta alırsınız.
Nginx servisini systemctl ile nasıl yönetirsiniz?
Modern Linux dağıtımlarında Nginx bir systemd servisi olarak çalışır. Günlük işlerin neredeyse tamamını şu komutlarla yaparsınız:
sudo systemctl start nginx # başlat
sudo systemctl stop nginx # durdur
sudo systemctl restart nginx # tamamen yeniden başlat
sudo systemctl reload nginx # bağlantıları kesmeden ayarı yeniden yükle
sudo systemctl enable nginx # açılışta başlat
sudo systemctl status nginx # durumu göster
Restart ile reload arasındaki fark önemlidir. Restart servisi durdurup yeniden başlatır, bu yüzden kısa bir kesinti yaşanabilir. Reload ise ana sürecin yeni ayarı okumasını, eski işçi süreçlerin mevcut istekleri bitirip kapanmasını sağlar. Dolayısıyla yapılandırma değişikliklerinde reload tercih edin.
Nginx kurulumu sonrasında servisin açılışta başladığından emin olmak için systemctl is-enabled nginx komutunu da çalıştırabilirsiniz. Çıktı enabled ise sunucu yeniden başladığında siteniz de kendiliğinden geri gelir. Bu küçük kontrol, bakım sonrası yaşanan sessiz kesintilerin önüne geçer.
Resmi başlangıç rehberi aynı işi nginx -s reload, nginx -s quit ve nginx -s reopen sinyalleriyle de anlatıyor. Ancak systemd ile yönetilen bir sunucuda systemctl kullanmanız, servis durumunun tutarlı kalması açısından daha temizdir.
Nginx yapılandırma dosyaları nerede durur?
Paketle kurduğunuz Nginx'te ana yapılandırma dosyası /etc/nginx/nginx.conf yolundadır. Bu dosya, genel ayarları içeren http bloğunu ve diğer dosyaları çağıran include satırlarını barındırır. Klasör yapısını şöyle özetleyebiliriz:
- /etc/nginx/nginx.conf: ana dosya; worker_processes, olay ayarları ve http bloğu burada durur.
- /etc/nginx/sites-available/: Debian ve Ubuntu'da her sitenin server bloğu ayrı bir dosyada durur.
- /etc/nginx/sites-enabled/: etkin sitelerin sembolik bağlantıları; Nginx yalnız buradakileri okur.
- /etc/nginx/conf.d/: RHEL ailesinde ve nginx.org paketlerinde .conf uzantılı site dosyaları burada durur.
- /etc/nginx/snippets/: Debian ve Ubuntu'da tekrar kullanılabilir küçük yapılandırma parçaları.
Yapılandırma sözdizimi iç içe bloklardan oluşur: http bloğunun içinde server, server bloğunun içinde location blokları yer alır. Her yönerge noktalı virgülle biter. Bu yüzden en sık yazım hatası, satır sonunda unutulan noktalı virgüldür. Ana dosyayı mümkün olduğunca az değiştirip site ayarlarını ayrı dosyalarda tutmanız, güncellemelerde çakışma riskini de azaltır.
İlk server bloğunu nasıl yazarsınız?
Server bloğu, Apache'deki sanal konağın Nginx karşılığıdır. Örnek alan adı olarak example.com kullanalım. Önce site dizinini oluşturun ve içine basit bir index.html koyun:
sudo mkdir -p /var/www/example.com/html
sudo nano /etc/nginx/sites-available/example.com
Ardından dosyaya şu temel bloğu yazın:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/example.com/html;
index index.html index.htm;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
location / {
try_files $uri $uri/ =404;
}
}
Debian ve Ubuntu'da siteyi etkinleştirmek için sembolik bağlantı oluşturur, sonra test edip yeniden yüklersiniz:
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
RHEL ailesinde aynı bloğu /etc/nginx/conf.d/example.com.conf dosyasına yazmanız yeterlidir; sembolik bağlantıya gerek yoktur.
Server bloğundaki yönergeler ne anlama gelir?
Her satırın görevini bilirseniz hata ayıklamak çok kolaylaşır. nginx.org'un çekirdek HTTP modülü belgesi bu yönergelerin söz dizimini ve varsayılanlarını listeliyor.
- listen: sunucunun dinleyeceği adres ve port. default_server parametresi, eşleşmeyen istekleri bu bloğa yönlendirir.
- server_name: bloğun yanıt vereceği alan adları. Nginx ilk adı birincil ad kabul eder; joker karakter ve düzenli ifadeyle de çalışır.
- root: dosyaların arandığı kök dizin. Nginx, istek yolunu bu dizinin sonuna ekler.
- index: bir dizin istendiğinde Nginx'in sırayla aradığı dosyalar.
- try_files: dosyaların varlığını sırayla kontrol eder; hiçbiri yoksa son parametreye, örneğin =404 yanıtına geçer.
Örneğin ziyaretçi /hakkimda adresini istediğinde Nginx önce bu adla bir dosya, ardından aynı adla bir dizin arar. İkisini de bulamazsa 404 döndürür. Tek sayfa uygulamalarında son parametreyi /index.html yaparak tüm yolları uygulamaya bırakırsınız.
Location blokları ve statik içerik nasıl çalışır?
Location blokları, isteğin yoluna göre farklı kurallar uygulamanızı sağlar. Önek eşleşmesi en basit türdür; tilde işaretiyle başlayan bloklar ise düzenli ifade kullanır. Statik dosyalar için tarayıcı önbelleği tanımlamak sık kullanılan bir örnektir:
location ~* \.(css|js|png|jpg|jpeg|webp|svg|woff2)$ {
expires 30d;
access_log off;
}
location ~ /\.(?!well-known) {
deny all;
}
İlk blok, belirtilen dosya türleri için örnek olarak 30 günlük önbellek süresi tanımlar. Bu süre bir örnektir; dosya adlarınız sürüm içermiyorsa daha kısa tutun. İkinci blok ise .git ya da .env gibi gizli dosyalara erişimi kapatır. Ancak Certbot doğrulamasının kullandığı .well-known dizinini açık bırakır.
Statik dosya hızının sıralamaya etkisini merak ediyorsanız site hızı SEO'yu nasıl etkiler yazımıza bakabilirsiniz. Kısacası Nginx tarafındaki önbellek ayarı, ölçüm ve iyileştirme sürecinin yalnız bir parçasıdır.
Nginx'i PHP-FPM ile nasıl bağlarsınız?
Nginx PHP kodunu kendisi çalıştırmaz; isteği FastCGI protokolüyle PHP-FPM servisine iletir. Debian ve Ubuntu paketinde bunun için hazır bir snippet dosyası gelir. Bu yüzden server bloğuna şu kadar bir ekleme çoğu zaman yeterlidir:
index index.php index.html;
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
Soket dosyasının adı PHP sürümüne ve dağıtıma göre değişir. Bu nedenle ls /run/php/ komutuyla gerçek yolu kontrol edin ve fastcgi_pass satırını buna göre düzenleyin. Yanlış soket yolu, en sık görülen 502 nedenlerinden biridir.
WordPress ya da Laravel gibi uygulamalarda location / bloğundaki try_files satırını isteği index.php dosyasına yönlendirecek biçimde değiştirirsiniz. Laravel için ayrıntılı adımları Laravel cPanel ve VPS kurulum rehberi yazımızda bulabilirsiniz. Node.js ve Next.js uygulamaları ise ters vekil yapısı ister; onları aşağıda ayrıca ele alıyoruz.
SSL sertifikasını Certbot ile nasıl eklersiniz?
Let's Encrypt, ücretsiz ve otomatik yenilenen sertifikalar sunar; Certbot ise bu sertifikaları alan resmi istemcidir. Certbot'un Nginx talimatları snap paketiyle kurulumu öneriyor:
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
sudo certbot --nginx
Son komut server_name satırındaki alan adlarını okur, sertifikayı alır ve Nginx yapılandırmasına 443 bloğunu ekler. Yapılandırmanıza dokunmasını istemiyorsanız certbot certonly --nginx komutunu kullanırsınız. Ardından yenilemenin çalıştığını şu komutla deneyin:
sudo certbot renew --dry-run
Certbot belgelerine göre paket, sertifikaları süreleri dolmadan yenileyen bir cron işi ya da systemd zamanlayıcısı kurar. SSL'in neden gerekli olduğunu ve sertifika türlerini SSL sertifikası nedir yazımızda anlattık. Kurulumdan sonra sertifika zincirini SSL sorgulama aracı ile dışarıdan doğrulayabilirsiniz.
Yapılandırmayı nginx -t ile neden her seferinde test etmelisiniz?
Nginx'te tek bir eksik noktalı virgül, yeniden başlatmada tüm sitelerin kapanmasına yol açabilir. Bu yüzden her değişiklikten sonra önce sözdizimini test edin:
sudo nginx -t
sudo systemctl reload nginx
Test başarılıysa çıktıda "syntax is ok" ve "test is successful" ifadelerini görürsünüz. Hata varsa Nginx dosya adını ve satır numarasını gösterir; siz de doğrudan o satıra gidersiniz. Reload, test başarısız olsa bile çalışan eski yapılandırmayı korur. Ancak restart komutu hatalı ayarla servisi hiç başlatamayabilir.
Birden fazla include dosyası varsa sudo nginx -T komutu, Nginx'in gerçekte okuduğu birleşik yapılandırmayı ekrana döker. Böylece hangi dosyanın hangi ayarı ezdiğini tek bakışta görürsünüz. Ayrıca nginx -v ile sürümü, nginx -V ile derleme seçeneklerini ve modülleri öğrenebilirsiniz.
Değişiklik yapmadan önce mevcut dosyanın bir kopyasını almanızı da öneriyoruz. Örneğin sites-available altındaki dosyayı tarihli bir adla kopyalarsanız, hatalı bir ayardan sonra eski hâline saniyeler içinde dönersiniz. Git ile yapılandırma dosyalarını sürümlemek de iyi bir alışkanlıktır.
Ekibimizin önerdiği alışkanlık basittir: değiştir, test et, yeniden yükle, tarayıcıda kontrol et. Bu dört adımı bir kural haline getirirseniz canlı sitede sürpriz yaşama olasılığınız ciddi biçimde azalır.
Nginx log dosyaları nerede durur ve onları nasıl okursunuz?
Paket kurulumlarında varsayılan loglar /var/log/nginx/access.log ve /var/log/nginx/error.log dosyalarındadır. Server bloğunda ayrı log yolu tanımladıysanız o sitenin kayıtları kendi dosyasına düşer. Canlı izleme için şu komutları kullanırsınız:
sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log
sudo journalctl -u nginx --since "1 hour ago"
Access log her isteği, yanıt kodunu ve istemci bilgisini kaydeder. Error log ise izin hatalarını, eksik dosyaları ve arka uç bağlantı sorunlarını gösterir. Bir hata sayfası gördüğünüzde ilk bakacağınız yer her zaman error log olmalı; çünkü sorunun gerçek nedeni genellikle orada açıkça yazar.
Loglar zamanla büyür. Dağıtım paketleri genellikle logrotate ile döndürme ayarı getirir; yine de disk dolmasın diye boyutları ara sıra kontrol edin. Ayrıca loglarda IP adresi gibi kişisel veri tutulduğunu unutmayın; saklama sürenizi KVKK ve GDPR yükümlülüklerinize göre belirleyin.
403, 404 ve 502 hataları neden çıkar ve onları nasıl çözersiniz?
Bu üç hata, yeni bir Nginx kurulumunda en sık karşılaşacağınız durumlardır. Her biri farklı bir katmana işaret eder:
- 403 Forbidden: Nginx dosyayı okuyamıyordur. Dizin izinlerini, index dosyasının varlığını ve RHEL ailesinde SELinux bağlamını kontrol edin. Bir WAF devredeyse ModSecurity ve 403 hatası yazımız yol gösterir.
- 404 Not Found: root yolu yanlış, dosya yok ya da try_files kuralı isteği yanlış yere gönderiyordur. Error log, Nginx'in aradığı tam yolu gösterir.
- 502 Bad Gateway: Nginx arka uca ulaşamıyordur. PHP-FPM ya da uygulama servisi kapalı olabilir, soket yolu ya da port yanlış olabilir.
502 için ayrıntılı teşhis sırasını 502 Bad Gateway hatası yazımızda adım adım anlattık. Genel kural şudur: önce error log'u okuyun, sonra arka uç servisinin durumunu systemctl status ile kontrol edin, en son yapılandırmayı nginx -T ile gözden geçirin. Dizinlerde Nginx kullanıcısının geçiş izni olması gerektiğini de unutmayın; dosyalar için 644, dizinler için 755 yaygın bir başlangıçtır.
Güvenlik başlıklarını nasıl eklersiniz ve sürüm bilgisini nasıl gizlersiniz?
Varsayılan durumda Nginx, hata sayfalarında ve Server yanıt başlığında sürüm numarasını gösterir. Çekirdek modül belgesine göre server_tokens yönergesinin varsayılanı on değeridir. Bunu kapatmak için http bloğuna şu satırı eklersiniz:
server_tokens off;
Sürümü gizlemek tek başına güvenlik sağlamaz, ama otomatik tarayıcılara kolay bilgi vermemiş olursunuz. Ardından server bloğuna temel güvenlik başlıklarını ekleyebilirsiniz:
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;
# HTTPS kalıcı olarak çalıştıktan sonra, örnek değer:
# add_header Strict-Transport-Security "max-age=31536000" always;
Önemli bir ayrıntı var: add_header yönergeleri, bulunduğunuz seviyede hiç add_header yoksa üst seviyeden miras kalır. Yani bir location bloğuna tek bir add_header eklerseniz üstteki başlıklar o blokta kaybolur. Uygulama düzeyindeki riskler için OWASP Top 10 yazımıza da göz atın.
Güvenlik duvarında hangi portları açmalısınız?
Web sunucusu için yalnız 80 (HTTP) ve 443 (HTTPS) portlarını açmanız yeterlidir. Yönetim için SSH portunu da açık tutarsınız; ama diğer servisleri dışarıya kapatın. Ubuntu'da Nginx paketi UFW için hazır uygulama profilleri getirir:
sudo ufw app list
sudo ufw allow 'Nginx Full'
sudo ufw status
Nginx Full profili hem 80 hem de 443 portunu açar. RHEL ailesinde ise firewalld kullanırsınız:
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
Güvenlik duvarını etkinleştirmeden önce SSH iznini mutlaka tanımlayın; aksi halde sunucuya erişiminizi kaybedersiniz. SSH tarafını sağlamlaştırmak için Linux swap ve SSH güvenliği yazımızdaki adımlar işinize yarar. Ayrıca bazı VPS sağlayıcılarında panelde ayrı bir ağ güvenlik duvarı da yer alır; iki katmanı da kontrol edin.
Ters vekil ve yük dengeleme için sonraki adım nedir?
Nginx'i statik site ya da PHP için kurduktan sonra çoğu ekip bir sonraki adımda onu uygulamaların önüne koyar. Bu yapıya ters vekil denir: Nginx 80 ve 443 portlarını dinler, istekleri yerel bir porttaki uygulamaya proxy_pass ile iletir. Böylece SSL ve sıkıştırma gibi işleri tek noktadan yönetirsiniz.
Node.js için uçtan uca örneği Node.js kurulumu ve Nginx ile deploy yazımızda, Next.js için ise Next.js VPS deploy rehberinde anlattık. Ters vekil ayrıntılarını, Nginx Proxy Manager'ı ve birden fazla sunucuya yük dağıtmayı ise bu serinin sıradaki iki yazısında ele alıyoruz. Bu yazıda yalnız temel web sunucusu kurulumuna odaklandık.
Nginx kurulumunu ne zaman kendiniz yapmamalısınız?
Dürüst olmak gerekirse herkesin kendi web sunucusunu yönetmesi gerekmez. Komut satırına alışkın değilseniz ya da güncellemeleri düzenli takip edecek vaktiniz yoksa yönetilen hosting veya yönetilen VPS daha güvenli bir seçimdir. Çünkü yanlış ayarlı bir sunucu, yavaş bir siteden çok daha büyük risk taşır.
Şu durumlarda işi hosting sağlayıcınıza ya da deneyimli bir sistem yöneticisine bırakmanızı öneriyoruz:
- Sitede ödeme, üyelik ya da kişisel veri işleniyorsa ve güvenlik denetimi gerekiyorsa.
- Yüksek trafik, birden fazla sunucu ya da kesintisiz çalışma gereksinimi varsa.
- Sunucuya acil durumda müdahale edecek kimse yoksa.
Hosting seçimini henüz yapmadıysanız hosting seçim rehberimiz iyi bir başlangıçtır. Sitenin kendisi, hızı ve dönüşümü tarafında ise web tasarım hizmetimizle destek veriyoruz.
Nginx kurulumu sonrası kontrol listesi nedir?
Kurulumu bitirdiğinizi düşündüğünüzde aşağıdaki listeyi tek tek işaretleyin. Böylece sonradan fark edilen küçük eksiklerin canlı sitede soruna dönüşmesini önlersiniz.
- systemctl status nginx çıktısı active (running) gösteriyor ve servis açılışta etkin.
- nginx -t hatasız geçiyor; yapılandırma değişikliklerini reload ile uyguluyorsunuz.
- Alan adı doğru IP'yi gösteriyor; www ve www'suz adresler tek bir adrese gidiyor.
- HTTPS çalışıyor ve certbot renew --dry-run başarılı.
- server_tokens off ve temel güvenlik başlıkları etkin.
- Gizli dosyalara erişim kapalı, dizin listeleme kapalı.
- Güvenlik duvarında yalnız SSH, 80 ve 443 açık.
- Error log temiz; 403, 404 ya da 502 kayıtlarının nedenini biliyorsunuz.
- Düzenli yedek ve geri dönüş planı hazır.
Bu listenin tamamı yeşilse Nginx kurulumu tamam ve site canlı trafiğe hazır demektir. Sonrasında performans ölçümü, önbellek ayarı ve ters vekil gibi ileri konulara güvenle geçebilirsiniz. Ekibimiz olarak önerimiz, her değişikliği küçük adımlarla yapıp her adımdan sonra test etmenizdir.



