VPN环境下VSCode中配置Athena连接遇阻问题排查

核心原因 #

SQLTools扩展未正确适配VPN环境的网络配置，或VSCode自身的网络代理设置与VPN冲突，导致无法正常访问Athena服务——但系统层面的网络（如nc、AWS CLI）不受影响，说明问题出在VSCode/扩展的专属配置上。

具体解决步骤 #

1. 手动配置VSCode网络代理 #

让VSCode复用VPN的代理设置，避免自动检测出错：

• 打开VSCode设置（快捷键Ctrl+,/Cmd+,）
• 搜索http.proxy，填入你的VPN代理地址（比如http://127.0.0.1:1080，具体地址看VPN客户端的代理端口）
• 若VPN使用自签名证书，把http.proxyStrictSSL设为false
• 重启VSCode后测试连接

2. 强制SQLTools复用AWS CLI配置 #

确保SQLTools使用和CLI一致的认证与网络规则：

• 打开AWS CLI配置文件（Linux/macOS路径~/.aws/config，Windows路径C:\Users\<你的用户名>\.aws\config），添加：

  [default]
  region = us-east-1
  cli_follow_urlparam = false
  

• 在SQLTools的Athena连接配置中，勾选Use AWS CLI credentials选项，让扩展直接复用CLI的配置

3. 关闭VSCode自动代理检测 #

部分VPN会干扰VSCode的自动代理识别，直接禁用：

• 在VSCode设置中搜索http.proxySupport，设置为off
• 或者直接编辑settings.json，添加：

  "http.proxySupport": "off"
  

4. 调整VPN路由规则 #

如果VPN强制将AWS域名导向内部网络，添加例外路由：

• 查看VPN客户端的路由表，确认athena.us-east-1.amazonaws.com是否被强制走VPN内部
• 若有，添加例外规则（比如OpenVPN中添加route athena.us-east-1.amazonaws.com 255.255.255.255 net_gateway），让该域名流量直接走本地网络

5. 重置SQLTools连接配置 #

清除旧配置缓存，重新创建连接：

• 删除现有SQLTools中的Athena连接
• 重新创建连接，仔细核对区域、认证方式等参数
• 测试前关闭并重新打开SQLTools面板

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