Azure Web App Service上的next js应用连远程数据库报127.0.0.1:3306错误

日志里出现connect ECONNREFUSED 127.0.0.1:3306，本质是运行时实际生效的数据库host值没有取到你配置的远程地址，直接触发了mysql库的默认连接配置（默认host为127.0.0.1、端口3306），常见触发场景包括：

• 代码中读取数据库配置时键名拼写错误：mysql、mysql2这类Node.js MySQL驱动的默认连接参数就是host为本地回环地址、端口3306。如果代码里读环境变量时把process.env.DB_HOST错写成其他拼写，拿不到对应配置值时，驱动不会抛出“配置缺失”的报错，会直接用默认值去连本地3306端口。
• Azure应用环境变量覆盖了代码硬编码值：Node.js进程加载系统环境变量的优先级高于代码内写死的常量。如果之前测试Hybrid Connection时，在Azure应用配置页误把DB_HOST的值设成127.0.0.1，这个值会直接覆盖你代码里写的远程主机地址，最终连接到本地端口。
• 生产构建产物残留旧配置：Next.js执行生产构建时，会把代码内的常量提前编译进.next目录的打包文件里。如果之前本地开发时临时把host改成127.0.0.1连本地数据库，没有改回正确值就打包上传，线上运行的还是旧构建包的本地地址配置，哪怕本地代码仓库已经修正了host值，线上也不会自动生效。
• Hybrid Connection配置错位：之前配置Hybrid Connection时，如果把规则的本地映射端点设为127.0.0.1:3306，又没有在本地网络侧启动对应的隧道代理服务，App Service的沙箱环境里根本没有监听3306端口的MySQL服务，自然会抛出连接拒绝的错误。

• 打印实际运行的连接配置定位问题。在报错对应的API路由（getFromUrl.js）中，在调用mysql.createPool之前，临时添加日志打印最终传给连接池的host、port值，通过日志流确认真实生效的配置是不是127.0.0.1:3306，直接排除是值传递错误还是被外部配置覆盖的问题。
• 核对Azure环境变量配置。进入应用服务的「环境变量」页面，排查所有和数据库连接相关的配置项，删除所有值为127.0.0.1的主机类配置——这些基本都是之前测试时误加的配置。同时核对代码里读取环境变量的键名，和Azure上配置的键名完全匹配，避免拼写错误导致取值失败。
• 修正Hybrid Connection的配置逻辑。如果远程数据库没有公网访问权限，确实需要通过Hybrid Connection打通内网连接，不要直接把数据库地址替换成127.0.0.1:3306。正确的配置方式是：
• 新增Hybrid Connection规则，远程端点填写数据库真实地址abcd.efghosting.com:3306，本地映射端点选择一个不常用的端口（比如127.0.0.1:3307）
• 在应用环境变量中设置DB_HOST为127.0.0.1、DB_PORT为刚才选定的映射端口，这样应用访问本地映射端口的流量，才会通过隧道转发到真实的远程数据库地址。之前的配置错误就是直接把本地端口设为3306，又没有启动对应的隧道代理，才会出现本地连接被拒的问题。
• 重新构建部署验证。如果排查发现是线上构建产物残留旧的本地配置，拉取最新代码执行完整的next build流程后重新部署，不要使用旧的构建包上传覆盖。

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