防炸教程：如何安全分享资源？ - cenglin123/SteganographierGUI GitHub Wiki

#安全分享

rentry 链接 https://rentry.org/safe_sharing
绅士仓库 https://cangku.moe/archives/215860

前言：这篇教程是做什么的？

自 2024 年 4 月份至今（2024.12.29）这几个月的时间里，我针对安全分享这个问题做了一些研究，并写了不少文章。在此过程中得到了许多网友的协助，综合我自己的经验，贯通仓库已有的各类经验贴，整合网盘方所给出的一些信息，通过几个重要文章的讨论，基本上把资源安全分享这个问题搞得比较明白了。

但是这些内容分散在各个不同的文章里，在加上为了普及安全分享相关知识（就是刷存在感），我的账号有大量的资源投稿，导致新人想要找到这些文章不是很容易。

虽然我的大部分投稿基本都引用了一些我认为重要的文章，某些重点内容也在不同的贴子中反复提及，但是到达知识点的过程仍然显得有些曲折，不利于新人快速查阅和掌握。

鉴于上述原因，正好现在仓库开放了注册，我打算单开一个账号，专门用来发布安全分享相关的内容，并汇总所有贴子的精要内容为一个总贴（All in One），便于读者从通盘的角度来查阅。

非常建议各位打算分享的人先读一遍此文（即便你懂得如何折腾 seedbox、明白如何抗投诉的自建网盘，也依然建议读一下）；如果你只想下载不想分享，大概理解其中的内容也能让你更好地判断资源炸链的原因是什么，帮助分享者安全有效地分享，这也有助于你通过各种方式拿到资源，而不是只会一句“炸了求补”。

这篇文章会显得比较长，但是我会制作目录的超链接，并且也会尽力保证行文逻辑贯通，详略得当，使得本文既可以作为教程系统性学习，也可以当作科普手册临时翻阅。

本文的主要内容如下：

1、2、3 节主要以百度网盘为核心讲解一些资源分享的基础性概念；

4、5 节讲解网盘具体应该如何“防炸”、“防止封号”；

6 节讲解防炸的最终手段：IPFS ，并给出了一个有效的操作示例。

现在看不了可以先收藏，有时间或者遇到问题了再回看。

下面是思维导图格式的目录

以下为正文。

1. 炸链的三大原因：文件名、在线解压、举报

1.1 为什么会炸链？错误的防炸方式

我们使用网盘分享时（比如百度网盘），经常会出现“此链接分享内容可能因为涉及侵权、色情、反动、低俗等信息，无法访问！”，等让人血压升高的情况，更有甚者发出后一个小时以内就会爆，并且还可能会伴随封号等。

这时可能会有各种传统的防爆方案，比如：

改后缀为 ico、jpg、png、mp4 等其他格式，或插入“删”等汉字；
在改后缀的基础上，两层、甚至三层以上的套娃压缩；
在前者基础上，不仅多层，每层还会设置无比复杂的密码，诸如 @763!4..2#/-*@$\ddg/*-*/*--r 等

但是事实证明，以上做法，完全没用，全部木大，该炸还是炸，解压还很麻烦。

这时可能有人会觉得，这肯定是资源被在线解压了，里面的违规文件被百度定位到，进而追查到原压缩包，所以炸了。

于是又会有一些更高级的方案：既然在线解压会炸，那让你不能在线解压不就完了？比如把文件分卷压缩行不行呢？分卷压缩是无法被任何网盘在线解压的。

事实证明也是不行的，该炸还是炸。这种情况在秒传时期大家就应该或多或少的察觉到，分卷的某一个或几个文件会莫名其妙违规无法下载，进而导致资源整个作废。

而且在某些情况下，某些特定资源 (比如小说合集、Fanbox 自购内容合集等) 还会出现地毯式炸链现象。

什么叫地毯式呢？就是不仅贴主的分享会炸，评论区分流传火的链接也会跟着炸。

这时可能有人会说了，那是你没有重新打包，百度网盘会记录文件 MD5 值，一个炸会连着其他所有 MD5 值相同的一起炸。

不错，确实有些情况是这样的，但是一旦出现真正的地毯式炸链，即使重新打包了也照炸不误。通常发出后几个小时内就会炸，一炸就是一片，补档也会跟着炸，补几次炸几次，炸的你没脾气，尸横遍野无一能幸存。例子1 例子2 例子3

遇到这种情况假如头铁继续发百度网盘，那么离封号就不远了，第一次先是禁止分享 30 天，第二次就直接永久。

那么，回到一开头的问题，网盘为什么老是爆？

是百度的审核太厉害了吗？但是基于 AES-256 加密，用复杂密码还加密了文件名的多层压缩包，连知道密码的人解压起来都很费劲，百度的审核是如何在很短的时间内就知道里面有违规文件进而判定违规的呢？这回我们再极端一些，直接使用 Veracrypt 进行加密，然后不给密钥文件，并且换其他小号分享出来。

结果是几个小时后依然提示“文件内容违规”。

这简直太厉害了，看起来百度的技术力强的离谱，可以在没有密钥文件的情况下短短几个小时就直接解密连 FBI 都解密不了的 Veracrypt 加密。

那还能不能更厉害一些呢？也是可以的，这回直接用普通的葫芦娃视频发出来，什么违规内容都没有，这总行了吧？

但是事实证明还是不行，这回连普通的葫芦娃都会提示“文件内容违规，该文件禁止分享”。

本节参考： [技巧分享] 关于评论区地毯式炸链现象的一些测试及初步猜想

1.2 恶意举报：百度网盘的举报漏洞

所以，1.1 节这种地毯式炸链情况，既不是加密手段本身的问题，也不是文件有违规内容被发现了导致的。

那么就只有一种可能了——举报。

百度网盘的审核有一个机制，只要文件在短时间内被不同的账号（或者同账号不同 IP ）举报的总数量达到一定的阈值，不管这个文件有没有问题（即使只是葫芦娃），也会强制一刀切的封禁。

这本来是用来体现用户的自决权的，即如果一个文件的确招致很多用户反感，那就应该被禁止分享以平息事端。

但是这个机制却被某些恶意团体（资源倒卖者）察觉到，并加以开发利用。

具体来说，购入一些百度黑号（百度在早年只需要邮箱就可以注册，因此存在大量不值钱的垃圾黑号），然后再给这些号购买一些代理 IP，用脚本批量调取这些号，让它们对分享的链接轮番进行举报，达到百度网盘的违规阈值，就可以让文件炸链了。

比如说 50 个号 × 20 个代理 IP，就能在一轮脚本循环中搞出 1000 个举报，这个值也差不多是能让账号封号的举报量，成本很低，而且能无限制地使用，一轮不行就多来几轮，总能让你违规/封号。

这种举报是针对具体文件的，哪怕用各种方式加密分享链接，只要倒卖者能获得这个文件，用一个靶子号来分享，然后用大量攻击号自己举报自己，重复上述流程，仍然可以让文件违规。

对于能申诉的隐写文件，则可以放在一个举报池中，每天定时运行计划任务，只要复活就举报。

严格来说，上面这种属于利用了百度网盘审核机制漏洞的攻击行为，不是单纯的举报行为。

而根据最近的一些案例1 案例2，倒卖者会直接举报账号使其封号，这样就可以减少人工处理链接的次数，节约资源，提高效率。

因此，只要百度不改变审核系统机制，在百度云上的举报就是无解的，任何防炸方案都没有太大的意义。

（隐写方案的文件可以申诉，不会像分卷那样无法下载，能够保证保存了的人能够有办法下载，但是对于分享者而言，账号自身扛不住这种举报）。

口语版说明：

倒狗用自动脚本举报，举报有 2 种方式，一种就是直接举报你的链接，这样封号的风险就由你承担了，所以分享能就小号就用小号；

还有一种是转存你的文件到一个靶子号的举报池里面，让靶子号分享然后举报这个靶子号的链接，把文件搞成违规文件，这样你的原分享自然就炸了，也就是说只要倒狗有办法获得这个文件，那就能把它搞成违规文件，让它无法分享乃至于无法下载。

