transfer.sh 介绍与选型指南

transfer.sh 是 Go 编写的命令行文件分享服务，本文覆盖项目定位、核心架构、功能特性、快速开始示例、适用场景与限制，并与 Plik、PicoShare、goploader、PsiTransfer 做同类自托管组件选型对比，全部信息联网溯源并标注查询日期。

transfer.sh文件分享文件传输Go2026/11/01

transfer.sh 介绍与选型指南

‍‍​​‌​> 目标：介绍 transfer.sh——Go 编写的命令行文件分享服务（"Easy and fast file sharing from the command-line"），覆盖项目定位、核心架构、功能特性、最小可用示例与同类自托管组件选型对比。本文为认知与选型篇，全部信息均联网溯源并标注来源与查询日期（2026-11-01），不含本地实测；部署、配置与命令的实测细节见系列后续各篇。

一、环境信息（溯源说明）

本文是认知与选型篇，不含本地实测，以下为溯源对象与信息渠道：

  • 溯源对象：transfer.sh（GitHub 仓库 dutchcoders/transfer.sh）
  • 溯源日期：2026-11-01（本文全部版本号、星数、维护状态、特性清单均在该日联网实查）
  • 信息渠道：GitHub 仓库页 HTML（星数/fork 数/归档状态/license）、GitHub Releases 页与 tags 页（版本与发布日期）、仓库 README（功能特性、用法示例、参数表）、commits atom feed（最近提交记录）
  • 星数取证方式：shields.io stars 徽章 JSON（https://img.shields.io/github/stars/dutchcoders/transfer.sh.json）返回 {"label":"stars","message":"16k",...}，与仓库页 HTML 内嵌数据 stargazerCount:15904 相互印证
  • 系列后续篇章：《transfer.sh 1.6.1 Docker Compose 部署指南》、《transfer.sh 1.6.1 配置参数详解》、《transfer.sh 1.6.1 curl 上传下载命令详解》

二、软件概述

2.1 项目定位

transfer.sh 自我描述为「Easy and fast file sharing from the command-line. This code contains the server with everything you need to create your own instance.」（来源：仓库 README，查询日期 2026-11-01）。它解决的是一个在服务器运维场景中极为高频的需求：两台机器之间快速交换一个文件，而不想架 FTP、不想开 SFTP 账号、也不想传网盘再拷链接。它的全部交互都发生在命令行里——上传是 curl --upload-file，下载是 curl，服务端返回一个可直接下载的 URL，配合管道与脚本可以无缝嵌入自动化流程。

它同时是一个自托管服务端：仓库内包含完整的服务端代码，单二进制即可运行，支持 local（本地磁盘）、s3（Amazon S3 及兼容端点）、gdrive（Google Drive）、storj（Storj 去中心化存储）四种存储后端。项目由 Remco Verhoef（dutchcoders）创建，当前维护者为 Francesca Schicchera（francescayeye）与 Stefan Benten（stefanbenten），采用 MIT 许可证（来源：仓库 README「Creators / Maintainers / Copyright and License」章节，查询日期 2026-11-01）。

💡 技术拓展：命令行文件分享（CLI-first file sharing）这一形态下，客户端方案有两类——

方案原理/特点适用场景
纯 curl 工作流零客户端安装，curl --upload-file 直传，服务器原生自带 curl服务器间临时传文件、脚本/CI 内嵌传输
专用 CLI 客户端项目自带二进制客户端（如 goploader 的 gpldr、Plik 的 plik），体验更细（进度条/剪贴板）固定团队日常使用、需要统一配置

transfer.sh 采用纯 curl 工作流——服务端协议就是普通 HTTP PUT/GET，任何带 curl 的机器即开即用，这是它与同类工具最大的形态差异。

2.2 项目身份与维护状态（2026-11-01 实查）

社区内流传「transfer.sh 仓库已归档停更」的说法，本文以仓库页实查数据为准：

核实项实查结果取证来源
归档状态未归档（仓库页 payload isArchived:false）仓库页 HTML，2026-11-01
星数15904（shields.io 徽章口径 16k）shields.io JSON + 仓库页 HTML，2026-11-01
fork 数1582仓库页 HTML，2026-11-01
watch 数200仓库页 HTML，2026-11-01
许可证MIT仓库页 HTML + LICENSE 文件
最新正式发行版v1.6.1（2023-12-04 打标）GitHub tags/releases 页，2026-11-01
最近提交2026-10-31（维护者 francescayeye 更新 README、Dockerfile、release.yml、新增 SECURITY.md）commits atom feed，2026-11-01

结论：仓库未归档，但 2023-12 之后约三年无正式发行版，处于「低频维护」状态；2026-10-31 维护者恢复了 README 与发布流水线层面的提交，社区活跃度有回暖迹象。选型时应把「发行版更新慢」当作现实约束（详见六、2 小节）。

