script တစ်ခုသည် Windows Internet Settings မှ ProxyServer ကို ဖတ်ပြီး WebProxy.Address သို့ သတ်မှတ်သည်။ စက်တစ်ခုတွင် အလုပ်လုပ်ပြီး၊ တန်ဖိုးက ဤသို့ဖြစ်နေသော အခြားစက်တွင် မအောင်မြင်ပါ။

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

ဤသည် protocol အလိုက် configuration စာကြောင်းဖြစ်ပြီး proxy URI တစ်ခုတည်း မဟုတ်ပါ။ လိပ်စာတစ်ခုတည်းကို မျှော်လင့်သော constructor သို့ တန်ဖိုးတစ်ခုလုံး ပေးခြင်းသည် input ၏ အဓိပ္ပာယ်ကို ပြောင်းလဲစေသည်။

အချက်အတွက် proxy ကို ရွေးချယ်သည်
http=...HTTP ဦးတည်ချက် တောင်းဆိုမှုများ
https=...HTTPS ဦးတည်ချက် တောင်းဆိုမှုများ

https key သည် ထို proxy သို့ ချိတ်ဆက်မှု TLS သုံးသည်ဟု အလိုအလျောက် မဆိုလိုပါ။ သာမန် HTTP proxy သည် HTTPS ဦးတည်ချက်ကို CONNECT မှတစ်ဆင့် သယ်ဆောင်နိုင်သည်။

client က ပေးသည့်နေရာတွင် အမှန်တကယ် ဦးတည်ချက်အတွက် ပံ့ပိုးထားသော system-proxy interface ကို ဦးစားပေးပါ။ လက်ဖြင့် proxy စာကြောင်းများ၊ bypass စည်းမျဉ်းများ၊ အလိုအလျောက် configuration URL များနှင့် အလိုအလျောက် ရှာဖွေမှုတို့သည် configuration ၏ မတူညီသော အပိုင်းများဖြစ်သည်။ registry တန်ဖိုးတစ်ခု ဖတ်ခြင်းဖြင့် ၎င်းတို့အားလုံးကို ပြန်လည်ဖန်တီး၍ မရပါ။ သိမ်းဆည်းထားသော မြေပုံကို စစ်ဆေးပါက၊ ProxyServer အနီးရှိ ProxyEnable နှင့် AutoConfigURL ကို ဖတ်ပါ.

integration တစ်ခုသည် လက်ဖြင့် mapping ကို ခွဲခြမ်းစိတ်ဖြာရမည်ဆိုပါက ၎င်း၏ မှတ်တမ်းတင်ထားသော format ကို လိုက်နာပြီး protocol ဆက်စပ်မှုကို ထိန်းသိမ်းကာ ရွေးချယ်ထားသော တန်ဖိုးတစ်ခုစီအတွက် အစစ်အမှန် URI သို့မဟုတ် endpoint parser ကို အသုံးပြုပါ။ ကော်လံတစ်ခုစီကို ခွဲခြင်းသည် IPv6 ကို ပျက်စီးစေသည်။ ပထမအချက်ကို ရွေးချယ်ခြင်းသည် အထက်ပါ ကွဲပြားမှုကို ဆုံးရှုံးစေသည်။

၎င်းကို သင့်လျော်သော အကောင့်အခြေအနေတွင် ထားရှိပါ။ အပြန်အလှန် အသုံးပြုသူ၏ ဆက်တင်များသည် အခြား အထောက်အထားအောက်တွင် လည်ပတ်နေသော ဝန်ဆောင်မှု၏ ဆက်တင်များ အလိုအလျောက် မဟုတ်ပါ။

ဆက်စပ်ဆောင်းပါးများ