Nginx’i Birden Fazla Portu Dinleyecek Şekilde Nasıl Yapılandırılır

Nginx, yapılandırması içindeki bir veya daha fazla `listen` bloğuna birden fazla `server` yönergesi ekleyerek aynı anda birden fazla portu dinleyebilir. Her `listen` yönergesi, Nginx’i belirli bir IP/port kombinasyonuna bağlar ve tek bir sunucu örneğinin ayrı işlemler çalıştırmadan farklı portlarda HTTP, HTTPS ve özel uygulama trafiğini işlemesine olanak tanır.

Bu özellik, çok kiracılı ortamlar, hazırlık/üretim port ayrımı, ters proxy mimarileri ve mikro hizmet yönlendirmesi için — hepsi tek bir VPS Hosting örneğinden — gereklidir.

Ön Koşullar

Devam etmeden önce aşağıdakileri doğrulayın:

• Nginx kurulu ve servis aktif (`systemctl status nginx`)
• Sunucuda `root` veya `sudo` ayrıcalıklarına sahipsiniz
• `/etc/nginx/nginx.conf` (genel yapılandırma) ile `/etc/nginx/sites-available/` (site başına yapılandırma blokları) arasındaki farkı anlıyorsunuz
• Güvenlik duvarı kuralları (`ufw`, `iptables` veya bir bulut güvenlik grubu) açmayı planladığınız portlarda trafiğe izin veriyor
• HTTPS portlarını yapılandırıyorsanız geçerli SSL sertifikaları mevcut (kendinden imzalı veya CA tarafından verilmiş)

Nginx Yapılandırma Mimarisi: Önce Bilmeniz Gerekenler

Nginx hiyerarşik bir yapılandırma modeli kullanır: `http` bağlamı, her biri bir veya daha fazla `listen` yönergesi içerebilen bir veya daha fazla `server` bloğu içerir. Bu hiyerarşiyi anlamak, en yaygın yanlış yapılandırma hatalarını önler.

İlgili temel yönergeler:

• `listen [address:]port [ssl] [http2] [default_server]` — sunucu bloğunu belirli bir porta ve isteğe bağlı IP’ye bağlar
• `server_name` — istekleri doğru bloğa yönlendirmek için `Host` başlığıyla eşleşir
• `default_server` — başka hiçbir `server_name` ile eşleşmeyen istekleri hangi sunucu bloğunun işleyeceğini belirler

Dağıtıma göre yapılandırma dosyası konumları:

Debian tabanlı sistemlerde, `sites-available/` içindeki dosyaların geçerli olabilmesi için `sites-enabled/` dizinine sembolik bağlantı oluşturulması gerekir:

“`bash

sudo ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/

“`

Adım 1: Nginx Yapılandırma Dosyasını Açın

Tüm sanal ana bilgisayarları etkileyen genel bir değişiklik için:

“`bash

sudo nano /etc/nginx/nginx.conf

“`

Siteye özgü yapılandırma için (üretim ortamı için önerilir):

“`bash

sudo nano /etc/nginx/sites-available/example.conf

“`

Siteye özgü dosyaların kullanılması kesinlikle tercih edilir. Değişiklikleri izole eder, geri almayı kolaylaştırır ve tek bir yanlış yapılandırmanın barındırılan tüm servisleri çökertmesini önler.

Adım 2: Tek Bir Sunucu Bloğunda Birden Fazla listen Yönergesi Yapılandırın

En basit çok portlu kurulum, bir sunucu bloğunu birkaç porta bağlar. Nginx, istemcinin hangi port üzerinden bağlandığından bağımsız olarak aynı yönlendirme mantığını uygular.

“`nginx

server {

listen 80;

listen 8080;

server_name example.com;

root /var/www/html;

index index.html index.htm;

location / {

try_files $uri $uri/ =404;

}

access_log /var/log/nginx/example_access.log;

error_log /var/log/nginx/example_error.log warn;

}

“`

Bu ne yapar:

• `listen 80;` — standart HTTP trafiğini kabul eder
• `listen 8080;` — alternatif HTTP portundaki trafiği kabul eder (geliştirme ortamları, dahili API’ler veya yük dengeleyici sağlık kontrolleri için yaygındır)
• Her iki port da `/var/www/html` dizininden aynı içeriği sunar

Uç durum — belirli bir IP adresine bağlama: Birden fazla ağ arabirimine sahip bir sunucuda (örn. genel bir IP ve özel bir LAN IP’si), Nginx’in hangi arabirimde dinleyeceğini kısıtlayabilirsiniz:

