Facing connection errors to `api.shopify.com`? It’s likely not a Shopify outage but your local DNS. Here’s a senior engineer’s guide to diagnosing and fixing this frustrating issue for good.

Is Shopify Down? Nope, It’s Your DNS. A DevOps War Story.

I still remember the 2:47 AM PagerDuty alert. The incident channel on Slack lit up like a Christmas tree. “DEPLOYMENT FAILED: Cannot connect to api.shopify.com”. Our entire CI/CD pipeline was blocked, devs were getting timeouts on their local machines, and the on-call SRE was already 15 minutes into a rabbit hole, convinced one of our egress gateways had failed. We checked Shopify’s status page—all green. We checked our own monitoring—all green. Yet, for all intents and purposes, Shopify had vanished from the internet, but only for us. This, my friends, is the classic DNS haunting that every engineer runs into eventually.

So, What’s Actually Happening? The “Why” Behind the Outage That Isn’t.

Before you start rebooting `prod-db-01`, let’s talk about the root cause. Shopify, like any massive platform, uses a Content Delivery Network (CDN). When your machine asks “Hey, where is `api.shopify.com`?”, the CDN’s DNS service doesn’t give a single IP address. It gives you an IP for a server that’s geographically close to you for speed and reliability.

The problem is that DNS responses get cached. Your computer, your office router, or your Internet Service Provider (ISP) will hold onto that IP address for a while. Sometimes, that cached IP becomes stale, unreachable, or just plain wrong for your current network path. The result? Your requests time out, and it feels exactly like the service is down, even when it’s perfectly healthy for the rest of the world.

The Fixes: From a Quick Hack to a Permanent Solution

I’ve seen teams waste hours on this. Let’s cut to the chase. Here are three ways to solve this, ranging from a battlefield patch to a proper long-term fix.

Solution 1: The ‘It’s 3 AM’ Quick Fix (Editing `/etc/hosts`)

This is my go-to when I need to get a critical deployment unblocked right now. We’re going to manually tell our machine which IP to use for `api.shopify.com`, bypassing DNS entirely. It’s a hack, but it’s an effective one.

First, find a working IP address. Use a tool like `dig` or `nslookup` with a public DNS server to get a valid record.

# Query Google's DNS server directly
dig @8.8.8.8 api.shopify.com

# You'll get a response with an IP, like 23.227.38.65
# (Your IP may be different!)

Now, take that IP address and add it to your hosts file. You’ll need admin/sudo privileges.

# Open the hosts file
sudo nano /etc/hosts

# Add this line at the bottom, then save and exit
23.227.38.65 api.shopify.com

Your connection should start working immediately. No reboot required.

Warning: This is a temporary fix! Hardcoding IPs in a hosts file is a form of technical debt. If Shopify changes this IP, your connection will break again, and you’ll forget you ever did this. Use it to get out of a jam, then revert it and apply the permanent fix.

Solution 2: The Permanent Fix (Change Your DNS Resolvers)

The root of the problem is a bad DNS cache upstream, likely from your ISP. The best way to fix this permanently is to stop using their DNS servers and switch to a more reliable public provider. My two favorites are Cloudflare and Google.

You can change this in your system’s network settings. You’re looking for the DNS server settings for your active network connection (Wi-Fi or Ethernet).

Set these in your OS network configuration, and you’ll bypass your ISP’s problematic cache for good. This solves the issue for your machine without the risks of the hosts file hack.

Solution 3: The ‘Nuclear’ Option (Flush Your Local Cache)

Sometimes the bad DNS record isn’t with your ISP, but cached right on your own machine. Before you try anything else, a quick cache flush is often the simplest solution. The command is different depending on your operating system.

On macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Windows (in Command Prompt as Administrator):

ipconfig /flushdns

On Linux (with systemd):

sudo systemd-resolve --flush-caches

Pro Tip: This is a great “first step” in any “the internet is acting weird” scenario. It’s harmless and solves a surprising number of problems. If this doesn’t work, then you know the bad cache is upstream, and you should move on to Solution 2.

So next time a critical service seems to be down just for you, take a deep breath. Don’t blame the network team (yet). Blame DNS. It’s almost always DNS.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions