प्रदायकको डाउनलोड सफल हुनुले पछिको क्लाउड API कलबारे थोरै मात्र भन्छ। पहिलो असफल हुने होस्टनाम र अपरेसनबाट सुरु गर्नुहोस्, त्यसपछि तिनको मालिक पहिचान गर्नुहोस्:

अपरेसनयो मार्ग पछ्याउनुहोस्
रजिस्ट्री लुकअप वा इन्स्टलेसन डाउनलोडTerraform प्रक्रिया, इन्स्टलेसन स्रोत र प्रोक्सी वातावरण
Git-आधारित मोड्युल फेचस्रोत URL र Git ट्रान्सपोर्ट; SSH र HTTPS ले फरक सेटिङ प्रयोग गर्छन्
क्लाउड API कलप्रदायक प्लगइन र यसको SDK को राउटिङ र विश्वास कन्फिगरेसन
रिमोट कार्यान्वयनरनरको वातावरण र नेटवर्क, ल्यापटपको होइन

CONNECT समर्थन गर्ने HTTP प्रोक्सीका लागि, यो वातावरण मानले HTTPS गन्तव्यहरूका लागि यसलाई सही रूपमा छान्न सक्छ:

HTTPS_PROXY=http://proxy.example:3128

भेरिएबलले गन्तव्यको स्किम नाम दिन्छ; मानले प्रोक्सीको ट्रान्सपोर्ट नाम दिन्छ। https:// तब मात्र प्रयोग गर्नुहोस् जब लिसनरले TLS दिन्छ र अनुरोध गर्ने क्लाइन्टले यसलाई समर्थन गर्छ। प्रदायकहरू अलग प्लगइन हुन् र SDK-विशिष्ट सेटिङ प्रयोग गर्न सक्छन्, त्यसैले यो मान हरेक प्रदायकबारे वाचा होइन।

पहिचान गरिएको मालिकसँग, सेटिङ बदल्नुअघि त्रुटिको तह छुट्याउनुहोस्: अस्वीकृत प्रोक्सी जडान, प्रोक्सी 407, अस्वीकृत CONNECT, प्रमाणपत्र त्रुटि र क्लाउड API 403 ले प्रत्येकले अर्को अनुसन्धानलाई फरक रूपमा साँघुरो पार्छ। चरण, गन्तव्य, कार्यान्वयन वातावरण र पहिलो त्रुटि सँगै राख्नुहोस्।

समर्थित सेटिङ त्यो घटकमा लागू गर्नुहोस्। ल्यापटपमा गरिएको निर्यातले रिमोट रनर कन्फिगर गर्दैन, र प्रोक्सी प्रमाणहरूले रजिस्ट्री वा क्लाउड API सामु प्रमाणीकरण गर्दैनन्।

सम्बन्धित लेखहरू