“`nginx

listen 192.168.1.10:8080;

listen 0.0.0.0:80;

“`

Bu, dahili servislerin istemeden kamuya açılmasını önlemek için çok ağlı sunucu yapılandırmalarında kritik öneme sahiptir.

Adım 3: Birden Fazla Portta HTTPS Yapılandırın

HTTPS, `listen` yönergesinde `ssl` parametresini ve geçerli sertifika/anahtar yollarını gerektirir. Aşağıdaki örnek, HTTPS’yi hem standart 443 portuna hem de özel 8443 portuna bağlar:

“`nginx

server {

listen 443 ssl;

listen 8443 ssl;

server_name example.com;

ssl_certificate /etc/nginx/ssl/example.com.crt;

ssl_certificate_key /etc/nginx/ssl/example.com.key;

Modern TLS hardening

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers HIGH:!aNULL:!MD5;

ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:10m;

ssl_session_timeout 10m;

root /var/www/html;

index index.html;

location / {

try_files $uri $uri/ =404;

}

}

“`

8443 portunun yaygın olarak kullanılmasının nedenleri:

• 443 portunun yukarı akış güvenlik duvarları tarafından engellendiği ortamlarda HTTPS trafiğine olanak tanır
• 443’teki bir üretim servisiyle çakışmadan güvenli bir sunucu çalıştırmak için geliştirme/hazırlık ortamlarında kullanılır
• HTTPS’yi standart dışı portlarda sunan bazı uygulama çerçeveleri (Tomcat, Node.js proxy’leri) tarafından gereklidir

Kritik tuzak: `ssl_protocols` ve `ssl_ciphers` parametrelerinin atlanması, Nginx’in potansiyel olarak zayıf varsayılanlar kullanmasına neden olur. Özellikle hassas verileri işleyen sunucularda TLS parametrelerini her zaman açıkça tanımlayın. Kendinden imzalı yerine güvenilir bir sertifikaya ihtiyaç duyuyorsanız, tanınmış bir CA’dan alınan SSL Sertifikaları tarayıcı uyarılarını ortadan kaldırır ve modern HSTS gereksinimlerini karşılar.

Adım 4: Farklı Portlarda Farklı İçerik Sunun

Portların farklı uygulamalara hizmet etmesi gerektiğinde — örneğin 80 portunda genel bir web sitesi ve 8080 portunda dahili bir yönetici paneli — ayrı `server` blokları kullanın:

“`nginx

server {

listen 80;

server_name example.com;

root /var/www/public;

index index.html;

location / {

try_files $uri $uri/ =404;

}

}

server {

listen 8080;

server_name example.com;

root /var/www/admin;

index index.html;

Restrict admin panel to internal network only

location / {

allow 10.0.0.0/8;

allow 192.168.0.0/16;

deny all;

try_files $uri $uri/ =404;

}

}

“`

Port tabanlı içerik ayrımı için gerçek dünya kullanım senaryoları:

• Port 80/443: Kamuya açık web sitesi
• Port 8080: Dahili REST API veya mikro hizmet uç noktası
• Port 8443: IP izin listesiyle kısıtlanmış güvenli yönetici panosu
• Port 9000: Prometheus taraması için metrik uç noktası (hiçbir zaman kamuya açık değil)
• Port 3000/5000: Node.js veya Python uygulamasına ters proxy

Adım 5: Birden Fazla Portta Nginx’i Ters Proxy Olarak Kullanma

Yaygın bir üretim deseni, farklı portları farklı arka uç uygulama sunucularına proxy’lemek için Nginx kullanmaktır:

“`nginx

server {

listen 80;

server_name app.example.com;

location / {

proxy_pass http://127.0.0.1:3000;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection 'upgrade';

proxy_set_header Host $host;

proxy_cache_bypass $http_upgrade;

}

}

server {

listen 8080;

server_name app.example.com;

location / {

proxy_pass http://127.0.0.1:4000;

proxy_http_version 1.1;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

}

“`

Bu desen, birden fazla Docker konteynerinin farklı dahili portlarda çalıştığı ve Nginx’in tek harici giriş noktası olarak görev yaptığı bir Dedicated Server üzerindeki konteynerleştirilmiş dağıtımların omurgasıdır.

Adım 6: Yapılandırmayı Doğrulayın

