404 Unable to identify proxy for host: and url:

症状

API 呼び出しのレスポンスで、クライアントアプリケーションが HTTP ステータスコード 404、"Not Found" というメッセージ、"Unable to identify proxy for host: and url: " というエラーメッセージが返されます。

このエラーメッセージは、Edge が指定の仮想ホストとパスで API プロキシを検出できなかったことを意味します。

エラーメッセージ

次の HTTP ステータスコードが返されます。

HTTP/1.1 404 Not Found

また、次のようなエラーメッセージが表示されます。

    {
       "fault":{
          "faultstring":"Unable to identify proxy for host: default and url: \/oauth2\/token",
          "detail":{
             "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
          }
       }
    }

上のエラーメッセージは、Edge が "default" 仮想ホストと "/oauth2/token" パスで API プロキシを検出できなかったことを意味します。

考えられる原因

このエラーの原因としては、次のような原因が考えられます。

原因	説明	トラブルシューティング手順の適用対象
API プロキシが特定の仮想ホストに関連付けられていない	特定の API プロキシが、エラーメッセージにある VirtualHost でリクエストを受信するように構成されていません。	Edge Public Cloud と Private Cloud のユーザー
パスが API プロキシに関連付けられていない	特定の API プロキシが、エラーメッセージにあるパスでリクエストを受信するように構成されていません。	Edge Public Cloud と Private Cloud のユーザー
API プロキシが環境にデプロイされていない	特定の API プロキシが、API リクエストを行う環境にデプロイされていません。	Edge Public Cloud と Private Cloud のユーザー
環境が Message Processor に読み込まれていない	エラーのため、特定の環境（API リクエストを行う環境）が Message Processor に読み込まれていません。	Edge Private Cloud ユーザー
API プロキシが Message Processor にデプロイされていない	デプロイ時にイベント通知がないため、API プロキシが Message Processor にデプロイされていません。	Edge Private Cloud ユーザー

原因: API プロキシが特定の仮想ホストに関連付けられていない

特定の仮想ホストに対するリクエストを受信するように API プロキシが構成されていない場合、404 Not Found というレスポンスと "Unable to identify proxy for host: and url: " といエラーメッセージを受信する場合があります。

診断

API プロキシのプロキシエンドポイントの構成を確認し、エラーで示された仮想ホストに対するリクエストを受信するように API プロキシが構成されていることを確認します。これは VirtualHost 要素で確認できます。次のプロキシエンドポイント構成のサンプルを見てください。 このサンプルでは、API プロキシが安全な仮想ホストのリクエストを受け入れることがわかります。

仮想ホストは、特定の環境で次のように定義されます。

名前	ポート	ホストのエイリアス
default	80	myorg-prod.apigee.net
secure	443	myorg-prod.apigee.net

URL http://myorg-prod.apigee.net/weather を使用して、default 仮想ホストに API リクエストを送信します。
上の例のように、プロキシエンドポイントに "default" 仮想ホストがありません。このため、404 レスポンスと次のエラーメッセージが返されます。
```
{"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
```
下の解決策に進み、この問題の解決方法を確認します。
"default" 仮想ホストでリクエストを受信するようにプロキシエンドポイントを構成している場合は、次の原因（パスが API プロキシに関連付けられていない）に進みます。

解決策

不足している VirtualHost をプロキシエンドポイントの構成に追加し、問題を解決します。
1. 上のサンプルで、プロキシエンドポイントの構成に次のようにデフォルトの仮想ホストを追加します。
```
<VirtualHost>default</VirtualHost>
    
```
  デフォルトの仮想ホストが追加されたプロキシエンドポイント構成のサンプル
上の例で、特定の API プロキシで安全な VirtualHost のみを使用する場合は、次のように https プロトコルを使用して安全な VirtualHost にのみ API リクエストを送信します。
```
https://myorg-prod.apigee.net/weather
```

原因: パスが API プロキシに関連付けられていない

API リクエスト URL で使用されているパスに対するリクエストを受信するように API プロキシが構成されていない場合、404 Not Found というレスポンスと "Unable to identify proxy for host: and url:" といエラーメッセージが返される場合があります。

診断

API リクエストを送信する API プロキシのプロキシエンドポイント構成を確認します。
エラーメッセージにあるパスに対するリクエストを受信するように API プロキシが構成されていることを確認します。確認するには、次の操作を行います。

シナリオ 1: パスが API プロキシのベースパスと一致しない

