In-App Notifications Disconnect and Reconnect (SSE)
Symptom
The browser console repeatedly reports a connection-interrupted error such as ERR_HTTP2_PROTOCOL_ERROR 200 (OK); notification messages only appear after a page refresh; the request drops and reconnects at fixed intervals.
Cause
In-app notifications use an SSE long-lived connection (/api/notify/user/sse/connect): the handshake succeeds and response headers return immediately, after which the server keeps it alive with periodic heartbeats. When any layer in the middle gives up waiting for data earlier than the heartbeat interval (currently 10 seconds), it cuts the stream after the browser has already received the 200, and the frontend reconnects automatically — a repeating disconnect loop.
Note that 200 means the handshake succeeded — this is not a caching problem, and not an auth or backend error, but the stream being terminated by a middle layer after it was established.
Real incident: in 2026-09, with the demo site behind Tencent EdgeOne, the notification connection dropped every 20–40 seconds and the browser reported
ERR_HTTP2_PROTOCOL_ERROR 200 (OK). An identical deployment reached directly (no CDN) stayed up for a long time, pinpointing the CDN edge's origin-wait timeout.
Fix (EdgeOne as the example)
- Origin timeout longer than the heartbeat interval: in the Rule Engine, set the origin (first-byte) timeout for
/api/notify/*to 60 seconds — far above the 10-second heartbeat - No-cache:
/api/notify/*must be excluded from caching; if you already configured the API-wide no-cache rule from CDN Deployment Notes, this is covered. Note that no-cache solves the caching problem and the origin timeout is a separate setting — you need both - Match the right environment: EdgeOne rules apply separately to the "Mainland China" and "Global" environments; if the site resolves to mainland nodes, the rule must be configured in "Mainland China" or it will not take effect
- HTTP/2 as a diagnostic switch: temporarily disable HTTP/2 to fall back to HTTP/1.1 — if the drops stop, the CDN's handling of HTTP/2 long-lived connections is the problem
Self-check
Watch the disconnect moment in the browser devtools Network panel — dropping at a consistent fixed number of seconds indicates a timeout somewhere in the chain cutting the stream; then compare with a deployment reached directly (bypassing the CDN): if the direct one stays stable while the CDN-fronted one reproduces, the CDN layer is the cause.