Proxy Error 502 “Sebep: Uzak sunucudan okuma hatası”, Apache 2.2.3 (Debian) mod_proxy ve Jetty 6.1.18 ile

Apache: 80 numaralı limanda istek alıyor ve bunları: 8080 numaralı limanda Jetty'ye vekalet ediyor

The proxy server received an invalid response from an upstream server
The proxy server could not handle the request GET /.

İkilemim: Her şey normal şekilde çalışıyor (hızlı istekler, birkaç saniye veya birkaç on saniye uzunluğundaki istekler tamam işleniyor ). İstek işleme uzun sürdüğünde (birkaç dakika?) Sorunlar oluşur .

Bunun yerine isteği olursa doğrudan limanında İskelesi: 8080 isteği Tamam işlenir. Bu yüzden sorun mod_proxy kullandığım Apache ve Jetty arasında bir yere oturmak olasıdır . Bu nasıl çözülür?

Şanssız, KeepAlive ayarları ile ilgili bazı "püf noktaları" denedim . İşte mevcut konfigürasyonum, herhangi bir öneriniz var mı?

#keepalive Off                     ## I have tried this, does not help
#SetEnv force-proxy-request-1.0 1  ## I have tried this, does not help
#SetEnv proxy-nokeepalive 1        ## I have tried this, does not help
#SetEnv proxy-initial-not-pooled 1 ## I have tried this, does not help
KeepAlive 20                       ## I have tried this, does not help
KeepAliveTimeout 600               ## I have tried this, does not help
ProxyTimeout 600                   ## I have tried this, does not help

NameVirtualHost *:80
<VirtualHost _default_:80>
    ServerAdmin webmaster@mydomain.fi

    ServerName www.mydomain.fi

    ServerAlias mydomain.fi mydomain.com mydomain www.mydomain.com

    ProxyRequests On
    ProxyVia On
    <Proxy *>
            Order deny,allow
            Allow from all
    </Proxy>

    ProxyRequests Off
    ProxyPass / http://www.mydomain.fi:8080/ retry=1 acquire=3000 timeout=600
    ProxyPassReverse / http://www.mydomain.fi:8080/

    RewriteEngine On
    RewriteCond %{SERVER_NAME} !^www\.mydomain\.fi
    RewriteRule /(.*) http://www.mydomain.fi/$1 [redirect=301L]

    ErrorLog /var/log/apache2/error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog /var/log/apache2/access.log combined
    ServerSignature On

</VirtualHost>

Ayrıca, başarısız bir istekten gelen hata ayıklama günlüğü:

74.125.43.99 - - [29/Sep/2010:20:15:40 +0300] "GET /?wicket:bookmarkablePage=newWindow:com.mydomain.view.application.reports.SaveReportPage HTTP/1.1" 502 355 "https://www.mydomain.fi/?wicket:interface=:0:2:::" "Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10"
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: error reading status line from remote server www.mydomain.fi, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: Error reading from remote server returned by /, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::

Sorunu çözdüm. Keepalive=OnEklenmesi gereken ProxyPassyapılandırma hattı:

ProxyPass / http://www.dom.fi:8080/ retry=1 acquire=3000 timeout=600 Keepalive=On

Şuna bak

Keepalive=On

Orada? Kritik ;)

Ayarı denediniz setenv proxy-initial-not-pooled 1mi?

Buraya referans

Bu hata, proxy url'nizi a ile sonlandırmazsanız da oluşabilir /. Her iki yol da bir /veya hiçbiriyle bitmemelidir.

Kayıtlara bakıldığında, 5 dakikada (= 300 saniye) zaman aşımına uğrayan bir şey var. Cevap beklemek çok uzun bir zaman. Jetty sunucusuna doğrudan eriştiğinizde, bu kaynağın yanıt vermesi gerçekten bu kadar uzun sürüyor mu?

