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

81

Apache reçoit les demandes au port 80 et les envoie à 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 très bien normalement (demandes rapides, quelques secondes ou quelques dizaines de secondes demandes longues sont traitées ok ). Des problèmes surviennent lorsque le traitement d'une demande prend beaucoup de temps (quelques minutes?).

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

J'ai déjà essayé quelques "astuces" relatives aux paramètres KeepAlive, sans succès. 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 en échec:

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

la source
Salut .. Je suis toujours coincé avec celui-ci. Tous les paramètres ci-dessus ont essayé et l'augmentation de jetty maxIdleTime n'a pas aidé. Quels sont les indicateurs à essayer ensuite?
Martin

Réponses:

91

J'ai résolu le problème. Le Keepalive=Ondevrait être inséré dans la ProxyPassligne de configuration:

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

Regarde ça

Keepalive=On

Là? C'est critique ;)

Martin
la source
9
Je crois que vous pouvez marquer vos propres réponses comme acceptées. Cela marque la question comme résolue dans le système pour que les autres personnes puissent la trouver.
sysadmin1138
Où mettez-vous cela exactement?
AlxVallejo
1
@AlxVallejo Vous devriez trouver vos fichiers de configuration ici /etc/apache2/sites-enabled/[sitename].conf
Steven
1
Nous avons exactement les mêmes erreurs de proxy. Elles se produisent très rarement (une demande sur mille). Pourquoi est-ce si Keepalive=Oncritique?
dokaspar
Ne pourrait-ce pas être le timeout=600ou retry=1qui corrige cela à la place? (ou le combo)
MattBianco le
4

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

Référence ici

TCampbell
la source
Non, ça n'a pas aidé. Ensuite, il ne s'agit pas d'une condition de concurrence critique, mais d'un long délai et d'un événement intermédiaire (une sorte de malentendu entre Jetty et mod_proxy).
4

Cette erreur peut également se produire si vous ne terminez pas votre URL de proxy avec un /. Les deux chemins doivent se terminer par un /ou aucun.

marque
la source
1

En regardant le journal, il y a quelque chose qui expire au bout de 5 minutes (= 300 secondes). C'est assez long d'attendre une réponse. Lorsque vous accédez directement au serveur Jetty, cette ressource est-elle si longue à 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.

En fonction de la configuration de votre réseau, il se peut qu’il n’y ait aucune raison d’essayer même d’utiliser un système keepalive (existe-t-il un pare-feu entre le serveur d’applications et le proxy pouvant être configuré pour abandonner trop longtemps les sessions inactives?) , mais ProxyTimeout affecterait le comportement du proxy lui-même.

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

Si, toutefois, les réponses sans proxy sont toujours nettement inférieures aux cinq minutes (voir limite limite), il se peut qu'il y ait une certaine interférence entre le proxy et le serveur d'applications, mais vous ne fournissez rien. valeur pour identifier ce que cela pourrait être.


la source
"Lorsque vous accédez directement au serveur Jetty, cette ressource prend-elle vraiment autant de temps pour produire une réponse?" -- OUI. J'ai également essayé de définir ce paramètre ProxyTimeout sur 600. Cela n'aide en rien. Il n'y a pas de pare-feu entre proxy et jetée. Le délai d'attente est également configuré dans ProxyPass.
"vous ne fournissez rien de précieux pour identifier ce que cela pourrait être": je ne sais pas ce que cela pourrait être. Tout ce que je reçois est un message d'erreur du serveur: Erreur de proxy Le serveur proxy a reçu une réponse non valide d'un serveur en amont. Le serveur proxy n'a pas pu gérer la requête GET /. Raison: erreur de lecture du serveur distant
En ce qui concerne l'augmentation du délai d'attente du proxy, cela a-t-il également modifié l'heure à laquelle votre navigateur a tourné avant d'obtenir l'erreur 502?
Ensuite, vous trouverez des moyens de savoir ce qui se passe sur le serveur d’applications: vous pouvez effectuer quelques vidages de threads et consulter ce qu’ils exécutent lorsque le navigateur est en attente. Vous pouvez également ajouter suffisamment d'instructions de journalisation de débogage pour pouvoir tracer votre code afin de déterminer la cause de la lenteur.
Je sais pourquoi c'est lent. Je ne sais pas pourquoi le proxy Apache refuse la réponse quand il est enfin prêt.
0

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:44929] AH01102: erreur lors de la lecture de la ligne d'état du serveur distant 0.0.0.0:80

Toutes les autres suggestions aiment SetEnv proxy-initial-not-pooledou Keep-Aliven'ont pas.

stackoverclan
la source
0

Si les solutions ci-dessus ne fonctionnent pas, vous pouvez essayer d’activer tous vos modules Apache pour vous assurer qu’il n’ya pas un module dont vous avez besoin qui a été désactivé par inadvertance.

Par exemple, la cause de mon problème était de remplacer toutes les instances de #LoadModule par LoadModule dans tous mes fichiers de configuration Apache. Puisque 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 un problème de dépendance manquante.

Car, 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é. Par conséquent, 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 rien casser, ce n’est évidemment pas une solution de meilleure pratique.

Alors, s'il vous plaît comprendre, je suggère simplement cela comme une étape de dépannage, pas une solution finale.

Veuillez également noter que j'utilise un projet spécial git pour suivre tous les fichiers de configuration apache de ma machine locale. De cette façon, je peux effectuer ce type d'opérations de recherche et de remplacement globales dans mon répertoire de travail apache config, en tant qu'étape de dépannage. Si l'activation de tous les modules réussit, essayez à nouveau de les désactiver un par un et de redémarrer apache entre-deux, jusqu'à ce que vous trouviez quel module il doit rester activé. Une fois que vous avez compris, remettez le repo dans 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'avez plus besoin de ces fichiers démodés .bak et .default.

CommaToast
la source
1
chaque bibliothèque apporte une fonctionnalité différente, pas nécessairement liée au proxy
Arnold Roa