ပရောက်စီသတ်မှတ်ပြီးနောက် Browser က IP အဟောင်းကိုပင် ပြနေသည်

ပြောင်းလဲမှုမတိုင်မီနှင့် ပြောင်းပြီးနောက် တူညီသောစစ်ဆေးရေး service က ပြသော IP အတိအကျကို နှိုင်းယှဉ်ပါ။ ဝဘ်ဆိုက်က သင့် login၊ ဘာသာစကား သို့မဟုတ် ဒေသကို ထိန်းထားခြင်းသည် public IP မပြောင်းကြောင်း အထောက်အထားမဟုတ်ပါ။

1. သတ်မှတ်ထားသော profile မှ request အသစ်တစ်ခုလုပ်ပါ။ စစ်ဆေးသည့်စာမျက်နှာကို ပြန်တင်ပါ သို့မဟုတ် ၎င်း၏ refresh control နှင့် request timestamp ကို သုံးပါ။ curl သို့မဟုတ် အခြား browser ရလဒ်က ဤ profile ကို မဖော်ပြပါ။
2. အသုံးပြုနေသော configuration ကို အတည်ပြုပါ။ Firefox သည် သက်ဆိုင်ရာ manual mode တွင်သာ address ကို သုံးသည်။ system၊ automatic နှင့် no-proxy mode များက မတူညီစွာ ရွေးသည်။ Chrome အတွက် system proxy သို့မဟုတ် အမှန်တကယ် လည်ပတ်နေသော profile ၏ flag များကို စစ်ပါ။ စတင်ခြင်းက ရှိနေသော process ကို ပြန်သုံးနိုင်သည်။ သီးသန့် user-data directory အသစ်က flag အခြေပြု သီးခြားစမ်းသပ်မှုကို ပိုရှင်းစေသည်။ extension က setting များကို ထိန်းချုပ်လျှင် ၎င်းကို စစ်ပါ။
3. စမ်းသပ် URL အတွက် ခြွင်းချက်များကို စစ်ပါ။ manual bypass၊ PAC ရလဒ်နှင့် system exception များက ပစ်မှတ်တစ်ခုကို တိုက်ရိုက်ဖြစ်စေနိုင်သည်။ localhost ဖြင့် မစမ်းပါနှင့်။ Chrome သည် loopback နှင့် အချို့ local address များအတွက် ထပ်မံသတ်မှတ်စရာမလိုဘဲ ပရောက်စီကို ကျော်သည်။
4. မှန်သော address များကို နှိုင်းယှဉ်ပါ။ သတ်မှတ်ထားသော listener နှင့် ပစ်မှတ်မြင်သော ထွက်ပေါက် မတူနိုင်ပါ။ ပြသော address သည် တိုက်ရိုက်ရလဒ်မှ ပြောင်းသွားသော်လည်း စာရင်းဝင် address နှင့် မတူလျှင် ပရောက်စီက အလုပ်လုပ်နေနိုင်သေးသည်။

တိုက်ရိုက်နှင့် ပရောက်စီရလဒ်များ တူနေဆဲဆိုလျှင် သင့် service သို့မဟုတ် အခမဲ့ proxy စာရင်းမှ တူညီသောပရိုတိုကော endpoint တစ်ခုခြားကို စမ်းပြီး client trace တွင် ရွေးထားသောပရောက်စီသို့ ဆက်သွယ်ရန် ကြိုးစားမှုကို ရှာပါ။ Chrome အတွက် NetLog မှတ်တမ်းက ထို request လမ်းကြောင်းကို လိုက်နိုင်သည်။ ပရောက်စီကို မရောက်နိုင်သည့်အခါ request အသစ်က အလုပ်လုပ်နေဆဲဆိုလျှင် address ကို ထပ်ခါတလဲလဲ ပြင်မည့်အစား တိုက်ရိုက်လမ်းကြောင်း သို့မဟုတ် အရန်လမ်းကြောင်းကို စုံစမ်းသင့်သည်။