Nitro Route Caching: Coordinating Server SWR and Client-side useFetch Deduplication

Direct Answer

There is no documented built-in mechanism that synchronizes a client-side useFetch refresh with a forced Nitro server-cache invalidation. The Nitro route cache (governed by maxAge/staleMaxAge in route rules) and the Nuxt payload/useFetch deduplication cache operate independently. Cache tags introduced in Nuxt 3.10 can purge server entries when backed by tag-capable storage (e.g., Redis), but they do not propagate to or clear the client-side payload state.

Why the Caches Stay Separate

• Nitro server cache: Keyed by the request path and route-rule configuration. SWR serves a stale response while a background revalidation runs, controlled entirely on the server.
• Client payload cache: Keyed by the useFetch/useAsyncData key and options. Deduplication returns the existing payload for identical keys without a network request; refresh() forces a new request but that request still hits the Nitro route cache.
• Tag purge: Only invalidates server-side entries in supported storage drivers. It does not call clearNuxtData() or touch the client payload.

Practical Pattern to Bypass Both Caches

1. Make the target endpoint uncached or version its URL

   // nuxt.config.ts
   export default defineNuxtConfig({
     routeRules: {
       '/api/uncached/**': { cache: false }, // disables Nitro caching for this path
       // or version the path: '/api/v2/resource'
     }
   })

2. Clear the matching client payload before refreshing

   // In a component or composable
   const { data, refresh, clear } = useFetch('/api/uncached/resource')
   
   async function forceFresh() {
     clear() // removes the local payload entry for this key
     await refresh() // now issues a request that bypasses Nitro cache (step 1)
   }

3. If you must keep the cached route rule, cache-bust the URL per request:

   const { data, refresh } = useFetch('/api/cached/resource', {
     query: { _ts: Date.now() } // unique query defeats both client key reuse and Nitro cache lookup
   })

4. After any server-side tag purge, repeat the client clear() because tags do not invalidate the payload cache.

Verification Checklist

• Inspect nuxt.config routeRules for the target path to confirm cache: false or SWR settings (maxAge/staleMaxAge).
• In DevTools Network tab, trigger the refresh and verify a new request is sent (not served from client payload) and that the response Date/ETag/body updates (not a stale Nitro hit).
• Confirm the storage driver supports tags if you rely on cacheTag purge; default file/memory storage does not.
• Test against the exact deployed Nuxt/Nitro version; clearNuxtData scoping and cacheTags behavior are not stable across versions.

One Missing Diagnostic That Changes the Recommendation

Is the target endpoint covered by a Nitro route rule and backed by tag-capable storage (Redis, etc.)? If no, tag-based purge is unavailable and cache-bypass (steps 1–3 above) is the only practical path. If yes, you can combine a server tag purge with the client clear() + refresh() pattern, but you must still perform both steps explicitly.