Google Workflow调用URL编码后的Cloud Run接口返回403错误

1. 身份验证拦截：请求未抵达Cloud Run #

Cloud Run无对应请求日志，说明请求在到达服务前就被拦截，403错误核心原因大概率是Workflow的服务账号权限不足：

• Shell中curl调用依赖的是你的个人用户身份（gcloud自动注入凭证），而Workflow默认使用自身专属服务账号（格式为[workflow-name]@[project-id].iam.gserviceaccount.com）。即便前期调用正常，也可能是该服务账号未被授予目标Cloud Run服务的roles/run.invoker权限，导致含编码字符的请求触发权限拦截。

2. URL双重编码引发的异常 #

Workflow的text.url_encode完成编码后，拼接成URL发起请求时，Workflow的HTTP客户端可能自动对URL再次编码，造成双重编码问题：

• 例如邮箱someone@email.com被编码为someone%40email.com后，再次编码会变成someone%2540email.com，此时Cloud Run的路由规则无法匹配到对应函数路径，但部分权限配置下会直接返回403而非404，同时不会生成服务日志。
• 验证方式：查看Workflow执行日志中的实际请求URL，确认是否存在双重编码情况。

3. 特殊编码字符触发安全拦截 #

文件名中包含的%01这类控制字符编码后，可能被Workflow的HTTP客户端判定为非法请求，触发内置安全拦截直接返回403，请求根本不会被转发到Cloud Run。

排查建议 #

• 补全服务账号权限：为Workflow的服务账号添加目标Cloud Run服务的Cloud Run Invoker角色，重新测试请求。
• 核对实际请求URL：从Workflow日志中提取实际发送的URL，复制到Shell用curl调用，确认是否同样返回403，以此区分是编码问题还是权限问题。
• 避免双重编码：尝试跳过手动text.url_encode，直接将原始字符串拼接进URL，让Workflow的HTTP客户端自动处理编码；或查看Workflow配置，是否支持禁用自动URL编码。

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