asepharyana
ec3a2867d4
- bun workspaces + Turborepo monorepo (apps/web, apps/mcp; packages/*, scripts) - @mcpedia/core single business-logic layer (Document/Content/Search services) - @mcpedia/db Drizzle schema: documents + weighted tsvector (GIN) for FTS - @mcpedia/parser frontmatter, @mcpedia/search Postgres FTS (ts_rank+ts_headline) - Next.js 16 Web UI (home/doc SSG, search dynamic) + react-markdown render - MCP server (stdio) with 4 tools + in-memory smoke test - scripts/indexer walks content/ -> upserts into Postgres - 4 seed docs; README + PHASES status
1016 B
1016 B
id, title, type, tags, status, author, created_at, updated_at
| id | title | type | tags | status | author | created_at | updated_at | |||
|---|---|---|---|---|---|---|---|---|---|---|
| websocket-timeout | Debugging a WebSocket Timeout Behind a Proxy | writeup |
|
published | asep | 2026-08-19 | 2026-08-19 |
Debugging a WebSocket Timeout Behind a Proxy
A recurring incident: the browser WebSocket connects, sends one frame, then silently times out. The server logs show no error. Root cause: the reverse proxy was buffering frames and only flushing on connection close.
Symptoms
- Connection opens (101 Switching Protocols).
- First message never reaches the upstream.
- Client hits its own 30s timeout and reconnects, creating a storm.
Fix
Disable proxy buffering for the WebSocket upgrade route and ensure the proxy does not apply an idle timeout shorter than the application's heartbeat interval. After that, frames flowed immediately and the timeout disappeared.
Lesson
Always confirm at the proxy layer whether frames are buffered before assuming the application server is at fault.