URL Configurations

1. authInterrupts

Status: authInterrupts is an experimental feature available in the canary release of Next.js. Enable it to test out upcoming authentication control APIs and provide feedback.

This configuration enables experimental APIs such as forbidden() and unauthorized(), which allow you to interrupt requests and send early authentication responses from server actions or middlewares.

Enable it in next.config.ts:

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  experimental: {
    authInterrupts: true,
  },
}

export default nextConfig

Real-world Example: Let’s say you want to block users without valid sessions from calling a server action. With authInterrupts enabled, you could call:

import { forbidden } from 'next/server'

export async function action() {
  const user = await getSession()
  if (!user) return forbidden()
}

This gives developers fine-grained access control inside server functions without needing a full redirect.

2. logging

The logging option lets you control what is logged to the console during development for fetch requests and incoming HTTP requests.

Fetch Request Logging

By default, fetch logs are limited. You can increase verbosity by enabling full URLs:

module.exports = {
  logging: {
    fetches: {
      fullUrl: true,
    },
  },
}

To log fetches triggered by HMR cache restores, set:

module.exports = {
  logging: {
    fetches: {
      hmrRefreshes: true,
    },
  },
}

Incoming Request Logging

Incoming requests are logged by default. To ignore noisy endpoints like health checks:

module.exports = {
  logging: {
    incomingRequests: {
      ignore: [/\api\/v1\/health/],
    },
  },
}

Or disable all incoming request logs:

module.exports = {
  logging: {
    incomingRequests: false,
  },
}

Disable All Logs

To disable all dev logs entirely:

module.exports = {
  logging: false,
}

Real-world Example: When integrating with external APIs during development, you may want to verify that the correct URLs are fetched. Turning on fullUrl helps inspect and debug fetch behavior quickly.

3. poweredByHeader

By default, Next.js sets the HTTP response header x-powered-by: Next.js.

To remove it (for example, for security or branding reasons):

module.exports = {
  poweredByHeader: false,
}

Real-world Example: Removing this header is a common practice in production environments to obscure the underlying framework and reduce the app’s exposure to targeted exploits.

4. trailingSlash

By default, Next.js strips trailing slashes from URLs (e.g., /about/ → /about). To reverse this behavior and force trailing slashes:

module.exports = {
  trailingSlash: true,
}

This redirects paths like /about to /about/.

Exceptions:

Static file paths like /logo.png will remain unchanged.
Any files under .well-known/ won’t be affected.

Real-world Example: If your static hosting platform expects URLs to map to folder-style paths like /blog/index.html, then enabling trailingSlash ensures that the URL /blog/ matches the directory structure.

5. typedRoutes

Status: typedRoutes is an experimental feature that adds compile-time type safety to route links in App Router mode using TypeScript.

Enable it via:

/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    typedRoutes: true,
  },
}

module.exports = nextConfig

Real-world Example: Suppose your app has a page at /users/[id]. With typedRoutes, the TypeScript compiler ensures that you pass a valid id when using Link or router.push():

import Link from 'next/link'

export default function UserLink() {
  return <Link href={{ pathname: '/users/[id]', query: { id: '123' } }}>User 123</Link>
}

This prevents runtime navigation bugs caused by missing or malformed route parameters, improving code reliability in larger apps.

MENU