Hosted relay returns Cloudflare 526 to Worker subrequests
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
**Describe the bug**
A Cloudflare Worker in a different Cloudflare account intermittently cannot reach a hosted relay at `.communities.buzz.xyz`. Repeated HTTPS subrequests from the Cloudflare edge return `526 Invalid SSL certificate` on some attempts, while other attempts reach the application (`/health` returns 200; unauthenticated GET probes to protected endpoints return 403). A production signed `POST /events` from the Worker returned 526 and blocked remote automation that submits Buzz events through the documented HTTP API.
The public client-facing certificate is valid: an OpenSSL handshake from macOS verifies the Google Trust Services chain for `communities.buzz.xyz`, and direct local requests to `/health` return 200. The failure is specific to the Worker-originated/cross-zone path. The exact Cloudflare internal path is unknown, and the available evidence does not distinguish between provider-side Cloudflare for SaaS configuration and Cloudflare platform routing; the zone owner is required to investigate either path.
**Steps to reproduce**
1. Deploy a read-only Worker in another Cloudflare account that calls `fetch("https://.communities.buzz.xyz/health")`.
2. Invoke the Worker repeatedly from the Cloudflare edge.
3. Observe that some invocations return HTTP 526. The same failure has been observed for GET probes to `/events` and `/query`, and for a WebSocket upgrade.
4. Enable the documented `global_fetch_strictly_public` compatibility flag and repeat; 526 responses still occur.
The GET requests to `/events` and `/query` are read-only TLS/reachability probes, not calls using those endpoints with their normal methods. A healthy path is expected to return an application response such as 403 or 405. The actual automation failure was a signed `POST /events` returning 526.
**Expected behavior**
Cloudflare Workers should consistently reach the hosted relay over HTTPS, with `/health` returning 200 and authenticated relay requests reaching the Buzz application.
**Version and platform**
- Buzz version: hosted relay, exact version unknown
- Caller: Cloudflare Workers runtime, compatibility date `2026-08-03`
- Local control: macOS, direct TLS verification succeeds
**Logs / additional context**
Representative failing read-only Cloudflare edge probe on 2026-08-03:
```text
GET https://.communities.buzz.xyz/health -> 526, CF-Ray a25257d4ae0baf6d-NRT
GET https://.communities.buzz.xyz/events -> 526, CF-Ray a25257d4ae0caf6d-NRT
GET https://.communities.buzz.xyz/query -> 526, CF-Ray a25257d4ae0daf6d-NRT
WebSocket upgrade -> 526, CF-Ray a25258c7348caf6d-NRT
Plain HTTP endpoints -> 522
```
Other Cloudflare edge probes reached the application: `/health` returned 200, and unauthenticated GET probes to `/events` and `/query` returned 403. This intermittent behavior may help distinguish origin, colo, or routing differences.
Direct public control at approximately the same time:
```text
openssl s_client: Verification: OK; Verify return code: 0
GET /health -> HTTP/2 200, CF-Ray a25252592e7a57c0-NRT
```
DNS:
```text
.communities.buzz.xyz CNAME communities.buzz.xyz.cdn.cloudflare.net
```
Please check both provider-owned configuration and Cloudflare platform routing for the hosted relay. Relevant provider-side settings include the Cloudflare for SaaS custom hostname, fallback origin, `custom_origin_server`, `custom_origin_sni`, and origin certificate/SNI coverage. If those are correct, the Ray IDs above should support escalation to Cloudflare for the Worker-originated/cross-zone path.
Contributor guide
Research direction
Start with the hosted relay's Cloudflare for SaaS custom hostname, fallback origin, custom_origin_server, custom_origin_sni, and origin certificate/SNI coverage. Compare the intermittent 526 probes, direct /health result, DNS CNAME, and listed CF-Ray IDs, then escalate to Cloudflare if provider settings are correct. Done means consistent Worker HTTPS reachability, including /health returning 200 and authenticated relay requests reaching the application.
Written by the indexing model from the issue text.
Assessment
- Domain
- cloud, networking, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100