Vraag Proxy Error 502 "Reason: Error reading from remote server" met Apache 2.2.3 (Debian) mod_proxy en Jetty 6.1.18


Apache ontvangt aanvragen op poort: 80 en stuurt ze naar Jetty op poort: 8080

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

Mijn dilemma: Alles werkt goed normaal gesproken (snelle verzoeken, enkele seconden of enkele tientallen seconden lang worden aanvragen verwerkt OK). Problemen voorkomen wanneer het verwerken van aanvragen lang duurt (paar minuten?).

Als ik in plaats daarvan een verzoek doe direct naar Jetty in poort: 8080 het verzoek wordt op OK verwerkt. Dus het probleem is waarschijnlijk om ergens te zitten tussen Apache en Jetty waar ik gebruik mod_proxy. Hoe dit op te lossen?

Ik heb al wat "trucs" geprobeerd gerelateerd aan KeepAlive-instellingen, zonder geluk. Hier is mijn huidige configuratie, eventuele suggesties?

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

Hier is ook het foutopsporingslogboek van een mislukt verzoek:

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

72
2017-09-29 17:35


oorsprong


Hallo .. Ik zit nog steeds vast aan deze. Alle bovenstaande instellingen hebben geprobeerd en ook het verhogen van de steiger maxIdleTime heeft niet geholpen. Alle tips wat te proberen volgende? - Martin


antwoorden:


Ik heb het probleem opgelost. De Keepalive=On moet worden ingevoegd in ProxyPass config regel:

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

Zie dat

Keepalive=On

er? Het is van cruciaal belang;)


81
2018-02-18 22:27



Ik geloof dat je je eigen antwoorden als Geaccepteerd kunt markeren. Het markeert de vraag als opgelost in het systeem voor andere mensen om te vinden. - sysadmin1138♦
Waar zet je dit precies in? - AlxVallejo
@AlxVallejo Je configuratiebestanden moeten hier worden gevonden /etc/apache2/sites-enabled/[sitename].conf - Steven
We hebben precies dezelfde proxy-fouten. Ze gebeuren zeer zelden (één op duizend verzoeken). Waarom precies dat is Keepalive=On kritisch? - dokaspar
Zou het niet de timeout=600 of retry=1 dat lost dit in plaats daarvan op? (of de combinatie) - MattBianco


Heb je instellingen geprobeerd? setenv proxy-initial-not-pooled 1?

Referentie hier


4
2017-09-29 17:46



Nee, dit heeft niet geholpen. Dan gaat het niet om de race-conditie, het gaat om de lange vertraging en er gebeurt iets tussendoor (een soort misverstand tussen Jetty en mod_proxy).


Deze fout kan ook optreden als u uw proxy-URL niet beëindigt met een /. Beide paden moeten eindigen met een / of geen van beide.


3
2018-06-14 23:37





Als je naar het logboek kijkt, is er iets dat na 5 minuten (= 300 seconden) verdwijnt. Dat is behoorlijk lang wachten op een reactie. Wanneer u rechtstreeks toegang krijgt tot de Jetty-server, duurt dit middel dan zo lang om een ​​reactie te produceren?

Als de vijf minuten echt binnen mogelijke reactietijden liggen, kunt u proberen de configuratierichtlijn van ProxyTimeout aan te passen.

Afhankelijk van uw netwerkconfiguratie, kan het goed zijn dat er geen reden is om zelfs maar een keepalive-systeem te gebruiken (is er een firewall tussen de app-server en proxy die kan worden geconfigureerd om sessies te laten die te lang inactief zijn?) , maar de ProxyTimeout zou het gedrag van de proxy zelf beïnvloeden.

Als dezelfde proxy ook andere backends ondersteunt, is het beter om de huidige ProxyTimeout te behouden en de time-out in de ProxyPass-richtlijn te configureren (zie documentatie mod_proxy).

Als de antwoorden zonder de proxy echter altijd iets veel minder zijn dan de vijf minuten, zie je hier de limiet voor uitsluiting, dan is er mogelijk sprake van een vreemde interferentie tussen de proxy en de app-server, maar je levert niets van waarde voor het identificeren van wat het zou kunnen zijn.


1
2017-10-10 18:51



