Siteleri Hızlı Tutan Nginx Yapılandırması

19 Eylül 2026 tarihinde yayımlandı

Bir site kusursuz şekilde sağlıklı görünebilir; ta ki küçük bir Nginx yapılandırma hatası rutin bir dağıtımı 502 hatasına, bir SSL uyarısına veya ziyaretçileri yararlı hiçbir yere götürmeyen bir yönlendirme döngüsüne dönüştürene kadar. Nginx hızlı ve güvenilirdir, ancak aynı zamanda çok titizdir: yanlış yerde bulunan tek bir yönerge, tüm bir sitenin nasıl davrandığını değiştirebilir. İyi haber şu ki, temiz bir yaklaşım Nginx yapılandırmasını çok daha az gizemli hale getirir.

Bu rehber, web siteleri barındırırken en önemli olan ayarlara odaklanır: server block'lar, PHP işleme, HTTPS, yönlendirmeler, statik dosyalar, önbellekleme ve güvenli test. Her Nginx yönergesini ezberlemeniz gerekmez. Sitenizi hangi kararların etkilediğini ve ziyaretçilerinizi etkilemeden önce bunları nasıl doğrulayacağınızı anlamanız gerekir.

Net Bir Nginx Yapılandırma Düzeniyle Başlayın

Çoğu Linux kurulumu, genel ayarları tekil web sitesi ayarlarından ayırır. Genellikle /etc/nginx/nginx.conf konumunda bulunan ana yapılandırma dosyası, worker process'leri, günlük kaydını, sıkıştırmayı ve dahil edilen yapılandırma dizinlerini kontrol eder. Tekil siteler genellikle sites-available, sites-enabled veya conf.d gibi bir dizinde bulunur.

Bu ayrım pratik bir nedenle faydalıdır: genel ayarlar dikkatle ve nadiren değiştirilmelidir, buna karşılık web sitesi düzeyindeki ayarlar düzenli ilgi gerektirir. Yeni bir alan adı, bir hazırlık sitesi veya bir yönlendirme kuralı ana dosyada değil, o sitenin server block'unda yer almalıdır.

Herhangi bir şeyi değiştirmeden önce etkin yapılandırmayı belirleyin ve test edin:

bash nginx -t

Test başarılı olursa, etkin bağlantıları düşürmeden Nginx'i yeniden yükleyin:

bash systemctl reload nginx

Normal yapılandırma değişiklikleri için reload kullanın. Bazen tam yeniden başlatma gerekir, ancak bir sanal ana bilgisayarı güncellerken ilk adım bu değildir. Bunun gibi küçük alışkanlıklar, beş dakikalık bir görevin gece geç saatlerde yapılan bir kurtarma işine dönüşmesini önler.

Her Web Sitesi İçin Bir Server Block Oluşturun

Bir server block, Nginx'e hangi alan adını sunduğunu, web sitesi dosyalarının nerede depolandığını ve isteklerin nasıl işlenmesi gerektiğini söyler. Bunu tek bir web sitesi için ön büro gibi düşünün. Birkaç alan adı tek bir sunucuyu paylaştığında, trafiğin doğru yere gitmesini sağlayan şey düzenli bir server block'tur.

Temel bir HTTP sitesi şöyle görünebilir:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

server_name, sunmayı amaçladığınız her ana makine adını listelemelidir. Ziyaretçiler hem kök alan adına hem de www adresine ulaşabiliyorsa, ikisini de ekleyin; ardından hangisinin yönlendirme yoluyla kanonik hale geleceğine karar verin.

root yolu, projenin en üst düzey klasörüne değil, herkese açık web dosyalarını içeren dizine işaret etmelidir. WordPress için bu genellikle wp-admin, wp-content ve wp-includes dosyalarının bulunduğu klasördür. Laravel ve benzer framework'ler için bu genellikle public dizinidir. Nginx'i yanlış klasöre yönlendirmek, asla herkese açık olmaması gereken dosyaları açığa çıkarabilir.

try_files kuralı dikkat gerektirir. Bu, eşleşmeyen istekleri uygulamaya iletmeden önce istenen bir dosya veya dizinin var olup olmadığını kontrol eder. Bu, WordPress kalıcı bağlantıları ve birçok modern PHP uygulaması için çok önemlidir. Bu olmadan sayfalar yalnızca ziyaretçiler index.php eklenmiş tam URL'yi kullandığında çalışabilir. İdeal değil ve müşterilerin ilk olarak bildirmesini isteyeceğiniz bir sorun da değil.

