Ta strona została przetłumaczona przez Cloud Translation API.

404 Wiele hostów wirtualnych z tym samym aliasem hosta

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 404 z komunikatem Not Found i komunikatem o błędzie Unable to identify proxy for host: VIRTUAL_HOST and url: PATH w odpowiedzi na wywołania interfejsu API.

Ten błąd oznacza, że Edge nie znalazł serwera proxy interfejsu API dla określonego hosta wirtualnego i ścieżki.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 404 Not Found

Możesz też zobaczyć komunikat o błędzie podobny do tego poniżej:

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

Możliwe przyczyny

Przyczyna	Opis	Instrukcje rozwiązywania problemów dotyczące
Host wirtualny ze zduplikowanym aliasem hosta	Wiele hostów wirtualnych ma ten sam alias hosta i ten sam numer portu.	Użytkownicy chmury publicznej i prywatnej Edge

Typowe kroki diagnostyki

Logi NGINX i logi procesora wiadomości pomogą w rozwiązywaniu problemu z błędem 404. Aby sprawdzić dzienniki, wykonaj te czynności:

Wyświetl logi NGINX za pomocą tego polecenia:

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

Sprawdź, czy wpisy logu zawierają te pola:

Pole	Wartość
`Upstream_status, status`	`404`
`X-Apigee-fault-code`	`messaging.adaptors.http.flow.ApplicationNotFound`

Zanotuj identyfikator wiadomości widoczny w dziennikach.

Sprawdzanie logów procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log), aby sprawdzić, czy wartość messaging.adaptors.http.flow.ApplicationNotFound dla konkretnego interfejsu API lub jeśli posiadasz unikalny identyfikatora wiadomości z kroku 2 dla żądania do interfejsu API.
Przykładowy komunikat o błędzie z dziennika procesora wiadomości

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)

Kod błędu i komunikat o błędzie w powyższym dzienniku wygląda tak:

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

Uwaga: powyższe reguły url i host mogą się różnić w zależności od serwera proxy interfejsu API na których występuje problem.

Przyczyna: wiele hostów wirtualnych z tym samym aliasem hosta i numerem portu

Routery brzegowe Apigee i procesory wiadomości używają zarówno nagłówka hosta, numeru portu, jak i ścieżek URI aby kierować ruch do odpowiedniego serwera proxy interfejsu API. podawanie niejednoznacznych definicji, np. wielu wirtualnych hosty z tym samym aliasem hosta i numerem portu są udokumentowane antywzorek, może prowadzić do nieoczekiwanych zachowań. Jednym z najczęstszych błędów jest 404 błąd z komunikatem Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Zazwyczaj, gdy istnieje wiele hostów wirtualnych z tym samym aliasem hosta, przejściowe błędy 404. Dzieje się tak, ponieważ można skonfigurować określony serwer proxy interfejsu API akceptacja żądań tylko na jednym z hostów wirtualnych. Gdy żądania do interfejsu API są kierowane do na konkretnym hoście wirtualnym skonfigurowanym na serwerze proxy interfejsu API, otrzymasz odpowiedź pomyślnie. Jednak gdy żądania do interfejsu API są kierowane do innych hostów wirtualnych, do których nie skonfigurowano do akceptowania żądań, interfejsy API przestaną działać w przypadku tych 404 .

Postępuj zgodnie z instrukcjami podanymi w 404 Nie udało się zidentyfikować serwera proxy dla hosta: <nazwa hosta wirtualnego> i url: <path> oraz jak go rozwiązać. Jeśli żadna z przyczyn tego błędu nie prowadzi do tego błędu, wykonaj poniższe czynności: poniżej, aby sprawdzić, czy hosty wirtualne ze zduplikowanymi aliasami hostów są przyczyną błędu 404 .

Diagnostyka

