You can't get a visitor's IP address in Shopify Liquid. Here's why.

It is one of the most common questions in Shopify theme development, and it has an unsatisfying answer. A merchant wants to hide a section from one problem visitor, or geo-gate a page, or log who is hammering the store. You go looking for the visitor's IP in Liquid, and it is not there. Not hidden behind a flag, not in an undocumented property. It does not exist.

The reason is architectural rather than arbitrary, and once you see it, a lot of Shopify's other constraints stop being surprising. This post covers what the request object actually holds, why the IP cannot be there, the three workarounds developers reach for and how each one fails, and where a visitor's IP genuinely is available on Shopify.

What the request object actually contains

The whole surface is five properties. This is it, straight from Shopify's Liquid reference:

No IP. No country. No user agent. No headers. Notice what the five that survived have in common: every one of them is a property of the URL being requested, not of the person requesting it. That is the whole rule, and it is the tell for why the IP was never going to be there.

The reason: one render, many visitors

Shopify serves storefronts through a global CDN. When the first shopper hits /products/ethiopian-yirgacheffe, Liquid renders and the resulting HTML is cached at the edge. The next few thousand shoppers who ask for that URL get served the cached bytes without Liquid running again.

That model is why Shopify storefronts are fast. It is also strictly incompatible with per-visitor data in the template. If Liquid could write {{ request.ip }} into the page, then either the CDN caches one shopper's IP and serves it to everyone (a data leak), or the page becomes uncacheable for everybody (a performance collapse). There is no third option, so Shopify never exposed it.

The three workarounds, and how each one fails

Search this problem and you will find three suggestions. All three are real techniques; none of them does what people usually want, and it is worth knowing precisely where each breaks.

1. Call a third-party IP API from the browser

The most-copied answer. Drop a fetch to a geo-IP service into your theme, read the response, act on it.

1// The pattern you'll find on every forum thread.2const res = await fetch("https://some-geo-api.example/json");3const { ip, country } = await res.json();4 5if (BLOCKED.includes(country)) {6  document.body.innerHTML = "Not available in your region";7}

It does return an IP. What it does not do is stop anyone. The page has already been delivered in full before that fetch resolves, so the content is in the DOM, in view-source, and in the browser cache. Anyone who disables JavaScript, or reads the HTML with curl, never sees the check at all. It also adds a blocking third-party round trip to every page load, and free geo-IP endpoints are rate-limited in ways that fail unpredictably under real traffic.

2. Put Cloudflare in front of the store

The instinct of every developer who has worked outside Shopify: park a proxy in front of it and filter there. On a Shopify-hosted storefront, you cannot. Enabling Cloudflare's proxy (the orange cloud) on a domain pointed at Shopify produces the error Your domain has a Cloudflare Proxy, which is not supported by Shopify. The DNS record has to stay on the grey cloud, DNS-only.

Shopify's stated reasoning is worth repeating, because it is not just territorial: a proxy in front of the store interferes with Shopify's ability to react to provider issues, and it alters request attributes before they reach Shopify, which degrades Shopify's own bot detection. You would be trading their bot defences for yours. Setups that appear to work are unsupported and outside the scope of Shopify Support.

3. Read it from a Shopify Function at checkout

Functions run server-side on Shopify's infrastructure, so this one feels promising. The Cart and Checkout Validation Function API is the only server-side way to validate a checkout, and it can block one. But look at what its input actually contains: the cart, the buyerJourney step, buyer identity, attributes. No IP, no network, no user agent. You can enforce rules about what is being bought and by whom, not about where the connection came from.

Where the IP does exist

Two places, both of them after or outside the cached storefront render.

1. On the order, once it exists. The Admin API exposes Order.clientIp, the IP the order was placed from. It needs the read_orders scope:

1query OrderClientIp {2  order(id: "gid://shopify/Order/1234567890") {3    id4    name5    clientIp6    customerJourneySummary {7      momentsCount8    }9  }10}

This is genuinely useful for fraud review, chargeback evidence, and spotting a cluster of orders from one network. It is useless for prevention: by the time you can read it, the order is placed and the inventory is committed.

2. On any request your own server handles. An app proxy forwards storefront requests to a server you control, and that server sees the connection like any other HTTP request. The same is true of an app embed that calls your own endpoint. This is the layer where per-visitor logic legitimately lives, and it is the layer every blocking tool on the App Store is built on, because it is the only one available.

So what do you actually build?

Work backwards from the requirement, because the right layer is entirely determined by what "blocked" has to mean.

If you land on the fourth row, you are building a small distributed system: an IP-reputation data source that stays current, an edge-cached decision service fast enough to sit in a page load, a fail-open path so an outage never takes the storefront down with it, and hashed logging so you are not accumulating raw visitor IPs in a database. That is a real project, not an afternoon.

Blocking an IP without building the stack

Cordon is a Shopify app built on exactly the architecture this post describes: an app embed in the storefront, backed by a detection service that does see the connection. Because it sits at that layer, it can act on everything Liquid cannot:

• Individual IPs and CIDR ranges. Block one address or a whole subnet, with allowlists for the addresses that must always get through.
• Whole networks by ASN. One rule covering every IP an operator controls, which is what you actually want when the problem rotates addresses within a range.
• Datacenter and cloud networks. AWS, Alibaba, Tencent, Huawei Cloud and similar, where scrapers and click fraud originate rather than real customers.
• VPNs, residential proxies and Tor exits. Live detection rather than a stale IP list, which matters because the whole point of a rotating proxy is that yesterday's list is wrong.
• Countries, 200+ of them. One click each, with presets for the common cases.

The engineering details are the part worth checking on any tool in this category, because they are where these things go wrong on a live store. Decisions land in under 50ms with a storefront script under 10KB. It fails open: if the detection service is unreachable, every visitor is allowed through, so an outage on their side never becomes downtime on the merchant's. Verified search engines are exempted by reverse DNS rather than by trusting a spoofable user-agent string, and iCloud Private Relay is allowlisted by default so Apple users are not swept up by proxy rules. Visitor IPs are SHA-256 hashed with a daily-rotating salt and are irreversible after 24 hours, while the log still shows country, network, and which rule fired.

If you just want the click-by-click version, our step-by-step guide to blocking an IP address on Shopify covers finding the offending address and picking the right rule width. But the durable takeaway is the layer model, not the tool. Once you internalise that Liquid renders once for everybody, you stop looking for per-visitor data in it, and you start asking the better question: which layer of this request is allowed to know that, and what does it cost me to run code there?