global-tunnel-ng ले प्रोक्सी चरहरू पढेपछि तिनीहरूलाई मेटाउँछ
http_proxy हराएपछि पनि पुरानो Node प्रक्रिया प्रोक्सी गर्न सक्छ; मोड्युलले राखेको अवस्था र अर्को क्लाइन्टको ट्रान्सपोर्ट जाँच्नुहोस्।
global-tunnel-ng प्रयोग गर्ने पुरानो अनुप्रयोगमा, initialize ले छानिएको कन्फिगरेसन राखेपछि समर्थित HTTP/HTTPS प्रोक्सी चरहरू जानाजान हटाउन सक्छ।
कारण दोहोरो ह्यान्डलिङ हो: अर्को लाइब्रेरीले मोड्युलको प्याच गरिएको HTTP मार्गमा वातावरण प्रोक्सी फेरि लागू गर्नु हुँदैन। त्यसैले process.env.http_proxy नहुनुको अर्थ प्रोक्सी रोकियो भन्ने होइन।
सक्रियताका लागि isProxying र राखिएको छनोटका लागि proxyConfig जाँच्नुहोस्। खाता भएको पूरा कन्फिगरेसन वा proxyUrl लग नगर्नुहोस्।
चरहरू हराएपछि पछिको क्लाइन्ट असफल भएमा, त्यसले प्याच गरिएको HTTP/HTTPS एजेन्ट, स्पष्ट एजेन्ट वा अर्को ट्रान्सपोर्ट प्रयोग गर्छ कि भनी पहिचान गर्नुहोस्। वातावरण आफै पढ्ने क्लाइन्टलाई आफ्नै अभिलेखित प्रोक्सी इनपुट चाहिन सक्छ।
node_modules बाट मेटाउने कोड हटाउँदा दोहोरो ह्यान्डलिङको सुरक्षा हट्छ र पुनःस्थापनामा हराउन सक्छ। यसको सट्टा ट्रान्सपोर्टको स्वामित्व समाधान गर्नुहोस्। यो Node अनुकूलताका सीमाहरू अभिलेखित पुरानो प्याकेज हो। अनुकूल Node संस्करणमा सुरुमा नै समावेश प्रोक्सी समर्थन मानक HTTP क्लाइन्टका लागि एउटा विकल्प हो; अनुकूलन एजेन्ट र प्रेषकलाई अझै आफ्नै मार्ग चाहिन्छ।