सामग्री पर जाएंVisual Studio Code में प्रॉक्सी क्रेडेंशियल कैसे कॉन्फ़िगर करें
VS Code प्रॉक्सी settings हिंदी संदर्भ में समझें तो प्रॉक्सी सेटिंग तीन अलग-अलग जगहों पर विफल हो सकती है: खुद एडिटर में, किसी एक्सटेंशन में, या इंटीग्रेटेड टर्मिनल से शुरू हुए किसी टूल में। यह अंतर मायने रखता है। ब्राउज़र चल सकता है, जबकि एडिटर फिर भी 407 त्रुटि दे सकता है या किसी एक्सटेंशन पेज को लोड करने से इनकार कर सकता है, और समाधान इस बात पर निर्भर करता है कि रिक्वेस्ट कहाँ से शुरू हुई।
1. पहले यह जांचें कि प्रॉक्सी की जरूरत खुद VS Code को है या किसी एक्सटेंशन को
एक सरल परीक्षण से शुरू करें: क्या टर्मिनल खोलने से पहले ही VS Code विफल हो जाता है? अगर Extensions view लोड नहीं हो पाती, तो समस्या ज़्यादातर एडिटर में है। अगर Git केवल तब विफल होता है जब आप टर्मिनल में कोई कमांड चलाते हैं, तो VS Code ठीक हो सकता है और समस्या शेल में हो सकती है। छोटा परीक्षण, बड़ा संकेत।
रिक्वेस्ट के स्रोत को पहचानें। VS Code एक्सटेंशनों, अपडेट्स, सेटिंग्स सिंक, और साइन-इन प्रॉम्प्ट्स के लिए नेटवर्क कॉल कर सकता है। एक्सटेंशन भी अपनी सेवाओं को कॉल कर सकते हैं। कोई लिंटर, रिमोट डेवलपमेंट एक्सटेंशन, या AI हेल्पर एडिटर की प्रॉक्सी सेटिंग्स को अनदेखा करके अपनी अलग नियमावली अपना सकता है। इसी वजह से एक ही नेटवर्क एक पैनल में काम कर सकता है और दूसरे में विफल, भले ही मशीन वही हो।
अगर आप प्रॉक्सी व्यवहार की व्यापक समझ चाहते हैं, तो प्रॉक्सी प्रमाणीकरण की सर्वोत्तम प्रथाओं वाला गाइड उपयोगी है, लेकिन यहाँ मुख्य काम थोड़ा सीमित है: यह पता लगाना कि वास्तव में कौन-सा कंपोनेंट ब्लॉक हुआ है। सिर्फ एक फेल डाउनलोड भी आपको अगला कदम बता सकता है।
2. सेटिंग्स बदलने से पहले जरूरी प्रॉक्सी विवरण ठीक से निकालें
कुछ भी बदलने से पहले प्रॉक्सी का होस्ट, पोर्ट, और प्रमाणीकरण विधि इकट्ठा करें। अंदाज़ा न लगाएँ। proxy.example.com जैसा होस्ट और 8080 जैसा पोर्ट SOCKS endpoint या ऐसे कॉर्पोरेट गेटवे के बराबर नहीं है जो यूज़रनेम और पासवर्ड मांगता है। अगर आप कोई एक फ़ील्ड भी छोड़ देते हैं, तो VS Code सेटिंग स्वीकार कर सकता है और फिर भी कनेक्ट होने में असफल हो सकता है।
अपनी नेटवर्क टीम से इस्तेमाल होने वाला सटीक फ़ॉर्मैट पूछें, खासकर जब VS Code में proxy username password वाली संरचना चाहिए हो। कुछ प्रॉक्सी सिर्फ होस्ट और पोर्ट चाहते हैं। कुछ क्रेडेंशियल URL में चाहते हैं। कुछ टीमें क्रेडेंशियल रोटेट करती हैं, कुछ नहीं। पासवर्ड में एक भी टाइपो नेटवर्क आउटेज जैसा दिख सकता है, और यह काफ़ी परेशान करने वाला लेकिन बहुत सामान्य है।
अगर आप अभी भी प्रॉक्सी प्रकारों की तुलना कर रहे हैं, तो SOCKS5 proxy vs HTTP proxy गाइड आपको ट्रांसपोर्ट और प्रमाणीकरण विवरण अलग करने में मदद कर सकती है। VS Code के लिए यहाँ सिर्फ वही मान महत्वपूर्ण है जो प्रॉक्सी वास्तव में अपेक्षा करता है। गलत पोर्ट, गलत पासवर्ड जितनी ही जल्दी कनेक्शन तोड़ देता है।
3. VS Code की यूज़र या वर्कस्पेस सेटिंग्स में प्रॉक्सी क्रेडेंशियल सेट करें
VS Code में Settings खोलें और proxy खोजें। आम तौर पर सही जगह user settings फ़ाइल होती है, हालांकि workspace किसी एक प्रोजेक्ट के लिए इसे ओवरराइड कर सकता है। अगर एक रिपॉजिटरी को प्रॉक्सी चाहिए और दूसरी को नहीं, तो यह अंतर महत्वपूर्ण है। गलत स्कोप में रखी गई सेटिंग घंटों तक रहस्य बना सकती है।
आम सेटिंग एडिटर का प्रॉक्सी endpoint होती है, और कई मामलों में आप इसे सीधे settings UI में या settings.json में दर्ज करते हैं। अगर आपके प्रॉक्सी को authentication चाहिए, तो certificate handling, strict SSL behavior, या extension downloads से जुड़ी सेटिंग्स को भी चालू या समायोजित करना पड़ सकता है। 2021 की किसी पुरानी ब्लॉग पोस्ट को कॉपी करने के बजाय मौजूदा settings list देखें।
जब आप अपने पूरे अकाउंट के लिए प्रॉक्सी चाहते हों, तब user settings का उपयोग करें। जब एक codebase को अलग route चाहिए, तब workspace settings का उपयोग करें। यह अलगाव आसानी से छूट जाता है, और बाद में बहुत सारा अनुमान लगाने से बचा सकता है। कॉर्पोरेट नेटवर्क वाला प्रोजेक्ट प्रॉक्सी मांग सकता है, जबकि कोई व्यक्तिगत side project उसे कभी नहीं छूना चाहिए।
बिना सोचे-समझे असंबंधित सेटिंग्स में random values न डालें। अगर कोई फ़ील्ड proxy URL के लिए है, तो उसमें proxy URL ही डालें। अगर कोई फ़ील्ड extension-specific endpoint के लिए है, तो editor proxy को वैसे ही छोड़ दें। साफ़ कॉन्फ़िगरेशन, तात्कालिक जुगाड़ से बेहतर है।
4. जब username और password चाहिए हों, तो प्रॉक्सी एड्रेस सही फ़ॉर्मैट में लिखें
जब प्रॉक्सी को एड्रेस के भीतर ही क्रेडेंशियल चाहिए होते हैं, तो फ़ॉर्मैट में आम तौर पर username, password, host, और port एक ही string में शामिल होते हैं। यह तब तक आसान लगता है जब तक पासवर्ड में special characters न हों। colon, at sign, या hash एड्रेस के पढ़े जाने के तरीके को बदल सकता है, और तब VS Code उस value को authenticated की बजाय malformed मान सकता है।
यही वह हिस्सा है जहाँ Visual Studio Code में proxy username password वाली सेटिंग समझना जरूरी हो जाता है, और Visual Studio Code में प्रॉक्सी क्रेडेंशियल कैसे कॉन्फ़िगर करें सिर्फ settings फ़ाइल में host डालने से आगे बढ़ जाता है। अगर आपके पासवर्ड में symbols हैं, तो percent-encoding की जरूरत पड़ सकती है। जो पासवर्ड ब्राउज़र प्रॉम्प्ट में काम करता है, वही URL में डालने पर विफल हो सकता है। यह VS Code की कोई विचित्रता नहीं है; यह फ़ॉर्मैट की समस्या है।
एक व्यावहारिक नियम मदद करता है: अगर प्रॉक्सी एडमिन ने पूरा authenticated URL दिया है, तो उसी exact form का उपयोग करें। अगर उन्होंने अलग-अलग फ़ील्ड दिए हैं, तो syntax की पुष्टि किए बिना उन्हें जोड़कर नया फ़ॉर्मैट न बनाएं। एक slash की कमी भी रिक्वेस्ट बिगाड़ सकती है।
अगर आप ऐसे प्रोजेक्ट के लिए प्रॉक्सी प्रकार चुन रहे हैं जो VS Code और external tools दोनों का उपयोग करता है, तो authenticated SOCKS5 proxy वाला लेख credentialed access की उपयोगी पृष्ठभूमि देता है। यहाँ मुख्य काम accuracy है। URL को प्रॉक्सी से मेल खाना चाहिए, आपकी याद से नहीं।
5. इंटीग्रेटेड टर्मिनल और उससे चलने वाले टूल्स पर भी वही प्रॉक्सी क्रेडेंशियल लागू करें
VS Code नेटवर्क तक पहुँच सकता है जबकि टर्मिनल नहीं। यह अक्सर होता है। एडिटर के पास प्रॉक्सी सेटिंग हो सकती है, लेकिन इंटीग्रेटेड टर्मिनल shell commands चलाता है, और वे commands अलग environment variables या पूरी तरह अलग config file पढ़ सकती हैं। Git, npm, pip, Maven, और curl इसके सामान्य उदाहरण हैं।
अपने shell को दिखने वाली जगह पर proxy variables सेट करें। कई सिस्टमों पर इसका मतलब HTTP_PROXY, HTTPS_PROXY, और कभी-कभी उनके lowercase version भी होते हैं। टर्मिनल से शुरू होने वाले टूल अक्सर किसी और चीज़ से पहले इन्हीं variables को देखते हैं। authentication prompt के साथ फेल होने वाला package install आम तौर पर एडिटर नहीं, शेल की ओर इशारा करता है।
Git अपनी अलग proxy config भी रख सकता है। npm अपनी registry और proxy entries का उपयोग कर सकता है। एक टूल दूसरों को बिना चेतावनी के अनदेखा कर सकता है। इसलिए आपको एडिटर और टर्मिनल को अलग-अलग टेस्ट करना चाहिए, यह मानकर नहीं कि एक सेटिंग सब पर लागू हो जाएगी। दो जांचें, दो संभावित विफलताएँ।
अगर आपकी टीम यह भी समझना चाहती है कि shell tools के लिए कौन-सा proxy endpoint इस्तेमाल करना है, तो web scraping के लिए proxy port numbers वाला गाइड port selection और संबंधित checks में मदद कर सकता है। यहाँ भी पैटर्न वही है: अगर टर्मिनल गलत port की ओर इशारा कर रहा है, तो proxy credentials सही होने पर भी authentication फेल हो जाएगी।
6. स्थानीय या आंतरिक addresses को proxy routing से बाहर रखें
हर address को proxy के रास्ते से नहीं जाना चाहिए। localhost और 127.0.0.1 जैसी local services को आम तौर पर इसे बायपास करना चाहिए। Private intranet hosts, internal package registries, और local test servers को भी ऐसा ही करना चाहिए। अगर आप इन्हें proxy से भेजेंगे, तो रिक्वेस्ट धीमी हो सकती है या पूरी तरह विफल हो सकती है।
जहाँ आपके टूल्स समर्थन करते हैं, वहाँ no-proxy settings का उपयोग करें। कई environments hosts, domains, या IP ranges की सूची स्वीकार करते हैं जिन्हें proxy को skip करना चाहिए। उस सूची का महत्व लोगों की अपेक्षा से ज़्यादा होता है। पोर्ट 3000 पर चल रहा local API server कोई public website नहीं है, और उसे आपके laptop पर जवाब देने के लिए proxy की जरूरत नहीं होनी चाहिए। छोटा नियम, बड़ा लाभ।
Internal names को भी bypass list में रखें। .corp पर समाप्त होने वाला hostname या 10.x.x.x जैसा private subnet design के अनुसार external proxy के ज़रिए पहुँच से बाहर हो सकता है। अगर VS Code किसी local service के लिए लगातार spinner दिखाता रहता है, तो जांचें कि रिक्वेस्ट को अनावश्यक रूप से तो नहीं घुमाया जा रहा।
Exclusion logic पर व्यापक चर्चा के लिए how to hide your IP address लेख उपयोगी संदर्भ देता है, लेकिन यहाँ बात सरल है: private traffic को वहाँ न भेजें जहाँ उसका काम नहीं है। Proxy public traffic के लिए है, आपकी अपनी मशीन के लिए नहीं।
7. जाँचें कि VS Code extension services और remote resources तक पहुँच पा रहा है
सेटिंग्स लागू होने के बाद उन रास्तों का परीक्षण करें जो महत्वपूर्ण हैं। Extensions view खोलें और किसी package page को लोड करने की कोशिश करें। अगर आपके workflow में sign-in चाहिए, तो sign in करें। देखें कि updates दिखाई देते हैं या नहीं। अगर आपकी टीम editor के भीतर remote repositories या documentation panels का उपयोग करती है, तो उन्हें भी खोलें। उद्देश्य यह पुष्टि करना है कि authenticated access वहीं काम कर रहा है जहाँ VS Code वास्तव में रिक्वेस्ट भेजता है।
विफलता के पैटर्न देखें। 407 response आम तौर पर proxy authentication समस्या की ओर इशारा करता है। Timeout का मतलब host या port गलत होना हो सकता है। Certificate warning यह संकेत दे सकती है कि proxy traffic intercept कर रहा है और editor अभी certificate chain पर भरोसा नहीं करता। हर लक्षण का अलग समाधान होता है, इसलिए उन्हें एक ही समस्या न समझें।
एक ज्ञात-कार्यशील resource और एक कम सामान्य resource आज़माएँ। इससे आपको दो data points मिलते हैं। अगर दोनों लोड हो जाते हैं, तो शायद काम पूरा है। अगर एक चलता है और दूसरा नहीं, तो समस्या main proxy configuration की बजाय किसी extension setting में हो सकती है। यह जितना होना चाहिए उससे ज़्यादा होता है।
ऐसी टीमों के लिए जो बड़े पैमाने पर extension downloads पर निर्भर हैं, endpoint trust और credential handling का प्रश्न व्यापक proxy planning से जुड़ जाता है। VPN कैसे चुनें वाला लेख उस बड़े infrastructure निर्णय को समझने में मदद कर सकता है, लेकिन VS Code का परीक्षण सरल ही रहता है: क्या editor बिना दोबारा पूछे अपनी ज़रूरत की चीज़ें लोड कर सकता है?
8. असफल authentication और credential storage समस्याओं को ठीक करें
अगर proxy फिर भी connection अस्वीकार कर रहा है, तो पहले साफ़-साफ़ गलतियों को ठीक करें। Username, password, host, और port फिर से जांचें। अतिरिक्त spaces हटाएँ। अगर password में special characters हैं, तो confirm करें कि encoding सही है। फिर VS Code को restart करें।
Stored secrets भी भ्रम पैदा कर सकते हैं। अगर VS Code ने पुराना password सेव कर लिया है, तो setting file बदलने के बाद भी editor वही भेजता रह सकता है। अपने सिस्टम के password manager, credential store, या settings cache से पुरानी entry हटाएँ। एक stale secret पूरी setup को बिगाड़ सकता है।
डुप्लिकेट proxy values भी देखें। Proxy VS Code, terminal profile, Git config, और किसी extension की अपनी settings में सेट हो सकता है। अगर इनमें से दो आपस में असहमत हैं, तो टूल विफल हो सकता है, भले ही हर value अपने आप में सही लगे। यही असुविधाजनक हिस्सा है: “सही” जवाब भी गलत जगह सहेजे जाने पर हार सकता है।
एक-एक स्तर करके reset करें। पहले VS Code proxy setting हटाएँ, फिर परीक्षण करें। उसके बाद उसे वापस रखें और shell proxy variables हटाएँ, फिर दोबारा परीक्षण करें। फिर Git या npm जांचें। यह क्रमिक तरीका धीमा है, लेकिन यह बताता है कि कौन-सा स्तर खराब value लिए हुए है। अगर editor सिर्फ एक stale credential हटाने के बाद काम करने लगे, तो आपने दोषी ढूँढ लिया है।
अगर इतनी कोशिशों के बाद भी authentication विफल हो रही है, तो पूछें कि क्या proxy service की policy बदल गई है। कुछ systems को अलग username format, नया realm, या IP allowlist चाहिए होता है। यह VS Code का bug नहीं है। यह policy change है, और इसके लिए proxy owner से मौजूदा नियमों की पुष्टि करनी पड़ेगी।
| जांच | कहाँ देखें | विफलता का सामान्य अर्थ |
|---|---|---|
| Extensions पेज लोड नहीं होता | VS Code सेटिंग्स | Proxy host, port, या auth गलत है |
| Terminal commands विफल होते हैं | Shell variables, Git, npm, या अन्य tool config | Editor proxy और terminal proxy मेल नहीं खाते |
| Local server पहुँच से बाहर है | No-proxy list | Internal traffic proxy के ज़रिए भेजा जा रहा है |
| 407 बार-बार लौटता रहता है | Credentials और saved secrets | Password, encoding, या stored secret पुराना है |
एक अंतिम जांच तब मदद करती है जब बाकी सब सही दिख रहा हो: settings JSON खोलें और हर proxy-related entry खोजें। उनकी गिनती करें। अगर आपको तीन अलग-अलग proxy values दिखती हैं, तो उनमें से एक शायद पुरानी है। अगर कोई भी नहीं दिखती, तो proxy अभी भी environment से inherited हो रहा है। दोनों स्थितियाँ होती हैं, और दोनों को ठीक किया जा सकता है।