エラーメッセージにあるパスが API プロキシのベースパスと一致しない場合、あるいはパスがベースパスで始まっていない場合、これがエラーの原因の可能性があります。
次の例で考えてみましょう。

API プロキシのベースパスが /weather
API リクエスト URL が https://myorg-prod.apigee.net/climate。API リクエスト URL のパスは /climate になります。

この例で、パスはベースパスに一致していません。また、ベースパスで始まっていません。このため、次のエラーが発生します。

{
       "fault":{
          "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
          "detail":{
             "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
          }
       }
    }

解決策

API リクエスト URL のパスに、API プロキシのベースパスを指定します。
上の例の場合、API リクエスト URL を https://myorg-prod.apigee.net/weather にします。

シナリオ 2: 使用可能な条件フローにパスが一致しない

API リクエスト URL のパスがベースパスで始まっている場合、エラーメッセージにあるパスの接尾辞（ベースパスの後ろの部分）がどの条件フローとも一致しないため、404 エラーが発生した可能性があります。
次の例で考えてみましょう。
1. API プロキシのベースパスが /weather
2. API リクエスト URL が https://myorg-prod.apigee.net/weather/Delhi。API リクエスト URL のパスは /weather/Delhi になります。
この例で、パスはベースパス /weather で始まっています。パスの接尾辞は /Delhi です。
プロキシエンドポイントに条件フローが定義されているかどうか確認します。
条件フローがないか、条件なしフローがある場合は、次の原因（API プロキシが環境にデプロイされていない）に進みます。
プロキシエンドポイントのすべてのフローが条件フローの場合、次の点を確認します。
1. すべての条件フローの条件が proxy.pathsuffix（ベースパスの後ろにあるパス）をチェックしているかどうか。
2. API リクエスト URL に指定されたパスの接尾辞がどの条件にも一致しない場合、これが問題の原因である可能性があります。

次のように、プロキシエンドポイントに 2 つのフローがあり、その両方が条件フローの場合について考えてみましょう。

<Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

    <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>

上の例では 2 つの条件フローがあります。1 つは proxy.pathsuffix（ベースパスの後ろにあるパス）が /Bangalore に一致し、もう 1 つは /Chennai に一致します。API リクエスト URL で渡されたパス（/Delhi）に一致するものはありません。

これが 404 エラーの原因です。このため、次のエラーが発生します。

{
       "fault":{
          "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
          "detail":{
             "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
          }
       }
    }

解決策

プロキシエンドポイントの 1 つ以上の条件フローに一致するパスの接尾辞を使用します。
上の例の場合、次の方法でエラーを解決できます。
1. パス /Delhi に対して特定のポリシーセットを実行する場合は、必要なポリシーセットを定義した別のフローを追加し、次のように proxy.pathsuffix /Delhi に一致する条件を設定します。
```
<Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    
```
2. パス /Delhi に対してポリシーの共通セットを実行するには、共通フローで汎用的な proxy.pathsuffix を許可する条件を追加します。これにより、ベースパス /weather の後ろにあるパスが許可されます。
```
<Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>
```

プロキシエンドポイントに正しいベースパスが定義され、API URL で指定されたパスの接尾辞がどの条件フローにも一致していない場合は、次の原因（API プロキシが環境にデプロイされていない）に進みます。

原因: API プロキシが環境にデプロイされていない

診断

API リクエスト URL で使用されたホストエイリアスが存在する環境を特定します。この作業を行うには、Edge UI で組織の環境にある仮想ホストをすべて確認します。
1. たとえば、次のような構成について考えてみます。
  1. URL が http://myorg-prod.apigee.net/weather。myorg-prod.apigee.net がホストエイリアスになります。
  2. ホストエイリアス myorg-prod.apigee.net が、組織の "prod" 環境にあるいずれかの仮想ホストで構成されている。
手順 1 で特定した環境に必要な API プロキシがデプロイされているかどうか確認します。
この環境に API プロキシがデプロイされていない場合、これが 404 エラーの原因です。
1. 手順 1 の場合、"prod" 環境に API プロキシがデプロイされていない場合、これがエラーの原因です。
2. 以下の「解決策」に進みます。
環境に API プロキシがデプロイされている場合は、次の原因（環境が Message Processor に読み込まれていない）に進みます。

解決策

API リクエストを行う環境に API プロキシをデプロイします。

原因: 環境が Message Processor に読み込まれていない

（Edge Private Cloud ユーザーのみ）

診断

Message Processor にログインして次のコマンドを実行し、API リクエストを行う環境が Message Processor に読み込まれているかどうか確認します。
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
    