Beş dakika gerçekten olası yanıt süreleri içindeyse, ProxyTimeout yapılandırma yönergesini değiştirmeyi deneyebilirsiniz.

Ağ kurulumunuza bağlı olarak, herhangi bir kalıcı sistem bile kullanmaya çalışmanızın bir nedeni olmayabilir (uygulama sunucusu ile proxy arasında çok uzun süre boşta kalan oturumları bırakacak şekilde yapılandırılmış bir güvenlik duvarı var mı?) , ancak ProxyTimeout, proxy'nin davranışını etkiler.

Aynı proxy diğer arka uçlara da hizmet veriyorsa, geçerli ProxyTimeout ürününü korumak ve ProxyPass yönergesinde zaman aşımını yapılandırmak daha iyi olur (mod_proxy belgelerine bakın).

Bununla birlikte, proxy olmayan yanıtlar sürekli olarak kesme sınırı olarak görülen beş dakikadan daha az bir şeyse, proxy ile uygulama sunucusu arasında gerçekten garip bir girişime neden olabilir, ancak ne olabileceğini belirlemek için değer.

Transfer-Encoding" (binary)Benim için benim sunucu-app (PHP) denilen bir başlık değerini kaldırmak için sorunu çözdü:

[proxy_http: error] [pid 17623] (22) Geçersiz tartışma: [istemci 127.0.0.1:44929] AH01102: uzak sunucudan durum satırını okuma hatası 0.0.0.0:80

Diğer tüm öneriler gibi SetEnv proxy-initial-not-pooledveya Keep-Aliveyapmadım.

Yukarıdaki çözümler işe yaramazsa, deneyebileceğiniz bir şey, tüm apache modüllerinin bir şekilde yanlışlıkla devre dışı bırakılması gereken bir modül olmadığından emin olmak için etkinleştirmektir.

Örneğin, sorunumun nedenini nasıl bulduğumu, tüm Apache yapılandırma dosyalarımdaki tüm #LoadModule örneklerini LoadModule ile değiştirmek oldu. Bu benim için sorunu çözdüğünden beri, sorunumun eksik bir "KeepAlive" yönergesel argümanı olmadığını biliyordum, fakat benim sorunum eksik bir bağımlılıktı.

Çünkü, unutmayın, .so dosyaları temelde statik kütüphanelerdir. Bir modülün etkin hale getirilmesi, bunun kullanılacağı anlamına gelmez, ancak birinin devre dışı bırakılması, kullanılamayacağı anlamına gelir ve bu nedenle, ona bağlı olan herhangi bir şey mutlaka başarısız olur.

Not: Bu cevabım, ilk cevabımın tüm modülleri sonsuza dek açık bırakmayı önerdiğini düşündüğü için bazı oylar aldı. Teorik olarak bunu hiçbir şeyi kırmadan yapabilecek olsanız da, kesinlikle en iyi uygulama çözümü değil.

Bu yüzden, lütfen anlayın, bunu yalnızca bir sorun giderme adımı olarak öneriyorum, nihai bir çözüm değil.

Ayrıca, lütfen dikkat: Yerel makinemin apache yapılandırma dosyalarını izlemek için özel bir git projesi kullanıyorum. Bu şekilde, apache config çalışma dizinimdeki bu tür genel arama ve değiştirme işlemlerini bir sorun giderme adımı olarak yapabilirim. Tüm modüllerin etkinleştirilmesi başarılı olursa, bunları birer birer devre dışı bırakmayı ve aralarında apache'yi yeniden başlatmayı deneyin; hangi modülün etkin kalması gerektiğini bulana kadar. Bunu anladıktan sonra, repoyu orijinal durumuna geri getirin ve yalnızca etkin kalması gereken bir modülü etkinleştirin.

Ayrıca, apache config dosyalarınızı izlemek için git kullanmanın bu dizinleri temizlediğini göreceksiniz, çünkü artık eski moda .bak ve .default dosyalarına ihtiyaç duymayacaksınız.