ഒരു സ്ക്രിപ്റ്റ് Windows Internet Settings-ൽ നിന്ന് ProxyServer വായിച്ച് WebProxy.Address-ന് നൽകുന്നു. ഇത് ഒരു മെഷീനിൽ പ്രവർത്തിക്കുന്നു, പിന്നീട് മൂല്യം ഇങ്ങനെയുള്ള മറ്റൊരു മെഷീനിൽ പരാജയപ്പെടുന്നു:

http=proxy-a.example:8080;https=proxy-b.example:8080

ഇത് പ്രോട്ടോക്കോൾ-നിർദ്ദിഷ്ട കോൺഫിഗറേഷൻ സ്ട്രിംഗ് ആണ്, ഒരു പ്രോക്സി URI അല്ല. ഒരു വിലാസം പ്രതീക്ഷിക്കുന്ന കൺസ്ട്രക്ടറിലേക്ക് മുഴുവൻ മൂല്യവും നൽകുന്നത് ഇൻപുട്ടിന്റെ അർത്ഥം മാറ്റുന്നു.

എൻട്രിഇതിനായി പ്രോക്സി തിരഞ്ഞെടുക്കുന്നു
http=...HTTP ലക്ഷ്യ അഭ്യർത്ഥനകൾ
https=...HTTPS ലക്ഷ്യ അഭ്യർത്ഥനകൾ

https കീ അതിൽത്തന്നെ ആ പ്രോക്സിയിലേക്കുള്ള കണക്ഷൻ TLS ഉപയോഗിക്കുന്നു എന്ന് അർത്ഥമാക്കുന്നില്ല. സാധാരണ HTTP പ്രോക്സിക്ക് CONNECT വഴി HTTPS ലക്ഷ്യം കൊണ്ടുപോകാം.

ക്ലയന്റ് നൽകുന്നിടത്ത് യഥാർത്ഥ ലക്ഷ്യത്തിനായി പിന്തുണയുള്ള സിസ്റ്റം-പ്രോക്സി ഇന്റർഫേസിന് മുൻഗണന നൽകുക. മാനുവൽ പ്രോക്സി സ്ട്രിംഗുകൾ, ബൈപാസ് നിയമങ്ങൾ, ഓട്ടോമാറ്റിക് കോൺഫിഗറേഷൻ URL-കൾ, ഓട്ടോമാറ്റിക് കണ്ടെത്തൽ എന്നിവ കോൺഫിഗറേഷന്റെ വ്യത്യസ്ത ഭാഗങ്ങളാണ്. ഒരു രജിസ്ട്രി മൂല്യം വായിച്ചാൽ അവയെല്ലാം പുനർനിർമ്മിക്കാനാവില്ല. സംഭരിച്ച മാപ്പ് പരിശോധിക്കുകയാണെങ്കിൽ, ProxyServer-ന്റെ അടുത്തുള്ള ProxyEnable, AutoConfigURL എന്നിവ വായിക്കുക.

ഒരു ഇന്റഗ്രേഷന് മാനുവൽ മാപ്പിംഗ് പാഴ്സ് ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, അതിന്റെ രേഖപ്പെടുത്തിയ ഫോർമാറ്റ് പിന്തുടരുക, പ്രോട്ടോക്കോൾ ബന്ധം നിലനിർത്തുക, തിരഞ്ഞെടുത്ത ഓരോ മൂല്യത്തിനും യഥാർത്ഥ URI അല്ലെങ്കിൽ എൻഡ്പോയിന്റ് പാഴ്സർ ഉപയോഗിക്കുക. ഓരോ കോളനും വിഭജിക്കുന്നത് IPv6 തകർക്കുന്നു; ആദ്യ എൻട്രി തിരഞ്ഞെടുക്കുന്നത് മുകളിലുള്ള വ്യത്യാസം നഷ്ടപ്പെടുത്തുന്നു.

ഇത് ഉചിതമായ അക്കൗണ്ട് സന്ദർഭത്തിൽ നിലനിർത്തുക. ഇന്ററാക്ടീവ് ഉപയോക്താവിന്റെ ക്രമീകരണങ്ങൾ മറ്റൊരു ഐഡന്റിറ്റിക്ക് കീഴിൽ പ്രവർത്തിക്കുന്ന സേവനത്തിന്റെ ക്രമീകരണങ്ങൾ സ്വയമേവ അല്ല.

അനുബന്ധ ലേഖനങ്ങൾ