Ошибка прокси 502 “Причины: Ошибка, читающая из удаленного сервера” с Apache 2.2.3 (Debian) mod_proxy и Причал 6.1.18
Вы могли упростить путем предотвращения старых двухпортовых протоколов FTP (FTP и FTPS). Под чем я подразумеваю, который является, что при использовании SFTP так как он использует единственный конвейер (в отличие от типичного FTP), затем Вы могли использовать ЛЮБОЙ прокси-сервер, чтобы сделать задание за исключением того, что Вы наклоняетесь, действительно осуществляют сниффинг трафика потому что его зашифрованный.
Для моего ответа я сказал бы для рассмотрения этого: http://frox.sourceforge.net/
Вы попытались установить setenv proxy-initial-not-pooled 1?
Сошлитесь здесь
-
1Нет, это не помогло. Затем это не о состоянии состязания, это - длительная задержка, и что-то происходит промежуточное (некоторое недоразумение между Причалом и mod_proxy). – 29 September 2010 в 22:47
При рассмотрении журнала существует что-то, что испытывает таймаут в 5 минут (=300 секунд). Это - довольно долгое время для ожидания ответа. При доступе к Гагатовому серверу непосредственно этот ресурс действительно занимает у этого много времени для создания ответа?
Если эти пять минут действительно в течение возможного времени отклика, Вы могли бы попытаться настроить конфигурационную директиву ProxyTimeout.
В зависимости от Вашей сетевой установки могло бы хорошо случиться так, что нет никакой причины даже попытаться использовать какую-либо систему проверки активности (там брандмауэр между сервером приложений и прокси, который мог бы быть настроен для отбрасывания сессий, которые неактивны слишком долго?), но ProxyTimeout влиял бы на поведение самого прокси.
Если бы тот же прокси также служит другим бэкендам, было бы лучше сохранить текущий ProxyTimeout и настроить тайм-аут в директиве ProxyPass (см. mod_proxy документацию).
Если, однако, ответы без прокси последовательно - что-то намного меньше, чем эти пять минут видят здесь как предел сокращения, то могла бы действительно быть некоторая нечетная интерференция между прокси-сервером и сервером приложений, но Вы не обеспечиваете ничего значения для идентификации, каково это могло бы быть.
-
1, "При доступе к Гагатовому серверу непосредственно, этот ресурс, действительно занимает у этого много времени для создания ответа?" - ДА. Я также пытался установить этот ProxyTimeout на 600. Не помогает. Нет никакого брандмауэра между прокси и причалом. Тайм-аут настроен также в ProxyPass. – 11 October 2010 в 15:39
-
2"Вы не обеспечиваете ничего значения для идентификации, каково это могло бы быть": Я не знаю, каково это могло быть. Все, что я получаю, является сообщением об ошибке с сервера: Ошибка Прокси прокси-сервер получила недопустимый ответ от вышестоящего сервера. Прокси-сервер не мог обработать запрос, ДОБИРАЮТСЯ/. Причина: Ошибка, читающая из Бойкого удаленного сервера – 11 October 2010 в 15:40
Эта ошибка также может возникнуть, если в конце URL-адреса прокси-сервера не указано / . Либо оба пути должны заканчиваться / , либо ни одним из них.
Для меня удаление значения заголовка под названием Transfer-Encoding "(двоичный) в моем серверном приложении (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 нет.
Если вышеперечисленные решения не работают, то можно попробовать включить все ваши apache-модули, чтобы убедиться, что нет нужного вам модуля, который каким-то образом случайно отключился.
Например, как я нашёл причину своей проблемы, я заменил все экземпляры #LoadModule на LoadModule во всех моих конфигурационных файлах Apache. Так как это решило проблему за меня, то я знал, что моя проблема не в отсутствующем аргументе директивы "KeepAlive", а скорее в отсутствующей зависимости.
Потому что, помните, .so файлы в основном являются статическими библиотеками. Включение модуля не означает, что он будет использоваться, но его отключение означает, что он не может быть использован, и, следовательно, все, что зависит от него, обязательно не будет работать. Замечание: этот ответ получил несколько голосов вниз из-за того, что в моем первоначальном ответе казалось, что я предлагаю оставить все модули включенными, навсегда. Хотя теоретически это можно сделать, не ломая ничего, но очевидно, что это не лучшее решение.
Так что, пожалуйста, поймите, я просто предлагаю это в качестве шага по устранению неполадок, а не как окончательное решение.
Также, пожалуйста, обратите внимание: я использую специальный git-проект для отслеживания всех конфигурационных файлов apache на моей локальной машине. Таким образом, я могу выполнять такого рода глобальные операции поиска и замены в рабочей директории моего конфигурационного файла apache, в качестве шага поиска и устранения неисправностей. Если включение всех модулей прошло успешно, то попробуйте отключить их снова один за другим и перезапустить apache между ними, пока не найдёте, какой именно модуль должен оставаться включённым. Как только вы это выясните, затем сбросьте репо обратно в исходное состояние, и включите только тот модуль, который должен остаться включенным.
Вы также обнаружите, что использование git'а для отслеживания конфигурационных файлов apache очищает эти каталоги, так как вам не понадобятся эти старые...создал .bak и .файлы по умолчанию.