[Bug]: CheckHelperImageJob fails with HTTP 403 + HTML page, while direct curl to the same URL succeeds

[watsonsimpore]

Error Message and Logs

Telegram notification (received repeatedly over 2 consecutive days):

CheckHelperImageJob failed with: HTTP request returned status code 403:

...(truncated HTML page, not JSON)

This is notable because it's not the usual cURL timeout/DNS errors reported in
other issues (e.g. #6298) — the job receives a full HTML page with HTTP 403,
suggesting a WAF/challenge response rather than a network connectivity failure.

Steps to Reproduce

1. Self-hosted Coolify instance with Telegram notifications enabled for job failures.
2. Wait for the scheduled CheckHelperImageJob run (checks https://cdn.coollabs.io/coolify/versions.json).
3. Job fails with HTTP 403 and an HTML response body instead of JSON.
4. From the same server, run: curl -v https://cdn.coollabs.io/coolify/versions.json
   → returns HTTP 200 with valid JSON immediately, no blocking, no rate limiting.

Example Repository URL

No response

Coolify Version

v4.1.2

Are you using Coolify Cloud?

No (self-hosted)

Operating System and Version (self-hosted)

Ubuntu 25.10

Additional Information

Manual verification that outbound connectivity from the server is healthy:

$ curl -v https://cdn.coollabs.io/coolify/versions.json
< HTTP/2 200
< content-type: application/json
< server: cloudflare
{ "coolify": { "v4": {...}, "helper": {"version": "1.0.14"}, ... } }

Since a plain curl succeeds instantly from the same host, this rules out
firewall/DNS/proxy issues on my side. Looking at app/Jobs/CheckHelperImageJob.php,
the request is made via Http::retry(3, 1000)->get(...) — Laravel's default
Guzzle client, with no custom User-Agent header. cdn.coollabs.io is served via
Cloudflare, and it's a known pattern for Cloudflare's bot protection / WAF to
intermittently challenge generic HTTP client signatures (default Guzzle UA)
while allowing curl through. This might explain the intermittent 403 + HTML
challenge page seen here, distinct from the timeout/DNS issues in other reports.

Suggested fix: set an explicit User-Agent header (e.g. "Coolify/{version}") on
this HTTP call, which is a common workaround for Cloudflare bot-protection
false positives.

[coderabbitai]

🔗 Related PRs

#7396 - Fix: Version downgrade prevention with cache validation [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[krizh-p]

I've gotten the same error in my Coolify instance for the past three days as well. I'm also using Cloudflare tunnels; my second, separate instance not using Cloudflare tunnels doesn't experience this problem.

[itsbrody]

Can confirm this pattern on my instance (Coolify v4.1.2, self-hosted, Ubuntu 24.04 LTS).

Timeline:

• 2026-07-10, 08:00 UTC: single one-off occurrence
• Starting 2026-07-12: fails reliably at 00:00 UTC, repeating daily since then

Additional detail: My instance has update_check_frequency: 0 * * * * (hourly) with instance_timezone: UTC. Only the 00:00 UTC run fails — the other 23 hourly runs each day succeed. This points toward something specific happening on cdn.coollabs.io / Cloudflare around midnight UTC rather than a random intermittent block, which fits the bot-protection theory here.

Manual curl -sI against the versions URL right after a failure also returns a clean HTTP/2 200 with cf-cache-status: HIT, consistent with what's reported above.

Re: @krizh-p's Cloudflare Tunnel correlation — worth noting I'm not using Cloudflare Tunnels (verified: no cloudflared binary, no related containers or systemd units on my host), and I still see the exact same failure pattern. So a tunnel setup doesn't appear to be a required factor, though it's possible it's a contributing one for some environments.

The suggested User-Agent fix sounds like the right direction if this is indeed Cloudflare bot protection flagging the default Guzzle signature.

[andrasbacsai]

We moved the cdn to Cloudflare a few days ago and probably their default security config doing this.

Added a custom rule to prevent this.

Lets monitor it in the upcoming days.

[CaffeinatedTech]

I just got the 403 message again an hour ago.

[schliesser]

I'm also getting this error since 12. july. Last today 5 hours ago.

[andreacasarin]

Same error here aswell since July 10th.

[PovarovDenis]

Same here

CheckHelperImageJob failed with: HTTP request returned status code 403:
<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en-US"> <![endif]-->
<!--[if IE 7]>    <html class (truncated...)

[andrasbacsai]

Fine tuned the expression again, so lets see. Please report if its back.

[ponas]

Got the same error a minute ago.