版本节奏（来源：GitHub Releases/tags 页，查询日期 2026-11-01）：

版本打标日期关键内容
v1.6.12023-12-04修复 v1.6.0 引入的 basic auth 绕过缺陷（IP 白名单场景）；autocert TLS 配置修正；依赖升级
v1.6.02023-11新增 http-auth-htpasswd（htpasswd 文件认证）；aws-sdk-go 升级 v2；Go 1.20 构建
v1.5.02023-03-11gpg 服务端加密支持（X-Encrypt-Password/X-Decrypt-Password）；HTTP Range 断点/范围下载
v1.3.22022ClamAV 病毒预扫描（--perform-clamav-prescan）； Storj 依赖升级
v1.3.12021Max-Days 过大值返回 400；Nix Flake
v1.2.62021-07-06开始随 Releases 提供多平台静态二进制
v1.2.32021-05-01GitHub Actions 发布流水线

三、核心架构

3.1 请求处理模型：PUT 上传、GET 下载

transfer.sh 服务端本质是一个极简的 HTTP 文件网关，协议面只有两个动词（来源：仓库 README「Usage」章节，查询日期 2026-11-01）：

  1. 上传 = HTTP PUT：curl --upload-file ./hello.txt https://transfer.sh/hello.txt——服务端把请求体按字节流落盘（或转发到对象存储），生成「随机短 token + 文件名」的下载路径，并在响应体返回完整下载 URL；
  2. 下载 = HTTP GET：拿到 URL 后 curl https://transfer.sh/<token>/hello.txt 即取回文件；/get/<token>/file 与 /inline/<token>/file 两个别名分别提供「强制下载（Content-Disposition: attachment）」与「内联渲染（按 MIME 直接展示）」两种取回形态。

整个过程没有登录、没有上传表单、没有中间确认页——HTTP 协议本身就是 UI。删除不走专用接口，而是上传时服务端在响应头 X-Url-Delete 里返回一个带删除令牌的 URL，对它发 curl -X DELETE 即可删除文件，令牌不泄露则文件无法被第三方删除。

3.2 存储后端抽象

服务端通过 --provider 参数在四种存储后端间切换（来源：仓库 README「Usage」参数表与 S3/Storj/GDrive 章节，查询日期 2026-11-01）：

💡 技术拓展：transfer.sh 可选的四类存储后端横向对比——

后端--provider 取值数据落在哪关键参数适用场景
本地磁盘local--basedir 指定的目录--basedir、--temp-path单机自托管、内网快传，最简
S3 及兼容s3S3 桶（AWS 或任意兼容端点）--aws-access-key、--bucket、--s3-endpoint、--s3-region数据与计算分离、扩容不改架构
Google DrivegdriveOAuth 授权的云端盘--gdrive-client-json-filepath、--gdrive-local-config-path借用现成云盘额度
Storjstorj去中心化对象网络--storj-access、--storj-bucket无信任中心的加密对象存储

本系列各篇实际采用 local 后端：单二进制 + 单目录即可完整复现全部功能面，也是内网场景的主流选择。

其中 S3 后端通过 --s3-endpoint 支持任意 S3 兼容服务（README 明确注明 MinIO 需要 --s3-path-style 打开路径风格寻址）；local 后端数据全部落在 --basedir 单目录内，配合 --purge-days/--purge-interval 可以做自动过期清理。

3.3 安全与控制机制

transfer.sh 的安全控制面完全由「请求头 + 服务端参数」构成（来源：仓库 README「Request Headers」「Response Headers」与参数表，查询日期 2026-11-01）：

  • 限次限期：上传时带 Max-Downloads: 1 限制下载次数、Max-Days: 1 限制存活天数，到期/超次后自动删除；
  • 上传认证：--http-auth-user/--http-auth-pass（或 --http-auth-htpasswd 文件）启用 HTTP Basic 认证，--http-auth-ip-whitelist 可放行指定 IP 免认证；
  • IP 过滤：--ip-whitelist/--ip-blacklist 控制可访问服务端的源地址；
  • 服务端加密：v1.5.0 起支持 X-Encrypt-Password 请求头，上传内容以 AES-256 在服务端加密落盘，下载时用 X-Decrypt-Password 解密；客户端侧亦可先 GPG 对称加密再上传（README 给出 gpg | curl 管道示例）；
  • 删除令牌：X-Url-Delete 响应头返回带随机令牌的删除 URL，令牌长度由 --random-token-length 控制（下载 token 长度的两倍）；
  • 病毒扫描：--clamav-host/--perform-clamav-prescan 可对接 ClamAV 对上传内容做预扫描。

💡 技术拓展：文件分享场景的两种加密路径对比——