Użyj jednej z tych metod, aby sprawdzić, czy istnieje wiele hostów wirtualnych mających ten sam alias/port hosta (#), który prowadzi do błędów 404:

Interfejs Edge
Interfejsy API do zarządzania

Interfejs Edge

Wykonaj te instrukcje, aby sprawdzić, czy istnieje kilka hostów wirtualnych mających tego samego hosta alias/port # za pomocą interfejsu Edge.

Jeśli na przykład zaobserwujesz błąd 404 dotyczący adresu URL http://example.com:9001/proxy1, musisz sprawdzić, które hosty wirtualne mają alias hosta example.com i port 9001.

W Public Cloud i nowym interfejsie Edge w Private Cloud:
1. Wybierz kartę Administracja.
2. Wybierz Virtual Hosts (Hosty wirtualne).
3. W przypadku każdego środowiska użyj filtra wyszukiwania, aby znaleźć wirtualny Hosty zgodne z konkretnym aliasem hosta używanym przez interfejs API. Liczba wywołanych żądań: .
4. Jeśli znajdziesz kilka hostów wirtualnych korzystających z tego samego aliasu hosta, otwórz Rozwiązanie.
Na przykład:
W klasycznym interfejsie użytkownika w Private Cloud:
1. Wybierz kartę Interfejsy API .
2. Kliknij Konfiguracja środowiska.
3. Wybierz Virtual Hosts (Hosty wirtualne).
4. W przypadku każdego środowiska wyświetl listę hostów wirtualnych, aby sprawdzić, czy któreś z nich są zgodne. konkretny alias hosta, z którym były wywoływane żądania do interfejsu API;
5. Jeśli znajdziesz kilka hostów wirtualnych pasujących do tego samego aliasu hosta, otwórz stronę Rozwiązanie.
Przykład:

Interfejsy API do zarządzania

Wykonaj te instrukcje, aby sprawdzić, czy istnieje kilka hostów wirtualnych mających tego samego hosta alias/port # za pomocą interfejsów API zarządzania.

Pobierz definicję każdego z hostów wirtualnych w każdym ze środowisk w organizacji, aby sprawdzić, które hosty wirtualne mają ten sam alias hosta i numer portu:

Jeśli na przykład zaobserwujesz błąd 404 dotyczący adresu URL http://example.com:9001/proxy1, musisz znaleźć hosty mają alias hosta example.com i port 9001.

Pobieranie listy środowisk

Użytkownik Public Cloud:

curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments -u USERNAME

Użytkownik Private Cloud:

curl -v -X GET http://MANAGEMENT_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments -u USERNAME

Gdzie:

ORGANIZATION_NAME to nazwa organizacji

Przykład:

curl http://127.0.0.1:8080/v1/organizations/myorg/environments -u USERNAME

[ "prod", "test", "dev" ]

Pobieranie listy hostów wirtualnych w środowisku

Użytkownik Public Cloud:

curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts -u USERNAME

Użytkownik Private Cloud:

curl -v -X GET http://MANAGEMENT_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts -u USERNAME

Gdzie:

ORGANIZATION_NAME to nazwa organizacji

ENVIRONMENT_NAME to nazwa środowiska.

Przykład:

curl http://127.0.0.1:8080/v1/organizations/myorg/environments/test/virtualhosts -u USERNAME

[ "default" ]

Pobierz definicję każdego z hostów wirtualnych w środowisku.

Użytkownik Public Cloud:

curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUAL_HOST_NAME  -u USERNAME

Użytkownik Private Cloud:

curl -v -X GET http://MANAGEMENT_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUAL_HOST_NAME -u USERNAME

Gdzie:

ORGANIZATION_NAME to nazwa organizacji

ENVIRONMENT_NAME to nazwa środowiska.

VIRTUAL_HOST_NAME to nazwa hosta wirtualnego

Przykład:

curl http://127.0.0.1:8080/v1/organizations/myorg/environments/test/virtualhosts/default -u USERNAME

{
  "hostAliases" : [ "example.com" ],
  "interfaces" : [ ],
  "listenOptions" : [ ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [ ]
}

Powtórz powyższe 2 kroki w przypadku innych środowisk w organizacji.

W tym przykładzie powtórz te czynności w przypadku środowiska dev:

curl http://127.0.0.1:8080/v1/organizations/myorg/environments/dev/virtualhosts -u USERNAME

[ "default" ]

curl http://127.0.0.1:8080/v1/organizations/myorg/environments/dev/virtualhosts/default -u USERNAME

{
  "hostAliases" : [ "example.com" ],
  "interfaces" : [ ],
  "listenOptions" : [ ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [ ]
}

W tym przykładzie możesz zobaczyć, że dwa hosty wirtualne default w 2 różnych środowiskach: test i dev. zawierają ten sam alias hosta example.com i numer portu 9001. To jest przyczyna 404 błędów.

Jeśli znajdziesz kilka hostów wirtualnych pasujących do tego samego aliasu hosta, otwórz stronę Rozwiązanie.

Rozdzielczość

Upewnij się, że każdy host wirtualny zawiera tylko unikalne kombinacje aliasów hosta i portów.
Zidentyfikujesz wiele hostów wirtualnych z tymi samymi kombinacjami aliasów hosta i portów musisz podać unikalne aliasy hosta.
Możesz je zaktualizować za pomocą interfejsu Edge UI lub interfejsu Management API. Instrukcje znajdziesz w tym artykule poniżej Modyfikowanie hosta wirtualnego.
Upewnij się, że każdy alias hosta ma prawidłowy wpis DNS.
Uwaga: jeśli na hoście wirtualnym skonfigurowanym na bezpiecznym serwerze jest zduplikowany alias hosta port, taki jak 443, musisz kupić certyfikat zgodny z nowym hostem nazwa aliasu lub nowy alias hosta w sieci SAN (Subject Alternative Name) w istniejącym certyfikacie używane w magazynie kluczy.

W powyższym przykładzie konfiguracja wygląda tak:

curl -X GET http://localhost:8080/v1/organizations/myorg/environments -u user

[ "prod", "test", "dev" ]

curl -X GET http://localhost:8080/v1/organizations/myorg/environments/test/virtualhosts/default -u user

{
  "hostAliases" : [ "example.com" ],
  "interfaces" : [  ],
  "listenOptions" : [  ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [  ]
}

curl -X GET http://localhost:8080/v1/organizations/myorg/environments/dev/virtualhosts/default -u user

{
  "hostAliases" : [ "example.com" ],
  "interfaces" : [  ],
  "listenOptions" : [  ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [  ]
}

Możesz zaktualizować nieprawidłowego hosta wirtualnego, tak aby się nie nakładały.
Zaktualizuje to alias hosta na example2.com.

Sprawdź, czy nowy alias hosta ma podobny wpis DNS co poprzedni alias hosta.

curl -X GET http://localhost:8080/v1/organizations/myorg/environments/dev/virtualhosts/default -u user -H 'Content-Type: application/json' -d '{
  "hostAliases" : [ "example2.com" ],
  "interfaces" : [  ],
  "listenOptions" : [  ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [  ]
}' -i

HTTP/1.1 200 OK
Date: Tue, 02 Feb 2021 20:54:29 GMT
Content-Type: application/json
X-Apigee.user: user
X-Apigee.organization: myorg
X-Apigee.environment: dev
X-Apigee.backends: management-server
Date: Tue, 02 Feb 2021 20:54:29 GMT
Content-Length: 152

{
  "hostAliases" : [ "example2.com" ],
  "interfaces" : [  ],
  "listenOptions" : [  ],
  "name" : "default",
  "port" : "9001",
  "retryOptions" : [  ]
}

Ponownie zwróć się do serwera proxy z wywołaniami interfejsu API i sprawdź, czy otrzymujesz prawidłowe odpowiedzi:

curl http://example.com:9001/proxy1

{
    "slideshow": {
	    "author": "Yours Truly",
		"date": "date of publication",
		"slides": [
		    {
			    "title": "Wake up to WonderWidgets!",
				"type:": "all"
			},
			{
			    "items": [
				    "Why WonderWidgets are great",
					"Who buys WonderWidgets"
				],
				"title": "Overview",
				"type": "all"
			}
		],
		"title": "Sample Slide Show"
    }

}

Jeśli problem nadal występuje, przeczytaj artykuł Wymagane są informacje diagnostyczne.

Musi zbierać informacje diagnostyczne

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zwróć uwagę na informacje diagnostyczne, a następnie skontaktuj się z zespołem pomocy Apigee Edge:

Jeśli jesteś użytkownikiem Public Cloud, podaj te informacje:

Nazwa organizacji
Nazwa środowiska
Nazwa serwera proxy interfejsu API
Wykonaj polecenie curl, aby odtworzyć błąd 404
Jeśli błędy typu 404 nie występują obecnie, podaj przedział czasu z informacjami o strefie czasowej, gdy w przeszłości wystąpiły błędy 404.

Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:

Pełny komunikat o błędzie zaobserwowany dla nieudanych żądań
Organizacja, nazwa środowiska i nazwa serwera proxy interfejsu API, które obserwujesz 404 błędu
Pakiet serwera proxy interfejsu API
Logi dostępu NGINX
/opt/apigee/var/log/edge-router/nginx/ORGANIZATION_NAME~ENVIRONMENT_NAME.PORT#_access_log
Logi procesora wiadomości
/opt/apigee/var/log/edge-message-processor/logs/system.log
Przedział czasu z informacjami o strefie czasowej, w którym wystąpiły błędy 404.