同VPC内Cloud Run服务间因CORS与Ingress配置访问受阻

核心原因分析 #

当Service B的Ingress设为Internal时，Cloud Run入口层会直接拦截所有VPC外部的请求（包括浏览器发起的OPTIONS预请求），这些请求根本无法抵达你的Flask应用——这也是你移除CORS配置后无变化、日志显示请求未到后端的原因。只有当Ingress设为All时，公网请求才能正常触达Flask服务，CORS配置才会生效。

排查方向 #

• 确认请求路径的网络归属：你的NextJS前端代码在用户浏览器中运行，浏览器发起的请求是从用户公网环境直接发往Service B，而非通过Service A的VPC链路。Service A的VPC配置仅作用于其容器自身的出站流量，不影响前端浏览器的请求路径。
• 查看Cloud Run入口层日志：检查Cloud Run的审计或请求日志，会发现OPTIONS预请求被入口层直接拒绝，并未转发到Flask服务。
• 验证VPC内访问有效性：在同VPC内的资源（如Cloud Shell、Compute VM）中向Service B发起请求，确认服务本身能正常响应并返回CORS头，排除服务自身逻辑问题。

解决方案 #

方案1：通过Service A代理转发请求 #

修改NextJS前端代码，将请求发送到Service A的API端点，再由Service A的容器内逻辑通过VPC访问Service B：

• 浏览器仅与Service A通信（同域名或已配置CORS的域名），规避跨域问题
• Service A容器通过VPC访问Service B，符合Internal Ingress的访问规则

示例NextJS API路由（pages/api/proxy-to-b.js）：

export default async function handler(req, res) {
  const backendUrl = process.env.SERVICE_B_URL;
  try {
    const response = await fetch(backendUrl, {
      method: req.method,
      headers: req.headers,
      body: req.body,
    });
    const data = await response.json();
    res.status(response.status).json(data);
  } catch (error) {
    res.status(500).json({ error: 'Failed to proxy request' });
  }
}

方案2：调整Service B的Ingress与权限控制 #

若需直接让浏览器访问Service B，可将Ingress设为All，同时通过IAM权限限制仅允许Service A的服务账号调用，或用Cloud Armor设置IP白名单，只放行Service A的出口IP。

方案3：VPC Access + 负载均衡组合配置 #

配置外部HTTP(S)负载均衡，通过VPC Connector将公网请求转发到Ingress为Internal的Service B，同时在负载均衡层配置CORS规则处理预请求。该方式适合需直接暴露后端、又要限制VPC内访问的场景。

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