百度补档不要让倒狗发现，要么反爬，或者把标题里的无修、合集等字样去掉，以图片形式放到封面图里，不然可能会被自动化举报。

本节参考：

[技巧分享] 网盘资源分享的几种安全级别、违规、审核与举报原理 [技巧分享] 我都套娃10层压缩了怎么还炸？分卷了都炸？一文(也可能是几文)教你用IPFS傻瓜式防炸！

1.3 错误的传火方式：不反爬以及不改哈希值

根据我们的观察，仓库经常发生因传火导致原分享炸链的现象，具体来说主要有 2 点：

提取码没有反爬导致被爬虫获取到链接，生的伟大死得随机；
文件没有修改哈希值导致【牵连】到原分享文件，造成连锁炸链。

对于这种情况，改变文件哈希值是一种必要的手段。

1.3.1 什么是爬虫以及为什么要反它？

爬虫是一种联网自动运行的脚本程序，如果把互联网比作一张蜘蛛网，爬虫就是在网上的蜘蛛，会根据设定的任务来自动从网上特定的地方下载或者上传内容。

爬虫通常通过关键词匹配的方式来判断是否触发任务，各个社交媒体平台上的水军机器人就是一种爬虫。大家经常用来嘲讽水军的“触发关键词了？”这句话的来历就是此处。

爬虫大多数时候并不用来评论，而是用来下载，下载的内容可以是文本、音频、视频等。下载以后就可以拿来保存或者分析。

这种下载动作形象化的说法是“爬取”，比如说百度这种搜索引擎就是靠百度爬虫不断地爬取网上的内容，收集到百度的数据库里，才能在你搜索时给出答案的（当然，爬取以后怎么处理又是一门学问了，这里不展开）。

那么这和资源分享有什么关系呢？

当然是有的，根据爬虫的上述特点，假如说某个爬虫的任务是根据关键词爬取网盘分享连接，然后自动举报，那么关系就很大了。

为了防止被爬虫自动举报，我们需要反爬。反爬的方法多种多样，比如常见的登录人机验证码就是一种常用的反爬手段，此外还可以用 base64 来重编码连接，或者给分享链接里插入一些其他字符等。

对于资源分享来说，容易被倒卖者举报的内容关键词有大致的规律，比如【无修】、【小说合集】等等，此时也可以避免在标题或者正文中出现这样的字眼，从而不触发爬虫的关键词。

当然有矛必有盾，爬虫自身的反反爬能力也是一直在提升的，很多老式的验证码目前已经不太能阻止爬虫了，而倒卖者也可能根据内容设置新的关键词或者匹配方式。总的来说反爬是需要长期关注的，没有一劳永逸的办法，本文也不推荐完全依赖反爬的方式来防炸，大家做到心里有数即可。

1.3.2 什么是哈希值以及为什么要改哈希值？

哈希值是某个文件通过哈希函数计算得出的一个固定长度的字符串，可以看作是文件的"数字指纹"（磁力链接里的神秘代码就是文件哈希值）。哈希值有很多种格式，常见的有 CRC-32、 MD5、SHA-256 等。

文件不管改名或改后缀都【不会】改变文件的哈希值，因此百度网盘等平台常用哈希值来识别和追踪文件。不过，虽然改名不能改变哈希值，但是改动文件的字节却是有效的，对于任何文件，即使只改变一个字节，其哈希值也会完全不同，从而避免被网盘识别。

所以，我们改哈希值主要有以下四个目的：

防止炸链牵连：当一个百度网盘分享链接被封禁（炸链）时，如果其他人分享了相同哈希值的文件，这些分享也会被连带封禁。而通过改变哈希值，可以避免这种牵连。
避开已知违规文件检测：百度网盘会记录被判定为违规的文件哈希值，一个哈希值被判定违规，那么整个网盘中相同哈希值的文件都会违规。只有改变哈希值才能绕过这种检测。
让传火有意义：传火的目的是对原资源进行分流，假如反而造成原资源炸链，则属于好心办了坏事。
实现补档：当原文件哈希被网盘封禁后，改变文件哈希值可以让文件在网盘系统看来是一个全新的文件，从而可以重新上传和分享。

需要补充的是，改哈希仅对加密打包后的文件有意义，能被 AI 直接扫描的纯文本、图像音视频等不在此列，对于和谐文件，分享前必须加密打包。

关于百度网盘的审核问题，接下来会加以说明。

本节内容参考： [杂谈-技巧分享] 你的传火姿势可能有错！传火前为什么要改哈希？

2. 关于百度网盘的审核系统检测、审核与举报原理

2.1 百度网盘的审核系统是如何检测的？

2.1.1 分享文件的文件名

在开始往下面讲解之前，需要先提一下百度网盘的文件名问题，这里引用这篇幻想次元文章的内容：

网盘已经不存在人工审核这种说法，百度网盘都开始搞网赚了，这破项目是真不挣钱。所以链接炸就只有两种情况开车姿势不对和倒狗举报（打X的为会被识别的名字）

①非法名称识别

