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


80

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:::

Selam .. Hala buna sıkışıp kaldım. Yukarıdaki ayarların tümü denendi ve ayrıca artan iskele maxIdleTime yardımcı olmadı. Herhangi bir işaretçi ne denemek için?
Martin

Yanıtlar:


91

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 ;)


9
Kendi cevaplarınızı Kabul edildi olarak işaretleyebileceğinizi düşünüyorum. Soruyu, sistemin diğer insanların bulması için çözüldüğü gibi işaretler.
sysadmin1138

Bunu tam olarak nereye koydun?
AlxVallejo

1
@AlxVallejo Sen /etc/apache2/sites-enabled/[sitename].conf buradan yapılandırma dosyaları bulmak gerekir
Steven

1
Tam olarak aynı proxy hatalarımız var. Çok nadir görülürler (binde bir talepte). Bu tam olarak neden Keepalive=Onkritik?
dokaspar

Değil olabilir timeout=600veya retry=1bu yerine giderir? (veya açılan)
MattBianco

4

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

Buraya referans


Hayır, bu yardımcı olmadı. O zaman bu yarış durumu ile ilgili değil, uzun gecikme ve arada bir şeyler oluyor (Jetty ve mod_proxy arasında bir tür yanlış anlama).

4

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


1

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.


"Jetty sunucusuna doğrudan eriştiğinizde, bu kaynağın yanıt vermesi gerçekten bu kadar uzun sürüyor mu?" -- EVET. Bu ProxyTimeout ürününü 600 olarak ayarlamayı da denedim. Proxy ve jetty arasında hiçbir güvenlik duvarı yoktur. Zaman aşımı, ProxyPass'ta da yapılandırılmıştır.

“Ne olabileceğini tanımlamak için değerli hiçbir şey sağlamıyorsun”: Ne olabileceğini bilmiyorum. Tek alıyorum sunucudan bir hata mesajı: Proxy Hatası Proxy sunucusu bir yukarı akış sunucusundan geçersiz bir yanıt aldı. Proxy sunucusu, GET / isteğini gerçekleştiremedi. Sebep: Uzak sunucudan okuma hatası

Proxy zaman aşımını artırmaya gelince, bu, 502 hatasını almadan önce tarayıcınızın dönüş zamanını da değiştirdi mi?

Ardından, uygulama sunucusunda neler olup bittiğini nasıl öğrenebileceğinize dair yollar: birkaç iş parçacığı dökümü alabilir ve tarayıcı beklerken nelerin yürütüleceğini görebilirsiniz. Alternatif olarak, yavaşlığın nedenini tam olarak belirlemek için kodunuzu izleyebilecek kadar hata ayıklama günlüğü ifadeleri ekleyin.

Neden yavaş olduğunu biliyorum. Apache proxy'nin nihayet hazır olduğunda yanıtı neden reddettiğini bilmiyorum.

0

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.


0

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.


1
Her kütüphane, vekaleten yakından ilgili olmayan, farklı bir özellik getirir
Arnold Roa,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.