Cloud Scheduler请求HTTPS端点误报502但服务端返回200，疑似链路超时

60秒固定超时阈值来自Firebase Hosting 反代Cloud Run服务的链路硬配置，不属于Cloud Scheduler或Cloud Run的配置问题。
具体触发逻辑为：

Firebase Hosting对通过自定义域名转发到后端Cloud Run的请求，存在固定60秒的最长等待时长，到点后如果未拿到后端响应，会直接向请求方返回502 Bad Gateway并切断与请求方的连接。该配置无用户侧可调参数，且Hosting不会主动中断与后端Cloud Run的连接，因此后端服务会继续完成任务、在日志中写入200响应记录，但这个响应无法回传到Cloud Scheduler，调度器只会收到502状态并判定任务失败。

已观测到的所有现象可完全匹配该机制：

• 直连Cloud Run域名时无60秒超时限制，80秒长任务可被正确标记成功
• 执行时长35秒的任务远低于60秒阈值，运行状态正常
• 执行时长80秒的任务触发Hosting层60秒断连，因此返回502
• 接口等待59秒返回200时可被识别成功，等待65秒返回则判定失败，与固定超时阈值的行为完全一致

可通过以下步骤确认超时节点，排除其他可能性：

• 核对全链路时间戳：分别提取三个节点的关键时间点
  1. Cloud Scheduler发起POST请求的时间
  2. Firebase Hosting边缘节点返回502的时间（可通过Hosting访问日志查询对应请求的响应码与时间戳）
  3. Cloud Run服务收到请求、执行完成写入200日志的时间
     正常情况下可观测到，Hosting在请求发起后恰好60秒返回502，Cloud Run的200日志在请求发起后80秒左右生成，两个时间点的差值为服务端实际执行时长，即可证明超时发生在Hosting层。
• 已排除的节点问题：
  • Cloud Scheduler侧：attemptDeadline配置为180s，不会在60秒触发超时判定
  • Cloud Run侧：服务默认请求超时阈值为300秒，且日志显示所有请求都正常生成200响应，未触发服务侧的超时逻辑
  • 域名配置侧：两个自定义域名的路由规则完全一致，报错仅和请求时长相关，与域名注册地区、配置无关

• 直接调整Cloud Scheduler的请求指向，跳过Firebase Hosting链路
  将任务的目标域名从Firebase Hosting绑定的自定义域名，改为Cloud Run服务的默认域名，同时为调度器任务配置对应服务的OIDC认证即可。该方案完全避开Hosting层的60秒超时限制，可兼容现有80秒的长执行任务，且服务路由逻辑无本质变化。
• 改造长耗时接口为异步响应模式
  将/api/jobs/update-prices接口调整为收到请求后，1秒内返回200 Accepted响应，将实际的价格更新逻辑交给后台任务执行（可搭配Cloud Tasks队列、或Cloud Run服务内的异步执行线程），保证请求响应时间远低于60秒阈值，避免触发Hosting层的超时断连。
• 拆分长耗时任务
  把单次执行80秒的全量价格更新逻辑，拆分为多个单次执行时长低于50秒的小批量任务，通过任务编排依次触发，保证每个通过Hosting链路的请求响应时间都在60秒阈值以内。

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