プロキシー・サーバーのトラブルシューティング

このトピックは、プロキシー・サーバーに関して発生する可能性のある問題の解決に役立ちます。

このタスクの概要

[z/OS]プロキシー・サーバー・エラーがジョブ・ログに記録されます。 ご使用のプロキシー・サーバーで問題が発生した場合は、以下のリストを参照してください。

[AIX Solaris HP-UX Linux Windows][IBM i]プロキシサーバーのエラーは、SystemOut。ログ、proxy.log、 またはlocal.logファイル。 ご使用のプロキシー・サーバーで問題が発生した場合は、 以下のリストを参照してください。

注記：このトピックでは、1 つ以上のアプリケーション サーバー ログ ファイルを参照します。 推奨される別の方法として、分散システムおよび IBM i システムで SystemOut.log、SystemErr.log、trace.log、および activity.log の各ファイルを使用する代わりに、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成することができます。 また、HPEL をネイティブの z/OS ロギング機能と併用することもできます。 HPEL を使用する場合、すべてのログとトレース情報にアクセスするには、サーバー・プロファイルの bin ディレクトリーから、LogViewer コマンド行ツールを使用します。 HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。

手順

  • プロキシ サーバーは正常に作成されましたが、起動できません。
    SYSOUT ファイルでポートの競合について確認してください。 netstat -a コマンドを使用して、プロキシー・サーバーに関連付けられたエンドポイントのうち、既に使用されているものがないか調べてください。 管理コンソールでポートを確認するには、をクリックしてください サーバー > サーバーの種類 > WebSphere プロキシサーバー > サーバー名 > 港。
    UNIX システムで権限のないユーザーとしてプロキシ サーバーを起動しようとして起動に失敗した場合は、ログで次のメッセージを確認してください。
    ChannelFramew E   CHFW0029E: Error initializing chain HTTPS_PROXY_CHAIN because of 
