Bağlantı Reddedildi ve Diğer Nginx Hataları: Deploynix Hata Ayıklama Kılavuzu

Laravel uygulamanız Nginx arkasında çalışırken, Nginx, PHP-FPM ve uygulama kodu arasında bir iletişim sorunu olduğunda, hatalar genellikle karmaşık bir hale gelir. Örneğin, “502 Bad Gateway” hatası gerçekteki problemi hemen göstermez. “Connection Refused” hatası ise on farklı sebebe işaret edebilir.

Bu rehber, Deploynix ile yönetilen bir Laravel uygulamasıyla karşılaşabileceğiniz en yaygın Nginx hatalarını ele alacak, sistem düzeyinde neler olduğunu açıklayacak ve her birini teşhis etme ve düzeltme adımlarını gösterecektir.

İstek Akışının Nasıl Çalıştığı

Hata ayıklamadan önce, istek akışını anlamanız önemlidir:

1. Kullanıcının tarayıcısı bir HTTPS isteği gönderir.
2. Nginx isteği 443 (veya 80 üzerinde, 443’e yönlendirme ile) alır.
3. Statik dosyalar (CSS, JS, resimler) için Nginx bunları doğrudan sunar.
4. PHP istekleri için Nginx isteği bir Unix soketi aracılığıyla PHP-FPM’ye iletir.
5. PHP-FPM, Laravel uygulamanızı çalıştırmak için bir işçi süreci başlatır veya yeniden kullanır.
6. Cevap geri döner: PHP-FPM’den Nginx’e, oradan da kullanıcının tarayıcısına.

Bu zincirdeki her geçişte hatalar meydana gelebilir. Tarayıcıda gördüğünüz hata, zincirin nerede kırıldığını ipucu verir.

502 Bad Gateway

Kullanıcının gördüğü:

Beyaz bir sayfa “502 Bad Gateway” ve Nginx sürümü ile birlikte.

Bu ne anlama geliyor:

Nginx isteği başarıyla aldı, ancak PHP-FPM’den geçerli bir yanıt alamadı. Nginx çalışıyor; PHP-FPM çalışmıyor.

Yaygın nedenler ve çözümler:

PHP-FPM Çalışmıyor

En basit sebep. PHP-FPM çökmüş veya durdurulmuş olabilir.

Teşhis:

systemctl status php8.4-fpm

Eğer durum “inactive” veya “failed” olarak görünüyorsa, PHP-FPM kapalıdır.

Çözüm:

systemctl restart php8.4-fpm

PHP-FPM nedeninin durduğuna dair günlükleri kontrol edin:

tail -50 /var/log/php8.4-fpm.log

Yaygın nedenler: bir PHP uzantısında segfault, OOM killer’in master sürecini sonlandırması veya bir PHP güncellemesinden sonra yapılandırma hatası olabilir.

Deploynix’ de PHP-FPM’yi SSH erişimi olmadan sunucu paneli üzerinden yeniden başlatabilirsiniz. Eğer PHP-FPM sürekli çöküyorsa, Deploynix’in bellek baskısını kontrol edin — OOM killer sıklıkla sunucu RAM’inden tükenirken PHP-FPM’i hedef alır.

Soket Uyuşmazlığı

Nginx, istekleri PHP-FPM’nin dinlediği soket yoluna iletmek üzere yapılandırılmıştır, ancak bu yol PHP-FPM’nin dinlediği yerle uyuşmamaktadır.

Teşhis:

Nginx site yapılandırmasında soket yolunu kontrol edin:

grep fastcgi_pass /etc/nginx/sites-enabled/*

Ardından, PHP-FPM’nin gerçekten dinlediği yeri kontrol edin:

grep listen /etc/php/8.4/fpm/pool.d/www.conf

Eğer bu yollar uyuşmuyorsa, Nginx PHP-FPM’e ulaşamaz.

Çözüm:

Soket yollarını eşleştirin. Deploynix tarafından yönetilen sunucularda soket yolu, kurulum sırasında tutarlı bir şekilde yapılandırılır. Bu uyuşmazlık genellikle sunucu yapılandırması manuel olarak değiştirildiğinde oluşur. Eğer PHP-FPM veya Nginx yapılandırma dosyalarını manuel olarak değiştirdiyseniz, Deploynix varsayılanlarını geri yükleyin veya soket yollarının eşleştiğinden emin olun.

PHP-FPM Çalışanlarının Hepsi Meşguldür

Her PHP-FPM işçisi bir isteği işliyor ve yeni istekler Nginx’in zaman aşımına ulaşana kadar bekliyor.

Teşhis:

grep "server reached pm.max_children" /var/log/php8.4-fpm.log

Eğer bu mesajı görüyorsanız, tüm işçiler tükendi demektir.

Çözüm:

PHP-FPM havuz yapılandırmasında pm.max_children‘ı artırın, ancak yalnızca sunucunun daha fazla işçiyi destekleyecek RAM’i varsa. Her işçi, uygulamanıza bağlı olarak 30-80 MB tüketir. 2 GB’lık bir sunucuda MySQL ve Valkey de çalışırken genellikle maksimum 5-8 işçi olmalıdır.

Eğer daha fazla işçi ekleyemiyorsanız, işçileri meşgul eden nedenleri tespit edin. Uzun süreli istekler (yavaş veritabanı sorguları, harici API çağrıları) işçileri meşgul eder. Yavaş işlemleri kuyruk işlerine taşınarak web isteklerinin hızlıca tamamlanmasını sağlayın.

504 Gateway Timeout

Kullanıcının gördüğü:

“504 Gateway Timeout” uzun bir bekleyişten sonra (genellikle 30-60 saniye).

Bu ne anlama geliyor:

Nginx, PHP-FPM’den yanıt bekledi, ancak yanıt belirtilen zaman aşımı süresi içinde gelmedi. İstek hala PHP-FPM’de işleniyor olabilir, ancak Nginx beklemeyi bırakmıştır.

Yaygın nedenler ve çözümler:

Yavaş Veritabanı Sorguları

En sık karşılaşılan sebep. 45 saniye süren bir sorgu, bir PHP-FPM işçisini meşgul eder ve sonucunda Nginx’in zaman aşımına neden olur.

Teşhis:

MySQL yavaş sorgu günlüğünü etkinleştirin:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;

Yavaş sorguları kontrol edin:

tail -100 /var/log/mysql/mysql-slow.log

Çözüm:

Sorguyu optimize edin. Laravel uygulamalarındaki yaygın sorunlar:

• where(), orderBy(), ve join() ifadelerinde kullanılan sütunlarda eksik veritabanı indeksleri.
• N+1 sorgu problemleri: eager loading için with() kullanın.
• Büyük veri kümesi yüklemeleri için bellek yüklemek: büyük veri setleri için chunk() veya cursor() kullanın.
• Gereksiz alan yüklemeleri: yalnızca gerekli olan birkaç sütunu yüklemek için select() kullanın.

Web İsteklerinde Harici API Çağrıları

Kontrolcünüz, bir üçüncü taraf API’ye senkron bir HTTP çağrısı yaparsa ve o API yavaş veya yanıt vermiyorsa, istek zaman aşımına uğrar.

Çözüm:

Harici API çağrılarını kuyruk işlerine taşıyın. Web isteği, işi gönderip hemen geri dönmeli (veya kullanıcıya “işlemde” durumu göstermelidir). Kuyruk işçisi, yavaş API çağrısını arka planda işleme alır.

API çağrısının senkron bir şekilde yapılması gerekiyorsa (örneğin, ödeme işlemleri sırasında), HTTP istemcisinde uygun zaman aşım sürelerini ayarlayın:

Http::timeout(10)->post('https://api.example.com/charge', $data);

Nginx Zaman Aşımı Yapılandırması

Eğer geçerli işlemlerin varsayılan zaman aşımından (60 saniye) daha fazlasına ihtiyacı varsa, Nginx’in proxy zaman aşımını artırabilirsiniz. Ancak bu genellikle yanlış bir çözüm — doğru çözüm, işlemi hızlı hale getirmek veya bunu bir arka plan işi yapmak olmalıdır.

Eğer zaman aşımını artırmak zorundaysanız:

fastcgi_read_timeout 120;

Deploynix’te, Nginx yapılandırması sunucu paneli aracılığıyla yönetilmektedir. Zaman aşımı değerlerini değiştirmek mümkündür, ancak bu son çare olarak düşünülmelidir.

Bağlantı Reddi

Kullanıcının gördüğü:

Tarayıcı “Bu site ulaşılamıyor” veya “Bağlantı reddedildi” mesajını gösteriyor — hiçbir Nginx hata sayfası yok.

Bu ne anlama geliyor:

Port 80 veya 443 üzerinde hiçbir şey dinlemiyor. Bu, Nginx’in çalıştığı 502’den farklıdır (sadece PHP-FPM kapalıdır). Burada Nginx kendisi yanıt vermiyor.

Yaygın nedenler ve çözümler:

Nginx Çalışmıyor

Teşhis:

systemctl status nginx

Çözüm:

systemctl restart nginx

Eğer Nginx başlamazsa, hata günlüğünü kontrol edin:

nginx -t

Bu, yapılandırmayı test eder ve herhangi bir sözdizim hatasını raporlar. Eksik bir noktalı virgül veya dahil edilmiş yapılandırma dosyasında geçersiz bir direktif, Nginx’in başlamasına engel olur.

Güvenlik Duvarı Portu Engelliyor

Deploynix, sunucu kurulumları sırasında güvenlik duvarı kurallarını yapılandırarak 80 ve 443 portlarını web trafiği için açar. Eğer güvenlik duvarı manuel olarak değiştirilirse ya da başka bir araç tarafından etkilenirse, bu portlar engellenebilir.

Teşhis:

ufw status

Portların 80 ve 443’ün “ALLOW” olarak gösterildiğinden emin olun.

Çözüm:

ufw allow 80
ufw allow 443

Deploynix’de güvenlik duvarı kuralları kontrol paneli aracılığıyla yönetilmektedir. HTTP ve HTTPS trafiğinin izin verildiğinden emin olun.

DNS Sunucuya İşaret Etmiyor

Yenidoğan bir site oluşturduysanız veya DNS kayıtlarını değiştirdiyseniz, alan adı henüz sunucunuzun IP’sine çözülmüyor olabilir.

Teşhis:

dig +short yourdomain.com

Dönen IP’yi, Deploynix panelindeki sunucunuzun IP’si ile karşılaştırın.

Çözüm:

DNS kayıtlarınızı doğru IP’ye işaret edecek şekilde güncelleyin. DNS yayılması birkaç dakikadan 48 saate kadar sürebilir, ancak çoğu değişiklik bir saat içinde yayılır.

Deploynix’in vanity alan adları (*.deploynix.cloud) otomatik olarak yapılandırılmıştır ve manuel DNS ayarı gerektirmez, bu nedenle DNS sorunu şüphesi olduğunda hızlı testler için faydalıdır.

403 Yasaklı

Kullanıcının gördüğü:

“403 Forbidden” — Nginx çalışıyor ve isteği aldı, ancak sunmaktan kaçınıyor.

Bu ne anlama geliyor:

Nginx, istenen dosyaya erişim iznine sahip değildir veya dizin indeksi yasaklanmıştır.

Yaygın nedenler:

Yanlış Dosya İzinleri

Nginx www-data kullanıcısı olarak çalışır. Uygulama dosyalarınız bu kullanıcı tarafından okunamazsa, Nginx 403 döner.

Teşhis:

ls -la /home/deploynix/your-site/current/public/

public dizini ve içeriği www-data tarafından okunabilir olmalıdır (genellikle grup izinleri aracılığıyla).

Çözüm:

chown -R deploynix:www-data /home/deploynix/your-site/current/public
chmod -R 755 /home/deploynix/your-site/current/public

Eksik İndeks Dosyası

Eğer public/index.php dosyası eksikse (başarısız dağıtım, yanlış web kökü yapılandırması), Nginx dizini listelemeye çalışır ve autoindex off (varsayılan) olduğunda 403 döner.

Teşhis:

ls -la /home/deploynix/your-site/current/public/index.php

Eğer dosya yoksa, dağıtım düzgün tamamlanmamıştır.

Çözüm:

Deploynix üzerinden yeniden dağıtım yapın veya sitesinin web dizininin yapılandırmada /public olarak ayarlandığından emin olun.

413 İstek Varlığı Çok Büyük

Kullanıcının gördüğü:

“413 Request Entity Too Large” dosya yüklemeleri sırasında.

Bu ne anlama geliyor:

Yüklenen dosya Nginx’in client_max_body_size limitini aşmıştır.

Çözüm:

Limitinizi Nginx site yapılandırmasında artırın:

client_max_body_size 100M;

Ayrıca PHP ayarlarını kontrol edin:

upload_max_filesize = 100M
post_max_size = 100M

Hem Nginx hem de PHP limitleri maksimum yükleme boyutunuza uygun olmalıdır. Deploynix’te, PHP ayarları sunucunun PHP yapılandırma panelinden ayarlanabilir.

SSL/TLS Hataları

ERR_SSL_PROTOCOL_ERROR

Tarayıcı SSL bağlantısını kuramıyor. Yaygın nedenler:

• SSL sertifikası yüklenmemiş veya süresi dolmuş.
• Nginx, 443 portunda dinlemek için yapılandırılmamış.
• Karmaşık HTTP/HTTPS yapılandırması.

Teşhis:

Sertifika dosyalarının mevcut olup olmadığını kontrol edin:

ls -la /etc/nginx/ssl/

SSL yapılandırmasını test edin:

nginx -t

Deploynix’te, SSL sertifikaları Let’s Encrypt veya vanity alan adları sertifikaları aracılığıyla otomatik olarak sağlanır. Eğer bir sertifika süresi dolarsa, Deploynix bunu otomatik olarak yeniler. SSL durumunu sitenizin ayarlarında kontrol edin.

ERR_CERT_AUTHORITY_INVALID

Sertifika kendi kendine imzalanmış veya sertifika zinciri eksik. Deploynix’in Let’s Encrypt entegrasyonuyla, düzgün bir zincir sağlaması beklenir. Bu hatayı görüyorsanız, sertifika muhtemelen eksik bir zincir ile manuel olarak değiştirilmiştir.

Sistematik Hata Ayıklama Yaklaşımı

Bir Nginx hatasıyla karşılaştığınızda, bu sırayı takip edin:

1. Hata kodunu belirleyin — 502, 504, 403 ve “Bağlantı Reddedildi” her biri yığınlar için farklı alanlara işaret eder.
2. Nginx durumunu kontrol edin — systemctl status nginx — çalışıyor mu?
3. PHP-FPM durumunu kontrol edin — systemctl status php8.4-fpm — çalışıyor mu?
4. Nginx yapılandırmasını test edin — nginx -t — yapılandırma geçerli mi?
5. Hata günlüklerini kontrol edin — /var/log/nginx/error.log ve /var/log/php8.4-fpm.log
6. Deploynix izleme sistemini kontrol edin — Hata zamanlamalarıyla örtüşen CPU, bellek veya disk uyarılarına bakın.
7. Son dağıtımları kontrol edin — Yakın zamanda bir dağıtım Nginx veya PHP yapılandırmasını değiştirdi mi?

Çoğu sorun, adım 2 veya 3’te çözülür (bir hizmetin yeniden başlatılması gerekir) veya adım 5’te (günlükler, belirli bir sebebi ortaya çıkarır). Deploynix’in web terminali, bu teşhis komutlarını doğrudan tarayıcınızdan çalıştırmanıza olanak tanır, böylece SSH kurmanıza gerek kalmaz.

Sonuç

Nginx hataları, daha derin sorunların görünür belirtileridir — PHP-FPM kaynak tükenmesi, yavaş uygulama kodu, yanlış yapılandırılmış izinler veya ağ problemleri. Hata kodu, başarısızlığın istek zincirinin nerede gerçekleştiğini daraltırken, sunucu günlükleri neyin yanlış gittiğini tam olarak gösterir.

Deploynix, dağıtım sırasında en yaygın yapılandırma sorunlarını otomatik olarak halleder ve kaynak sorunlarını kullanıcı kaynaklı hatalar oluşmadan önce yakalamak için izleme sağlar. Ancak hatalar meydana geldiğinde, Nginx’ten PHP-FPM’e ve ardından Laravel’e giden zinciri anlamak, sorunları dakikalar içinde çözmenizi sağlar.

Bu kılavuzu elinizin altında bulundurmanızı öneririz. İçerisindeki hatalar, bir Laravel uygulaması ile karşılaşacağınız Nginx ile ilgili sorunların büyük çoğunluğunu kapsamaktadır.