Google Cloud SQL Proxy配置为服务后无法正常工作的求助

核心问题根源 #

手动运行和systemd服务的运行环境完全不同——手动执行时继承了你当前用户的环境变量、工作目录和权限，但systemd服务默认以独立上下文运行，这就是两者表现不一致的核心原因。

分步解决方法 #

1. 强制指定认证文件路径 #

手动运行时，你的用户环境大概率配置了GOOGLE_APPLICATION_CREDENTIALS变量，或者proxy能自动找到当前目录下的认证密钥，但systemd服务没有这个环境。直接在服务命令里指定密钥文件路径：
修改服务文件的ExecStart行：

ExecStart=/path/path/cloud_sql_proxy -credential_file=/绝对路径/到/你的/service-account-key.json -instances=<INSTANCE NAME>=tcp:0.0.0.0:5004

务必替换成你实际的服务账号密钥文件的绝对路径

2. 配置服务的工作目录与运行用户 #

如果proxy依赖特定工作目录，或者你想更安全地用普通用户运行，在[Service]块中添加：

WorkingDirectory=/你的proxy程序所在目录的绝对路径
User=pi
Group=pi

这里的pi是树莓派默认用户，根据你的实际登录用户调整

3. 修复认证文件权限 #

确保密钥文件权限严格，避免被其他用户读取，同时让服务运行用户能访问：

chmod 600 /绝对路径/到/你的/service-account-key.json
chown pi:pi /绝对路径/到/你的/service-account-key.json

4. 验证服务状态与日志 #

修改完服务文件后，重载配置并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart cloud-sql-proxy.service

查看服务状态和实时日志，定位具体错误：

sudo systemctl status cloud-sql-proxy.service
sudo journalctl -u cloud-sql-proxy.service -f

日志会直接告诉你是认证失败、文件找不到还是其他问题，这是排查的关键

5. 确认端口监听状态 #

用ss命令检查proxy是否真的在监听5004端口：

ss -tulpn | grep 5004

如果没有监听记录，说明服务启动失败，回到日志找原因；如果有监听但仍无法连接，检查树莓派的防火墙（比如ufw status）是否放行5004端口

额外提醒 #

• 服务文件中所有路径必须用绝对路径，禁止使用相对路径
• 若你的Cloud SQL实例是私网访问，确保树莓派的网络能正常连通实例（但手动能连的话这个可能性极低）

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