Nginx Reverse Proxy Nedir? Nginx Proxy Manager Kurulumu

Nginx reverse proxy nedir ve ne işe yarar?

Nginx reverse proxy, ziyaretçiden gelen isteği karşılayıp arkadaki bir uygulama sunucusuna ileten, yanıtı da yine ziyaretçiye geri döndüren ara katmandır. Ziyaretçi yalnız Nginx ile konuşur; Node.js, Python ya da Docker içindeki servis dışarıya kapalı kalır. Böylece tek IP adresinde birden çok uygulamayı güvenle yayınlarsınız.

Basit bir örnekle anlatalım. Sunucunuzda 3000 portunda bir Node.js uygulaması, 8080 portunda da bir yönetim paneli çalışıyor olsun. Ziyaretçinin adres çubuğuna port numarası yazmasını istemezsiniz. Nginx 80 ve 443 portlarını dinler, gelen isteğin alan adına bakar ve onu doğru uygulamaya aktarır. Yani kapıda tek bir görevli durur, herkesi doğru odaya yönlendirir.

Bu yazıda önce kavramı ve forward proxy farkını netleştiriyoruz. Ardından resmi Nginx dokümanına dayanarak proxy_pass, başlık aktarımı, zaman aşımları ve WebSocket ayarlarını adım adım gösteriyoruz. Son bölümde ise arayüzle çalışan Nginx Proxy Manager kurulumunu, Let's Encrypt sertifikasını ve panel güvenliğini ele alıyoruz. Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz; bu nedenle anlatımı resmi kaynaklara bağlı tutuyoruz.

Reverse proxy ile forward proxy arasındaki fark nedir?

İki kavram da araya giren bir sunucuyu anlatır; fark, kimin adına çalıştığıdır. Forward proxy istemcinin adına çalışır. Örneğin bir şirket ağındaki çalışanlar internete tek bir çıkış noktası üzerinden çıkar ve hedef site gerçek çalışanı değil, proxy sunucusunu görür.

Reverse proxy ise sunucunun adına çalışır. Ziyaretçi arkada kaç uygulama olduğunu, hangi portta çalıştıklarını ya da hangi makinede durduklarını bilmez. Kısacası forward proxy istemciyi gizler, reverse proxy sunucuyu gizler.

Bu yazının konusu ikinci sütundur. Dolayısıyla "proxy" kelimesini gördüğünüzde, ziyaretçinin değil sitenizin önünde duran bir katmanı düşünün.

Nginx reverse proxy hangi durumlarda gerekir?

Her site reverse proxy kullanmak zorunda değildir. Paylaşımlı hostingde çalışan klasik bir WordPress sitesi için bu katmanı genellikle hosting sağlayıcınız zaten yönetir. Ancak kendi VPS sunucunuzu yönetiyorsanız aşağıdaki durumlarda Nginx reverse proxy neredeyse şart olur:

• Tek IP, çok uygulama: Aynı sunucuda blog, API ve yönetim paneli gibi birkaç servis çalıştırıyorsanız, her birine ayrı alan adı ya da alt alan adı verirsiniz.
• SSL sonlandırma: HTTPS şifrelemesini Nginx yürütür. Arkadaki uygulama sertifikayla uğraşmaz.
• Önbellek ve sıkıştırma: Sık istenen yanıtları Nginx katmanında tutarak uygulamanın yükünü azaltırsınız.
• Güvenlik ve gizleme: Uygulama portları dışarıya kapanır; ziyaretçi yalnız 80 ve 443 portlarını görür.
• Bakım kolaylığı: Uygulamayı yeni bir porta ya da yeni bir container'a taşıdığınızda yalnız proxy ayarını güncellersiniz.

Öte yandan birden çok sunucu arasında yük dağıtmak ayrı bir konudur. Yük dengeleme (load balancer) kurulumunu kardeş yazımızda ayrıca ele alıyoruz; burada tek sunucu üzerindeki reverse proxy senaryosuna odaklanıyoruz.

Reverse proxy kurmadan önce neleri hazırlamalısınız?