路径原理密钥暴露面适用场景
服务端加密（X-Encrypt-Password）内容以 AES-256 在服务端落盘加密服务端同时见到密文与处理请求，密码经 HTTPS 传输到服务端自托管实例，信任自家服务器、防存储层泄露
客户端加密（GPG 管道）先 gpg --symmetric 加密成密文流再上传服务端只见密文，密码永不出本机跨不可信网络传敏感文件，端到端保密

transfer.sh 两者都支持；README 明确警示 X-Encrypt-Password 只应在自托管实例上使用（不应把密码交给第三方公共服务）。

四、功能特性

以下特性清单逐条溯源自仓库 README（查询日期 2026-11-01）：

  • 纯命令行工作流：上传、下载、删除全由 curl 完成，无需浏览器；
  • 管道友好：cat file | curl --upload-file - https://transfer.sh/file 支持从标准流上传；README 提供 transfer() shell 函数，可把整个目录自动打 zip 上传；
  • 限次限期：Max-Downloads/Max-Days 请求头按文件粒度控制；
  • 删除令牌：X-Url-Delete 响应头，随传随得，curl -X DELETE 即删；
  • 服务端 AES-256 加密（v1.5.0+）：X-Encrypt-Password/X-Decrypt-Password；
  • GPG 端到端加密：官方给出「加密上传 / 下载解密」管道示例；
  • 范围下载（v1.5.0+）：接受 HTTP Range 请求，支持断点续传与部分取回；
  • 直链与内联别名：/get/、/inline/ 路径别名控制取回形态；
  • 多存储后端：local / s3（含 MinIO 等兼容端点）/ gdrive / storj；
  • 自动过期清理：--purge-days/--purge-interval（S3 与 Storj 后端除外）；
  • 上传限速与限流：--max-upload-size（KB）与 --rate-limit（请求/分钟）；
  • ClamAV 病毒预扫描（v1.3.2+）：可要求每个上传先过本地 clamd 扫描；
  • TLS：内建 Let's Encrypt 自动签发（--lets-encrypt-hosts）与自定义证书两条路径；
  • VirusTotal 集成：PUT /file/virustotal 触发在线扫描（需 --virustotal-key）。

五、快速开始（最小可用示例）

本节命令溯源自官方 README（查询日期 2026-11-01），为官方给出的原样示例：

上传一个文件到公共服务实例：

$ curl -v --upload-file ./hello.txt https://transfer.sh/hello.txt

配合管道加密上传（客户端 GPG 对称加密，密钥不出本机）：

$ gpg --armor --symmetric --output - /tmp/hello.txt | curl --upload-file - https://transfer.sh/test.txt

下载并解密：

$ curl https://transfer.sh/1lDau/test.txt | gpg --decrypt --output /tmp/hello.txt

自托管最小启动（官方 README「Docker」章节给出的单行启动，容器化部署的完整 Compose 步骤、数据持久化与参数说明见《transfer.sh 1.6.1 Docker Compose 部署指南》）：

docker run --publish 8080:8080 dutchcoders/transfer.sh:latest-noroot --provider local --basedir /tmp/

⚠️ 注意：README 明确不建议在生产用 latest 标签（可能指向未发布的开发构建），应使用 vx.y.z 或 vx.y.z-noroot 版本标签；-noroot 后缀的镜像以非特权 UID/GID 5000 运行，官方标注为推荐用法。

六、适用场景与限制

6.1 适用场景

  • 服务器间临时传文件：运维最典型场景——没有共享存储、不想开 SFTP，一条 curl 解决；
  • 脚本与 CI/CD 内嵌传输：构建产物、日志、抓包文件随流水线上传，配合 Max-Days 自动过期，不留垃圾；
  • 命令输出快速分享：dmesg | curl --upload-file - https://<host>/dmesg.txt 把排障现场发给同事；
  • 给非技术同事发文件：返回的 URL 在浏览器可直接下载，/get/ 别名强制走下载而非预览；
  • 中等规模自托管分享服务：S3/Storj 后端 + 限流 + 认证 + 病毒扫描的组合可作为团队级对外分享服务底座。

6.2 已知限制与风险

  • 无 Web 上传界面：默认前端页面仅提供下载与（受限的）删除能力，上传必须走命令行——非技术用户自传文件需要指导；README 亦说明仓库不背书任何第三方公共实例，建议自托管；
  • 发行版更新慢：最新正式版 v1.6.1 停留在 2023-12-04（查询日期 2026-11-01），期间仅 2026-10-31 恢复了文档与构建层面提交；依赖的 CVE 修复与新特性需等发行版跟进；
  • 安全告警未随发行版修复：README 顶部保留 SECURITY WARNING 横幅（issue #670）——「IP filter and HTTP auth bypass via unauthenticated X-Forwarded-For header spoofing」：攻击者可通过伪造 X-Forwarded-For 头绕过 IP 白名单与 HTTP 认证（查询日期 2026-11-01，来源：仓库 README 横幅及 issue 链接）。在官方修复发布前，暴露公网的实例应在反向代理层收敛该头（只信任代理自身注入的 X-Forwarded-For，并在网关处丢弃客户端原始值）；
  • 删除令牌即唯一删除凭证：X-Url-Delete 丢失后无法删除文件（服务端无管理接口），运维上需要把删除令牌与下载 URL 一并落日志；
  • gdrive/storj 后端额外依赖 OAuth/Access Grant 配置，内网环境通常无此条件，选型时按需评估。

