Erreur proxy.ts Next.js 16 : missing expected function export

Next.js 16 arrête le build avec l'erreur « Proxy is missing expected function export name » quand proxy.ts n'exporte ni une fonction nommée proxy, ni une fonction par défaut. La cause habituelle : un fichier renommé depuis middleware.ts qui contient encore export function middleware. Renommez cette fonction en proxy, ou exportez-la par défaut, et le build passe.

Nous avons reproduit chaque cas de cette page le 5 novembre 2026 dans une application vierge avec Next.js 16.4.5, next-intl 4.14.9 et Turbopack (le bundler par défaut de Next.js 16), et copié les messages directement depuis le terminal. Chaque correctif a été relancé en build pour vérifier qu'il fonctionne.

Vérifié en novembre 2026.

Que dit exactement l'erreur ?

Voici le message complet de next build sur Next.js 16.4.5. La phrase recherchée « expected function export name default or proxy function export » vient de sa première ligne et de sa dernière indication.

▲ Next.js 16.4.5 (Turbopack)
  Creating an optimized production build ...

> Build error occurred
Error: Turbopack build failed with 1 error:
./proxy.ts
Error: Proxy is missing expected function export name
This function is what Next.js runs for every request handled by this proxy (previously called middleware).

Why this happens:
- You are migrating from `middleware` to `proxy`, but haven't updated the exported function.
- The file exists but doesn't export a function.
- The export is not a function (e.g., an object or constant).
- There's a syntax error preventing the export from being recognized.

To fix it:
- Ensure this file has either a default or "proxy" function export.

Learn more: https://nextjs.org/docs/messages/middleware-to-proxy

La même erreur a deux autres formulations, selon la façon dont vous lancez l'application :

# next build --webpack, and next dev
Error: The file "./proxy.ts" must export a function, either as a default export or as a named "proxy" export.

# next start or next dev, when a request reaches a proxy that exports no function
⨯ [Error: The Proxy file "/proxy" must export a function named `proxy` or a default function.]

Les trois veulent dire la même chose : Next.js a ouvert proxy.ts et n'y a trouvé aucune fonction à appeler pour chaque requête.

D'où vient « Proxy is missing expected function export name » ?

Au build, Next.js lit les exports de proxy.ts et cherche une fonction nommée proxy ou un export par défaut. Tout le reste échoue. Voici le cas le plus courant, un fichier renommé à la main :

// proxy.ts (renamed from middleware.ts, function not renamed)
import { NextResponse, type NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  return NextResponse.next();
}

Nous avons lancé un build pour chacune de ces formes sur Next.js 16.4.5. La colonne de droite indique ce qui s'est passé.

Contenu de proxy.ts	Résultat sur 16.4.5
export function middleware()	Build en échec : missing expected function export name
export const middleware = ...	Build en échec : même erreur
Une fonction avec un autre nom, comme export function handler()	Build en échec : même erreur
Seulement export const config = {...}	Build en échec : même erreur
Un fichier vide	Build en échec : même erreur
export const middleware = createMiddleware(routing) (next-intl)	Build en échec : même erreur
export { default as middleware } from 'next-intl/middleware'	Build en échec : même erreur
export * from './other-file'	Build en échec : même erreur, même si l'autre fichier exporte proxy
export { middleware as default } from './old-middleware'	Compile, puis échoue à l'étape « Collecting page data » avec « must export a function »
export default { ... } (un objet, pas une fonction)	Le build passe, puis chaque requête renvoie 500
export const config = { runtime: 'edge' }	Build en échec avec une autre erreur : Proxy does not support Edge runtime
middleware.ts et proxy.ts côte à côte	Build en échec : les deux fichiers sont détectés
proxy.ts à la racine alors que l'app est dans src/app	Le build passe, mais le proxy ne tourne jamais

Les trois dernières lignes ne sont pas l'erreur d'export, mais elles apparaissent pendant la même migration, donc nous les traitons plus bas.

Correctif 1 : exporter une fonction nommée proxy

Renommez la fonction en proxy. C'est la forme utilisée par la documentation de Next.js, et elle passe le build :

// proxy.ts
import { NextResponse, type NextRequest } from 'next/server';

export function proxy(request: NextRequest) {
  return NextResponse.next();
}

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

La fonction peut être async, et une fonction fléchée assignée à export const proxy fonctionne aussi. Nous avons testé les deux :

// Pick one. Each of these also builds on Next.js 16.4.5.
export async function proxy(request: NextRequest) {
  return NextResponse.next();
}

// or
export const proxy = (request: NextRequest) => NextResponse.next();