Varsayılan Sunucu Tuzağından Kaçının

Nginx, yapılandırılmış bir ana makine adıyla eşleşmeyen istekler için bir varsayılan sunucuya ihtiyaç duyar. Yanlış site varsayılan olarak ayarlanırsa, bilinmeyen bir alan adı veya doğrudan IP isteği başka birinin web sitesini görüntüleyebilir. Bu en iyi ihtimalle kafa karıştırıcı, en kötü ihtimalle ise risklidir.

Çok siteli sunucular için, 404 yanıtı gibi yararlı bir içerik döndürmeyen basit bir varsayılan sunucu kullanın. Gerçek web sitelerini, kendi server\_name değerlerine sahip açık server block'larda tutun. Bu, paylaşımlı bir sunucunun yönetimini kolaylaştıran küçük bir sınırdır.

PHP'yi Tahmine Dayanmadan Yapılandırın

Nginx, PHP'yi kendi başına işlemez. PHP isteklerini, kodu çalıştıran PHP-FPM'ye iletir. Bağlantı normalde bir Unix soketi veya yerel bir TCP portudur.

Yaygın bir PHP location bloğu şöyle görünür:

location ~ \.php$ {
    try_files $uri =404;

    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

PHP sürümü ve soket yolu sunucuya göre değişir. Bir PHP güncellemesinden sonra Nginx 502 Bad Gateway hatası döndürüyorsa, kontrol edilmesi gereken ilk yerlerden biri soket yoludur. PHP-FPM durmuş olabilir, farklı bir sürüm çalıştırıyor olabilir veya Nginx'te tanımlanan yoldan başka bir yerde dinliyor olabilir.

try_files $uri =404; satırını korumak da faydalıdır. Bu, Nginx'in var olmayan PHP dosyaları için gelen istekleri PHP işlemcisine göndermesini engeller. Bu, hem güvenliği hem de hata işlemeyi iyileştirir.

WordPress için, neden gerektiğini bilmiyorsanız rastgele forum gönderilerinden kopyalanmış geniş kurallar eklemekten kaçının. WordPress; temiz bir try_files kurulumu, doğru PHP işleme ve yalnızca WordPress'in ihtiyaç duyduğu yerlerde yazılabilir izinlerle zaten iyi çalışır. Daha fazla kural otomatik olarak daha iyi bir yapılandırma anlamına gelmez.

HTTPS'yi Varsayılan Yol Haline Getirin

Her herkese açık web sitesi HTTPS sunmalı ve HTTP trafiğini güvenli sürüme yönlendirmelidir. Yaygın kalıp, yalnızca yönlendirme yapan bir HTTP server block'u ve siteyi sunan ayrı bir HTTPS bloğudur.

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://example.com$request_uri;
}

HTTPS server block'u daha sonra 443 portunda dinler ve sertifika ile özel anahtar yollarını içerir. Sertifika dosyaları SSL'nin nasıl sağlandığına bağlıdır, ancak ilke aynı kalır: sertifika yapılandırmasını onu kullanan sitenin içinde tutun.

Hedeften emin olduktan sonra kalıcı bir 301 yönlendirmesi uygundur. Etkin bir taşıma veya kısa süreli bir test sırasında 302 yönlendirmesi daha güvenli olabilir, çünkü tarayıcılar bunu o kadar agresif şekilde önbelleğe almaz. Bu, teknik olarak en güçlü görünen seçeneğin her zaman doğru operasyonel tercih olmadığı durumlardan biridir.

Ayrıca tercih edilen tek bir ana makine adı seçin. Ya www adresini kök alan adına ya da kök alan adını www adresine yönlendirin. Tutarlı bir yönlendirme olmadan her ikisini de sunmak analitiği bölebilir, arama motorları için yinelenen sayfalar oluşturabilir ve çerez davranışını teşhis etmeyi zorlaştırabilir.

Statik Dosyaları Verimli ve Güvenli Şekilde Sunun

Nginx bunları doğrudan sunabiliyorken resimler, CSS, JavaScript, yazı tipleri ve indirilebilir dosyalar PHP kaynaklarını tüketmemelidir. Nadiren değişen dosyalar için makul tarayıcı önbelleklemesi ayarlayın:

