生产环境下Next.js(T3应用)与Docker网络问题：TypeError: fetch failed

修复Standalone模式的fetch failed错误 #

该错误源于Next.js Standalone模式的内部IPC服务寻址问题：Standalone服务器启动时会生成随机端口的IPC服务，但容器内的主机名解析异常，导致服务尝试连接127.0.0.1而非容器内部的正确地址。可通过以下两种方式解决：

1. 显式指定HOST环境变量 #

在Dockerfile的RUNNER阶段，添加HOST=0.0.0.0环境变量，强制Next.js监听所有接口，并让内部IPC服务使用正确的容器地址：

# 在RUNNER阶段的ENV PORT 3000下方添加
ENV HOST=0.0.0.0

或在docker-compose的environment字段中添加：

environment:
  # ... 其他已有环境变量
  - HOST=0.0.0.0

2. 升级Next.js版本 #

该IPC连接问题在Next.js 13.4及以上版本中已被官方修复，若使用旧版本，升级到最新稳定版即可解决。

修改后重新构建镜像并启动容器，日志中应显示started server on 0.0.0.0:3000，此时访问应用即可正常工作。

不使用Standalone构建的弊端 #

在Docker容器中放弃output: "standalone"会带来以下问题：

• 镜像体积臃肿：Standalone模式仅打包运行必需的最小依赖和文件，默认构建会包含完整的node_modules（含开发依赖）和构建中间文件，镜像体积可能从几百MB膨胀至几GB，增加拉取时间和存储成本。
• 启动速度缓慢：next start需要加载完整的Next.js框架代码和所有依赖，启动时间远慢于Standalone模式下的node server.js。
• 安全风险提升：完整的node_modules包含大量不必要的文件和开发依赖，扩大了潜在攻击面；Standalone模式仅保留生产必需文件，安全性更高。
• 资源占用过高：运行时需加载更多模块，占用更多内存和CPU资源，在容器化资源受限场景下影响尤为明显。

内容的提问来源于Stack Exchange，提问作者Niklas