404 Не удалось определить прокси-сервер для хоста: <имя виртуального хоста> и URL: <путь>

Вы просматриваете документацию по Apigee Edge.
Перейдите к документации по Apigee X. Информация

Symptom

Клиентское приложение получает код статуса 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 не удалось найти прокси-сервер API для виртуального хоста default и пути /oauth2/token.

Возможные причины

Ниже перечислены возможные причины этой ошибки.

Распространенные этапы диагностики

Для устранения ошибки 404 могут пригодиться журналы NGINX и Message Processor. Чтобы проверить журналы, выполните следующие действия:

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

   Запишите идентификатор сообщения из журналов.

3. Проверьте журналы Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)), чтобы узнать, есть ли у вас messaging.adaptors.http.flow.ApplicationNotFound для определенного API или уникальный идентификатор сообщения из шага 2 для запроса к API.

   Пример сообщения об ошибке из журнала обработчика сообщений

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. Вы отправляете запрос API к default VirtualHost, используя URL 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 по умолчанию

   

2. В приведенном выше примере, если вы хотите использовать для этого прокси-сервера API только secure VirtualHost, отправляйте запросы к API только на secure VirtualHost по протоколу HTTPS:

   https://myorg-prod.apigee.net/weather

Причина: виртуальный хост удален в новой версии прокси-сервера API

Если после удаления определенного виртуального хоста (который был частью ранее развернутой версии) развертывается новая версия прокси-сервера API, которая по-прежнему используется клиентами для выполнения запросов к API, это может привести к возникновению проблемы.

диагностика;

1. Проверьте конфигурацию конечной точки прокси-сервера для прокси-сервера API, чтобы узнать, настроен ли прокси-сервер API на прием запросов для виртуального хоста, указанного в ошибке. Это указано в элементе VirtualHost конфигурации ProxyEndpoint.
2. Если виртуальный хост, указанный в сообщении об ошибке, не существует в конфигурации ProxyEndpoint, выполните следующие действия: В противном случае перейдите к следующей причине – Путь не связан ни с одним прокси-сервером API.
3. Сравните конфигурацию ProxyEndpoint ранее развернутой версии с текущей.
   1. Например, если ранее развернутая версия была 5, а текущая – 6:
      • Виртуальные хосты, настроенные в конечной точке прокси-сервера в версии 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>

   to

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

2. Повторно разверните версию.

Рекомендации

Новые прокси-серверы или их версии рекомендуется развертывать в период обслуживания или когда трафик минимален. Это позволит избежать проблем при развертывании или свести к минимуму их влияние на трафик.

Причина: путь не связан ни с одним прокси-сервером API

Если прокси-сервер API не настроен на прием запросов для определенного пути, используемого в URL запроса к API, то мы можем получить ответ 404 Not Found с сообщением об ошибке Unable to identify proxy for host: VIRTUAL_HOST and url: PATH..

диагностика;

1. Посмотрите конфигурацию ProxyEndpoint для определенного прокси API, для которого вы хотели сделать запросы API.
2. Проверьте, настроен ли прокси-сервер API на прием запросов для определенного пути, указанного в сообщении об ошибке. Для этого выполните действия, описанные в сценарии 1 и сценарии 2.

Сценарий 1. Путь не совпадает с базовым путем прокси-сервера API

