Zugriffsrouting-Probleme bei Apigee

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Für dieses Thema gibt es keine entsprechende Apigee Edge-Dokumentation.

Symptom

In einigen Fällen können externe Clients nicht auf Apigee zugreifen bzw. keine Verbindung wie gewünscht herstellen. Dazu gehören Netzwerkverbindungsfehler (TLS-Handshake-Fehler) und 4xx/5xx-Antworten von Apigee.

Fehlermeldung

Wenn Sie eine API-Anfrage von Ihrem Client an Apigee senden, tritt ein TLS-Handshake-Fehler oder eine 4xx/5xx-Antwort auf, obwohl die API-Proxys in der Apigee-Benutzeroberfläche möglicherweise fehlerfrei erscheinen.

Mögliche Ursachen

Ursache	Beschreibung	Fehlercodes
TLS-Fehler beim HTTPS-Load-Balancer	Sie verwalten die TLS-Konfiguration des HTTPS-Load-Balancers. Prüfen Sie alle TLS-Fehler in den HTTPS-Load-Balancer-Logs.	TLS-Handshake-Fehler von der IP-Adresse des Load-Balancers
Google Cloud Armor blockiert die Anfragen	Wenn Sie Google Cloud Armor verwenden, werden Anfragen möglicherweise von einer Regel blockiert.	Der API-Antwortcode kann je nach Google Cloud Armor-Konfiguration variieren. Regeln für das Ablehnen können eine Antwort vom Typ `HTTP 403` (Unauthorized), `404` (Access Denied) oder `502` (Bad Gateway) oder einen anderen Antwortcode zurückgeben.
Apigee-Proxy-VMs können Traffic nicht an die Apigee-Instanz weiterleiten	Die Proxy-Konfiguration des Apigee API-Traffic-Routers und dessen Zustand müssen untersucht werden.	`502 Server Error`
Fehlerhafte Netzwerkkonfiguration	Prüfen Sie, ob das richtige Netzwerk mit der Apigee-VPC verbunden ist.	`502 Server error`
Nicht angehängte Umgebungen auf der neuen Apigee-Instanz, die im Rahmen der Regionserweiterung erstellt wurden	Nachdem Sie eine neue Instanz erstellt haben, z. B. eine zweite Region, müssen Sie ihr Umgebungen hinzufügen. Andernfalls kann sie nicht auf API-Anfragen antworten.	`503 error response`

Ursache: TLS-Fehler am HTTPS-Load-Balancer

Diagnose

Suchen Sie das TLS-Zertifikat, das dem Load-Balancer zugeordnet ist.

Google Cloud Console verwenden:
1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
  
  Load-Balancing aufrufen
2. Klicken Sie auf den Namen des Lastenausgleichsmoduls. Die Seite Details: Load-Balancer wird geöffnet.
3. Prüfen Sie, ob im Bereich Frontend in der Spalte IP:Port der korrekte Load-Balancer angezeigt wird. Prüfen Sie dazu dessen IP-Adresse und Port.
4. Klicken Sie in der Spalte Zertifikat auf den Zertifikatsnamen, um das TLS-Zertifikat aufzurufen.

Verwenden eines gcloud-Befehls:

Listen Sie die Load-Balancer mit dem folgenden gcloud-Befehl auf. Dieser Befehl zeigt auch die den einzelnen Load-Balancern zugeordneten SSL_CERTIFICATES an.
```
gcloud compute target-https-proxies list --project=PROJECT_NAME
```
Ersetzen Sie PROJECT_NAME durch den Namen Ihres Projekts.

Es wird in etwa Folgendes zurückgegeben:
```
NAME: example-proxy-https-proxy
SSL_CERTIFICATES: example-ssl-cert
URL_MAP: example-proxy-url-map
REGION:
CERTIFICATE_MAP: 
```

Rufen Sie das TLS-Zertifikat mit dem folgenden gcloud-Befehl auf. Dies setzt voraus, dass

jq

oder ein ähnliches Tool auf Ihrem Computer installiert ist:

gcloud compute ssl-certificates describe CERTICATE_NAME \
--project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -text -noout