Une seule fonction par fichier. La documentation de Next.js précise que le fichier doit exporter une seule fonction et que plusieurs proxys dans un même fichier ne sont pas pris en charge.

Correctif 2 : utiliser un export par défaut

Un export par défaut fonctionne quel que soit le nom de la fonction, et une fonction fléchée anonyme exportée par défaut passe aussi le build. Le guide de migration de Next.js recommande quand même de la nommer proxy, pour que le nom et le fichier concordent :

// proxy.ts
import { NextResponse, type NextRequest } from 'next/server';

export default function proxy(request: NextRequest) {
  return NextResponse.next();
}

Un piège : l'export par défaut doit être une fonction. export default { matcher: ['/'] } a passé next build dans notre test, puis chaque page a renvoyé une erreur 500 avec « The Proxy file "/proxy" must export a function named `proxy` or a default function. » Certains ré-exports échouent aussi. Importez d'abord la fonction, puis exportez-la :

// Fails at "Collecting page data" on Next.js 16.4.5
export { middleware as default } from './old-middleware';

// Builds: import first, then export
import { middleware } from './old-middleware';
export default middleware;

Comment écrire proxy.ts avec next-intl ?

createMiddleware() de next-intl renvoie une fonction : exportez-la par défaut. C'est la configuration de la documentation de next-intl, qui rappelle aussi que proxy.ts s'appelait middleware.ts jusqu'à Next.js 16 :

// src/i18n/routing.ts
import { defineRouting } from 'next-intl/routing';

export const routing = defineRouting({
  locales: ['en', 'ar'],
  defaultLocale: 'en',
});

// src/proxy.ts
import createMiddleware from 'next-intl/middleware';
import { routing } from './i18n/routing';

export default createMiddleware(routing);

export const config = {
  // Skip /api, /trpc, /_next, /_vercel and any path with a dot (files)
  matcher: '/((?!api|trpc|_next|_vercel|.*\\..*).*)',
};

export const proxy = createMiddleware(routing); passe aussi le build, et c'est ce qu'écrit le codemod de Next.js quand il migre un fichier next-intl. Ces formes échouent, parce que la fonction ne s'appelle pas proxy ou n'est pas visible pour Next.js au moment du build :

// src/proxy.ts: these three fail with "missing expected function export name"
export const middleware = createMiddleware(routing);
export { default as middleware } from 'next-intl/middleware';
export * from './intl-proxy';

Pour lancer votre propre vérification avant la redirection de langue (connexion, en-tête, redirection), écrivez une fonction proxy et appelez le handler de next-intl depuis l'intérieur :

// src/proxy.ts: your own check first, then next-intl
import createMiddleware from 'next-intl/middleware';
import { NextResponse, type NextRequest } from 'next/server';
import { routing } from './i18n/routing';

const handleI18nRouting = createMiddleware(routing);

export function proxy(request: NextRequest) {
  const isAccount = request.nextUrl.pathname.includes('/account');
  const hasSession = request.cookies.has('session');

  if (isAccount && !hasSession) {
    return NextResponse.redirect(new URL('/en/login', request.url));
  }

  return handleI18nRouting(request);
}

export const config = {
  matcher: '/((?!api|trpc|_next|_vercel|.*\\..*).*)',
};

Nous avons compilé ce fichier, lancé next start -p 3040 et envoyé trois requêtes. Le proxy a choisi la langue et a fait la vérification du compte :

$ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://localhost:3040/
307 http://localhost:3040/en
$ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' -H 'Accept-Language: ar' http://localhost:3040/
307 http://localhost:3040/ar
$ curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://localhost:3040/en/account
307 http://localhost:3040/en/login

C'est cette redirection qui envoie un même visiteur vers une page en anglais ou en arabe. Voici la page d'accueil du template restaurant d'Aniq UI sur /en et sur /ar :

Une fois les pages arabes chargées, la mise en page doit aussi s'inverser. Cette partie relève du CSS, pas du proxy : le guide RTL de Tailwind CSS couvre dir, les utilitaires logiques et la variante rtl:.

Où placer proxy.ts : à la racine ou dans src/ ?

À côté de votre dossier app. La documentation de Next.js indique de le créer à la racine du projet, ou dans src si vous en utilisez un, au même niveau que app ou pages.

# Without a src folder        # With a src folder
my-app/                       my-app/
├── app/                      ├── src/
├── proxy.ts                  │   ├── app/
└── package.json              │   └── proxy.ts
                              └── package.json

