Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

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

您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info

問題

用戶端應用程式會收到 HTTP 狀態碼 404，以及訊息 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 未設定為接受錯誤訊息中指定的虛擬主機要求。	Edge 公有和私有雲使用者
在新部署的 API Proxy 修訂版本中移除虛擬主機	如果用戶端仍在使用特定虛擬主機，但您從新部署的修訂版本中移除虛擬主機，就可能導致這個問題。	Edge 公有和私有雲使用者
路徑未與任何 API Proxy 建立關聯	特定 API Proxy 未設定為接受錯誤訊息中指定路徑的要求。	Edge 公有和私有雲使用者
API Proxy 未部署至環境	特定 API Proxy 未部署在您嘗試提出 API 要求的特定環境中。	Edge 公有和私有雲使用者
訊息處理器未載入環境	由於發生錯誤，訊息處理器未載入特定環境 (您嘗試發出 API 要求的環境)。	Edge Private Cloud 使用者
API Proxy 未部署在一或多個訊息處理器上	由於部署期間缺少事件通知，API Proxy 可能無法部署到一或多個訊息處理器。	Edge Private Cloud 使用者

常見的診斷步驟

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

使用下列指令查看 NGINX 記錄：

/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

檢查記錄項目中是否有下列欄位：

欄位	值
`Upstream_status, status`	`404`
`X-Apigee-fault-code`	`messaging.adaptors.http.flow.ApplicationNotFound`

記下記錄中的郵件 ID。

檢查訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log))，確認您是否擁有特定 API 的 messaging.adaptors.http.flow.ApplicationNotFound，或是 API 要求中是否有步驟 2 的專屬訊息 ID。
訊息處理工具記錄中的錯誤訊息示例

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

注意：上述 url 和 host 可能會因發生問題的 API 代理而異。

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

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

診斷

檢查 API Proxy 的Proxy Endpoint 設定，確認 API Proxy 是否已設定為接受錯誤中指定的虛擬主機要求。這會以 VirtualHost 元素表示。讓我們看看範例 ProxyEndpoint 設定，瞭解這項功能。
範例 Proxy 端點設定，顯示 API Proxy 接受安全虛擬主機上的要求

假設特定環境中定義的虛擬主機如下：

名稱	通訊埠	主機別名
`default`	`80`	`myorg-prod.apigee.net`
`secure`	`443`	`myorg-prod.apigee.net`

您使用網址 http://myorg-prod.apigee.net/weather 向 default VirtualHost 發出 API 要求

由於 ProxyEndpoint 沒有 default VirtualHost (如上例所示)，因此您會收到 404 回應代碼和下列錯誤訊息：

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

如要解決這個問題，請參閱下方的「解決方法」一節。
如果 ProxyEndpoint 已設定為接受 default 上的要求，請前往下一個原因 -「路徑未與任何 API Proxy 建立關聯」VirtualHost。

解析度

在 ProxyEndpoint 設定中新增缺少的 VirtualHost，即可解決問題。以上述範例為例，您可以按照下列方式，將預設 VirtualHost 新增至 ProxyEndpoint 設定：
```
<VirtualHost>default</VirtualHost>
```
範例 Proxy 端點設定，顯示新增的預設> VirtualHost>
或者，在上述範例中，如果您只打算使用這個特定 API Proxy 的 secure VirtualHost，請只透過 HTTPS 通訊協定，對 secure VirtualHost 發出 API 要求：
```
https://myorg-prod.apigee.net/weather
```

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

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

診斷

