Intermittent Cloudflare 502 (HTML page) on REST API via Seoul (ICN) edge — not in API logs

[feedle-woogi]

Is anyone else in the Seoul / ap-northeast-2 region seeing this?

Setup

• Project region: ap-northeast-2, Pro plan
• Client: supabase-js, called server-side from Next.js on Vercel (icn1)

Symptom

• Since 2026-10-20, REST (/rest/v1/*) and /auth/v1/user requests intermittently
  return an HTML "502 Bad Gateway" page from Cloudflare, not a PostgREST error.
• The cf-ray header always ends in -ICN.
• The project's API edge logs show 0 responses with status 502 for the same
  periods, so the requests seem to fail before reaching the gateway.
• It happens several times a day, including low-traffic hours (01:00–04:00 KST),
  so it does not look load-related.
• Retrying once after 200 ms almost always returns 200. On one occasion the
  retry also returned 502.

Questions

1. Is this a known issue with the Seoul edge?
2. Can a Cloudflare 502 like this be treated as "never reached PostgREST", so
   that retrying writes (POST/PATCH/DELETE/RPC) is safe?

A support ticket is open as well. I'm asking here to see whether others have
the same problem.

[Rustaman1280]

Here is a technical breakdown of what is happening under the hood and why you must be careful with write retries.

1. Why does Cloudflare return an HTML 502 that does not appear in Supabase logs?

When Cloudflare serves its own HTML "502 Bad Gateway" page (identifiable by the Cloudflare branded HTML and a cf-ray header ending in -ICN), the error is generated by Cloudflare's Seoul edge proxy, not by Supabase's Kong gateway or PostgREST:

• Origin Connection Failure: Cloudflare attempted to forward the request to the Supabase upstream origin (in AWS ap-northeast-2), but the TCP handshake timed out, TLS negotiation failed, or the origin sent a TCP RST. Because the request never successfully reached Kong/Envoy, Kong never processed it, which is why your project's edge_logs report 0 errors for that timestamp.
• Vercel / Undici Keep-Alive Race: In Next.js (Node.js runtime on Vercel icn1), fetch uses persistent keep-alive connection pooling via undici. If Cloudflare's edge node closes an idle keep-alive socket at the exact same millisecond Vercel reuses that socket to send an outgoing request, Cloudflare tears down the connection and emits an immediate 502. Because network traffic between Vercel icn1 and Cloudflare ICN has near-zero latency, keep-alive race windows happen disproportionately during low-traffic periods when pooled sockets sit idle near their timeout threshold.

2. Can a Cloudflare 502 be treated as "never reached PostgREST" (safe for write retries)?

Short answer: No, you should not assume the write never reached the database.

While most 502s occur during the initial TCP/TLS handshake before any bytes are transmitted, a 502 is also returned in a second, dangerous failure mode:

• Mid-flight socket termination after write execution:
  1. Cloudflare sends the HTTP POST / RPC payload to Kong.
  2. Kong forwards it to PostgREST, and PostgreSQL commits the transaction to disk.
  3. Right as the response is being sent back, the upstream connection between AWS and Cloudflare drops (e.g., an AWS ALB/gateway idle timeout, proxy worker reload, or transient TCP packet loss).
  4. From Cloudflare's perspective, the origin severed the connection before delivering valid HTTP response headers, so Cloudflare serves a 502 Bad Gateway to your Next.js client.
  5. The database already persisted the record, but your client receives a failure.

If you blindly retry non-idempotent writes (POST or non-idempotent RPC), you risk duplicate row insertions or double execution of business logic.

3. Recommended Remediation & Architecture

1. Make Writes Idempotent with Client-Generated Keys:

   • For Table Inserts: Generate a UUID on the client (crypto.randomUUID()) for the primary key or unique identifier, and use .upsert(..., { onConflict: 'id' }) instead of .insert(...). If a 502 retry occurs after a successful commit, the second call is an idempotent no-op rather than a duplicate insertion.
   • For RPCs: Pass an idempotency_key parameter and verify against a processed keys table inside your PostgreSQL function before executing the side effect.

2. Safe Retry Matrix:

   • Safe to auto-retry: GET, HEAD, PUT, DELETE, and idempotent PATCH.
   • Unsafe to auto-retry without idempotency tokens: raw .insert() and non-idempotent rpc().

3. Bypass the Cloudflare Edge via Direct Supavisor Connection:

   • If your Next.js server-side code runs in Node.js (Server Actions, Route Handlers), consider connecting directly via PostgreSQL connection pooler (Supavisor on port 6543) using postgres-js or pg. This establishes a direct TCP+TLS connection to AWS ap-northeast-2 without traversing Cloudflare's HTTP reverse proxy, eliminating Cloudflare HTML 502 edge errors entirely for backend database operations.

[nicholas-greenwood]

tempting, given the 200 ms retry nearly always works, but i wouldn't read it as "never reached postgrest"

a 502 only says a proxy got an invalid response from upstream, not whether the write was applied. edge_logs only cover http requests through the api gateway, so a missing row there isn't proof nothing committed

rfc 9110 says not to auto-retry a non-idempotent request unless you know it's idempotent or can tell the original never ran. DELETE counts as idempotent there. POST, PATCH and rpc depend on what each call does

for writes that already got a 502, i'd look them up by a stable business or operation key before replaying anything

going forward, i'd save a unique operation key in the same transaction as the side effect and its result, and have a retry with an existing key return that saved result. keep the key non-null, since nulls don't clash under a unique constraint by default

i can't tell whether seoul has a known issue. -ICN only says which cloudflare data centre processed the request, not which part failed

for the ticket:

• exact timestamp and time zone
• method and url
• cf-ray
• row or operation key
• response page and headers, and whether the page is cloudflare-branded (cloudflare reads a branded 502 as the origin's)

[RafchanSami]

If the 502 response is generated by Cloudflare and the request never appears in your API logs, I would investigate the connection between the Cloudflare edge and the origin server first.

Here are a few troubleshooting steps:

1. Check the Cloudflare Ray ID

Capture the CF-Ray response header from failed requests. It can help identify the specific request and the Cloudflare data center handling it (ICN in this case).

2. Compare successful and failed responses

Record these headers:

• CF-Ray
• CF-Cache-Status
• Server
• HTTP status code

Check whether failures consistently come from the ICN edge.

3. Check origin connectivity

Review origin server logs, load balancer logs, firewall rules, and TLS handshake errors. The request might fail before reaching the API application.

4. Test the origin directly

If possible, send the same request directly to the origin while preserving the correct Host header and TLS SNI. Compare the result with the Cloudflare-proxied request.

5. Check Cloudflare error details

Inspect the full 502 HTML response and its Ray ID. Different 502 error messages can indicate different failure points.

Could you share:

• The exact 502 HTML error message
• Whether the issue happens only through ICN or other Cloudflare locations too
• Whether direct-origin requests succeed
• The response headers and timestamps of failed requests

These details should help narrow down whether this is an edge-to-origin connectivity issue or an origin-side failure.

Avoid sharing API keys, cookies, or other sensitive credentials.