Support

Hello,

Admin Tools Professional 7.9.1 on Joomla 6.1.2 shows the "Core file verification unavailable" warning after every PHP File Change Scanner run.

I traced the cause: my server *can* reach `getpanopticon.com` perfectly (DNS, TLS and routing are fine, response in 0.1 s), but Cloudflare serves it an interstitial challenge page instead of the checksums file. Critically, it is returned with **HTTP 200 and `content-type: text/html`**, so Admin Tools sees a successful download and then fails to gunzip it.

**Server outbound IP:** 62.193.193.15 (Belgium, shared hosting)

**Test results** (plain cURL from the server, PHP 8.4.23 / cURL 8.21.0):

| Test | URL | User agent | Result |
|---|---|---|---|
| A | /checksums/joomla/6.1.2/md5.json.gz | `CoreSumsTest/2.0` | HTTP 200, text/html, 11956 bytes, title "One moment, please...", `cf-ray: a267978bdd35985a-BRU`, `cf-cache-status: HIT` |
| B | same | Chrome 139 desktop UA | identical, `cf-ray: a267978c0b245631-BRU` |
| C | same | `Joomla/6.1 (Admin Tools CoreSums)` | identical, `cf-ray: a267978c3d222211-BRU` |
| D | /checksums/ | Chrome 139 desktop UA | identical, `cf-ray: a267978c7a57b1ce-BRU`, `cf-cache-status: MISS` |
| E | / (homepage) | Chrome 139 desktop UA | identical, `cf-ray: a267978cfcc43d1a-BRU`, `cf-cache-status: DYNAMIC` |

`https://getpanopticon.com/cdn-cgi/trace` from the same server returns:

```
ip=62.193.193.15
uag=CoreSumsTest/2.0
colo=BRU
http=http/2
loc=BE
tls=TLSv1.3
```

Notes:

- The challenge is served regardless of user agent and on every path including the site root, so this looks like an IP-reputation or ASN-level rule rather than bot filtering on the checksums endpoint.
- The same URL returns the correct gzip payload from other networks, so the service itself is healthy.
- Requests reach the BRU (Brussels) Cloudflare colo.

**Requests:**

1. Could you allowlist this IP (or exempt the `/checksums/*` path from the challenge, since it serves static public files to servers rather than browsers)?
2. Would you consider having Admin Tools validate the response `content-type` / gzip magic bytes and log the actual body when it is not gzip? Right now a challenge page returned with HTTP 200 produces only a generic "could not download" warning, which makes this failure mode hard to diagnose.

Thank you.

Follow-up with a controlled comparison.

I ran the exact same test script from a different host, on a Portuguese
ISP (outbound IP 62.233.41.62, Cloudflare colo LIS), and every request
succeeded:

/checksums/joomla/6.1.2/md5.json.gz
-> HTTP 200, content-type: application/x-gzip, 229111 bytes,
valid gzip, 819011 bytes of JSON
cf-ray: a267ae9a093ce3b8-LIS
Same result for all three user agents (generic, Chrome, Joomla).
/checksums/ and / also returned the real pages, not a challenge.

From the blocked server (62.193.193.15, Belgium, colo BRU) the same
URLs return the "One moment, please..." interstitial regardless of
user agent. So the trigger is IP/ASN reputation on that outbound
address, not the request itself.

My site is migrating to the working network in a few days, so this is
no longer blocking me. Two things may still be worth your attention:

1. Other customers on Belgian shared hosting are likely hitting the
same wall silently.
2. The failure is invisible to Admin Tools because Cloudflare returns
the challenge with HTTP 200. Checking the response content-type or
the gzip magic bytes, and logging the first bytes of the body when
they do not match, would turn this from a generic "could not
download" warning into a one-glance diagnosis.