Un fichier au mauvais endroit ne donne aucune erreur. Dans notre test, un proxy.ts à la racine d'un projet dont l'app était dans src/app a passé le build et n'a jamais tourné. Un proxy.ts placé dans le dossier app a été ignoré de la même façon. La vérification rapide se trouve à la fin de la sortie de next build. Quand Next.js a trouvé votre proxy, la liste des routes se termine par cette ligne :

Route (app)
┌ ○ /
└ ○ /_not-found
ƒ Proxy (Middleware)

Si la ligne ƒ Proxy (Middleware) manque, Next.js n'a pas trouvé le fichier. Si vous avez modifié pageExtensions dans next.config, le nom du fichier suit, par exemple proxy.page.ts.

Le matcher de config provoque-t-il cette erreur ?

Non. config est facultatif, et un fichier qui ne contient que config échoue parce qu'il n'a pas de fonction, pas à cause du matcher. Le matcher choisit les chemins sur lesquels le proxy tourne. Sans matcher, le proxy tourne sur chaque requête, y compris _next/static, les images et les fichiers de public/. Un motif négatif les exclut :

export const config = {
  matcher: [
    // Everything except API routes, static files, image optimization and metadata files
    '/((?!api|_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)',
  ],
};

Les valeurs du matcher doivent être des constantes, car Next.js les lit au moment du build. La documentation précise qu'une valeur construite à partir d'une variable est ignorée. Chaque source doit commencer par /.

Comment migrer de middleware.ts vers proxy.ts ?

Lancez le codemod officiel depuis la racine du projet. Il renomme le fichier et la fonction exportée :

npx @next/codemod@canary middleware-to-proxy .

Nous l'avons lancé (version 16.5.0-canary.41) sur un middleware.ts à la racine et sur un src/middleware.ts qui utilise next-intl. Les deux fichiers et les deux fonctions ont été renommés, et les deux apps ont passé le build :

