next.js 16.4.6回移了route handler响应压缩修补。自托管项目升级后，可用同一个响应内容分别检查应用直连和代理后的响应，确认请求接受哪些编码、服务实际返回哪种编码，以及压缩由哪一层负责。本文针对生产启动路径，不把开发服务器结果当作生产结论。
Next.js官方说明如何检查编码及关闭内置压缩
在生产启动模式准备测试接口
在测试环境使用项目自己的Route Handler，选择可压缩、体积足够的文本或JSON响应。先完成项目构建，再启动生产服务器；按项目已有脚本运行，不要只运行next dev。
npm run build npm run start
如果接口需要登录，使用有权限的测试请求，避免把跳转到登录页或错误页的响应头误当成目标接口结果。
检查请求与响应编码
将示例路径替换为真实测试接口。这里使用GET请求丢弃响应体并保留响应头，避免HEAD与GET处理不同造成误判。
curl -sS -D - -o /dev/null \ -H "Accept-Encoding: gzip" \ http://localhost:3000/api/check
重点看Content-Type和Content-Encoding。没有Content-Encoding不一定说明升级失败，还需要排除压缩配置关闭、返回类型不适合压缩、响应过小或请求未走预期路径等条件。
经过代理后再次验证
把地址换成测试站点域名，保持接口、请求头和返回内容相同，再观察响应。Next.js文档说明，已在自定义服务器中配置压缩时，不会再额外添加压缩；也可以在使用Nginx等外层压缩时把compress设为false。
module.exports = {
compress: false,
}
只有已经由外层负责压缩时才选择上述配置。不要在应用与外层都不压缩的情况下关闭它，也不要强行给已经解压的响应体补上Content-Encoding。
不要原样透传压缩上游响应
对应PR特别说明，Route Handler返回的Response不能简单依靠上游编码头判断是否原样透传。处理fetch返回体时需要考虑自动解压，专门的代理场景应使用适合的代理实现，避免重复压缩或编码头与实际内容不一致。
