排查Docker中通过Cloud SQL Auth Proxy连接Google Cloud SQL的问题

一、API容器连接拒绝的核心原因 #

你的API容器尝试连接127.0.0.1:3307，但在Docker Compose默认网络中，每个容器都有独立的网络命名空间——容器内的127.0.0.1指向自身而非代理容器。同时，代理容器当前配置--address 127.0.0.1，仅监听自身的localhost接口，其他容器无法访问该端口。

修复步骤： #

1. 修改代理的监听地址：将代理服务的--address参数改为0.0.0.0，让代理监听容器内所有网络接口，允许其他容器通过服务名访问：

   command: myproject:myregion:myinstance --credentials-file=/secrets/cloudsql/credentials.json --address 0.0.0.0 --port=3307
   

2. 更新API的数据库连接地址：将Node.js API中的数据库连接字符串从127.0.0.1:3307改为proxy:3307（proxy是Docker Compose中代理服务的名称，会被自动解析为代理容器的IP）。

二、无效密钥容器代理仍能启动的可能原因 #

1. 令牌缓存机制 #

Cloud SQL Proxy会缓存已获取的认证令牌，当你修改密钥为无效值后，如果代理容器之前已用有效密钥启动过，缓存的令牌可能未过期，代理会继续正常运行，直到令牌需要刷新时才会触发认证错误。而本地运行时没有缓存，会立即验证密钥有效性，因此报错。

2. 容器挂载的密钥文件未更新 #

虽然你修改了本地的cloud-sql.credentials.json，但Docker卷挂载可能存在延迟，或代理容器未重启导致未加载最新文件。你可以进入代理容器验证文件内容：

docker exec -it <你的代理容器ID> cat /secrets/cloudsql/credentials.json

3. Proxy启动流程差异 #

部分版本的Cloud SQL Proxy启动时会先启动监听服务，再异步进行认证验证。容器环境下可能采用非阻塞启动逻辑，即使认证失败也会先监听端口；而本地运行时可能采用阻塞式认证，必须通过验证才会启动服务。

三、后续排查步骤 #

1. 强制重启代理容器：确保加载最新的密钥文件，查看是否触发认证错误：

   docker-compose restart proxy
   

2. 测试容器间连通性：进入API容器，测试是否能访问代理服务的端口：

   docker exec -it <你的API容器ID> nc -zv proxy 3307
   

   如果返回succeeded!，说明网络连通正常，问题出在API的数据库配置。
3. 核对Proxy版本：确保本地运行的Cloud SQL Proxy版本与容器内的2.8.2一致，版本差异可能导致行为不同。
4. 查看Proxy详细日志：添加-verbose参数启动代理，获取更详细的认证日志，确认是否存在隐性认证失败：

   command: myproject:myregion:myinstance --credentials-file=/secrets/cloudsql/credentials.json --address 0.0.0.0 --port=3307 -verbose
   

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