Ersetzen Sie CERTIFICATE_NAME durch den Zertifikatsnamen. Beispiel: example-ssl-cert.

Es wird in etwa Folgendes zurückgegeben:

certCertificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            51:3b:a4:60:fe:49:34:a2:09:af:14:85:96:a2:4f:d9
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1D4
        Validity
            Not Before: Jul 11 11:51:52 2023 GMT
            Not After : Oct  9 12:44:45 2023 GMT
        Subject: CN = 34.149.207.105.nip.io
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                .
                .

                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                A5:DB:7C:6A:8B:0B:7A:22:45:52:1E:85:29:32:77:18:A3:9D:87:76
            X509v3 Authority Key Identifier:
                keyid:25:E2:18:0E:B2:57:91:94:2A:E5:D4:5D:86:90:83:DE:53:B3:B8:92

            Authority Information Access:
                OCSP - URI:http://ocsp.pki.goog/s/gts1d4/qMhEcTt7LjA
                CA Issuers - URI:http://pki.goog/repo/certs/gts1d4.der

            X509v3 Subject Alternative Name:
                DNS:34.149.207.105.nip.io
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.11129.2.5.3

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crls.pki.goog/gts1d4/LjtNmxrQfWE.crl

Achten Sie darauf, dass der allgemeine Name (CN) im Zertifikat mit dem CN übereinstimmt, der in CN konfiguriert ist. Prüfen Sie, ob das Zertifikat gültig und nicht abgelaufen ist. Für diese Prüfungen können Sie openssl verwenden.

Führen Sie den folgenden openssl-Befehl auf Ihrem Clientcomputer aus, um das vom Load-Balancer zurückgegebene TLS-Zertifikat zu prüfen. Prüfen Sie, ob dieses Zertifikat mit dem in Schritt 1 oben zurückgegebenen Zertifikat übereinstimmt.
```
openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts
```
Ersetzen Sie Folgendes:
- LB_HOSTNAME_OR_IP: Hostname oder IP-Adresse des Load-Balancers. Beispiel: my-load-balancer.
- LB_HOSTNAME: Hostname des Load-Balancers. Zum Beispiel, my-hostname.
Führen Sie den folgenden Befehl in Ihrem Client aus, um zu überprüfen, ob die Zertifikate übereinstimmen:
```
echo | openssl s_client -connect HOST_NAME:443 -servername HOST_NAME | openssl x509 -noout -text | openssl md5
```
Ersetzen Sie HOST_NAME durch den in Apigee konfigurierten Hostnamen (Administrator > Umgebungen > Gruppen).

Prüfen Sie dann mit folgendem gcloud-Befehl, ob md5 übereinstimmt:
```
gcloud compute ssl-certificates describe CERTIFICATE_NAME --project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -noout -text | openssl md5
```
Ersetzen Sie CERTIFICATE_NAME durch den Namen des Zertifikats. z. B. my-certificate.
Stimmen die Zertifikate Schritt 1 und Schritt 2 überein (wenn die md5-Werte übereinstimmen), fahren Sie mit dem Erfassen eines clientseitigen packet capture fort, um den TLS-Handshake-Fehler zu untersuchen. Sie können die Paketerfassung auf der Clientseite mit Tools wie Wireshark, tcpdump oder anderen zuverlässigen Tools bearbeiten.
Aktivieren Sie Logs auf dem Load-Balancer gemäß der Anleitung unter Logging in einem vorhandenen Backend-Dienst aktivieren.
Prüfen Sie die Logs des Load-Balancers auf Fehler.

Lösung

