VSCode连接数据库超时主因是链路中某层中断请求，需依次检查数据库服务可达性、网络端口连通性、服务端监听配置（如SQL Server启用TCP/IP、MySQL/PG绑定地址与权限）、VSCode扩展超时参数（如database.timeout设为30000）、驱动保活参数（如MySQL加keepAlive=true）及防火墙/NAT空闲超时策略。
VSCode 连接数据库超时，绝大多数情况不是 VSCode 本身的问题，而是连接链路中某一层主动中断了请求——常见于网络策略、数据库服务配置或驱动超时参数未对齐。
检查数据库服务是否真正可访问（别跳过这步）
很多人在 VSCode 里反复改连接字符串，却没确认数据库服务本身是否对外“真通”。VSCode 的报错（比如 connect ETIMEDOUT 或 Timeout expired）和 telnet host port 或 nc -zv host port 的结果必须一致，否则所有后续配置都是白忙。
- SQL Server：确保
sqlservermanager15.msc（2019）或sqlservermanager16.msc（2022）中已启用 TCP/IP 协议，且IPALL下的TCP Port明确填了（如1433），TCP Dynamic Ports清空 - MySQL/PostgreSQL：确认
bind-address没写死成127.0.0.1，远程用户权限含host = %或具体 IP - 用
ping只能测 ICMP，不能代替端口连通性测试；必须用nc -zv your-db-host 3306或telnet your-db-host 5432
调整 VSCode 数据库扩展的超时参数（以 mssql / mysql / postgres 扩展为例）
VSCode 自身不管理数据库连接，而是靠第三方扩展（如 mssql、mysql、vscode-postgresql）调用对应驱动。这些扩展通常把底层驱动的超时参数暴露为设置项，但默认值往往偏保守（比如 15 秒），在高延迟或资源紧张的服务器上根本不够用。
- 打开 VSCode 设置（
Ctrl+,），搜索database.timeout—— 这是多数数据库扩展共用的通用键名，单位是毫秒，建议设为30000（30 秒）起步 - 某些扩展还支持更细粒度控制，例如
mssql扩展额外读取sqltools.connections中的connectionTimeout字段，需在settings.json手动添加："sqltools.connections": [{ "name": "prod", "server": "x.x.x.x", "connectionTimeout": 60 }] - 注意：改完设置后必须重启 VSCode 的数据库连接（断开再重连），热重载不生效
防火墙与中间设备静默丢包（最常被忽略的底层原因）
即使 nc 能通、VSCode 设置也调高了，仍可能在执行查询中途断连——这时大概率是网络路径中的防火墙/NAT 设备设置了短空闲超时（如 60 秒），而数据库连接在等待结果时没有心跳，被当成“僵死连接”清掉了。
- 解决方案不是改 VSCode，而是让数据库驱动本身发送保活包。例如 MySQL 驱动支持
keepAlive=true参数，可在连接字符串末尾加上：?keepAlive=true&connectTimeout=30000 - PostgreSQL 驱动可通过
tcpKeepAlive=true启用 TCP 层保活，部分扩展允许在连接配置里加options字段传参 - SQL Server 的
encrypt=false在内网调试时可临时关闭加密协商，避免 TLS 握手耗时叠加超时（仅限可信环境）
真正卡住人的，往往是服务端监听配置 + 客户端驱动参数 + 网络设备策略三者没对齐。比如你把 VSCode 的 database.timeout 改到 60 秒，但数据库服务器只允许单个连接最大空闲 30 秒，或者中间防火墙 45 秒就断流——最后还是超时。得一层层查，而不是只盯着 VSCode 设置改。
