404 無法識別下列主機的 Proxy：<虛擬主機名稱> 和 url: <path>

您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊

問題

用戶端應用程式會取得 404 的 HTTP 狀態碼，內含 Not Found 訊息和錯誤訊息 Unable to identify proxy for host: VIRTUAL_HOST and url: PATH 以回應 API 呼叫。

這個錯誤代表 Edge 找不到指定虛擬主機和路徑的 API Proxy。

錯誤訊息

畫面上會顯示以下 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 Proxy。

可能原因

這個錯誤的一些可能原因如下：

原因 說明 適用的疑難排解指示
API Proxy 未與特定虛擬主機建立關聯 特定 API Proxy 未設定於錯誤訊息中指定的虛擬主機上接受要求。 邊緣公開與私有雲使用者
在新部署的 API Proxy 修訂版本中移除虛擬主機 如果用戶端仍使用特定虛擬主機，而從新部署的修訂版本中移除虛擬主機，可能就會發生這個問題。 Edge Public and Private Cloud 使用者
未與任何 API Proxy 建立關聯的路徑 特定 API Proxy 並未設為接受錯誤訊息所指定路徑的要求。 邊緣公開與私有雲使用者
未部署於環境中的 API Proxy 您在嘗試提出 API 要求的特定環境中並未部署特定的 API Proxy。 邊緣公開與私有雲使用者
訊息處理器未載入環境 發生錯誤，訊息處理器尚未載入特定環境 (您嘗試提出 API 要求的目標環境)。 Edge Private Cloud 使用者
一或多個訊息處理器未部署 API Proxy 由於在部署期間缺少事件通知，API Proxy 可能無法部署至一或多個訊息處理器。 Edge Private Cloud 使用者

常見診斷步驟

NGINX 和訊息處理器記錄有助於排解 404 錯誤。請按照下列步驟查看記錄：

  1. 使用下列指令查看 NGINX 記錄： 
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. 檢查記錄項目中的下列欄位：
    欄位 值
    Upstream_status, status 404
    X-Apigee-fault-code messaging.adaptors.http.flow.ApplicationNotFound

    記下記錄中的郵件 ID。

  3. 查看訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log)，確認是否有特定 API 的 messaging.adaptors.http.flow.ApplicationNotFound)，或是否已有步驟 2 中針對 API 要求提供的專屬訊息 ID。

    郵件處理器記錄的錯誤訊息範例

    4. NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

    上方記錄顯示錯誤代碼和錯誤訊息如下：

    code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

原因：API Proxy 未與特定虛擬主機建立關聯

如果 API Proxy 未設定接受特定虛擬主機的要求，我們可能會收到 404 Not Found 回應並顯示錯誤訊息 Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