Yapılandırmaya geçmeden önce birkaç temel parçanın yerinde olması gerekir. Aksi halde hata aldığınızda sorunun proxy ayarında mı yoksa altyapıda mı olduğunu ayırt etmek zorlaşır.

1. Sunucu ve işletim sistemi: Güncel bir Linux dağıtımı ve sudo yetkili bir kullanıcı. İlk adımlar için Ubuntu Server ilk yapılandırma rehberimize göz atabilirsiniz.
2. Nginx kurulumu: Paket yöneticisiyle kurduğunuz ve çalışan bir Nginx. Kurulum adımlarını ayrı yazımızda anlatıyoruz; burada tekrar etmiyoruz.
3. DNS kaydı: Alan adınızın ya da alt alan adınızın A (IPv4) veya AAAA (IPv6) kaydı sunucu IP adresini göstermeli. Kaydı DNS sorgulama aracımızla kontrol edebilirsiniz.
4. Arka uç uygulama: Uygulamanız yalnız yerel adreste, örneğin 127.0.0.1:3000 üzerinde dinlemeli.
5. Güvenlik duvarı: 80 ve 443 portları açık, uygulama portları kapalı olmalı.

Örneğin bir Node.js uygulamasını systemd servisi olarak ayağa kaldırmak istiyorsanız Node.js kurulumu ve deploy rehberimiz bu hazırlığı adım adım gösterir.

Nginx reverse proxy yapılandırmasını nasıl yazarsınız?

Nginx reverse proxy ayarının kalbi proxy_pass direktifidir. Bu direktif, eşleşen isteği hangi adrese ileteceğinizi söyler. Aşağıdaki örnek, app.example.com alan adına gelen istekleri aynı sunucudaki 3000 portuna aktarır:

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 Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Bu dosyayı dağıtımınızın kullandığı yapılandırma dizinine kaydedin. Ardından sözdizimini test edip Nginx'i yeniden yükleyin:

sudo nginx -t
sudo systemctl reload nginx

Test komutu hata verirse yeniden yükleme yapmayın. Çünkü nginx -t hangi dosyanın hangi satırında sorun olduğunu söyler ve mevcut çalışan yapılandırmayı değiştirmez. Ayrıca reload komutu, açık bağlantıları koparmadan yeni ayarları devreye alır; bu yüzden canlı sitede restart yerine onu tercih edin.

proxy_pass adresindeki sondaki eğik çizgi neyi değiştirir?

Reverse proxy kuranların en sık takıldığı nokta budur. Resmi Nginx proxy modülü dokümanına göre proxy_pass içinde bir URI belirtirseniz, isteğin location ile eşleşen kısmı o URI ile yer değiştirir. URI belirtmezseniz istek, istemcinin gönderdiği haliyle arka uca gider.

Somut bir örnek verelim. Diyelim ki location /api/ bloğu tanımladınız:

• proxy_pass http://127.0.0.1:3000; yazarsanız, /api/users isteği arka uca /api/users olarak gider.
• proxy_pass http://127.0.0.1:3000/; yazarsanız, /api/ kısmı / ile yer değiştirir ve istek arka uca /users olarak gider.

Yani tek bir eğik çizgi, uygulamanızın 404 dönmesine ya da doğru çalışmasına karar verebilir. Uygulamanız kendi yollarını /api ön ekiyle tanımlıyorsa ilk biçimi, ön eki bilmiyorsa ikinci biçimi seçin. Dokümana göre location düzenli ifadeyle tanımlıysa ya da proxy_pass içinde değişken kullanıyorsanız URI belirtmemeniz gerekir. Kısacası her değişiklikten sonra birkaç farklı yolu tarayıcıda ya da komut satırında deneyin.

Host, X-Forwarded-For ve X-Forwarded-Proto başlıkları neden önemlidir?

Varsayılan durumda Nginx, arka uca giden istekte Host başlığını $proxy_host değeriyle doldurur; yani uygulama 127.0.0.1:3000 adresini görür. Resmi dokümanda varsayılan değerler Host $proxy_host ve Connection close olarak geçer. Uygulamanız alan adına göre davranıyorsa bu durum yanlış yönlendirmelere yol açar.

