函数工作流（FunctionGraph）连接 VPC 内 RDS 超时，安全组放通后仍需检查以下配置：1. 函数 VPC 配置确认函数已配置 VPC 和子网，且子网与 RDS 在同一 VPC函数的子网需要有可用 IP（子网不能耗尽）2. 安全组双向放通不仅 RDS 安全组要放通函数子网 IP，函数的安全组也要放通出站到 RDS 端口检查 RDS 安全组入站规则：允许函数子网 CIDR 访问 RDS 端口（默认 3306/5432）3. RDS 网络配置确认 RDS 未开启 SSL 强制但函数未配置 SSLRDS 白名单/访问控制是否限制了来源 IP4. 路由和 DNS子网路由表是否有到 RDS 的路由函数内连接 RDS 用的是内网 IP 还是域名，DNS 能否正确解析5. 超时时间函数默认超时可能太短，适当调大函数超时时间（如 60s）建议先在函数内用 telnet/curl 测试 RDS 内网 IP 端口连通性，逐步定位网络层还是应用层问题。

df 显示磁盘满但 du 找不到大文件，常见原因和排查方法：1. 已删除文件仍被进程占用（最常见）文件被删除但仍有进程持有句柄，inode 未释放，空间未回收。排查：lsof +L1 或 lsof | grep deleted 找出占用已删除文件的进程解决：重启对应进程或 kill -9 PID 释放句柄2. 隐藏文件/目录du 默认不统计以.开头的隐藏文件，但 df 统计全部排查：du -ah / | sort -rh | head -20 包含隐藏文件3. 挂载点覆盖新挂载的文件系统覆盖了原有目录，原目录下文件被遮蔽排查：先 umount，再 du 查看被覆盖的目录4. reserved blockext4 默认保留 5% 给 root，可用 tune2fs -m 0 /dev/sdX 调整建议按顺序排查，lsof +L1 能解决 90% 的情况。

按量付费 ECS 关机与释放的计费区别，一句话总结：关机只停算力费用，存储和公网 IP 仍在计费；要彻底零费用必须释放实例并清理关联资源。【关机（关机不收费）】- vCPU、内存：停止计费- 系统盘/数据盘（EVS）：继续按容量按量计费- 弹性公网 IP（EIP）及带宽：继续计费- 适用场景：短期内可能再开机使用，关机即可，剩余盘和 EIP 费用较低【释放（删除实例）】- 彻底停止该 ECS 所有计费- 操作要点：控制台删除 ECS 时勾选同时删除云硬盘；解绑 EIP 后单独释放；不需要的快照/备份也一并删除- 注意：释放不可恢复，操作前务必备份重要数据【费用核查】关机后若仍看到扣费，到费用中心查看按量消费清单按资源查看，大概率是云硬盘或 EIP 在计费，释放对应资源即可归零。

写好 Skill 的 description 关键在于以下几点：1. 明确触发词：在 description 中包含具体的动作动词+对象名词组合。2. Trigger 行示例：在 description 末尾加上 Trigger 行。3. 避免歧义：多个 Skill 涉及同一名词时区分动作范围。4. 中英文双语：同时写中文和英文关键词。5. description 长度适中：建议 100-300 字。

Nginx 502偶发但后端健康，常见原因和定位方法如下： 1. 后端连接超时：Nginx的proxy_connect_timeout/proxy_read_timeout设置过短，后端偶发慢响应时会触发502。检查Nginx error日志中是否有"upstream timed out"，适当调大超时参数。 2. upstream keepalive连接复用问题：后端偶发关闭keepalive连接但Nginx仍复用该连接发请求，导致502。在upstream块中配置proxy_http_version 1.1和proxy_set_header Connection ""来启用keepalive，或减少keepalive_requests。 3. 后端worker进程偶发OOM或crash：后端服务整体健康但个别worker被OOM Killer杀掉后重启，短暂窗口内Nginx拿到502。检查dmesg和后端应用日志是否有OOM或重启记录。 4. 端口耗尽/连接队列满：高并发时后端accept队列溢出（somaxconn过小），Nginx拿不到连接返回502。检查ss -lntn的Recv-Q是否堆积，调大net.core.somaxconn和后端listen backlog。 5. 健康检查与实际请求路径不一致：负载均衡健康检查走的是简单接口返回200，但实际业务接口偶发500/502。确保健康检查路径覆盖真实业务逻辑。 定位步骤：先看Nginx error.log确认502的具体upstream错误码（connect refused/timeout/read error），再对照后端日志时间戳，最后用strace或tcpdump抓包确认连接层面的异常。