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 ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಒಂದು ಆಯ್ಕೆ; ಕಸ್ಟಮ್ ಏಜೆಂಟ್ ಮತ್ತು ಡಿಸ್ಪ್ಯಾಚರ್‌ಗಳಿಗೆ ಇನ್ನೂ ತಮ್ಮದೇ ಮಾರ್ಗ ಬೇಕು.