מצאו בקשה שנכשלה ביומני Squid
השתמשו ב־access.log לתוצאות עסקאות וב־cache.log לכשלים של Squid עצמו, תוך הבחנה בין מצב המנהרה למצב היעד.
בחבילת Squid 6 של Debian התחילו ביומני העסקאות ותהליך הרקע הרגילים:
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, שאילתות, כתובות מקור ושמות משתמש עשויים להיות פרטיים; הוצאת יומנים שלמים או הפעלת רישום כותרות מלא ללא צורך מסוים מוסיפות חשיפה במקום ראיות מועילות.