```
上のコマンドの出力に環境が含まれている場合は、次の原因（API プロキシが Message Processor にデプロイされていない）に進みます。
環境がリストにない場合は、Message Processor で /opt/apigee/var/log/edge-message-processor/logs/system.log と /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log を調べ、環境の読み込みでエラーが発生していないかどうか確認します。
Message Processor に環境が読み込まれていない原因は 1 つだけではありません。発生したエラーによって解決策も異なります。

解決策

環境が Message Processor に読み込まれない原因は 1 つとは限りません。このセクションでは、この問題で考えられる原因とその解決方法を説明します。

Message Processor ログに次のいずれかのエラーが記録されている場合、環境のキーストア / トラストストアに追加された証明書 / 鍵に問題があります。

エラー 1: java.security.KeyStoreException: 独自の証明書を上書きできない

2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
    com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
    at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
    at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
    at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
    at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
    …
    Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
    at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
    at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
    at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]

... 20 common frames omitted

2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

エラー 2: java.security.KeyStoreException: 秘密鍵を上書きできない

2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
    com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
    at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
    at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
    ...
    Caused by: java.security.KeyStoreException: Cannot overwrite secret key
    at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
    at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
    at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
    ... 20 common frames omitted

    2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

次の API 管理呼び出しを使用して、前の手順のエラーメッセージにあるキーストア / トラストストアの詳細を確認します。

curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

出力例:

{
       "certs":[
          "mycert",
          "mycert-new"
       ],
       "keys":[
          "mycert"
       ],
       "name":"myTruststore"
    }

この出力例を見ると、トラストストア myTruststore に 2 つの証明書と 1 つの鍵が格納されていることがわかります。通常、トラストストアに鍵はありません。鍵がある場合は、1 つの証明書と 1 の鍵にする必要があります。

次の API を使用して、2 つの証明書の詳細を確認します。

curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>

証明書の有効期限を調べて、期限切れの証明書や古い証明書がないか確認します。
期限切れの証明書または不要な証明書をトラストストア "myTruststore" から削除します。

問題が解決しない場合、または上の手順 1 以外のエラーが発生している場合は、診断情報の収集に進みます。

原因: API プロキシが Message Processor にデプロイされていない

（Edge Private Cloud ユーザーのみ）

API プロキシが Message Processor にデプロイされていない可能性があります。この問題はごくまれにしか発生しませんが、API プロキシのデプロイで管理サーバーから Message Processor にイベント通知が送信されていないことが原因で発生します。この問題が発生した場合、Edge UI でトレースセッションを作成できません。

診断

Message Processor にログインして次のコマンドを実行し、API プロキシの特定のリビジョンがデプロイされているかどうかを確認します。
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
    
```
上の手順 1 で実行したコマンドの出力に API プロキシの特定のリビジョンが表示されていない場合、以下の解決策で説明するように Message Processor を再起動します。
すべての Message Processor に手順 1 と 2 を繰り返します。
API プロキシの特定のリビジョンがすべての Message Processor にデプロイされている場合、これは問題の原因ではありません。診断情報の収集に進みます。

解決策

API プロキシの特定のリビジョンがデプロイされていない Message Processor を再起動します。
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```

API Monitoring を使用して問題を診断する

注: このセクションの手順を行えるのは、Public Cloud ユーザーのみです。

API Monitoring では、問題領域を簡単に切り分けて、エラー、パフォーマンス、レイテンシの問題とその原因（デベロッパーアプリ、API プロキシ、バックエンドターゲット、API プラットフォームなど）を診断できます。

サンプルのシナリオを使用して、API Monitoring で API のトラブルシューティングを行います。たとえば、404 ステータスコードの数が特定のしきい値を超えたときに通知を行うようにアラートを設定します。

診断情報の収集

上記の手順でも問題が解決されない場合は、次の診断情報を収集する必要があります。Apigee サポートに連絡して、収集した情報を共有してください。

Public Cloud をご利用の場合は、次の情報を提供してください。
1. 組織名
2. 環境名
3. API プロキシ名
4. エラーを再現する完全な curl コマンド
Private Cloud をご利用の場合は、次の情報を提供してください。
1. 確認したエラーメッセージの全文
2. 環境名
3. API プロキシバンドル
4. Message Processor のログ /opt/apigee/var/log/edge-message-processor/logs/system.log
5. Message Processor で実行した次のコマンドの出力
このプレイブックで試したセクションや詳しい分析情報を提供していただけると、迅速な問題解決に役立ちます。