多Docker Compose互联fetch请求报错getaddrinfo EAI_AGAIN如何解决

你遇到的FetchError: request to http://nginx:80/Api/Pages/GetHeaderMenuElements/ failed, reason: getaddrinfo EAI_AGAIN nginx错误属于DNS解析失败，结合你可以在next容器内用wget正常访问nginx服务的现象，基本可以确定问题出在请求发起的环境：

• Next.js应用存在两种请求场景：
  • SSR/SSG/ISR等服务端渲染场景：请求在next容器内部发起，可通过docker自定义网络的内置DNS正常解析nginx主机名
  • CSR客户端渲染场景：请求在Windows本地的浏览器端发起，本地系统没有docker网络的DNS解析规则，无法识别nginx主机名，就会抛出该解析错误

以下三种方案可根据你的使用场景选择：

方案1：区分环境配置请求地址（最通用） #

在Next.js的环境变量配置文件中分别配置服务端和客户端的API请求地址：

1. 新增/修改.env文件内容：

# 服务端专用请求地址，仅在node环境生效
API_SERVER_URL=http://nginx:80
# 客户端专用请求地址，带NEXT_PUBLIC前缀会暴露到浏览器端
NEXT_PUBLIC_API_CLIENT_URL=http://localhost:11000

2. 在代码封装的请求工具中判断运行环境，动态选择请求地址：

const baseUrl = typeof window === 'undefined' ? process.env.API_SERVER_URL : process.env.NEXT_PUBLIC_API_CLIENT_URL

方案2：修改本地hosts映射（适合固定本地开发场景） #

直接给Windows系统添加主机名映射，让本地可以识别nginx域名：

1. 用管理员权限打开文本编辑器，打开hosts文件：C:\Windows\System32\drivers\etc\hosts
2. 末尾添加一行配置：

127.0.0.1 nginx

3. 保存后刷新DNS缓存（cmd执行ipconfig /flushdns），后续前端可统一使用http://nginx:11000作为API请求基地址即可。

方案3：配置统一反向代理入口（最贴近生产部署） #

在前端的docker-compose中新增一个nginx反向代理服务，统一接收浏览器请求，静态资源转发给next服务，/api前缀的请求转发给后端nginx服务，这样前端所有请求都可以用相对路径，不需要配置不同环境的基地址，避免跨域和解析问题。

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