Nginx’i yeniden başlatmadan önce her zaman yapılandırma sözdizimini test edin. Sözdizimi hatası, servisin yeniden yüklenmesinin başarısız olmasına ve barındırılan tüm sitelerin çökmesine neden olur.

“`bash

sudo nginx -t

“`

Başarı durumunda beklenen çıktı:

“`

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

“`

Hatalar görünürse, çıktı dosya ve satır numarasını belirtir. Devam etmeden önce bildirilen tüm sorunları düzeltin.

Sıfır kesinti süreli yeniden yükleme için (üretim ortamında tam yeniden başlatmaya tercih edilir):

“`bash

sudo systemctl reload nginx

“`

Tam yeniden başlatma yalnızca `worker_processes`, `user` veya diğer ana işlem düzeyindeki yönergeleri değiştirirken gereklidir:

“`bash

sudo systemctl restart nginx

“`

Adım 7: Nginx’in Doğru Portları Dinlediğini Doğrulayın

Yapılandırmayı uyguladıktan sonra, Nginx’in beklenen portlara bağlandığını `ss` kullanarak doğrulayın (kullanımdan kaldırılmış `netstat` yerine tercih edilir):

“`bash

sudo ss -tlnp | grep nginx

“`

Örnek çıktı:

“`

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

LISTEN 0 511 0.0.0.0:8080 0.0.0.0:* users:(("nginx",pid=1234,fd=7))

LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=8))

LISTEN 0 511 0.0.0.0:8443 0.0.0.0:* users:(("nginx",pid=1234,fd=9))

“`

Bir port görünmüyorsa şunları kontrol edin:

1. Yapılandırma dosyasındaki `listen` yönergesi sözdizimi
2. Başka bir işlemin o portu zaten kullanıp kullanmadığı: `sudo ss -tlnp | grep :8080`
3. `nginx -t` komutunun hatasız geçip geçmediği
4. Standart dışı port bağlamayı engelleyebilecek SELinux veya AppArmor politikaları

Komut satırından curl ile test etme (hata ayıklama için tarayıcıdan daha güvenilir):

“`bash

curl -I http://example.com

curl -I http://example.com:8080

curl -Ik https://example.com

curl -Ik https://example.com:8443

“`

`-I` bayrağı yalnızca başlıkları getirir. `200 OK` veya `301 Moved Permanently` yanıtı, portun aktif olduğunu ve Nginx’in doğru şekilde yanıt verdiğini doğrular.

Adım 8: Güvenlik Duvarı Portlarını Açın

Ana bilgisayar güvenlik duvarı gelen bağlantıları engelliyorsa Nginx’te bir portu dinlemek yeterli değildir. Portların izin verildiğinden emin olun:

UFW (Ubuntu/Debian):

“`bash

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw allow 8080/tcp

sudo ufw allow 8443/tcp

sudo ufw reload

“`

firewalld (CentOS/RHEL/AlmaLinux):

“`bash

sudo firewall-cmd –permanent –add-port=8080/tcp

sudo firewall-cmd –permanent –add-port=8443/tcp

sudo firewall-cmd –reload

“`

iptables (doğrudan):

“`bash

sudo iptables -A INPUT -p tcp –dport 8080 -j ACCEPT

sudo iptables -A INPUT -p tcp –dport 8443 -j ACCEPT

“`

Bulut altyapısında (AWS EC2, DigitalOcean, Hetzner), sağlayıcı düzeyinde güvenlik grubu veya bulut güvenlik duvarı kurallarını da güncellemeniz gerekir — yalnızca ana bilgisayar düzeyindeki güvenlik duvarı değişiklikleri yeterli değildir.

Karşılaştırma: Tek Portlu ve Çok Portlu Nginx Yapılandırmaları

Yaygın Tuzaklar ve Bunlardan Nasıl Kaçınılır

Mevcut servislerle port çakışması: 80 portu Apache tarafından zaten kullanılıyor olabilir. Yapılandırmadan önce `sudo ss -tlnp | grep :80` komutunu çalıştırın. Çakışan servisleri durdurun veya farklı portlar kullanacak şekilde yeniden yapılandırın.

`default_server` çakışmaları: Birden fazla sunucu bloğu `default_server` parametresini atlarsa veya birden fazla blok aynı port için bunu talep ederse, Nginx dosya sırasındaki ilk bloğu kullanır. Açık olun:

“`nginx

listen 80 default_server;

“`

IPv6 kapsanmıyor: `listen 80;` eklemek yalnızca IPv4’e bağlar. Çift yığınlı sunucular için şunu ekleyin:

