Вопрос: Ошибка прокси-сервера 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:::

71
2017-09-29 17:35


Источник


Привет .. Я все еще придерживаюсь этого. Все вышеприведенные настройки пытались, а также увеличение максимума приманок maxIdleTime не помогло. Любые указатели, что попробовать дальше? - Martin


Ответы:


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

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

Видеть, что

Keepalive=On

там? Это важно;)


81
2018-02-18 22:27



Я считаю, что вы можете пометить свои собственные ответы как Accepted. Он отмечает вопрос, который разрешен в системе для других людей. - sysadmin1138♦
Ты святой! Спасибо!! : D - sova
Где именно вы это положили? - AlxVallejo
@AlxVallejo Здесь вы должны найти свои конфигурационные файлы /etc/apache2/sites-enabled/[sitename].conf - Steven
У нас точно такие же ошибки прокси. Они случаются очень редко (одна тысяча запросов). Зачем именно это Keepalive=On критическим? - dokaspar


Вы пробовали настройку setenv proxy-initial-not-pooled 1?

Справка Вот


4
2017-09-29 17:46



Нет, это не помогло. Тогда речь идет не о состоянии гонки, это долгая задержка, и что-то происходит между ними (какое-то недоразумение между Jetty и mod_proxy).


Эта ошибка также может возникнуть, если вы не закончите свой URL-адрес прокси с помощью /, Либо оба пути должны заканчиваться / или нет.


3
2018-06-14 23:37





Глядя на журнал, есть что-то, что истекает через 5 минут (= 300 секунд). Это довольно долго ждать ответа. Когда вы напрямую обращаетесь к серверу Jetty, действительно ли этот ресурс занимает много времени, чтобы дать ответ?

Если пять минут действительно находятся в пределах возможных откликов, вы можете попробовать настроить конфигурационную конфигурацию ProxyTimeout.

В зависимости от вашей настройки сети вполне может быть, что нет причин даже пытаться использовать любую систему keepalive (есть ли межсетевой экран между сервером приложений и прокси-сервером, который может быть настроен на то, что вы слишком долго не выполняете длительные сеансы?) , но ProxyTimeout повлияет на поведение самого прокси.

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

Если, однако, ответы без прокси-сервера являются последовательно чем-то гораздо меньшим, чем пять минут, рассматриваемых здесь как предел отсечки, тогда действительно могут быть некоторые нечетные помехи между прокси-сервером и сервером приложений, но вы не предоставляете ничего из значение для определения того, что это может быть.


0
2017-10-10 18:51



«Когда вы напрямую обращаетесь к серверу Jetty, действительно ли этот ресурс занимает столько времени, чтобы дать ответ?» -- ДА. Я также попытался установить этот ProxyTimeout на 600. Не помогает. Между прокси-сервером и причалом нет брандмауэра. Тайм-аут настроен также в ProxyPass.
«вы не предоставляете ничего полезного для определения того, что это может быть»: я не знаю, что это может быть. Все, что я получаю, это сообщение об ошибке с сервера: Ошибка прокси-сервера Прокси-сервер получил неверный ответ от восходящего сервера. Прокси-сервер не смог обработать запрос GET /. Причина: Ошибка чтения с удаленного сервера
Что касается увеличения тайм-аута прокси-сервера, это также изменило время, в течение которого ваш браузер работал, прежде чем получить ошибку 502?
Затем, чтобы узнать, что происходит на сервере приложений: вы можете взять пару дампов потоков и посмотреть, что происходит, когда браузер ждет. В качестве альтернативы добавьте достаточное количество протоколов ведения журнала отладки, чтобы отслеживать ваш код, чтобы определить причину медленности.
Я знаю, почему это медленно. Я не знаю, почему apache proxy отказывается от ответа, когда он наконец готов.


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

[proxy_http: error] [pid 17623] (22) Недопустимый аргумент: [клиент   127.0.0.1:44929] AH01102: строка состояния считывания ошибок с удаленного сервера 0.0.0.0:80

Все другие предложения, такие как SetEnv proxy-initial-not-pooled или Keep-Alive не.


0
2018-05-21 12:27





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

Например, как я нашел причину моей проблемы, было заменить все экземпляры #LoadModule на LoadModule во всех моих конфигурационных файлах Apache. Поскольку это решило проблему для меня, поэтому я знал, что моя проблема не была отсутствующим аргументом директивы «KeepAlive», но, скорее, моя проблема была отсутствующей зависимостью.

Потому что, помните, файлы .so - это в основном статические библиотеки. Наличие модуля не означает, что он будет использоваться, но наличие одного отключенного означает, что он не может привыкнуть, и поэтому все, что от него зависит, обязательно не удастся.

Примечание: этот ответ получил несколько голосов из-за того, что мой первоначальный ответ, казалось, предлагал оставить все модули включенными навсегда. Хотя теоретически вы можете сделать это, не нарушая ничего, это, очевидно, не лучшее решение.

Поэтому, пожалуйста, поймите, я просто предлагаю это как шаг устранения неполадок, а не окончательное решение.

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

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


-1
2017-12-24 09:56



каждая библиотека приносит другую функцию, необязательно связанную с прокси-сервером - Arnold Roa