// middleware.ts -> proxy.ts
- export function middleware(request: NextRequest) {
+ export function proxy(request: NextRequest) {

// src/middleware.ts -> src/proxy.ts
- export const middleware = createMiddleware(routing);
+ export const proxy = createMiddleware(routing);

Il n'agit que sur une fonction nommée middleware. Quand nous avons essayé un middleware.ts dont la fonction s'appelait handler, le codemod a laissé le fichier tel quel : dans ce cas, renommez le fichier et la fonction à la main. La commande plus large npx @next/codemod@canary upgrade latest inclut aussi l'étape middleware vers proxy.

Deux autres points pendant la migration :

• middleware.ts fonctionne encore en 16.4.5, avec un avertissement. Le build affiche l'avertissement ci-dessous et exécute le fichier. Prévoyez quand même le renommage, car la convention est dépréciée.
• Ne gardez pas les deux fichiers. Avec middleware.ts et proxy.ts côte à côte, le build s'arrête.

⚠ The "middleware" file convention is deprecated. Please use "proxy" instead.
  To migrate automatically, run:
  npx @next/codemod@canary middleware-to-proxy .
  Learn more: https://nextjs.org/docs/messages/middleware-to-proxy

Error: Both middleware file "./middleware.ts" and proxy file "./proxy.ts" are detected. Please use "./proxy.ts" only. Learn more: https://nextjs.org/docs/messages/middleware-to-proxy

Les options de configuration qui contenaient « middleware » ont aussi été renommées. Par exemple, skipMiddlewareUrlNormalize devient skipProxyUrlNormalize :

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  skipProxyUrlNormalize: true, // was skipMiddlewareUrlNormalize
};

export default nextConfig;

proxy.ts peut-il utiliser le runtime Edge ?

Non. Le guide de migration vers Next.js 16 indique que le runtime du proxy est nodejs, qu'il n'est pas configurable, et que les applications qui ont besoin du runtime Edge doivent garder middleware pour l'instant. Ajouter export const config = { runtime: 'edge' } dans proxy.ts a arrêté notre build avec ce message :

./proxy.ts:7:14
Error: Next.js can't recognize the exported `config` field in route. Proxy does not support Edge runtime.
> 7 | export const config = { runtime: 'edge' };

Supprimez la ligne runtime. Si vous dépendez vraiment d'Edge, gardez middleware.ts jusqu'à ce que Next.js publie ses instructions complémentaires.

La vérification en une minute

1. Le fichier s'appelle proxy.ts (ou .js) et se trouve à côté de app : à la racine, ou dans src/.
2. Il exporte function proxy ou une fonction par défaut. Plus aucun nom middleware.
3. Avec next-intl, la ligne est export default createMiddleware(routing);.
4. Il n'y a pas de middleware.ts à côté.
5. config contient un matcher constant et aucun runtime.
6. next build se termine par ƒ Proxy (Middleware), et une requête sous next start ne renvoie pas 500.

FAQ

Pourquoi proxy.ts affiche « missing expected function export name » après la mise à jour vers Next.js 16 ?

Parce que le fichier a été renommé, mais pas la fonction. Next.js 16 n'accepte dans proxy.ts qu'une fonction nommée proxy ou un export par défaut, donc export function middleware échoue. Renommez-la en proxy, ou lancez npx @next/codemod@canary middleware-to-proxy .

Puis-je garder middleware.ts avec Next.js 16 ?

Oui, pour l'instant. Sur Next.js 16.4.5, un middleware.ts passe encore le build et s'exécute, avec un avertissement de dépréciation. C'est aussi le choix documenté si vous avez besoin du runtime Edge. Ne le gardez jamais à côté d'un proxy.ts : le build s'arrête quand les deux existent.

next-intl fonctionne-t-il avec proxy.ts ?

Oui. La documentation de next-intl utilise src/proxy.ts avec export default createMiddleware(routing); et le matcher '/((?!api|trpc|_next|_vercel|.*\\..*).*)'. Nous l'avons compilé et lancé avec next-intl 4.14.9 sur Next.js 16.4.5.

Pourquoi le build passe mais chaque page renvoie 500 ?

Votre export par défaut n'est probablement pas une fonction, par exemple un objet. Le build l'a accepté dans notre test, puis chaque requête a échoué avec « The Proxy file "/proxy" must export a function named `proxy` or a default function. » Exportez une fonction à la place.

Où mettre proxy.ts quand on utilise un dossier src ?

Dans src/proxy.ts, à côté de src/app. Avec cette structure, un proxy.ts à la racine est ignoré sans erreur : vérifiez donc que next build affiche ƒ Proxy (Middleware).

L'erreur est-elle différente avec webpack ?

Seule la formulation change. Avec next build --webpack, le message est « The file "./proxy.ts" must export a function, either as a default export or as a named "proxy" export. » Le correctif est le même.

Conclusion

Cette erreur se résume toujours à une ligne : l'export. Nommez la fonction proxy ou exportez-la par défaut, gardez le fichier à côté de app et supprimez l'ancien middleware.ts. Avec next-intl, cette ligne est export default createMiddleware(routing);. Vérifiez ensuite que next build affiche le proxy, et envoyez une vraie requête avant de déployer.

Des templates avec proxy.ts et next-intl prêts

Si vous préférez partir d'un code où tout cela fonctionne déjà, tous les templates payants d'Aniq UI tournent sur Next.js 16 avec src/proxy.ts et next-intl, en anglais et en arabe avec une vraie mise en page de droite à gauche. Nous avons ouvert les dépôts le 5 novembre 2026 : chaque application est en Next.js 16.3 ou 16.4, et les deux correctifs de ce guide y sont utilisés. La landing page SaaS utilise export default createMiddleware(routing), et le template restaurant utilise export async function proxy.

Ce que coûte chacun, en paiement unique, avec le code source :

• Sites et boutiques (restaurant, immobilier, LMS, e-commerce, location de vacances, billetterie) : $39.
• Landing pages (SaaS et Publino) : $39.
• Dashboards d'administration : à partir de $49 (le dashboard financier coûte $49, le dashboard admin avec IA et le dashboard fitness $69).
• API backend : $99.
• Full stack (site, dashboard et API ensemble) : $149.
• Les 10 templates : le pack, prix catalogue $499. Consultez la page pour l'offre du moment.

Parcourir les templates et ouvrir n'importe quelle démo en arabe avant d'acheter.

Guides associés

• next-intl nextjs 16: cache de composants via root-params
• Guide RTL Tailwind CSS : propriétés logiques et variante rtl:
• Comment lancer un site SaaS en anglais et en arabe avec Next.js
• Templates de dashboard arabe RTL pour Next.js : 9 dashboards Aniq UI

Sources

• Next.js : convention de fichier proxy.js (exports, matcher, runtime, migration)
• Next.js : migrer vers la version 16 (middleware vers proxy, runtime Edge, options renommées)
• Next.js : Renaming Middleware to Proxy (le lien du message d'erreur)
• next-intl : Proxy / middleware
• next-intl : configuration App Router avec routage i18n

Testé avec Next.js 16.4.5, next-intl 4.14.9, React 19.3.1 et TypeScript 5.9.3 sur Node.js 24.17.0. Vérifié en novembre 2026.