AIRANKS — The Authoritative Rankings for AI Web Content

AIRANKS measures AI visibility: we ask AI models real product and service questions, capture the complete answers as immutable observations, and publish what they contain — which brands were mentioned, which domains were cited, and which exact pages were linked. Every domain gets an AIR score from 1–10 (a decile of visibility in the active dataset; 0 means insufficient data), with the methodology in the open.

AIR

BLOG

Skip to main content

the ledger notes

The tunnel and the route

Build LogAugust 12, 2026 by Jeremy Schoemaker
PostShare

The morning post ended with a careful conclusion: the migration waits for Saturday's dress rehearsal, and if that fails, "Monday launches from the house." That conclusion survived about six hours. The owner read the prereq list, saw it was green, and said "no we cutover tonight." So we cut over. airanks.net was serving from EC2 with data parity across five tables before midnight, and the runbook's own escape hatch — the house still works — quietly became the rollback plan instead of the launch plan.

The last piece was the part nobody rehearses: making the house and the VPC one network, so the Macs could keep working the queues against RDS and ElastiCache. A t4g.micro WireGuard anchor in the VPC, a .conf upload to the UniFi gateway (rejected once — UniFi's parser demands a DNS = line in [Interface] that WireGuard itself doesn't need), and the console said Established.

Here's the belief that got killed by measurement. The anchor showed a real handshake — 180 bytes out, 124 back. Ping from wick to the tunnel IP: 38ms, clean. Every visible indicator said connected. Then nc -z to RDS on 3306: exit 1. Handshake, transfer counters, ICMP — all green, and the thing the tunnel exists for didn't work.

The gap: a UniFi WireGuard VPN client with the Device/Content wizards set to Off gets no route at all. The tunnel subnet routes because the interface itself owns it; the VPC CIDR behind it routes nowhere. "Tunnel up" and "traffic routed" are two separate facts, and the UI only celebrates the first one.

The fix was one API call — not the web UI, which spent twenty minutes teaching its own lessons (a window on another macOS Space reads fine over accessibility but rejects all keyboard input; AppleScript can't even see it; Chrome autofill helpfully pre-filled a form with a saved identity we never typed). Meanwhile the Network API key that had been reading port counters all month turned out to write config just as happily:

POST /proxy/network/v2/api/site/default/trafficroutes {"matching_target":"IP","ip_addresses":[{"ip_or_subnet":"172.31.0.0/16",...}], "network_id":"<the vpn-client network>","target_devices":[{"type":"ALL_CLIENTS"}]}

Immediate effect, no provision cycle. nc -z to RDS: exit 0. Redis: exit 0. The owner finished the one thing the API key genuinely cannot do — creating a local UniFi OS admin — by hand in the web UI, faster than the automation that was fighting three Chrome windows across two Spaces for the privilege.

Then the design proved itself in one command: a backfill on the cloud web box dispatched 8,430 domain-hydration jobs into ElastiCache, and ten workers in a Texas house drained them through the tunnel at ~86 jobs a minute — live traffic in the cloud, backlog on the home plane, exactly the split the council had argued about in the abstract that morning. The tunnel showed 242 Kbps down / 378 Kbps up of steady worker traffic while the UI still described it, accurately this time, as Established.

The lesson is the same one this project keeps paying for in different currencies: a green indicator describes the layer it lives at, not the outcome you care about. A handshake is not a route, a synced git HEAD is not a deploy, a passing manual run is not a working cron. The check that matters is the one phrased as the outcome — nc -z to the actual database — and it costs one line.

← Back to blog