מתוצאת בדיקת PAC לנתיב האמיתי של הדפדפן
הפרידו בין הנתיב שמחזירה פונקציית PAC לבין אספקת הקובץ, אימוץ הדפדפן, נגישות ה-proxy והנתיב הסופי של הבקשה.
בודק PAC מחזיר PROXY proxy.example:8080. תוצאה שימושית. אך לפני שמכריזים שתצורת הדפדפן אומתה, נותרו כמה שאלות.
| שאלה | מה לבדוק |
|---|---|
| מה מחזיר הסקריפט הזה עבור הקלט הזה? | המעריך, כתובת ה-URL של הקלט ותוצאות פונקציות העזר |
| האם הדפדפן השיג את העותק הזה? | כתובת ה-PAC המוגדרת והוכחות אספקה או מטמון |
| האם הדפדפן השתמש בנתיב שהוחזר? | אבחון הדפדפן לקביעת ה-proxy ולחיבור |
| האם הנתיב הזה יכול היה לשאת את הבקשה? | החיבור של נקודת הקצה שנבחרה והחלפת הנתונים עם ה-proxy |
כלי כמו pacparser מעריך את לוגיקת ה-PAC באמצעות פונקציות העזר הנתמכות שלו בלבד. הוא אינו מריץ את מלוא מנגנוני הדפדפן היעד לגילוי תצורה, מדיניות, מטמון וחיבור.
שמרו על קלטים ברי-השוואה. סכימת URL אחרת, כתיב אחר של שם המארח, תשובת DNS אחרת או כתובת לקוח שסופקה יכולים לשנות תוצאה תקינה. בדיקה ברשת אחרת עשויה להפעיל ענף אחר בלי שום תקלה בסקריפט.
מדיניות הדפדפן עשויה לבחור כתובת PAC אחרת או proxy קבוע. עריכת הקובץ בדיסק אינה מוכיחה שהדפדפן הוריד אותו שוב. ב-Chrome, רענון PAC שונה מניקוי פרוקסי גרועים שנזכרו. תעדו את גרסת הקובץ המדויקת ואת ההגדרות הרלוונטיות יחד עם התוצאה.
השתמשו בהערכה לא מקוונת כדי לצמצם בעיית לוגיקה. השתמשו באבחון של הלקוח האמיתי כדי לבסס אימוץ וניתוב. אם תוצאת הסקריפט נכונה אך ה-proxy אינו רואה תנועה, חקרו את הפער לפני שכותבים מחדש כלל שעובד.