Bu yüzden üç başlığı açıkça ayarlamanızı öneririz:

• Host $host: Ziyaretçinin yazdığı alan adını uygulamaya taşır. Çok alan adlı uygulamalar ve mutlak bağlantı üreten çatılar bunu bekler.
• X-Forwarded-For $proxy_add_x_forwarded_for: Ziyaretçinin IP adresini zincirin sonuna ekleyerek iletir. Gelen istekte bu başlık yoksa değişken doğrudan $remote_addr değerine eşit olur.
• X-Forwarded-Proto $scheme: Ziyaretçinin HTTP mi HTTPS mi kullandığını bildirir.

Özellikle son başlığı birçok kişi atlar. HTTPS'i Nginx sonlandırdığında uygulama kendisine HTTP ile gelen bir istek görür. Başlığı göndermezseniz uygulama ziyaretçiyi tekrar HTTPS'e yönlendirmeye çalışır ve sonsuz yönlendirme döngüsü oluşur. Ayrıca dokümandaki önemli bir kural var: Bir location içinde tek bir proxy_set_header bile yazarsanız, üst seviyedeki tüm başlık tanımları o blokta geçersiz kalır. Dolayısıyla başlıkları ya hep aynı seviyede toplayın ya da her blokta eksiksiz tekrarlayın.

Nginx reverse proxy ayarınızı nasıl test edersiniz?

Yapılandırmayı yükledikten sonra tarayıcıya geçmeden önce komut satırından birkaç kontrol yapmanızı öneririz. Böylece tarayıcı önbelleği ya da yönlendirme hafızası sizi yanıltmaz.

1. Uygulamanın gerçekten yerel adreste dinlediğini ss -tlnp komutuyla kontrol edin.
2. Arka uca doğrudan istek atın: curl -I http://127.0.0.1:3000 komutu yanıt vermiyorsa sorun proxy'de değil, uygulamadadır.
3. Nginx üzerinden aynı isteği deneyin: curl -I -H "Host: app.example.com" http://127.0.0.1 komutu, DNS'e bağlı kalmadan doğru server bloğunun eşleştiğini gösterir.
4. Son olarak gerçek alan adıyla HTTPS isteği atın ve yanıt başlıklarındaki durum kodunu ve yönlendirme adresini okuyun.

Bu sıra, sorunun hangi katmanda olduğunu hızlıca ayırır. Örneğin ikinci adım başarılı, üçüncü adım başarısızsa sorun büyük olasılıkla server_name ya da proxy_pass satırındadır. Ayrıca uygulama kayıtlarında X-Forwarded-For değerinin kendi IP adresinizi gösterdiğini doğrulayın.

Gerçek ziyaretçi IP adresi uygulamaya nasıl ulaşır?

Reverse proxy arkasındaki uygulama, bağlantıyı Nginx'ten aldığı için kaynak adres olarak hep 127.0.0.1 görür. Ziyaretçi IP adresini istatistik, oran sınırlama ya da güvenlik kaydı için kullanıyorsanız uygulamanın X-Forwarded-For başlığını okuması gerekir.

Burada dikkatli olun. Bu başlığı istemci de kendi isteğine koyabilir. Bu nedenle uygulamanıza yalnız güvendiğiniz proxy adreslerinden gelen başlığı dikkate almasını söylemelisiniz. Laravel, Express ve Django gibi çatıların "trusted proxy" ayarı tam olarak bu işe yarar. Her çatının kendi dokümanındaki adımı izleyin.

Nginx önünde ikinci bir katman, örneğin bir CDN ya da başka bir proxy varsa, Nginx'in kendisi de gerçek adresi görmez. Bu durumda ngx_http_realip_module modülünün set_real_ip_from ve real_ip_header direktiflerini kullanırsınız:

set_real_ip_from 192.0.2.10;
real_ip_header X-Forwarded-For;

