‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

בעיות בניתוב גישה ב-Apigee

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

תיאור הבעיה

במקרים מסוימים, לקוחות חיצוניים לא יכולים לגשת ל-Apigee או להתחבר אליו באופן הרצוי. אלה כוללים כשלים בקישוריות רשת (כשלים בלחיצת יד של TLS) או תגובות של 4xx/5xx מ-Apigee.

הודעת השגיאה

כששולחים בקשת API מהלקוח אל Apigee, מוצגת שגיאת TLS handshake או תגובה מסוג 4xx/5xx, למרות שנראה שממשקי ה-API proxy תקינים בממשק המשתמש של Apigee.

סיבות אפשריות

מטרה	תיאור	קודי שגיאה
שגיאות TLS במאזן עומסים מסוג HTTPS	אתם מנהלים את הגדרת ה-TLS של מאזן העומסים ב-HTTPS. בודקים אם יש שגיאות TLS ביומנים של מאזן העומסים ב-HTTPS.	שגיאות לחיצת יד של TLS מכתובת ה-IP של מאזן העומסים
בקשות נחסמות על ידי Google Cloud Armor	אם אתם משתמשים ב-Google Cloud Armor, יכול להיות שיש כלל שחוסם את הבקשה.	קוד התגובה של ה-API עשוי להשתנות בהתאם להגדרות של Google Cloud Armor. כללי דחייה יכולים להחזיר תגובה מסוג `HTTP 403` (לא מורשה), `404` (הגישה נדחתה) או `502` (שער לא תקין), או אפילו קוד תגובה אחר.
מכונות וירטואליות של proxy ב-Apigee לא יכולות להעביר את התעבורה למופע Apigee	צריך לבדוק את ההגדרה של ה-proxy של נתב התנועה של Apigee API ואת תקינותו	`502 Server Error`
הגדרת רשת שגויה	מוודאים שהרשת הנכונה היא רשת עמיתים של Apigee VPC.	`502 Server error`
סביבות לא מצורפות במופע Apigee החדש שנוצר כחלק מהרחבת האזור	אחרי שיוצרים מופע חדש, למשל אזור שני, צריך לצרף אליו סביבות. אחרת, הוא לא יוכל להגיב לבקשות API.	`503 error response`

הגורם: שגיאות TLS במאזן עומסים ב-HTTPS

אבחון

מחפשים את אישור ה-TLS שמשויך למאזן העומסים.

שימוש במסוף Google Cloud :
1. ב- Google Cloud קונסולה, עבור אלאיזון עומסים עַמוּד.
  
  מעבר לדף Load balancing
2. לחץ על שם של מאזן העומסים. ייפתח הדף Load balancer details.
3. באזור Frontend, בעמודה IP:Port, ודא שאתה מסתכל על מאזן העומסים הנכון על ידי אימות כתובת ה-IP והפורט שלו.
4. בעמודה תעודה, לחץ על שם התעודה כדי להציג את תעודת ה-TLS.

באמצעות פקודה של gcloud:

מציגים את מאזני העומסים באמצעות הפקודה הבאה של gcloud. פקודה זו מציגה גם את המספר SSL_CERTIFICATES המשויך לכל מאזן עומסים.
```
gcloud compute target-https-proxies list --project=PROJECT_NAME
```
מחליפים את PROJECT_NAME בשם הפרויקט.

מוחזרת תשובה שדומה לדוגמה הבאה:
```
NAME: example-proxy-https-proxy
SSL_CERTIFICATES: example-ssl-cert
URL_MAP: example-proxy-url-map
REGION:
CERTIFICATE_MAP: 
```

הצג את אישור ה-TLS באמצעות הפקודה gcloud הבאה (זה בהנחה ש-

jq

או כלי דומה מותקן במחשב שלך):

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

מחליפים את CERTIFICATE_NAME בשם האישור. לדוגמה, example-ssl-cert.

מוחזרת תשובה שדומה לדוגמה הבאה:

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

מוודאים שהשם הנפוץ (CN) באישור זהה לשם המארח שהוגדר ב-Apigee > Admin > Environments > Groups. מוודאים שהאישור תקף ולא פג תוקף. אפשר להשתמש בפונקציה openssl כדי לבצע את הבדיקות האלה.

