web-dev-qa-db-fra.com

Erreur de proxy 502 "Raison: erreur de lecture à partir du serveur distant" avec Apache 2.2.3 (Debian) mod_proxy et Jetty 6.1.18

Apache reçoit des demandes au port: 80 et les envoie par procuration à Jetty au port: 8080

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

Mon dilemme: Tout fonctionne correctement normalement (les requêtes rapides, quelques secondes ou quelques dizaines de secondes sont traitées ok ). Des problèmes se produisent lorsque le traitement des demandes prend du temps (quelques minutes?).

Si j'émets une demande à la place directement à Jetty au port: 8080, la demande est traitée correctement. Le problème est donc susceptible de se situer quelque part entre Apache et Jetty où j'utilise mod_proxy. Comment résoudre ça?

J'ai déjà essayé quelques "trucs" liés aux paramètres de KeepAlive, sans chance. Voici ma configuration actuelle, des suggestions?

#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 [email protected]

    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>

Voici également le journal de débogage d'une requête qui échoue:

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:::
apache-2.2jetty
82
Martin

J'ai résolu le problème. Le Keepalive=On doit être inséré dans la ligne de configuration ProxyPass:

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

Regarde ça

Keepalive=On

là? C'est critique ;)

96
Martin

Avez-vous essayé de définir setenv proxy-initial-not-pooled 1?

Référence ici

5
TCampbell

Cette erreur peut également se produire si vous ne mettez pas fin à votre URL proxy avec un /. Soit les deux chemins doivent se terminer par un / ou ni l'un ni l'autre.

4
Mark

En regardant le journal, il y a quelque chose qui expire au bout de 5 minutes (= 300 secondes). C'est un temps assez long pour attendre une réponse. Lorsque vous accédez directement au serveur Jetty, cette ressource prend-elle vraiment autant de temps pour produire une réponse?

Si les cinq minutes sont vraiment dans les temps de réponse possibles, vous pouvez essayer de peaufiner la directive de configuration ProxyTimeout.

Selon la configuration de votre réseau, il se pourrait bien qu'il n'y ait aucune raison d'essayer d'utiliser un système Keepalive (existe-t-il un pare-feu entre le serveur d'applications et le proxy qui pourrait être configuré pour supprimer les sessions inactives pendant trop longtemps?) , mais le ProxyTimeout affecterait le comportement du proxy lui-même.

Si le même proxy sert également d'autres backends, il serait préférable de conserver le ProxyTimeout actuel et de configurer le timeout dans la directive ProxyPass (voir la documentation de mod_proxy).

Si, cependant, les réponses sans le proxy sont toujours quelque chose de beaucoup moins que les cinq minutes considérées ici comme la limite de coupure, alors il peut y avoir vraiment une interférence étrange entre le proxy et le serveur d'application, mais vous ne fournissez rien de valeur pour identifier ce que cela pourrait être.

1
user56707

Pour moi, la suppression d'une valeur d'en-tête appelée Transfer-Encoding" (binary) dans mon application serveur (PHP) a résolu le problème pour:

[proxy_http: erreur] [pid 17623] (22) Argument non valide: [client 127.0.0.1.144929] AH01102: erreur de lecture de la ligne d'état du serveur distant 0.0.0.0:80

Toutes les autres suggestions comme SetEnv proxy-initial-not-pooled ou Keep-Alive non.

0
stackoverclan

Si les solutions ci-dessus ne fonctionnent pas, vous pouvez essayer d'activer tous vos modules Apache pour vous assurer qu'aucun module dont vous avez besoin n'a été désactivé accidentellement.

Par exemple, la façon dont j'ai trouvé la cause de mon problème était de remplacer toutes les instances de #LoadModule par LoadModule dans tous mes fichiers de configuration Apache. Comme cela a résolu le problème pour moi, je savais donc que mon problème n'était pas un argument de directive "KeepAlive" manquant, mais plutôt que mon problème était une dépendance manquante.

Parce que, rappelez-vous, les fichiers .so sont essentiellement des bibliothèques statiques. Avoir un module activé ne signifie pas qu'il sera utilisé, mais en avoir un désactivé signifie qu'il ne peut pas être utilisé, et donc, tout ce qui en dépend échouera nécessairement.

Remarque: cette réponse a reçu quelques votes négatifs en raison du fait que ma réponse initiale semblait suggérer de laisser tous les modules activés, pour toujours. Bien que vous puissiez théoriquement le faire sans nécessairement casser quoi que ce soit, ce n'est évidemment pas une solution de meilleure pratique.

Donc, veuillez comprendre, je suggère simplement cela comme une étape de dépannage, pas une solution finale.

Veuillez également noter: j'utilise un projet git spécial pour suivre tous les fichiers de configuration Apache de ma machine locale. De cette façon, je peux effectuer ces sortes d'opérations globales de recherche et de remplacement dans mon répertoire de travail de configuration Apache, comme étape de dépannage. Si l'activation de tous les modules réussit, essayez de les désactiver à nouveau un par un et de redémarrer Apache entre les deux, jusqu'à ce que vous trouviez le module qui doit rester activé. Une fois que vous avez compris cela, réinitialisez le référentiel à son état d'origine et activez uniquement le module qui doit rester activé.

Vous constaterez également que l'utilisation de git pour suivre vos fichiers de configuration Apache nettoie ces répertoires, car vous n'aurez plus besoin de ces fichiers .bak et .default à l'ancienne.

0
CommaToast