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.
Otwórz dokumentację Apigee X. Informacje

Krótki opis problemu

W odpowiedzi na wywołania interfejsu API 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.

Ten błąd oznacza, że Edge nie udało się znaleźć serwera proxy interfejsu API dla określonego hosta wirtualnego i ścieżki.

Komunikat o błędzie

Aplikacja kliencka pobiera ten kod odpowiedzi:

HTTP/1.1 404 Not Found

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

{
   "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 usługi Edge

Najczęstsze kroki diagnostyki

Logi NGINX i procesora wiadomości pomogą Ci rozwiązać problem 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 we wpisach logu nie występują te pola:

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

Zanotuj identyfikator wiadomości w dziennikach.

Sprawdź logi procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log), aby sprawdzić, czy masz messaging.adaptors.http.flow.ApplicationNotFound dla konkretnego interfejsu API, czy masz unikalny identyfikator 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)

Powyższy dziennik zawiera kod błędu, a ten komunikat o błędzie:

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

Uwaga: podane wyżej wartości url i host mogą się różnić w zależności od serwera proxy interfejsu API, na którym występuje problem.

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

Routery brzegowe Apigee i procesory wiadomości używają zarówno nagłówka hosta, numeru portu, jak i ścieżek URI do kierowania ruchu do odpowiedniego serwera proxy interfejsu API. Niejednoznaczne określenie wielu hostów wirtualnych z tym samym aliasem hosta i numerem portu to udokumentowany antywzorzec i może prowadzić do nieoczekiwanych zachowań. Jednym z typowych błędów, które możesz zauważyć, jest błąd 404 z komunikatem Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

Zwykle jeśli istnieje wiele hostów wirtualnych z tym samym aliasem hosta, będą występować przejściowe błędy 404. Wynika to z faktu, że serwer proxy interfejsu API można skonfigurować tak, aby akceptował żądania tylko z jednego z hostów wirtualnych. Gdy żądania do interfejsu API będą kierowane do konkretnego hosta wirtualnego skonfigurowanego w serwerze proxy interfejsu API, otrzymasz odpowiedź. Jeśli jednak żądania do interfejsu API będą kierowane do innych hostów wirtualnych, do których serwer proxy interfejsu API nie jest skonfigurowany tak, aby je akceptować, interfejsy API nie powiodą się z powodu tych błędów 404.

Wykonaj instrukcje podane w sekcji 404 Nie można zidentyfikować serwera proxy dla hosta <nazwa hosta wirtualnego i url: <ścieżka>, a następnie rozwiąż ten problem. Jeśli żadna z przyczyn nie powoduje tego błędu, wykonaj poniższe czynności, aby sprawdzić, czy błędy 404 powodują hosty wirtualne ze zduplikowanymi aliasami hosta.

Diagnostyka

Aby sprawdzić, czy wiele hostów wirtualnych ma ten sam alias/numer portu, co prowadzi do błędów 404, użyj jednej z tych metod:

Interfejs Edge
Interfejsy API do zarządzania

Interfejs Edge

Wykonaj te instrukcje, aby określić, czy w interfejsie użytkownika Edge ma wiele hostów wirtualnych z tym samym aliasem/numerem portu hosta.

Jeśli na przykład zauważysz błąd 404 z adresem URL http://example.com:9001/proxy1, musisz sprawdzić, które hosty wirtualne mają alias hosta example.com i port 9001.

W chmurze publicznej i nowym interfejsie użytkownika Edge w Private Cloud:
1. Wybierz kartę Administracja.
2. Wybierz Hosty wirtualne.
3. W przypadku każdego środowiska użyj filtra wyszukiwania, aby określić hosty wirtualne pasujące do aliasu hosta, z którym zostały wywołane żądania do interfejsu API.
4. Jeśli znajdziesz wiele hostów wirtualnych używających tego samego aliasu hosta, przejdź do sekcji Rozwiązanie, aby rozwiązać ten problem.
Przykład:
W klasycznym interfejsie w Private Cloud:
1. Kliknij kartę Interfejsy API .
2. Kliknij Konfiguracja środowiska.
3. Wybierz Hosty wirtualne.
4. W przypadku każdego środowiska wyświetl listę hostów wirtualnych, aby sprawdzić, czy któreś z nich pasują do konkretnego aliasu hosta, z którym zostały wywołane żądania do interfejsu API.
5. Jeśli znajdziesz wiele hostów wirtualnych pasujących do tego samego aliasu hosta, przejdź do sekcji Rozwiązanie, aby rozwiązać ten problem.
Przykład:

Interfejsy API do zarządzania

Wykonaj te instrukcje, aby określić, czy istnieje wiele hostów wirtualnych z tym samym aliasem/numerem portu hosta za pomocą interfejsów API zarządzania.

Sprawdź definicję każdego hosta wirtualnego w każdym środowisku w organizacji, aby sprawdzić, które hosty wirtualne mają ten sam alias hosta i ten sam numer portu:

Jeśli na przykład zauważysz błąd 404 z adresem URL http://example.com:9001/proxy1, musisz sprawdzić, które hosty wirtualne mają alias hosta example.com i port 9001.

Pobierz listę środowisk

Użytkownik chmury publicznej:

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 chmury publicznej:

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" ]

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

Użytkownik chmury publicznej:

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 te 2 kroki dla innych środowisk w organizacji.

W tym przykładzie powtórz te kroki dla ś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 widać, że dwa hosty wirtualne default w 2 różnych środowiskach – test i dev – mają ten sam alias hosta example.com i ten sam numer portu 9001. To jest przyczyna błędów 404.

Jeśli znajdziesz wiele hostów wirtualnych pasujących do tego samego aliasu hosta, przejdź do sekcji Rozwiązanie, aby rozwiązać ten problem.

Rozdzielczość

Upewnij się, że każdy host wirtualny zawiera tylko unikalne kombinacje aliasów hosta i portów.
Jeśli zidentyfikujesz wiele hostów wirtualnych z tą samą kombinacją aliasu hosta i portów, musisz podać dla nich unikalny alias hosta.
Możesz je zaktualizować za pomocą interfejsu Edge lub Management API. Instrukcje znajdziesz w sekcji Modyfikowanie hosta wirtualnego.
Sprawdź, czy każdy alias hosta ma prawidłowy wpis DNS.
Uwaga: jeśli zduplikowany alias hosta został znaleziony na hoście wirtualnym skonfigurowanym na bezpiecznym porcie, takim jak 443, musisz kupić certyfikat zgodny z nową nazwą aliasu hosta lub nowy alias hosta w nazwie alternatywnej podmiotu SAN w istniejącym certyfikacie używanym w magazynie kluczy.

Jeśli w podanym wyżej przykładzie nasza konfiguracja wyglądała 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 w taki sposób, aby się nie nakładał.
Alias hosta zostanie zmieniony na example2.com.

Sprawdź, czy nowy alias hosta ma wpis DNS podobny do poprzedniego aliasu 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" : [  ]
}

Wykonaj ponownie wywołania interfejsu API do serwera proxy i sprawdź, czy regularnie otrzymujesz skuteczne 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, przejdź do artykułu Musisz zebrać informacje diagnostyczne.

Musisz zebrać informacje diagnostyczne

Jeśli problem nie ustąpi mimo wykonania powyższych instrukcji, zbierz poniższe informacje diagnostyczne i skontaktuj się z zespołem pomocy Apigee Edge:

Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:

Nazwa organizacji
Nazwa środowiska
Nazwa serwera proxy interfejsu API
Wykonaj polecenie curl, aby odtworzyć błąd 404
Jeśli błędy 404 nie występują obecnie, podaj informacje o strefie czasowej, w których wystąpiły błędy 404 w przeszłości.

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

Zaobserwowany pełny komunikat o błędzie dotyczący nieudanych żądań
Organizacja, nazwa środowiska i nazwa serwera proxy interfejsu API, w przypadku których zaobserwowano 404 błędu
Pakiet proxy 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
Okres z informacjami o strefie czasowej, w których wystąpiły błędy 404