Örnekteki adres yalnız temsilidir; buraya önünüzdeki katmanın gerçek adres aralığını yazın. Modülün Nginx derlemenizde bulunup bulunmadığını nginx -V çıktısında kontrol edebilirsiniz. Böylece sahte başlık gönderen biri, kayıtlarınızda başka birinin IP adresiyle görünemez.

Zaman aşımı ayarlarını ne zaman değiştirmelisiniz?

Resmi dokümana göre üç temel zaman aşımının varsayılan değeri 60 saniyedir. proxy_connect_timeout arka uçla bağlantı kurma süresini, proxy_read_timeout iki okuma arasındaki bekleme süresini, proxy_send_timeout ise iki yazma arasındaki süreyi sınırlar.

Önemli ayrıntı şu: Okuma ve gönderme zaman aşımları yanıtın tamamı için değil, iki ardışık işlem arasındaki sessizlik için geçerlidir. Yani 5 dakika süren ama sürekli veri akıtan bir indirme yarıda kalmaz. Buna karşılık 70 saniye boyunca hiç yanıt üretmeyen bir rapor sorgusu, varsayılan ayarla 504 hatasına düşer.

location /rapor/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 10s;
    proxy_read_timeout 180s;
    proxy_send_timeout 180s;
}

Örnekte süreyi yalnız uzun işlem yapan yol için artırdık. Tüm siteye büyük değer vermek, takılan isteklerin bağlantıları uzun süre meşgul etmesine yol açar. Ayrıca dokümana göre bağlantı kurma zaman aşımı genellikle 75 saniyeyi geçemez. Uzun işlemler için asıl çözüm çoğu zaman zaman aşımını büyütmek değil, işi arka plan kuyruğuna almaktır.

WebSocket için Nginx reverse proxy ayarını nasıl yaparsınız?

Canlı sohbet, bildirim ya da anlık panel gibi özellikler WebSocket kullanır. WebSocket, HTTP isteğiyle başlar ve Upgrade başlığıyla kalıcı bir bağlantıya geçer. Ancak Nginx WebSocket dokümanının belirttiği gibi Upgrade ve Connection başlıkları proxy üzerinden kendiliğinden geçmez; bu nedenle onları açıkça aktarmanız gerekir.

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        location /ws/ {
            proxy_pass http://127.0.0.1:3000;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_read_timeout 300s;
        }
    }
}

Buradaki map bloğu, istemci yükseltme istemediğinde Connection başlığını close olarak gönderir. Böylece aynı location hem normal hem WebSocket isteklerine hizmet eder. Resmi doküman, yakın tarihli Nginx sürümlerinde HTTP 1.1'in varsayılan hale geldiğini, daha eski sürümlerde ise 1.0 olduğunu belirtiyor. Bu yüzden proxy_http_version 1.1 satırını açıkça yazmak her sürümde güvenli bir tercihtir.

Üstelik dokümana göre arka uç 60 saniye boyunca veri göndermezse bağlantı kapanır. Çözüm olarak proxy_read_timeout değerini artırabilir ya da uygulamanızın düzenli ping çerçeveleri göndermesini sağlayabilirsiniz.

SSL sonlandırma ve önbellek reverse proxy üzerinde nasıl çalışır?

SSL sonlandırma, HTTPS şifresini Nginx reverse proxy katmanının çözmesi anlamına gelir. Sertifika yalnız Nginx'te durur, arka uçla trafik sunucu içinde düz HTTP olarak akar. Böylece her uygulamaya ayrı sertifika kurmazsınız ve yenileme işini tek noktadan yönetirsiniz. Sertifikanın temellerini SSL sertifikası rehberimizde anlatıyoruz.

Sertifika almak için Let's Encrypt en yaygın seçenektir. Let's Encrypt doğrulama türleri dokümanına göre HTTP-01 doğrulaması 80 portunun erişilebilir olmasını ister; joker (wildcard) sertifika için ise yalnız DNS-01 doğrulaması geçerlidir. Joker sertifika ihtiyacınız varsa wildcard SSL rehberimize bakabilirsiniz. Kurulumdan sonra zinciri SSL sorgulama aracımızla test edin.

