בדיקת כללי NO_PROXY של .NET עם HttpClient.DefaultProxy.IsBypassed
ציינו גם את התחום החשוף וגם את הצורה עם נקודה מובילה כאשר HttpClient צריך לעקוף פרוקסי עבור שניהם, ואז בדקו את IsBypassed.
לפי מדיניות הפרוקסי הסביבתית המתועדת של HttpClient, example.internal ו־.example.internal מתאימים באופן שונה. השם החשוף בוחר במארח האב; הצורה עם נקודה מובילה בוחרת בתת־התחומים שלו.
אם שניהם אמורים לעבור ישירות, כללו את שניהם בסביבת האתחול:
export no_proxy='example.internal,.example.internal'
מזגו אותם עם רשימת העקיפה הקיימת שאליה אתם מתכוונים. במערכות שבהן שמות משתנים מבחינים בין אותיות גדולות לקטנות, .NET בודק תחילה שמות סביבה של פרוקסי באותיות קטנות ואחר כך באותיות גדולות, ולכן no_proxy מיושן עשוי לקבל עדיפות על NO_PROXY.
בתוך היישום אפשר לבדוק את הבורר המוגדר כברירת מחדל בלי לשלוח את בקשת ה־HTTP ליעד:
foreach (var host in new[] {
"example.internal", "api.example.internal", "other.internal"
})
{
var uri = new Uri("https://" + host + "/");
Console.WriteLine($"{host}: bypass={HttpClient.DefaultProxy.IsBypassed(uri)}");
}
הקטע משתמש ב־System וב־System.Net.Http. אם היישום סיפק במפורש IWebProxy אחר, בדקו במקום זאת את הפרוקסי בפועל של המטפל. הגדירו את הסביבה הרצויה לפני אתחול הפרוקסי המוגדר כברירת מחדל.
אלה הכללים המתועדים של .NET. תוצאת curl עם אותה מחרוזת אינה מוכיחה שלקוח אחר בחר באותו מסלול, והחלטת עקיפה עדיין דורשת נגישות רשת ישירה.