Fix GCP Metadata Server Unreachable – 3 Step Guide

Quick Test – 30 Seconds

Run this on your VM to see if the metadata server is reachable at all:

curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email

If you get a blank response or a timeout, the metadata server is unreachable. If you get a 404, you've got a path issue – the server is alive. If you get a connection refused or timeout, it's a network or DNS problem.

Simple Fix – Check DNS and Hosts (1 Minute)

The culprit here is almost always DNS. The metadata server lives at metadata.google.internal which resolves to 169.254.169.254. On GCP VMs, this is handled by the internal DHCP. But if your VM has custom DNS or a broken /etc/hosts file, it won't work.

Check DNS resolution:

dig +short metadata.google.internal

If it doesn't return 169.254.169.254, your DNS is misconfigured. The quick fix: add this line to /etc/hosts:

169.254.169.254 metadata.google.internal metadata

That overrides DNS and forces the correct IP. Test again – most people stop here.

Also check your /etc/resolv.conf. If it points to anything other than the GCP default (like 8.8.8.8 or a corporate DNS), that's your problem. The metadata server only responds on the internal IP from within the VM. You can't hit it from outside or through a proxy.

Moderate Fix – Check Firewall and Network Tags (5 Minutes)

If DNS is fine but you still get timeouts, look at the VM's network interface and firewall rules.

First, verify the VM is on the right network and has the correct network tags. Go to the GCP Console → Compute Engine → VM Instances → click your VM. Under "Network interfaces", check the VPC network and subnet. The metadata server is only accessible from within the same VPC. If your VM is on a Shared VPC or has a custom firewall that's blocking outbound traffic to 169.254.0.0/16, that'll break it.

Run this to check your route table:

ip route show | grep 169.254

You should see something like:

169.254.169.254 via 10.128.0.1 dev eth0

If the route is missing, you need to add it. Don't bother with complex routing – just add a static route:

ip route add 169.254.169.254/32 via $(ip route | grep default | awk '{print $3}')

That's a temporary fix. To make it permanent, add that to a startup script or use a custom route in GCP.

Also check your firewall rules. On GCP, the metadata server is a special endpoint that bypasses most firewall rules, but if you have iptables running inside the VM, it can block it. Run:

sudo iptables -L -n | grep 169.254

If you see any DROP or REJECT rules for that IP range, remove them. Same for firewalld – check with sudo firewall-cmd --list-all.

Advanced Fix – Check Proxy Config, Certificates, and OS-Level Issues (15+ Minutes)

If you're still stuck, the problem is deeper. Here's what I've seen cause this:

1. HTTP Proxy Environment Variables

Many enterprises set HTTP_PROXY or HTTPS_PROXY in their container or VM. The metadata server doesn't go through a proxy – it's a local endpoint. If your shell has these set, curl will try to use the proxy and fail.

Check:

echo $http_proxy $https_proxy $HTTP_PROXY $HTTPS_PROXY

If any are set, unset them:

unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY

Then test again. For containers, make sure your Docker or Podman config isn't injecting proxy variables.

2. TLS/SSL Certificate Issues

The metadata server uses HTTP, not HTTPS. But if you've got a corporate CA that's intercepting traffic or a broken certificate store, it shouldn't matter here – but I've seen cases where curl with --cacert or --capath fails because it's trying to validate the metadata server's lack of HTTPS. Explicitly use http:// (not https://) in your curl commands.

3. Custom OS Images or Immutable Instances

If you're running a hardened image (like CIS-benchmarked Linux), the metadata server access might be blocked by apparmor, selinux, or grsec. Check audit.log or journalctl for denials:

sudo journalctl -u systemd-networkd -f | grep -i metadata

Look for anything about denied or blocked. If you see SELinux denials, run:

sudo ausearch -m avc -ts recent | audit2allow -M mypol
sudo semodule -i mypol.pp

That's a quick fix – not production-ready, but it'll get you unblocked.

4. Network Interfaces and Multiple IPs

If your VM has multiple NICs or alias IPs, the metadata server might respond on a different interface. Check which interface has the default route:

ip route get 169.254.169.254

If it's going out the wrong interface, you can bind curl to the correct one:

curl --interface eth0 -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/hostname

Last Resort – Rebuild or Redeploy

If none of this works, the VM itself might be in a weird state. I've seen this when a VM was cloned from a snapshot that had corrupted network state. Delete the VM and create a fresh one. Yes, it's drastic, but after 15 minutes of troubleshooting, it's faster. Make sure you detach any persistent disks first.

One more thing: don't bother with curl -v or wget --debug unless you're really stuck. They'll just clutter the output. Stick with the simple test above.