Metadata Service Unreachable

GCP Compute Engine Metadata Service Unreachable Fix

Server & Cloud Intermediate 👁 10 views 📅 Jun 27, 2026

Your VM can't reach the metadata server? This is almost always a firewall rule, a routing problem, or a bad image. Here's how to fix it.

First, check your firewall rules

I know this error is infuriating. You SSH into your VM, run a simple command like curl http://metadata.google.internal/computeMetadata/v1/instance/, and it just hangs or gives you a timeout. This tripped me up the first time too, back when I ran a help desk blog. The fix is almost always a firewall rule.

The metadata server lives at 169.254.169.254 (link-local address). Your VM talks to it directly. But if you created custom firewall rules that block outbound traffic, or you have a very restrictive VPC, you might have blocked this route.

The fix: Go to the GCP Console -> VPC network -> Firewall. Look for an egress rule that allows traffic to 169.254.169.254/32 on TCP port 80. If you don't see one, create it. Here's the rule:

gcloud compute firewall-rules create allow-metadata --direction=EGRESS --priority=1000 --network=default --action=ALLOW --rules=tcp:80 --destination-ranges=169.254.169.254/32 --target-tags=metadata-allowed

Then apply this tag to your VM: gcloud compute instances add-tags YOUR-VM-NAME --tags=metadata-allowed. Wait a minute, test it again. If it works, you're done. Nine times out of ten, this is it.

But wait – if you're using a custom VPC or shared VPC, make sure the firewall rule applies to the right network. I've seen people put it in the wrong VPC and wonder why it doesn't work.

Second, check your routing

If the firewall looks clean, the next culprit is routing. Your VM needs a default route that points to the internet gateway. Without it, packets to the metadata server get dropped.

This happens most often when you create a VM without a default route, or when you delete the default route in your VPC. I once spent an hour debugging this on a fresh Ubuntu 22.04 VM – turned out I had deleted the default-internet-gateway route by accident.

The fix: Check your routes in GCP Console -> VPC network -> Routes. You should see a route with destination 0.0.0.0/0 and next hop default-internet-gateway. If it's missing, add it:

gcloud compute routes create default-route --network=default --destination-range=0.0.0.0/0 --next-hop-gateway=default-internet-gateway

Also, check that your VM's subnet has a valid gateway. In GCP, every subnet gets a default gateway automatically, but if you've messed with subnet settings, it might be gone. The metadata server is always reachable via the default gateway, so no gateway means no metadata.

One more thing: if your VM is in a VPC with peering or VPN, make sure those routes don't override the default. I've seen peering routes with a more specific destination block the metadata server. The fix is to add a static route for 169.254.169.254/32 through the default gateway.

Third, check your image or OS

Firewall and routing are fine? Then the problem might be your VM's image or OS configuration. Some minimal Docker images or custom images disable the metadata service intentionally. I've seen this with Container-Optimized OS (COS) images, especially older ones like COS 93.

Another common cause: you're running a distro that uses systemd-resolved, which sometimes interferes with DNS resolution for the metadata server. The metadata server uses DNS name metadata.google.internal, which resolves to 169.254.169.254. If systemd-resolved blocks that, you're stuck.

The fix: First, test directly with the IP address, not the DNS name:

curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/

If that works but the DNS name doesn't, add the IP to /etc/hosts:

echo '169.254.169.254 metadata.google.internal' | sudo tee -a /etc/hosts

If neither works, check if your image has a firewall inside the VM (like iptables or ufw) that blocks port 80. On Ubuntu 20.04+, ufw is often off by default, but I've seen cases where it's enabled. Run sudo ufw status. If it's active, allow port 80:

sudo ufw allow out 80/tcp

If you're on a custom image built from a Packer template or a saved snapshot, verify that the Google Guest Agent is installed and running. Without it, the metadata server won't respond. Check with systemctl status google-guest-agent. If it's not running, start it:

sudo systemctl enable google-guest-agent
sudo systemctl start google-guest-agent

Quick-reference summary table

Cause Symptom Fix
Firewall rule blocks outbound to 169.254.169.254:80 Connection timeout Add egress firewall rule with destination 169.254.169.254/32, TCP 80
Missing default route to internet gateway No route to host Add route 0.0.0.0/0 -> default-internet-gateway
Image blocks metadata server or DNS fails DNS resolution fails, or direct IP fails Add to /etc/hosts, check ufw, start google-guest-agent

Was this solution helpful?