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 建立關聯 特定 API Proxy 未設為接受指定路徑上的要求 。 邊緣公有雲和私有雲使用者
未部署於環境中的 API Proxy 未部署特定 API Proxy 所在的特定環境 嘗試發出 API 要求 邊緣公有雲和私有雲使用者
訊息處理器未載入環境 未具體的環境 (您嘗試發出 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. 您使用以下網址向 default VirtualHost 提出 API 要求 http://myorg-prod.apigee.net/weather
  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&gt;正在新增

  2. 在上述範例中，如果您只想使用 secure VirtualHost (用於這個特定 API Proxy)，然後發出 API 要求 只能透過 HTTPS 通訊協定傳送至 secure VirtualHost： 
    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 設定與目前部署修訂版本的 先前的 Deployment 版本
    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 的一部分)，則您將可取得 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 Proxy 的 ProxyEndpoint 設定 提出 API 要求
  2. 檢查 API Proxy 是否已設為接受指定路徑的要求 。步驟如下： 情境 1 和 情境 2：

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

  1. 如果在錯誤訊息中指定的 path 與 basepath 不同 特定 API Proxy 的 URI 開頭，或其開頭不是 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 與 basepath 相同 特定 API Proxy 的存取權
  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 要求網址中，主機別名所在的環境。 方法是檢查各環境中所有虛擬主機的詳細資料。 確定所有必要的架構

    舉例來說，假設下列設定如下：

    • 如果 http://myorg-prod.apigee.net/weather 是您的網址，則 myorg-prod.apigee.net 是主機別名。
    • 主機別名 myorg-prod.apigee.net 已設定在 貴機構 prod 環境的虛擬主機。
  2. 如要確認特定 API Proxy 是否已部署於特定環境下， 。
  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 的憑證/金鑰發生問題 指定環境內存在的 Pod

    錯誤 #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. 取得 方法是使用下列 Management 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"
}
  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. 登入每個「訊息處理器」，查看是否 已部署或未使用下列指令： 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  2. 如果指令輸出內容中未顯示該 API Proxy 的特定修訂版本 ，然後重新啟動特定訊息處理器，如 解析度：
  3. 針對所有訊息處理器重複步驟 1 到 2。
  4. 如果 API Proxy 的特定修訂版本已部署在所有訊息處理器上，則 這並非導致這項問題的成因。前往 必須收集診斷資訊。

解析度

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

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

使用 API Monitoring 診斷問題

API Monitoring 可讓您快速找出問題所在 診斷錯誤、效能和延遲問題及其來源，例如開發人員應用程式。 API Proxy、後端目標或 API 平台。

針對此問題，您可以前往「API 監控」調查頁面 選擇適當的日期、Proxy 等，可能會看到下列詳細資料：

UI 中出現錯誤程式碼和狀態碼

  • 錯誤代碼： messaging.adaptors.http.flow.ApplicationNotFound
  • 狀態碼： 404
  • 錯誤來源： Apigee 或 MP

此外，您還可以點選「查看記錄」(正如上方螢幕截圖所示)，進一步查看記錄。

查看記錄

逐步示範 使用 API Monitoring 排解 API 的「5xx」問題。例如，你可以設定 我想設定快訊，以便在 404 狀態碼數量超過 或特定閾值

必須收集診斷資訊

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

  1. 如果您是公用雲端的使用者，請提供下列資訊：
    • 機構名稱
    • 環境名稱
    • API Proxy 名稱
    • 完成 curl 指令即可重現錯誤
  2. 如果您是 Private Cloud 使用者，請提供以下資訊：
    • 觀察到完整的錯誤訊息
    • 環境名稱
    • 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. 詳細說明您試過的教戰手冊，以及 可協助我們快速追蹤這個問題。