System.Net.WebProxy को BypassList तर्कमा नियमित अभिव्यक्तिहरू हुन्छन्। *.office.example जस्तो ढाँचा अवैध हुन्छ किनभने सुरुको तारोसँग दोहोर्याउन अघिल्लो अभिव्यक्ति हुँदैन।

office.example र यसका उपडोमेनमा जाने HTTP र HTTPS अनुरोधका लागि PowerShell कन्फिगरेसनले यो प्रयोग गर्न सक्छ:

$bypass = @('^https?://([a-z0-9-]+\.)*office\.example(:[0-9]+)?$')
$proxy = [System.Net.WebProxy]::new(
    'http://proxy.example:8080',
    $false,
    [string[]]$bypass
)

एस्केप गरिएका थोप्लाहरू शाब्दिक थोप्लासँग मिल्छन्। दोहोरिने होस्टनाम-लेबल समूहले आधार डोमेन र त्यसअन्तर्गतका नाम दुवैलाई अनुमति दिन्छ। एङ्करहरूले office.example.other.test जस्तो नामलाई यो नियमबाहिर राख्छन्। एकल उद्धरणका PowerShell स्ट्रिङहरूले अभिव्यक्तिले प्रयोग गर्ने ब्याकस्ल्यासहरू जोगाउँछन्।

हालको .NET कार्यान्वयनले यी अभिव्यक्तिहरूलाई गन्तव्यको स्किम, होस्टनाम र गैर-पूर्वनिर्धारित पोर्टसँग मिलाउँछ। यसले अनुरोधको पथ वा क्वेरी स्ट्रिङ समावेश गर्दैन। त्यसैले वैकल्पिक पोर्ट समूहले गैर-पूर्वनिर्धारित पोर्टलाई पनि अनुमति दिन्छ; नीतिले विशेष सेवा चाह्यो भने यसलाई हटाउनुहोस् वा साँघुरो बनाउनुहोस्।

यो उदाहरणमा BypassProxyOnLocal false छ, ताकि regex नीतिलाई त्यो थप बाइपास सेटिङबाट अलग जाँच्न सकियोस्। नतिजा प्रॉक्सी वस्तुलाई त्यसलाई प्रयोग गर्नुपर्ने HTTP क्लाइन्टसँग जोड्नुहोस्। बाइपास डोमेनबाहिरको अनुमति प्राप्त सार्वजनिक URL परीक्षणका लागि, HTTP proxy list बाट एउटा HTTP प्रविष्टिले यसको ठेगाना दिन सक्छ, कुनै प्रॉक्सी खाता कन्फिगर नगरी।

राउटिङ निर्णय जाँच्न प्रतिनिधि Uri मानहरूसँग IsBypassed प्रयोग गर्नुहोस्: आधार डोमेन, एउटा उपडोमेन, असम्बन्धित बाह्य होस्ट र भ्रमित पार्ने लामो प्रत्यय। true नतिजाको अर्थ सिधा पहुँच छानिएको हो; यसले सिधा गन्तव्य पुग्न सकिन्छ भनी प्रमाणित गर्दैन।

सम्बन्धित लेखहरू