App Router: SPA navigation via <Link> hangs 15-20s on 2nd visit behind Traefik reverse proxy

[ShivSync]

Environment

• Next.js versions tested: 16.2.2, 16.2.6, 16.3.0-canary.21 — bug reproduces on all three
• Node.js: 22.x
• Deployment: Docker (standalone output) behind Traefik v2 reverse proxy (Coolify PaaS on Contabo VPS)
• Browser: Chrome 137, Firefox 138, Safari 18 — reproduces on all

Description

In a multi-tenant SaaS app (App Router, ~30 routes, 4 nested client providers), client-side navigation via <Link> works perfectly on the first visit to any route. On the second visit to a previously-visited route, the router transition hangs for 15-20 seconds — the URL does not update, usePathname() stays stale, and the page appears frozen. After the timeout the navigation eventually completes.

Switching <Link> to <a> (hard navigation) eliminates the issue entirely.

Key observations

1. Only reproduces behind Traefik. Direct localhost:3000 access in the same Docker container does not exhibit the bug.
2. Only on 2nd visit. First navigation to any route via <Link> is instant. Returning to a cached route triggers the hang.
3. Consistent across 3 Next.js versions (16.2.2, 16.2.6, 16.3.0-canary.21).
4. No errors in browser console or server logs during the hang — no failed fetches, no RSC payload errors, no chunk load failures.
5. SSE connection present — app uses a Supabase Realtime-style SSE channel (RealtimeProvider). Unclear if this contributes.

What we tried

• Upgraded Next.js across 3 versions — no change
• Stripped sidebar to minimal <Link> elements — still hangs
• Disabled all non-essential providers one at a time — still hangs
• Checked Traefik access logs — requests complete normally (200, <100ms)
• Verified no Cache-Control or Vary header differences between direct and proxied responses

Partial repro (does NOT reproduce)

We built a minimal repro with the same stack delta:

• 4 routes with <Link> sidebar navigation
• 4 nested client providers (TenantProvider, RealtimeProvider with SSE, ThemeProvider, ToastProvider)
• 10 parallel Supabase queries per page on mount
• Same Dockerfile, same Traefik config, same Coolify deployment

Repo: https://github.com/ShivSync/nextjs-router-stall-repro
Live demo: https://nextjs-bug.meridiansuite.ai

The repro navigates instantly on every visit. The production app (same infra, same proxy) hangs on 2nd visit.

Delta between repro and production

The production app has:

• ~30 routes (vs 4 in repro)
• Complex RSC data fetching with Promise.all of 10+ queries in server components
• Dynamic [id] routes with generateMetadata
• Middleware for auth redirects
• Larger client-side state (Zustand stores, form state)
• More CSS/Tailwind classes (larger stylesheet)

Current workaround

Replaced <Link> with <a> in the sidebar layout for all primary navigation. This forces full page loads but eliminates the hang. Production is stable with this workaround.

Request

We suspect the interaction is between the App Router prefetch/cache layer and Traefik's HTTP/2 connection handling, possibly related to RSC payload caching or flight data revalidation on 2nd visit. We'd appreciate any pointers on:

1. Is there a known interaction between App Router's client cache and reverse proxies that modify Connection or Transfer-Encoding headers?
2. Are there debug flags we can enable to trace the router's internal state during a transition (beyond NEXT_DEBUG_LOGGING)?
3. Could the number of routes (~30) or RSC payload size affect the prefetch cache behavior differently behind a proxy?

Happy to provide Traefik configs, HAR captures, or any additional debugging output that would help isolate this.

[mg1986jp]

This screams HTTP/2 connection reuse issue with Traefik, not an App Router bug.

The fact that it only happens on 2nd visit and only behind Traefik is the giveaway. Here's what's likely happening:

On the first <Link> navigation, the browser opens a fresh HTTP/2 connection through Traefik and gets the RSC payload fine. On the second visit to a cached route, the App Router sends a revalidation request (with RSC: 1 and Next-Router-State-Tree headers) over the existing HTTP/2 connection. If Traefik is holding that connection in a weird state — especially with SSE running on the same connection — the request can stall at the proxy level without ever failing.

Things to try:

1. Check Traefik's HTTP/2 settings

# traefik.yml or dynamic config
serversTransport:
  maxIdleConnsPerHost: 0  # try disabling connection pooling to backend