Wenn Ihr selbstverwaltetes Zertifikat auf dem Load-Balancer abgelaufen ist oder falsche CN/SAN-Werte hat, müssen Sie möglicherweise das Zertifikat auf dem Load-Balancer ersetzen.
Stimmen das vom Load-Balancer in Schritt 1 zurückgegebene Zertifikat und das Zertifikat aus Schritt 2 nicht überein, so kann dies bedeuten, dass der Load-Balancer ein veraltetes/falsches Zertifikat bereitstellt. In diesem Fall sollten Sie ein Ticket beim Google Cloud Customer Care einreichen.
Wenn ein tcpdump auf einen TLS-Handshake-Fehler hinweist, prüfen Sie, ob der Verbindungsfehler vom Load-Balancer oder auf der Clientseite stammt.
- Wenn der Fehler oder das Zurücksetzen der Verbindung auf der Clientseite erfolgt, prüfen Sie Ihre Clientanwendung, um festzustellen, warum sie sich abweichend verhält. Sie können beispielsweise die clientseitige Netzwerkkonfiguration prüfen oder nachsehen, ob die Clientanwendung mit Apigee verbunden ist.
- Wenn der Fehler/das Zurücksetzen beim Load-Balancers selbst auftritt, lesen Sie den Abschnitt Fehlerbehebung bei allgemeinen Verbindungsproblemen und reichen Sie ein Ticket beim Google Cloud Customer Care ein, wenn erforderlich.
Wenn in den Load-Balancer-Logs Fehler vermerkt sind, finden Sie unter Unklare 5XX-Fehler weitere Informationen und reichen Sie bei Bedarf ein Ticket beim Google Cloud Customer Care ein.

Wenn Sie weiterhin Hilfe benötigen, lesen Sie den Abschnitt Erfassen von Diagnoseinformationen erforderlich.

Ursache: Cloud Armor blockiert die Anfragen

Diagnose

Wird eine der Fehlermeldungen 403, 404 oder 502 basierend auf der Cloud Armor-Konfiguration angezeigt, prüfen Sie den Load-Balancer und die MIG-Konfiguration, um zu bestätigen, dass diese Elemente richtig konfiguriert sind und funktionsfähig wirken.

Wenn Sie Google Cloud Armor in Ihrer Google Cloud-Umgebung verwenden, prüfen Sie die Google Cloud Armor-Konfiguration auf Regeln, die die Anfrage blockieren könnten. Die Sicherheitsrichtlinien finden Sie unter Google Cloud Armor-Sicherheitsrichtlinien konfigurieren.
Wenn Sie nicht sicher sind, welche Regel den Traffic ablehnt, können Sie versuchen, das Logging am Load-Balancer zu aktivieren, wie unter Logging für einen vorhandenen Backend-Dienst aktivieren beschrieben.
Sobald das Logging aktiviert ist, führen Sie eine Logabfrage aus, um alle Anfragen zu finden, die durch Google Cloud Armor-Richtlinien blockiert werden:
1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
  
  Zum Log-Explorer
2. Fügen Sie Folgendes in den Bereich Abfrage ein:
```
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
```
3. Klicken Sie auf Abfrage ausführen.
4. Der Name der erzwungenen Richtlinie wird in jsonPayload.enforcedSecurityPolicy.name im Bereich Abfrageergebnisse angezeigt:

Lösung

Passen Sie die Google Cloud Armor-Regeln/-Konfiguration an Ihre Anforderungen an, um dieses Problem zu beheben. Wenn Sie dabei Unterstützung benötigen, wenden Sie sich an Google Cloud Customer Care.

Ursache: Apigee-Proxy-VMs können Traffic nicht an die Apigee-Instanz weiterleiten

Diagnose

Erhalten API-Clients HTTP 502-Fehler mit der folgenden Fehlermeldung, befinden sich die Proxy-VMs des Apigee API-Trafficrouters möglicherweise in einem fehlerhaften Zustand.

502-Fehler wie die folgenden können von den Clients empfangen werden:
```
<html><head> <meta http-equiv="content-type"
  content="text/html;charset=utf-8"> <title>502 Server Error</title> </head>
  <body text=#000000 bgcolor=#ffffff> <h1>Error: Server Error</h1> <h2>The
  server encountered a temporary error and could not complete your
  request.<p>Please try again in 30 seconds.</h2> <h2></h2> </body></html>
```
Prüfen Sie die Load-Balancer-Logs auf Fehlermeldungen wie die folgenden:
```
statusDetails: "failed_to_pick_backend"
severity: "WARNING"
```
In einer verwalteten Instanzgruppe (MIG) wird eine Reihe von VMs (mit dem Präfix apigee-proxy) ausgeführt, die Traffic an die Apigee-Instanz weiterleiten. Werden Nachrichten wie die oben gezeigten angezeigt, prüfen Sie den Status der apigee-proxy-VMs in der Instanzgruppe anhand der folgenden Schritte:
1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
  
  Load-Balancing aufrufen
