为了 AutoDL 传文件更快更省心我自己做了个 SSH 工作区SSHFerry下载见结尾之前我写过一篇和 AutoDL 上传有关的文章没想到后面慢慢有了 1 万多阅读。但那篇文章现在回头看我觉得还是有点不够负责。因为我当时给出的推荐方案本质上还是在现成工具里做取舍。可真正用久了之后我发现很多人遇到的问题并不是到底选哪个工具而是这类工具本身就没有把日常 SSH 文件传输这件事做顺手。尤其是评论区里不断有人提到SSH 连不上或者连得不稳定密码明明没错结果就是进不去上传下载能用但体验很碎一到整个文件夹、很多小文件、或者服务器和服务器之间互传就开始麻烦所以后来我没有继续写还有没有更好的替代品而是自己下场写了一个工具名字叫SSHFerry。这篇文章我想认真讲清楚三件事我为什么不再继续推荐 MobaXterm 这类方案SSHFerry 到底解决了什么问题我在速度、便捷性、UI 和技术实现上具体做了哪些东西先提前说一句这不是一个换皮 SSH 工具也不是一个只会把文件传过去的壳。它更像是我自己长期折腾 AutoDL、远程服务器之后逼出来的一套真正能用的工作流。说明文中的速度数据和体验结论主要来自我自己的实际使用场景尤其是 AutoDL 环境。不同机器、不同带宽、不同线路下数据会有差异但设计目标和优化方向是一致的。✨ 先看结论如果你只想记住这一篇文章里的 4 个点那就是下面这 4 句⚡AutoDL 实测能稳定跑到 10MB/s 左右支持整个文件夹直接传很多小文件也不会拖垮体验️本地、远端、任务中心放在同一个工作区里我最在意的差异点是远端 UI 直接操作和后续互传能力️ 先看图我到底做了个什么东西先不急着讲实现先看界面。图 1SSHFerry 主界面总览。左侧是站点列表中间是本地工作区右侧是远端工作区下方是任务中心右下角是日志区。我的目标不是做一个只会弹上传框的小工具而是做一个能长期使用的 SSH 文件工作区。看完这张图基本就能明白 SSHFerry 的方向了不是把 SSH 套一层 GUI而是把本地、远端、任务流和后续操作全部收进一个工作区。⚡ 先说结论我想做的不是能传而是传得顺手如果你只是想传一个单独的大文件那绝大多数 SSH 工具最终都绕不开一个事实上限通常还是你的带宽。所以我后来越来越不想再拿单文件峰值速度去做主要卖点。真正把体验拉开差距的反而是这些东西连接稳不稳大文件会不会自动走更合理的传输策略小文件和整个文件夹是不是也能快服务器和服务器之间能不能直接操作互传传输过程能不能看见、暂停、继续、重试UI 是不是顺手而不是逼你反复切命令行和多个窗口而 SSHFerry 的目标就是把这些问题一起解决掉。在我现在的实际使用里它最让我满意的几个点是⚡AutoDL 实测传输可以稳定在 10MB/s 左右本地上传服务器、从服务器下载到本地都很快支持整个文件夹直接传递️一批 256 张图片我这边实测 1 秒左右就能完成传递最关键的一点我把远端 UI 直接操作互传这件事做进去了这也是我现在最想强调的差异点。我不是只想把本地传服务器做好我是想把本地、远端、远端与远端之间的文件流转都统一到一个界面里。❌ 为什么我不再继续推荐 MobaXterm先说清楚不是说 MobaXterm 不能用。它当然能用而且很多人第一次接触 SSH 图形化工具都会先用到它。但问题在于它解决的是你可以通过图形界面连 SSH而不是你可以很顺手地长期管理 SSH 文件工作流。这个差别一开始不明显用久了会越来越明显。1. 它能连不代表它省心这一点其实我不是自己拍脑袋下的结论而是看评论区一点点堆出来的。不少人遇到的问题都很像SSH 连接建立不稳定明明密码没错就是认证失败配置逻辑不够直观新手第一次用很容易卡住如果只是临时连一下服务器也许还能忍。但如果你平时就是经常跟 AutoDL、云主机、实验室服务器打交道这种不确定性会非常烦。2. 真正麻烦的从来不是传一个大文件很多人容易以为文件传输工具的核心竞争力就是谁更快。但我现在越来越觉得这个理解其实只说对了一半。因为对于单个大文件来说很多工具的上限都差不多最后还是会卡在网络带宽。真正难受的往往是下面这些场景你要传的是一个文件夹不是单文件你要传的是一堆零碎小文件不是一个大压缩包你不只是本地和服务器之间传还要服务器和服务器之间互传你中途断了之后不知道进度、不知道剩多少、也不知道该不该重试这些问题恰恰是我自己天天会遇到的。3. 很多工具更像功能有了不是工作流打通了我后来真正不满足的点不是某一个按钮少了而是整体工作流太碎。你很容易进入下面这种状态一个窗口看本地文件一个窗口看远端文件另一个窗口看另一个服务器真到远端互传的时候再去敲scp或手动中转传输了之后还得自己判断到底卡没卡、断没断、成功没成功这件事做久了我就一个感觉我想要的不是勉强能做完而是打开软件就能把这件事顺下来。所以 SSHFerry 就是这么来的。 SSHFerry 到底是什么一句话说SSHFerry 是一个围绕 SSH 文件操作工作流来设计的工具。它现在的整体形态不只是一个前端界面而是三层结构桌面客户端Python PySide6本地后端FastAPIWeb 前端React Vite真正的传输调度核心是复用的不是桌面端一套、Web 端一套各写各的。这也是为什么我后面很多优化不是停留在 UI 层而是直接做进了传输引擎和调度器里。可以先看一眼它的整体结构我目前最推荐的入口还是桌面端。因为桌面端现在已经能覆盖我日常最常用的几条路径本地上传到远端远端下载到本地远端和远端之间直接互传整个文件夹传输任务状态查看、暂停、继续、取消、重试你可以把 SSHFerry 理解成一个 SSH 文件工作区而不是一个单独的上传弹窗。还有一个我自己很喜欢的小点是它上手比我原来预想得更快。图 2新增站点时可以直接粘贴 SSH 命令自动解析。像ssh -p 端口 用户名主机这种现成命令复制进来就能拆出 host、port 和用户名不用再手动一项项填。这一点看起来不大但我觉得很有用。因为真正高频用 SSH 的人手上往往已经有现成命令了能少填一遍表单就是更顺手。 我最想强调的 4 个点1. ️ 它不是单纯传文件而是把文件流转做成一个工作区我现在最满意的设计不是某个测速数字而是工作区这个思路。在 SSHFerry 里我想做的是这样一套流转也就是说你不是只能做本地 - 远端这种最基础的一跳。你可以在同一个工作区里同时盯着本地、多个远端会话和任务中心把整条链路做完。这对我自己来说非常重要因为我很多场景本来就不是单点传输而是本地先传到一台中转机再从中转机传到另一台服务器或者从 A 服务器直接拷到 B 服务器如果这些动作还得拆成多个软件、多组命令那我根本不会满意。而且现在从界面上看这个工作区思路已经比较清楚了左边维护站点中间看本地目录右边看远端目录下方统一看任务状态我自己现在越来越不想回到文件传输靠多个窗口拼出来的状态。图 3连接成功后的工作区界面。本地目录、远端目录和任务中心会同时出现在一个界面里整个文件夹传输、目录扫描和任务状态都能直接看见不需要来回切窗口。2. ⚡ 速度不是喊出来的我是按场景做优化我不想写那种很空的宣传词比如速度显著提升“性能大幅优化”。我更想直接说它为什么会更快。大文件自动分片并行在 SSHFerry 里本地和远端之间的单文件传输默认会按文件大小决定策略。默认阈值是50MB文件大于等于 50MB 时会优先走并行 SFTP默认上传 preset 是10 个 worker 4MB 分块默认下载 preset 是16 个 worker 8MB 分块也就是说它不是一上来就粗暴开并发也不是所有文件都一视同仁。小文件就老老实实普通传大文件才切块并行。这一点背后不是简单调个线程数而是专门做了并行传输引擎。每个 worker 会各自建立 SFTP 连接按分块偏移量写入目标文件如果某个块失败了会做块级重试而不是整任务重来。中断场景优先保证正确性还有一点我自己很在意速度不能建立在容易传坏文件的前提上。所以 SSHFerry 的策略不是并行传输强行兼容所有情况而是全新的大文件优先并行如果已经有部分文件需要断点续传退回普通 SFTP 续传这听起来没那么激进但我觉得这是对的。因为续传场景最重要的是正确不是看起来很猛。我的实际感受就我自己的 AutoDL 场景来说SSHFerry 现在给我的感受不是偶尔冲一个很高的峰值而是✅速度稳定✅不折腾✅传大文件和传目录都比较省心我更愿意用稳来形容而不是只晒某一次跑出来的最高数字。实测里我这边常见场景能稳定在10MB/s 左右这个对我来说已经很够用了。3. 真正能拉开差距的其实是文件夹和一堆小文件这部分我反而觉得比大文件更重要。因为现实里最烦的事情经常不是传一个 20GB 的单文件而是这种一个数据集目录一堆图片一堆零碎脚本、配置、标注文件一整套实验输出结果这种场景如果还按传统思路一个个文件慢慢传体验就会非常差。所以 SSHFerry 里对目录传输做的是mixed 策略大文件单独处理继续走并行传输规则小文件优先打成tar bundle再传这套策略不是写着好看仓库里是真有一整套规则的。默认情况下小文件 bundle 单批最大字节数是128MB单批文件数上限是256这也是为什么我这边会出现256 张图片只要 1 秒左右这种体验。因为这类场景真正慢的地方很多时候不是网络本身而是反复建立小文件传输开销。把这一层开销吃掉之后体感会直接不一样。而且它不只是支持传文件而是支持整个文件夹直接传递。这一点对经常跑实验、拉数据、备份结果的人来说非常重要。从现在这张图里其实已经能看到目录任务的状态了这里直接复用上一张连接后的工作区图就够了。任务中心里能看到目录任务已经进入队列当前状态、进度、源路径、目标路径都在同一个区域里统一展示。对我来说知道它现在在干嘛和它到底能不能传一样重要。4. 远端互传和 UI是我最想做出差异化的地方如果只做本地上传下载其实很多工具都能勉强覆盖。但我自己最需要的场景之一是远端和远端之间互传。这也是我现在最愿意拿出来讲的点。我希望做到的是不是只能本地当中转不是还得你自己打开终端敲命令不是还要在两个 SSH 工具之间切来切去而是直接在 UI 里把一个远端的文件拖到另一个远端剩下的交给调度器。对我来说这一点非常关键。因为它决定了这个工具到底只是个图形化上传器还是一个真正能干活的远程文件工作区。在实现上远端互传也不是单一路径而是会自动选更合适的方式能直接拷就优先 direct copydirect 不行就走 bridge大文件场景会进一步考虑parallel bridge默认超过128MB的远端大文件复制会优先进入dual-path策略dual-path这部分其实是我自己很喜欢的一块实现。你可以简单理解成它不是只赌一条路径而是让 direct lane 和 relay lane 同时竞争谁先把块传完就算谁赢。说白了我想做的不是一个能用就行的按钮而是让远端互传这件事真的变得好用。 它为什么会快把传输策略做进调度器而不是只做在界面里我觉得这部分有必要展开讲一下。因为 SSHFerry 的优势不只是 UI 看起来更完整而是底层真的有传输调度逻辑。它大概是这样一套流程具体来说当前版本里比较关键的技术点有这些1. 并行 SFTP 不是口号是真的分块本地和远端之间的大文件传输默认阈值是50MB。超过这个大小就会优先进入并行传输逻辑。默认参数大概是上传10 个 worker4MB chunk下载16 个 worker8MB chunk每个 worker 负责不同 offset 的数据块失败块单独重试。这比一条顺序流一路跑到底更适合大文件场景。2. 目录传输不是递归硬传而是大文件和小文件分治对于目录我不想让它退化成递归遍历 一个个上传。所以现在的策略是大文件单独走并行逻辑小文件优先打包成 bundle不满足 bundle 条件时再自动回退到逐文件传输这样做的好处很直接目录里如果混着几个大文件和一堆小文件不需要所有文件都走最笨的路径。3. 远端互传不是简单 scp 包一层 UI远端和远端之间复制时当前实现会优先探测能不能 direct copy。如果 direct 不行再继续退到 bridge、parallel bridge 或 dual-path。也就是说这不是界面上看起来支持互传而是底层真的按不同链路做了分支。4. 任务是可观察的不是黑盒这一点我自己也很在意。很多时候最烦的不是传得慢而是你根本不知道它现在在干嘛。所以 SSHFerry 里我一直想做的是可观察的任务流能看见任务进度能暂停、继续、取消、重试能知道现在跑到哪里失败了也不是一脸懵我自己很讨厌那种转个圈然后你猜它到底成功没的传输体验。 UI 这件事我不是拿来做装饰的我知道很多人一看到 GUI 工具会先担心两个问题会不会只是把命令包了个壳会不会界面花里胡哨但真用起来不顺手所以我从一开始就没打算把 UI 当成装饰层。我对 SSHFerry 的 UI 预期很简单本地面板和远端面板要能并排看多个远端会话要能同时开拖拽要是一等工作流不是附属功能任务中心要长期可见用户不应该为了确认状态反复切终端还有一个很直观的小细节就是右键操作这件事。图 4本地目录里右键就能直接上传到当前激活的远端会话。这个动作本身不复杂但它非常符合我对这类工具的预期别让我再去想下一步该在哪个窗口里做我只想顺手把文件送过去。这也是为什么我会特别强调远端 UI 直接操作互传。对我来说这不是一个锦上添花的功能而是整个产品体验有没有站住的关键。如果后面继续往下打磨我会继续重点做这几件事远端互传体验继续抛光Web 端继续补齐更多传输场景下的策略优化UI 交互再压缩一次操作路径 谁会比较适合用 SSHFerry如果你是下面这类人我觉得你大概率会有感觉经常使用云平台如 AutoDL经常在本地和远端服务器之间传模型、数据集、结果文件不想每次都靠多个窗口和命令拼工作流经常要在不同服务器之间互相搬文件对整个文件夹传输和一堆小文件也得快这件事比较敏感反过来说如果你一年就上传两三次文件什么工具都能忍那你未必会觉得它差很多。但如果你是高频用户差距会很快出来。❤️ 我为什么愿意继续做这个项目因为它不是我为了发项目而临时写的展示品。它就是我自己真在用、真被需求逼出来的东西。我做 SSHFerry 的出发点从来不是做一个看起来很全的 SSH 工具而是想把下面这几件事做扎实连接更稳传输更快文件夹和小文件也要快远端互传真正能用UI 直接服务工作流我自己其实很清楚这个项目还远远没到已经做完的阶段。但我觉得它已经开始呈现出我真正想要的样子了。这也是我为什么愿意把它公开出来而不是只留着自己用。 项目地址和下载方式如果你看到这里最直接的两件事就是去 GitHub 看项目和 Release直接下载试一下看它是不是刚好解决了你的那类场景GitHub 项目地址GitHubhttps://github.com/lllllllama/SSHFerry当前 ReleaseReleaseshttps://github.com/lllllllama/SSHFerry/releases/tag/v0.1.3如果你更习惯网盘也可以直接拿打包版本百度网盘https://pan.baidu.com/s/1aoCw0hFQ-8Zmz_vp83gr6A?pwdczm5提取码czm5✅ 最后如果你之前看过我那篇 AutoDL 上传的文章这篇其实算是我的一次修正。我现在的看法比之前更明确了真正好用的 SSH 文件工具不该只是能连上、能上传而是应该把本地、远端、远端和远端之间的工作流真正串起来。SSHFerry 现在还在继续更新但它已经是我自己愿意长期用下去的方向了。如果你也有类似需求欢迎来 GitHub 看看试用一下顺手点个 Star提 issue提建议直接参与改进项目地址https://github.com/lllllllama/SSHFerry