Cloudflare Workers → PostgREST requests fail with HTTP 500 (Cloudflare error 1003), while the same requests succeed outside Workers

[edwinzunigap]

Hi Supabase team,

I'm looking for guidance because we've exhausted the usual troubleshooting steps and have an open support ticket (SU-432362).

Stack

• Next.js (OpenNext)
• Cloudflare Workers
• @supabase/supabase-js 2.110.8
• @supabase/ssr 0.12.3

Problem

Our application deploys successfully to Cloudflare Workers.

However, every PostgREST request executed from inside the Worker fails and our app returns HTTP 500.

The same request succeeds (HTTP 200) when executed from outside Cloudflare Workers.

The runtime exception is:

Error: No se pudo leer el catálogo: error code: 1003
    at Object.listPublished (worker.js:70807:24)

The failing request is triggered from:

GET /es-MX

What we have already verified

• Cloudflare Worker deploys successfully.
• Runtime environment variables are present.
• NEXT_PUBLIC_SUPABASE_URL is correct.
• NEXT_PUBLIC_SUPABASE_ANON_KEY is correct.
• Service Role Secret is configured correctly.
• RLS policies are correct.
• Network restrictions are open (0.0.0.0/0).
• No banned IPs.
• Same REST endpoint returns HTTP 200 outside Cloudflare Workers.
• Explicit globalThis.fetch testing made no difference.

What makes this confusing

Everything points to the request only failing when executed from Cloudflare Workers.

That makes us suspect some interaction between Cloudflare Workers and Cloudflare protection in front of the Supabase API (WAF/Bot Management or similar), but we have not been able to confirm that.

Question

Has anyone seen Cloudflare Workers requests consistently fail with Cloudflare error 1003 while the exact same PostgREST request succeeds from outside Workers?

Is there any known compatibility issue, configuration, or diagnostic we should check?

Any guidance would be greatly appreciated.

Thank you!

[GaryAustin1]

Is the request even making it to the Supabase API Gateway log?

What is the form of your URL for Supabase?

[edwinzunigap]

Hola Gary! Thanks for your reply and for taking a look at this. That's exactly what we're trying to determine. From our side we can confirm: The application works correctly outside Cloudflare Workers. The same request fails consistently only when executed from a Cloudflare Worker. We performed a completely clean production deployment (lint, typecheck, tests, build, deploy all passed) and reproduced the exact same behaviour. The failure occurs while calling listPublished() using the Supabase server client. The Worker logs only report: Error: Failed to read catalog: error code: 1003 We currently don't know whether the request actually reaches the Supabase API Gateway or is rejected earlier by Cloudflare's edge. Regarding the URL, we're using the standard project URL provided by Supabase: https://<project-ref>.supabase.co (No direct IP, no custom domain.) We use the official @supabase/supabase-js client with the project's standard SUPABASE_URL and anon key. Is there a way for us—or for the Supabase team—to verify whether these requests appear in the API Gateway logs? That would immediately tell us whether the request reaches Supabase or is blocked before the gateway.

…

On Mon, Jul 27, 2026 at 7:30 AM GaryAustin1 ***@***.***> wrote: Is the request even making it to the Supabase API Gateway log? What is the form of your URL for Supabase? — Reply to this email directly, view it on GitHub <#48342?email_source=notifications&email_token=CJ2CD6QYR72LJI7X2EATF4D5G5KP7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXHE3TSMZZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17797939>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CJ2CD6TXO6TGPXRHE3CJ7ET5G5KP7AVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBVGAYTMNBSUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CJ2CD6QLAPOYXZISFSSGL435G5KP7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXHE3TSMZZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CJ2CD6QPYFMS2E4Z6WZYMF35G5KP7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXHE3TSMZZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[GaryAustin1]

You look in logs in the dashboard under Logs, then API Gateway.
If this is happening on the Cloudflare side (which I believe that error code indicates) then they may not be showing up. The biggest thing I see online is for people using direct IP instead of full URL, which you believe you are doing correctly.

Note Supabase will not likely see your issue here, but you also have a ticket generated which is correct for them to comment.

[edwinzunigap]

Thanks — I checked the Supabase Dashboard under Logs → API Gateway. The only matching request to the products endpoint is this previous manual curl test: GET /rest/v1/products?select=id&limit=1 User-Agent: curl/8.7.1 Status: 200 There is no API Gateway log entry corresponding to the failing request from the Cloudflare Worker during the latest reproduction. So the full Supabase URL works correctly from outside Workers, but the failing Worker request does not appear to reach the Supabase API Gateway at all. That seems consistent with the request being rejected earlier at the Cloudflare edge. I’ll add this evidence to support ticket SU-432362 as well.

…

On Mon, Jul 27, 2026 at 7:45 AM GaryAustin1 ***@***.***> wrote: You look in logs in the dashboard under Logs, then API Gateway. If this is happening on the Cloudflare side (which I believe that error code indicates) then they may not be showing up. The biggest thing I see online is for people using direct IP instead of full URL, which you believe you are doing correctly. Note Supabase will not likely see your issue here, but you also have a ticket generated which is correct for them to comment. — Reply to this email directly, view it on GitHub <#48342?email_source=notifications&email_token=CJ2CD6TYTQ2UCR6X72QL7NL5G5MGZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXHE4DCMZYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17798138>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CJ2CD6SLG4M7DHTTYJNNYZT5G5MGZAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBVGAYTMNBSUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CJ2CD6UWFRZQY5YRUX2PPJT5G5MGZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXHE4DCMZYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CJ2CD6UK7HB2YTL3LC6PX5L5G5MGZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXHE4DCMZYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>