除外、 
com.ibm.wsspi.channel.framework.exception.RetryableChannelException: Permission 
denied
TCPPort       E   TCPC0003E: TCP Channel TCP_7 initialization failed.  The socket 
bind failed for host * and port 80.  The port may already be in use.」
    PROXY_HTTP_ADDRESS および PROXY_HTTPS_ADDRESS トランスポート・チェーンのポートを 1024 より大きな値に変更します。
  • プロキシ サーバーは、管理ポートを介して Web コンテナーに要求をルーティングします。
    プロキシー・サーバーは、いくつかの Web コンテナーの前に配置されます。 構成には、Web コンテナーが 9061、9081、などのデフォルト以外のポートを listen することが必要です。 このシナリオは、新規でさまざまなポートを構成内で使用することを強制する、複数のアプリケーション・サーバーが同じマシン上にある場合のデフォルトのケースです。 このシナリオでプロキシー・サーバーは、期待される 9081 のポートを使用する代わりに、9061 の管理ポートを介して、アプリケーション要求を Web コンテナーへ送付する可能性があります。

    Web コンテナーの listen ポート番号を、ターゲット・アプリケーションと関連付けられた仮想ホストに追加します。 このプロセスにより、プロキシー・サーバーが正しいポート番号を介して Web コンテナーへ要求を送付することが確認されます。

  • プロキシ サーバーは起動しましたが、プロキシ サーバーのエンドポイントを介してアプリケーション リソースにアクセスできません。
    プロキシー・サーバーの エンドポイントが、アプリケーションに関連付けられた仮想ホストの ホスト・エイリアス内にあることを確認します。
  • プロキシ サーバーは別のコア グループにルーティングします。
    セル内のコア・グループ間に コア・グループ・ブリッジが存在するかどうか、およびブリッジとして選択された プロセスが再始動されたかどうかを確認します。 コア・グループの間に ファイアウォールが存在する場合は、コア・グループのブリッジ・トラフィック用の正しいポートが 開かれているかどうかを確認します。
  • プロキシ サーバーは要求を別のセルにルーティングできません。
    コア・グループの ブリッジ設定を確認します。 HMGR0149E エラー・メッセージがいずれかのサーバーに記録されている場合 (通常は、コア・グループ・ブリッジとして機能するサーバー)、 セルのセキュリティー設定を変更して、通信を許可する必要があります。

    複数セル間のセル・セキュリティーの構成について詳しくは、Lightweight Third Party Authentication 鍵のエクスポート に関するトピックを参照してください。

  • プロキシにリクエストを送信すると空白ページが表示されます。
    以下のアクションを考慮してください。
    • 仮想ホストを更新します。 ターゲット・アプリケーションおよびルーティング・ルールが、 プロキシー・サーバーの listen ポート (デフォルトは、HTTP 80、HTTPS 443) を含む 仮想ホストに割り当てられていることを確認します。 プロキシー・サーバーの listen ポートを アプリケーションに追加するか、仮想ホストにルーティング・ルールを追加するか、または proxy_host を 仮想ホストにします。
    • 競合しているプロセスを停止します。 システムを確認し、プロキシサーバーのポート（デフォルト： HTTP 80、 HTTPS 443）を使用する他のプロセス（例： Apache、 IBM® HTTP Server など）が実行されていないことを確認してください。 この問題が発生した場合は、 プロキシー・サーバーは正常に始動するように見えるものの、影響を受けた listen ポートの要求を受信できません。 ご使用のシステムを以下のように確認してください。
      1. プロキシー・サーバーを停止します。
      2. netstat および ps コマンドを使用してシステムに照会し、 問題のプロセスが、プロキシー・サーバーが listen しているポートを使用しているかどうかを判別します。
      3. 問題の原因となっているプロセスが判明した場合は、そのプロセスを停止し、システムが始動する間に そのプロセスが開始しないようにシステムを構成します。
    • プロキシーのルーティングを有効にします。 プロキシー・ルーティングがアプリケーションの Web モジュールに対して有効にされていることを確認します。 デフォルトでは、プロキシー・ルーティングは有効です。 したがって、プロキシーのプロパティーが変更されていない場合は、この解決方法は無視してください。 そうでない場合は、プロキシプロパティの変更方法については 「アプリケーションへのルーティングのカスタマイズ」 を参照してください。
    • 直接要求をテストします。 アプリケーション・サーバーへ直接要求することによって、ターゲット・アプリケーションが インストールされていることを確認します。 応答が受信されなかった場合、 問題はプロキシー・サーバーではなくアプリケーション・サーバーに 存在します。 この場合、アプリケーション・サーバーからの応答を直接受信できる状態にしてから、 プロキシー・サーバーを検証してください。
  • HTTP プロキシサーバーから404（ファイルが見つかりません）エラーを受信しました。
    以下のアクションを考慮してください。
    • 仮想ホストを更新します。 ターゲット・アプリケーションおよびルーティング・ルールが、 プロキシー・サーバーの listen ポート (デフォルトは、HTTP 80、HTTPS 443) を含む 仮想ホストに割り当てられていることを確認します。 プロキシー・サーバーの listen ポートを アプリケーションに追加するか、仮想ホストにルーティング・ルールを追加するか、または proxy_host を 仮想ホストにします。
    • プロキシーのルーティングを有効にします。 プロキシー・ルーティングがアプリケーションの Web モジュールに対して有効にされていることを確認します。 デフォルトでは、プロキシー・ルーティングは有効です。 したがって、プロキシーのプロパティーが変更されていない場合は、この解決方法は無視してください。 そうでない場合は、プロキシプロパティの変更方法については 「アプリケーションへのルーティングのカスタマイズ」 を参照してください。
    • 直接要求をテストします。 アプリケーション・サーバーへ直接要求することによって、ターゲット・アプリケーションが インストールされていることを確認します。 応答が受信されなかった場合、 問題はプロキシー・サーバーではなくアプリケーション・サーバーに 存在します。 この場合、アプリケーション・サーバーからの応答を直接受信できる状態で、 プロキシー・サーバーを検証してください。
  • アプリケーションまたはルーティング ルールに Secure Sockets Layer (SSL) 要求を送信できません。
    アプリケーションの仮想ホストまたはルーティング・ルールに、 プロキシー・サーバーの SSL ポート (デフォルトは 443) のホスト別名が含まれていることを 確認してください。
  • プロキシ サーバーに接続できません...要求がタイムアウトしました。
    競合しているプロセスを停止します。 システムを確認し、プロキシサーバーのポート（デフォルト： HTTP 80、 HTTPS 443）を使用する他のプロセス（例： Apache、 IBM HTTP Server など）が実行されていないことを確認してください。 この状態が発生した場合は、 プロキシー・サーバーは正常に始動するように見えるものの、影響を受けた listen ポートの要求を受信できません。 ご使用のシステムを以下のように確認してください。
    1. プロキシー・サーバーを停止します。
    2. netstat および ps コマンドを使用してシステムに照会し、 問題のプロセスが、プロキシー・サーバーが listen しているポートを使用しているかどうかを判別します。
    3. 問題の原因となっているプロセスが判明した場合は、そのプロセスを停止し、システムが始動する間に そのプロセスが開始しないようにシステムを構成します。
  • HTTP エラーが発生した際（例：404）、エラーページアプリケーションからの応答を受け取れませんでした。
    エラー・ページ URI が正しく 入力されていることを確認してください。 また、HTTP エラー応答をバックエンド・サーバーから 処理している場合は、「Handle remote errors」オプションが選択されていることを 確認してください。 詳細については、 カスタムエラーページポリシーの概要およびプロキシサーバー 設定のカスタムエラーページポリシーセクションを参照してください。
  • プロキシ サーバーをトレースするときに有効にするパッケージは何ですか?
    すべてのトレースに以下のパッケージがすべて必要というわけではありませんが、 特定できない場合は、以下をすべて使用します。
    • *=info
    • WebSphere Proxy=all
    • GenericBNF=all
    • HAManager=all
    • HTTPChannel=all
    • TCPChannel=all
    • WLM*=all
    • DCS=all
    • ChannelFrameworkService=all
    • com.ibm.ws.dwlm.*=all
    • com.ibm.ws.odc.*=all
  • SSL のオン/オフロードを有効にするにはどうすればいいですか?
    SSL のオン/オフ・ロードは、 管理コンソールのトランスポート・プロトコルとして参照されており、 トランスポート・プロトコルは、Web モジュールのプロパティーです。 アプリケーションへのルーティングのカスタマイズを参照して、Webモジュールのプロパティを設定する方法を確認してください。 トランスポート・プロトコルは、 ルーティング・ルールで指定されている汎用サーバー・クラスターに継承されるため、 ルーティング・ルールに対して、SSL のオン/オフ・ロードまたはトランスポート・プロトコル・プロパティーは存在しません。
  • 前にいる場合IBM HTTP Serverまたは Web サーバー プラグインの場合、仮想ホストにポートを追加しなくても済むようにプロキシ サーバーを構成するにはどうすればよいでしょうか?
    プロキシー・サーバーによって、製品が追加するプライベート・ヘッダーなどの、要求に含まれるセキュリティー関連の情報が信頼されるようにするには、プロキシー・サーバーの信頼できるセキュリティー・プロキシー・リストに要求のオリジネーターを追加します。 例えば、 IBM HTTP Serverまたは、プロキシ サーバーに要求をプロキシ サーバーの信頼できるセキュリティ プロキシ リストに送信する Web サーバー プラグイン。 その後、Web サーバー・プラグインは、製品が追加したプライベート・ヘッダー情報を送信することができます。この中には、要求の仮想ホスト情報が含まれています。 Web サーバー・プラグインまたはいずれかのクライアントからのこれらのプライベート・ヘッダーがプロキシーによって信頼されない場合は、プロキシー・サーバーによって、サーバー独自のプライベート・ヘッダーが追加されます。このプライベート・ヘッダーは、プロキシー・サーバーの HTTP ポートと HTTPS ポートを仮想ホストに追加するよう要求します。 一般に、プロキシー・サーバーで Web サーバー・プラグインを使用する場合は、プロキシー・サーバーをバックエンド・サーバーとして使用することを意図しています。 したがって、プロキシー・サーバーのポートを公開せずに済むように、信頼できるセキュリティー・プロキシーとしてプラグインを追加する必要があります。 プラグインからのリクエストをプロキシサーバーにルーティングすることで、 プロキシサーバーと併用するWebサーバープラグインの設定に関する詳細情報が提供されます。 プロキシサーバーの設定では、 信頼できるセキュリティプロキシの設定に関する詳細情報を提供します。
  • プロキシサーバーがストレス下でハングしているように見える、またはffdcに「Too many files open」例外が表示されるか、SystemErr。ログ。
    高い接続負荷の下で、使用可能な数のファイル・システム記述子が使用し尽され、プロキシー・サーバーがソケットを開くことができないために、ハングして、ffdc ディレクトリーまたは SystemError.log ファイル内に「Too Many Files Open」例外をドロップする場合があります。 この問題を軽減するには、オペレーティング・システム・レベルおよびプロキシー・サーバー・レベルで、以下のパラメーターのうち 1 つ以上を変更し、プロキシー・サーバーの接続の使用を最適化します。
    • [Windows]Windows 2003 および XP のオペレーティングシステム調整
      • TcpTimedWaitDelay - TCP/IP がクローズされた接続を解放し、そのリソースを再利用するまでの経過時間を判断します。 クローズと解放との間隔は、TIME_WAIT 状態、またはセグメントの最大存続時間の 2 倍 (2MSL) 状態として知られています。 この期間中は、 新しく接続を確立するよりも、クライアントとサーバーへの接続を再オープンしたほうが、負担が軽くて済みます。 この項目の値を減らすと、TCP/IP はクローズされた接続を迅速に解放して、 より多くのリソースを新しい接続に提供することができます。 実行中のアプリケーションが、接続の迅速な 解放、または新しい接続の作成を必要とする場合、あるいは TIME_WAIT 状態の 接続が多すぎるためにスループットが低い場合は、このパラメーターを調整してください。
        以下のようにして、この値を表示または設定します。
        1. 使用regeditコマンドとアクセスHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parametersレジストリサブキーを使用して、新しいREG_DWORD値を作成します。 TcpTimedWaitDelay。
        2. この値を、16 進数の 0x0000001e に当たる 10 進数の 30 に設定します。 この値は、待ち時間を 30 秒に設定します。
        3. システムを停止して再始動します。
        情報 値
        デフォルト値 0xF0 です。この値は待ち時間を 240 秒 (4 分) に設定します。
        推奨値 最小値は 0x1E で、この値は待ち時間を 30 秒に設定します。
      • MaxUserPort - アプリケーションが使用可能なユーザー・ポートをシステムに要求したときに、 TCP/IP が割り当てることのできる最高のポート番号を決定します。 以下のようにして、この値を表示または設定します。
        1. 使用regeditコマンドにアクセスするHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parametersレジストリサブキーを作成し、新しいREG_DWORD値を作成します。MaxUserPort。
        2. この値を最小でも 10 進数の 32768 に設定します。
        3. システムを停止して再始動します。
        情報 値
        デフォルト値 なし
        推奨値 最小でも 10 進数の 32768。
    • [Linux]Linux® のオペレーティングシステム調整
      • timeout_timewait パラメーター - TCP/IP がクローズされた接続を解放し、 そのリソースを再利用するまでの経過時間を判断します。 クローズと解放との間隔は、TIME_WAIT 状態、またはセグメントの最大存続時間の 2 倍 (2MSL) 状態として知られています。 この期間中は、 新しく接続を確立するよりも、クライアントとサーバーへの接続を再オープンしたほうが、負担が軽くて済みます。 この項目の値を減らすと、TCP/IP はクローズされた接続を迅速に解放して、 より多くのリソースを新しい接続に提供することができます。 実行中のアプリケーションが、接続の迅速な 解放、または新しい接続の作成を必要とする場合、あるいは TIME_WAIT 状態の 接続が多すぎるためにスループットが低い場合は、このパラメーターを調整してください。 timeout_timewait パラメーターを 30 秒に設定する以下のコマンドを発行して、 この値を表示または設定します。
        echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
      • Linuxファイル記述子 (ulimit) - サポートされるオープンファイルの数を指定します。 ほとんどのアプリケーションについては、通常はデフォルト設定のままで十分です。 このパラメーターに設定した値が低すぎると、ファイル・オープン・エラー、メモリー割り振り失敗、 または接続確立エラーが表示される場合があります。

        さまざまなシェルの構文については、UNIX リファレンス ページで ulimit コマンドを確認して、この値を表示または設定します。 KornShell シェル (ksh) で ulimit コマンドを 65535 に設定するには、ulimit -n 65535 コマンドを実行します。 システム・リソースの制限についてすべての現行値を表示するには、ulimit -a コマンドを使用します。

        情報 値
        デフォルト値 1024
        推奨値 65535
    • [AIX]AIX® のオペレーティングシステム調整
      • TCP_TIMEWAIT - TCP/IP がクローズされた接続を解放し、 そのリソースを再利用するまでの経過時間を判断します。 クローズと解放との間隔は、TIME_WAIT 状態、またはセグメントの最大存続時間の 2 倍 (2MSL) 状態として知られています。 この期間中は、 新しく接続を確立するよりも、クライアントとサーバーへの接続を再オープンしたほうが、負担が軽くて済みます。 この項目の値を減らすと、TCP/IP はクローズされた接続を迅速に解放して、 より多くのリソースを新しい接続に提供することができます。 実行中のアプリケーションが、接続の迅速な 解放、または新しい接続の作成を必要とする場合、あるいは TIME_WAIT 状態の 接続が多すぎるためにスループットが低い場合は、このパラメーターを調整してください。 TCP_TIMEWAIT 状態を 15 秒に設定する以下のコマンドを発行して、 この値を表示または設定します。
        /usr/sbin/no -o tcp_timewait =1
      • AIXファイル記述子 (ulimit) - 許可されるオープンファイルの数を指定します。 ほとんどのアプリケーションについては、通常はデフォルト設定のままで十分です。 このパラメーターに設定した値が低すぎると、ファイルを開いたとき、または接続を確立したときに エラーが発生し、メモリー割り振りエラーが表示される場合があります。 防止するためにWebSphere® Application Serverリソース不足を防ぐために、ユーザーがログインしているユーザーアカウントのリソースの上限（ulimit）を削除します。 WebSphere Application Serverプロセスが実行されます。
        以下のように ulimit 設定を変更して、 この値を表示または設定します。
        1. コマンド・ウィンドウを開きます。
        2. タイプsmitty users開くAIX設定プログラム。
        3. ユーザーの「Change」または「Show Characteristics」を選択します。
        4. ユーザーアカウントの名前を入力します。 WebSphere Application Server実行されます。
        5. Enter キーを押します。
        6. 以下の設定値を指示された値に変更します。
          情報 値
          Soft FILE Size -1
          Soft CPU Time -1
          Soft STACK Size -1
          Soft CORE File Size -1
          Hard FILE Size -1
          Hard CPU Time -1
          Hard STACK Size -1
          Hard CORE File Size -1
        7. Enter キーを押して、変更を保存します。
        8. ログアウトし、ご使用のアカウントでログインします。
        9. 製品を再始動します。
        情報 値
        デフォルト値 2000
        推奨値 unlimited
    • [HP-UX]HP-UX のオペレーティングシステム調整

      HP-UX nfile カーネル・パラメーター - 指定された時刻にシステム上で開くことができるファイルの最大数を指定します。 十分に大きな数値を指定しないと、システムの処理能力が制限されます。

      HP-UX ninode カーネル・パラメーター - メモリーに存在できる、開いている inode の最大数を指定します。 開いている inode は、固有のオープン・ファイルそれぞれに関連付けられています。 このため、ninode パラメーターに指定する値は、同時に開いておく必要がある固有のファイルの数より大きくする必要があります。

    • [Solaris]Solarisのオペレーティングシステム調整
      • Solaris ファイル記述子 (ulimit) - サポートされるオープン・ファイルの数を指定します。 このパラメーターに指定した値が小さすぎると、ファイル・オープン・エラー、メモリー割り振り障害、または接続確立エラーが表示される場合があります。 さまざまなシェルの構文については、UNIX リファレンス ページで ulimit コマンドを確認して、この値を表示または設定します。
        • システム・リソースに対するすべての制限の現行値を表示するには、ulimit -a コマンドを使用します。
        • KornShell シェル (ksh) で ulimit コマンドを 65535 に設定するには、ulimit -n 65535 コマンドを実行します。
        • プロセスで開くことができるファイルの最大数は、グローバルなカーネル制限の rlim_fd_max 設定および rlim_fd_cur 設定によっても影響されます。 /etc/system ファイルのこれらの設定の値を増やす必要がある場合があります。
        Solaris 10 は、カーネル・パラメーターの設定のための新しい手段を提供します。 Solaris 10 のファイル記述子のカーネル・パラメーターの最大数に新しい制限を指定するには、以下のコマンドのいずれかを発行します。
        1. 現在のシェル・セッションの値を変更するには、以下のコマンドを実行します。
          prctl -n process.max-file-descriptor -r -v 65535 $$
        2. 変更をシステム全体に適用するには、以下のコマンドを実行します。
          projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)'
