ביומיים האחרונים שוב קיבלתי שיעור ממערכת הפרוקסי של Windows. התסמינים על פני השטח היו:
- Chrome גולש כרגיל
- גם בשורת הפקודה אפשר לגשת לרוב האתרים
- אבל חנות מיקרוסופט אומרת לי ברצינות תהומית: אין לך אינטרנט
בסוף האמת הייתה: לא שאין אינטרנט, אלא ש“נוסעים על מחסניות רשת שונות”.
קודם המסקנה (לעסוקים)
ב־Windows נפוצות לפחות שלוש כניסות פרוקסי:
WinINet: הרבה אפליקציות דסקטופ, דפדפנים, וחזית UWP קוראות מזה (״פרוקסי מערכת״ בדרך כלל מתכוון לזה)WinHTTP: הרבה שירותי מערכת/רכיבי רקע משתמשים בזה (הסט שלnetsh winhttp show proxy)- פרוקסי דרך משתני סביבה:
HTTP_PROXY/HTTPS_PROXY/NO_PROXY, בעיקר לכלי CLI
כשאתה לוחץ ב־Clash על “System Proxy”, לרוב זה משנה את WinINet, ולא בהכרח את WinHTTP.
המקרה שלי: למה “החנות אופליין, הדפדפן אונליין”
ההגדרות שלי באותו רגע:
- WinINet =
127.0.0.1:7890(פרוקסי מקומי של mihomo) - WinHTTP =
DIRECT - TUN של Clash פתוח
התנהגות:
- Chrome הולך לפי WinINet, מצליח להשתמש בפרוקסי, ולכן נראה ש“הרשת תקינה”
- חנות מיקרוסופט (UWP/AppContainer) זורקת שגיאת רשת
0x80072EFD(CannotConnect)
הנקודה הקריטית כאן:
ל־UWP כברירת מחדל אין הרשאה לגשת לכתובת לופבאק מקומית (
127.0.0.1/localhost).
אז כשהחנות מנסה להתחבר לפורט הפרוקסי המקומי שלך, ייתכן שהיא פשוט נחסמת ע״י כללי הסנדבוקס. זה לא שהיא לא יכולה להגיע לאינטרנט—אלא שהיא קודם לא יכולה להגיע ל“כניסת הפרוקסי”.
למה גם “חנות בסין היבשתית יכולה להתחבר ישירות” עלול להתפוצץ?
הרבה אנשים יאמרו: storeedge.microsoft.com בסין היבשתית מלכתחילה אפשר להתחבר אליו ישירות. זה נכון, אבל לא שלם.
כי המסלול הוא:
אפליקציית UWP -> פרוקסי מקומי(127.0.0.1:7890) -> ניתוב לפי כללים(DIRECT/PROXY) -> אתר יעד
אם הקפיצה הראשונה (UWP אל הלופבאק המקומי) נחסמת, אז ל“אמור להתחבר ישירות” בכלל אין הזדמנות לקרות.
מה שבאמת תיקן את זה הפעם
לא כיביתי פרוקסי גלובלי, לא שיניתי WinHTTP, לא נגעתי בשירותים שתלויים בזה—עשיתי רק שינוי מינימלי:
checknetisolation loopbackexempt -a -n=microsoft.windowsstore_8wekyb3d8bbwe
checknetisolation loopbackexempt -a -n=microsoft.storepurchaseapp_8wekyb3d8bbwe
checknetisolation loopbackexempt -a -n=microsoft.xboxidentityprovider_8wekyb3d8bbwe
ואז פתיחה מחדש של Store—והכול חזר לעבוד.
זה נקרא חריגת לופבאק (loopback exempt) ב־UWP: פתיחת רשימת לבן לפי שם חבילה (package name) ספציפי של UWP, כדי לאפשר לו לגשת ל־localhost/127.0.0.1 המקומיים.
למה הפרוקסי של Windows נראה “מבולגן”
כי זו לא דרך אחת, אלא “כמה נתיבים במקביל”:
- דפדפנים/חלק מאפליקציות דסקטופ: קוראים WinINet
- שירותי מערכת: קוראים WinHTTP
- כלי טרמינל: עלולים להכיר רק משתני סביבה
- UWP: מושפע גם ממדיניות אבטחת הלופבאק של AppContainer
- TUN: יכול גם להשתלט על חלק מהתעבורה ברמת ה־IP
אתה רואה “מתג אחד”, אבל במערכת בפועל יש “חמישה שערים”.
השוואה מול Linux / macOS
Linux
- אין “מתג פרוקסי מערכתי” אחיד שמכסה את כל האפליקציות
- נפוץ: משתני env + הגדרה לכל אפליקציה בנפרד
- פרוקסי שקוף לרוב נשען על
tun + iptables/nftables + policy routing - יתרון: נשלט, ניתן לסקריפט; חסרון: פרגמנטציה בולטת
macOS
- יש הגדרת פרוקסי יחסית אחידה לפי שירות רשת (System Settings)
- אבל כלי CLI עדיין לרוב מסתכלים על משתני env
- אין את הסמנטיקה של AppContainer loopback כמו UWP (מודל הסנדבוקס שונה)
Windows
- חוויית GUI נראית כמו “כניסה אחידה”, אבל מתחת יש הכי הרבה מטען היסטורי
- WinINet / WinHTTP / UWP / TUN חיים יחד, והכי קל להגיע ל“זה עובד, וזה אופליין”
סדר בדיקות שאני משתמש בו היום
- לבדוק WinINet: האם הפרוקסי מכוון ל־
127.0.0.1:xxxx - לבדוק WinHTTP:
netsh winhttp show proxy - לבדוק שהפורט באמת מאזין (
Get-NetTCPConnection) - לבדוק חריגות לופבאק ב־UWP (
checknetisolation loopbackexempt -s) - לבדוק קודי שגיאה ביומני האפליקציה (למשל
0x80072EFDשל החנות) - ואז להחליט אם זו בעיית פרוקסי, בעיית DNS או בעיית אתר יעד
משפט תלונה לסיום
הפרוקסי של Windows הוא לא “הגדרה שגויה”—אלא “כיוונת נכון רק שכבה אחת”.
כשאתה מגלה: הדפדפן עובד מצוין, אבל החנות צועקת שאין אינטרנט—אל תפקפק מיד בשפיות שלך; קודם תפקפק בכך שהם בכלל לא נוסעים באותה דרך. 