Squid లాగ్లలో విఫలమైన అభ్యర్థనను కనుగొనండి
ట్రాన్సాక్షన్ ఫలితాలకు access.log, Squid సొంత వైఫల్యాలకు cache.log వాడి, టన్నెల్ స్థితిని లక్ష్యం స్థితి నుంచి వేరు చేయండి.
Debian Squid 6 ప్యాకేజీలో సాధారణ ట్రాన్సాక్షన్, డీమన్ లాగ్లతో ప్రారంభించండి:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logఅనుకూల లాగింగ్ లేదా సేవా నిర్వాహకం వాటిని వేరే చోటకు పంపవచ్చు. తెలిసిన మూలం నుంచి పరిమిత పరిధిలో ఒక అభ్యర్థనను మళ్లీ సృష్టించి, సరైన రికార్డును సరిపోల్చేందుకు సమయం, పద్ధతి, లక్ష్యాన్ని నమోదు చేయండి.
| ఆధారం | దానిలో చదవాల్సినది |
|---|---|
| access.log అసలు ఫార్మాట్ ఫలితం | Squid ఫలిత కోడ్, HTTP స్థితి ట్రాన్సాక్షన్లో వేర్వేరు భాగాలు. |
| యాక్సెస్ శ్రేణి సమాచారం | ఫార్వర్డింగ్ పేరెంట్ ప్రాక్సీ లేదా మరో మార్గాన్ని ఎలా వాడిందో. |
| CONNECT విజయం | టన్నెల్ తెరుచుకుంది; ఇది ఎన్క్రిప్ట్ చేసిన TLSలో తరువాత వచ్చే వెబ్సైట్ స్థితి కాదు. |
| cache.log | Squidలోని హెల్పర్, ప్రారంభం, రిజాల్వర్, కాన్ఫిగరేషన్ వైఫల్యాలు. |
సరిపోలే అభ్యర్థన కనిపించకపోతే ఈ క్లయింట్ ఈ నడుస్తున్న ఇన్స్టన్స్, లిసనర్ను చేరిందని నిర్ధారించండి. లాగింగ్ ACLలు, బఫరింగ్, రొటేషన్, ట్రాన్సాక్షన్ ఇంకా క్రియాశీలంగా ఉందా పరిశీలించండి; దీర్ఘకాల టన్నెల్కు తుది యాక్సెస్ రికార్డు ఇంకా లేకపోవచ్చు. బైపాస్ లేదా పాత ప్రాక్సీ ప్రక్రియ ట్రాఫిక్ను వేరే చోటకు పంపవచ్చు, కాబట్టి యాక్సెస్ విధానాన్ని మార్చే ముందు వింటున్న ప్రక్రియను అది లోడ్ చేసిన కాన్ఫిగరేషన్తో సరిపోల్చండి.
సున్నితమైన సమాచారం దాచిన సంబంధిత ట్రాన్సాక్షన్, సమీపంలోని లోపాలను పంచుకోండి. URLలు, క్వెరీలు, మూల చిరునామాలు, వినియోగదారు పేర్లు వ్యక్తిగతం కావచ్చు; నిర్దిష్ట అవసరం లేకుండా మొత్తం లాగ్లు ఇవ్వడం లేదా పూర్తి హెడర్ లాగింగ్ ఆన్ చేయడం ఉపయోగకరమైన ఆధారానికి బదులుగా బహిర్గతాన్ని పెంచుతుంది.