location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|ico|woff2)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Otuz gün mantıklı bir başlangıç noktasıdır, yasa değildir. Dosya adlarınız sürüm numaraları veya hash'lenmiş dosya adları içeriyorsa, daha uzun önbellekleme çok iyi sonuç verebilir. Aynı dosya adı sık sık değiştirilirse, uzun bir önbellek ziyaretçilerin daha eski bir tasarım veya betik görmesine neden olabilir. Önbellekleme her zaman hız ile değişikliklerin ne kadar hızlı görünmesi gerektiği arasında bir uzlaşmadır.

Gizli dosyaları yanlışlıkla açığa çıkarmayın. Basit bir kural, sertifika doğrulaması tarafından kullanılan .well-known dizinine izin verirken dotfile isteklerini engelleyebilir:

location ~ /\.(?!well-known(?:/|$)) {
    deny all;
}

Sertifika kurulumunuza bağlı olarak .well-known için özel bir istisnaya ihtiyaç duyabilirsiniz. Erişim kurallarını daha sıkı hale getirdikten sonra yenileme davranışını test edin. Güvenlik kuralları maruziyeti azaltmalı, güvendiğiniz hizmetleri sessizce bozmamalıdır.

Güvenlik Başlıklarını Bağlam İçinde Kullanın

Yanıt başlıkları tarayıcı tarafı korumayı iyileştirebilir, ancak test edilmeleri gerekir. Yaygın örnekler arasında X-Content-Type-Options nosniff, Referrer-Policy ve Content-Security-Policy bulunur. Sonuncusu güçlüdür ve yanlış yapılandırılması kolaydır. Katı bir ilke, sitenin bağımlılıkları anlaşılmadan eklenirse betikleri, yazı tiplerini, ödeme bileşenlerini, analitiği veya gömülü içeriği engelleyebilir.

Amacı net ve riski düşük başlıklarla başlayın; ardından uygulamanız destekliyorsa yalnızca rapor modunda bir content security policy ekleyin. Amaç etkileyici bir yönerge yığını toplamak değildir. Amaç, insanların kullanması gereken sayfaları bozmadan gerçek riski azaltmaktır.

Hız sınırlama, özellikle WordPress oturum açma uç noktaları için kötüye kullanılan trafik ve oturum açma saldırılarında da yardımcı olabilir. Ancak agresif sınırlar, paylaşımlı ofis ağlarının veya mobil operatörlerin arkasındaki meşru kullanıcıları engelleyebilir. Yalnızca katı gelen sayılar seçmek yerine günlükleri inceleyin ve gerçek trafik örüntülerine göre ayarlama yapın.

Değişiklikleri Önemliymiş Gibi Test Edin

Her Nginx değişikliği aynı kısa rutini izlemelidir: geçerli dosyayı yedekleyin veya kopyalayın, tek bir odaklı değişiklik yapın, nginx -t çalıştırın, Nginx'i yeniden yükleyin ve web sitesini bir tarayıcıdan ve komut satırından test edin. Hedeflenen alan adını, kanonik olmayan alan adını, HTTP'yi, HTTPS'yi ve PHP tarafından işlenen bir sayfayı kontrol edin.

Bir şey başarısız olduğunda, yapılandırmayı yeniden yazmadan önce hata günlüklerini okuyun. Nginx erişim ve hata günlükleri, sorunun eksik bir dosya, yanlış izin, başarısız upstream bağlantısı veya kötü bir yönlendirme olup olmadığını çoğu zaman ortaya çıkarır. Tahminde bulunmak, hiçbirini çözmeden üç yeni sorun yaratabilir.

Bir kontrol paneli; web sitesi düzeyindeki ayarları, sertifikaları, PHP sürümlerini ve günlükleri tek bir yerde oluşturarak ve düzenleyerek bu manuel işin büyük kısmını ortadan kaldırabilir. FASTPANEL, bu pratik orta yol için tasarlanmıştır: her alan adı değişikliğini bir yapılandırma arkeolojisi projesine dönüştürmeden barındırma ortamınızın kontrolünü elinizde tutarsınız.

İyi Nginx yapılandırması, en uzun dosyayı oluşturmak veya kullanılabilir her yönergeyi kullanmakla ilgili değildir. Bu, her siteyi öngörülebilir hale getirmekle ilgilidir: doğru alan adı doğru dosyalara ulaşır, PHP'nin sağlıklı bir upstream'i vardır, HTTPS zorunlu kılınır, statik içerik verimlidir ve değişiklikler ziyaretçiler bunlarla karşılaşmadan önce test edilir. Bu temel oluşturulduğunda, büyüyen bir sunucuyu yönetmek çok daha az dramatik hale gelir - tam da olması gerektiği gibi.