Error de proxy 502 "Motivo: error al leer desde el servidor remoto" con Apache 2.2.3 (Debian) mod_proxy y Jetty 6.1.18

Apache recibe solicitudes en el puerto: 80 y las envía por proxy a Jetty en el puerto: 8080

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

Mi dilema: todo funciona bien normalmente (las solicitudes rápidas, pocos segundos o pocas decenas de segundos se procesan bien ). Se producen problemas cuando el procesamiento de la solicitud tarda mucho (¿unos minutos?).

Si, en cambio, emito una solicitud directamente a Jetty en el puerto: 8080, la solicitud se procesa correctamente. Por lo tanto, es probable que el problema se encuentre en algún lugar entre Apache y Jetty donde estoy usando mod_proxy . ¿Cómo resolver esto?

Ya he probado algunos "trucos" relacionados con la configuración de KeepAlive, sin suerte. Aquí está mi configuración actual, ¿alguna sugerencia?

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

Aquí también está el registro de depuración de una solicitud fallida:

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

He resuelto el problema. El Keepalive=Ondebe insertarse en la ProxyPasslínea de configuración:

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

Mira eso

Keepalive=On

¿ahí? Esto es crítico ;)

¿Has intentado configurar setenv proxy-initial-not-pooled 1?

Referencia aquí

Este error también puede ocurrir si no finaliza su URL de proxy con un /. Ambas rutas deben terminar con una /o ninguna.

Mirando el registro, hay algo que se agota a los 5 minutos (= 300 segundos). Es un tiempo bastante largo para esperar una respuesta. Cuando accede al servidor Jetty directamente, ¿este recurso realmente tarda tanto en producir una respuesta?

Si los cinco minutos realmente están dentro de los tiempos de respuesta posibles, puede intentar ajustar la directiva de configuración ProxyTimeout.

Dependiendo de la configuración de su red, es posible que no haya razón para intentar usar un sistema keepalive (¿hay un firewall entre el servidor de aplicaciones y el proxy que podría configurarse para abandonar las sesiones que están inactivas durante demasiado tiempo?) , pero ProxyTimeout afectaría el comportamiento del proxy en sí.

Si el mismo proxy también sirve a otros servidores, sería mejor mantener el ProxyTimeout actual y configurar el tiempo de espera en la directiva ProxyPass (consulte la documentación de mod_proxy).

Sin embargo, si las respuestas sin el proxy son consistentemente algo mucho menor que los cinco minutos que se ven aquí como el límite de corte, entonces podría haber alguna interferencia extraña entre el proxy y el servidor de aplicaciones, pero no está proporcionando nada de valor para identificar lo que podría ser.

Para mí, eliminar un valor de encabezado llamado Transfer-Encoding" (binary)en mi servidor-aplicación (PHP) resolvió el problema para:

[proxy_http: error] [pid 17623] (22) Argumento no válido: [cliente 127.0.0.1:44929] AH01102: error al leer la línea de estado del servidor remoto 0.0.0.0:80

Todas las demás sugerencias gustaron SetEnv proxy-initial-not-pooledo Keep-Aliveno.

Si las soluciones anteriores no funcionan, una cosa que puede intentar es habilitar todos sus módulos de apache para asegurarse de que no haya algún módulo que necesite que de alguna manera se deshabilitó accidentalmente.

Por ejemplo, cómo encontré la causa de mi problema fue reemplazar todas las instancias de #LoadModule con LoadModule en todos mis archivos de configuración de Apache. Como eso resolvió el problema para mí, por lo tanto, sabía que mi problema no era un argumento de la directiva "KeepAlive" que faltaba, sino que mi problema era una dependencia que faltaba.

Porque, recuerde, los archivos .so son básicamente bibliotecas estáticas. Tener un módulo habilitado no significa que se usará, pero tener uno deshabilitado significa que no se puede usar y, por lo tanto, cualquier cosa que dependa de él necesariamente fallará.

Nota: esta respuesta ha recibido algunos votos negativos debido al hecho de que mi respuesta inicial parecía sugerir dejar todos los módulos habilitados, para siempre. Si bien, en teoría, podría hacerlo sin necesariamente romper nada, obviamente no es una solución de mejores prácticas.

Entonces, por favor, comprenda, simplemente sugiero esto como un paso de solución de problemas, no como una solución final.

Además, tenga en cuenta: uso un proyecto git especial para rastrear todos los archivos de configuración de apache de mi máquina local. De esa manera, puedo hacer este tipo de operaciones globales de búsqueda y reemplazo en mi directorio de trabajo de configuración de apache, como un paso de solución de problemas. Si la habilitación de todos los módulos tiene éxito, intente deshabilitarlos nuevamente uno por uno y reinicie apache en el medio, hasta que encuentre qué módulo es el que debe permanecer habilitado. Una vez que lo hayas resuelto, restablece el repositorio a su estado original y solo habilita ese módulo que necesita permanecer habilitado.

También encontrará que el uso de git para rastrear sus archivos de configuración de apache limpia esos directorios, ya que ya no necesitará esos archivos .bak y .default antiguos.