system

          このコマンドを発行すると、すべてのユーザーの設定、およびすべてのプロジェクトが変更されるため、注意が必要です。

        3. ユーザー root によって所有されるすべてのプロジェクトの値を変更するには、以下のコマンドを実行します。
          projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)'
user.root
        4. 非 root ユーザーによって所有されるすべてのプロジェクトの値を変更するには、以下のコマンドを実行します。
          projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)'
user.username
      • TCP_TIME_WAIT_INTERVAL - クローズされた接続制御ブロックを保持しておく時間を TCP/IP に 通知します。 アプリケーションが TCP/IP 接続を完了すると、指定された時間だけ制御ブロックが保持されます。 接続率が高い場合は、TCP/IP 接続のバックログ分が多くなり、サーバーのパフォーマンスが低下します。 特定のピーク期間に、サーバーが停止することがあります。 サーバーが停止した場合、netstat コマンドを使用すると、HTTP サーバーに対して オープンされたソケットの多くが、CLOSE_WAIT または FIN_WAIT_2 状態になっていることが分かります。 目に見える 遅延が最大で 4 分間にもわたって発生する場合があり、 その間サーバーは応答をまったく送信しませんが、 システム・プロセスのアクティビティー全体での CPU 使用率は高い状態のままです。
        この値を表示または設定するには、get コマンドを使用して現在の間隔を判別し、set コマンドを使用して間隔を 30 秒に指定します。 例:
        ndd -get /dev/tcp tcp_time_wait_interval     
