Помилка проксі-сервера 502 "Причина: Помилка читання з віддаленого сервера" з модулем Apache 2.2.3 (Debian) mod_proxy та Jetty 6.1.18

Apache отримує запити в порт: 80 і надає їм доступ до Jetty в порту: 8080

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

Моя дилема: все працює нормально (швидкі запити, декілька секунд або кілька десятків секунд запити обробляються нормально ). Проблеми виникають, коли обробка запиту займає багато часу (кілька хвилин?).

Якщо я надсилаю запит замість Jetty безпосередньо в порт: 8080 запит обробляється ОК. Тому проблема, ймовірно, сидить десь між Apache та Jetty, де я використовую mod_proxy . Як це вирішити?

Я вже спробував декілька "хитрощів", пов’язаних із налаштуваннями KeepAlive, без удачі. Ось моя поточна конфігурація, якісь пропозиції?

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

Ось також журнал налагодження з невдалого запиту:

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

Я вирішив проблему. Keepalive=OnПовинен бути вставлений в ProxyPassконфігурації лінії:

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

Бачиш це

Keepalive=On

там? Це критично;)

Ви пробували налаштування setenv proxy-initial-not-pooled 1?

Довідка тут

Ця помилка також може виникнути, якщо ви не закінчите URL-адресу проксі-сервера /. Або обидва шляхи повинні закінчуватися /ані, і ні.

Дивлячись на журнал, щось відбувається за 5 хвилин (= 300 секунд). Досить довго чекати відповіді. Коли ви безпосередньо отримуєте доступ до сервера Jetty, чи дійсно цьому ресурсу потрібно так довго, щоб отримати відповідь?

Якщо п’ять хвилин дійсно знаходяться в межах можливого часу відповіді, ви можете спробувати налаштувати директиву конфігурації ProxyTimeout.

Залежно від налаштування вашої мережі, можливо, немає ніяких причин навіть намагатися використовувати будь-яку систему keepalive (чи є брандмауер між сервером додатків та проксі, який може бути налаштований на те, щоб занадто довго відмовляти від сеансів у режимі очікування?) , але ProxyTimeout вплине на поведінку самого проксі.

Якщо той же проксі також обслуговує інші перешкоди, було б краще зберегти поточний ProxyTimeout та налаштувати тайм-аут у директиві ProxyPass (див. Документацію mod_proxy).

Якщо, однак, відповіді без проксі-сервісу постійно щось набагато менше, ніж п’ять хвилин розглядають тут як обмежувальну межу, то між проксі-сервером та сервером додатків дійсно може бути якесь дивне втручання, але ви нічого не надаєте значення для визначення того, що це може бути.

Для мене видалення значення заголовка, викликаного Transfer-Encoding" (binary)в моєму додатку сервера (PHP), вирішило проблему для:

[proxy_http: помилка] [pid 17623] (22) Неправильний аргумент: [клієнт 127.0.0.1:24929] AH01102: помилка читання рядка стану з віддаленого сервера 0.0.0.0:80

Всі інші пропозиції подобалися SetEnv proxy-initial-not-pooledчи Keep-Aliveні.

Якщо вищезгадані рішення не спрацьовують, можна спробувати одне - ввімкнути всі ваші модулі apache, щоб переконатися у відсутності потрібного модуля, який якимось чином випадково вимкнувся.

Наприклад, як я виявив причину моєї проблеми, було замінити всі екземпляри #LoadModule на LoadModule у всіх моїх конфігураційних файлах Apache. Оскільки це вирішило проблему для мене, тому я знав, що моя проблема не є відсутнім аргументом директиви "KeepAlive", а, скоріше, моєю проблемою була відсутність залежності.

Тому що, пам’ятайте, .so файли - це в основному статичні бібліотеки. Якщо увімкнути модуль, це не означає, що він звикне, але те, що він відключений, означає, що він не може звикнути, а отже, все, що від нього залежить, обов'язково вийде з ладу.

Примітка: ця відповідь отримала кілька голосів у зв'язку з тим, що мої початкові відповіді пропонують залишити всі модулі ввімкненими назавжди. Хоча теоретично ви могли це зробити, не обов'язково нічого порушуючи, це, очевидно, не найкраще рішення.

Отже, будь ласка, зрозумійте, я просто пропоную це як крок усунення несправностей, а не остаточне рішення.

Крім того, зверніть увагу: я використовую спеціальний проект git для відстеження всіх конфігураційних файлів apache моєї локальної машини. Таким чином я можу робити такі види глобальних операцій пошуку та заміни в робочому каталозі apache config, як крок усунення несправностей. Якщо ввімкнення всіх модулів успішно, спробуйте відключити їх знову один за одним і перезавантажте апаш між ними, поки ви не знайдете, який саме модуль повинен залишатися включеним. Після того, як ви це зрозуміли, поверніть репо до його початкового стану і ввімкніть лише той модуль, який повинен залишатися ввімкненим.

Ви також виявите, що за допомогою git для відстеження ваших конфігураційних файлів apache очищає ці каталоги, оскільки ті старі старомодні файли .bak та .default вже не знадобляться.