2. Klicken Sie auf den Namen des Lastenausgleichsmoduls. Die Seite Details: Load-Balancer wird geöffnet.
3. Prüfen Sie im Abschnitt Back-End, ob alle Load-Balancer-Back-Ends in der Spalte Fehlerfrei ein grünes Häkchen haben.
Prüfen Sie, ob die IP-Adresse des Endpunkts in der MIG-Vorlage mit der IP-Adresse der Apigee-Instanz übereinstimmt.

Die apigee-proxy-VMs werden mit einer Instanzvorlage erstellt. Die Vorlage definiert die IP-Adresse ENDPOINT für die Verbindung zur IP-Adresse der Apigee-Instanz.
1. Rufen Sie die IP-Adresse der Apigee-Instanz ab:
```
curl -s -H "Authorization: Bearer (gcloud auth print-access-token)" \
"https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/INSTANCE_NAME"
```
  Ersetzen Sie Folgendes:
  - ORG_NAME: Der Name Ihrer Organisation. Beispiel: my-org.
  - INSTANCE_NAME: Der Name der Instanz. Beispiel: apigee-proxy-example.
2. Oder rufen Sie die IP-Adresse der Apigee-Instanz über die Apigee-Benutzeroberfläche ab:
  1. Klicken Sie in der Apigee-Benutzeroberfläche auf Administrator > Instanzen.
  2. In der Spalte IP-Adressen wird die IP-Adresse aufgeführt:
3. Rufen Sie die IP-Adresse ENDPOINT aus der Vorlage ab:
  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
    
    Load-Balancing aufrufen
  2. Klicken Sie auf den Namen des Lastenausgleichsmoduls. Die Seite Details: Load-Balancer wird geöffnet.
  3. Klicken Sie im Bereich Back-End auf den Namen eines Back-End-Dienstes.
  4. Klicken Sie im Bereich Instanzgruppenmitglieder auf einen Vorlagennamen.
  5. Scrollen Sie auf der Vorlagenseite zu Benutzerdefinierte Metadaten. Hier wird die IP-Adresse ENDPOINT angezeigt:
Achten Sie darauf, dass die ENDPUNKT-IP-Adresse mit der in Schritt 2 zurückgegebenen Apigee-IP-Adresse übereinstimmt. Stimmen diese Elemente nicht übereinstimmt, gehen Sie zu Lösung.

Lösung

Wenn die apigee-proxy-VMs in der Instanzgruppe einen Problemstatus anzeigen, prüfen Sie, ob eine Firewallregel vorhanden ist, mit der das Load-Balancing auf die IP-Adressbereiche 130.211.0.0/22 und 35.191.0.0/16 der MIG zugreifen kann.
Rufen Sie in der Google Cloud Console die Seite Firewall auf.

Zur Firewall
Achten Sie darauf, dass mit target-tag eine Firewallregel für eingehenden Traffic wie gke-apigee-proxy und Quell-IP-Bereiche wie 130.211.0.0/22 und 35.191.0.0/16 über den Port 443 TCP vorhanden sind:

Wenn die MIG ein anderes Tag als gke-apigee-proxy hat, achten Sie darauf, dass das Tag dem target-tag in der Firewallregel hinzugefügt wird.

Ist die Firewallregel nicht vorhanden, fügen Sie sie hinzu.
Wenn die ENDPUNKT-IP-Adresse nicht mit der IP-Adresse der Apigee-Instanz übereinstimmt, ist es möglich, dass die Instanz gelöscht und neu erstellt wurde. Dies würde zu einer IP-Adresse führen, die nicht mehr mit der IP-Adresse in der Vorlage übereinstimmt. Folgen Sie der Anleitung unter Instanz-IP-Adressen ändern, um die Vorlage für die Verwendung der neuen IP-Adresse zu aktualisieren.

Ursache: Fehlerhafte Netzwerkkonfiguration

Diagnose

