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 गन्तव्य अनुमति दिन्छ भनी प्रमाणित गर्दैन।