ndd -set /dev/tcp tcp_time_wait_interval 30000
        情報 値
        デフォルト値 240000 ミリ秒、つまり 4 分です。
        推奨値 60000 ミリ秒
    • プロキシー・サーバー調整
      • パーシスタント要求 - パーシスタント要求とは、 既存の TCP 接続を使用して送信される要求です。 TCP 接続を使用してクライアントから受信される要求の数を増やすことにより、 パフォーマンスを最大化できます。 この値は、Web ページ +1 の、例えば GIF などの 組み込みオブジェクトの最大数を表します。

        この値は、管理 WebSphere Application Server コンソールで をクリックして表示 サーバー > プロキシサーバー > サーバー名 > プロキシサーバーのトランスポート > HTTP_PROXY_CHAIN/HTTPS_PROXY_CHAINまたは設定できます。

        情報 値
        デフォルト値 100
        推奨値 Web ページ + 1 に組み込まれるオブジェクトの最大数を表す値。
      • アウトバウンド接続プール・サイズ - プロキシー・サーバーはターゲット・サーバーへの アウトバウンド接続をプールし、プールに常駐する接続の数は構成可能です。 接続のプールが使い尽くされたか、または空の場合は、 プロキシー・サーバーによってターゲット・サーバーへの新規接続が作成されます。 並行負荷が高い場合は、 パフォーマンスを最適化するために、接続のプール・サイズは、 予想される並行クライアント負荷の値まで増やす必要があります。

        この値は、 WebSphere Application Server 管理コンソールで 「サーバー 」 ＞ 「プロキシサーバー 」＞「サーバー名 」＞「 プロキシサーバーのトランスポート 」＞「 HTTP プロキシサーバーの設定 」をクリックして表示または設定できます。 「コンテンツ・サーバー接続」セクションで、 「サーバーあたりの最大接続数」フィールドの値を接続するクライアント数の予想最大数より 大きな値にします。 変更を保存し、プロキシー・サーバー・ノードにその変更を同期化し、プロキシー・サーバーを再始動します。

        情報 値
        推奨値 並行するクライアントの予想される負荷と整合する値
      • アウトバウンド要求タイムアウト - 多くの場合、プロキシー・サーバーがフロントとなっている バックエンド・アプリケーション・サーバーの負荷は高く、応答時間が適切ではありません。したがって、 プロキシー・サーバー上の接続が、バックエンド・アプリケーション・サーバーからの応答の待機のために 拘束される可能性があります。 ターゲット・サーバーからの応答をプロキシー・サーバーが 待機する時間を構成することにより、この状態を軽減します。 これが、アウトバウンド要求タイムアウト値です。 プロキシー・サーバーが、低速なバックエンド・アプリケーション・サーバーを待機する時間を 管理することにより、接続が解放されて速度が向上し、他の要求を処理するために接続を 使用できるようになります。
        この値は、管理コンソールで 「サーバー 」＞「 サーバーの種類 」＞「 WebSphere プロキシサーバー 」＞「 プロキシサーバー名 」＞「 HTTP プロキシサーバー設定 」をクリックして表示または設定できます。 「コンテンツ・サーバー接続」セクションで、 アウトバウンド要求のタイムアウトの値をクライアントの視点から許容できる応答時間を表す値に 設定します。
        情報 値
        デフォルト値 120
        推奨値 クライアントの視点から許容できる応答時間を表す値。