იპოვეთ წარუმატებელი მოთხოვნა Squid-ის ჟურნალებში
გამოიყენეთ access.log ტრანზაქციების შედეგებისთვის და cache.log თვით Squid-ის გაუმართაობებისთვის; განასხვავეთ გვირაბის სტატუსი დანიშნულების სტატუსისგან.
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-ები, მოთხოვნის პარამეტრები, წყაროს მისამართები და მომხმარებლის სახელები შეიძლება პირადი იყოს; კონკრეტული საჭიროების გარეშე მთელი ჟურნალების გამოტანა ან ყველა სათაურის ჟურნალირების ჩართვა სასარგებლო მტკიცებულების ნაცვლად ინფორმაციის გამჟღავნებას ზრდის.