这是一个创建于 105 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近看到一个 transfer.zip-web 的开源项目，稍微体验了一下,感觉挺不错的! 
在咱们自己动手之前，你完全可以先去官方的体验网站感受一下。
官方体验地址： 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 （网页实时通信），说白了，就是让两个浏览器可以直接“对话”。
当你朋友打开分享链接时，我们刚才搭的服务里的“信令服务器”（ Signaling Server ）会当一次中间人，帮你们俩的浏览器交换一下网络地址之类的信息，让它们能互相找到对方。一旦“握手”成功，信令服务器就功成身退了，数据直接在你和朋友的浏览器之间飞，不占用你服务器的一丁点带宽。这就是为什么它能传大文件，因为服务器根本不碰数据本身。
2. 后备路线：Relay 服务器中转
当然，现实没那么理想。如果你或你的朋友网络环境比较复杂，比如躲在好几层路由器或者严格的公司防火墙后面，P2P 直连可能会失败。
为了保证文件一定能传到，transfer.zip-web 设计了后备方案：Relay （中继）模式。
直连失败时，文件数据会先加密，然后一段一段地发到你的服务器，再由服务器转发给对方。这时候，你的服务器就成了一个临时的“快递中转站”。数据只是流过，并不会被存下来。
一个非常关键的细节： 根据项目的设定，当文件大于 10MB 时，为了保证传输的稳定和速度，程序会强制走 Relay 服务器中转模式,可以自行修改代码,处理这一块的限制。这一点一定要知道！这意味着，你用它传大文件时，是会实打实地消耗你服务器的带宽和流量的。
所以，真实的工作模式是：
- 小文件（<10MB ）且网络好：走 P2P ，几乎不耗服务器流量。
- 网络不好，或传大文件（>10MB ）：走服务器中转，消耗服务器带宽。
用之前，你需要知道的几件事
在你把它当成主力工具前，还有几个小贴士：
- 链接是“活”的：传输链接和你打开的网页是绑定的。如果你上传了文件然后关了网页，链接就失效了。你必须保持上传页面开着，直到朋友接收完。
- 真的不存文件：再强调一遍，这不是网盘。它的使命就是“安全送达”，送到了就没它事了，服务器上啥也不留。
- 上个域名和 HTTPS 更靠谱：用 IP 地址访问毕竟不方便也不够安全。我强烈建议你给它配个域名，然后用 Nginx 或 Caddy 这类工具做个反向代理，顺便把免费的 HTTPS 证书也配上。这能让你的服务看起来更专业，用起来也更安心。
- 盯着点服务器流量：既然知道了传大文件会吃服务器带宽，那就要对你服务器的流量套餐心里有数。如果你和朋友天天传几十 G 的东西，那普通的小水管服务器可能就吃不消了。
23 条回复 2025-06-26 22:16:00 +08:00
 | 1 sadfasdfa 105 天前 via iPhone 大文件传递属于低频率使用的东西，还不如用微信传，超过 1G 分割一下 |
 | 3 duanxianze 105 天前 我本来想说对于大牛，过于简单，对于小白，过于复杂了，然后我又仔细想了想，不管对谁来说，还是不如上传网盘方便快捷啊还免费啊 |
 | 4 JustW OP @duanxianze 网盘考虑的还是下载问题,不过要是有个下载不限速的,那还是挺不错的 |
 | 5 cjpjxjx 105 天前 via Android 小文件走 P2P ，大文件走服务器中转，我的需求正好相反。。。 |
 | 6 gvdlmjwje 105 天前 蛮有用的 |
 | 7 daybreakfangyang 105 天前 via Android 我那点服务带宽，算了吧 |
| 8 duanxianze 105 天前  1 @JustW #4 网盘会员可比服务器费用便宜多了 |
 | 9 clf 105 天前 没事，运营商会限制你上行速度的。真的大到痛苦的文件不如叫个跑腿送 U 盘，或者是快递得了。不是那么痛苦的就用网盘。 |
 | 10 shunia 105 天前 @cjpjxjx #5 对啊，既然要在意服务器流量和“阅后即焚”，不恰恰应该是相反的吗？ 大文件走 P2P 不消耗服务器流量； 小文件存服务器上也无所谓，还不用一直开着网页等对方来下载，只要对方下载完后自动删除就行了； |
 | 12 icy37785 105 天前 via iPhone 小文件 p2p ，大文件服务器中转确实反直觉。虽然我也能理解 webrtc 传大文件没那么理解，而且特别大的文件浏览器有限制。 虽然能理解这些妥协，但是实际问题就是妥协后，会速度以及成本都比如网盘了。 速度受自己上行和服务器下行的限制，几乎是没可能比网盘快了，即使是限速后的网盘。毕竟国内服务器都是带宽太贵，国外服务器不是优化线路的话速度也慢，优化线路的话带宽也贵。 成本的话，如果想提供比网盘限速后更快的速度，需要的服务器的带宽成本是网盘 vip 的若干倍，低成本方案打不过限速后的网盘，高成本的情况打不过网盘的 vip 。 这还只是跟网盘比，真所谓的“阅后即焚”文件传输，谁也不会用网盘，而是会用 qq 之类的 im 工具，那是真的无成本还快。 感觉你这个项目本身功能没问题，但是定位有问题，文案改一下，设计一个只有小文件分发的场景，那就一切合理了。虽然暂时我还没想道特别合适的场景。 |
 | 13 fibroblast 105 天前 我也是考虑这个问题 |
 | 14 tomclancy 105 天前 via iPhone 开局假设我有服务器，我没服务器呢 |
 | 15 dingdangnao 105 天前 开个 oss ，写个网页就传上去了 |
 | 17 Oceanhime 105 天前 教程用 GPT 写的吧。说白了，这就像是算法生成的“星空”璀璨、精确，却少了点人间的烟火气。 |
 | 19 garlics 105 天前 看着还不错，可以代替 pp 直连传文件了，不过相对没那么方便。 |
 | 20 Overfill3641 105 天前 @Rendex 那正好可以教他了，又不是什么复杂事情，装个压缩软件就能解决。 |
 | 21 docx 105 天前 via iPhone 1 我一直用的 copypaste.me ，也是 P2P ，除了传文件，还能传文本，配对也比较方便 |
 | 22 hewitt29 105 天前 大文件点对点用 QQ 不就完了。。费这劲，要的就是小文件方便下载啊。。 |
 | 23 SnowMountain 105 天前 via iPhone 能部署在 Cloudflare Worker 就很棒了 |
Select Language