Führen Sie folgenden API-Aufruf aus, um den Wert für authorizedNetwork zu finden:

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME"

Es wird in etwa Folgendes zurückgegeben:

{
  "name": "apigee-example-org",
  "createdAt": "1621287579456",
  "lastModifiedAt": "1674063833580",
  "environments": [
    "test"
  ],
  "properties": {
    "property": [
      {
        "name": "features.mart.connect.enabled",
        "value": "true"
      },
      {
        "name": "features.hybrid.enabled",
        "value": "true"
      }
    ]
  },
  "analyticsRegion": "us-west1",
  "authorizedNetwork": "default",
  "runtimeType": "CLOUD",
  "subscriptionType": "PAID",
  "caCertificate": "certificate-number",
  "runtimeDatabaseEncryptionKeyName": "projects/apigee-example-org/locations/us-west1/keyRings/my-database-key-ring/cryptoKeys/my-database-key",
  "projectId": "apigee-example-org",
  "state": "ACTIVE",
  "billingType": "SUBSCRIPTION",
  "addonsConfig": {
    "advancedApiOpsConfig": {},
    "integrationConfig": {},
    "monetizationConfig": {}
  },
  "apigeeProjectId": "l09587a43efde330cp-tp"
}

In diesem Beispiel ist der Wert für authorizedNetwork der Standardwert.

Prüfen Sie, ob der authorizedNetwork-Wert mit dem Netzwerk übereinstimmt, das über Peering mit servicenetworking verbunden ist:
1. Rufen Sie in der Google Cloud Console des Hostprojekts die Seite VPC-Netzwerk-Peering auf.
  
  Zum VPC-Netzwerk-Peering
2. Der unter Ihr VPC-Netzwerk für servicenetworking-googleapis-com aufgeführte Wert muss mit dem vom API-Aufruf zurückgegebenen Wert übereinstimmen. Beispiel: default
Wenn Sie eine freigegebene VPC verwenden, muss der authorizedNetwork-Wert den Wert der tatsächlichen VPC im Hostprojekt haben, der per Peering mit servicenetworking verbunden ist.
1. Rufen Sie in der Google Cloud Console die Seite Freigegebene VPC auf.
  
  Zu Shared VPC gehen
2. Wählen Sie das Hostprojekt aus.
3. Der unter Ihr VPC-Netzwerk für servicenetworking-googleapis-comaufgeführte Wert muss mit dem vom API-Aufruf zurückgegeben Wert authorizedNetwork übereinstimmen. Beispiel: default
Prüfen Sie, ob die mit dem Load-Balancer verknüpfte Instanzgruppe dem Netzwerk mit dem authorizedNetwork-Wert entspricht.
1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
  
  Load-Balancing aufrufen
2. Klicken Sie auf den Namen eines Load-Balancers. Die Seite Details: Load-Balancer wird geöffnet. Eine Liste der Instanzgruppen wird im Bereich Back-End angezeigt:
3. Klicken Sie auf den Namen einer Instanzgruppe. Die Seite Übersicht der Instanzgruppe wird angezeigt.
4. Klicken Sie auf den Tab Details.
5. Scrollen Sie zum Abschnitt Netzwerk:
6. Prüfen Sie, ob das primäre Netzwerk hier mit dem Wert authorizedNetwork übereinstimmt. Beispiel: default
7. Klicken Sie auf den Tab Übersicht.
8. Klicken Sie im Bereich Instanzgruppenmitglieder auf den Namen einer Instanz. Die Seite Details wird angezeigt.
9. Scrollen Sie zum Bereich Netzwerkschnittstellen:
10. Prüfen Sie, ob der Wert Netzwerk mit dem authorizedNetwork-Wert übereinstimmt. Beispiel: default
11. Wechseln Sie zum Tab Übersicht und wiederholen Sie Schritt h bis Schritt j für alle Instanzen im Bereich Instanzgruppenmitgliedern.

Lösung

