A customer on a VPN could not get into the site. We had blocked him, and the reason was ordinary: his VPN exit address sat in a blacklisted hosting range. We unblocked his address and nothing else.
The part worth writing down is the block page. It shows a Ref number, and that number is meant to be the visitor’s IP. It was showing a Cloudflare address instead.
Two places, one bug
The wrong address was not only on the block page. The same parsing bug sat in the shared Cloudflare check that other pages call. We fixed both places and shipped the change as one hotfix, then loaded the page and confirmed it live before closing the ticket.
The same week, a wider rule
Scanner requests for .php paths were still reaching our server, and we found out why and closed the gap with a wider Cloudflare rule. A wide rule on a file extension is exactly the kind that catches real files, so the check that mattered was whether it spared a real customer photo. It did, and we verified that live before the ticket closed.
The crawl tool we use to check pages for problems already lived in our own tooling, so the ticket to build one closed as no-code. Two follow-ups came out of it: one to verify the first weekly crawl run actually happens, and one for an IP Octet Review script that does not exist yet.
What to take from it
Load your own block page from behind your proxy and read the address it prints. If it is the proxy’s address, it cannot help anyone diagnose a real customer. Then look for the same parsing in other checks, because it was in two places here.
AI Skills
Use this lesson with the AI assistant you already use
A customer on a VPN was blocked because his exit address sat in a blacklisted hosting range. The block page printed a Cloudflare address in its Ref field instead of his IP, and the same parsing bug lived in a second check. One hotfix fixed both.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Check That A Block Page Names The Visitor, Not The Proxy
SOURCE: dxdev.com/blog/2026-09-27_silent-failures-need-daily-check
WHAT HAPPENED: A customer was blocked because the VPN address he used sat in a blacklisted hosting range. The blocked page showed a Cloudflare address in its Ref field instead of the visitor's IP. The same parsing bug existed in a shared Cloudflare check. The fix covered both places and shipped as one hotfix, verified live.
THE RULE: Anything that shows a visitor's address for support or diagnosis must be tested from behind the proxy. If it prints the proxy's own address, it cannot help you find the real cause.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Does every page or log line that prints a client IP read the visitor address rather than the connecting proxy address?
2. Is client-IP parsing done in one shared place, or copied into several checks?
3. Has the block or error page been loaded from behind the proxy in a live test, not only read in code?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.