在网上发送文件到底安全吗？

最近更新: 2026-08-06

「发这份文件安全吗？」是个值得停下来想一想的问题——不管是一份报税单、一份合同，还是几张你希望别人看不到的照片。这篇文章不是要吓唬你远离常用工具，而是想平实地讲清楚：用邮件发文件、把文件丢进云盘文件夹、或者用 U 盘带着走的时候，到底会发生什么；「端到端加密」和「零知识」这两个词到底承诺了什么；以及在把重要的东西交给任何一个工具之前，你该检查什么。

这些都不需要技术背景。读完之后，你会知道该问哪些问题——对任何一种传输方式都适用，包括本文介绍的这一个。

文件真正会出问题的地方：那些日常风险

邮件附件会经过你和收件人各自邮件服务商的服务器，双方都会例行地扫描、索引、备份邮件，用于反垃圾和灾难恢复——在你早已忘掉这封邮件很久之后，它们还留在那里。只要邮件被转发一次，文件就到了你从未打算给的人面前，而你没有办法确认每一份副本都被清除了。

云盘链接很方便，但一个链接通常会一直有效，直到你想起来去撤销它；而「拥有链接的任何人都能打开」有多私密，全看这个 URL 有多难猜——短链接服务或一次不小心的转发，都能让它不再难猜。文件的安全性还会连带取决于它所在的整个账号，而不只是这一次分享本身。

U 盘让人感觉安全，因为它是离线的，但这恰恰是问题所在：大多数 U 盘默认不加密，一旦落在笔记本包里或者租来的车上，捡到的人拿到的就是明文，不需要任何密码。

免费的公开上传网站解决了眼前的问题——把文件从 A 送到 B——但很少说清楚接下来会发生什么：文件会被保留多久、会不会被扫描、谁可能碰巧看到它，以及网站靠什么赚钱（靠广告维持的文件托管站，历史上不乏被曝出捆绑追踪器甚至更糟东西的先例）。

邮件：会被邮件服务器保留和扫描，也很容易被转发到你控制不了的地方
云盘链接：在被撤销之前一直有效，并且继承整个账号的安全性
U 盘：默认不加密，容易丢失或落在某处
免费上传网站：保留和扫描的做法通常并不透明

「端到端加密」和「零知识」到底是什么意思

不少服务说自己「加密」，其实只是指连到它服务器的这段通道是加密的——也就是标准的 HTTPS/TLS，和你网银用的是同一把挂锁图标。这确实能防止有人在网络上偷听，但保护止步于服务器：文件一旦到达，服务本身就能读到它，因为密钥在它手里。很多日常工具正是止步于此。

端到端加密的意思更进一步：文件在离开你的设备之前就已经加密，而这把密钥只有发送方和指定的接收方手里有。承载文件的那个服务——服务器、中继、中间的任何一环——从来没有这把密钥，所以不管被谁要求，它都拿不出明文。

「零知识」是一个相关但略有不同的概念，通常用在「存放」而不是「实时发送」的场景：即便数据静静地躺在服务器上，加密它用的那把密钥也从未交给过服务器本身，所以运营方无论数据放多久，都没有办法读懂它。

单说「加密」，往往只是到服务器为止的 TLS——服务商仍然能读到文件。
「端到端加密」意味着只有发送方和接收方手里有密钥。
「零知识」意味着服务器持有的数据，结构上就无法被它自己解密，哪怕只是静静存着。

信任一个传输工具之前，真正该检查什么

要跑这份核查清单，你需要什么

十分钟和一个浏览器。前两项是阅读，不是审计。
两台设备，用于实时的那几项。第三、第四项没法在营销页面上完成，而这恰恰是它们值得做的原因。
不需要安全专业知识。下面每一项要么是你能读到的东西，要么是你能亲眼看见发生的事。

官网上的营销话术，远不如几个具体问题管用：

到厂商的源码里去找他们自己对「你们能读我的文件吗」的回答，而不是去定价页找。如果根本没有源码，那本身就已经是个回答。
```
https://github.com/relayium/relayium
```
看一下许可证，以及那个仓库是不是真正部署上线的那份东西。一个你能亲自查验的说法，和一个要求你接受的说法，是两种不同的说法。
在一次实时传输中，比对两块屏幕上的校验码。正是这一步，把「端到端加密」从一句话变成了在这两个具体端点之间正在被强制执行的事。
```
https://relayium.com/
```
在那次传输进行时，打开浏览器的开发者工具，看网络面板。在上传的内容里找你自己文件的内容。找不到才是重点；找得到才是结论。
检查事后还剩下什么：链接会不会自己过期，以及如果有人日后要求，服务方还能不能把这个文件重新拿出来。

通过这份清单到底说明了什么

前两项代价很低，几分钟就能筛掉大多数工具。后三项是落地页伪造不了的，因为它们是你在自己那两台设备上亲眼看着发生的事。

这些都不会让一个工具在抽象意义上变得可信。它们做的是让具体的说法变得可核查——在不逐行读完所有代码的前提下，这已经是我们任何人能做到的极限。

它说的是「加密」（可能只是 TLS），还是明确说「端到端加密」（只有发送方和接收方持有密钥）？
有没有办法验证连接没有被篡改——是一段你要亲自核对的校验码，而不只是一个你只能选择相信的挂锁图标？
文件的完整性有没有被校验，好让损坏或被改动过的文件不会悄无声息地「正常」抵达？
代码是不是开源、可审查的，还是这些说法只是你必须单凭信任接受的宣传语？
发送或接收是否要求你交出比这次传输真正需要的更多身份信息？
如果有内容被存放在服务器上，它有没有一个明确、有限的生命周期——比如过期时间，或者阅后即焚——而不是无限期地留在那里？

