App Engine 也能连上你的 VPN 数据库：哪些设置必须对齐

“标准版 App Engine 无法通过 Cloud VPN 访问私有数据库”的说法，是平台早期版本留下的旧结论。标准实例确实不像某些运行时那样拥有 VPC 原生地址，但它们可以把出口流量送进你网络里的 Serverless VPC Access 连接器。这条通路一旦存在，Cloud VPN 和远端防火墙看到的连接器流量就和任何其他来源一样。真正失败的往往不是能力本身，而是三项从未对齐的设置之一。

旧说法从何而来

在连接器出现之前，实际答案确实是标准版只能访问公网端点，团队为了绕开限制，会改用代理 VM 或别的运行时。平台变了，传说没变。网上很多建议至今仍停留在完全没有出口选项的年代。

修正比听起来要窄。标准版确实能到达私有网络，但只能经由受支持的出口集成，而且只覆盖该集成真正捕获的目标。

先选出口路径

把连接器挂到服务上，流量才会进入 VPC。连接器文档列出了区域前提和出口设置；连接器必须位于服务所在区域，并且部署所用的身份有权使用它。

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only 只把私有目标送进 VPC，其余流量仍走正常互联网路径，这通常正是数据库连接需要的。all-traffic 则把出站流量整体推入 VPC，于是普通互联网调用也会继承 VPC 的 NAT 和防火墙策略。

只在本地改文件，不部署就不会生效。正在运行的版本会保留创建时的配置。

源地址是连接器，不是你的笔记本

调试时间大多花在这里。远端 VPN 网关和数据库防火墙要放行的是 VPC 内分配给连接器的地址范围，既不是你办公室的地址，也不是服务的公网出口地址。写第一条规则之前，先去控制台查清这个范围。

还有两处必须一致。VPC 路由表需要有通往远端数据库网段的路由，远端也要有回程路由指向连接器范围。如果隧道使用流量选择器，请确认连接器范围落在协商范围内。只有远端到本地单向存在的路由是常见疏漏，它能通 ping，却永远完不成 TCP 握手。

只放行 VM 子网的隧道会直接丢弃连接器数据包，而且不给有用的报错，这就是数据库超时看起来像凭据问题的原因。

DNS 走的是另一条路

私有数据库主机名必须在连接器可达的网络内解析，可以借助 Cloud DNS 对等互联，或 VPC 可用的转发区域。在工作站上能解析，并不能证明已部署的服务也能解析，因为你的笔记本并没有使用那个解析器。

如果从 VPC 内部把该名字解析成公网地址，那你接下来调试的会是错误的防火墙。

URL Fetch 不走连接器

出口设置覆盖的是运行时正常的出站套接字，旧版 URL Fetch 服务不在其中。通过 urlfetch 发出的请求无论配置怎么写都会绕过连接器。当失败的调用藏在仍使用 URL Fetch 的旧库里时，解决办法是把该调用迁到标准 HTTP 客户端。

对数据库驱动来说这很少是问题，但它正是同一服务里一个端点能用、另一个不能用的经典原因。

用一条窄查询验证

部署之后，从已部署版本执行一次被允许的数据库操作，同时观察远端。数据库或 VPN 网关记录的源地址应当是连接器的地址。如果不是，说明请求根本没进 VPC，再多的隧道配置也修不好。把它和控制台里查到的范围比对；不一致通常意味着有第二个连接器在为该版本服务。

在 VPC 内的 VM 上查询成功，只能证明路由存在，不能证明服务选择了它。