Önbellek tarafında Nginx, proxy_cache_path ile bir disk alanı ve paylaşımlı bellek bölgesi tanımlamanıza, proxy_cache ile de bu alanı bir location'da kullanmanıza izin verir. Varsayılan durumda önbellek kapalıdır. Oturum açmış kullanıcıya özel sayfaları önbelleğe almak veri sızıntısına yol açabilir; dolayısıyla yalnız herkese aynı görünen içeriği hedefleyin. Daha kapsamlı bir HTTP önbelleği arıyorsanız Varnish Cache yazımız farklı bir yaklaşım sunar.

Nginx Proxy Manager nedir, kimler için uygundur?

Nginx Proxy Manager (NPM), Nginx'i web arayüzüyle yönetmenizi sağlayan açık kaynak bir projedir. Docker container'ı olarak çalışır. Resmi dokümanda sayılan başlıca özellikler şunlardır: alan adı yönlendirmeleri, yeniden yönlendirmeler, stream ve 404 host tanımları, Let's Encrypt ile ücretsiz SSL ya da kendi sertifikanızı yükleme, erişim listeleri ve temel HTTP kimlik doğrulaması, kullanıcı yönetimi ve denetim kaydı.

NPM, yapılandırma dosyası yazmadan birkaç servisi yayınlamak isteyenler için pratiktir. Örneğin ev sunucusunda ya da küçük bir VPS'te Docker ile çalışan birkaç uygulamanız varsa, her biri için birkaç tıklamayla alan adı ve sertifika tanımlarsınız. Ayrıca proje, ileri düzey kullanıcılar için host başına özel Nginx ayarı girmeye de izin verir.

Buna karşılık çok karmaşık yönlendirme kuralları, yüksek trafik altında ince ayar ya da yapılandırmayı Git ile sürümlemek istiyorsanız elle yazılan Nginx dosyaları daha şeffaf kalır. Docker temellerine yabancıysanız önce Docker nedir rehberimizi okumanızı öneririz.

Nginx Proxy Manager'ı Docker ile nasıl kurarsınız?

Nginx Proxy Manager resmi kurulum sayfası, Docker ve Docker Compose kurulduktan sonra tek bir compose dosyasıyla başlamayı önerir. Dokümana göre 80 portu genel HTTP, 443 portu genel HTTPS, 81 portu ise yönetim arayüzü içindir. Biz yönetim portunu baştan yalnız sunucunun kendisine açan bir varyasyon öneriyoruz:

services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '127.0.0.1:81:81'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Dosyayı boş bir klasöre docker-compose.yml adıyla kaydedin ve aynı klasörde şu komutu çalıştırın:

docker compose up -d

İlk açılışta anahtarlar ve veritabanı oluştuğu için arayüzün hazır olması birkaç dakika sürebilir. Dokümana göre varsayılan veritabanı SQLite'tır ve data klasöründe durur; isterseniz MySQL, MariaDB ya da PostgreSQL de bağlayabilirsiniz. Resmi kurulum sayfası belirli bir sürüm etiketiyle örnek veriyor; üretim ortamında latest yerine sabit bir sürüm etiketi kullanmanızı öneririz. Böylece güncellemeyi siz planlarsınız. Container'ları arayüzle izlemek isterseniz Portainer kurulum rehberimiz bu kurulumla uyumlu çalışır.

İlk girişte hangi güvenlik adımlarını atmalısınız?

Yönetim portunu yalnız 127.0.0.1 adresine bağladığınız için panele uzaktan doğrudan erişemezsiniz. Bunun yerine kendi bilgisayarınızdan bir SSH tüneli açın:

ssh -L 8181:127.0.0.1:81 kullanici@203.0.113.10

Ardından tarayıcıda http://127.0.0.1:8181 adresine gidin. Panel sürüme göre ilk açılışta ya yönetici hesabı oluşturmanızı ister ya da varsayılan bir hesapla açılıp bilgileri güncellemenizi bekler. Hangisi olursa olsun şu adımları atlamayın:

1. Kendi e-posta adresinizi ve uzun, benzersiz bir parola tanımlayın; varsayılan hiçbir bilgiyi bırakmayın.
2. Panelde birden fazla kişi çalışacaksa her birine ayrı kullanıcı açın ve yalnız ihtiyaç duyduğu yetkiyi verin.
3. data ve letsencrypt klasörlerini yedekleme planınıza ekleyin; host tanımları ve sertifikalar burada durur.
4. Sürüm güncellemelerini resmi sürüm notlarını okuyarak, önce yedek alıp öyle yapın.

Bu adımlar ilk bakışta küçük duruyor. Ancak panel ele geçirilirse saldırgan tüm alan adlarınızın trafiğini istediği yere yönlendirebilir. Kısacası NPM paneli, sunucunuzdaki en değerli kapılardan biridir.

Proxy host eklemek ve Let's Encrypt SSL almak için ne yapmalısınız?

Panelde Hosts menüsünden Proxy Hosts bölümüne girip yeni bir kayıt eklersiniz. Details sekmesinde dört temel alan vardır: alan adı, şema (http ya da https), isteği aktaracağınız ana bilgisayar adı ya da IP adresi ve port. Aynı sekmede WebSocket desteğini ve yaygın saldırı kalıplarını engelleme seçeneğini de açabilirsiniz.

Burada Docker ağına dikkat edin. NPM bir container içinde çalıştığı için oradaki 127.0.0.1 sunucunun kendisi değil, NPM container'ının kendisidir. En temiz çözüm, NPM ile uygulamayı aynı Docker ağına almaktır. Önce ortak bir ağ oluşturun:

docker network create proxy-ag

Ardından her iki compose dosyasının sonuna bu ağı harici ağ olarak ekleyin:

networks:
  default:
    name: proxy-ag
    external: true

Böylece yönlendirme alanına IP yerine container adını, porta da uygulamanın container içindeki portunu yazarsınız. SSL sekmesinde ise yeni bir Let's Encrypt sertifikası isteyip HTTPS zorlama ve HTTP/2 seçeneklerini açarsınız. HTTP-01 doğrulaması için alan adının DNS kaydı bu sunucuyu göstermeli ve 80 portu dışarıdan erişilebilir olmalıdır.

Erişim listeleri (Access Lists) ne işe yarar?

Erişim listeleri, bir proxy host'a kimin ulaşabileceğini belirler. NPM'de iki tür kısıtı birleştirebilirsiniz: kullanıcı adı ve parolayla temel HTTP kimlik doğrulaması ve IP adresi ya da adres aralığına göre izin verme ve engelleme kuralları.

Örneğin şirket içinde kullanılan bir raporlama panelini yalnız ofisin sabit IP adresine açabilirsiniz. Ya da test ortamınızı arama motorlarından ve meraklı ziyaretçilerden korumak için basit bir parola koyabilirsiniz. Listeyi oluşturduktan sonra ilgili proxy host'un ayarında seçmeniz yeterlidir.

Yine de temel kimlik doğrulamayı tek savunma hattı olarak görmeyin. Şifreli bağlantı olmadan gönderilen parola ağda okunabilir; bu yüzden erişim listesini mutlaka SSL ile birlikte kullanın. Ayrıca uygulamanın kendi oturum ve yetki sistemini de güçlü tutun. Kaba kuvvet denemelerini sunucu seviyesinde engellemek isterseniz Fail2ban rehberimiz tamamlayıcı bir katman sağlar.

Panel portunu (81) internete açmak neden risklidir?

Resmi örnekteki compose dosyası 81 portunu tüm ağ arayüzlerine yayınlar. Sunucunuz doğrudan internete bağlıysa bu, yönetim panelinin giriş ekranının herkese açık olması demektir. Üstelik bu port varsayılan haliyle düz HTTP üzerinden çalışır; yani giriş bilgileri şifresiz akar.

Bir de çoğu kişinin gözden kaçırdığı bir ayrıntı var. Docker'ın resmi ağ ve güvenlik duvarı dokümanı, yayımlanan container portlarının trafiğinin ufw gibi araçların kurallarından önce yönlendirildiğini belirtir. Dolayısıyla "ufw ile 81'i kapattım" demeniz, portun gerçekten kapalı olduğunu garanti etmez. Bu nedenle şu yöntemlerden birini seçin:

