ટર્મિનલમાં ડાઉનલોડ કામ કરે છે, પરંતુ VPN પર VS Code એક્સ્ટેન્શન નિષ્ફળ જાય છે

કન્ટેનરના ટર્મિનલમાં સફળ થતા ડાઉનલોડ તે ટર્મિનલના પર્યાવરણ વિશે વાસ્તવિક પુરાવા છે. તેઓ એડિટર પ્રક્રિયા, એક્સ્ટેન્શન ઇન્સ્ટોલર અથવા એક્સ્ટેન્શન પછીથી મેળવતી બાઇનરી વિશે કંઈ કહેતા નથી. એ ત્રણ વચ્ચે પ્રોક્સી ચલ કૉપી કરવા એક નિષ્ફળ વિનંતીને અસંબંધિત ફેરફારોની આખી બપોરમાં ફેરવે છે.

બે પર્યાવરણ સામાન્ય રીતે બરાબર એક જ બાબતમાં ભિન્ન હોય છે. તે બાબત શોધવી પ્રોક્સી દસ્તાવેજીકરણ બે વાર વાંચવા કરતાં ઝડપી છે.

કઈ પ્રક્રિયાએ નિષ્ફળ વિનંતી કરી

એક ઇન્સ્ટોલ દરમિયાન ત્રણ વિનંતીઓ નિષ્ફળ થઈ શકે છે, અને દરેકની પોતાની નેટવર્ક ઓળખ હોય છે. એડિટર Marketplace પાસેથી મેટાડેટા અને પેકેજ URL માંગે છે, પછી પેકેજ ડાઉનલોડ કરે છે. ત્યાર પછી જ એક્સ્ટેન્શન હોસ્ટ એવો કોડ ચલાવે છે જે ભાષા સર્વર અથવા પોતાની બાઇનરી મેળવી શકે છે. કયો તબક્કો તૂટ્યો તે નક્કી કરે છે કે કઈ પ્રક્રિયાને પ્રોક્સી જોઈએ, અને ભૂલની સપાટી ભાગ્યે જ તબક્કાનું નામ આપે છે.

કામ કરતું ટર્મિનલ સાબિત કરે છે કે કન્ટેનર ઇન્ટરનેટ સુધી પહોંચી શકે છે, એ નહીં કે એડિટર પહોંચી શકે છે. એક્સ્ટેન્શન લોગમાં તેણે અજમાવેલ છેલ્લું URL વાંચો. ત્યાં નામ આપેલ હોસ્ટ પ્રક્રિયા અને તેના પર લાગુ થતી નીતિ ઓળખે છે.

સ્થાનિક એડિટર અને દૂરસ્થ કન્ટેનર બે પર્યાવરણ છે

દૂરસ્થ વર્કસ્પેસમાં એક્સ્ટેન્શન તે બાજુ ચાલે છે જે તેનો પ્રકાર જાહેર કરે છે. ઇન્ટરફેસ એક્સ્ટેન્શન સ્થાનિક એડિટર સાથે રહે છે, અને વર્કસ્પેસ એક્સ્ટેન્શન કન્ટેનરમાં ચાલે છે. એકમાં સેટ કરેલી પ્રોક્સી બીજા માટે અદૃશ્ય છે, અને પુનર્નિર્માણ કન્ટેનરનું પર્યાવરણ તેની રૂપરેખાંકન ફાઇલમાંથી બનાવે છે, તમે શેલમાં જે નિકાસ કર્યું તેમાંથી નહીં. એ વિભાજન સમજાવે છે કે શા માટે એ જ એક્સ્ટેન્શન લેપટોપ પર ઇન્સ્ટોલ થાય છે અને SSH દ્વારા એ જ પ્રોજેક્ટમાં નિષ્ફળ જાય છે.

કંઈપણ સંપાદિત કરતા પહેલા ઇન્સ્ટોલેશન સ્થાન વાંચો. જ્યારે લોગ દૂરસ્થ ઇન્સ્ટોલેશનની જાણ કરે, ત્યારે કન્ટેનરનું પર્યાવરણ મહત્ત્વનું છે.

પ્રોક્સી ત્યાં મૂકો જ્યાંથી વિનંતી શરૂ થાય છે

ખરેખર HTTP પ્રોક્સીની જરૂર હોય એવા Dev Container માટે, ચલ કન્ટેનર રૂપરેખાંકનમાં હોવું જોઈએ જેથી પુનર્નિર્માણ તેને પુનઃઉત્પાદિત કરે. નીચેનો ટુકડો તે પર્યાવરણ માટે તેને સેટ કરે છે. પ્લેસહોલ્ડર સરનામું તમારા પોતાના ગેટવેનું પ્રતિનિધિત્વ કરે છે, અને બાકાતો વૈકલ્પિક પેડિંગ નથી.

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

ચલનું નામ ગંતવ્ય પ્રોટોકોલ વર્ણવે છે, તેથી HTTPS_PROXY મૂલ્ય કાયદેસર રીતે http થી શરૂ થઈ શકે છે. સમર્થિત પુનર્નિર્માણ માર્ગ દ્વારા ફેરફાર લાગુ કરો અને બાકાતો રાખો, કારણ કે આંતરિક હોસ્ટને અટકાવતી પ્રોક્સી કન્ટેનરને જરૂરી સેવાઓ તોડે છે.

વિશ્વાસની નિષ્ફળતાઓને પહોંચશક્તિથી અલગ કરો

જે પ્રોક્સી જોડાય છે અને પછી પ્રમાણપત્ર ચકાસણીની ભૂલ પરત કરે છે તે જોડાણ નકારતી પ્રોક્સી કરતાં પછીના તબક્કે પહોંચી છે. પ્રથમ નિષ્ફળતાને સંસ્થાની મંજૂર વિશ્વાસ સામગ્રી જે પર્યાવરણ વિનંતી કરે છે ત્યાં ઇન્સ્ટોલ કરેલી જોઈએ. બીજીને પહોંચી શકાય તેવું સરનામું અને પોર્ટ જોઈએ. બંનેને એક સમસ્યા તરીકે ગણવાથી એવો ઉકેલ મળે છે જે બંનેમાંથી કોઈ માટે કામ કરતો નથી.

ચકાસણી બંધ કરવી, અથવા એડિટરને ઊંચા અધિકારો સાથે ચલાવવું, ગુમ થયેલી પ્રોક્સી અથવા ગુમ થયેલી વિશ્વાસ-શૃંખલાનું સમારકામ નથી. બંને દૃશ્યમાન ભૂલને શાંત ભૂલ સાથે બદલે છે. તે પછી એ જ એક્સ્ટેન્શન ફરી અજમાવો અને નિષ્ફળ થતું આગળનું URL નોંધો.

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

વર્કસ્પેસની કઈ બાજુએ એ URL ઉત્પન્ન કર્યું તે નોંધો. તબક્કો, હોસ્ટ અને બાજુનું નામ આપતી ટૂંકી નોંધ કોઈએ બદલેલી સેટિંગ્સની યાદી કરતાં વધુ મૂલ્યવાન છે, કારણ કે એ નોંધ જ આગલી વ્યક્તિ પુનઃઉત્પાદિત કરી શકે છે.