别再用网盘传大文件了，教你搭一个私人“阅后即焚”的文件传输服务

我有个做视频剪辑的朋友，我俩之间传文件简直是日常折磨。一个几GB的素材传来传去，微信、QQ肯定不行，用网盘呢？上传、分享、下载这一套流程走下来，慢得让人抓狂。有时候链接莫名其妙就失效了，更别提心里总犯嘀咕的隐私问题。

最近看到一个 transfer.zip-web 的开源项目，稍微体验了一下,感觉挺不错的!

有了它，你就能给自己搭一个专属的文件传输网页，功能纯粹到极致：拖入文件，生成一个链接或二维码，发给朋友。对方在浏览器里打开，文件就开始点对点（P2P）传输。全程没有登录注册，不限制文件大小，而且是端到端加密的。最妙的是，文件压根不经过我的服务器存储，传完就彻底没了，干净利落。

想先尝尝鲜？官方有体验版

在咱们自己动手之前，你完全可以先去官方的体验网站感受一下。

官方体验地址：https://transfer.zip

你直接打开这个网站，拖个文件进去，把链接发给朋友，就能立刻明白我为什么这么推荐它。

体验过后，如果你和我一样，对数据有掌控欲，不希望任何东西（哪怕是临时的）经过第三方服务器，那么，拥有一个完全属于自己的版本才是最终的归宿。

下面，我就带你走一遍，看看怎么把它部署到自己的服务器上。

动手搭建：用 Docker 快速启动

项目地址: https://github.com/robinkarlberg/transfer.zip-web

假设你已经有了一台自己的服务器，并且装好了 Docker 和 Docker Compose。如果没有，可以快速搜一下教程，现在这基本是服务器的标配了。

登录你的服务器，跟着下面的命令敲就行：

# 1. 从 GitHub 把项目代码弄下来
git clone https://github.com/robinkarlberg/transfer.zip-web.git

# 2. 进入项目目录
cd transfer.zip-web

# 3. 创建一个默认的配置文件
# 这条命令会帮你生成一个 .env 文件，里面是一些基本配置，我们先用默认的
sh ./createenv.sh

# 4. 一键构建并启动！
docker compose build && docker compose up -d

搞定！服务已经跑起来了。因为docker-compose.yml配置中限制了只允许本地IP访问,并且我取消这段配置后,通过IP访问页面会出现报错的问题

所以你还需要配置一个域名代理到本地,可以在服务器上装个nginx,配置一个反向代理,按如下配置即可,这段在官方介绍中也有说明,关于反向代理的配置方式,可以自行搜索一下!

# Put this at the top
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

# Put this in your server-block
# server {
# ...
    location /ws {
        proxy_pass http://localhost:9001/ws;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
    }
# ...
# }

你可以马上试试：

在页面上点击【Upload File】，随便选个文件，越大越能看出效果。
它会立刻生成一个链接和一个二维码。
把链接发给你的朋友（或者自己用手机扫码也行），你会看到页面提示“Waiting for receiver”。
当对方打开链接，文件传输就开始了。进度条会实时滚动，速度基本就取决于你俩的网速。

这体验，是不是比任何网盘都直接？

它到底是怎么工作的？P2P 还是服务器中转？

你可能会好奇，既然不存文件，那它是怎么从我的浏览器跑到朋友的浏览器的？这正是这个项目最聪明的地方，它会根据情况自动选择最佳传输路线。

1. 首选路线：WebRTC 点对点直连

这东西的核心技术是 WebRTC（网页实时通信），说白了，就是让两个浏览器可以直接“对话”。

8ed1c00c-b1c4-418d-b774-0c466aa81d25

当你朋友打开分享链接时，我们刚才搭的服务里的“信令服务器”（Signaling Server）会当一次中间人，帮你们俩的浏览器交换一下网络地址之类的信息，让它们能互相找到对方。一旦“握手”成功，信令服务器就功成身退了，数据直接在你和朋友的浏览器之间飞，不占用你服务器的一丁点带宽。这就是为什么它能传大文件，因为服务器根本不碰数据本身。

2. 后备路线：Relay 服务器中转

当然，现实没那么理想。如果你或你的朋友网络环境比较复杂，比如躲在好几层路由器或者严格的公司防火墙后面，P2P直连可能会失败。

为了保证文件一定能传到，transfer.zip-web 设计了后备方案：Relay（中继）模式。

直连失败时，文件数据会先加密，然后一段一段地发到你的服务器，再由服务器转发给对方。这时候，你的服务器就成了一个临时的“快递中转站”。数据只是流过，并不会被存下来。

一个非常关键的细节：
根据项目的设定，当文件大于10MB时，为了保证传输的稳定和速度，程序会强制走Relay服务器中转模式,可以自行修改代码,处理这一块的限制。这一点一定要知道！这意味着，你用它传大文件时，是会实打实地消耗你服务器的带宽和流量的。

所以，真实的工作模式是：

小文件（<10MB）且网络好：走P2P，几乎不耗服务器流量。
网络不好，或传大文件（>10MB）：走服务器中转，消耗服务器带宽。

用之前，你需要知道的几件事

在你把它当成主力工具前，还有几个小贴士：

链接是“活”的：传输链接和你打开的网页是绑定的。如果你上传了文件然后关了网页，链接就失效了。你必须保持上传页面开着，直到朋友接收完。
真的不存文件：再强调一遍，这不是网盘。它的使命就是“安全送达”，送到了就没它事了，服务器上啥也不留。
上个域名和HTTPS更靠谱：用IP地址访问毕竟不方便也不够安全。我强烈建议你给它配个域名，然后用 Nginx 或 Caddy 这类工具做个反向代理，顺便把免费的HTTPS证书也配上。这能让你的服务看起来更专业，用起来也更安心。
盯着点服务器流量：既然知道了传大文件会吃服务器带宽，那就要对你服务器的流量套餐心里有数。如果你和朋友天天传几十G的东西，那普通的小水管服务器可能就吃不消了。