404 无法识别主机 <虚拟主机名> 和网址：<路径> 的代理

<ph type="x-smartling-placeholder"></ph> 您正在查看 Apigee Edge 文档。
转到 Apigee X 文档。 信息

问题

客户端应用将收到 HTTP 状态代码 404 以及消息 Not Found 和错误消息 Unable to identify proxy for host: VIRTUAL_HOST and url: PATH 作为对 API 调用的响应。

此错误表示 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 路径。

可能的原因

下面列出了一些可能导致此错误的原因：

原因 说明 适用的问题排查说明
<ph type="x-smartling-placeholder"></ph> API 代理未与特定虚拟主机相关联 特定 API 代理未配置为接受虚拟主机上的请求 错误消息中指定的名称。 Edge 公有云和私有云用户
在新部署的 API 代理修订版本中移除虚拟主机 从新部署的修订版本中移除虚拟主机，同时客户端仍在运行 使用特定虚拟主机可能会导致此问题。 Edge 公有云和私有云用户
<ph type="x-smartling-placeholder"></ph> 路径未与任何 API 代理相关联 特定 API 代理未配置为接受指定路径上的请求 。 Edge 公有云和私有云用户
<ph type="x-smartling-placeholder"></ph> 环境中未部署 API 代理 特定 API 代理未在您所处的特定环境中部署 尝试发出 API 请求 Edge 公有云和私有云用户
<ph type="x-smartling-placeholder"></ph> 消息处理器上未加载环境 尝试发出 API 请求的特定环境 因为发生错误。 Edge Private Cloud 用户
<ph type="x-smartling-placeholder"></ph> 一个或多个消息处理器上未部署 API 代理 由于 API 代理缺少 事件通知。 Edge Private Cloud 用户

常见诊断步骤

NGINX 和 Message Processor 日志有助于排查 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 代理未与特定虚拟主机相关联

如果 API 代理未配置为接受对特定虚拟主机的请求， 我们可以得到 404 Not Found 响应，其中包含错误消息 Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

诊断

  1. 检查 API 代理的代理端点配置，看看 API 代理是否已安装 配置为接受针对此错误中指定的虚拟主机的请求。这是 由 VirtualHost 元素指示。我们来看一个示例 ProxyEndpoint 以了解这一点

    代理端点配置示例，显示 API 代理在某个设备上接受请求 安全虚拟主机

  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 代理相关联。

分辨率

  1. 将缺失的 VirtualHost 添加到 ProxyEndpoint 配置中， 解决问题对于上面所示的示例，您可以添加默认的 VirtualHost 添加到 ProxyEndpoint 配置，如下所示： 
    <VirtualHost>default</VirtualHost>

    代理端点配置示例（显示默认值）VirtualHost&gt;正在添加

  2. 或者，在上述示例中，如果您只想使用 secure VirtualHost 针对此特定 API 代理，然后发出 API 请求 仅传送到 secure VirtualHost（使用 HTTPS 协议）： 
    https://myorg-prod.apigee.net/weather

原因：新部署的 API 代理修订版本中移除了虚拟主机

在移除特定虚拟主机后部署了 API 代理的新修订版本 （属于之前部署的修订版本的一部分），但仍由客户端使用 则可能会导致此问题

