პროქსი დახურულია. რატომ მოდის მოთხოვნები კვლავ?
განასხვავეთ გაგრძელებული კავშირის მცდელობები წარმატებული არაავტორიზებული გადაცემისგან პროქსიზე წვდომის გამკაცრების შემდეგ.
მუდმივი შემომავალი მოთხოვნები არ ამტკიცებს, რომ გარეშე პირებს პროქსის გამოყენება კვლავ შეუძლიათ. ძველი ბოლო წერტილები შეიძლება დარჩეს მოთხოვნების სიებში წვდომის პოლიტიკის შეცვლის შემდეგ. შეამოწმეთ შეკეთება იმით, რაც გადაეცემა:
- გაუშვით ნებადართული და აკრძალული მოთხოვნები კონტროლირებულ დანიშნულებაზე.
- წაიკითხეთ წვდომის გადაწყვეტილება და Squid-ისთვის იერარქიის ველები კონფიგურირებულ ჟურნალის ფორმატში.
- დაადგინეთ, მართლაც მიაღწია თუ არა აკრძალულმა მოთხოვნამ დანიშნულებას. TCP-ის მიღება, HTTP მოთხოვნის უარყოფა და შემდგომი მოთხოვნის დასრულება სხვადასხვა შედეგია.
- შეამოწმეთ სხვა აქტიური მსმენელები და ვირტუალური ჰოსტები, რათა შეკეთებულმა პოლიტიკის ბლოკმა სხვა შესასვლელი ღია არ დატოვოს.
მხოლოდ შებრუნებული რუკების მოსამსახურებელი Apache-ისთვის დაადასტურეთ, რომ უნებლიე პირდაპირი პროქსირება გამორთულია. ProxyRequests Off შეიძლება არსებობდეს ProxyPass-თან ერთად.
მხოლოდ შეცდომის გვერდი უფრო სუსტი მტკიცებულებაა, თუ არ იცით რომელმა კომპონენტმა შექმნა იგი. კლიენტის შედეგი, პროქსის გადაწყვეტილება და დანიშნულებაზე დაკვირვება ერთად შეინახეთ.
თუ უარყოფილი ტრაფიკი კვლავ მოიხმარს რესურსებს, შეავიწროეთ ქსელური წვდომა და მართეთ სიხშირეები და ჟურნალების შენახვა. არ არსებობს სანდო ლოდინის პერიოდი, რომლის შემდეგ მცდელობები უნდა შეწყდეს; სწორი გადაცემის გადაწყვეტილებები მიღების კრიტერიუმია.