עדיפות משתני פרוקסי ועקיפה ב-gRPC C-Core
עקבו אחר עדיפות הפרוקסי והעקיפה של gRPC Core בלי להניח שהטמעת gRPC אחרת משתמשת באותו ממפה.
שינוי http_proxy עשוי לא לעשות דבר כאשר הגדרת gRPC בעדיפות גבוהה יותר כבר קיימת. התחילו בזיהוי ההטמעה: ההתנהגות הבאה שייכת לממפה ברירת המחדל של פרוקסי HTTP ב-gRPC C-Core ולמי שתלוי בו.
הממפה בודק ארגומנט פרוקסי של ערוץ, אחר כך grpc_proxy, אחר כך https_proxy, אחר כך http_proxy, ועוצר בערך המוגדר הראשון.
לגילוי העקיפה יש סדר משלו: no_grpc_proxy גובר על no_proxy. ערך ישן שם יכול להסביר מדוע יעד מסוים נמנע מפרוקסי שמוגדר אחרת.
הממפה הזה משתמש ב-HTTP CONNECT. ה-URI המתועד שלו לפרוקסי מצפה לסכימת HTTP; שירות gRPC מוגן TLS אינו מחייב כשלעצמו נקודת קצה של פרוקסי מוגנת TLS. בדקו בנפרד אילו אימותים נתמכים במקום להניח שסכימת התחברות כלשהי של דפדפן זמינה. עבור יעד gRPC ציבורי שבו מתווכים ציבוריים מותרים, רשימת שרתי פרוקסי HTTP מציעה מועמדים לנקודות קצה עבור URI הפרוקסי שנבחר; אשרו גישה ליעד ה-CONNECT ולפורט בפועל.
הטמעת gRPC ב-Java, ב-Go, ב-JavaScript או בשפה אחרת עשויה להשתמש בקוד תעבורה ובתצורה שונים. אל תחילו רשימת משתנים של C-Core ככלל אוניברסלי על כל מה שנקרא gRPC.
בערוץ שנכשל, שמרו את הפרוקסי שנבחר, את החלטת העקיפה, את היעד ואת שלב השגיאה. API של HTTP שנגיש דרך לקוח אחר אינו מוכיח שהממפה הזה השתמש באותן הגדרות או שהפרוקסי מתיר את יעד ה-CONNECT הנדרש.