FunctionGraph 访问 VPC 内 RDS 超时：先定阶段，再逐层查链路

现象：给 FunctionGraph 函数配了 VPC 和子网，RDS 安全组也放通了对应端口，调用函数连数据库还是超时。安全组只是其中一环，这类问题要先定位“超时”卡在哪一步，再逐层排查。

一、先看异常类型，定排查方向

报错信息不一样，根因完全不同：

• connect timeout / connection timed out：TCP 根本没建连，往 VPC、子网、安全组方向查；
• 建连成功但认证慢、查询慢：往超时参数和 SQL 性能方向查；
• Access denied for user：这是白名单或账号权限问题，不是网络超时。

建议先在函数里打印异常类型，别笼统按“网络不通”排查。

二、确认函数真的挂进了 VPC

FunctionGraph 函数默认不运行在用户的 VPC 中，需要手动为函数配置 VPC 信息（选择 VPC、子网、安全组）。如果函数没有配置 VPC，它无法访问 VPC 内的任何资源。在函数配置页确认 VPC 访问已启用，且指向 RDS 所在的 VPC——跨 VPC 是不通的，除非打了对等连接并配好路由。

三、安全组要双向、字段要看准

很多人只配了 RDS 的安全组入方向，容易漏两点：

• RDS 安全组入方向：放通函数子网的网段（或直接引用函数的安全组 ID），对应 RDS 端口（MySQL 3306 / PostgreSQL 5432 等）；
• 函数安全组出方向：默认全部放通，但如果有自定义规则，需确认放通了 RDS 子网网段对应端口。

源地址建议填函数所在子网的网段，或直接引用函数的安全组 ID。不要填函数实例的公网 IP，也不要图省事填 0.0.0.0/0——前者不匹配，后者不安全。

四、几个容易漏的点

1. DNS 解析：函数在 VPC 内访问 RDS 内网域名，依赖子网的 DNS 服务。如果子网改过自定义 DNS 服务器、或者 DNS 配置异常，域名解析失败的表现就是“一直超时”。快速验证：把连接地址临时换成 RDS 内网 IP 直连，通了就是 DNS 的问题。
2. 子网 IP 耗尽：函数实例会从所选子网占用 IP 地址。如果子网地址段太小、可用 IP 耗尽，新实例拿不到 IP，建连也会失败。检查子网剩余可用 IP，必要时换个大网段的子网。
3. 网络 ACL（子网级）：安全组之外，子网还可能配了网络 ACL。NACL 是无状态的：放通了 3306 入方向，还要放通返回流量的出方向（临时端口范围），否则握手包回不来，现象同样是超时。NACL 默认规则是全放通，改过才需检查。
4. RDS 实例侧：实例是否正常运行、连接数是否打满、是否处于备份窗口，也可以顺手确认一下。

五、超时参数本身

FunctionGraph 默认超时时间较短（3 秒），如果数据库连接初始化较慢，可能还没连上就超时了。建议先把函数超时时间调大到 30~60 秒，排除误判——很多“一直超时”其实是函数执行时被平台掐断，网络根本没问题。

六、快速验证：一段 TCP 探测代码

在函数里跑一段纯 TCP 连接测试（不跑业务 SQL），把网络问题和认证、驱动问题分开：

import socket

def handler(event, context):
    s = socket.socket()
    s.settimeout(5)
    try:
        s.connect(('RDS内网IP', 3306))
        return 'tcp ok'
    except Exception as e:
        return str(e)

• TCP 能通：网络没问题，往认证、白名单、驱动配置查；
• TCP 不通：回到前面核对 VPC、子网、安全组。

七、排查顺序清单

看异常类型定阶段 → IP 直连排除 DNS → 查子网剩余 IP 和 NACL → 核对安全组源地址 → 最后看实例状态和超时参数。

按这个顺序走一遍，大多数“安全组放通了还是超时”的问题都能定位到具体一层。