درخواست‌های ورودی ادامه‌دار ثابت نمی‌کنند که افراد بیرونی هنوز می‌توانند از پروکسی استفاده کنند. نقاط پایانی قدیمی می‌توانند پس از تغییر خط‌مشی دسترسی در فهرست درخواست‌ها بمانند. تعمیر را با آنچه ارسال می‌شود بررسی کنید:

  1. درخواست‌های مجاز و غیرمجاز به مقصدی تحت کنترل بفرستید.
  2. در قالب گزارش پیکربندی‌شده تصمیم دسترسی و برای Squid فیلدهای سلسله‌مراتب را بخوانید.
  3. تعیین کنید آیا درخواست ممنوع واقعاً به مقصد رسیده است. پذیرش TCP، رد یک درخواست HTTP و تکمیل درخواست بعدی نتایج متفاوتی هستند.
  4. شنوندگان فعال و میزبان‌های مجازی دیگر را بررسی کنید تا یک بلوک خط‌مشی تعمیرشده ورودی دیگری را باز نگذارد.

برای Apache که فقط برای نگاشت‌های معکوس در نظر گرفته شده، تأیید کنید که پروکسی رو به جلو ناخواسته غیرفعال است. ProxyRequests Off می‌تواند همراه با ProxyPass وجود داشته باشد.

صفحه خطا به‌تنهایی شاهد ضعیف‌تری است اگر ندانید کدام مؤلفه آن را ساخته است. نتیجه مشتری، تصمیم پروکسی و مشاهده در مقصد را کنار هم نگه دارید.

اگر ترافیک ردشده هنوز منابع مصرف می‌کند، دسترسی شبکه را محدود کنید و نرخ‌ها و نگهداری گزارش را مدیریت کنید. هیچ دوره انتظار قابل اعتمادی وجود ندارد که پس از آن تلاش‌ها باید متوقف شوند؛ تصمیم‌های درست ارسال، معیار پذیرش است.

مقالات مرتبط