gRPC C-Core मधील प्रॉक्सी आणि बायपास व्हेरिएबल्सचे प्राधान्य

उच्च प्राधान्याचे gRPC सेटिंग आधीच असल्यास http_proxy बदलल्याने काहीही होऊ शकत नाही. आधी अंमलबजावणी ओळखा: खालील वर्तन gRPC C-Core च्या डीफॉल्ट HTTP प्रॉक्सी मॅपरचे आणि त्यावर अवलंबून असलेल्या भागांचे आहे.

मॅपर प्रथम चॅनेल प्रॉक्सी आर्ग्युमेंट, नंतर grpc_proxy, नंतर https_proxy, नंतर http_proxy तपासतो आणि पहिल्या कॉन्फिगर केलेल्या मूल्यावर थांबतो.

बायपास शोधण्याचा स्वतःचा क्रम आहे: no_grpc_proxy चे no_proxy वर प्राधान्य आहे. तिथले जुने मूल्य एखादे लक्ष्य अन्यथा कॉन्फिगर केलेल्या प्रॉक्सीला का टाळते हे स्पष्ट करू शकते.

हा मॅपर HTTP CONNECT वापरतो. त्याचे दस्तऐवजीकृत प्रॉक्सी URI HTTP स्कीम अपेक्षिते; TLS-संरक्षित gRPC सेवेला स्वतः TLS-संरक्षित प्रॉक्सी एंडपॉइंटची आवश्यकता नसते. कोणतीही ब्राउझर लॉगिन स्कीम उपलब्ध आहे असे गृहीत न धरता समर्थित प्रमाणीकरण स्वतंत्रपणे तपासा. जिथे सार्वजनिक मध्यस्थांना परवानगी आहे अशा सार्वजनिक gRPC लक्ष्यासाठी, HTTP प्रॉक्सी यादीतून निवडलेल्या HTTP प्रॉक्सी URI साठी एंडपॉइंट उमेदवार देते; प्रत्यक्ष CONNECT लक्ष्य आणि पोर्टपर्यंत पोहोच सुनिश्चित करा.

Java, Go, JavaScript किंवा अन्य भाषेतील gRPC अंमलबजावणीचा ट्रान्सपोर्ट कोड आणि कॉन्फिगरेशन वेगळे असू शकते. gRPC असे म्हटल्या जाणाऱ्या प्रत्येक गोष्टीवर C-Core व्हेरिएबल यादी सार्वत्रिक नियम म्हणून लागू करू नका.

अयशस्वी चॅनेलसाठी निवडलेली प्रॉक्सी, बायपास निर्णय, लक्ष्य आणि त्रुटीचा टप्पा जतन करा. दुसऱ्या क्लायंटद्वारे पोहोचण्यायोग्य HTTP API हे सिद्ध करत नाही की या मॅपरने तीच सेटिंग वापरली किंवा प्रॉक्सी आवश्यक CONNECT गंतव्यस्थानास परवानगी देते.