---
title: "NEXT.JS 16.1 MIGRATION: REFACTORING MIDDLEWARE.TS TO PROXY.TS (WITHOUT BREAKING AUTH"
url: https://daily.dev/posts/next-js-16-1-migration-refactoring-middleware-ts-to-proxy-ts-without-breaking-auth-fhoz078h2
source_url: https://daily.dev/posts/next-js-16-1-migration-refactoring-middleware-ts-to-proxy-ts-without-breaking-auth-fhoz078h2
type: freeform
source: "The React Community"
author: "Beyondit.Blog"
published: 2026-02-18T05:17:43.433Z
updated: 2026-02-18T05:18:06.336Z
tags: ["webdev", "react", "nodejs", "authentication", "nextjs"]
reading_time: 3
upvotes: 0
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# NEXT.JS 16.1 MIGRATION: REFACTORING MIDDLEWARE.TS TO PROXY.TS (WITHOUT BREAKING AUTH

**[The React Community](https://daily.dev/sources/the_react_community)** · [@beyondit](https://daily.dev/beyondit) · 3 min read · 0 upvotes · 0 comments

## Summary

Next.js 16.1 introduces a breaking change by renaming middleware.ts to proxy.ts and shifting from Edge Runtime to Node.js runtime. The migration requires updating file exports, converting synchronous cookie/header access to async (due to React 19 alignment), and refactoring authentication logic to avoid common pitfalls like logout loops. Vercel provides a codemod for basic migration, but authentication implementations with Supabase, Auth.js, or Clerk need careful restructuring to separate optimistic checks in proxy.ts from actual validation in server components.

## Content

You ran `npm install next@latest`, typed the upgrade command, and watched your terminal explode. Or maybe you just saw the deprecation warning in **Next.js 16.1** and felt that familiar pit in your stomach.

It’s not just you. Next.js 16.1 isn't just an upgrade; it’s a paradigm shift.

Vercel has officially renamed `middleware.ts` to `proxy.ts`. This isn't cosmetic—it's a hard pivot from the Edge Runtime back to Node.js, and it changes where your authentication logic belongs.

**🚀 TL;DR / Full Guide:** This article covers the basic syntax migration. For the **advanced survival guide**covering **Supabase Cookie Syncing**, **Auth.js v5 wrappers**, and **Clerk migration patterns**, read the full article on my blog:

👉 [**The Complete Next.js 16.1 Migration Guide (Beyond IT)**](https://beyondit.blog/blogs/nextjs-16-1-migration-middleware-to-proxy)

## ⚡ The Quick Fix (The Codemod)

If you just want to get your build passing, Vercel provides a codemod to handle the file renaming and export updates.

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

This will rename your file and change the export from `middleware` to `proxy`:

```
// proxy.ts (formerly middleware.ts)
import { NextRequest, NextResponse } from 'next/server';

// The export must be named 'proxy'
export function proxy(request: NextRequest) {
  return NextResponse.next();
}

export const config = {
  matcher: ['/dashboard/:path*'],
};
```

## 🚨 The "Async Trap" (Why your build might still fail)

Next.js 16.1 aligns with React 19, which means **you can no longer access cookies or headers synchronously.**

If your old middleware looked like this, it will crash at runtime:

```
// ❌ BROKEN in 16.1
const cookieStore = cookies();
const token = cookieStore.get('token');
```

You must update every instance to use `await`:

```
// ✅ FIXED
const cookieStore = await cookies();
const token = cookieStore.get('token');
```

## 🛑 The "Where Does Auth Go?" Crisis

This is where things get tricky. `proxy.ts` now defaults to the **Node.js runtime**. It is designed to be a "Thin Proxy" for redirects and rewrites, NOT for heavy database calls or complex JWT validation.

![unnamed-2.png](https://media.daily.dev/image/upload/s--YOhWAN5Z--/f_auto/v1771391847/ugc/content_42efa511-e18f-4bba-a0ef-6ed0f2d75a6d?_a=BAMAMiiu0)

If you are using **Supabase**, **Auth.js**, or **Clerk**, your authentication flow likely needs a refactor to avoid the **"Logout Loop" bug** (where users try to sign out but the cookie never clears because the proxy didn't pass the response header).

**⚠️ Fixing the Logout Loop:** The solution requires creating a mutable response object and manually syncing cookies between the request and response. I've documented the exact code patterns for **Supabase**and **Auth.js** in the full guide.

👉 [**Get the Library-Specific Code Snippets Here**](https://beyondit.blog/blogs/nextjs-16-1-migration-middleware-to-proxy)

### The New Architecture

To avoid bottlenecks, you need to split your logic:

1. **In **`proxy.ts`**:** Perform "optimistic" checks. Does the session cookie exist? If no, redirect to login.
2. **In Server Components:** Perform the actual validation (database lookups).

## Summary

The shift to `proxy.ts` forces a cleaner architecture, but the migration path is full of undocumented traps regarding authentication libraries.

If you are stuck debugging a specific auth provider, check out the full deep dive on **Beyond IT**, where I cover the exact implementations for:

- ✅ **Supabase** (Fixing the infinite loop)
- ✅ **Auth.js (v5)** (The correct wrapper config)
- ✅ **Clerk** (The new middleware naming convention)

👉 [**Read the Full Next.js 16.1 Guide on Beyond IT**](https://beyondit.blog/blogs/nextjs-16-1-migration-middleware-to-proxy)

## Similar posts on daily.dev

- [Next.js 16: What’s New for Authentication and Authorization](https://daily.dev/posts/next-js-16-what-s-new-for-authentication-and-authorization-jgzlqdt3d) · Auth0 · 47 upvotes · 0 comments

---

Tags: [#webdev](https://daily.dev/tags/webdev), [#react](https://daily.dev/tags/react), [#nodejs](https://daily.dev/tags/nodejs), [#authentication](https://daily.dev/tags/authentication), [#nextjs](https://daily.dev/tags/nextjs)

[View this post on daily.dev](https://daily.dev/posts/next-js-16-1-migration-refactoring-middleware-ts-to-proxy-ts-without-breaking-auth-fhoz078h2)