DNS ပြောင်းလဲမှုက SOCKS proxy ကို အဘယ်ကြောင့် မသတ်မှတ်နိုင်သနည်း

DNS အဖြေကို ပြောင်းခြင်းက ဘရောက်ဇာ ချိတ်ဆက်သည့် လိပ်စာကိုသာ ပြောင်းသည်။ ထိုသို့ရောက်ပြီးနောက် ဘရောက်ဇာ ပြောဆိုသည့် ပရိုတိုကောကို မပြောင်းလဲပါ။

သာမန် HTTP URL ကို ဖွင့်လျှင် ဘရောက်ဇာက HTTP ပို့သည်။ HTTPS URL ကို ဖွင့်လျှင် ထိုဆိုက်အတွက် TLS စတင်သည်။ သို့သော် SOCKS5 ဆာဗာက ပထမဦးစွာ ၎င်း၏ ကိုယ်ပိုင် ညှိနှိုင်းမှုကို စောင့်သည်။ နည်းလမ်းရွေးချယ်မှု၊ ရှိပါက အတည်ပြုမှုနှင့် ဦးတည်ရာကို အမည်ပေးသော တောင်းဆိုမှုတို့ ဖြစ်သည်။ မပြင်ဆင်ရသေးသော ဘရောက်ဇာက ယင်းတို့ကို လုံးဝ မပို့ပါ။

ထို့ကြောင့် DNS ပြောင်းပြီးနောက် ရောက်ရှိနိုင်သော Dante နားထောင်သူက ချိတ်ဆက်မှုကို ချက်ချင်း ပိတ်နိုင်သည်။ ဝန်ဆောင်မှုက ကျန်းမာနိုင်သော်လည်း ဝင်လာသော byte များသည် မှားသော ပရိုတိုကော၏ ဖြစ်သည်။ နားထောင်သူကို port 80 သို့မဟုတ် 443 သို့ ရွှေ့ခြင်းက ထို byte များကို SOCKS မဖြစ်စေပါ။

ဘရောက်ဇာ၏ SOCKS မျက်နှာပြင်ကို ပြင်ဆင်ပါ၊ ဥပမာ Firefox ၏ SOCKS ဆက်တင်များ၊ သို့မဟုတ် အပ်ပလီကေးရှင်း အလိုက် proxy ဆက်တင်ကို သတ်မှတ်ပါ၊ ထို့ကြောင့် ၎င်းက လက်ဆွဲနှုတ်ဆက်မှုကို ပြုလုပ်ပြီး proxy ကို ဆက်လက်ချိတ်ဆက်ရန် တောင်းဆိုမည်။ PAC ဖိုင်က ၎င်းကို အသုံးပြုသော အပ်ပလီကေးရှင်းများအတွက် ပံ့ပိုးထားသော proxy လမ်းကြောင်းကို ရွေးနိုင်သည်။ ၎င်းသည် သီးခြား proxy ပြင်ဆင်မှုဖြစ်နေဆဲဖြစ်ပြီး A သို့မဟုတ် AAAA မှတ်တမ်း၏ ဂုဏ်သတ္တိ မဟုတ်ပါ။

HTTPS သည် DNS သက်သက် အယူအဆအပေါ် နောက်ထပ် အတားအဆီးတစ်ခု ထပ်တိုးသည်။ ဘရောက်ဇာက URL ထဲရှိ ဆိုက်၏ အထောက်အထားကို ဆက်လက် မျှော်လင့်နေသည်။ proxy host အတွက် လက်မှတ်သည် DNS က ချိတ်ဆက်မှုကို ထိုနေရာသို့ ပို့ခဲ့သောကြောင့်သာ ထိုမျှော်လင့်ချက်ကို ဖြည့်ဆည်းပေးနိုင်မည် မဟုတ်ပါ။

ထင်ရှားသော ကွန်ရက် ကြားဖြတ်ခြင်းသည် လမ်းကြောင်းပေးခြင်းနှင့် သဟဇာတဖြစ်သော ကြားဖြတ်ဆော့ဖ်ဝဲ ပါဝင်သည့် အခြားဒီဇိုင်းတစ်ခု ဖြစ်သည်။ DNS မှ SOCKS ဆာဗာ၏ လိပ်စာကို ပြန်ပေးခြင်းဖြင့် ၎င်းကို မရနိုင်ပါ။