אתרים באותה תת-רשת יכולים לעקוף את ה-proxy השקוף של השער
מסביר מדוע תעבורה באותה תת-רשת יכולה לעקוף כלל יירוט בשער, בעוד בקשות אינטרנט מופיעות ביומן שלו.
גלישה באינטרנט מופיעה ביומן ה-proxy של השער. אתר ברשת המקומית של המשרד לא. לפני שינוי מסנן ה-URL, קבעו אם בקשת הרשת המקומית בכלל הגיעה לשער.
עבור יעד IPv4 המחובר ישירות, הלקוח יכול לפתור את כתובת שכבת הקישור של היעד ולשלוח אליו בקטע המקומי. שער ברירת המחדל שלו אינו נמצא אוטומטית בנתיב הזה. כלל יירוט שקוף בשער אינו יכול להפנות מחדש חבילות שהשער אינו מקבל לעולם.
לדוגמה, שני מארחים באותה תת-רשת מחוברת ישירות יכולים להחליף תעבורה דרך מתג בעוד מחשב ה-proxy מחובר ליציאת מתג אחרת. עצם ההימצאות ברשת המקומית הזו אינה הופכת את ה-proxy לנקודת העברה.
בחרו את הנתיב המיועד
הגדרת proxy מפורשת יכולה לשלוח את בקשת היישום המשתתף ל-proxy גם כאשר אתר היעד מקומי. בדקו גם כללי עקיפה והחלטות PAC: הם עשויים לבחור במכוון DIRECT עבור שמות או כתובות פרטיים.
אם נדרש יירוט, על הרשת להציב את נקודת היירוט בנתיב בפועל; בשער Linux, הבדילו בין נתיבי חבילות מקומיים ומועברים. הפרדת תת-רשתות בניתוב או גשר המוכנס בכוונה לקו יכולים לעשות זאת בתכנונים מתאימים, אך כל אחד משנה את התנהגות ההעברה והכשל. גשר במקום אחר ברשת המקומית אינו בקו אוטומטית.
הפרידו את דרישת פרוטוקול היישום. גם לאחר שהתעבורה עוברת במכשיר, המאזין חייב לתמוך במצב היירוט. העברת החבילות אינה הרשאה לפענח HTTPS ואינה הבטחה שפורט SOCKS רגיל יוכל לקבל אותן.
תעדו את הנתיב שנבחר בלקוח, את הקטע המקומי ואת התקן ההעברה בפועל. יומן proxy חסר יכול להיות תיאור נכון של הטופולוגיה ולא כשל רישום.