1. Если значение path, указанное в сообщении об ошибке, не совпадает со значением basepath в определенном прокси-сервере API или не начинается с basepathнего, то это может быть причиной ошибки.
2. Рассмотрим пример.
1. basepath целевого прокси-сервера API – /weather.
2. URL запроса к API: https://myorg-prod.apigee.net/climate. Это означает, что путь, используемый в URL запроса к 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. Убедитесь, что параметр path, используемый в URL запроса к API, совпадает с параметром basepath определенного прокси-сервера API.
2. В примере выше URL запроса API должен выглядеть так:

   {
   https://myorg-prod.apigee.net/weather

Сценарий 2. Путь не соответствует ни одному из доступных условных процессов

1. Если path, используемый в URL запроса API, начинается с basepath, то, возможно, path suffix (часть, которая следует за basepath), указанный в сообщении об ошибке, не соответствует ни одному из условных потоков. В этом случае может возникнуть ошибка 404.
2. Рассмотрим пример:
   1. basepath целевого прокси-сервера API – /weather.
   2. URL запроса к API: https://myorg-prod.apigee.net/weather/Delhi. Это означает, что путь, используемый в URL запроса к API, – /weather/Delhi..
3. В этом примере path начинается с basepath /weather. Кроме того, у него path suffix из /Delhi.
4. Теперь проверьте, есть ли в ProxyEndpoint условные потоки.
5. Если у вас нет условных потоков или их немного, перейдите к следующей причине – прокси-сервер API не развернут в среде.
6. Если в ProxyEndpoint есть только процессы с условиями, проверьте следующее:
   1. Если условия во всех этих условных потоках проверяют определенный proxy.pathsuffix (путь после базового пути).
   2. Если значение path suffix, указанное в URL запроса API, не соответствует ни одному из условий, это и будет причиной ошибки.
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, которое является значением параметра path suffix, переданного в URL запроса API.
   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. В примере выше можно устранить ошибку одним из следующих способов:
   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, а path suffix, указанный в URL API, соответствует одному из условных потоков, перейдите к следующей причине – прокси-сервер API не развернут в среде.

Причина: прокси-сервер API не развернут в среде

диагностика;

1. Определите среду, в которой существует псевдоним хоста, используемый в URL запроса к API. Для этого нужно проверить сведения обо всех виртуальных хостах в каждом из окружений организации в интерфейсе Edge.

   Предположим, что у вас настроена следующая конфигурация:

   • Если ваш URL выглядит так: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 развернут в определенной среде, перейдите к следующей причине: Среда не загружена в процессоры сообщений.

Разрешение

Разверните прокси-сервер API в той среде, в которой вы планируете отправлять запросы к API.

Причина: среда не загружена в процессоры сообщений

диагностика;

1. Войдите в каждый из Message Processor и проверьте, загружена ли в нем среда, в которой вы отправляете запрос к API, с помощью следующей команды:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

2. Если определенная среда указана в приведенной выше команде, перейдите к следующему пункту: прокси-сервер API не развернут на одном или нескольких процессорах сообщений.
3. Если нужной среды нет в списке, проверьте /opt/apigee/var/log/edge-message-processor/logs/system.log и /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log в разделе "Обработчики сообщений" на наличие ошибок при загрузке сред.
4. Причин, по которым среда не загружается в Message Processor, может быть много. Решение зависит от возникшей ошибки.

Разрешение

Среда может не загружаться в Message Processor по разным причинам. В этом разделе описаны некоторые возможные причины этой проблемы и способы ее устранения.

1. Если в журнале 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: Cannot overwrite secret key (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 не развернут на одном или нескольких Message Processor

Прокси-сервер API может быть не развернут на одном или нескольких процессорах сообщений. Эта проблема возникает очень редко и в основном из-за отсутствия уведомления о событии от сервера управления к Message Processor во время развертывания определенного прокси-сервера API. В этом случае вы также не сможете создать сеанс трассировки в интерфейсе Edge.

диагностика;

1. Войдите в каждый из обработчиков сообщений и проверьте, развернута ли определенная версия прокси-сервера API, с помощью следующей команды:

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
   

2. Если определенная версия прокси-сервера API не отображается в выходных данных команды, упомянутой на шаге 1 выше, перезапустите определенный Message Processor, как описано в разделе Решение.
3. Повторите шаги 1–2 для всех процессоров сообщений.
4. Если определенная версия прокси-сервера API развернута на всех Message Processor, то это не причина проблемы. Перейдите к разделу Как получить диагностическую информацию.

Разрешение

Перезапустите определенные Message Processor, на которых не развернута определенная версия прокси-сервера API.

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

Как диагностировать проблемы с помощью API Monitoring

Мониторинг API позволяет быстро выявлять проблемные области, чтобы диагностировать ошибки, проблемы с производительностью и задержками, а также их источник, например приложения разработчиков, прокси API, целевые серверы или платформу API.

Чтобы устранить эту проблему, перейдите на страницу Мониторинг API > Исследовать, выберите нужную дату, прокси и т. д. и посмотрите следующие сведения:

• Код ошибки: messaging.adaptors.http.flow.ApplicationNotFound
• Код статуса: 404.
• Источник ошибки: Apigee или MP

Кроме того, вы можете нажать Посмотреть журналы, как показано на скриншоте выше, и проверить дополнительную информацию.

В разделе Пошаговое описание примера показано, как устранять неполадки с API 5xx с помощью мониторинга API. Например, вы можете настроить оповещение, которое будет срабатывать, когда количество кодов статуса 404 превысит определенный порог.

Необходимо собрать диагностическую информацию

Если проблема не устранена, соберите указанную ниже диагностическую информацию. Свяжитесь со службой поддержки Apigee Edge и поделитесь с ней этой информацией.

1. Если вы используете общедоступное облако, предоставьте следующую информацию:
   • Название организации
   • Название среды
   • Название прокси-сервера API
   • Полная команда curl для воспроизведения ошибки
2. Если вы используете частное облако, предоставьте следующую информацию:
   • Полное сообщение об ошибке
   • Название среды
   • Пакет прокси-сервера 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. Подробную информацию о том, какие разделы этого руководства вы уже попробовали и какие другие действия предприняли, чтобы мы могли быстрее решить проблему.