The Ref number was a Cloudflare address

The Ref number on the blocked page read 104.23.x.x. That’s a Cloudflare edge address, and the visitor it was attached to was on a residential VPN in Florida.

He had filed a support ticket saying he couldn’t reach the site at all, just a block page with a reference number. Support pasted the Ref number into the firewall log to look him up and got nothing. The number on his screen wasn’t his IP. It was Cloudflare’s edge server IP for the request that hit our origin.

His VPN egress IP sat inside a hosting-provider range we’d blocklisted months earlier, the kind of range abused for scraping and credential stuffing. The rule was doing its job. We found his actual IP through the account, correlated the timestamp, and unblocking just that address was the easy part.

The harder part was the Ref number itself, because it’s supposed to make this fast. A customer hits a block, screenshots the Ref number, support pastes it into the firewall log, done. The value being captured was whatever IP the code found first when it walked the request headers. On our stack that landed on the connecting peer address at the edge, which is Cloudflare’s own server, instead of CF-Connecting-IP.

The check that builds the block page constructs the record from the request object. Somewhere in that path, someone had grabbed the socket-level remote address as a fallback, and it was winning over the header Cloudflare sets for this purpose. That fallback was correct enough when no proxy sat between the client and our origin. It was wrong every time Cloudflare did.

The same ordering in the shared helper

Once we saw it in the block page, we checked the shared Cloudflare IP-parsing helper the rest of the app calls. It had the identical ordering bug. Anything using that helper to log or display “the visitor’s IP” was capturing edge infrastructure whenever the two disagreed, which in practice is whenever the header exists at all. It had presumably been wrong for a long time. The two only diverge when the header path is exercised, so it took a blocked VPN user with a support ticket for anyone to notice.

The fix was to read CF-Connecting-IP first and use the raw remote address only when the header is absent:

def get_client_ip(request):
    cf_ip = request.headers.get("CF-Connecting-IP")
    if cf_ip:
        return cf_ip
    return request.remote_addr

Trivial diff. The logic was never the problem. The fallback had been promoted to primary at some point, and nobody had a reason to look until the number on screen stopped matching anything a person could search for.

Checking it live

We fixed the block page and the shared helper together and shipped them as one hotfix. Then we checked against his session. The block page rendered his real VPN egress IP in the Ref number, and the helper returned the right address too. Fixing only the block page would have left the next support ticket hitting the same wall somewhere else in the app.

We closed the ticket with a reply for support to send him, and gave the account its own whitelist entry so the range block doesn’t refire on him. The fix that mattered was making the Ref number trustworthy again. A block page that shows the wrong IP breaks the one support workflow that exists to resolve blocks quickly. It does that in exactly the cases where you most need the number to be right, when the request came in through a proxy layer.

If your site sits behind a proxy or CDN, look at what your block page shows as the reference number, and check that every shared helper reads the proxy’s client-IP header before it touches the socket address.