proxy_redirect NGINX'i VPN ana bilgisayarınıza bağlamaz
proxy_redirect zaten gelen bir yanıttaki başlıkları yeniden yazar; upstream'i asla seçmez. proxy_pass'i, backend'e giden rotayı ve ardından başlıkları kontrol edin.
Adında redirect kelimesi var, bu yüzden VPN arkasındaki bir backend'e erişilemediğinde bir location bloğuna yapıştırılıyor. Hiçbir şey değişmiyor ve bariz sonuç, yönergenin bozuk olduğu ya da farklı bir sözdizimi gerektirdiği. Gerçekte olan daha basit ve daha az pohpohlayıcı: proxy_redirect zaten geri dönmüş bir yanıt üzerinde çalışır ve bu kurulumda hiçbir istek o kadar ileri gitmedi.
İki yönerge, tek istekte iki an
Ters proxy üzerinden geçen bir HTTP isteği sırayla birkaç karardan geçer ve iki yönerge bu dizinin karşıt uçlarında durur. Biri isteğin nereye gideceğini seçer. Diğeri geri dönen yanıttaki belirli başlıkları düzenler.
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
Bu sıra yanıtın tamamıdır. Birinci satır başarısız olduğu için ikinci satır hiç çalışmazsa, ikinci yönerge yanlış yapılandırılmamıştır, yalnızca erişilemezdir. İkinci satırı ne kadar yeniden yazarsanız yazın, düzenlemesi gereken yanıt oluşmaz. Teşhisi ilk satırdan dışa doğru yapın; kafa karıştıran davranış eksik bir rotaya ya da reddedilmiş bir bağlantıya indirgenir.
Upstream seçimi proxy_pass'e aittir
Diyelim ki NGINX genel bir giriş ana bilgisayarında çalışıyor ve VPN'i üzerinden 10.40.0.20:8080 adresindeki bir uygulamaya ulaşıyor. Bu uygulamayı seçen parça, var olan bir server bloğunun içinde şöyle görünür:
location / {
proxy_pass http://10.40.0.20:8080;
}Gerçek şemayı, adresi ve bağlantı noktasını kullanın ve bunu bir kurulum değil parça olarak ele alın. Giriş ana bilgisayarı VPN rotasını, izin verilen iletme yolunu ve o hizmete çalışan dönüş trafiğini de tutmalıdır, çünkü kâğıt üzerinde bir adrese ulaşan proxy'nin yine de çekirdeğin onayına ihtiyacı vardır.
proxy modülü başvurusu upstream seçimini yanıt başlıklarının yeniden yazılmasından ayrı tutar ve URI içeren bir proxy_pass değerinin eşleşen location önekini nasıl değiştirileceğini değiştirdiğini belirtir. Uygulamanın beklediği URL'yi kontrol etmeden yol bileşenleri eklemek veya kaldırmak, yönlendirme hatasına benzeyen bir 404 üretmenin güvenilir yoludur.
proxy_redirect özel adresi sızdıran yanıtları onarır
Trafik akmaya başladığında backend, özel adresini belirten bir Location başlığıyla yanıt verebilir. Bu başlığı izleyen tarayıcı genel giriş noktasından ayrılır ve çözemeyeceği bir şeye ulaşmaya çalışır. Bilinçli olarak yapılandırılmış yanıt yeniden yazma, özel URL'yi genel olanın üzerine eşler:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Her iki tarafı da gerçek değerlerle değiştirin. Dar kapsamı da anlayın: eşleşen Location ve Refresh başlıklarının metni yeniden yazılır, ancak HTML, JavaScript veya indirilen dosyalara gömülü URL'ler yazılmaz.
Bir uygulama her yerde mutlak bağlantılar kuruyorsa kalıcı çözüm, proxy üzerinde büyüyen bir yeniden yazma kuralları listesi değil, uygulamanın kendi dış URL yapılandırmasıdır. Çıktı doğru görünene kadar kural eklemek, kimsenin test etmediği ilk sayfada başarısız olan bir yapılandırma üretir. Tek bir doğru uygulama ayarı bütün koleksiyonun yerini alır.
Başlık yeniden yazmanın onaramadığı şeyler
Birkaç komşu sorun yönlendirme sorununa benziyor ama değil. Upstream'e gönderilen Host başlığının backend'in sanal ana bilgisayarıyla eşleşmesi gerekebilir. TLS upstream belirli bir sunucu adı ve sertifika doğrulaması gerektirebilir ve yanıt başlığını yeniden yazmak ikisine de yardımcı olmaz.
Çerez kapsamı ve alan adı öznitelikleri uygulamaya ve onun yapılandırmasına aittir. Proxy gün boyu başlıkları atabilir veya yeniden yazabilir ve yine de ikinci istekte başarısız olan bir oturum üretir, çünkü çerez tarayıcının hiç ziyaret etmediği bir ana bilgisayar için verilmiştir. Bu arıza aralıklı görünür, bu yüzden bilet kuyruğunda bu kadar uzun yaşar. Çerezin alan adını okumak genellikle incelemeyi bir dakikada bitirir.
Kimlik doğrulamayı ve backend seçimini de amaçlanan uygulamayla sınırlı tutun. Genel bir ters proxy, bir uygulamayı sunucunun VPN'i üzerinden sunmalıdır, o ana bilgisayarın ulaşabildiği her özel adrese genel bir geçit olmak yerine. Çağıranın istediği her şeyi ileten tek bir genel location, açılmış tek bir hizmeti özel ağınızın haritasına dönüştürür. Upstream'i açıkça adlandırın ve orada tutun.
İsteğin gittiği sırayla test edin
Üç şeyi sırayla doğrulayın: NGINX amaçlanan location'ı seçti, backend'e isteği tamamladı ve tarayıcı sonraki herhangi bir yönlendirmeyi izleyip alt kaynakları yükledi. Her adımın kendi günlük satırları vardır ve bunları sırayla okumak belirsiz bir 502'yi somut bir bulguya dönüştürür.
İhtiyacınız olan ayrım, başarısız bir upstream bağlantısı ile ulaşılamayan bir özel ada gönderilen tarayıcı arasındadır. Birincisi proxy hata günlüğünde görünür; ikincisi hiç gelmeyen bir istek olarak görünür ve tarayıcı çözemeyeceği bir ana bilgisayardan yakınır. İki farklı sorun, iki farklı dosya ve yalnızca biri proxy_redirect ile ilgilidir.