درخواست ناموفق را در لاگ‌های Squid پیدا کنید
از access.log برای نتیجهٔ تراکنش‌ها و از cache.log برای خطاهای خود Squid استفاده کنید و وضعیت تونل را از وضعیت مقصد جدا بدانید.
در بستهٔ 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 | خطاهای برنامه‌های کمکی، راه‌اندازی، resolver و پیکربندی خود Squid. |
اگر درخواست مطابقی نیست، تأیید کنید که این کلاینت به همین نمونهٔ در حال اجرا و شنونده رسیده است. ACLهای ثبت لاگ، بافرکردن، چرخش و فعال‌بودن تراکنش را بررسی کنید؛ تونل طولانی‌مدت ممکن است هنوز رکورد دسترسی نهایی نداشته باشد. دورزدن پراکسی یا فرایند قدیمی‌تر پراکسی ممکن است ترافیک را به جای دیگری بفرستد؛ پس پیش از تغییر سیاست دسترسی، فرایند شنونده را با پیکربندی بارگذاری‌شدهٔ خودش تطبیق دهید.
تراکنش مرتبط با اطلاعات حساس پوشانده‌شده و خطاهای نزدیک آن را به اشتراک بگذارید. URLها، پرس‌وجوها، آدرس‌های مبدأ و نام‌های کاربری ممکن است خصوصی باشند؛ بیرون‌دادن کل لاگ‌ها یا فعال‌کردن ثبت کامل هدرها بدون نیاز مشخص، به‌جای شواهد مفید میزان افشا را بیشتر می‌کند.