Relayium 如何回应这些问题

在一次双方同时在线的实时传输中，Relayium 会让每台设备各生成一对全新的 X25519 密钥，再各自推导出同一把只存在于两个浏览器内部的 AES-256-GCM 共享密钥——它从不会发送给 Relayium 自己的服务器。可选的那段简短校验码（SAS）——打开默认关闭的「高级验证」后才会显示——能让双方确认密钥没有被中间不诚实的服务器调包；每个文件的 SHA-256 哈希也会做端到端核对，这样一次损坏的传输不会看起来「一切正常」。想知道这背后具体是怎么运作的，可以接着读《Relayium 如何对文件端到端加密》，那篇讲得更深入。

当接收方还不在线时，存储下载链接采用的是另一套零知识方案：你的浏览器会生成一把随机的 AES-256-GCM 密钥，在任何内容上传之前就用它把文件加密好。这把密钥从不会发给服务器——它只存在于链接的 URL 片段里，也就是 # 号之后、浏览器从不发送的那部分。服务器最终持有的是它无法解密的密文，外加一个由你选择的有效期：1 小时、1 天、3 天、7 天，最长 14 天（上限取决于你的套餐），或者阅后即焚（首次完整下载后即删除）。

跨网络时，Relayium 浏览器端按设计使用 TURN：中继承载端到端加密的密文，但从未拿到密钥，无法读取或解密文件。

这些都不需要你单凭信任去接受：Relayium 的客户端和服务器代码都以 AGPL-3.0 许可证开源，谁都可以阅读和审查，而不必只是相信宣传。

同一网络内的传输完全不需要账号。
跨网络用配对码发送，或者创建一个存储链接，都需要发送方登录——但接收方永远不需要账号。

加密不是全部——有几个习惯依然值得保持

强加密能保护文件在传输中和存放时的安全，但它挡不住你把链接发给了错的人——把分享链接当作文件本身来对待，不要把它公开发到什么地方。

对于真正敏感的内容，请打开高级验证，多花几秒钟，在通话里读出校验码或者当面核对，而不要只是相信两块并排的屏幕不可能同时被骗过。

而且不管加密做得多好，任何传输工具都保护不了一台已被攻破的设备上早已暴露的文件——好的加密假设的前提是两端本身可信。这些都不是让你对发文件这件事草木皆兵的理由，只是值得清楚加密到底覆盖了什么、没覆盖什么。

当某一项给不出干净的答案时

有三个地方容易卡住。而在每一种情形里，这份模糊本身就是有信息量的。

你遇到什么、检查什么、它意味着什么

网络面板里有一大块上传，但你看不出里面是什么。

https://relayium.com/   # developer tools, Network panel, during a transfer

这正是预期结果，不是死胡同。你要找的是「找不到任何能认出来的东西」——你自己起的文件名，或者你知道文档里有的某个字符串。如果你能在上传内容里读出自己的东西，那才是结论，而且是决定性的结论。

没有校验码，所以第三项做不了。

https://relayium.com/   # a stored link has no second live endpoint to compare against

你用的是存储型链接传输，而不是实时传输。这里没有第二个在线端点可供比对，所以保证的形态不同：密钥存在链接的片段部分，根本不会到达服务器。实时传输比对校验码，存储型传输则检查链接过期。

源码是开放的，但你读不懂它用的那门语言。

https://github.com/relayium/relayium   # is the claim falsifiable at all

你不需要读懂。这一项要回答的问题是：这个说法到底可不可证伪——有没有仓库，它是否对应着实际部署的东西，一个读得懂那门语言的人有没有可能站出来反驳它。一个没有任何人有条件去核查的说法，本身就是结论。

常见问题

用邮件发敏感文件安全吗？

邮件并不是为机密文件传输设计的——附件通常会被收发双方的邮件服务器保留、扫描并备份，而一封被转发的邮件可能把文件送到你从未打算给的人面前。发一些无关紧要的文件没问题；涉及敏感内容时，一个具备端到端加密的工具能消除这种暴露。

「零知识」到底是什么意思？

意思是存放你数据的一方，从未拿到过能读懂它的密钥。加密发生在你的设备上、内容上传之前，而密钥只存在于服务器永远看不到的地方——比如 URL 片段——所以服务器上存放的是它结构上就无法解密的密文，而不只是一份「承诺不看」的数据。

给压缩包加个密码是不是就够了？

总比什么都不做强，但这个密码常常和文件走同一条路——比如就在同一封邮件里——这就抵消了保护的作用；而且不同压缩软件实现的加密强度也参差不齐。一个建立在端到端加密之上的工具从根本上不需要共享密码，也就消除了这个薄弱环节。

Relayium 会保留我的文件副本吗？

实时模式下，Relayium 不保留服务器端副本或传输历史：同一局域网内 WebRTC 直连，跨网络浏览器则按设计经 TURN 承载端到端加密的密文，中继无法读取或解密。对于存储链接，服务器只持有它无法读取的密文，直到链接过期；如果你选了「阅后即焚」，则在首次完整下载之后立即删除。

发送或接收文件需要账号吗？

在同一网络内，双方都不需要账号。跨网络用配对码发送，或者创建一个存储链接，需要发送方登录——但无论用哪种方式，接收方都从不需要账号。

想知道一个工具是不是真的做到了它宣称的保护？发起一次传输，打开高级验证，亲眼看看那段校验码和这个零知识链接。

立即试用 Relayium