Eight URLs that went nowhere

Pages reads a plain-text _redirects file from the build output, one rule per line: source, destination, optional status code. Every moved or renamed page adds a line, and the file grows quietly.

Eight of my lines did nothing. The old URLs returned 404 instead of a 301 to the new page, and they kept doing that for two months.

That's the stake for anyone who uses _redirects for SEO housekeeping. A 301 tells a search engine where a page went. A 404 tells it the page is gone. Two months of 404 on URLs that already had links is two months of asking Google to drop them.

Wrong guess: the file is too big

The rules that failed were the ones past roughly the first 120, so my first theory was size. The file was 10,508 bytes. Maybe Pages read a fixed number of bytes and dropped the tail.

So I shrank it to 8,313 bytes, deployed and re-checked.

Nothing changed. The same rules still returned 404.

That experiment was useful because it ruled something out. If 2,195 fewer bytes didn't move the cutoff, bytes weren't the limit. What was left was the number of rules: roughly the first 120 worked and the rest didn't.

What the docs say

The Pages redirects docs have a per-file limit:

A _redirects file is limited to 2,000 static redirects and 100 dynamic redirects

That's 2,100 combined, and each declaration has a 1,000-character limit. The same section says "The order of your redirects matter." and "Static redirects should appear before dynamic redirects."

My file had nowhere near 2,000 rules. What the page doesn't do is define "static" and "dynamic", or say what happens past a limit. Splats (*) and placeholders (:slug) are described on the same page, so it's natural to assume only those rules are dynamic. It's also easy to read "should appear before" as style advice.

What the parser says

Cloudflare publishes a _redirects parser in workers-sdk: parseRedirects.ts. Three things in it matter here.

1. Classification is positional. A rule counts as static only if its source has no *, no : followed by a letter, and no dynamic rule appeared earlier (L82-L86). The first dynamic rule sets canCreateStaticRule = false (L97), and nothing sets it back. Every rule after that counts as dynamic, even /old-page /new-page 301.

2. The caps are the documented ones. constants.ts sets MAX_DYNAMIC_REDIRECT_RULES = 100 and MAX_STATIC_REDIRECT_RULES = 2000. The placeholder test is /:[A-Za-z]\w*/g, the splat test is /\*/g.

3. The two caps fail differently. Past 2,000 static rules, the parser skips that one line and carries on. Past 100 dynamic rules, it records "Skipping remaining N lines of file" and breaks out of the loop (L99-L105). Everything below that line is gone. It's a warning, not a failed build.

Put together, "about 120" stops looking random. If the first dynamic rule sits around line 20, you get about 20 static rules, then 100 rules counted as dynamic, then nothing. Bytes don't enter into it, which matches the shrink experiment.

What I can't tell you: which of my rules was the first dynamic one, or whether any of them was. This is the explanation that fits the code and my symptoms, not one I traced rule by rule. In workers-sdk this parser is used by wrangler pages dev and Miniflare, the local tools. I couldn't confirm that Git-connected production builds run the same code, and there is at least one visible difference: the parser's line cap is 2,000 characters, the docs say 1,000.

Reproduce it locally

The quickest check needs no script. Point wrangler pages dev at your build folder and read the startup log. I built a synthetic file: a comment, a blank line, 20 plain rules, one /blog/* https://blog.example.com/:splat 301, then 110 plain FAQ rules. Wrangler 4.153.0 printed:

✨ Parsed 120 valid redirect rules.
▲ [WARNING] Found 1 invalid redirect rule:
  ▶︎ Maximum number of dynamic rules supported is 100. Skipping remaining 12 lines of file.

It also printed one hint per plain rule below the splat, saying it "could be made more performant by bringing it above any lines with splats or placeholders." That's 120 working rules and 11 dead ones (the 12 skipped lines include the trailing empty line), from a file with only one splat.

Count your own file in CI

If you'd rather not boot a dev server in CI, this script copies the parser's counting rules. It's an illustration, not an official tool: it skips blank and # lines, takes the first field as the source, and applies the same two regexes and the same one-way flag.

// count-redirects.mjs: illustration, not an official tool.
// Mirrors the counting logic in workers-sdk's parseRedirects.ts.
// Usage: node count-redirects.mjs path/to/_redirects
import { readFileSync } from "node:fs";

const MAX_STATIC = 2000, MAX_DYNAMIC = 100;
const SPLAT = /\*/, PLACEHOLDER = /:[A-Za-z]\w*/;