כדי לבדוק את אישור ה-TLS המוחזר על ידי מאזן העומסים, הפעל את הפקודה openssl הבאה ממחשב הלקוח שלך. בדוק אם האישור הזה תואם לזה שהוחזר בשלב 1 לעיל.
```
openssl s_client -connect LB_HOSTNAME_OR_IP:443 -servername LB_HOSTNAME -showcerts
```
מחליפים את מה שכתוב בשדות הבאים:
- LB_HOSTNAME_OR_IP: שם המארח או כתובת ה-IP של מאזן העומסים. לדוגמה, my-load-balancer.
- LB_HOSTNAME: שם המארח של מאזן העומסים. לדוגמה, my-hostname.
כדי לוודא שהתעודות תואמות, הפעל את הפקודה הבאה מהלקוח שלך:
```
echo | openssl s_client -connect HOST_NAME:443 -servername HOST_NAME | openssl x509 -noout -text | openssl md5
```
מחליפים את HOST_NAME בשם המארח שהוגדר ב-Apigee (Admin > Environments > Groups).

ולאחר מכן ודא שה-md5 תואם על ידי הפעלת הפקודה הבאה של gcloud:
```
gcloud compute ssl-certificates describe CERTIFICATE_NAME --project PROJECT_NAME --format json | jq -r '.certificate' | openssl x509 -noout -text | openssl md5
```
מחליפים את CERTIFICATE_NAME בשם האישור. לדוגמה, my-certificate.
אם האישורים של שלב 1 ו-שלב 2 תואמים (כלומר, אם ערכי md5 תואמים), המשך לאסוף packet capture בצד הלקוח כדי לחקור את כשל לחיצת היד של TLS. אפשר לבצע את לכידת המנות בצד הלקוח באמצעות כלים כמו Wireshark,‏ tcpdump או כלים מהימנים אחרים.
הפעל רישום ביומן במאזן העומסים על ידי ביצוע ההוראות בסעיף הפעלת רישום ביומן בשירות לקצה העורפי קיים.
בדוק את יומני ה- יומני של מאזן העומסים כדי לאתר שגיאות.

רזולוציה

אם תוקף האישור בניהול עצמי במאזן העומסים פג או שיש בו ערכי CN/SAN שגויים, יכול להיות שתצטרכו להחליף את האישור במאזן העומסים.
אם האישור שהוחזר על ידי מאזן העומסים בשלב 1 והאישור בשלב 2 אינם תואמים, ייתכן שמאזן העומסים מגיש אישור ישן/שגוי, ועליך להגיש פנייה לשירות הלקוחות של Google Cloud.
אם tcpdump מציין כשל בלחיצת יד בפרוטוקול TLS, צריך לבדוק אם הכשל בחיבור נובע ממאזן העומסים או מצד הלקוח.
- אם הכשל או איפוס החיבור הם מצד הלקוח, בדוק את יישום הלקוח שלך כדי להבין מדוע הוא מתנהג בצורה לא תקינה. לדוגמה, תוכל לבדוק את תצורת הרשת בצד הלקוח שלך או לוודא שליישום הלקוח יש קישוריות עם Apigee.
- אם אתם רואים שהאיפוס או הכשל נובעים ממאזן העומסים עצמו, כדאי לעיין במאמר בנושא פתרון בעיות כלליות בקישוריות ולשלוח כרטיס תמיכה ל-Google Cloud Customer Care אם צריך.
אם אתם רואים שגיאות ביומני מאזן העומסים, עיינו ב שגיאות 5XX לא מוסברות והגישו כרטיס תמיכה לCloud Customer Care במידת הצורך.

אם עדיין דרושה לך עזרה, אפשר לעיין במאמר בנושא איסוף מידע לצורך אבחון.

הגורם: Cloud Armor חוסם את הבקשות

אבחון

אם מוצגת תגובת שגיאה 403, 404 או 502 על סמך ההגדרה של Cloud Armor, צריך לבדוק את ההגדרה של מאזן העומסים ושל קבוצת ה-MIG כדי לוודא שהן מוגדרות בצורה נכונה ושהן תקינות.

אם אתם משתמשים ב-Google Cloud Armor בסביבת Google Cloud , כדאי לבדוק את ההגדרות של Google Cloud Armor כדי לראות אם יש כללים שחוסמים את הבקשה. ניתן למצוא את מדיניות האבטחה בסעיף הגדרת מדיניות אבטחה של Google Cloud Armor.
אם אתם לא בטוחים איזו כלל חוסם את התנועה, אתם יכולים לנסות להפעיל את הרישום ביומן במאזן העומסים, כמו שמתואר במאמר הפעלת רישום ביומן בשירות קצה עורפי קיים.
אחרי שמפעילים את רישום היומן, מריצים שאילתת יומנים כדי למצוא בקשות שנחסמו על ידי כללי המדיניות של Google Cloud Armor:
1. נכנסים לדף Logs Explorer במסוף Google Cloud .
  
  כניסה לדף Logs Explorer
