- Konu sahibi
- #1
Reverse proxy, ziyaretçi ile web uygulaması veya sunucu arasında duran ve istemciden gelen istekleri arka uç sunucusuna ileten ara katmandır. Kullanıcı doğrudan uygulama sunucusuna değil, reverse proxy’ye bağlanır; proxy isteği uygun backend’e aktarır ve backend yanıtını kullanıcıya döndürür.
Örneğin ziyaretçi
İstek akışı genellikle şöyledir:
Bu yapı, tek bir sunucuda birden fazla uygulamayı farklı alan adları veya yollar üzerinden yayınlamayı sağlar. Ayrıca uygulama sunucusunun doğrudan internete açılmasını önleyebilir, önbellekleme ve yük dengeleme gibi görevleri merkezi hâle getirebilir. Ancak reverse proxy tek başına uygulama güvenliği, yedekleme veya sunucu güncellemesi yerine geçmez.
Aşağıdaki en küçük örnekte uygulamanın
Bu blok yalnız HTTP port 80 içindir; sertifika/443 kurulumu içermez. HTTPS yayını için ayrıca doğrulanmış TLS yapılandırması gerekir. Burada proxy_pass sonunda URI bölümü yoktur; farklı bir yol öneki kullanacaksanız URI değiştirme ve sondaki slash davranışını ayrıca kontrol edin. X-Forwarded-For zincirindeki istemciden gelen değerleri gelişigüzel güvenilir kabul etmeyin; uygulama yalnız bilinen proxy zincirini değerlendirmelidir.
Uygulama adımları:
Başarılı durumda kullanıcı uygulamanın yanıtını alan adı üzerinden görür.
Kararı şu şekilde verebilirsiniz:
WebSocket, uzun süre açık bağlantı veya büyük dosya yükleme kullanan uygulamalarda varsayılan proxy ayarları yeterli olmayabilir. Bu durumlarda bağlantı yükseltme başlıkları, zaman aşımı ve gövde boyutu gibi ayarları uygulamanın gereksinimine göre düzenleyin. Reverse proxy arkasında çalışan uygulamanın gerçek istemci IP’sine güvenmesi de yalnızca güvenilir proxy’lerden gelen başlıklar için etkinleştirilmelidir.
Backend’i yanlış adrese bağlamak: Uygulama başka bir portta veya yalnızca farklı bir arayüzde dinliyorsa proxy bağlantı kuramaz.
DNS’i unutmak: Yapılandırma doğru olsa bile alan adı proxy sunucusuna çözülmüyorsa istek sunucuya ulaşmaz.
HTTPS yönlendirme döngüsü oluşturmak: TLS proxy’de sonlanırken backend’in her isteği tekrar HTTPS’e yönlendirmesi sonsuz yönlendirmeye neden olabilir. İletilen protokol başlığının uygulama tarafından doğru okunmasını sağlayın.
Doğrudan backend erişimini açık bırakmak: Uygulama portu internete açık kaldığında kullanıcılar proxy kurallarını atlayabilir. Dış erişimi yalnızca gerçekten gerekliyse bırakın.
Tam olarak değil. Load balancer, trafiği birden fazla backend arasında dağıtma görevine odaklanır. Reverse proxy bu özelliği sunabilir; ancak tek bir backend’in önünde TLS sonlandırma, yönlendirme veya önbellekleme de yapabilir.
Hayır. Uygulama iç ağda mevcut portunda çalışmaya devam edebilir. Kullanıcıların gördüğü dış port ve alan adı reverse proxy tarafından yönetilir; proxy de istekleri uygulamanın dinlediği iç adrese aktarır.
Hayır. Önbellekleme, sıkıştırma veya bağlantı yönetimi uygun yapılandırılırsa fayda sağlayabilir; fakat yanlış ayarlar ek gecikme ve hata oluşturabilir. Önce backend yanıtını doğrudan yerel olarak doğrulayıp sonra proxy katmanını ölçerek değerlendirin.
Örneğin ziyaretçi
example.com adresine bağlanırken, uygulamanız yalnızca 127.0.0.1:3000 üzerinde çalışabilir. Nginx veya Apache reverse proxy olarak görev yaparsa dışarıya 443 portundan hizmet verir, HTTPS işlemini üstlenir ve isteği yerel uygulamaya iletir.Nasıl çalışır?
İstek akışı genellikle şöyledir:
- Kullanıcı alan adına bağlanır.
- DNS, alan adını reverse proxy sunucusunun IP adresine yönlendirir.
- Reverse proxy isteği alır; HTTPS kullanılıyorsa sunucu sertifikasını istemciye sunar ve TLS bağlantısını sonlandırır; sertifika güvenini doğrulayan esas taraf istemcidir. HTTPS backend’e bağlanıyorsa backend sertifikasının doğrulanması ayrı proxy ayarıdır.
- İstek, belirlenen backend adresine aktarılır.
- Backend yanıtı reverse proxy’ye verir; proxy de yanıtı kullanıcıya gönderir.
Bu yapı, tek bir sunucuda birden fazla uygulamayı farklı alan adları veya yollar üzerinden yayınlamayı sağlar. Ayrıca uygulama sunucusunun doğrudan internete açılmasını önleyebilir, önbellekleme ve yük dengeleme gibi görevleri merkezi hâle getirebilir. Ancak reverse proxy tek başına uygulama güvenliği, yedekleme veya sunucu güncellemesi yerine geçmez.
Somut örnek: Nginx ile yerel uygulamayı yayınlamak
Aşağıdaki en küçük örnekte uygulamanın
127.0.0.1:3000 üzerinde dinlediği ve Nginx’in example.com için istekleri buraya aktaracağı varsayılır:
Kod:
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://127.0.0.1:3000;
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 blok yalnız HTTP port 80 içindir; sertifika/443 kurulumu içermez. HTTPS yayını için ayrıca doğrulanmış TLS yapılandırması gerekir. Burada proxy_pass sonunda URI bölümü yoktur; farklı bir yol öneki kullanacaksanız URI değiştirme ve sondaki slash davranışını ayrıca kontrol edin. X-Forwarded-For zincirindeki istemciden gelen değerleri gelişigüzel güvenilir kabul etmeyin; uygulama yalnız bilinen proxy zincirini değerlendirmelidir.
Uygulama adımları:
- Backend uygulamasını
127.0.0.1:3000üzerinde çalıştırın ve aynı sunucudan yanıt verdiğini doğrulayın. - Nginx yapılandırmasına benzer bir
serverbloğu ekleyin;server_namedeğerini kendi alan adınızla değiştirin. - Önce sudo nginx -t ile yapılandırma testini geçirin; sonra dağıtımın desteklediği reload yöntemini kullanın. Systemd ile yönetilen Linux kurulumlarında bu genellikle sudo systemctl reload nginx olur. Test başarısızsa reload yapmayın.
- Alan adının DNS kaydını reverse proxy sunucusuna yönlendirin ve tarayıcıdan alan adını açın.
Başarılı durumda kullanıcı uygulamanın yanıtını alan adı üzerinden görür.
502 Bad Gateway görülürse proxy çalışıyor ancak backend’e bağlanamıyor olabilir; uygulamanın çalışıp çalışmadığını, portu ve yerel erişimi kontrol edin. 404 hem proxy hem backend tarafından üretilebilir; yalnız durum kodundan backend’e ulaşıldığı sonucunu çıkarmayın. Access/error logları ve upstream durumu ile hangi katmanın yanıtladığını belirleyin. Uygulama istemci IP’sini logluyorsa X-Forwarded-For ve benzeri başlıkları doğru yorumlayacak şekilde yapılandırılmalıdır.Hangi durumda kullanılır?
Kararı şu şekilde verebilirsiniz:
| İhtiyaç | Reverse proxy’nin katkısı | Dikkat edilmesi gereken |
|---|---|---|
| HTTPS’i merkezi yönetmek | TLS sonlandırmayı proxy’de toplar | Backend ile proxy arasındaki trafiğin güvenlik gereksinimini ayrıca değerlendirin |
| Birden fazla uygulama yayınlamak | Alan adı veya URL yoluna göre yönlendirme yapar | Çakışan yollar ve doğru Host başlığı kontrol edilmelidir |
| Trafiği birden fazla backend’e dağıtmak | Yük dengeleme ve arıza toleransı sağlayabilir | Oturumların hangi backend’e gideceği ayrıca tasarlanmalıdır |
WebSocket, uzun süre açık bağlantı veya büyük dosya yükleme kullanan uygulamalarda varsayılan proxy ayarları yeterli olmayabilir. Bu durumlarda bağlantı yükseltme başlıkları, zaman aşımı ve gövde boyutu gibi ayarları uygulamanın gereksinimine göre düzenleyin. Reverse proxy arkasında çalışan uygulamanın gerçek istemci IP’sine güvenmesi de yalnızca güvenilir proxy’lerden gelen başlıklar için etkinleştirilmelidir.
Sık yapılan hatalar
Backend’i yanlış adrese bağlamak: Uygulama başka bir portta veya yalnızca farklı bir arayüzde dinliyorsa proxy bağlantı kuramaz.
DNS’i unutmak: Yapılandırma doğru olsa bile alan adı proxy sunucusuna çözülmüyorsa istek sunucuya ulaşmaz.
HTTPS yönlendirme döngüsü oluşturmak: TLS proxy’de sonlanırken backend’in her isteği tekrar HTTPS’e yönlendirmesi sonsuz yönlendirmeye neden olabilir. İletilen protokol başlığının uygulama tarafından doğru okunmasını sağlayın.
Doğrudan backend erişimini açık bırakmak: Uygulama portu internete açık kaldığında kullanıcılar proxy kurallarını atlayabilir. Dış erişimi yalnızca gerçekten gerekliyse bırakın.
Kaynaklar
Sık sorulan sorular
Reverse proxy ile load balancer aynı şey midir?
Tam olarak değil. Load balancer, trafiği birden fazla backend arasında dağıtma görevine odaklanır. Reverse proxy bu özelliği sunabilir; ancak tek bir backend’in önünde TLS sonlandırma, yönlendirme veya önbellekleme de yapabilir.
Reverse proxy kullanınca uygulamanın portunu değiştirmek gerekir mi?
Hayır. Uygulama iç ağda mevcut portunda çalışmaya devam edebilir. Kullanıcıların gördüğü dış port ve alan adı reverse proxy tarafından yönetilir; proxy de istekleri uygulamanın dinlediği iç adrese aktarır.
Reverse proxy uygulamayı otomatik olarak hızlandırır mı?
Hayır. Önbellekleme, sıkıştırma veya bağlantı yönetimi uygun yapılandırılırsa fayda sağlayabilir; fakat yanlış ayarlar ek gecikme ve hata oluşturabilir. Önce backend yanıtını doğrudan yerel olarak doğrulayıp sonra proxy katmanını ölçerek değerlendirin.