const lines = readFileSync(process.argv[2] || "_redirects", "utf8").split("\n");
let statics = 0, dynamics = 0, firstDynamic = null, cut = null;
const lateStatics = [];

lines.forEach((raw, i) => {
  const line = raw.trim();
  if (!line || line.startsWith("#") || cut) return;
  const from = line.split(/\s+/)[0];
  const looksDynamic = SPLAT.test(from) || PLACEHOLDER.test(from);
  if (!firstDynamic && !looksDynamic) return void statics++;
  if (!firstDynamic) firstDynamic = { line: i + 1, from };
  if (++dynamics > MAX_DYNAMIC) return void (cut = { line: i + 1, from });
  if (!looksDynamic) lateStatics.push(i + 1);
});

console.log(`static: ${statics}  counted as dynamic: ${Math.min(dynamics, MAX_DYNAMIC)}`);
if (firstDynamic)
  console.log(`first dynamic rule: line ${firstDynamic.line} (${firstDynamic.from})`);
if (lateStatics.length)
  console.log(`WARN ${lateStatics.length} plain rules after it are counted as dynamic: lines ${lateStatics.slice(0, 10).join(", ")}...`);
if (statics > MAX_STATIC) console.log(`WARN more than ${MAX_STATIC} static rules`);
if (cut) console.log(`FAIL dynamic budget runs out at line ${cut.line} (${cut.from}); the rest of the file is skipped`);

On the same synthetic file it agrees with Wrangler:

static: 20  counted as dynamic: 100
first dynamic rule: line 23 (/blog/*)
WARN 99 plain rules after it are counted as dynamic: lines 24, 25, 26, 27, 28, 29, 30, 31, 32, 33...
FAIL dynamic budget runs out at line 123 (/faq/old-99); the rest of the file is skipped

If the first dynamic rule sits near the top, the cheap fix is the one the docs already state: move every rule without * or :name above every rule with them. Order still matters within each group, because the top-most rule for a source wins, so check for duplicates when you reshuffle.

Check every redirect after deploy

Counting tells you what should happen. This loop tells you what did. It requests every rule without * or :name and compares the status code and Location header with the file. Also an illustration: it assumes 302 when no code is given (the documented default), skips 200 rewrites, doesn't handle inline # comments, and leaves dynamic rules for you to test by hand.

#!/usr/bin/env bash
# check-redirects.sh: illustration. Usage: ./check-redirects.sh https://example.com _redirects
# Requests every rule without * or :placeholder and compares status + Location.
site="${1%/}"; file="${2:-_redirects}"; fail=0
while read -r from to code _; do
  [[ -z "$from" || "$from" == \#* ]] && continue
  [[ "$from" == *'*'* || "$from" =~ :[A-Za-z] ]] && continue   # dynamic: test by hand
  code="${code:-302}"
  [[ "$code" == 200 ]] && continue                             # rewrites have no Location
  read -r got loc < <(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$site$from")
  want="$to"; [[ "$to" == /* ]] && want="$site$to"
  if [[ "$got" != "$code" || "$loc" != "$want" ]]; then
    echo "FAIL $from -> got $got ${loc:-<no Location>}, want $code $want"; fail=1
  fi
done < "$file"
exit $fail

%{redirect_url} is the Location curl would follow, already resolved to an absolute URL, which is why relative destinations get the site prefixed. Run it against a preview deploy before you promote it, and against production after. A failure looks like this:

FAIL /faq/old-100 -> got 404 <no Location>, want 301 https://example.com/faq/new-100

The exit code is non-zero on any failure, so in CI a silent 404 becomes a red build.

When reordering isn't enough

If you really have more than 100 rules that need splats or placeholders, reordering only delays the cutoff. The docs point to two other places to put them.

Bulk Redirects. These live at the account level, and the docs name them as the way past the 2,100-rule limit of _redirects. In case of duplicates, Bulk Redirects "run in front of your Pages project". They suit long lists of fixed old-to-new pairs. Check your plan's list limits before moving a large file.

A Pages Function. Code has no rule budget. One catch, straight from the docs: _redirects rules "are not applied to requests served by Pages Functions." A root functions/_middleware.js runs in front of every request, including static files, so expect it to take over your redirects. Either move all of them into it or scope the Function to the paths that need it.

// functions/_middleware.js: illustration. Replace the map with your own rules.
const MOVED = {
  "/old-page": "/new-page",
  "/tools/old-name": "/tools/new-name",
};

export async function onRequest({ request, next }) {
  const url = new URL(request.url);
  const to = MOVED[url.pathname];
  return to ? Response.redirect(new URL(to, url).toString(), 301) : next();
}

Static asset requests on Pages are free and unlimited, but requests that invoke Functions count toward your Workers quota, so check it first.

Rules I'm keeping

1. A limit is defined by how things are counted, not by the number. "100 dynamic" meant something different from what I assumed until I read the parser.
2. Run the experiment that can rule a theory out. Cutting 2,195 bytes and seeing no change killed the size theory.
3. Plain rules first, patterns last. The docs say so in one sentence. The code shows why.
4. Test redirects from the outside, after every deploy. A green deploy says the build worked, not that /old-page answers 301.

If you've hit this with a file that should have fit, I'd like to know whether your cutoff matched the first-dynamic-rule position. A few more data points would show whether this is the whole story.

I built MyIPScan, a set of IP and browser leak checks on Cloudflare Pages, and this one cost me two months of 404s.

That was a bug in the question, not in Google. I had built the check on DNS-over-HTTPS lookups sent straight from the page, and a DoH lookup from the page goes to the DoH provider, not to the resolver your system uses. So the test reported the one server it was guaranteed to reach, and it would have done the same with a VPN that leaked every query to the ISP.

I built MyIPScan, the site this test runs on, so everything below is my own code and my own mistakes.

This post covers how a browser DNS leak test can work at all, every timeout in the current code, what I measured, and why "Unable to check" never falls through to "no leak".

Why the page can't just ask

JavaScript in a page gets answers from DNS, never the identity of whoever asked on its behalf. There is no navigator.dnsResolver.

So any browser DNS leak test has to work backwards. You can't read the DNS resolver from the client side, so you read it from the server side: make the browser resolve a name that only you control, and log who comes asking.

What my first version did instead

The old check sent two DoH queries from the page, through the providers' JSON APIs.

The first was Cloudflare's whoami.cloudflare, a debugging name meant to be asked of Cloudflare's resolver directly. Through DoH, the client Cloudflare sees is my page's DoH request, so at best it describes that, not your system resolver. In practice it returned NXDOMAIN to the DoH query my page sent.

The second was Google's o-o.myaddr.l.google.com, a TXT name that Google Public DNS answers with the address of the Google resolver that handled the query, plus the EDNS client subnet if one was sent. Through Google's DoH, that means you learn about Google's own servers and a slice of the visitor's network. Never the system resolver.

A test that shows your public DNS provider every time looks reassuring. That is the problem.

The browser DNS leak test detour

The current test uses bash.ws, which runs a DNS zone whose authoritative server records every resolver that queries it. The whole probe is three steps:

1. GET https://bash.ws/id                     -> a one-time id
2. browser looks up N.<id>.bash.ws, N = 1..6  -> your resolver asks bash.ws's nameserver
3. GET https://bash.ws/dnsleak/test/<id>?json -> the resolvers that asked, plus the
                                                 public IP that fetched step 1

To make the browser resolve a name, I fetch it:

// FETCH_BASE = { cache: "no-store", credentials: "omit", referrerPolicy: "no-referrer" }
// timed(promise, ms, controller) races the promise against a timer that
// aborts the controller and rejects with "timeout".
function lookupOnce(url, outer) {
  const c = new AbortController();
  if (outer) outer.addEventListener("abort", () => c.abort(), { once: true });
  // The request is expected to fail. Only the DNS lookup before it matters.
  return timed(fetch(url, Object.assign({ mode: "no-cors", signal: c.signal }, FETCH_BASE)), LOOKUP_MS, c)
    .then(() => true, () => true);
}

I expect every one of these requests to fail, most likely at TLS, since 1.<id>.bash.ws is not a site anyone serves. How it fails doesn't matter. A browser has to resolve the name before it can open any connection, and the resolution is what bash.ws logs. Both outcomes of the promise map to true on purpose: success or failure of the fetch tells me nothing.

The id makes each name new, so no cache can answer for it. Whoever resolves it has to ask bash.ws, and bash.ws writes down who that was.

Every number in the probe

These are the constants in the shipped file, /assets/dns-resolver-probe.js:

The six lookups run in parallel (Promise.allSettled). After 700 ms the page reads the result. If no DNS rows have arrived yet, it waits 1.5 seconds and asks exactly once more. Resolvers are de-duplicated by IP and capped at eight.

Add up the worst case and you get 4 + 3 + 0.7 + 4 + 1.5 + 4 = 17.2 seconds. That exceeds the budget on purpose: per-step timeouts stop any one request hanging, and the 12-second budget aborts whatever step is running when it expires.

What I actually measured

On 24 October 2026 I loaded the probe module in my own Chrome on Windows, on my home ISP connection with no VPN, and ran it three times:

In the plain case a run takes a little over a second and the retry never fired. One resolver, on my ISP's network, as expected with nothing in between.

What this does not show: I haven't measured a VPN run or a Secure DNS run yet, and six lookups is an untested choice. My reasoning is that some setups spread queries across several upstreams; one connection with one resolver neither confirms nor refutes it.

Reading what comes back

The result lists resolver IPs with network (ASN) and country, next to your public IP. Each resolver gets one of five labels:

1. Same network: the resolver's ASN matches your public IP's. Typical of ISP DNS without a VPN, or a VPN running its own resolver.
2. Public DNS service: the ASN is on a fixed list (Google 15169, Cloudflare 13335, Quad9 19281 and 42, Cisco OpenDNS 36692, NextDNS 34939, AdGuard DNS 212772) or the organisation name matches one.
3. Different network: neither of the above, and not caught by the country check below.
4. Different country and different network: reviewed as a possible leak when you expect a VPN.
5. Not compared: the page didn't have what it needed to compare that resolver.

Label 4 is a prompt to look, not a verdict. Three things make honest setups look odd:

• Forwarders. If a resolver forwards to another, the authoritative server sees only the last hop. Your VPN's resolver can show up as its upstream somewhere else.
• Browser Secure DNS. If Chrome or Firefox uses a DoH provider, the browser skips the system resolver and you see the DoH provider. Mozilla began turning DoH on by default for US Firefox users in February 2020, so many people have this without choosing it.
• Proxies. An HTTP proxy using CONNECT resolves the hostname itself, so you see the proxy's resolver. A SOCKS5 proxy only does that with remote DNS enabled (in curl, socks5h:// instead of socks5://); otherwise your machine resolves locally.

A note on what the page can't know. On a VPN, your public IP is the VPN's, so the page has no idea who your home provider is. The page can't flag "your ISP" for you. You can: if the network column names your home provider while the VPN is on, that query went around the tunnel. That is the VPN DNS leak the test exists to show.

The result I refuse to fake

Plenty can stop the probe: a content blocker, a captive portal, a corporate network that only allows its own DNS, or bash.ws being down. Each leaves the result list empty.

An empty list is the most dangerous output a leak test has, because the obvious code calls it good news:

if (!resolvers.length) showClean(); // "no leaking resolvers found"

That line turns "I couldn't look" into "nothing there", and the person behind the blocker stops checking.

My probe throws instead when it saw nothing, and the error says which kind of nothing:

if (!resolvers.length) throw new Error(rows.some((r) => r.type === "error")
  ? "test id not found"
  : "no resolver seen");

The result rows from bash.ws come typed: ip for the public IP that fetched the id, dns for each resolver, conclusion, or error. An error row means bash.ws didn't know the id; no rows of type dns means it knew the id but nobody resolved the names.

The caller catches the error, adds an entry to an attempts list (source, ok, error, time) and returns null, and the page shows Unable to check.

I could have added ip-api.com as a fallback, but its free service is licensed for non-commercial use only. One provider and an honest "unknown" beats two providers and a licence problem.

What the probe sends, and what it keeps

A privacy tool that contacts third parties on page load would undercut its own point, so the probe module is loaded with a dynamic import only when you press the button. Before that, nothing contacts bash.ws.

When you run it, bash.ws sees your public IP and the resolvers that ask on your behalf; that's inherent to the method. The one-time id and the test hostnames stay inside the module. The attempts list lives in the returned object in page memory and disappears with the tab; nothing is written to storage, and MyIPScan doesn't store the result on its side either.

The page also runs a control lookup through MyIPScan's own DNS Lookup API, server side via a free public DoH resolver. It only proves the API path is up and is never counted as evidence about your resolver.

Rules I'd give anyone building one

• Observe from the side that can see. Make the client cause an event on a server you can read.
• Make every name unique. A cached answer tells you about the cache, not the resolver.
• Bound every step, then bound the whole run.
• Keep "unknown" as a third state all the way to the UI. An empty list is not a pass.
• Pick fallbacks you're allowed to use. Read the terms first.

To watch it run, open the network panel and press the button on the DNS leak test at MyIPScan. You'll see the id request, six failing fetches to N.<id>.bash.ws, then the result read. The methodology page at myipscan.net/methodology describes the same flow and its limits.

One question for people who have tested this on more networks than I have: when you resolve several unique names through a VPN's DNS, how many distinct resolvers do you usually see, and is six enough to catch them?