2. מדביקים את השאילתה הבאה בחלונית Query:
```
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
```
3. לוחצים על Run query.
4. שם המדיניות הנאכפת מוצג ב-jsonPayload.enforcedSecurityPolicy.name בחלונית תוצאות שאילתה:

רזולוציה

כדי לפתור את הבעיה, צריך לשנות את הכללים או את ההגדרות של Google Cloud Armor בהתאם לצורך. אם אתם צריכים עזרה בנושא הזה, אתם יכולים לפנות אל Cloud Customer Care של Google Cloud.

סיבה: מכונות וירטואליות של Apigee Proxy אינן מסוגלות להעביר את התעבורה למופע Apigee

אבחון

אם לקוחות API מקבלים שגיאות HTTP 502 עם הודעת השגיאה הבאה, ייתכן שמכונות ה-VM של נתב התעבורה של Apigee API נמצאות במצב לא תקין.

ייתכן שיתקבלו שגיאות 502 כגון הבאות על ידי הלקוחות:
```
<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>
```
סקור את יומני מאזן העומסים עבור הודעות שגיאה כגון הבאות:
```
statusDetails: "failed_to_pick_backend"
severity: "WARNING"
```
יש קבוצה של מכונות וירטואליות (עם הקידומת apigee-proxy) שפועלות בקבוצת מופעי מכונה מנוהלים (MIG) ומעבירות את התעבורה למופע Apigee. אם אתם רואים הודעות כמו זו שלמעלה, בדקו את תקינות המכונות הווירטואליות apigee-proxy שחלק מקבוצת המופעים באמצעות השלבים הבאים:
1. נכנסים לדף Load balancing במסוף Google Cloud .
  
  מעבר לדף Load balancing
2. לוחצים על השם של מאזן העומסים. ייפתח הדף Load balancer details.
3. בקטע Backend, מוודאים שכל ה-backends של מאזן העומסים מסומנים בסימן וי ירוק בעמודה Healthy.
ודא שכתובת ה-IP של נקודת הקצה בתבנית MIG תואמת לכתובת ה-IP של מופע Apigee.

