ارسال درخواست‌های Squid از طریق پروکسی والد

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

برای Squid 6.13، این نمونه یک والد نام می‌برد و ارسال مستقیم به مبدأ را برای یک منبع کلاینت منع می‌کند:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

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

قواعد مسیریابی موجود را بررسی کنید

no-query پرس‌وجوهای ICP به این همتا را غیرفعال می‌کند. صفر پورت پرس‌وجوی همتاست، نه شنونده HTTP آن. شنونده سمت کلاینت و قواعد دسترسی‌اش جدا می‌مانند.

پیش از افزودن این بخش، تنظیم‌های always_direct موجود و انتخاب‌های دیگر همتا را مرور کنید. رد یک تطبیق در always_direct به‌تنهایی والد را الزامی نمی‌کند. قاعده صریح never-direct این الزام را برای کلاینت انتخاب‌شده بیان می‌کند.

این بر تراکنش‌هایی حاکم است که ارسال لازم دارند. ورودی قابل‌استفاده کش محلی می‌تواند بدون تماس با والد ارائه شود؛ پس نبود اتصال تازه به والد خودکار نقض مسیریابی نیست.

مسیر و رفتار هنگام شکست را بررسی کنید

از مقصد تحت کنترل استفاده کنید و اطلاعات سلسله‌مراتب لاگ دسترسی را با مشاهده‌های مقصد بسنجید. فقط وضعیت HTTP نهایی نمی‌گوید Squid از والد استفاده کرده یا مسیر مستقیم.

در آزمایش نگهداری، والد را از دسترس خارج کنید و همان درخواست کش‌نشده را تکرار کنید. اگر سیاست ارسال مستقیم را منع می‌کند، تراکنش باید شکست بخورد، نه اینکه از مسیر دیگر به مبدأ برسد. فقط روی خدمات تحت کنترل خود انجام دهید و بعد تنظیم مطلوب را بازگردانید.