Squid မှတ်တမ်းများတွင် မအောင်မြင်သော request ကို ရှာခြင်း
Transaction ရလဒ်များအတွက် access.log၊ Squid ကိုယ်တိုင်၏ ချို့ယွင်းမှုများအတွက် cache.log ကို အသုံးပြုပြီး tunnel အခြေအနေကို ဦးတည်ရာ၏ အခြေအနေနှင့် ခွဲခြားပါ။
Debian ၏ Squid 6 package တွင် ပုံမှန် transaction နှင့် daemon မှတ်တမ်းများမှ စတင်ပါ။
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logစိတ်ကြိုက် logging သို့မဟုတ် service manager က ၎င်းတို့ကို အခြားနေရာသို့ ပို့နိုင်သည်။ သိရှိထားသော ရင်းမြစ်မှ အတိုင်းအတာကန့်သတ်ထားသည့် request တစ်ခုကို ပြန်လုပ်ပြီး မှန်ကန်သော record နှင့် တွဲဖက်နိုင်ရန် အချိန်၊ method နှင့် ဦးတည်ရာကို မှတ်ပါ။
| အထောက်အထား | ၎င်းမှ ဖတ်ရမည့်အရာ |
|---|---|
| access.log မူလဖော်မတ်၏ ရလဒ် | Squid ရလဒ်ကုဒ်နှင့် HTTP status သည် transaction ၏ သီးခြားအစိတ်အပိုင်းများ ဖြစ်သည်။ |
| ဝင်ရောက်မှု အဆင့်ဆင့်အချက်အလက် | Forwarding က parent proxy သို့မဟုတ် အခြားလမ်းကြောင်းကို မည်သို့ အသုံးပြုခဲ့သည်။ |
| CONNECT အောင်မြင် | Tunnel ပွင့်သွားသည် ဟုဆိုလိုပြီး စာဝှက်ထားသော TLS အတွင်းမှ နောက်ပိုင်းဝဘ်ဆိုက် status မဟုတ်ပါ။ |
| cache.log | Squid ကိုယ်တိုင်ရှိ helper၊ စတင်ခြင်း၊ resolver နှင့် configuration ချို့ယွင်းမှုများ။ |
ကိုက်ညီသော request မတွေ့ပါက ဤ client သည် ဤလုပ်ဆောင်နေသော instance နှင့် listener ထံ ရောက်ရှိခဲ့ကြောင်း အတည်ပြုပါ။ Logging ACL၊ buffering၊ rotation နှင့် transaction လုပ်ဆောင်နေဆဲလား စစ်ဆေးပါ။ ကြာရှည်ဖွင့်ထားသော tunnel တွင် နောက်ဆုံး access record မရှိသေးနိုင်ပါ။ Bypass သို့မဟုတ် အဟောင်း proxy process က traffic ကို အခြားနေရာသို့ ပို့နိုင်သောကြောင့် access policy မပြင်မီ နားထောင်နေသော process ကို ၎င်းတင်ထားသည့် configuration နှင့် တွဲဖက်စစ်ဆေးပါ။
အထိခိုက်မခံအချက်အလက်များ ဖုံးကွယ်ထားသော သက်ဆိုင်သည့် transaction နှင့် အနီးရှိ error များ ကို မျှဝေပါ။ URL၊ query၊ ရင်းမြစ်လိပ်စာနှင့် အသုံးပြုသူအမည်များသည် သီးသန့်ဖြစ်နိုင်သည်။ တိကျသောလိုအပ်ချက်မရှိဘဲ မှတ်တမ်းအားလုံးကို ထုတ်ပေးခြင်း သို့မဟုတ် header အပြည့်အစုံကို မှတ်တမ်းတင်ခြင်းက အသုံးဝင်သော အထောက်အထားထက် အချက်အလက်ဖော်ထုတ်မှုကို တိုးစေသည်။