Wenn in Schritt 2 oder Schritt 3 der Wert authorizedNetwork nicht mit dem Netzwerk übereinstimmt, das über Peering mit servicenetworking verbunden ist, prüfen Sie, ob Sie das richtige VPC-Netzwerk mit servicenetworking verbunden haben. Führen Sie dazu die Schritte unter Schritt 4: Dienstnetzwerk konfigurieren aus.
Wenn in Schritt 4f und 4j die Netzwerkwerte nicht mit dem authorizedNetwork-Wert übereinstimmen, prüfen Sie, ob authorizedNetwork das per Peering mit servicenetworking. verbundene Netzwerk ist. Falls das Peering korrekt ist und das Netzwerk trotzdem nicht mit authorizedNetwork, übereinstimmt, bedeutet dies, dass die Instanzgruppe fehlerhaft erstellt wurde. Sie sollten sich an den Google Cloud Customer Care wenden.

Ursache: Nicht angehängte Umgebung auf der neuen Apigee-Instanz, die im Rahmen der Regionserweiterung erstellt wurde

Diagnose

Auf der Clientseite wird ein 503-Fehler angezeigt. Beispiel:
```
HTTP/2 503
date: Thu, 08 Jun 2023 07:22:15 GMT
content-length: 0
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
```
Hinweis: Dieser 503-Fehler wird im Debug-Trace nicht angezeigt, da die Anfragen den Laufzeit-Nachrichtenprozessor nie erreichen.
Wenn in der zweiten Region nach einer Regionserweiterung sofort 503-Fehler auftreten:
1. Prüfen Sie, ob die Umgebungen an die neue Instanz angehängt sind. Führen Sie dazu folgenden API-Aufruf aus:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/NEW_INSTANCE/attachments"
```
  Beispiel:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/apigee-example-org/instances/apigee-proxy-example/attachments"
```
  Es wird in etwa Folgendes zurückgegeben:
```
{
  "attachments": [
    {
      "name": "9ed157df-5ef2-4cdc-b1d5-2643b480eb33",
      "environment": "dev",
      "createdAt": "1628153855420"
    },
    {
      "name": "a9e04dff-4ca4-4749-902f-5058e28c26a5",
      "environment": "prod",
      "createdAt": "1664517347106"
    }
  ]
}
```
  In diesem Beispiel ist die Instanz mit dem Namen apigee-proxy-example an zwei Umgebungen angehängt: dev und prod.
2. Prüfen Sie, ob die verwaltete Instanzgruppe (MIG) für die zweite Region erstellt wurde und als funktionsfähig angezeigt wird:
  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
    
    Load-Balancing aufrufen
  2. Klicken Sie auf den Namen des Lastenausgleichsmoduls. Die Seite Details: Load-Balancer wird geöffnet.
  3. Unter Backend sollten zwei MIGs angezeigt werden: eine für Region 1 und eine für Region 2. Prüfen Sie, ob beide fehlerfrei sind:
  4. Um die zweite MIG zu validieren führen Sie die Schritte unter Apigee-Proxy-VMs können den Traffic nicht an die Apigee-Instanz weiterleiten aus.

Lösung

Wenn die neue Instanz nicht an die Umgebung angehängt ist, hängen Sie die Instanz an die Umgebung an. Folgen Sie dazu der Anleitung unter Umgebungen an die neue Instanz anhängen.

Eine weitere Option besteht darin, dass der Load-Balancer die Anfrage an das richtige Backend weiterleitet, falls die Umgebung bereits angehängt ist. Beispiel: In einer Nicht-Produktionsumgebung. Eventuell möchten Sie dies nur mit einer Region verknüpfen. Der Load-Balancer leitet die Anfrage jedoch möglicherweise an die falsche Region weiter. Sie müssen die Konfiguration des Load-Balancers aktualisieren, damit er an die richtige Region weiterleitet.
Wenn eine MIG fehlerhaft ist, sieheDiagnose und Lösung in Apigee-Proxy-VMs können Traffic nicht an die Apigee-Instanz weiterleiten.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Google Cloud-Support:

Apigee-Organisation
Umgebung und API-Proxy, wo das Problem auftritt
Heruntergeladene Debug-Sitzung (bei vorübergehenden Problemen)
Ausführliche curl-Ausgabe einer fehlgeschlagenen Anfrage.
Load-Balancer, der zum Senden von API-Aufrufen an Apigee konfiguriert ist