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] ）。リクエストの処理に時間がかかると（数分？）問題が発生します。

代わりに、ポート：8080でJetty に直接リクエストを発行すると、リクエストは正常に処理されます。そのため、問題はmod_proxyを使用しているApacheとJettyの間のどこかにある可能性があります。これを解決するには？

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サーバーに直接アクセスする場合、このリソースは応答を生成するのに本当に時間がかかりますか？

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

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

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

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

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でした。

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

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

なぜなら、.soファイルは基本的に静的ライブラリだからです。モジュールを有効にすると、モジュールが使用可能になるわけではありませんが、モジュールを無効にすると、使用できなくなるため、それに依存するモジュールは必ず失敗します。

注：私の最初の答えは、すべてのモジュールを永久に有効にしておくことを示唆しているように思われたため、この答えはいくつかのダウン票を受け取りました。必ずしも何かを壊すことなく理論的にはできますが、明らかにベストプラクティスのソリューションではありません。

したがって、これはトラブルシューティングの手順として提案するものであり、最終的な解決策ではないことをご理解ください。

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

また、古い形式の.bakファイルと.defaultファイルが不要になるため、gitを使用してapache設定ファイルを追跡すると、これらのディレクトリがクリーンアップされることがわかります。