Check the local request path before diagnosing an Azure metadata timeout

Source facts

Azure IMDS is reachable only from inside the VM at a non-routable address; requests stay on the host. Clients must bypass proxies, send Metadata: true, and omit X-Forwarded-For. Requests must use the primary NIC and primary IP with DHCP enabled. Microsoft directs timeout investigations to the local route for 169.254.169.254. IMDS is unauthenticated and available to processes on the VM, so it is not a place for sensitive data. Microsoft Learn.

Applicability

Use this check for a metadata request originating within the affected VM. Identify the actual HTTP client, inherited proxy configuration, chosen interface, and requested endpoint. Separate a connection failure from a rejected request or a missing metadata field.

DSE recommendation

Test proxy bypass, the primary NIC and IP, DHCP, and the local metadata route before changing broader network controls. Compare the guest’s interface and route observations with the VM’s Azure configuration. Use a narrowly scoped, nonsensitive metadata query for diagnosis and preserve the HTTP status. Review any local access restrictions with their owner instead of removing them indiscriminately.

Verification

Repeat the same query through the intended application client after an approved correction, not only through an administrator’s separate test utility. Confirm that the required headers and explicit proxy bypass remain in place. Record the interface, route, client settings, and result without collecting unrelated metadata. If the request still fails, distinguish timeout, rejection, and absent data in the escalation so the next investigation starts at the correct boundary.

Official references

Microsoft Learn: Azure Instance Metadata Service. Source reviewed September 9, 2026.