“`nginx

listen [::]:80;

listen [::]:8080;

“`

SELinux standart dışı portları engelliyor: SELinux zorlama modunda RHEL/CentOS’ta, Nginx açık izin olmadan politikasında bulunmayan portlara bağlanamaz:

“`bash

sudo semanage port -a -t http_port_t -p tcp 8080

sudo semanage port -a -t http_port_t -p tcp 8443

“`

Değişikliklerden sonra yeniden yüklemeyi unutmak: Yapılandırma düzenlemeleri Nginx yeniden yüklenene kadar etkili olmaz. Bunu CI/CD pipeline’larında bir dağıtım sonrası `nginx -t && systemctl reload nginx` adımıyla otomatikleştirin.

Pratik Karar Matrisi

Senaryonuz için doğru çok portlu yapılandırma desenini belirlemek üzere bu kontrol listesini kullanın:

• Aynı içerik, birden fazla port — Tek bir `server` bloğunda birden fazla `listen` yönergesi kullanın
• Port başına farklı içerik — Farklı `root` dizinleriyle ayrı `server` blokları kullanın
• Port başına farklı arka uç uygulamalar — Farklı yukarı akış adreslerine işaret eden `proxy_pass` ile ayrı `server` blokları kullanın
• Standart dışı bir portu güvenli hale getirme — `listen` yönergesine `ssl` ekleyin ve sertifika yollarınıza başvurun; sertifikanın SAN’ının etki alanını kapsadığından emin olun
• Bir portu dahili trafikle kısıtlama — `allow`/`deny` yönergeleri ekleyin veya `listen` yönergesini yalnızca özel bir IP’ye bağlayın
• cPanel ile bir VPS üzerinde çalışma — cPanel’in yerleşik Apache/Nginx yapılandırmasının çakışmadığını doğrulayın; cPanel’in “Include Editor”ını veya özel bir Nginx yapılandırma eklenti dizinini kullanın
• Birden fazla kontrol paneli seçeneğini yönetme — GUI aracılığıyla Nginx port yönetimini sunan birini bulmak için mevcut VPS Kontrol Panellerini inceleyin

SSS

Nginx birden fazla sunucu bloğunda aynı portu dinleyebilir mi?

Evet. Birden fazla `server` bloğu aynı portu paylaşabilir. Nginx, HTTP `Host` başlığıyla eşleşen `server_name` yönergesini kullanarak aralarında ayrım yapar. Hiçbir `server_name` eşleşmezse, `default_server` bloğu isteği işler.

Daha fazla listen portu eklemek Nginx performansını etkiler mi?

Ek yük ihmal edilebilir düzeydedir. Her `listen` yönergesi, Nginx ana işlemine bir dosya tanımlayıcısı ekler. Pratik sınır, port sayısı değil, sistemin açık dosya tanımlayıcısı üst sınırıdır (`ulimit -n`). Yüksek trafikli dağıtımlar için `nginx.conf` içindeki `worker_rlimit_nofile` ve `worker_connections` değerlerini ayarlayın.

8080 portundaki tüm trafiği 80 portuna nasıl yönlendiririm?

`return` yönergesiyle özel bir sunucu bloğu kullanın:

“`nginx

server {

listen 8080;

server_name example.com;

return 301 http://example.com$request_uri;

}

“`

Yapılandırma doğru görünse de Nginx neden bir portu dinlemiyor?

En yaygın dört neden şunlardır: (1) yapılandırma düzenlendikten sonra yeniden yüklenmedi, (2) başka bir işlem zaten o porta bağlı, (3) bir güvenlik duvarı kuralı portu engelliyor veya (4) SELinux/AppArmor bağlamayı engelliyor. `ss -tlnp`, `nginx -t` ve güvenlik duvarı durum komutlarını kullanarak her nedeni sistematik olarak inceleyin.

Aynı etki alanındaki farklı HTTPS portları için farklı SSL sertifikaları kullanabilir miyim?

Evet. Her `server` bloğunun kendi `ssl_certificate` ve `ssl_certificate_key` yönergeleri vardır. İki sunucu bloğu sırasıyla 443 ve 8443 portlarını dinleyebilir ve aynı `server_name` için bile tamamen farklı sertifika dosyalarına başvurabilir. Bu, sertifikaları döndürürken veya geçiş döneminde eski bir sertifikayı yenisiyle birlikte çalıştırırken kullanışlıdır.