Errore proxy 502 “Motivo: errore durante la lettura dal server remoto” con Apache 2.2.3 (Debian) mod_proxy e Jetty 6.1.18

Apache sta ricevendo richieste al porto: 80 e le sta inoltrando al molo al porto: 8080

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

Il mio dilemma: tutto funziona normalmente normalmente (richieste veloci, richieste di pochi secondi o poche decine di secondi vengono elaborate ok ). Si verificano problemi quando l'elaborazione della richiesta richiede molto tempo (pochi minuti?).

Se invio invece la richiesta direttamente al molo alla porta: 8080 la richiesta viene elaborata OK. Quindi è probabile che il problema si collochi da qualche parte tra Apache e Jetty dove sto usando mod_proxy . Come risolverlo?

Ho già provato alcuni "trucchi" relativi alle impostazioni di KeepAlive, senza fortuna. Ecco la mia configurazione attuale, qualche suggerimento?

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

Ecco anche il registro di debug da una richiesta non riuscita:

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

Ho risolto il problema Il Keepalive=Ondeve essere inserito in ProxyPasslinea di configurazione:

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

Guarda quello

Keepalive=On

Là? È fondamentale;)

Hai provato a impostare setenv proxy-initial-not-pooled 1?

Riferimento qui

Questo errore può verificarsi anche se non si termina l'URL del proxy con a /. Entrambi i percorsi dovrebbero terminare con un /o nessuno dei due.

Guardando il registro, c'è qualcosa che scade in 5 minuti (= 300 secondi). È un tempo piuttosto lungo per aspettare una risposta. Quando si accede direttamente al server Jetty, questa risorsa impiega davvero tanto tempo a produrre una risposta?

Se i cinque minuti rientrano davvero nei tempi di risposta possibili, è possibile provare a modificare la direttiva di configurazione ProxyTimeout.

A seconda della configurazione della tua rete, potrebbe anche non esserci motivo per provare a utilizzare un sistema keepalive (esiste un firewall tra l'app server e il proxy che potrebbe essere configurato per eliminare sessioni inattive per troppo tempo?) , ma ProxyTimeout influirebbe sul comportamento del proxy stesso.

Se lo stesso proxy serve anche altri back-end, sarebbe meglio mantenere l'attuale ProxyTimeout e configurare il timeout nella direttiva ProxyPass (consultare la documentazione mod_proxy).

Se, tuttavia, le risposte senza proxy sono costantemente qualcosa di molto inferiore ai cinque minuti che vedono qui come limite di interruzione, allora potrebbero esserci davvero delle strane interferenze tra il proxy e il server delle app, ma non stai fornendo nulla di valore per identificare ciò che potrebbe essere.

Per me la rimozione di un valore di intestazione chiamato Transfer-Encoding" (binary)nella mia app server (PHP) ha risolto il problema per:

[proxy_http: errore] [pid 17623] (22) Argomento non valido: [client 127.0.0.1:44929] AH01102: errore durante la lettura della riga di stato dal server remoto 0.0.0.0:80

Tutti gli altri suggerimenti piacciono SetEnv proxy-initial-not-pooledo Keep-Aliveno.

Se le soluzioni di cui sopra non funzionano, una cosa che puoi provare è abilitare tutti i tuoi moduli apache per assicurarti che non ci sia qualche modulo di cui hai bisogno che in qualche modo sia stato disabilitato accidentalmente.

Ad esempio, come ho trovato la causa del mio problema è stato quello di sostituire tutte le istanze di #LoadModule con LoadModule in tutti i miei file di configurazione di Apache. Dal momento che ciò ha risolto il problema per me, quindi ho saputo che il mio problema non era un argomento della direttiva "KeepAlive" mancante, ma piuttosto, il mio problema era una dipendenza mancante.

Perché, ricorda, i file .so sono sostanzialmente librerie statiche. Avere un modulo abilitato non significa che verrà utilizzato, ma averne uno disabilitato significa che non può essere utilizzato e, pertanto, tutto ciò che dipende da esso fallirà necessariamente.

Nota: questa risposta ha ricevuto alcuni voti negativi a causa del fatto che la mia risposta iniziale sembrava suggerire di lasciare tutti i moduli abilitati, per sempre. Anche se teoricamente potresti farlo senza necessariamente rompere nulla, ovviamente non è una soluzione delle migliori pratiche.

Quindi, per favore, capisci, sto semplicemente suggerendo questo come un passaggio per la risoluzione dei problemi, non una soluzione finale.

Inoltre, tieni presente che utilizzo uno speciale progetto git per tracciare tutti i file di configurazione apache della mia macchina locale. In questo modo posso eseguire questo tipo di operazioni globali di ricerca e sostituzione nella mia directory di lavoro di configurazione di apache, come fase di risoluzione dei problemi. Se l'abilitazione di tutti i moduli ha esito positivo, prova a disabilitarli di nuovo uno a uno e a riavviare apache nel mezzo, fino a trovare il modulo che deve rimanere abilitato. Dopo averlo capito, ripristina il repository allo stato originale e abilita solo quel modulo che deve rimanere abilitato.

Scoprirai anche che usare git per tracciare i tuoi file di configurazione di apache ripulisce quelle directory, dato che non avrai più bisogno di quei file .bak e .default vecchio stile.