If you monitor your Netskope proxy logs or Real-Time Protection events, you have likely come across traffic destined for raw public IP addresses where the Host FQDN looks something like this:

http://77.111.102.203/filestreamingservice/files/ff268a10-8dd6-4190-8bc1-d1db06722d0c?P1=...&cacheHostOrigin=1D.tlu.dl.delivery.mp.microsoft.com
https://194.36.32.209/92f3b6cc-ee7d-4056-af0d-6026e0d4e2f2/.../86ec8c94.intunewin.bin?cacheHostOrigin=swdb02-mscdn.manage.microsoft.com

Seeing raw IP addresses in HTTP GET requests can immediately raise red flags for SOC and network teams. However, this pattern is completely normal behavior for Microsoft Delivery Optimization (DO).

In this post, we’ll explain why this happens and show you how to build a hyper-efficient, lightweight regex URL profile to accurately match and bypass/steer this traffic in Netskope.

Understanding the Behavior: Why Raw IPs?

When Windows endpoints fetch OS patches, Defender updates, or Intune app packages (.intunewin), Microsoft’s cloud environment routes the requests through nearby Content Delivery Networks (CDNs) or Microsoft Connected Cache (MCC) nodes—often hosted directly inside ISP or local networks.

To minimize latency, the endpoint contacts the CDN or local cache directly via its raw IPv4 address.

Because there is no standard host header resolve step, Netskope logs the destination host as a raw IP. However, the original intended Microsoft endpoint is explicitly preserved inside the URL query string:

...&cacheHostOrigin=tlu.dl.delivery.mp.microsoft.com

The Challenge for Proxy Administrators

Since these CDN and ISP IP addresses change dynamically based on geographic location and network routing, traditional static IP lists or FQDN matches won't work. Passing these multi-gigabyte binary streams through full SSL Decryption and Deep Content Inspection can waste bandwidth and cause unnecessary CPU overhead.

The most effective way to manage this traffic is by matching the cacheHostOrigin query parameter using a custom URL List.

Optimizing Policy Execution: Why Regex Efficiency Matters

While a catch-all pattern like .*cacheHostOrigin=.* works, heavy reliance on standard wildcards (.*) introduces regex backtracking, which adds micro-latency to URL engine evaluations at scale.

To create a fast, resource-friendly policy, we can target the exact query parameters while keeping character matching minimal and performant.

Critical Regex Nuances to Watch Out For

1. Hyphens in Subdomains: Microsoft delivery subdomains often include hyphens (e.g., swdb02-mscdn.manage.microsoft.com). Standard [a-z0-9\.] classes will fail to match these—make sure to include the hyphen [a-z0-9\.-]+.

2. Clean Character Classes: Use [?&] instead of [\?|\&]. Inside square brackets, characters like ? and & are evaluated as literal characters automatically, so no backslashes or pipes are required.

3. End-of-String Anchors ($): If cacheHostOrigin is consistently the last parameter in your environment, using a trailing $ anchor optimizes execution even further by immediately stopping evaluation once the domain matches.

Step-by-Step Implementation in Netskope

Step 1: Create the Custom URL Profile

1. Go to Netskope Tenant > Policies > Profiles > Custom Profiles > URL List.

2. Click Add URL List.

3. Name your list (e.g., Custom_URL_Microsoft_Delivery_Optimization).

4. Add the optimized Regex patterns:

[?&]cacheHostOrigin=[a-z0-9\.-]+\.download\.windowsupdate\.com
[?&]cacheHostOrigin=[a-z0-9\.-]+\.delivery\.mp\.microsoft\.com
[?&]cacheHostOrigin=[a-z0-9\.-]+\.manage\.microsoft\.com

(Note: If cacheHostOrigin is guaranteed to be the final query variable in your traffic, you can append $ to the end of each pattern).

5. Save the URL List.

Step 2: Apply in Real-Time Protection Policies

• SSL Decryption Policy: Add a rule near the top of your SSL Decryption Policy selecting your new Custom URL List as the criteria and set the Action to Bypass.

• Steering Configuration / Real-Time Protection: Ensure an Allow rule is set for this traffic to prevent accidental blocks on raw IP destinations.

Summary

By leveraging clean, non-backtracking regular expressions targeting cacheHostOrigin, you can cleanly isolate Microsoft Delivery Optimization traffic without relying on static IP lists—keeping your Netskope policy evaluation fast and your endpoint updates running smoothly.