pnpm install
node echo-server.js & # plain TCP echo server on :3901
ENABLE_TEST_PROXY=true pnpm build
ENABLE_TEST_PROXY=true ECHO_PORT=3901 pnpm start # next start -p 3900
curl http://localhost:3900/api/probe # hangs forever on 16.3.0Set ENABLE_TEST_PROXY=false (or install next@16.2.12) and the same request
resolves in a few ms.
next.config.js—experimental.testProxygated byENABLE_TEST_PROXY.app/api/probe/route.js— opens a rawnet.Socket(nofetch, no HTTP) to the echo server, writes a byte, awaits the echo, returns it.echo-server.js— trivial TCP echo server standing in for any non-fetch TCP consumer (Postgres client, Redis client, etc).
testProxy: true+next@16.2.12: request resolves in ~6ms.testProxy: true+next@16.3.0: request never resolves (verified no timeout, no error — just hangs indefinitely).testProxy: false+next@16.3.0: request resolves in ~3ms.
Same Node version, same code, only the next version / flag differs.
testProxy is the flag next/experimental/testmode/playwright/msw turns on
to intercept fetch() for MSW-based mocking in Playwright e2e tests. In a
real app we use it that way, and one of our API routes also does a normal
pg (node-postgres) query in the same request. On 16.3.0, any request that
reaches a pg connection while testProxy is enabled hangs forever — no TCP
connection to Postgres is ever attempted (confirmed via pg_stat_activity
and lsof on the server process). Every Playwright test whose fixture calls
that route times out after Playwright's default 30s hook timeout, and with
retries + a single worker this silently burns ~90 minutes in CI before the
job reports failure.
This repro shows the same hang for TCP sockets in general (not pg-specific),
so it looks like testProxy in 16.3.0 started intercepting/blocking non-fetch
socket traffic it doesn't know how to proxy, and never falls through.