Or force HTTP/1.1 between Traefik and your Next.js container:

serversTransport:
  disableHTTP2: true

This isolates whether HTTP/2 multiplexing between Traefik and Next.js is the problem.

2. Separate the SSE connection

Your RealtimeProvider SSE channel shares the same origin, so the browser multiplexes it on the same HTTP/2 connection as RSC requests. A long-lived SSE stream can interfere with flow control on that connection. Try putting the SSE endpoint on a different subdomain or port to force a separate connection.

3. Add response buffering in Traefik

Traefik may be streaming the RSC response and waiting for a signal that never comes:

middlewares:
  buffering:
    buffering:
      maxResponseBodyBytes: 10485760

4. Debug the actual stall

Open Chrome DevTools → Network → filter by Fetch/XHR during the hang. You should see a pending request to the RSC endpoint. Check:

• Does the request reach Traefik? (Traefik access log)
• Does the request reach Next.js? (add a middleware log)
• Where exactly does the 15-20s timeout happen?

My bet is on the Traefik → Next.js leg. The request reaches Traefik but gets stuck on the HTTP/2 connection to the backend.

[DaCameraGirl]

This is a Traefik HTTP/2 connection multiplexing issue — not a Next.js bug. Here's the root cause and a prioritized fix list.

Root Cause

Next.js App Router's <Link> component triggers RSC (React Server Component) prefetch and revalidation requests on the second visit to a cached route. These requests go through Traefik, which in v2 uses HTTP/2 multiplexing between itself and your Node container by default.

The 15-20 second hang matches Node.js's default HTTP/2 stream timeout. What's happening:

1. First visit — RSC request opens an HTTP/2 stream, completes normally
2. Second visit — Traefik attempts to reuse the same HTTP/2 connection, but the stream is stale or the connection has been recycled by Node.js on the backend
3. Traefik waits for the stream to be acknowledged, eventually times out, then falls back — this is your 15-20s window
4. <a> hard nav bypasses this entirely because it forces a full new HTTP request cycle

Fix Priority Order

Fix 1 (fastest, test first): Disable HTTP/2 on Traefik → Next.js leg

# traefik.yml or docker-compose labels
serversTransport:
  disableHTTP2: true  # Force HTTP/1.1 between Traefik and backend
  maxIdleConnsPerHost: 100
  forwardingTimeouts:
    responseHeaderTimeout: 60s

This is the most impactful change. HTTP/1.1 between Traefik and Node.js doesn't have the multiplexing race condition.

Fix 2: Set flushInterval to prevent buffering

# Traefik middleware / service config
http:
  services:
    nextjs:
      loadBalancer:
        servers:
          - url: "http://nextjs:3000"
        responseForwarding:
          flushInterval: 1ms  # Don't buffer streaming RSC responses

Fix 3: Prevent SSE connections from starving RSC streams

If you're using SSE (or WebSockets) for real-time features, they keep HTTP/2 connections alive indefinitely. Move them to a separate service/subdomain so they don't share the same connection pool as RSC prefetch requests:

# Route SSE to a dedicated endpoint
http:
  routers:
    sse:
      rule: "Host(`app.example.com`) && PathPrefix(`/api/sse`)"
      service: nextjs-sse
    main:
      rule: "Host(`app.example.com`)"
      service: nextjs

Fix 4: Adjust Next.js staleTimes to reduce revalidation requests

// next.config.ts
export default {
  experimental: {
    staleTimes: {
      dynamic: 0, // Don't attempt RSC revalidation on 2nd visit for dynamic routes
      static: 300,
    },
  },
};

This reduces the frequency of RSC refetch requests but doesn't fix the underlying connection issue.

Fix 5: Exclude Next.js internal paths from middleware

If you have auth middleware, ensure it doesn't intercept _next/ paths — auth checks on prefetch requests can cause serialization issues:

// middleware.ts
export const config = {
  matcher: [
    '/((?!_next/static|_next/image|favicon.ico|api/public).*)',
  ],
};

Verification

To confirm it's the Traefik→Next.js leg and not something else, add this to your container:

NEXT_PRIVATE_DEBUG_CACHE=1

Then watch logs during the hang — if you see RSC cache miss logs only after the 15-20s timeout, it confirms Traefik is holding the request before Next.js ever sees it. If you see the request arrive immediately, the issue is inside Next.js.

Start with Fix 1 — it resolves this for most setups.