MだSたろう.zip（x）/AH-64阿帕奇直升机.png（x）/AI91大佬作品.zip(x）/醉里挑灯看剑.7z（√）

日文以及类似番号的名字，再后面就是类似于资源的文件名。你不管怎么改后缀都是有自己的MD5码的，再怎么改都是压缩文件！这种会被系统优先照顾，如果资源分享点击量超过一天/200这个数量就有可能封禁，最后那种伪造成课件或者其他类型的会被自动过滤（zip有概率会被在线解压出一个文件夹但是7z不会，这是服了百度的代码）。

②文件过大

超过4G这个大小的文件如果分享到达上述这个值也会封禁，原因很简单你影响百度卖他的在线解压服务了，它会默认你是资源合集。

③在线解压

压缩选择分卷压缩即可规避

做好这三个就可以挡住自动检测和小范围举报

2.2.2 账号的监控等级

对于百度的审核系统来说，根据账号的可疑度一共分为 5 个监控等级，其中 1 级就是普通账号，没有可疑的地方，大部分平时冒个泡的用户属于此列；如果 24 小时的分享数超过了 6 个，就会被系统标记，并进入 2 级以上，也就是【可能发布违规内容的账号】，此时系统会开始检查账号分享的内容。（超过 6 个是指发出以后被其他用户开始查看、转存、下载的链接，只创建不发布的链接不算）

因此这里就有个第一个安全对策：【①不要发布当天创建的链接】，而是等 24 小时以后再发布，这样可以避免账号进入标记状态。并且同一个账号 24 小时内最好不要发布超过 6 个链接。

此外，分享时采用非默认文件名也会更容易违规。创建分享链接的时候，百度会记录时间和并检测文件名，这里的检测不仅仅检测文件名有没有敏感词，还会检测文件名是不是默认的，如果文件名不是默认的，就会认为你在记录资源的日期等信息，监控等级自动+1，因此第二个策略就是：【②不要修改默认文件夹名称】。

这是什么意思呢？比如说你在百度网盘里面新建一个文件夹，系统会给一个默认名称类似于【新建文件夹_20250525_133552】，这个文件夹名在系统看来就是默认文件夹名，而假如你修改了这个文件夹的名称或者从本地上传一个自己命名的文件夹，在系统看来就不是默认文件夹名，简单来说，就是系统给的名字才是安全的，不要改动系统默认的文件夹名称。

比如这样的文件名和文件夹结构就会被检测到：

└─20250524-13-219411                                  
│ └─[MMD][无修正][wink]4月28日新作 身分証提示物語 奏渚汐藍[2G] 
│ │ └─twintail-seiran-mmd_720p.mp4           216.33 MB （ ←这个文件是原文件）

而这样就没有问题：

└─新建文件夹_20250525_133552                                     
│ └─20250524-13-219411
│ │ └─微信视频20250524.mp4           226.33 MB （ ←这个文件是隐写文件）

分享最外层的文件夹名称要保持默认，如果要记录信息需要在文件夹的内部进行（题外话：不会有人直接用资源的原名称打包吧？如果是请参考资源分享的几种安全级别的第 1 部分）

然后使用分卷压缩、自解压、隐写等方法防止在线解压，就可以避免系统原因导致的炸链。关于百度炸档机制的更详细内容，后面 @风灵月影宗会发文进行详细的说明，本文只简单带过。

需要记住，上述做法只能应对自动检测，应对不了举报，接下来就来谈谈举报相关的内容。

2.2 百度网盘的举报：两个违规级别

对于百度网盘而言，把一个分享文件举报到违规，其所需的举报有一个基本数量阈值，否则容易出现误操作。
当举报量达到一定的数量以后，就会有审核来查看，这一阶段的审核不一定是人类审核，大概率是 AI 审核，根据文件的类型（文本、图像、视频、音频、压缩包等）分别由不同的专用 AI 模型来检查文件是否有违规内容。

文本类由于可采用关键词匹配或者计算文本哈希的办法，可以在上传之后立刻进行检测。但是对于某些较为隐晦委婉的内容，则需要深度学习模型（比如 LSTM 或者 BERT 、GPT 之类）来处理，后者能更准确地理解语义（包括谐音、拆字、改拼音之类），但是消耗的资源更多，大概率是不能每一个文本文件都用的，从成本角度考虑，用在被分享/举报的文件上更有性价比。

对于图像、音视频类的数据，则大概率直接由深度学习模型处理（比如 ResNet、Yolo、ViT 之类），基于和文本类同样的理由，大概只会应用在被分享的文件上，这就能解释为什么显然违规文件放在网盘没事，但一分享就炸的原因（阿里云是个例外，推测由于阿里是云服务提供商财大气粗，可以对上传的每个音视频文件用一次）。而对于被举报的文件，则应该会更加仔细地检查（比如抽取更多的帧进行图像识别）。

对于压缩包，则会试图扫描其中内容，由于百度云分布式存储机制，使得它没法加载文件系统里同目录的同名文件，因此无法解压分卷压缩包，当然也不能解压未知密码的压缩包文件。当举报量达到“大量”时（下文称为“第一级别”，参考此文章的测试），此时百度网盘会判定这个文件“可疑”，然后禁止此文件的分享。

注意，禁止分享并不意味着文件被锁定了，假如这个文件在网盘里，还是能正常查看和下载的，只是不能分享而已（提示“该文件禁止分享”）。只有举报量远超过“大量”，达到了“海量”的级别（第二级别），这个文件才会被判定为“违规”，然后彻底锁定（提示“文件违规，根据相关法律法规予以屏蔽”）。

百度网盘最终在判定一个可疑文件为第一级别之前，应该还会经过一次复核，对于音视频文件而言，假如内容看起来是正常的，那么就会被当作误报，免于被判定违规（这是隐写文件安全性的来源之一）。但是对于无法的解密的压缩包、加密卷等文件就没那么好运了，出于风险考虑基本上都会被判定为违规。

以上两种级别，不管哪种，对于分享链接来说，其外在表现形式都是炸链。（提示“此链接分享内容可能因为涉及侵权、色情、反动、低俗等信息，无法访问 ”）

2.3 能不能用外网盘？

那么，既然国内的网盘审核如此的严格，我们能不能使用国外的网盘呢？本着这个想法，我在绅士仓库某一个被倒卖者盯上的炸链重灾区 https://cangku.moe/archives/210844 上传了文件进行测试（南加可以看这个 https://www.south-plus.net/read.php?tid-2375356.html 情况类似），这回使用的网盘是 MEGA。
结果出乎我的意料，我用来测试的小号被封号了，理由根据举报，文件包含非法/令人反感的内容。

资源提示违规

分享账号被封禁

如果说直接上传侵害儿童的内容，被举报而封号，那也合乎情理。

但是，测试样本完全是葫芦娃

因此，MEGA 网盘也不安全，看起来 MEGA 网盘似乎也有分享链接收到大量举报就封禁分享链接的机制（哪怕分享内容完全为葫芦娃），相比于百度网盘只是禁止分享链接，MEGA 网盘更加严厉还会顺带封号，并且会根据 IP 地址和设备信息追着封禁其他的号，虽然我们可以进行申诉来解封账号，但是这样一来二去会花费很多时间，如同打官司，综合来看其使用体验还不如百度网盘。

Mega 的申诉流程走了半个月

此外，MediaFire：

https://www.mediafire.com/folder/72v59rojjm5jc

PikPak

Pixeldrain

https://pixeldrain.com/l/i7BgWjYo#item=0

等等，很多传统意义上认为安全的网盘无一例外一一都败下阵来，因为分享这件事对于我们来说，充其量也只是业余时间的消遣；而对于倒卖者团体而言，则是生计攸关的大事，会想尽一切办法举报，即使是诬告。

总的来说，如果依然要用网盘进行分享，那么还是选择国内网盘更好一些。

2.4 目前倒卖者举报能力归纳

小结一下，倒卖者的举报能力可初步归纳如下：

可以用脚本把文件举报到相当于百度网盘封禁等级第二级（“文件违规根据相关法律法规予以屏蔽”），因为是脚本自动化完成，百度网盘上的举报极其难以应对。
可以举报所有国内网盘分享链接（包括但不限于百度、阿里云、天翼云、微云、迅雷盘等）、国外网盘（测试时共计被封禁 8 个小号，皆使用隐写文件+正常 MP4 文件完成，包括但不限于 Mega、Mediafire、Pixeldrain、Pikpak、Gofire、Modsfire 等传统或非传统意义上认为安全的外盘，但是无法处理 IPFS 、BT [5, 7]、自建网盘[6] 等不会因为举报而封禁的分享方式（但是可以举报一部分会受理举报的 IPFS 网关、迅雷/pikpak/115 等磁力离线盘中的资源，以及通过各种手段骗取自建网盘真实信息后举报到云服务商）。
可以举报网盘分享账号本身使之封号，已经证实的有百度、Mega、MediaFire、Gofire、Modsfire、Pikpak 等（百度需要违规次数达到一定数量才可以，不能凭空让人封号，其余外网盘则可以凭空让人封号）

本节参考：

[技巧分享] 网盘资源分享的几种安全级别、违规、审核与举报原理

3. 资源分享的六种安全级别

综合上述内容，我们可以总结以下 6 种安全级别的排名：

(1). 直接上传&分享：真的勇士，总是敢于直面惨淡的人生和淋漓的鲜血，以及炸链、封号等一系列挫折。

(2). 单层/多层压缩包：有密码并加密文件名就能防止网盘扫描压缩包中的内容，一定程度上可以抵抗审查，但是无法防止在线解压（手机端可以在线解压包括 7z 在内的压缩包格式，虽然大于 20 GB 的压缩包无法在线解压，但不建议上传这种大文件）。如果没有密码，那么参考 (1)

(3)-1 单层/多层分卷压缩包：内层为多个分卷加密压缩包（改不改后缀名并无太多影响），外层为多层加密压缩包。由于分卷可以防止在线解压，安全性较 (2) 提高了很多。
(3)-2 自解压格式压缩包：格式为 exe 的压缩包，不需要有解压软件直接执行就可以解压，可以设置密码加密文件名。自解压文件也不能在线解压，安全性与多层分卷压缩包为同一级别。

(4). 其他专有格式的加密文件：包括但不限于 Cryptomator 、VeraCrypt 等专有格式加密文件。相比于较为通用的压缩包，网盘方不太可能搭载能够解密这些专有格式的功能，所以安全性高于前者。不过无法应对大量举报造成的强制违规。

(5). 隐写文件：这里特指 MP4/MKV隐写文件，从加密技术层面来看，隐写文件属于 3 这个级别（隐写文件也不能在线解压，会提示压缩包损坏）。但由于其伪装能力强的特性，不怕强制违规，有申诉的可能。因此安全性高于上述所有。

(6) BT、IPFS、自建网盘：去中心化分享由于无法被举报，所以安全性是顶级，自建网盘也是同理。

总的来说，根据【1. 能否加密】【2. 能否在线解压】【3. 能否被举报】这三个分界点，可以把资源分享方式大致划分为 3 个大的安全级别。

本节参考： [技巧分享] 网盘资源分享的几种安全级别、违规、审核与举报原理

4. 怎么“打包”才防炸？防炸的原理是躲猫猫！

由于本文较长，有可能有人会直接空降到这里找答案，所以本节起了一个类似标题党的名字，而且给打包两个字加上了引号。

我们这里先简单小结一下前文内容。

文件名有敏感词，文件被在线解压、文件遭到举报，这是炸链的三大主要原因；
百度网盘的文件有“禁止分享”和“禁止下载”两个违规级别；
资源分享由低到高有六种安全级别。

可以概括为

三大原因，两个违规，六种级别

接下来，我们正式来说明一下防炸问题。

4.1 百度网盘上的举报是无解的

首先需要明确一点，举报是炸链的最主要原因，一切防炸方案的核心都是防举报。

而如第一节以及本节标题所述，由于百度网盘存在举报漏洞，举报者可以用脚本堆举报数量来强行使链接或者文件违规，或者使账号封号。因此只要百度不修改审核机制，在百度网盘上的举报就是无解的。

如果即使使用了前一节提到的 (3)~(5) 级别的打包方式，百度网盘也依然出现反复炸链的情况，那么此时大概率可以判定是被举报了。并且大文件 ( > 4 GB) 比小文件更容易违规，按百度的说法，大文件被举报默认是黄片。被举报的后果除了炸链，还有可能封号，第一次禁止分享 30 天，第二次直接永久。

看到这里大家最好检查一下自己的重要百度账号有没有分享能被倒卖者看到的永久链接（即使分享的是正常内容），有的话尽量取消掉，因为现在发现倒卖者会翻旧账强行封号。

这种情况下不建议再使用百度，应该考虑 IPFS、BT 这种无法被举报的分享方式。

不过假如依然需要使用百度等网盘分享，就需要考虑一些曲线救国的方式，比如和倒卖者躲猫猫。接下来在 4.2 节详细说明这个问题。

在说明前，请大家先记住一句话：

自然界最好的防御不是叠甲而是伪装。

4.2 基于隐写的“防炸”方案 (2024-12-28 版)

根据对倒卖者举报行为规律的长期观察，目前我们倾向于认为其技术路线如下：

倒卖者平时会使用爬虫自动监视指定投稿下方的新增评论，然后解析其中含有百度云分享链接的内容并转存文件进入举报池账号，然后运行举报爬虫依次攻击举报池中的文件以及原分享链接。对于爬虫获取出现错误的情况，则会转由人工进行处理。

放入举报池的文件，失效超过一定时间，就会被移出举报池给其他文件腾地方。

确定这个具体时间对于我们是很有用的，因为隐写文件是可以申诉的，这意味着我们可以找到最合适的申诉时间——即在倒卖者把文件移出举报池以后，就是我们可以申诉的时候了。申诉解封文件以后，就可以再次创建分享而不必重新上传。

4.2.1 百度云申诉操作流程

这里我们强调一下倒卖者存在性判据：

1-隐写文件炸链 2-炸链后可成功申诉

隐写文件炸链说明存在大量举报，文件可成功申诉说明网盘不知情。

只要满足上述 2 个条件，不需要等待申诉成功的文件二次炸链，或者观察其他评论是否炸链，在文件申诉成功的那个时刻，即可判定必然是倒卖者所为。

申诉流程如下：

看到反馈成功这四个字，即说明申诉成功了

因此，假如要使用百度云进行分享，面对倒卖者我们可以采取如下应对手段：

首先通过判据证实倒卖者的存在：隐写文件炸链后申诉成功。
确定倒卖者以后，分享使用文件夹进行，如有需要便于进行换源操作，申诉时文件和文件夹需要分开申诉。
文件炸链后等待数日，然后采用尝试分享的方式申诉文件，申诉成功后不急着分享，先观察文件一天，一天后再次检查文件是否违规，如果没有违规则说明已经被移出了举报池，否则需要继续等待。
确认文件已被移出举报池后即可申诉文件夹分享链接，恢复链接可用性。申诉时不能改动链接里面的内容，比如改名或者移走文件夹中的文件，由于前后内容不一致，审核无法确认内容，会导致一直卡在审核的阶段，这样等同于申诉失败。

这样可以在不重新分享的情况下保住原本的链接，让倒卖者注意不到（也可以在申诉成功后悄悄换源，这样即使文件没有被倒卖者移出举报池也不会影响分享链接的二次存活，换源可以使用隐写者的哈希修改器工具修改文件的哈希值后再上传，不必重新隐写）。

需要说明的是，文件可以多次通过尝试分享的方式进行申诉，但是分享链接只有一次申诉机会，如果二次炸链，就需要重新分享了。

4.2.2 提取码的反爬处理

躲猫猫虽然能降低倒卖者手动举报概率，但仍有可能被倒卖者的爬虫扫描到，所以链接的提取码必须要有反爬措施，让爬虫无法注意到链接以及提取码的出现

基于文字识别+逻辑推理的验证码是比较有效的办法。

我在新版的隐写者软件中提供了快速创建并复制验证码的工具模块，可以使用这个工具创建具有反爬效果的验证码作为提取码，详情见图。

我们生成 2 组验证码，然后可以说：

【提取码为下列图片中第一个验证码的后半部分与第二个验证码的前半部分的组合，请倒着输入】

也可以生成一排验证码然后选择其中的一个或一部分：

如上图，此时可以说：【请输入红色验证码的中间四位】（答案为【EIGS】），或者【请输入每个验证码的第一位字符组成 4 位提取码】（答案为【TCPL】）

以上只是示例，更多的逻辑反爬方式大家感兴趣可以自己探索，只需要思考人类容易完成，机器难以完成的方式即可。

像这样对于人类容易理解的问题，对于目前即使是多模态的模型都是很困难的。

对于纯视觉模型来说，最多可以识别出验证码的内容，但是无法进行逻辑推理，自然无法找到正确的答案；

而对于多模态大语言模型来说，可以进行逻辑推理，但目前大多数拼接多模态模型是很难识别正确的。

目前的原生多模态模型（自称）不多，GPT-4o 和 Claude 各算一个，但目前实际测试下来不管是 GPT-4o 还是 Claude-3.5 ，都无法准确得到答案，这两个不行，其他的模型也就不用看了，退一步说，即使今后有些 SOTA 模型能够实现这样的功能，由于任务包含了多模态图片文本识别理解，其成本也会变得不可控，这种反爬方法在今后可以预见的一段时间内应该都是有效的。

4.2.3 链接的反爬处理

除了提取码以外，链接本身也要反爬，因为如果爬虫检测到链接却无法访问，就会给倒卖者“通风报信”，这样就会让对方注意到提取码进行了反爬处理，此时对方会手动举报。

(1) 插字法

传统的链接反爬主要是插字法，比如给百度链接插入无关的汉字：

ht为tps://pa海n.bai绵du.co宝m/s/1e9YTAyr宝8gOPCqOSx8KoR8g?pwd=wp79

此资源为海绵宝宝

不过这种反爬手法现在已经基本无效了，因为只需要正则一下去除汉字即可。

(2) 截断法

还有一种手法是截断法，就是只取链接的后半部分，使得爬虫无法识别到链接的关键词：

度链
1e9YTAyr8gOPCqOSx8KoR8g
wp79

其中提取码也可以同步进行反爬处理，这种手法需要大家明白百度链接的结构。

不过上面 2 种情况都只是简单修改避免触发爬虫，并没有真正意义上隐藏链接，对方只需要多加一个匹配逻辑或者用大语言模型 API 赋能爬虫就可以破解，想要避免被爬，需要真正隐藏链接的存在，接下来讲几个隐藏链接的方法。

(3) 加密法

通过类似于萌研社的熊曰等加密方法，把链接转换为加密后的字符

http://hi.pcmoe.net/index.html

加密前

https://pan.baidu.com/s/1e9YTAyr8gOPCqOSx8KoR8g?pwd=wp79

加密后

熊曰：呋食食雜嗄盜覺吃取註啽現嘿你動果森物喜歡噗洞嘿嗒噤樣麼森嗚襲吖果森家爾啽擊擊歡嗷覺呱森笨沒你類破嚁現嗒肉破哈擊呦非呱蜂吃你物咬嚄萌洞擊嗄襲呱物人你

加密后需要到同界面下面输入密文，点击【领悟熊所言的真谛 ↑↑】，才能解密还原链接。除了熊曰以外，同界面还有佛曰、兽音、颜文等其他闭源加密方法，大家都可以使用。

注意：

不要使用 Base64 这种比较通用的编码方法，因为过于常见很可能已经加入了爬虫的尝试逻辑中，建议使用熊曰这种闭源的加密方法；
此外也不要使用 MD5、SHA1 等哈希算法，因为哈希算法是单向的不可逆，不能还原链接。

除了熊曰还有魔曰 (Abracadabra) 这样的开源项目，可以进行仿文言文风格的加密，进一步降低可疑度，支持自定义密码

也可以在这个网址进行可自定义密码的 AES 加密： https://bafkreigh3txpz6f4umsu35crfb4i4w5peyogebq56hod6ghnwzcui7zpoe.ipfs.dweb.link

(4) 二维码法

还有一种办法就是把链接转换为二维码，或者在百度分享时使用二维码链接，这种链接用爬虫脚本的难度较大。

如下图所示

因此上述这种链接必须由人工才能完成举报。

在尽量不影响下载者获取资源，不较多增加分享传火者操作成本的情况下增加倒卖者的举报成本，就是对抗倒卖者最直接有效的手段。

小结一下：

必须用隐写文件**，这意味着可以申诉，拥有可操作的空间，通过申诉保住链接然后悄悄换源，加密链接或者采用二维码的方式分享

提取码和分享链接应进行反爬处理，逼迫倒卖者必须人工处理链接，增加其成本；

避免使用容易触发脚本的关键词，如“无修”、“小说合集”等，可以用图片文字的形式放在封面中；补档不要在评论区发新评论引起倒卖者的注意

本节内容参考 [技巧分享] 如何应对恶意举报 - 百度云篇 - 其一资源防炸链解决方案倡议(https://cangku.moe/archives/212735) [工具分享] 隐写者：把资源嵌入MP4文件的隐写工具

4.3 其他网盘的抗举报能力

虽然前文也提到只要是网盘就能被举报，但是不同网盘的抗举报能力还是不尽相同的，这里给出几个建议使用的网盘。

4.3.1 Pikpak/迅雷

如 2.2 节所述，Pikpak 可以被举报，但是在审核层面这个网盘确实比较宽松，迄今为止没有发现脚本举报的迹象。对于 BT 离线的适配性强，不足之处是需要搭配一个大流量的梯子。

此外，这两个网盘之所以能够被推荐，是因为它们依靠了 BT 这个分享体系，可以采取做种并离线到云盘的方式让 pikpak/迅雷代为保存资源，从而能把磁链当成秒传链接来用，撤种后也能长久保持资源的可用性。下载时只需要使用云下载/离线下载功能即可立即获得资源，这称为“秒离”。（注意百度网盘的离线下载功能不能秒离）

关于 BT 相关的内容会在后面的章节进行讲解，这里只简要带过。因为 BT 的磁力链接并不专属于 pikpak 或者迅雷，所以在仅使用磁力链接分享的情况下，并没有办法判断资源保存在 pikpak 还是迅雷，所以也就难以针对性的举报，因此带来了安全性。

4.3.2 阿里云盘

阿里云盘只能使用自解压文件或者隐写文件分享，但是类似于百度，对空间给的比较慷慨，免费账号最低也有 100 GB 的免费空间。在使用隐写文件分享的情况下，性价比尚可。

4.3.3 123 网盘

这个网盘有 webdav 对第三方支持，对于愿意折腾自建网盘的人来说还是比较推荐。

4.4 不建议使用的网盘

4.4.1 夸克网盘

夸克网盘目前在南+已经被禁用，据说是因为这个网盘分享的返佣比较高，导致某些分享者为了争夺返佣而互相举报，导致分享环境恶化。

夸克网盘的审核机制也类似于百度网盘，能够被脚本自动化举报，而且只要被大量举报就会导致链接自动违规，极端情况下，即使分享的只是空文件夹，也会违规，整个过程除了分享者就没有活人参与。

夸克类似于阿里云盘，已违规的链接不能申诉，这点又不如百度网盘，可以说是集两家之短。（不过只是链接违规，文件不会违规，还是可以重新分享的）

下面是空文件夹被举报到违规的情况

此外，有充分的证据表明，倒卖者在使用爬虫等自动化脚本持续监控指定关键词的投稿、评论区的内容，只要内容发生改变（diff）就会自动检查并上报，然后交由举报爬虫予以定向攻击。（关于爬虫如果不理解可以看看 1.3.1 节）

因此夸克网盘和百度网盘一样，任何形式的分享都可以被强行违规，不建议使用夸克进行分享。

本部分暂且说这么多，其余网盘后续如果有可靠信息也会补充。也可以翻阅仓库投稿须知或南+投稿须知的来了解其他网盘。

5. 怎么“防止封号”？能用小号就用小号！

由于本文较长，有可能有人会直接空降到这里找答案，所以本节也起了一个类似标题党的名字，而且给“防止封号”加上了引号。

我们这里先简单小结一下前文内容。

文件名有敏感词，文件被在线解压、文件遭到举报，这是炸链的三大主要原因；
百度网盘的文件有“禁止分享”和“禁止下载”两个违规级别；
资源分享由低到高有六种安全级别。

可以总结为

三大原因，两个违规，六种级别

接下来，我们正式来说明一下如何防止封号这个问题。

5.1 网盘大号传小号分享

据 1.2 节以及 4.1 节，我们已经知道百度网盘上应对恶意举报非常困难，需要考虑止损问题。

根据仓库 2020 年的这篇文章（也是秒传时代的开端）：

关于百度近日封号的相关措施

假如还要使用百度网盘进行分享，为了防止大号被封号造成损失，强烈建议采用大号上传，把资源传给小号，然后小号创建分享链接的方式进行分享。

但是假如采用创建分享链接发给小号或者发给网盘好友的方式来传给小号，数量一多就显得很麻烦。如下图所示：

那么有没有更简单方便的办法呢？

当然是有的，就是采用安卓模拟器（比如 MuMu 模拟器、雷电模拟器之类）安装移动端的百度网盘，然后创建共享文件夹群组，把所有小号都拉进来，这样大号只管上传文件，上传完毕后会自动同步给小号，小号只需要转存一下即可分享。

百度网盘的移动端相比于 PC 端多了很多功能，能看到更多的细节，个人比较推荐。安装模拟器后，把下面的 apk 文件拖入模拟器即可安装，安装完成后登录即可。

百度网盘 v 12.15.7 版. Apk

https://gw.crustgw.work/ipfs/bafybeihsvkz5nsq2x47bsamhye6vbirhnybkhi4nhgoxhj6it57u5mx5ri?filename=BaiduNetdisk_v12.15.7.apk

小号可以在淘宝购买手机卡注册获取，或者采用其他可行的途径也可以，这里大家自己想办法，我就不过多展开了。

看到这里大家最好先检查一下自己的重要百度账号有没有分享能被倒卖者看到的永久链接（即使分享的是正常内容），有的话尽量取消掉，因为现在发现倒卖者会翻旧账强行封号。

接下来说明创建共享文件夹的具体步骤：

5.1.1 大号的操作

点击共享-选择现有的文件夹共享

然后选择要共享的小号

5.1.2 小号的操作

创建完毕后用模拟器登录小号（可以使用模拟器的多开功能打开多个小号），在共享页面点击加入，然后即可同步查看共享文件夹

选中大号上传的文件，点击【保存到网盘】，即可快速转存，后面的分享流程就和普通分享一样了

移动端的有效期和提取码都可以记住上次的操作，这样一来就可以解决 PC 端每次都要手动调整 365 天到永久有效的问题。

复制的结果如下

通过百度网盘分享的文件：2024-06-29…
链接:https://pan.baidu.com/s/1QTIgEbhr31og3flpmR7Srw 
提取码:4417
复制这段内容打开「百度网盘APP 即可获取」

接下来每次大号上传文件到共享文件夹，都会自动同步到小号。因为是小范围分享，即使文件夹里有违规文件也没有关系，但是千万注意文件名不要有敏感词，否则会炸群，需要重新创建共享。

最后，百度网盘的移动端相比于 PC 端能看见更多的细节，对于炸链的文件在分享页面能看到具体是什么文件，而不是只显示一个【分享已失效】，并且也能更容易的进行申诉。

以上内容参考：

[技巧分享] 百度网盘大号传小号分享的操作方法资源安全分享方案(https://cangku.moe/archives/214440)

5.2 百度网盘的账号封禁机制说明

在 4.2.1 节中我们讨论了百度云上的恶意举报存在性证明、尝试分析了倒卖者的举报原理细节，并讨论了基于隐写的申诉方案。在本节中我们将结合百度官方的一些信息，尝试继续讨论百度云上的恶意举报问题。

此前，有几个投稿发生了地毯式炸链现象，根据行事风格极大可能是倒卖者所为。但是和以往不一样的是，此次情况引起了百度官方的注意，在百度官方对事件进行处理时所透露出来的一些信息，让我们有机会更加深入地了解百度网盘的一些机制，并且首次通过百度官方确认了恶意举报者在百度网盘上存在这一事实。

此外，也顺带证实了倒卖者的举报手法的确是通过脚本调用大量机器人账号举报的办法，并可以根据倒卖者账号数量推断出普通文件的举报违规阈值是 100 左右。

接下来，就某些具体的问题，详细展开一下内容。

5.2.1 秒传失效的原理，二种哈希值

根据百度官方所透露的一些信息，我们可以认为百度网盘除了使用 SHA-256 、MD5 这样的文件唯一性哈希，也会使用文件相似度哈希，文件在上传时除了文件本身的唯一性哈希值，还有一个单独的加密过的相似度哈希值，后者的作用主要有 2 个：(1). 统一监管类似文件 (2). 封禁秒传&防止恶意攻击。

第二种哈希就是秒传链接失效的根本原因，因为秒传链接生成器算不出这个哈希值。这个哈希值的目的并不只是封禁秒传，还有安全性方面的作用，使得用户只能秒传自己上传过的文件，防止恶意攻击。

当一个文件被举报违规以后，与其哈希值完全相同的文件会全网盘封禁，与之类似的哈希则会进入监控名单统一监管。被监管的文件相比于普通文件更容易违规（只需要 40-50 个举报就会违规）。

5.2.2 账号监控机制&压制性举报、自动违规

以 15 天为一个周期，当账号及其分享链接被大量举报后，会进入重点监控状态，此时当查转下数量稍高，即使文件不被举报，也不管文件有没有违规信息，都会直接判定文件违规（相同查转下的情况下大文件更容易违规），

【2025-01-09新增：百度近期将账号监控机制改为炸链累计值，累计值重新计数的时长暂不明确，假如发生连续炸链，建议暂时停止用百度分享】

因此，倒卖者的举报除了针对分享链接以外，还可以针对分享账号本身，只需要保持对某个账号每日举报一定的数量，就可以让此账号的分享自动违规，而不需要一一举报分享链接。更进一步，假如直接让账号封号 2 次，第二次封号将会永久禁止分享功能，这种情况下账号的所有分享都会炸。

以我自己为例，根据我从百度处了解到的信息，我的某个账号平均每天会被举报近 1000 次，在这样对账号的压制性举报下，就会出现分享大量自动违规的情况（如下图），需要强调，隐写并不能彻底防止炸链，但是其可申诉的特性可以进行更多的操作，并且也让保存了的人有办法下载。不过对于反复违规的链接，在其某一次恢复正常后，还是建议取消分享并换源。这样通过减少违规量的办法，可以降低封号的风险。

需要说明的是，被举报的账号自身是无法申诉的，大概率会申诉失败或石沉大海，如果需要进行申诉的话，需要另找一个没有被举报过的号来申诉文件，所以假如要申诉，最好大号把资源传给小号分享，然后大号来负责申诉，并且注意不要暴露该账号，避免该账号也被举报压制。

对于这种情况，有一种权宜之计，就是分享采用文件夹进行，并且下载者不能点开文件夹，需要直接下载整个文件夹或者转存后下载，只要下载者不直接看到文件，就不会触发这种类型的自动违规（提示该文件禁止分享，刷新后显示分享暂时不可访问，而不是涉嫌色情、侵权这样的提示），但注意假如文件真的违规了是没用的，点开链接就会直接炸链。

本段中百度官方相关信息，特别感谢 @卑鄙的外乡人 https://cangku.moe/user/191611/post

本节内容参考 [技巧分享] 如何应对恶意举报 - 百度云篇 - 其二资源安全分享方案倡议(https://cangku.moe/archives/213855)

6. 应对恶意举报的有效解决方案：去中心化

小结一下，前一节中我们尝试结合百度官方给出的信息，讨论了秒传失效的原理、百度网盘的账号监控机制，以及账号压制性举报造成的自动违规，及其应对方法。

但是，不管哪种中心化的网盘，说到底都无法完全的应对倒卖者的举报，对于倒卖者来说，只要能够找到举报的途径，那么就一定会举报。因此在传统网盘领域，并不存在完美的防炸方案。

6.1 究竟应该如何才能防止恶意举报？

那么，前面说了这么多网盘的不是，究竟应该如何真正意义上防止举报呢？

答案就是人人为我，我为人人的去中心化方案。

去中心化的分享由于不存在中央节点，即使某个节点被举报或者攻击，只要在网络中还有备份，就依然可以下载。非常适合用来应对恶意举报。

去中心化方案其实有不少，不过目前具有推广可行性的方案只有 2 个：

BT ：受众最多的传统 P2P 分享方案，分享形式通常为磁链、种子等；
IPFS：星际文件系统，作为 web3 的基础，在 BT 的基础上进行了很多改进的方案。

6.1.1 BT

BT 大部分人应该很熟悉了，各种新番、爱情动作片，版权电影电视剧等基本都是通过它发布的，各大字幕组可以不用网盘，但是必须得有 BT 种子、磁链。这么多年一直深受信赖，甚至有句话叫“BT 永流传”，从这点就可以体会到它的力量。

在 BT 网络中，下载者下完以后还会把资源开启上传模式（称为做种），下一个下载的人来的时候，除了从原发布者那里下载以外，还可以从上一个人那里拿到资源，这样一来下载的人越多整体效率就越高，速度也越快。

BT 下载正符合“人人为我，我为人人”的互联网精神。

但是 BT 也有其缺点，首先要求所有人都做种是不现实的，因为大部分人的硬盘空间有限，不可能都拿来做种；另外，假如做种者因为各种原因没有开机做种，或者资源比较冷门没人做种，那就没法下载了（俗称死种）。

因此，磁力资源最终还是逐渐地趋于中心化，大家还是会选择迅雷、pikpak 等可以长期保存文件的磁力云盘。

说到迅雷，一个不能不说的就是迅雷的 BT 吸血行为，所谓吸血，就是指在 BT 网络中只下载不上传的行为，类似于水蛭贴在动物身上吸血，损人肥己，因此而得名。

但是看一个事物需要从两面看，尽管迅雷存在吸血的行为，但不可否认的是，迅雷仍然保存了很多老种、死种。并且可以采取做种并离线到迅雷云盘的方式让迅雷代为保存资源，从而能把磁链当成秒传链接来用，撤种后也能 24 小时保持资源的可用性。

在其他 BT 方法本身都没办法好好下载的情况下，强行要求大家不用迅雷是不现实的（Pikpak 大同小异）。

不过，BT 并非不能恶意举报，刚才提到的离线下载就是如此，因为资源保存在迅雷的云盘，如果给迅雷写小作文，也是有可能导致资源违规无法下载的。

小结一下 BT 的优缺点。

去中心化分享：BT 基于点对点技术，资源分布在多个用户端，理论上无法被举报或封禁。但是前提是需要持续做种，而强制要求所有用户做种是不现实的。
资源越多，下载越快：在 BT 网络中，下载的人数越多，整体下载效率越高，下载速度也会越快，充分体现了“人人为我，我为人人”的共享精神。
资源存续性有限：BT 网络依赖用户的自愿做种，缺乏持续做种的资源会死种，导致无法下载。离线下载可以解决这个问题，但资源存储在云盘中，容易受到恶意举报，导致资源无法下载。

此外，BT 还有一个隐患，因为传递资源时文件信息和 IP 地址都是暴露的，短时间分发还好，长时间做种容易导致安全性方面的问题（通俗说就是可能被请喝茶）。

6.1.2 IPFS

那么，上面 BT 的问题就没有办法解决了吗？答案是有的，就是接下来要讲的 IPFS 了，也是本文标题中所推荐的目前最有效也最值得推广的防炸方案。

IPFS 全称（InterPlanetary File System ）星际文件系统，在 BT 的基础上进行了很大的改进，使得它在拥有 BT 优点的情况下，弥补了很多 BT 的缺点。

首先，IPFS 的去中心化程度比 BT 更加彻底，在 BT 中还存在 Tracker 服务器的概念，也就是用来帮助寻找其他做种中节点的服务器，这些服务器容易被攻击或者封禁。

而 IPFS 则完全依靠 DHT（分布式哈希表）来进行点对点的查找，所有节点之间都是平等的，不需要 Tracker 服务器。

其次，就像刚才提到的，IPFS 是一种和 web3 关联紧密的技术，甚至称之为基石也不为过。关于 web3 可能有朋友不太了解，我说几个关键词：区块链、加密货币、挖矿，是不是就耳熟了？

而在这三个词里面，挖矿的“矿工”，正是使得 IPFS 能够突破传统 BT 做种难问题的关键。

提起挖矿，大家可能第一时间想到的是比特币，比特币需要消耗大量的计算资源才能挖出来；但是 IPFS 挖矿并不需要，因为 IPFS 所对应的加密货币，其对应的是“存储”这个概念。

是的，所有加密货币都有一个对应的概念，也称共识机制，由于加密货币是运行在去中心化的区块链上的，区块链是一个流水账本，负责记录交易信息，区块链人手一本，所以单个节点无法篡改交易记录，否则跟别人的帐对不上别人就不认你，而正因为人手一本，因此需要一个机制来让大家对区块链的运行达成共识。（除非你能掌握整个区块链超过 50% 以上的节点来强行投票，但这几乎不可能）

最有名的共识机制是“工作量证明机制”，也就是谁工作量多谁就能取得区块链记账的资格、也就挖到了矿，获得加密货币的奖励。比特币是“计算”，只有做到了足够多的“计算工作量”才能挖出“计算”概念的加密货币；而 IPFS 相关加密货币，则需要矿工做到足够多的“存储工作量”才能挖出“存储”概念的加密货币。

具体到场景，就是矿工需要帮用户存储文件，存的越多，就赚的越多。

这有什么意义呢？

这意味着，网络中会有一部分专门存储他人文件的矿工节点，这些矿工节点针对存储进行了特化，他们的硬盘空间以 PB 级别计算（1PB=1024TB），只要你支付加密货币给他们，他们就会帮你存文件。存文件和网盘的逻辑一样，拿钱办事。

不过不同的是，网盘是下载者付费，而 IPFS 正好反过来，上传者存文件付费，而下载者免费。而且价格相比网盘来说低得多，因为矿工挖矿本身就可以获得收入，能抵消一部分成本，矿工也不止从一个人那里收费。

以 CrustNetwork 为例，这是一个矿工与存储用户的交易平台，由于矿工可以获得收入，所以相比于传统中心化网盘，IPFS 存储价格会更低（根据官网，存储价格 $ 0.00331 /GB/Year，即 1TB 每年 $ 3.389，按最近汇率约 24.04 CNY ，相比之下百度网盘 svip 一年 5TB 容量连续包年优惠价格￥263，则 1TB = 52.6 CNY），当然价格可能会随币价波动，但是由于 IPFS 是按量付费，总的来说比百度要划算一些。

因为文件存储是和矿工的收入挂钩的，所以矿工做种的积极性会很高。

这样通过加密货币激励矿工托管的方式，就制度性地解决了 BT 中保种难的问题。矿工属于个人，并没有义务理会任何举报。因为 IPFS 是去中心化的，文件分布式地保存在很多不同的矿工手中，就算找到了对方也未必会理你。并且想要找全哪些矿工保存了文件本身就是个很大的工程，因为文件不一定只保存在 Crust 矿工那里，可以保存在任何能托管的地方。

按目前已经知道的例子，至少西班牙政府这种级别的实体没有办法彻底封禁 IPFS 网络。对于普通的倒卖者团体来说，这更是不可能完成的任务。

IPFS 分享在方便性程度上也大于 BT，BT 需要软件才能下载，而 IPFS 对于下载者而言，直接打开分享者发布的网关直链，用 IDM、FDM 等下载软件，或者直接用浏览器的下载功能即可下载。

可以试试点击下面的链接下载 IPFS 分享助手（打不开多刷新几次，第5节会提到如何生成这样的链接）：

https://k51qzi5uqu5dh1ts2qvcw3069src00zyjw0qmwdkb102k8q4ft8bztw75iwi25.eth.sucks

最后是安全性方面，相比于 BT ，IPFS 有网络层面的加密，并且做种内容的人是矿工，不是发布者，即使被追踪，找到的也是矿工，不会找到发布者。

小结一下， IPFS 通过加密货币激励矿工托管的方式，解决了 BT 中的三大痛点：

1. 保种问题

2. 离线资源防举报问题

3. 分享者安全性问题

6.2 为什么 IPFS 无法举报？

6.2.1 图解 IPFS 和网盘、BT 的分享原理异同

这里提一下用 IPFS 分享的原理，由于大部分人只用过网盘，可能有人会觉得 IPFS 的分享方式有些莫名其妙，怎么有些教程里一开始说下载 IPFS 客户端，实际使用时怎么又冒出来什么酸奶网盘，什么 IPFS 分享助手？我分享一个文件咋还要下三个程序？到底哪个才是 IPFS 的 “网盘”？为什么要搞那么复杂？

其实并不是教程故意要弄得很复杂，而是 IPFS 分享文件的原理和传统的网盘是不同的，如果拿大家熟悉的网盘举例，IPFS 类似于百度网盘秒传链接的分享方式，CID 就是“秒传链接”；如果大家用过 BT 的话，也可以说 IPFS 类似于 BT，CID 就是“磁力链接”。但是不管怎么打比方，毕竟还是不同的概念，总会有微妙的差别，大家各自对于资源分享这个过程有各自的理解，这就造成了大家使用 IPFS 时容易先入为主，拿其他分享方式的思维（尤其是网盘的）来生搬硬套，这样自然就会带来各种各样使用上的问题。

而懂得的人往往又受制于“知识的诅咒”，也就是所谓的“难了不会会了不难”。懂得一个概念的人难以想象不懂这个概念的人初次接触时会产生什么样的疑惑。因此以往没有人尝试厘清这个问题，今天我索性借此机会一次性把它讲个明白。

现在我们丢开网盘、BT、IPFS 等等这些名词，当我们从未知道它们，先回归到“分享”这个动作上。

我们可以把互联网分享资源分为：（1）【上传】、（2）【分享】、（3）【下载】，这三个步骤，不管什么分享方式都万变不离其宗。只要你是通过互联网把一个东西传给另一个人，一定都可以分成这三个步骤。

举个例子，百度网盘，【上传】就是把文件上传到网盘；【分享】就是对这个文件创建分享链接，然后发给下载者；【下载】就是下载者点击链接转存到自己的网盘里，然后用百度网盘的客户端下载，或者直接用客户端下载。如果使用秒传链接，【上传】部分不变，【分享】步骤变为发布这个文件的秒传链接，【下载】部分变为下载者使用秒传链接把文件保存到自己的网盘里然后下载。

对于 BT 而言，【上传】就是上传者把保存在自己硬盘里的文件做种；【分享】就是上传者把文件的种子文件或者磁力链接发布出去；【下载】就是下载者在 BT 下载器中使用种子文件或者磁力链接下载文件的过程。

根据以上三个步骤，我们来看看 IPFS，看完之后，你就不会再觉得莫名其妙了。

对于 IPFS ，【上传】就是上传者把文件上传到托管平台或者在自己的硬盘里做种；【分享】就是上传者把文件的 CID 或者带网关的分享链接发布出去；【下载】就是下载者把 CID 导入自己的 IPFS 节点右键下载或者通过 IPFS 网关 + CID 的链接进行下载。

如下图所示：

对此图感兴趣可以参考：https://rentry.org/ipfs_web

总结 IPFS 分享的工作流，可以分为 3 步：上传、分享、下载

(1) 上传

把文件通过酸奶网盘或者 Crust files 上传到 IPFS 网络

(2) 分享

拖入文件到 IPFS 分享助手、计算 CID、测定速度、生成下载链接，进行分享

(3) 下载

使用 IDM 、FDM、结合 IPFS 辅助油猴脚本批量复制下载链接进行批量下载

6.2.2 IPFS 无法举报的本质原因：权责不明

上述特点正是 IPFS 无法举报的原因了，因为这里的一切都是“不清不楚”、“稀里糊涂”、“权责不明”的，举报者找不到内容的相关责任人，自然就无法举报了。这种情况并非设计上的疏漏或者架构上的落后，反而恰恰是 IPFS 的设计者们为了达到上述效果，为了构建一个更为开放，更为透明，更为公平的互联网而刻意为之的。

在 IPFS 的基础上，就可以构建出一种有别于传统 HTTP 互联网的新概念互联网—— web3.0 ——这个话题非常庞大，加之本人水平也有限，就不对其展开论述了，感兴趣大家可以自行了解，这里大家只记住一点即可：IPFS 一般来说无法举报。

回到我们的小节标题，现在我们就完全可以理解 CrustFiles 的用法了，它对应【上传】步骤，把文件通过 CrustFiles 上传托管到 Crust 的诸多矿工那里保存。接下来通过 IPFS 分享助手计算文件的 CID 并进行网关测速，最后根据测速结果生成下载链接，即可通过“权责不明”的网关从“稀里糊涂”的矿工那里下载“不清不楚”的文件。

6.2.3 IPFS “直链”的构成：网关+CID

访问形式：https://[网关]/ipfs/[CID] https://[CID].ipfs.[网关]
下载时可以加（?filename=[命名]）来命名文件

6.3 IPFS 矿工托管速成教程

讲了这么多理论，都快要忘了标题了，接下来就以一个很暴力但是能快速教会你怎么使用 IPFS 托管的教程来收尾。

先说明这个不是正经教程，而只是一个操作流程，你不需要纠结其中任何操作的含义，只需要按照流程操作即可。

想要了解具体教程可以看参考文章：

[技巧分享] IPFS分享资源快速上手及其适用场景浅议资源防炸链解决方案(https://cangku.moe/archives/212530)

以下正式开始

打开 https://yoghourt.cloud/ 酸奶网盘的官网，下载最新版酸奶网盘并安装，或者在这里下载

https://gw.crustgw.work/ipfs/bafybeiaeq2sblmnjvs27qr7romzc6ryqz5qiy6ng2ltrs7tgxux7rdeqh4?filename=yogurt-cloud-client-0.1.4-setup.exe

当右下角显示 IPFS 连接成功，即可拖入上传文件

然后等待上传完毕

上传完毕后等待至副本数大于 0

然后打开 IPFS 分享助手：

https://k51qzi5uqu5dh1ts2qvcw3069src00zyjw0qmwdkb102k8q4ft8bztw75iwi25.eth.sucks/

在右下角的计算器中拖入那个文件，然后计算 CID 后点击【填写CID和文件名到主输入框】，
填写后点击【下载网关测速】，
测速完成后点击【生成下载链接】，即可得到能直接链接到资源的链接了，
再点击【复制下载链接】，即可复制链接并发布，下载的时候只需要打开这个链接，用浏览器或 IDM 就能下载。

如果某个链接不能用了，把链接中的 CID (即 baf...6cwe 这样的字符串) 复制后填入图中的位置，重复 2 3 4 步骤即可。

下面是最终得到的链接，可以直接在浏览器中打开使用：

[img]https://i0.img2ipfs.com/ipfs/bafkreibm2z34rvt5qhbiz3cv4524skjefg2mard7h4i7stqinpi5sl6cwe?filename=%E4%B8%BA%E4%BB%80%E4%B9%88%E8%A6%81%E5%88%86%E4%BA%AB%EF%BC%9F.jpg[/img]

这是刚才上传的图

结语：为什么要写教程？

本文很早就打算写了，但是各种原因还是拖到了现在。如最后那张图所示，分享是一件需要热情与精力乃至金钱的事情，一分钱不挣还需要花费精力来完成，属于损己利人，并且分享灰色地带的资源还可能给自己带来麻烦。不仅要跟网盘斗智斗勇，还需要跟倒卖者互相拉扯。

所以有句话叫“资源不分享，只赠有缘人”，如果你想要获得某样东西，就需要自己去争取，而不是等人喂饭。分享是出于热爱，既没有收入更不是一种义务。这也就是为什么很多分享者不喜欢伸手党的原因了，因为伸手伸的实在太理直气壮。而这种情况大部分是把分享者当成了 up 主，下意识认为观众是 up 主衣食父母，由此产生的惯性思维在作怪。

对于写教程而言更是如此，分享的意义暂且不论，写教程有什么意义呢？

平心而论，写教程搞研究确实要比单纯的分享更占精力，因为这是教科书上、乃至各大平台的知识区所没有的东西。假如你对某样互联网技术产生了兴趣，不管是基础的编程、还是 web3、 AI 等，你基本都能找到对应的系统化教程。但是唯独资源分享这个领域，至今没有充分的研究或探索，大部分都是靠个人经验，各家各有各法，有些是有效的，有些则是无用功，并没有系统性的教程。

对于我个人而言，探索这件事本身就是意义，我不敢说这个教程就是最好的，但是至少在我已知的范围内，已经尽可能囊括了绝大多数前人的有价值经验，再加上一些我自己的测试和探索，是目前我认为对新人来说最行之有效的一套方案了。对于某些有技术的分享者来说，本教程的内容可能没有太多的作用，因为懂得折腾 seedbox ，并且深谙网站抗投诉方案的分享者可以有办法用 BT 或者自建网盘进行分享，但是多了解一些信息我认为是有益无害的。

更关键在于本教程结合了来自百度官方的一些信息，以及 IPFS 这样的新技术，这使得即使是纯新手，在面对倒卖者时也不是完全的束手无策，而现在唯一的问题就是如何更好地向所有人普及这些内容。分享这件事不能强求所有人都来参与；但是另一个层面来说，也正是因为如此，才更需要给愿意分享的人以安全和动力。

当然，分享者也是人，不可能完美无缺，也没有必要崇高化分享者，因为“我为人人”的最终目的还是“人人为我”。我们希望等到有一天我们想要某个资源的时候，一搜索便发现已经有贴心的分享者整理好，而不是需要跑到咸鱼或者淘宝上掏钱从倒卖者那里购买他们免费从分享者那里获取到，并反手炸了链接的一模一样的资源。或者搜索到 B 站找到诸如“加威vx xxxxxxxxxx 入群免费领取、点击关注后私信免费领取资料”等营销号信息。

相比于其他的某些其他平台，仓库这样的资源分享社区已经很自由民主了，获取资源也没有太多门槛，按照隔壁南+管理的说法，就是“安心的分享，痛快地下载”。可对于一个有注册门槛，显然是私域的站点，目前竟然无法做到这一点，这显得有点荒唐。在我们无法改变互联网大环境的情况下，通过尽可能简单的方式提升分享者的能力，就是我们所能做到的事情了。

所以，也希望有能力的人能够参与到安全分享普及相关的事情中来，因为自己淋过雨，所以要告诉他人如何不淋雨，授人以鱼不如授人以渔。只有有能力的人越来越多，分享社区才能更加稳定，才能驱除倒卖者这样的牛鬼蛇神，还分享社区一个清朗。

最后，值此跨年之际，预祝大家 2025 新年快乐。

层林尽染

2024.12.29