诊断

  1. 检查 API 代理的代理端点配置，确认 API 代理是否正常 配置为接受针对此错误中指定的虚拟主机的请求。这是 由 ProxyEndpoint 配置中的 VirtualHost 元素指明。
  2. 如果 ProxyEndpoint 中不存在错误中指定的虚拟主机 然后执行以下步骤。否则，就去下一个原因 - 路径未与任何 API 代理相关联。
  3. 将之前部署修订版本的 ProxyEndpoint 配置与当前修订版本进行比较 修订版本
    1. 例如，假设您之前部署的修订版本是 5， 当前部署的修订版本为 6： <ph type="x-smartling-placeholder">
        </ph>
      • 在修订版本 5 的代理端点中配置的虚拟主机
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • 在修订版本 6 的代理端点中配置的虚拟主机
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. 在上面的示例中，VirtualHost vh1 存在于 revision 5, 中 但已从 revision 6 中移除，并替换为 VirtualHost secure。
    3. 如果您或您的客户使用 向此 API 代理发出请求， 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. 使用其他基本路径创建新的代理，并使用其他虚拟主机 （在先前部署的修订版本中不存在）。

  2. 如果您想继续使用现有的 API 代理，但改用其他虚拟主机， 那么最好保留现有的虚拟主机，并添加额外的虚拟主机。

    这将确保此 API 代理的用户不受此更改的影响。

  3. 如果您想使用现有的 API 代理，但只有一台不同的虚拟主机， 并提前通知用户，并在维护期间进行相应更改。

    这样可以确保此 API 代理的用户了解更改，并 可以使用其他虚拟主机调用此 API 代理。因此 则不受此更改的影响

场景 2：意外更改

如果虚拟主机移除是误操作而非有意为之，请执行以下操作：

  1. 更新当前部署的修订版本中要使用的 ProxyEndpoint 配置 先前部署的修订版本中使用的相同虚拟主机。在 请将以下部分从： 
    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

    至

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

最佳做法

在维护期间，始终建议部署新代理或新修订版本 或是在流量预计最少的时候 确保部署期间出现的所有问题都能 或者最大限度地减少对流量的影响。

原因：路径未与任何 API 代理相关联

如果 API 代理未配置为接受针对 API 请求网址，我们就可以获得包含错误消息的 404 Not Found 响应 Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

诊断

  1. 查看您希望用于特定 API 代理的 ProxyEndpoint 配置 发出 API 请求
  2. 检查 API 代理是否已配置为接受针对所指示的特定路径的请求 。为此，您可以执行 情景 #1 和 场景 2。