診斷

  1. 檢查 API Proxy 的 Proxy 端點設定，並查看 API Proxy 是否已設為接受錯誤中指定的虛擬主機要求。這會透過 VirtualHost 元素指出。讓我們來看看以下 ProxyEndpoint 設定範例，瞭解設定方式。

    顯示 Proxy 端點設定範例，顯示 API Proxy 接受來自安全虛擬主機的要求

  2. 假設在特定環境中定義虛擬主機，如下所示：
    名稱 通訊埠 主機別名
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. 您使用網址 http://myorg-prod.apigee.net/weather 向 default VirtualHost 提出 API 要求
  4. 如上例所示，ProxyEndpoint 沒有 default VirtualHost，因此您會收到 404 回應代碼和以下錯誤訊息： 
    {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  5. 請參閱下方的解決部分，瞭解如何解決這個問題。
  6. 如果將 ProxyEndpoint 設為接受 default VirtualHost 的要求，請前往下一個原因： 未與任何 API Proxy 建立關聯的路徑。

解析度

  1. 將缺少的 VirtualHost 新增至 ProxyEndpoint 設定，以便解決問題。以上述範例為例，您可以將預設的 VirtualHost 新增至 ProxyEndpoint 設定，如下所示： 
    <VirtualHost>default</VirtualHost>

    Proxy 端點設定範例，顯示正在新增預設> VirtualHost>

  2. 或者，在上述範例中，如果您只想針對這個特定 API Proxy 使用 secure VirtualHost，請使用 HTTPS 通訊協定只向 secure VirtualHost 提出 API 要求： 
    https://myorg-prod.apigee.net/weather

原因：在新部署的 API Proxy 修訂版本中移除虛擬主機

如果在移除特定虛擬主機 (屬於先前部署的修訂版本) 之後部署了新的 API Proxy 修訂版本，用戶端目前仍在發出 API 要求時，就可能導致這個問題。

診斷

  1. 檢查 API Proxy 的 Proxy 端點設定，確認 API Proxy 是否已設為接受錯誤中指定的虛擬主機要求。這會以 ProxyEndpoint 設定中的 VirtualHost 元素來表示。
  2. 如果 ProxyEndpoint 設定中沒有錯誤中指定的虛擬主機，請執行下列步驟。否則，請前往下一個原因：未與任何 API Proxy 建立關聯的路徑。
  3. 將先前部署的修訂版本的 ProxyEndpoint 設定與目前部署的修訂版本進行比較。
    1. 舉例來說，假設您先前部署的修訂版本為 5，而目前部署的修訂版本為 6：
      • 在修訂版本 5 的 Proxy 端點中設定的虛擬主機
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • 在修訂版本 6 的 Proxy 端點中設定的虛擬主機
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. 在上述範例中，VirtualHost vh1 存在於 revision 5, 中，但已移除在 revision 6 中，並替換為 VirtualHost secure。
    3. 因此，如果您或您的用戶端使用 VirtualHost vh1 (屬於 revision 5 的一部分) 向這個 API Proxy 提出要求，您會收到 404 回應代碼，內含下列錯誤訊息： 
      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  4. 檢查虛擬主機變更是意外或非刻意在目前部署的修訂版本中進行，並按照「解決方法」一節的說明採取適當的措施。

解析度

如果您發現虛擬主機或主機已從新的修訂版本中移除，這可能是刻意設定的，也可能是不小心。針對每個案件，執行下列解決方案/建議步驟以解決問題。

情境 #1：意圖變更

如果您刻意移除虛擬主機，請選擇下列其中一個選項，並使用第一個選項：

  1. 建立新的 Proxy，並設定不同的基本路徑，並使用其他虛擬主機 (先前部署的修訂版本中沒有)。

  2. 如果您想繼續使用現有的 API Proxy，但要改用其他虛擬主機，建議您保留現有的虛擬主機，並新增其他虛擬主機。

    以確保這項變更不會影響這個 API Proxy 的使用者。

  3. 如果您想使用現有的 API Proxy，且只有一個不同的虛擬主機，請事先通知使用者，並在維護期間進行這項變更。

    這麼做可確保這個 API Proxy 的使用者知道這項變更，且他們可以使用其他虛擬主機對這個 API Proxy 發出呼叫。因此不受這項異動影響。

情境 2：意外變更

如果是不小心移除虛擬主機，且並非蓄意移除，請按照下列步驟操作：

  1. 將目前部署的修訂版本中的 ProxyEndpoint 設定更新為使用先前部署修訂版本中使用的虛擬主機。在上述範例中，將下列區段從： 
    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

    到

    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
  2. 重新部署修訂版本。

最佳做法

建議您一律在維護期間或流量預期最差時，部署新的 Proxy 或新的修訂版本，避免部署期間發生的任何問題，或將對流量的影響降到最低。

原因：未與任何 API Proxy 建立關聯的路徑

如果 API Proxy 未設定為 API 要求網址中使用的特定路徑要求，我們可能會收到 404 Not Found 回應並顯示錯誤訊息 Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

診斷

  1. 針對您要提出 API 要求的特定 API Proxy 查看 ProxyEndpoint 設定。
  2. 檢查 API Proxy 是否設為接受錯誤訊息所指出特定路徑的要求。您可以執行情境 1 和情境 2 中的步驟。

情境 #1：路徑與 API Proxy 的基本路徑不符

  1. 如果錯誤訊息中指出的 path 與特定 API Proxy 的 basepath 不同，或並非以 basepath 開頭，這可能是發生錯誤的原因。
  2. 讓我們透過範例來說明這個情況：
    1. 預期的 API Proxy 為 basepath 是 /weather
    2. API 要求網址為 https://myorg-prod.apigee.net/climate。也就是說，API 要求網址中使用的路徑為 /climate.
  3. 在本例中，path 與 basepath 不同，且開頭不是 basepath。因此您會收到以下錯誤訊息： 
    {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

解析度

  1. 確認 API 要求網址中使用的 path 與特定 API Proxy 的 basepath 相同。
  2. 在上述範例中，API 要求網址應如下所示： 
    {
https://myorg-prod.apigee.net/weather

情境 2：路徑不符合任何可用的條件式流程

  1. 如果 API 要求網址中使用的 path 開頭為 basepath，則錯誤訊息中指出的 path suffix (位於 basepath 之後的部分) 可能不符合任何條件流程，就有可能造成 404 錯誤。
  2. 讓我們以範例說明這個問題：
    1. 預期的 API Proxy 為 basepath 是 /weather
    2. API 要求網址為 https://myorg-prod.apigee.net/weather/Delhi。也就是說，API 要求網址中使用的路徑為 /weather/Delhi.
  3. 在這個範例中，path 的開頭是 basepath /weather。此外，它的 path suffix 為 /Delhi。
  4. 現在請檢查 ProxyEndpoint 中是否有任何條件式流程。
  5. 如果沒有條件式流程或有幾項無條件流程，請前往下一個原因： 未部署在環境中的 API Proxy。
  6. 如果 ProxyEndpoint 只有條件式流程，請檢查以下事項：
    1. 如果這些條件流程中的所有條件都會檢查特定的 proxy.pathsuffix (基本路徑之後的路徑)。
    2. 如果 API 要求網址中指定的 path suffix 不符合任何條件，就是導致錯誤的原因。
  7. 假設 ProxyEndpoint 中有兩個資料流，兩者都是條件式流程，如下所示： 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    1. 在上述範例中，有兩個條件式流程，一個與 proxy.pathsuffix (基本路徑之後的路徑) 與 /Bangalore 相符，另一個則與 /Chennai 相符。不過，沒有任何與 /Delhi 相符的項目，也就是 API 要求網址中傳遞的 path suffix。
    2. 這是 404 錯誤的原因。因此，您會收到以下錯誤訊息： 
      {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

解析度

  1. 確保 path suffix 至少與 Proxy 端點中的一個條件式流程相符。
  2. 在上述範例中，您可以使用以下方法解決錯誤：
    1. 如果您想針對路徑 /Delhi 執行任一組特定政策，請另外新增包含一組所需政策的獨立流程，並確保條件符合 /proxy.pathsuffix /Delhi，如下所示： 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    2. 如要針對路徑 /Delhi 執行一組通用政策，請在共用流程中確保設有允許一般 /proxy.pathsuffix 的條件。也就是說，它會允許 basepath /weather 之後的任何路徑，如下所示： 
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

如果 ProxyEndpoint 的 basepath 和 API 網址中指定的 path suffix 與其中一個條件式流程相符，則請採取下一個原因：未部署於環境中的 API Proxy。

原因：未部署於環境中的 API Proxy

診斷

  1. 找出 API 要求網址中使用的主機別名所在的環境。方法是在 Edge UI 中檢查貴機構各個環境中所有虛擬主機的詳細資料。

    例如，假設採用以下設定：

    • 如果 http://myorg-prod.apigee.net/weather 是網址，則 myorg-prod.apigee.net 是主機別名。
    • 主機別名 myorg-prod.apigee.net 已設定為貴機構 prod 環境中的其中一個虛擬主機的一部分。
  2. 查看上述 API Proxy 是否已部署於上方步驟 1 所述的特定環境中。
  3. 如果 API Proxy 未在特定環境中部署，這就是 404 錯誤的原因。
    1. 因此在上述步驟 1 使用的範例中，假設 API Proxy 並未部署在 prod 環境中，這就是發生錯誤的原因。
    2. 請參閱下方的解析度部分。
  4. 如果 API Proxy 是在特定環境中部署，請前往下一個原因： 未在訊息處理器上載入環境。

解析度

在您要提出 API 要求的特定環境中部署 API Proxy。

原因：未在訊息處理器上載入環境

診斷

  1. 登入每個訊息處理器，使用下列指令，檢查您發出 API 要求的特定環境是否已在訊息處理器上載入：
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. 如果上述指令中包含特定環境，則請採取下一個原因： 未部署在一或多個訊息處理器上的 API Proxy。
  3. 如未列出特定環境，請查看訊息處理器上的 /opt/apigee/var/log/edge-message-processor/logs/system.log 和 /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log，確認環境載入期間是否有任何錯誤。
  4. 有許多不同錯誤可能導致訊息處理器在訊息處理器中載入環境。「解決方法」取決於發生的錯誤。

解析度

由於許多原因，環境可能無法在訊息處理器上載入。本節說明可能導致這個問題的幾個可能原因，並說明如何解決問題。

  1. 如果您在「訊息處理者」記錄檔中看到下列其中一項錯誤，表示該問題出自已在指定環境中新增至指定 KeyStore/truststore 的憑證/金鑰發生問題。

    錯誤 #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
  2. 請使用下列管理 API 呼叫，取得上一步中錯誤訊息中指定的 KeyStore/truststore 詳細資料： 
    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"
}
  3. 範例輸出內容顯示信任儲存庫 myTruststore 中有兩個憑證和金鑰。信任儲存庫通常不含金鑰。如果是的話，最好使用單一憑證和單一金鑰。
  4. 使用以下 API 取得兩個憑證的詳細資料： 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
  5. 檢查每個憑證的到期日，判斷過期/較舊的憑證。
  6. 從信任儲存庫「myTruststore」中刪除過期或不需要的憑證。

如果問題仍未解決，或是您看到步驟 1 中提及的其他錯誤，請參閱「必須收集診斷資訊」一節。

原因：未部署於一或多個訊息處理器上的 API Proxy

一或多個訊息處理器可能無法部署 API Proxy。這個問題極少發生，通常是因為在部署特定 API Proxy 期間，管理伺服器缺少事件通知給訊息處理者。在這種情況下，您也無法在 Edge UI 中建立追蹤工作階段。

診斷

  1. 登入每個訊息處理器，並使用下列指令查看是否已部署 API Proxy 的特定修訂版本： 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  2. 如果 API Proxy 的特定修訂版本並未顯示為上述步驟 1 中提及的指令輸出內容，請按照解析度所述，重新啟動特定的訊息處理器。
  3. 對所有訊息處理器重複步驟 1 到 2。
  4. 如果所有訊息處理器都已部署 API Proxy 的特定修訂版本，那麼這就不是問題所在。前往「 必須收集診斷資訊」。

解析度

重新啟動未部署 API Proxy 特定修訂版本的特定訊息處理器。

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

使用 API 監控功能診斷問題

API 監控功能可讓您快速找出問題區域，診斷錯誤、效能與延遲問題及其來源 (例如開發人員應用程式、API Proxy、後端目標或 API 平台)。

您可以依序前往「API Monitoring」>「調查」頁面並選擇適當的日期、Proxy 等，您可能會看到下列詳細資料：

UI 中的錯誤代碼和狀態碼

  • Fault Code: messaging.adaptors.http.flow.ApplicationNotFound
  • 狀態碼： 404
  • 失敗來源： Apigee 或 MP

此外，您也可以點選上方螢幕截圖中的「查看記錄」，並進一步瞭解詳情。

查看記錄檔

逐步操作範例示範如何使用 API Monitoring 排解 API 的 5xx 問題。例如，您可以設定快訊，讓系統在 404 狀態碼數量超過特定門檻時收到通知。

必須收集診斷資訊

如果按照上述操作說明操作，問題仍未解決，請收集下列診斷資訊。請與 Apigee Edge 支援團隊聯絡並分享這項資訊。

  1. 如果您是公有雲使用者，請提供下列資訊：
    • 機構名稱
    • 環境名稱
    • API Proxy 名稱
    • 完成 curl 指令即可重現錯誤
  2. 如果您是私有雲使用者，請提供下列資訊：
    • 偵測到完整錯誤訊息
    • 環境名稱
    • API Proxy 套裝組合
    • 訊息處理器記錄 /opt/apigee/var/log/edge-message-processor/logs/system.log
    • 針對每個訊息處理器輸出下列指令。
      • curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
      curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  3. 詳細說明您參與本教戰手冊的章節，並取得其他有助於我們快速解決這項問題的洞察資訊。