Possible bug with loopback test

Hi, I’m observing something odd when running the plugin’s cache health / loopback-style checks on my setup, and I wanted to ask whether this could be a bug in how the test target URL is built.

My topology is:

– public site URL: https://example.com
– WordPress runs behind nginx
– Varnish is exposed only on a localhost port, for example 127.0.0.1:57005
– that Varnish port is plain HTTP, not HTTPS
– the plugin is configured to target Varnish through VHP_VARNISH_IP=127.0.0.1:57005

So the intended flow is effectively:

– browser -> public nginx -> Varnish
– plugin purge/health checks -> 127.0.0.1:57005 with Host: example.com

What I observe is:

– the site itself works properly in the browser
– direct HTTP requests to the Varnish loopback port work when sent like this:

curl -H ‘Host: example.com’ http://127.0.0.1:57005/

– but the plugin reports:

Could not reach any site URLs. Your server may block loopback requests.

From reading the behavior, it looks like the test may be preserving the original site scheme from home_url(), which is HTTPS, and then rewriting only the host/port to VHP_VARNISH_IP.

If that is what’s happening, the resulting request would become something like:

https://127.0.0.1:57005/

with:

Host: example.com
It’s my understanding that direct requests to Varnish in this kind of setup should normally still use plain HTTP transport, and the original frontend scheme should be distinguished separately, for example
via X-Forwarded-Proto, rather than by trying to speak HTTPS directly to the localhost Varnish port.

So in this case, the loopback target itself appears reachable, but the scheme used for the rewritten health-check URL would be wrong for that endpoint.

My guess is that this may explain the misleading “server may block loopback requests” result in cases where loopback is actually fine.

I wanted to ask:

• could the health check force http:// when VHP_VARNISH_IP is used as a host:port override?
• or alternatively support an explicit scheme-aware override?
• if preserving the original scheme is intentional, would it make sense to at least improve the error message so it distinguishes real loopback blocking from a protocol mismatch? I may be misunderstanding the intended behavior, but from my testing this looks like a possible false negative in the loopback test on HTTPS sites using a plain HTTP localhost Varnish port.

ON wordpress itself the URL is set as https://example.com

PS: The full cache test is all greens

Connectivity Test

Verify connection to cache server

Connected to: 127.0.0.1:57005

Create Test Post

Create a temporary post with unique content

Created post: #117

Prime Cache

Request the post to populate the cache

HTTP 200
x-cache: MISSx-varnish: 1212439age: 0via: 1.1 af90f568aa14 (Varnish/7.7)

Verify Caching

Modify post and confirm cache serves stale content

Cache is serving stale content ✓
x-cache: HITx-varnish: 1212442 1212440age: 2via: 1.1 af90f568aa14 (Varnish/7.7)

Trigger Purge

Send PURGE request to invalidate cached content

PURGE sent for: https://example.com/vhp-cache-test-2026-03-26-175458/

Verify Purge

Confirm fresh content is now served

Fresh content now being served ✓
x-cache: HITx-varnish: 1277957 1212447age: 2via: 1.1 af90f568aa14 (Varnish/7.7)

Cleanup

Delete test post and temporary data

Test post deleted