SFTP 端口是多少？为什么连接不上？一篇讲清楚

在绝大多数情况下，SFTP 的默认端口就是 22。这也是 SSH 默认使用的端口。

所以当你执行 `sftp user@server` 时，本质上就是在连接 SSH 的默认端口，然后启动 SFTP 子系统。换句话说，如果没有额外指定端口，客户端默认一定会先尝试 22。

最常见的场景是：服务器实际监听的不是 22，而你仍然按照默认方式发起连接。比如服务器把 SSH 端口改成了 2222，但本地命令还是 `sftp [email protected]`，那客户端就一定会先打到 22。

如果 22 上没有 SSH 服务在监听，结果自然就是 `Connection refused`。这种问题看起来像是 “SFTP 不可用”，但本质上只是客户端连接错了 SSH 端口。

很多人会误以为 SFTP 只是“加密版 FTP”，所以直觉上应该有自己独立的端口。实际上并不是这样。

SFTP 的全称是 SSH File Transfer Protocol，它本身就是 SSH 连接之上的一个子系统。也就是说，SFTP 不会绕开 SSH 单独工作，而是在 SSH 连接建立之后，由服务端切换到文件传输模式。

从实际排查经验看，SFTP 不能连接的问题，大多数都集中在少数几个点上。看起来像很多种情况，实际上根因通常不复杂。

因为很多人的路径都差不多：先拿到服务器，然后开始传文件，再去搜索 FTP、SCP、SFTP 的差异。刚开始只有一台机器时，直接打一条命令问题不大。

但当服务器数量变多，不同机器使用不同端口、不同用户、不同协议时，问题就不再是 “会不会写命令”，而是 “能不能稳定记住这些连接细节”。

在服务器很少的时候，命令行完全够用。但随着连接越来越多，重复输入端口、主机、用户名和协议，会逐渐变成一件消耗注意力的事情。

很多人最后都会把这些信息记到笔记、表格或者不同的工具里。到这个阶段，你会发现真正影响效率的，不是 SFTP 本身，而是这些连接参数的管理方式。

更高效的方式不是每次重新敲 `sftp -P 2222 user@server`，而是把主机地址、端口、用户名和协议类型统一保存下来，需要时直接连接。

像 DartShell 这类一体化远程工具，本质上解决的就是这个问题：把 SSH、SFTP、RDP、数据库等分散的连接参数集中到一个工作台里，减少重复输入，也降低出错概率。

SFTP 默认端口是 22，这一点本身并不复杂。真正需要理解的是：SFTP 依赖 SSH，所以排查 SFTP 问题，本质上就是在排查 SSH 连接和配置链路。

如果连接失败，优先检查端口是否被修改、防火墙是否放行，以及 SSH/SFTP 配置是否正常。而当连接越来越多时，把这些参数交给统一的远程管理工具，会比反复记命令轻松很多。