web-dev-qa-db-ja.com

Apache 2.2.3（Debian）mod_proxyおよびJetty 6.1.18でのプロキシエラー502「理由：リモートサーバーからの読み取りエラー」

Apacheはポート：80でリクエストを受信し、ポート：8080でJettyにプロキシしています

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

私のジレンマ：すべてが正常に動作します通常（速いリクエスト、数秒または数十秒の長いリクエストが処理されますok）。 問題occurリクエスト処理に時間がかかる場合（数分？）.

代わりにリクエストを発行する場合直接Jettyのポート：8080でリクエストは正常に処理されますしたがって問題はlikely私が使用している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 [email protected]

    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:::
apache-2.2jetty
82
Martin

私は問題を解決しました。 Keepalive=OnをProxyPass構成行に挿入する必要があります：

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

ほら

Keepalive=On

そこ？それは重要です;）

96
Martin

設定してみましたかsetenv proxy-initial-not-pooled 1？

参照 ここ

5
TCampbell

このエラーは、プロキシURLを/で終了していない場合にも発生する可能性があります。両方のパスが/で終わるか、どちらでもないかのどちらかです。

4
Mark

ログを見ると、5分（= 300秒）でタイムアウトするものがあります。これは、応答を待つのにかなり長い時間です。 Jettyサーバーに直接アクセスする場合、このリソースが応答を生成するのに本当に長い時間がかかりますか？

5分が実際に可能な応答時間内にある場合は、ProxyTimeout構成ディレクティブを微調整してみてください。

ネットワークの設定によっては、キープアライブシステムを使用する理由さえない可能性があります（アプリサーバーとプロキシの間にファイアウォールがあり、アイドル状態が長すぎるセッションをドロップするように構成されている可能性がありますか？）ただし、ProxyTimeoutはプロキシ自体の動作に影響します。

同じプロキシが他のバックエンドにもサービスを提供する場合は、現在のProxyTimeoutを維持し、ProxyPassディレクティブでタイムアウトを構成することをお勧めします（mod_proxyのドキュメントを参照）。

ただし、プロキシを使用しない応答が一貫して5分未満である場合は、ここでカットオフ制限と見なされます。プロキシとアプリサーバーの間に奇妙な干渉がある可能性がありますが、何も提供していません。それが何であるかを識別するための値。

1
user56707

私のサーバーアプリ（PHP）でTransfer-Encoding" (binary)というヘッダー値を削除すると、次の問題が解決しました。

[proxy_http：error] [pid 17623]（22）Invalid argument：[client 127.0.0.1:44929] AH01102：error reading status line from remote server 0.0.0.0:80

SetEnv proxy-initial-not-pooledやKeep-Aliveなどの他のすべての提案はそうしませんでした。

0
stackoverclan

上記の解決策が機能しない場合は、すべてのApacheモジュールを有効にして、必要なモジュールが誤って無効にされていないことを確認することができます。

たとえば、私の問題の原因を見つける方法は、すべてのApache構成ファイルで#LoadModuleのすべてのインスタンスをLoadModuleに置き換えることでした。これで問題が解決したので、「KeepAlive」ディレクティブの引数が欠けているのではなく、依存関係が欠けていることが問題であることがわかりました。

覚えておいてください。soファイルは基本的に静的ライブラリです。モジュールを有効にしても使用できるわけではありませんが、無効にすると使用できなくなるため、それに依存するものは必ず失敗します。

注：私の最初の回答では、すべてのモジュールを永久に有効にしておくことを提案しているように見えたため、この回答にはいくつかの反対票がありました。理論的には必ずしも何も壊さずにそれを行うことができますが、明らかにベストプラクティスソリューションではありません。

したがって、理解してください。これは、最終的なソリューションではなく、トラブルシューティングの手順として提案するだけです。

また、注意してください：私は特別なgitプロジェクトを使用して、ローカルマシンのすべてのApache構成ファイルを追跡しています。こうすることで、トラブルシューティングの手順として、Apache config作業ディレクトリでこの種のグローバルな検索と置換操作を実行できます。すべてのモジュールの有効化が成功した場合は、モジュールを1つずつ無効にして、その間にApacheを再起動し、有効にする必要があるモジュールを見つけます。それを理解したら、リポジトリを元の状態にリセットし、有効にしておく必要があるモジュールのみを有効にします。

また、gitを使用してApache構成ファイルを追跡すると、これらのディレクトリがクリーンアップされます。これは、古い.bakファイルや.defaultファイルが不要になるためです。

0
CommaToast