"Wanneer u de Jetty-server rechtstreeks benadert, duurt deze resource dan echt zo lang om een ​​reactie te produceren?" -- JA. Ik heb ook geprobeerd om deze ProxyTimeout in te stellen op 600. Helpt niet. Er is geen firewall tussen proxy en steiger. Time-out is ook geconfigureerd in ProxyPass.
"u geeft niets van waarde om te identificeren wat het zou kunnen zijn": ik weet niet wat dat zou kunnen zijn. Alles wat ik krijg is een foutmelding van de server: Proxy-fout De proxyserver ontving een ongeldig antwoord van een upstream-server. De proxyserver kon het verzoek GET / niet aan. Reden: Fout bij lezen van externe server
Wat betreft het verhogen van de proxy-timeout, veranderde dit ook de tijd die uw browser heeft gehad voordat hij de 502-fout kreeg?
Vervolgens naar manieren waarop u kunt achterhalen wat er op de toepassingsserver gebeurt: u kunt enkele thread-dumps nemen en van daaruit bekijken wat wordt uitgevoerd wanneer de browser wacht. U kunt ook voldoende foutopsporingsloginstructies toevoegen om uw code te traceren om de oorzaak van traagheid te achterhalen.
Ik weet waarom het langzaam is. Ik weet niet waarom apache proxy het antwoord weigert als het eindelijk klaar is.


Voor mij het verwijderen van een header-waarde genoemd Transfer-Encoding" (binary) in mijn server-app (PHP) loste het probleem op voor:

[proxy_http: error] [pid 17623] (22) Ongeldig argument: [client   127.0.0.1:44929] AH01102: statusregel voor foutlezing van externe server 0.0.0.0:80

Alle andere suggesties zoals SetEnv proxy-initial-not-pooled of Keep-Alive deed niet.


0
2018-05-21 12:27





Als de bovenstaande oplossingen niet werken, kun je proberen al je apachemodules in te schakelen om ervoor te zorgen dat er niet een module is die je op de een of andere manier per ongeluk hebt uitgeschakeld.

Bijvoorbeeld, hoe ik de oorzaak van mijn probleem ontdekte, was dat ik alle instanties van #LoadModule met LoadModule in al mijn Apache-configuratiebestanden moest vervangen. Omdat dit het probleem voor mij oploste, wist ik dat mijn probleem geen ontbrekend "KeepAlive" -richtlijnargument was, maar eerder dat mijn probleem een ​​ontbrekende afhankelijkheid was.

Omdat, onthoud, .so-bestanden zijn in wezen statische bibliotheken. Het hebben van een module betekent niet dat het zal wennen, maar een uitgeschakeld hebben betekent dat het niet kan wennen, en daarom zal alles wat ervan afhangt onvermijdelijk falen.

Opmerking: dit antwoord heeft een aantal down-stemmen gekregen vanwege het feit dat mijn eerste antwoord leek te suggereren dat alle modules voor altijd moeten worden ingeschakeld. Hoewel je dat theoretisch zou kunnen doen zonder iets noodzakelijkerwijs te breken, is het duidelijk geen oplossing met beste praktijken.

Dus, begrijp alsjeblieft, ik suggereer dit alleen als een stap voor probleemoplossing, geen definitieve oplossing.

Merk ook op: ik gebruik een speciaal git-project om alle apache-configuratiebestanden van mijn lokale machine bij te houden. Op die manier kan ik dit soort globale zoek-en-vervang operaties doen in mijn apache config werkdirectory, als een stap voor probleemoplossing. Als het inschakelen van alle modules is gelukt, probeer dan ze een voor een uit te schakelen en de apache tussendoor opnieuw te starten, totdat je weet welke module het moet blijven. Als je dat eenmaal hebt bedacht, reset je de repo opnieuw naar de oorspronkelijke staat en schakel je alleen die ene module in die ingeschakeld moet blijven.

Je zult ook merken dat het gebruik van git om je apache-configuratiebestanden bij te houden, die mappen opschoont, omdat je die ouderwetse .bak- en .default-bestanden niet meer nodig hebt.


-1
2017-12-24 09:56



elke bibliotheek heeft een andere functie, niet noodzakelijk gerelateerd aan proxy - Arnold Roa