Azure DevOps (dev.azure.com) page fails to load - vsassetscdn.azure.cn DNS resolution error (NXDOMAIN)

Baoyu Yin 20 Reputation points
2026-07-14T01:10:42.3133333+00:00

When accessing Azure DevOps at https://dev.azure.com/[Your-Organization-Name], the page fails to load due to DNS resolution failure for the China CDN domain.

Affected resources:

Issue details:

  • DNS_PROBE_FINISHED_NXDOMAIN error
  • Tested with multiple DNS servers including 8.8.8.8 (Google), 223.5.5.5 (AliDNS), etc. — all fail to resolve
  • Occurs in mainland China network environment

This prevents MSAL authentication flow and static resources from loading properly.

Please investigate the availability of the vsassetscdn.azure.cn CDN domain.

Azure DevOps
0 comments
Answer accepted by question author
Jerald Felix 18,760 Reputation points Volunteer Moderator
2026-07-14T01:41:08.1366667+00:00

Hello Baoyu Yin,

Greetings! Thanks for raising this question in the Q&A forum.

This is a known service side issue rather than something misconfigured in your network. Azure DevOps loads some static assets and MSAL authentication library files from a China specific CDN domain (vsassetscdn.azure.cn and gallerycdn.azure.cn) whenever it detects a request originating from mainland China. These domains are documented as required allowlist entries for Azure DevOps in China, but the CDN domain itself has been intermittently failing to resolve (NXDOMAIN) or returning certificate errors for some users, which has already been reported separately on the Visual Studio Developer Community as a domain outage affecting vsassetscdn.azure.cn. Since this is the CDN endpoint that Azure DevOps redirects China based clients to, no DNS server on your side including public resolvers like 8.8.8.8 or AliDNS can resolve it if the domain itself is not currently being served.

Here is how to confirm and work around this while it is being fixed.

  1. Confirm it is not local DNS caching

Flush your local resolver cache and retest before assuming it is a broader outage.

ipconfig /flushdns
nslookup vsassetscdn.azure.cn

If nslookup returns NXDOMAIN against multiple independent public resolvers as you already tested, this confirms the failure is authoritative and not a caching or ISP specific issue.

  1. Check whether the issue is intermittent

Some users have reported the same failure resolving in some regions or via some network paths but not others. Try the lookup from a different network path (mobile hotspot, different ISP) to see if resolution succeeds anywhere, which helps determine if this is a partial CDN outage versus a global one.

  1. Temporary workaround using a hosts file entry

As a short term workaround only, you can attempt to bypass the broken DNS record by resolving the CDN through an alternate working path, for example a public DNS over HTTPS resolver, and adding a manual hosts file entry pointing to a currently resolvable IP for the CDN. This is not a long term fix since CDN IPs rotate and change without notice, so remove the entry once Microsoft resolves the DNS record. Location of hosts file on Windows:

C:\Windows\System32\drivers\etc\hosts
  1. Check if a corporate proxy or firewall is intercepting the request

If you are behind a corporate proxy or security appliance doing DNS filtering or SSL inspection, confirm it is not silently blackholing the azure.cn subdomains, since this can also present as NXDOMAIN even though the domain resolves fine externally.

  1. Escalate through the correct channel

Azure DevOps issues are not monitored through the Microsoft Q&A forum tag, they are tracked by the product team through the Visual Studio Developer Community. Since this specific CDN outage has already been reported there, add your details (region, DNS servers tested, timestamp) as a comment on the existing report so the product team can correlate scope, or file a new report if none matches your exact symptom, at

https://developercommunity.visualstudio.com/report?space=21&entry=problem
  1. If you have a paid Azure support plan

Open a support ticket under Azure DevOps service issues if you need a formal SLA tracked incident, since a stuck or unresolvable CDN DNS record is a backend configuration issue that requires the DevOps team to intervene, not something fixable from the client side.

Report a problem with Azure DevOps (Developer Community): https://developercommunity.visualstudio.com/report?space=21&entry=problem

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix

Was this answer helpful?

1 person found this answer helpful.
0 comments

2 additional answers

Sort by: Newest
Most helpful Newest Oldest
  1. Pravallika KV 18,850 Reputation points Microsoft External Staff Moderator
    2026-07-14T06:28:50.47+00:00

    Hi @Baoyu Yin ,

    Thanks for reaching out to Microsoft Q&A.

    NXDOMAIN during hostname resolution typically indicates a DNS resolution failure that can stem from DNS records/delegation issues or misconfiguration in the DNS path (e.g., how DNS queries are reaching the authoritative resolvers).

    1. Verify the hostnames being queried
      • Confirm the exact FQDN(s) failing (from the network/devtools error and/or the specific URLs).
      • In your case, you already identified vsassetscdn.azure.cn and gallerycdn.azure.cn and a specific script URL under vsassetscdn.azure.cn.
    2. Check whether DNS resolution failure is caused by delegation/authoritative resolution path
      • A practical way to validate delegation is to query the zone’s NS records and confirm they match what Azure expects (using tools like nslookup/dig).
    3. Validate from an environment with known-good DNS behavior
      • Since you tested multiple public DNS resolvers and still got NXDOMAIN, this suggests the failure may not be limited to your local/ISP resolver.
      • It’s still useful to test from a different network/location (or another mainland China network) to confirm whether the failure is systemic for those CDN hostnames.
    4. If you use any custom DNS / Azure DNS forwarding/private resolver
      • If the client is behind a corporate DNS solution, conditional forwarders, or an Azure Private DNS/Resolver setup, DNS forwarding/resolver linkage can prevent the correct responses from being returned.

    Hope this helps!

    If the resolution was helpful, kindly take a moment to click on User's imageand click on Yes for was this answer helpful. And, if you have any further query do let us know.

    Was this answer helpful?

    0 comments
  2. Christos Panagiotidis 3,551 Reputation points
    2026-07-14T06:19:06.7733333+00:00

    Hi, NXDOMAIN means the failure happens at DNS resolution, before Azure DevOps can serve the asset. On the affected machine, compare nslookup for the hostname using your normal resolver and a known public resolver, then check VPN, secure-DNS, proxy/PAC, firewall, and DNS-filter logs. Also clear the browser and Windows DNS caches after any change. If your organization intentionally uses the public Azure DevOps service, a dependency on an azure.cn asset may indicate a tenant/geo routing or cached configuration issue; capture a HAR and the exact failing hostname and raise it with Azure DevOps support. I would not add a hosts-file entry, because CDN addresses can change and that masks the real routing problem.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.