Bu rehber neyi çözer?
Nginx ve Apache olgun web sunucularıdır; seçim benchmark yerine uygulama mimarisi, ekip deneyimi, modül ve reverse proxy ihtiyacına göre yapılmalıdır.
Nginx
Web server, reverse proxy, cache, load balancer ve TCP/UDP proxy rollerinde kullanılabilir.
Event-driven mimarisi yüksek bağlantı sayısında verimli olabilir.
Apache
Zengin modül ekosistemi, .htaccess desteği ve geniş uygulama uyumluluğu güçlü yanlarıdır.
mod_rewrite, özel modüller veya dizin bazlı yapılandırma gerekliyse doğal tercih olabilir.
PHP ve reverse proxy
PHP-FPM ile iki platform da kullanılabilir; framework, URL rewrite ve cache davranışı test edilmelidir.
TLS termination ve reverse proxy ayrı katmanlara da ayrılabilir.
Güvenlik ve operasyon
Minimum modül, patch, güçlü TLS, log merkezi, WAF ve least privilege temel kontrollerdir.
Yapılandırma değişikliklerinde syntax test ve rollback süreci bulunmalıdır.
Sık Sorulan Sorular
Nginx her zaman Apache’den hızlı mı?
Hayır. Sonuç workload, yapılandırma, cache, uygulama ve donanıma bağlıdır.
.htaccess şart mı?
Hayır. Merkezi virtual host yapılandırmau çoğu kurumsal ortamda daha kontrollüdür.
Nginx ve Apache birlikte kullanılabilir mi?
Evet; ancak ek katman operasyonel karmaşıklık getirdiği için net bir gerekçesi olmalıdır.
Kaynaklar ve teknik referanslar
Linux Sunucu Projenizi Değerlendirelim
Mevcut Windows/Linux rollerinizi, uygulama bağımlılıklarını ve geçiş hedeflerinizi birlikte değerlendirebiliriz.
Mimari ve çalışma modeli
Nginx ve Apache seçimi reverse proxy, uygulama entegrasyonu ve işletim alışkanlığıyla birlikte yapılır. HTTP dinleme noktası, TLS sonlandırma, upstream, timeout ve yükleme sınırları ayrı tasarlanmalıdır. Statik dosya benchmarkı dinamik uygulama performansını temsil etmez. Proxy başlıklarına güven sınırı konmadan gerçek istemci kimliği doğrulanamaz.
- 1İstemci ve TLS
- 2Web/proxy katmanı
- 3Upstream uygulama
- 4Log ve yanıt
Tasarım parametreleri
- Proxy ve backend
- TLS sonlandırma, forwarding headerları ve backend timeoutlarını eşleştirin; güvenilir proxy sınırını yazın.
- Statik ve dinamik yük
- Web server workerı ile uygulama workerını ayrı ölçün; yavaş backendi yalnız web ayarıyla çözmeyin.
- Servis ve kullanıcı
- Gerçek servis kullanıcısını, grup üyeliğini, çalışma dizinini ve gerekli yetkileri listeleyin. Root ile başarılı test sınırlı hesapla çalışmayı kanıtlamaz.
- Depolama ve kalıcılık
- Mount, dosya sistemi, inode ve kalıcı veriyi birlikte kontrol edin. Yeniden başlatma ve yeniden oluşturma aynı test değildir.
- Ağ ve güvenlik katmanı
- Dinlenen arayüz, firewall, TLS ve SELinux/AppArmor politikalarını ayırın. Bir katmandaki engel başka katmanın ayarıyla çözülmez.
- Paket ve işletim yöntemi
- Sürüm, depo, güncelleme yöntemi ve servis bağımlılıklarını belgeleyin. Bakım sonrası reboot ve uygulama doğrulamasını planlayın.
Hesap ve uygulama örneği
Örnek pilotta normal istek, büyük upload ve yavaş upstream ayrı test edilir. Yapılandırma doğrulaması başarılıysa desteklenen reload uygulanır; eski oturum davranışı ölçülür. 502/504 hatasını doğrudan web sunucusunun kapasitesine bağlamadan upstream sağlık ve timeoutlarını kontrol edin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
nginx -t
# Apache kurulumunda / on Apache:
apachectl configtestHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| 502/504 hataları artıyor | Backend bağlantısı, worker doluluğu veya timeout olabilir. | Request ID ile proxy ve uygulama loglarını eşleştirin. |
| Servis aktif ama yanıt vermiyor | Process sağlığı, port dinleme ve uygulama sağlığı farklı kontrollerdir. | Yerel sağlık kontrolünü uzak istemci isteğiyle karşılaştırın; log ve bağımlılık durumunu inceleyin. |
| Dosya yazılamıyor | İzin, ACL, read-only mount, inode veya disk doluluğu etkili olabilir. | Servis kimliğiyle dizin zincirini ve mount durumunu doğrulayın; izinleri topluca açmayın. |
| Reboot sonrası yapılandırma kayboldu | Geçici mount, runtime ayarı veya yanlış yapılandırma kaynağı kullanılmış olabilir. | Kalıcı ayarı ve açılış sırasını kontrol edin; temiz reboot testini tekrarlayın. |
Kabul ve doğrulama kontrolleri
- TLS, proxy başlıkları ve upstream hata davranışını aynı istek kimliğiyle izleyin.
- Servisi tanımlanan sınırlı kimlikle çalıştırıp temel iş akışını test edin.
- Reboot sonrasında mount, ağ, zaman ve uygulama durumunu doğrulayın.
- Yapılandırma, veri ve anahtarları ayrı kurtarma kalemleri olarak kaydedin.
- Güncellemeden önce ve sonra aynı sağlık testini çalıştırın.
- Ayrı hedefe geri yükleyerek platform bağımlılıklarını doğrulayın.
İlgili kavramlar
TLS ve sertifika doğrulaması
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.