根本原因是Sublime SFTP插件底层调用PuTTY工具链（非OpenSSH），对密钥格式（仅认.ppk）、DNS解析（UseDNS yes易卡顿）、超时机制（默认几秒即弃）等更敏感；需改用IP、设UseDNS no、显式配置connect_timeout、转私钥为.ppk并用绝对路径指定。
为什么 sftp 类型配置总报 connection timeout
根本原因不是插件坏了，而是 Sublime SFTP 插件默认用的是 OpenSSH 兼容模式，但实际底层调用的是 PuTTY 的 pscp/plink 工具链（尤其 Windows 下），对密钥格式、认证流程、超时逻辑都更敏感。你用 FileZilla 或命令行 sftp 能连上，不代表 Sublime 的 SFTP 插件能走通同一条路。
常见诱因包括：服务器 SSH 配置中 UseDNS yes 导致反向解析卡顿；云厂商安全组虽放行 22 端口，但限制了并发连接数或连接频率；本地 DNS 解析慢，而插件没设 connect_timeout，默认只等几秒就放弃。
- 优先改用 IP 地址而非域名填入
host字段，绕过 DNS 延迟 - 确认服务器端
/etc/ssh/sshd_config中设置了UseDNS no并重启sshd - 在
sftp-config.json中显式加一行："connect_timeout": 60（单位秒） - 如果用密码登录，确保
password字段值是明文字符串，不是空字符串或注释掉的占位符
ssh_key_file 路径写对了却还是认证失败
Sublime SFTP 插件只认 PuTTY 格式的私钥（.ppk），不支持 OpenSSH 默认生成的 id_rsa。直接把 ~/.ssh/id_rsa 路径填进 ssh_key_file，必然失败——它会静默跳过密钥认证，退回到密码方式，而你又没配 password，最终就是 timeout。
- 必须用
puttygen.exe（Windows）或ssh-keygen -p -m PEM -f id_rsa+puttygen（macOS/Linux）转成.ppk -
ssh_key_file值要写绝对路径，Windows 下用正斜杠或双反斜杠，例如："ssh_key_file": "C:/keys/deploy.ppk" - 确保该
.ppk文件权限未被系统锁定（右键属性 → 安全 → 当前用户有读取权） - 公钥必须已正确部署到服务器
~/.ssh/authorized_keys，且文件权限为600
改用 "type": "ftp" 能连上，但不安全也不推荐
这是临时绕过问题的“止痛剂”，不是解法。FTP 明文传账号密码，一旦中间网络被嗅探，服务器凭据就彻底暴露；而且多数云服务器默认禁用 FTP 服务，靠它只是碰巧开了 vsftpd 或 pure-ftpd，隐患极大。
- FTP 模式下
port必须改成21，且服务器防火墙需额外开放被动模式端口段（常被忽略） - Sublime SFTP 插件在 FTP 模式下不支持断点续传和原子上传，大文件保存易出错
- 一旦服务器管理员关闭 FTP 服务，整个工作流立即中断，而 SFTP 是 SSH 子系统，只要 SSH 在就能用
配置文件里哪些字段最容易填错
sftp-config.json 表面简单，但几个字段的值类型和语义非常容易踩坑，尤其是从网上复制模板时没细看注释。
-
"remote_path"必须以/开头，且是远程用户有写权限的目录（如/home/deploy/app），不能是~/app或空字符串 -
"user"必须是服务器上真实存在的用户名，不能是root（很多云主机默认禁用 root 密码登录） -
"upload_on_save"和"sync_down_on_open"推荐先设为false，调试通连接后再开，避免保存即上传失败导致本地文件被意外覆盖 - 所有字符串值（包括
host、user、remote_path）必须用英文双引号包裹，JSON 不接受单引号或中文引号
最麻烦的其实是“连得上但传不了文件”——那往往是 remote_path 权限不对，或者服务器 SELinux/AppArmor 限制了 SSH 子系统的写入能力。这时候看插件控制台（Ctrl + `）输出的真实错误比盲猜快得多。