场景 1：路径与 API 代理的基本路径不匹配

  1. 如果错误消息中指示的 path 与 basepath 不同 或者不以 basepath 开头，那么 可能是导致错误的原因。
  2. 我们通过一个示例来说明这一点：
    1. 预期 API 代理的 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 代理的名称
  2. 在上例中，API 请求网址应如下所示： 
    {
https://myorg-prod.apigee.net/weather

场景 2：路径与任何可用条件流都不匹配

  1. 如果 API 请求网址中使用的 path 以 basepath 开头， 那么 path suffix（位于 basepath）与任何条件语句都不匹配。 数据流，则可能会导致 404 错误。
  2. 我们通过一个示例来说明这一点： <ph type="x-smartling-placeholder">
      </ph>
    1. 预期 API 代理的 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 代理。
  6. 如果 ProxyEndpoint 只有条件流，请检查以下内容： <ph type="x-smartling-placeholder">
      </ph>
    1. 如果所有这些条件流中的条件都检查是否存在特定的 proxy.pathsuffix （基本路径后面的路径）。
    2. 如果 API 请求网址中指定的 path suffix 与任何 那么这就是导致错误的原因。
  7. 假设 ProxyEndpoint 中有两个 Flow， 条件流，如下所示： 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    <ph type="x-smartling-placeholder">
      </ph>
    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 与代理端点中的至少一个条件流匹配。
  2. 在上面的示例中，您可以使用以下方法来解决错误： <ph type="x-smartling-placeholder">
      </ph>
    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 代理。

原因：环境中未部署 API 代理

诊断

  1. 确定 API 请求网址中使用的主机别名所在的环境。 为此，可以检查每个环境中所有虚拟主机的详细信息 组织管理员。

    例如，假设存在以下配置：

    • 如果 http://myorg-prod.apigee.net/weather 是您的网址，则 myorg-prod.apigee.net 是主机别名。
    • 主机别名 myorg-prod.apigee.net 被配置为 位于贵组织的 prod 环境中的虚拟主机。
  2. 检查特定 API 代理是否已部署在 步骤 1。
  3. 如果 API 代理未在特定环境中部署，则会导致 404 错误。
    1. 在上述第 1 步中使用的示例中，我们假设 API 代理未部署在 prod 环境中，则这就是导致错误的原因。
    2. 转到下面的解决方法部分。
  4. 如果 API 代理部署在特定环境中，则接着采取下一个原因 - <ph type="x-smartling-placeholder"></ph> 消息处理器上未加载环境。

分辨率

在您打算在其中发出 API 请求的特定环境中部署 API 代理。

原因：消息处理器上未加载环境

诊断

  1. 登录到每个消息处理器，并检查 使用下列命令在消息处理器上加载 API 请求： 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. 如果上述命令中列出了特定环境，则转到下一个原因 - <ph type="x-smartling-placeholder"></ph> 一个或多个消息处理器上未部署 API 代理。
  3. 如果其中未列出特定环境，请查看 /opt/apigee/var/log/edge-message-processor/logs/system.log和 /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log上的 环境加载过程中出现的任何错误的消息处理器。
  4. 可能存在许多不同的错误，这些错误可能会导致在 Google Cloud 上加载环境失败 消息处理器解决方法取决于发生的错误。

分辨率

消息处理器上未加载环境的原因有很多。此部分 说明了可能导致该问题的几种原因，并说明了如何解决 问题。

  1. 如果您在消息处理器日志中看到以下某个错误，则是由 已添加到指定密钥库/信任库的证书/密钥存在问题 特定环境下的资源

    错误 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 调用： 
    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 代理 部署在一个或多个消息处理器上

API 代理可能未部署在一个或多个消息处理器上。这个问题在 很少出现，主要是因为没有从管理服务器接收事件通知， 部署特定 API 代理期间的消息处理器。在这个示例中 无法在 Edge 界面中创建跟踪会话。

诊断

  1. 登录到每个消息处理器并检查 是否部署了 API 代理，或者是否使用以下命令： 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  2. 如果 API 代理的特定修订版本未显示为命令的输出 然后按照第 1 步中的说明重启特定的消息处理器， 解决方法。
  3. 针对所有消息处理器重复第 1-2 步。
  4. 如果在所有消息处理器上都部署了 API 代理的特定修订版本，则 这并非出现此问题的原因。转到 必须收集诊断信息。

分辨率

重新启动 API 代理的特定修订版本所在的特定消息处理器 未部署。

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

使用 API 监控来诊断问题

API 监控可帮助您快速找出问题所在领域 诊断错误、性能和延迟问题及其来源，例如开发者应用、 API 代理、后端目标或 API 平台。

对于此问题，您可以导航至 API 监控 >调查页面并 选择合适的日期、代理等，并且可能会看到以下详细信息：

界面中的故障代码和状态代码

  • 错误代码：messaging.adaptors.http.flow.ApplicationNotFound
  • 状态代码：404
  • 故障来源：Apigee 或 MP

此外，您可以点击查看日志（如上方屏幕截图所示），进行进一步的检查。

查看日志

逐步完成示例场景 使用 API Monitoring 排查 API 存在的 5xx 问题。例如，您可以 您希望设置提醒，以便在 404 状态代码的数量超过 特定阈值。

必须收集的诊断信息

如果按照上述说明操作后问题仍然存在，请收集 以下诊断信息。请与 Apigee Edge 支持团队联系并分享这些信息。

  1. 如果您是公有云用户，请提供以下信息： <ph type="x-smartling-placeholder">
      </ph>
    • 组织名称
    • 环境名称
    • API 代理名称
    • 完整 curl 命令以重现该错误
  2. 如果您是 Private Cloud 用户，请提供以下信息： <ph type="x-smartling-placeholder">
      </ph>
    • 观察到完整的错误消息
    • 环境名称
    • API 代理软件包
    • 消息处理器日志“/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. 详细说明您在本手册中的哪些部分尝试过，以及任何其他能够让您有所收获的数据洞见 将有助于我们尽快解决此问题。