七、同类选型对比

7.1 量化对比（社区活跃度与版本节奏）

自托管临时文件分享领域可选项众多。下表对比本平台已收录的四个同领域代表项目（星数取自 shields.io stars 徽章 JSON 及各项目仓库页，版本号取自各项目官方 Releases 页与官方 Docker Hub 推送记录；各项目数据的具体查询日期与出处见其对应文档，transfer.sh 为本文 2026-11-01 实查）：

项目语言最新稳定版版本日期GitHub 星数交互形态存储后端
transfer.shGov1.6.12023-12-0415.9k（16k 徽章口径）纯 CLI（curl）local/s3/gdrive/storj
PicoShareGov1.5.42026-05-263.1kWeb UI 为主本地磁盘
PsiTransferNode.jsv2.4.52025~2kWeb UI（bundle 上传）本地磁盘
PlikGo1.4.320241.8kWeb UI + 专用 CLI多后端（含 E2EE）
goploaderGo1.0.22025~301服务端 + CLI 客户端本地磁盘

（PicoShare 3.1k、Plik 1.8k 查询日期 2026-10-30/2026-10-31；PsiTransfer 2k、goploader 301302 查询日期 2026-11-01/2026-10-30；各项目功能口径以官方仓库描述为准，详见 《PicoShare 介绍与选型指南》、《PsiTransfer 2.4.5 介绍与选型指南》、《Plik 介绍与选型指南》、《goploader 1.0.2 介绍与选型指南》。）

关键解读：transfer.sh 的星数（15.9k）是其余四个项目之和的两倍以上，是该领域知名度最高、生态检验最充分的项目；但它的发行版节奏（v1.6.1 停留三年）明显慢于 PicoShare/PsiTransfer 等活跃项目，属于「体量大、迭代慢」的长跑型项目。

7.2 能力矩阵对比

能力transfer.shPlikPicoSharegoploaderPsiTransfer
上传通道curl PUT（无客户端）Web + 专用 CLIWeb UIgpldr CLI / curlWeb UI（多文件 bundle）
限下载次数✅ Max-Downloads 头✅❌✅（一次性）✅（可选）
限存活天数✅ Max-Days 头✅✅（可选过期）✅✅
删除令牌✅ X-Url-Delete✅✅（管理链接）✅✅
服务端加密✅ AES-256（v1.5.0+）❌（客户端 E2EE 可选）❌❌❌
客户端 E2EE✅（GPG 管道）✅❌❌✅（可配）
范围/断点下载✅（v1.5.0+）✅（流式）❌❌✅（流式）
对象存储后端✅ s3/gdrive/storj✅（多后端）❌（本地）❌（本地）❌（本地）
上传认证✅ Basic Auth + htpasswd + IP 白名单✅（admin）访客链接✅（可选）❌（无账号体系）
病毒扫描✅ ClamAV / VirusTotal❌❌❌❌
Web 上传界面❌（仅下载/删除）✅✅✅（可选）✅

（各项目能力口径取自其官方仓库 README 与本站对应文档，整理日期 2026-11-01。）

关键解读：transfer.sh 是唯一同时具备「多对象存储后端 + 上传认证 + 病毒扫描 + 服务端加密」的服务端，能力面在五者中最宽，代价是没有 Web 上传界面；若核心诉求是给非技术用户提供网页传文件，PsiTransfer/PicoShare 更合适；若需要浏览器端上传 + E2EE + 专用 CLI 的组合，Plik 是更对口的候选。

7.3 选型建议

  • 服务器/脚本/CI 场景传文件 → transfer.sh（纯 curl、无依赖、限次限期头随用随给）；
  • 内网团队想给所有人一个网页上传入口 → PsiTransfer 或 PicoShare（Web 上传、零学习成本）；
  • 需要端到端加密与完整客户端体验 → Plik（专用 CLI + E2EE + 流式）；
  • 只想要一个极简的一次性文件投递点 → goploader（一次性下载、体量最小）；
  • 数据必须离开本机（云存储/去中心化） → transfer.sh（s3/gdrive/storj 四后端唯一可选）+ Plik（多后端）二选一。

八、参考链接