檢查 API Proxy 的「Proxy Endpoint」設定，確認 API Proxy 是否已設定為接受錯誤中指定的虛擬主機要求。這會以 ProxyEndpoint 設定中的 VirtualHost 元素表示。
如果錯誤中指定的虛擬主機不存在於 ProxyEndpoint 設定中，請執行下列步驟。否則，請前往下一個原因 -「路徑未與任何 API Proxy 建立關聯」。
比較先前部署的修訂版本與目前部署的修訂版本的 ProxyEndpoint 設定。
1. 舉例來說，假設您先前部署的修訂版本是 5，而目前部署的修訂版本是 6：
  - 在修訂版本 5 的 Proxy 端點中設定的虛擬主機
  - 在修訂版本 6 的 Proxy 端點中設定的虛擬主機
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"}}}
```
檢查目前部署的修訂版本是否有意或無意變更虛擬主機，並採取「解決方法」一節中說明的適當措施。

解析度

如果您發現新修訂版本中已移除虛擬主機，可能是刻意為之，也可能是意外。請針對每種情況執行下列解決方法/建議步驟，解決問題。

情境 1：刻意變更

如果是有意移除虛擬主機，建議您選擇下列其中一個選項：

建立具有不同基本路徑的新 Proxy，並使用不同的虛擬主機 (先前部署的修訂版本中不存在)。
如要繼續使用現有的 API Proxy，但使用不同的虛擬主機，建議保留現有的虛擬主機，並新增其他虛擬主機。

確保這項異動不會影響 API Proxy 的使用者。
如果您想使用現有的 API Proxy，但只有虛擬主機不同，請事先通知使用者，並在維護期間進行這項變更。

這樣一來，這個 API Proxy 的使用者就會知道這項變更，並可使用其他虛擬主機呼叫這個 API Proxy。因此不會受到影響。

情境 2：無意間變更

如果虛擬主機是誤刪而非刻意移除，請按照下列步驟操作：

更新目前部署的修訂版本中的 ProxyEndpoint 設定，使用先前部署的修訂版本中使用的相同虛擬主機。在上述範例中，將下列部分從：

<HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

到

<HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>

重新部署修訂版本。

最佳做法

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

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

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

診斷

查看您打算提出 API 要求的特定 API Proxy 的 ProxyEndpoint 設定。
檢查 API Proxy 是否已設定為接受錯誤訊息中指出特定路徑的要求。如要這麼做，請按照「情境 1」和「情境 2」中的步驟操作。

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

如果錯誤訊息中顯示的 path 與特定 API Proxy 的 basepath 不同，或並非以 basepath 開頭，則可能是導致錯誤的原因。
以下舉例說明：

預期 API Proxy 的 basepath 為 /weather
API 要求網址為 https://myorg-prod.apigee.net/climate。這表示 API 要求網址中使用的路徑為 /climate.

在本例中，path 與 basepath 不同，且並非以 basepath 開頭。因此您會收到下列錯誤：

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

解析度

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

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

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

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
```
1. 在上述範例中，我們有兩個條件流程，一個流程會將 proxy.pathsuffix (basepath 後方的路徑) 比對至 /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"
      }
   }
}
```

解析度

確認 path suffix 至少符合 Proxy 端點中的一個條件流程。
在上述範例中，您可以採用下列方法解決錯誤：
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 未部署在環境中

診斷

找出 API 要求網址中使用的主機別名所屬的環境。如要執行這項操作，請在 Edge UI 中，查看貴機構各環境的所有虛擬主機詳細資料。
舉例來說，假設有下列設定：
- 如果 http://myorg-prod.apigee.net/weather 是您的網址，則 myorg-prod.apigee.net 是主機別名。
- 主機別名 myorg-prod.apigee.net 已在貴機構的 prod 環境中，設定為其中一個虛擬主機的一部分。
檢查特定 API Proxy 是否部署在上述步驟 1 中確定的特定環境。
如果 API Proxy 未部署在特定環境中，就會導致 404 錯誤。
1. 因此，在上述步驟 1 的範例中，假設 API Proxy 未部署在 prod 環境中，這就是造成錯誤的原因。
2. 請參閱下方的「解決方法」一節。
如果 API Proxy 已部署在特定環境中，請前往下一個原因 -「訊息處理器未載入環境」。

解析度

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

原因：訊息處理工具未載入環境

診斷

登入每個訊息處理器，並使用下列指令檢查您發出 API 要求的特定環境是否已載入訊息處理器：
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
```
如果上述指令列出特定環境，請前往下一個原因 - API Proxy 未部署在一或多個訊息處理器上。
如果未列出特定環境，請檢查「Message Processors」中的 /opt/apigee/var/log/edge-message-processor/logs/system.log 和 /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log，確認載入環境時是否有任何錯誤。
導致訊息處理器無法載入環境的錯誤有很多種。解決方式取決於發生的錯誤。

解析度

環境可能因許多原因而無法載入訊息處理器。本節將說明可能導致這個問題的幾個原因，以及如何解決問題。

如果在 Message Processor 記錄檔中看到下列其中一項錯誤，表示指定環境中，新增至指定金鑰儲存區/信任儲存區的憑證/金鑰發生問題。

錯誤 #1：java.security.KeyStoreException：Cannot overwrite own certificate

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

使用下列 Management API 呼叫，取得上一個步驟中顯示的錯誤訊息所指定 KeyStore/信任儲存庫的詳細資料：

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 中有兩個憑證和一個金鑰。信任儲存庫通常不含金鑰。如果可以，最好使用單一憑證和單一金鑰。

使用下列 API 取得這兩項憑證的詳細資料：

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

檢查每個憑證的到期日，找出過期/較舊的憑證。
從信任儲存區 myTruststore 刪除過期或不需要的憑證。

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

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

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

診斷

登入每個訊息處理器，然後使用下列指令檢查是否已部署 API Proxy 的特定修訂版本：
```
curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
```
如果 API Proxy 的特定修訂版本未顯示為上述步驟 1 中指令的輸出內容，請按照「解決方法」一節的說明，重新啟動特定訊息處理器。
針對所有訊息處理器重複執行步驟 1 到 2。
如果 API Proxy 的特定修訂版本已部署在所有訊息處理器上，則這不是造成問題的原因。請參閱「必須收集診斷資訊」。

解析度

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

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

使用 API 監控功能診斷問題

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

如要解決這個問題，請前往「API 監控」>「調查」頁面，然後選擇適當的日期、Proxy 等等，您可能會看到下列詳細資料：

使用者介面中的錯誤碼和狀態碼

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

此外，您也可以點選上圖所示的「查看記錄」，進一步檢查。

查看記錄

逐步瞭解範例情境：說明如何使用 API 監控功能，排解 API 的 5xx 問題。舉例來說，您可能想設定快訊，在 404 狀態碼數量超過特定門檻時收到通知。

必須收集診斷資訊

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

如果您是公有雲使用者，請提供下列資訊：
- 機構名稱
- 環境名稱
- API Proxy 名稱
- 完成 curl 指令，重現錯誤
如果您是 Private Cloud 使用者，請提供下列資訊：
- 出現的完整錯誤訊息
- 環境名稱
- API Proxy 套裝組合
- 訊息處理器記錄 /opt/apigee/var/log/edge-message-processor/logs/system.log
- 在每個訊息處理器上執行下列指令的輸出內容。
您已嘗試使用本手冊中的哪些章節，以及任何其他有助於我們加速解決這個問題的洞察資訊。