המכונות הווירטואליות apigee-proxy נוצרות באמצעות תבנית של מכונה. התבנית מגדירה את ENDPOINT כתובת ה-IP לחיבור לכתובת ה-IP של מופע Apigee.
1. קבל את כתובת ה-IP של מופע Apigee:
```
curl -s -H "Authorization: Bearer (gcloud auth print-access-token)" \
"https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/INSTANCE_NAME"
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫ORG_NAME: שם הארגון. לדוגמה, my-org.
  - ‫INSTANCE_NAME: השם של המכונה. לדוגמה, apigee-proxy-example.
2. אפשר גם לקבל את כתובת ה-IP של מופע Apigee באמצעות ממשק המשתמש של Apigee:
  1. ב-ממשק המשתמש של Apigee, לחץ על Admin Instances.
  2. בעמודה IP addresses מופיעה כתובת ה-IP:
3. קבל את כתובת ה-IP של ENDPOINT מהתבנית:
  1. נכנסים לדף Load balancing במסוף Google Cloud .
    
    עבור לאיזון עומסים
  2. לחץ על שם של מאזן העומסים. ייפתח הדף Load balancer details.
  3. באזור Backend, לוחצים על שם של שירות לקצה העורפי.
  4. באזור חברי קבוצת מופעים, לחץ על שם של תבנית.
  5. בדף התבנית, גוללים אל Custom metadata (מטא-נתונים בהתאמה אישית) שבו מוצגת כתובת ה-IP של ENDPOINT:
מוודאים שכתובת ה-IP של נקודת הקצה זהה לכתובת ה-IP של Apigee שמוחזרת בשלב 2. אם הוא לא תואם, עוברים אל פתרון הבעיה.

רזולוציה

אם apigee-proxy המכונות הווירטואליות בקבוצת המופעים מציגות סטטוס לא תקין, ודא שיש לך כלל חומת אש שמאפשר לטווחי כתובות ה-IP של איזון עומסים 130.211.0.0/22 ו-35.191.0.0/16 גישה ל-MIG.
נכנסים לדף Firewall במסוף Google Cloud .

כניסה לדף Firewall
מוודאים שקיים כלל חומת אש לתעבורת נתונים נכנסת (ingress) עם target-tag כמו gke-apigee-proxy וטווחים של כתובות IP של מקורות כמו 130.211.0.0/22 ו-35.191.0.0/16 ביציאה 443 TCP:

אם ל-MIG יש תג שונה מ-gke-apigee-proxy, צריך לוודא שהתג נוסף ל-target-tag בכלל חומת האש.

אם כלל חומת האש לא קיים, מוסיפים אותו.
אם כתובת ה-IP של ENDPOINT אינה תואמת לכתובת ה-IP של מופע Apigee, ייתכן שהמופע נמחק ונוצר מחדש, מה שיוביל לכתובת IP שכבר אינה תואמת לכתובת ה-IP בתבנית. כדי לעדכן את התבנית כך שתשתמש בכתובת ה-IP החדשה, פועלים לפי ההוראות במאמר שינוי כתובות IP של מופעים.

הסיבה: הגדרת רשת שגויה

אבחון

מריצים את הקריאה הבאה ל-API כדי למצוא את הערך של authorizedNetwork:

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

מוחזרת תשובה שדומה לדוגמה הבאה:

{
  "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"
}

בדוגמה זו, הערך עבור authorizedNetwork הוא ברירת המחדל.

מוודאים שהערך של authorizedNetwork זהה לרשת שמתבצעת איתה התאמה בין רשתות servicenetworking:
1. במסוף Google Cloud של פרויקט המארח, עוברים לדף קישור בין רשתות VPC שכנות.
  
  מעבר לקישור בין רשתות VPC שכנות (peering)
2. הערך המופיע עבור servicenetworking-googleapis-com ב-רשת VPC שלך צריך להיות זהה לערך המוחזר מקריאה ל-API. לדוגמה, default.
אם אתם משתמשים ב-VPC משותף, ודאו שערך authorizedNetwork הוא זהה לערך של ה-VPC בפועל בפרויקט המארח, אשר מחובר ל-servicenetworking.
1. נכנסים לדף VPC משותף במסוף Google Cloud .
  
  מעבר ל-VPC משותף
2. בחר את הפרויקט המארח.
3. הערך המופיע עבור servicenetworking-googleapis-com ב-רשת VPC שלך צריך להיות זהה לערך authorizedNetwork המוחזר מקריאה ל-API. לדוגמה, default.
מוודאים שקבוצת המופעים שמשויכת למאזן העומסים נמצאת באותה רשת כמו הערך authorizedNetwork:
1. נכנסים לדף Load balancing במסוף Google Cloud .
  
  מעבר לדף Load balancing
2. לחץ על שם של מאזן עומסים. נפתח דף פרטי מאזן העומסים. רשימה של קבוצות מופעים מוצגת באזור הצד האחורי:
3. לחץ על שם קבוצת מופעים. מוצג דף הסקירה כללית של קבוצת המופעים.
4. לוחצים על הכרטיסייה פרטים.
5. גוללים לקטע Networking (רשת):
6. מוודאים שהערך של Primary network זהה לערך של authorizedNetwork. לדוגמה, default.
7. לחץ על הכרטיסייה סקירה כללית.
8. במקטע חברי קבוצת מופעים, לחץ על שם המופע. יוצג הדף פרטים.
9. גלול אל הקטע ממשקי רשת:
10. ודא שערך ה-רשת זהה לערך של authorizedNetwork. לדוגמה, default.
11. עבור לכרטיסייה סקירה כללית וחזור על שלב ח עד שלב י עבור כל מופע במקטע חברי קבוצת מופעים.

רזולוציה

אם בשלב 2 או בשלב 3, הערך של authorizedNetwork לא זהה לרשת שמקושרת ל-servicenetworking, צריך לוודא שקישרתם את רשת ה-VPC הנכונה ל-servicenetworking באמצעות השלבים שמפורטים במאמר שלב 4: הגדרת Service Networking.
אם בשלב4f ו4j, ערכי הרשת אינם זהים ל-authorizedNetwork ערך, לאחר מכן ודא ש-authorizedNetwork האם הרשת מחוברת עםservicenetworking. אם הוא מחובר כהלכה, והרשת עדיין אינה זהה ל-authorizedNetwork, אז פירוש הדבר שקבוצת המופעים נוצרה באופן שגוי ועליך ליצור קשרCloud Customer Care.

סיבה: סביבה לא מחוברת במופע Apigee החדש שנוצר כחלק מהרחבת אזור

אבחון

אתה רואה שגיאת 503 בצד הלקוח. לדוגמה:
```
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
```
הערה: השגיאה 503 לא מוצגת במעקב הניפוי באגים כי הבקשות אף פעם לא מגיעות למעבד ההודעות של זמן הריצה.
אם אתה רואה503 שגיאות באזור השני מיד לאחר הרחבת אזור :
1. ודא שהסביבות מחוברות למופע החדש על ידי הפעלת קריאה ל-API הבאה:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/ORG_NAME/instances/NEW_INSTANCE/attachments"
```
  לדוגמה:
```
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://apigee.googleapis.com/v1/organizations/apigee-example-org/instances/apigee-proxy-example/attachments"
```
  מוחזרת תשובה שדומה לדוגמה הבאה:
```
{
  "attachments": [
    {
      "name": "9ed157df-5ef2-4cdc-b1d5-2643b480eb33",
      "environment": "dev",
      "createdAt": "1628153855420"
    },
    {
      "name": "a9e04dff-4ca4-4749-902f-5058e28c26a5",
      "environment": "prod",
      "createdAt": "1664517347106"
    }
  ]
}
```
  בדוגמה הזו, המופע שנקרא apigee-proxy-example מצורף לשתי סביבות: dev ו-prod.
2. מוודאים שקבוצת מופעי מכונה מנוהלים (MIG) באזור השני נוצרה ומוצגת כקבוצה תקינה:
  1. נכנסים לדף Load balancing במסוף Google Cloud .
    
    עבור לאיזון עומסים
  2. לוחצים על השם של מאזן העומסים. הדף Load balancer details נפתח.
  3. תחת Backend, אמורים לראות שני קבצי MIG; אחד עבור אזור 1 ואחד עבור אזור 2. מוודאים ששניהם תקינים:
  4. אמת את ה-MIG השני על ידי ביצוע השלבים בסעיף מכונות וירטואליות של Apigee Proxy אינן מסוגלות להעביר את התעבורה למופע Apigee.

רזולוציה

אם המופע החדש אינו מחובר לסביבה, צרפו את המופע לסביבה על ידי ביצוע ההוראות בסעיף צרפו סביבות למופע החדש.

אפשרות נוספת היא לוודא שמאזן העומסים מנתב את הבקשה לקצה האחורי הנכון, שאליו הסביבה כבר מחוברת. לדוגמה, של סביבה שאינה מיוצרת. ייתכן שתרצה לצרף זאת לאזור אחד בלבד; עם זאת, ייתכן שמאזן העומסים מנתב את הבקשה לאזור הלא נכון. תצטרך לעדכן את תצורת מאזן העומסים כדי לוודא שהוא מנתב לאזור הנכון.
אם קבוצת MIG לא תקינה, אפשר לעיין במאמר בנושא אבחון ופתרון בעיות בקטע מכונות וירטואליות של שרתי proxy של Apigee לא יכולות להעביר את התנועה למופע Apigee.

צריך לאסוף פרטי אבחון

אם הבעיה נמשכת גם אחרי שמבצעים את ההוראות שלמעלה, צריך לאסוף את נתוני האבחון הבאים ואז לפנות אל Cloud Customer Care:

ארגון Apigee
הסביבה וה-proxy ל-API שבהם נתקלתם בבעיה
סשן ניפוי באגים שהורד (אם הבעיה מתרחשת לסירוגין)
פלט תלתל מפורט של בקשה שנכשלה.
מאזן עומסים מוגדר לשליחת קריאות API ל-Apigee

בעיות בניתוב גישה ב-Apigee קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

תיאור הבעיה

הודעת השגיאה

סיבות אפשריות

הגורם: שגיאות TLS במאזן עומסים ב-HTTPS

אבחון

רזולוציה

הגורם: Cloud Armor חוסם את הבקשות

אבחון

רזולוציה

סיבה: מכונות וירטואליות של Apigee Proxy אינן מסוגלות להעביר את התעבורה למופע Apigee

אבחון

רזולוציה

הסיבה: הגדרת רשת שגויה

אבחון

רזולוציה

סיבה: סביבה לא מחוברת במופע Apigee החדש שנוצר כחלק מהרחבת אזור

אבחון

רזולוציה

צריך לאסוף פרטי אבחון

בעיות בניתוב גישה ב-Apigee