Next.js App Router流式SSR经IIS反向代理后直接访问UI异常求助

问题现象 #

• 使用Next.js App Router（app/目录）结合流式SSR，通过IIS反向代理部署到Node.js实例（如端口3000）后，直接输入URL访问或F5刷新页面时，服务器返回的Content-Type为text/x-component而非预期的text/html，导致页面UI渲染异常
• 通过Next.js内部导航（如next/link跳转）时，页面渲染完全正常

原因分析 #

IIS反向代理默认的响应处理逻辑会干扰Next.js流式SSR的分块响应：

• Next.js流式SSR在全页请求时，会先发送text/x-component类型的初始片段，但后续会切换为text/html
• IIS的响应缓冲、动态压缩或头信息重写规则，可能会锁定初始的text/x-component作为最终响应头，导致浏览器无法识别为HTML页面

解决方案 #

1. 强制IIS返回正确的Content-Type #

在IIS的URL重写规则中添加服务器变量，强制覆盖响应头：

• 打开IIS管理器 → 目标站点 → URL重写 → 编辑反向代理规则
• 切换到「服务器变量」标签，添加RESPONSE_CONTENT_TYPE，设置值为text/html; charset=utf-8
• 也可以直接在站点的web.config中配置：

<rewrite>
  <rules>
    <rule name="Next.js Reverse Proxy" stopProcessing="true">
      <match url="(.*)" />
      <action type="Rewrite" url="http://localhost:3000/{R:1}" />
      <serverVariables>
        <set name="RESPONSE_CONTENT_TYPE" value="text/html; charset=utf-8" />
      </serverVariables>
    </rule>
  </rules>
</rewrite>

2. 禁用IIS动态压缩（临时排查+修复） #

IIS的动态压缩会破坏流式响应的分块结构，先尝试禁用：

• 进入站点的「压缩」功能，取消勾选「启用动态内容压缩」
• 若问题解决，可进一步配置压缩规则，仅对非流式响应启用压缩

3. 强制Next.js页面动态渲染 #

在页面组件中添加动态渲染标识，避免静态生成的头信息异常：

// app/page.tsx 或对应路由组件
export const dynamic = 'force-dynamic';

export default function Home() {
  return <div>页面内容</div>;
}

4. 关闭IIS ARR的响应缓冲 #

• 打开IIS管理器 → 服务器节点 → 应用程序请求路由 → 服务器代理设置
• 取消勾选「响应缓冲」，确保流式响应能实时转发给浏览器

内容的提问来源于stack exchange，提问作者esadbacaci