Seeing a drop in Google Ads traffic? Your server’s IPv6 configuration might be the silent killer. Here’s my senior engineer’s guide to diagnosing and fixing the common DNS and network interface issues that cause Google’s crawlers to time out.

Is Google Ads Traffic Drying Up? Your Server’s IPv6 Might Be the Ghost in the Machine.

I remember one frantic Tuesday morning. PagerDuty went off at 3 AM, but the alert wasn’t our usual “disk space critical on prod-db-01”. It was a high-priority ticket from the marketing team. Our biggest product launch of the quarter was live, ad spend was in the six figures, and the Google Ads console was screaming “Destination not working.” All our internal monitoring was green. I could `curl` the site, the execs could see it, but to Google, our brand new landing page was a ghost. We burned almost an entire morning’s ad budget before we found the culprit: a single, innocent-looking AAAA DNS record pointing to a server that wasn’t properly configured to listen on its IPv6 address. It’s the kind of problem that doesn’t show up on standard health checks but can silently assassinate your traffic.

The “Why”: Google’s IPv6 Preference vs. Your Server’s Reality

Let’s get this straight. This isn’t a bug; it’s a feature of the modern internet clashing with common server configurations. When you register a domain, your DNS provider typically creates two main records for your server’s IP address:

• A Record: This points your domain (e.g., `yourapp.com`) to an IPv4 address (like `192.0.2.1`). This is the classic internet address.
• AAAA Record: This points to an IPv6 address (like `2001:db8::1`). This is the newer, much larger address space.

Here’s the catch: Google’s crawlers, being the forward-thinking bots they are, will almost always prioritize the AAAA record if it exists. They want to use IPv6. The problem arises when your cloud provider (like DigitalOcean, Linode, or AWS) automatically assigns an IPv6 address and creates that AAAA record for you, but your web server (Nginx, Apache, etc.) isn’t actually configured to listen for traffic on that IPv6 interface.

So, Google’s crawler follows the AAAA record, knocks on the IPv6 door, and… gets silence. After a frustrating timeout period, it *might* try the IPv4 address, but often, it just gives up and reports your site as down. To you, your site is fine because your browser probably connected via IPv4. To Google, it’s a black hole.

The Fixes: From Emergency Patch to Permanent Solution

Depending on how much fire is raining down on you, here are three ways to tackle this, from the quick-and-dirty to the architecturally sound.

Solution 1: The Quick Fix (Tell Nginx to Ignore IPv6)

It’s 3 AM, the business is losing money, and you just need the bleeding to stop. This is your battle-tested emergency patch. You’re essentially telling your web server to only listen for IPv4 traffic, making the AAAA record irrelevant for connections.

For Nginx, you’d edit your site’s configuration file (e.g., /etc/nginx/sites-available/yourapp.conf). Find the listen directives.

Your config might look like this:

server {
    listen 80;
    listen [::]:80; # This is the IPv6 listener!
    server_name yourapp.com;
    ...
}

The quick fix is to comment out or remove the IPv6 line:

server {
    listen 80;
    # listen [::]:80; # The problem is gone, for now.
    server_name yourapp.com;
    ...
}

Then, reload Nginx with sudo systemctl reload nginx. The site will now only respond on IPv4, and Google’s crawler will connect successfully.

Warning: This is a band-aid. You’re accumulating tech debt and disabling a feature of the modern web. Use this to get back online, but plan to implement the permanent fix later.

Solution 2: The Permanent Fix (Configure It Properly)

This is the “do it right” approach. You’re going to tell your server to properly listen on both IPv4 and IPv6, and make sure nothing is blocking it. This is the robust, future-proof solution.

Step 1: Fix the Web Server Config

Ensure your Nginx config is explicitly listening on both protocols. The ipv6only=off parameter allows a single port directive to handle both, which is my preferred clean method.

server {
    # This single directive handles both IPv4 and IPv6 traffic.
    listen [::]:80 ipv6only=off; 

    server_name yourapp.com;
    ...
}

Step 2: Check The Firewall (The Real “Gotcha”)

This is the step everyone forgets. Your web server might be listening, but the server’s firewall is blocking the connection. If you’re using UFW (Uncomplicated Firewall) on Ubuntu, you might have only allowed IPv4 traffic.

Check your rules with sudo ufw status. You need to ensure your “Nginx Full” or port 80/443 rules apply to v6 as well. The easiest way to fix this is to use the application profiles:

# This command updates the firewall rules for both IPv4 and IPv6.
sudo ufw allow 'Nginx Full'

After reloading Nginx and your firewall, you’ll be serving traffic on both stacks correctly. Google will be happy, and you’ll be prepared for the future.

Solution 3: The ‘Nuclear’ Option (Nuke the AAAA Record)

Look, I get it. Sometimes you don’t control the server config, or your organization has a strict “no-IPv6” policy for legacy reasons. In this case, you can solve the problem by removing the source of the misdirection entirely: the AAAA record in your DNS.

How to do it:

1. Log into your DNS provider (e.g., AWS Route 53, Cloudflare, GoDaddy).
2. Find the DNS records for `yourapp.com`.
3. Locate the record of type `AAAA`.
4. Delete it. Just wipe it out.

Now, when any client (including Google) asks for the IP of `yourapp.com`, it will only receive the IPv4 `A` record. There’s no IPv6 door to knock on, so there’s no timeout.

Pro Tip: This is a valid strategy, but be aware of the consequences. You’re actively opting out of the next generation of the internet, and DNS changes can take time to propagate across the globe. If you ever want to enable IPv6 in the future, you’ll have to remember to come back and recreate this record.

Ultimately, the choice is yours. My recommendation is always Solution 2. It takes a few extra minutes, but it aligns your infrastructure with the direction the web is heading. Don’t let a simple network configuration silently sabotage your most important campaigns.

---

🤖 Frequently Asked Questions