• Portu compose dosyasında 127.0.0.1 adresine bağlayın ve panele SSH tüneliyle girin.
• Paneli kendi alan adınızla bir proxy host olarak yayınlayın, SSL zorlayın ve erişim listesiyle yalnız kendi IP adresinize açın.
• Panel erişimini VPN üzerinden verin.

Hangisini seçerseniz seçin, değişiklikten sonra portun dışarıdan gerçekten kapalı olduğunu başka bir ağdan test edin.

Elle Nginx yapılandırması mı, Nginx Proxy Manager mı seçmelisiniz?

İki yol da aynı motoru kullanır; fark, yönetim biçimindedir. Aşağıdaki tablo seçim yaparken bakmanız gereken başlıkları özetliyor:

Pratikte birçok ekip ikisini farklı ortamlarda kullanır. Örneğin test sunucusunda NPM ile hızlı deneme yapar, canlı ortamda ise sürümlenen Nginx dosyalarıyla ilerler. Kendi sunucunuzda uygulama platformu arıyorsanız Coolify rehberimiz üçüncü bir seçenek sunar.

Reverse proxy kurulumunda en sık yapılan hatalar nelerdir?

Nginx reverse proxy hatası aldığınızda önce Nginx hata kaydına bakın; sorunun büyük kısmı orada açıkça yazar. Sık karşılaşılan durumları şöyle özetleyebiliriz:

• 502 Bad Gateway: Nginx arka uca ulaşamıyor. Uygulama çalışmıyor olabilir, yanlış portu dinliyor olabilir ya da Docker ağında ad çözümlemesi başarısız olabilir.
• 504 Gateway Timeout: Arka uç yanıt vermeden okuma zaman aşımı doldu. Uzun işlemi arka plana alın ya da yalnız o yolda süreyi artırın.
• Sonsuz yönlendirme: X-Forwarded-Proto başlığı eksik ya da uygulama proxy'ye güvenmiyor.
• Karışık içerik uyarısı: Uygulama HTTPS sayfada HTTP bağlantılar üretiyor; yine şema bilgisinin aktarımını kontrol edin.
• Tüm ziyaretçiler aynı IP ile görünüyor: Nginx X-Forwarded-For başlığını aktarmıyor ya da uygulama onu okumuyor.
• WebSocket kopuyor: Upgrade başlıkları eksik ya da okuma zaman aşımı çok kısa.

Bu listeyi bir kontrol sırası gibi kullanın. Önce bağlantı, sonra başlıklar, en son zaman aşımları. Böylece rastgele ayar değiştirerek yeni sorunlar yaratmazsınız.

Bu işi ne zaman hosting sağlayıcınıza ya da bir uzmana bırakmalısınız?

Dürüst olmak gerekirse herkesin kendi Nginx reverse proxy katmanını yönetmesi gerekmez. Sitenizi paylaşımlı hostingde ya da yönetilen bir platformda barındırıyorsanız, bu katmanı sağlayıcınız zaten işletir. Orada kendi Nginx'inizi kurmaya çalışmak hem mümkün olmayabilir hem de destek kapsamınızı bozabilir.

Şu durumlarda işi sağlayıcınıza ya da deneyimli bir sistem yöneticisine bırakmanızı öneririz:

• Sunucuda ödeme, sağlık ya da kişisel veri işleyen bir uygulama çalışıyorsa.
• Kesinti dakika başına ciddi gelir kaybı demekse.
• SSH, güvenlik duvarı ve log okuma konusunda kendinizi rahat hissetmiyorsanız.

Kendi uygulamanızı geliştirirken altyapı kararlarını da birlikte planlamak isterseniz özel yazılım geliştirme hizmetimiz kapsamında mimariyi baştan doğru kurmanıza yardımcı oluyoruz. Kısacası reverse proxy güçlü bir araçtır; ancak sorumluluğunu da beraberinde getirir.