ALL_PROXY ഉം “Unknown scheme: http” പിശകും
HTTP_PROXY സ്വീകരിക്കുന്നുണ്ടെങ്കിലും ALL_PROXY-യിലെ http:// മൂല്യം ഒരു പ്രോഗ്രാം നിരസിച്ചേക്കാം. പിന്തുണയ്ക്കുന്ന സ്കീമുകൾ നിർണ്ണയിക്കുന്നത് വേരിയബിളിന്റെ ഉപഭോക്താവാണ്.
ഒരേ എൻഡ്പോയിന്റ് curl-ൽ പ്രവർത്തിക്കുമ്പോൾ proxy: unknown scheme: http വിചിത്രമായി തോന്നാം. എൻഡ്പോയിന്റ് കുഴപ്പമില്ലായിരിക്കാം. മറ്റൊരു പ്രോഗ്രാമാണ് വേരിയബിൾ വ്യാഖ്യാനിക്കുന്നത്.
എൻവയോൺമെന്റ് പേരുകൾ കൺവെൻഷനുകളാണ്, സാർവത്രിക നെറ്റ്വർക്കിംഗ് API അല്ല. Go-യുടെ golang.org/x/net/proxy പാക്കേജിന് SOCKS-കേന്ദ്രിത URL കൈകാര്യം ചെയ്യലുണ്ട്. ആ പാഴ്സർ ഉപയോഗിക്കുന്ന ഉപഭോക്താവ് ഒരു പൂർണ്ണ HTTP ക്ലയന്റ് മറ്റെവിടെയോ പിന്തുണയ്ക്കുന്ന HTTP സ്കീം നിരസിച്ചേക്കാം.
പിശക് നൽകുന്ന ഘടകവും അത് വായിക്കുന്ന വേരിയബിളും കണ്ടെത്തുക. അതിന്റെ പതിപ്പും രേഖപ്പെടുത്തിയ സ്കീമുകളും പരിശോധിക്കുക. മറുവശത്തെ സേവനം യഥാർത്ഥത്തിൽ SOCKS5 സംസാരിക്കുന്നില്ലെങ്കിൽ http:// എന്നത് socks5:// ആക്കി മാറ്റരുത്. ഈ ഉപഭോക്താവിന് SOCKS5 ആവശ്യമാണെങ്കിൽ, പൊതു റൂട്ട് അനുവദനീയമാണെങ്കിൽ, SOCKS5 പ്രോക്സി പട്ടിക ആ പ്രോട്ടോക്കോളിന്റെ യഥാർത്ഥ എൻഡ്പോയിന്റുകൾ നൽകുന്നു; മറ്റ് ക്ലയന്റുകൾക്ക് ആവശ്യമായ HTTP റൂട്ടുകൾ വേർതിരിച്ച് സൂക്ഷിക്കുക.
പഴയ Docker Toolbox റിപ്പോർട്ട് ഒരു പ്രത്യേക ചരിത്രപരമായ നടപ്പാക്കലിനെക്കുറിച്ചായിരുന്നു. അത് ആധുനിക Docker ഇൻസ്റ്റലേഷൻ ഡൗൺഗ്രേഡ് ചെയ്യാനുള്ള കാരണമല്ല. നിലവിലെ Docker daemon-ന്റെ HTTP പ്രോക്സി ക്രമീകരണങ്ങൾക്ക് അവയുടെ സ്വന്തം രേഖപ്പെടുത്തിയ ഇന്റർഫേസുണ്ട്.
കാരണം ബന്ധമില്ലാത്ത പാരമ്പര്യ ALL_PROXY മൂല്യമാണെങ്കിൽ, ഉദ്ദേശിച്ച പ്രോസസ് പരിധിയിൽ അത് നീക്കം ചെയ്യുകയോ മറികടക്കുകയോ ചെയ്യുക. മറ്റ് ക്ലയന്റുകൾക്ക് ആവശ്യമായ HTTP പ്രോക്സി ക്രമീകരണം നിലനിർത്തുക. രണ്ട് മൂല്യങ്ങളും ഉള്ള ഒരൊറ്റ എൻവയോൺമെന്റ്, വ്യക്തിഗത ആപ്പുകൾ ഒറ്റയ്ക്ക് ഒരിക്കലും കാണിക്കാത്ത വ്യത്യാസങ്ങൾ വെളിപ്പെടുത്തിയേക്കാം.