2025-02-02

防炸教程：如何安全分享资源？

前言：这篇教程是做什么的？
1. 炸链的三大原因：文件名、在线解压、举报
2. 网盘的两个违规级别、审核与举报
3. 资源分享的六种安全级别
4. 怎么“打包”才防炸？防炸的原理是躲猫猫！
5. 怎么“防止封号”？能用小号就用小号！
1. 5.1 网盘大号传小号分享
  1. 5.1.1 大号的操作
  2. 5.1.2 小号的操作
2. 5.2 百度网盘的账号封禁机制说明
  1. 5.2.1 秒传失效的原理，二种哈希值
  2. 5.2.2 账号监控机制&压制性举报、自动违规
6. 应对恶意举报的有效解决方案：去中心化
1. 6.1 究竟应该如何才能防止恶意举报？
  1. 6.1.1 BT
  2. 6.1.2 IPFS
2. 6.2 IPFS 矿工托管速成
结语：为什么要写教程？
参考

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

自 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 百度网盘的审核机制

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

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

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

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

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

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

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

2.2 能不能用外网盘？

那么，既然国内的网盘审核如此的严格，我们能不能使用国外的网盘呢？本着这个想法，我在绅士仓库某一个被倒卖者盯上的炸链重灾区 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.3 目前倒卖者举报能力归纳

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

可以用脚本把文件举报到相当于百度网盘封禁等级第二级（“文件违规根据相关法律法规予以屏蔽”），因为是脚本自动化完成，百度网盘上的举报极其难以应对。
可以举报所有国内网盘分享链接（包括但不限于百度、阿里云、天翼云、微云、迅雷盘等）、国外网盘（测试时共计被封禁 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. 怎么“打包”才防炸？防炸的原理是躲猫猫！

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

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

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

可以概括为

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

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

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

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

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

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

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

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

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

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

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

4.2 基于隐写的“防炸”方案 (20241228 版)

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

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

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

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

4.2.1 百度云申诉操作流程

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

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

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

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

申诉流程如下：

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

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

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

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

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

4.2.2 提取码的反爬处理

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

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

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

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

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

上图的答案是 PJ1B

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

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

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

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

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

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

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

4.2.3 链接的反爬处理

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

(1) 插字法

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

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

此资源为海绵宝宝

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

(2) 截断法

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

1
2
3

度链
1e9YTAyr8gOPCqOSx8KoR8g
wp79

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

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

(3) 加密法

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

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

加密前

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

加密后

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

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

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

也可以在这个网址进行可自定义密码的 AES 加密：

https://bafkreigh3txpz6f4umsu35crfb4i4w5peyogebq56hod6ghnwzcui7zpoe.ipfs.dweb.link

(4) 二维码法

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

如下图所示

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

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

小结一下：

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

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

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

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

4.3 其他网盘的抗举报能力

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

4.3.1 阿里云盘

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

就目前所知，我们可以明确倒卖者对于网盘的举报都是采用脚本调用网盘的举报 API 接口来实现的，因为他们的举报规模需求非常大，手工完成这种规模的举报几乎不可能。

就目前所观察到的，百度、夸克、Mega 等网盘都可以以一个比较快的速度大规模完成举报→封禁的操作，但是唯独在阿里云盘上出现了例外，不管是违规的规模还是速度，相比前三者都存在较大的差距。（比如说即使很紧急的举报也不能立刻使得链接违规，至少需要等到第二天，并且对于大批量的分享链接举报速度十分低下）

造成这样的现象必然有其原因，为了更深入的考察这一问题，我们尝试分析一下阿里云盘的举报过程。

阿里云举报的 API 接口长这样：

1	https://api.aliyundrive.com/adrive/v1/tipoff/create

阿里云确实理论上可以用 API 实现脚本批量举报。

然而，虽然如此，我们也要注意到阿里云盘的举报界面长这样：

其中存在 2 个难点——即使能够通过 API 创建并提交举报，但是问题截图是举报所必须的——这可能造成了倒卖者对于阿里云盘分享进行举报的效率较为低下。

另外，阿里云盘的联系手机号不知道是否会影响举报的效果，但合理推测有联系方式的举报会更加有效，不过倒卖者显然是不敢留真实手机号的。

此外，与百度网盘不同，阿里云盘违规的只是链接不是文件，也就是说即使炸链了，可以直接对原本的文件重新分享，而不用像百度网盘那样需要申诉或者改哈希重新上传。

同样地，这种情况下使用[[隐写文件]]会达到最好的效果。

4.3.2 UC 网盘

这个网盘目前来看有不少优点，首先到现在为止，UC 网盘确实下载不限速，免费的账号有 10 GB 的空间，这意味着只要资源单文件小于 10 GB，就可以很方便地下载。

此外，UC 网盘的举报程序也较为复杂，如下图所示，仅有移动端可以举报，并且必须要提交问题描述以及联系方式，仓库有作者在使用 UC 分享，到目前为止并没有观察到 UC 大规模违规的情况。

UC 的缺点是免费账号的空间太小了只有 10 GB，用来下载足够，但是对于分享来说可能不太够。

建议使用的网盘还有 Pikpak 、OneDrive 、Google drive 等，不过假如要抗举报，它们的使用难度稍大，也各有一些毛病，不适合普通分享者使用，这里带过。

4.4 不建议使用的网盘

4.4.1 夸克网盘

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

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

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

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

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

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

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

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

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

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

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

可以总结为

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

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

5.1 网盘大号传小号分享

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

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

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

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

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

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

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

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

百度网盘 v 12.15.7 版. Apk

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

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

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

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

5.1.1 大号的操作

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

然后选择要共享的小号

5.1.2 小号的操作

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

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

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

复制的结果如下

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

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

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

以上内容参考：

[技巧分享] 百度网盘大号传小号分享的操作方法 [资源安全分享方案]

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

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

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

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

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

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

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

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

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

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

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

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

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

以我自己为例，根据我从百度处了解到的信息，我的某个账号平均每天会被举报近 1000 次，在这样对账号的压制性举报下，就会出现分享大量自动违规的情况（如下图），需要强调，隐写并不能彻底防止炸链，但是其可申诉的特性可以进行更多的操作，并且也让保存了的人有办法下载。

不过对于反复违规的链接，在其某一次恢复正常后，还是建议取消分享并换源。这样通过减少违规量的办法，可以降低封号的风险。

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

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

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

本节内容参考
[技巧分享] 如何应对恶意举报 - 百度云篇 - 其二 [资源安全分享方案倡议]

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 矿工托管速成

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

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

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

[技巧分享] IPFS分享资源快速上手及其适用场景浅议 [资源防炸链解决方案]

以下正式开始

打开 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 步骤即可。

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

(1) 上传

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

(2) 分享

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

(3) 下载

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

与百度网盘及 BT 的对比图如下

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

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

1	[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

参考

主要内容

[1] [技巧] 用文件隐写来规避网盘和谐

[2] [工具分享] 隐写者：把资源嵌入MP4文件的隐写工具 [资源防炸链解决方案倡议&规避网盘审查技巧探讨]

[3] [技巧分享] 隐写分享压力测试阶段性报告 [资源防炸链解决方案倡议]

[4] [技巧分享] 后秒传时代如何避免资源分享炸链 [资源防炸链解决方案倡议]

[5] [技巧分享] 关于评论区地毯式炸链现象的一些测试及初步猜想 [资源防炸链解决方案倡议]

[6] [技巧分享] 关于此评论区地毯式炸链的真实原因及补档相关说明 [资源防止炸链解决方案倡议]

[7] [技巧分享] 后秒传时代的安全分享路在何方？为什么我们需要隐写？ [资源分享传火呼吁&隐写用法释疑]

[8] [技巧分享] 网盘资源分享的几种安全级别、审核与举报原理 [资源防炸链解决方案倡议]

[9] [技巧分享] 隐写文件误区及申诉补档建议、百度云批量申诉工具 [资源防炸链解决方案倡议]

[10] [技巧分享] 如何应对恶意举报 - 百度云篇 - 其一 [资源防炸链解决方案倡议]

[11] [技巧分享] 如何应对恶意举报 - 百度云篇 - 其二 [资源安全分享方案倡议]

[12] [技巧分享] 百度网盘大号传小号分享的操作方法 [资源安全分享方案]

[13] [技巧分享] 我都套娃10层压缩了怎么还炸？分卷了都炸？一文(也可能是几文)教你用IPFS傻瓜式防炸！

[14] [杂谈] 你的传火姿势可能有错！传火前为什么要改哈希？

延伸阅读

[X1] [技术分享] 如何在.mkv格式视频里夹带隐藏文件，附带mkvtoolnix，MkvEdit和gMKVExtractGUI工具

[X2] [杂谈] 给新司机的一个简单的科普 (笔者注：此文是关于安全分享的科普)

[X3] [技巧分享] IPFS分享资源快速上手及其适用场景浅议 [资源防炸链解决方案]

[X4] [技巧] 利用网盘离线下载分享规避审查

[X5] [技巧分享] [自建网盘] 自建网盘cloudreve+离线下载

[X6] [高阶文章] 关于新时代文件分享机制的思考 (笔者注：此文介绍了除网盘外的其他分享方案)

[X7] [技巧分享] 图种的制作与使用

[X8] [技巧分享] 防炸教程 (笔者注：本文介绍了网盘常用的分享方案，不过作者有可能要吃电脑屏幕了)

[X9] [教程] BitTorrent (种子文件) 扫盲 [绅士仓库 tracker 更新] [2020 Rev] (笔者注：本文是磁力做种的教程)

[X10] [技巧分享] [IPFS] 无法被举报的文件分享神器CRUST IPFS操作指南 PART.I ( IPFS 托管平台教程)

[X11] 关于百度近日封号的相关措施 (此文也是秒传时代的开端)

[X12] [南+] 本坛还是有牛马用户啊，低能儿请远离互联网好吗？一口一个敬语问我要资源下载了之后反手就去微软举报，你咋不去网信部举报？说不定给你颁一个好市民奖

[X13] [南+] 看看单纯的举报行为会对百度网盘资源有多大的影响

[X14] [Pixiv] 一个网警的心法教学-P站写色文发黄图到底安不安全【全网最全最细致】

[X15] [工具分享] IPFS分享助手：IPFS资源分享一站式解决方案 [资源防炸链解决方案]

[X16] [工具分享] [油猴脚本] 自动抓取 IPFS CID-文件名-下载链接的辅助脚本

[X17] [技巧分享] 把IPFS当作网盘来用-IPFS进阶教程 [资源安全分享解决方案]

[X18] [技巧分享] 盘点主流IPFS托管平台：功能、限制与推荐指数全面对比 [资源安全分享方案]

2025-02-02

网盘资源分享的几种安全级别、审核与举报原理

技巧分享-网盘分享的几种安全级别、违规、审核与举报原理
前言
1. 资源分享的几种安全级别
2. 关于百度网盘的举报、审核以及两个违规级别
3. 如何让正常文件违规？
4. 关于安全分享的一些建议
5. 能不能使用外网盘？
6. 目前倒卖者举报能力归纳
7. 关于理论最强安全性
附录：MP4隐写技术相关系列文章（时间顺序）

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

网盘资源分享的几种安全级别、审核与举报原理

前言

根据近期对网盘分享的种种策略的测试，本人尝试整理总结了网盘分享的不同安全级别，以及百度网盘的审核、举报相关的细节说明，然后给出了根据风险级别选择分享安全级别的建议，希望能对大家有所帮助。

1. 资源分享的几种安全级别

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

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

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

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

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

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

2. 关于百度网盘的举报、审核以及两个违规级别

3. 如何让正常文件违规？

资源分享社区有一个长期存在的痼疾——资源倒卖者，俗称“倒狗”。这些人会把各大分享者免费分享的灰色地带资源拿走后在某宝、某鱼等平台上开价售卖。

一单的售价不算高，通常只有几块到几十块不等，但是架不住量多，而且除了信息差几乎没有成本，所以有很大盈利空间。

为了垄断销售渠道（人话就是吃独食），倒卖者会采用各种办法炸掉其他的免费分享链接，保证只有自己一个来源。所谓“没有信息差就人为制造信息差”，以此囤积居奇。

其中，尤其以百度网盘的情况最为恶劣。

资源倒卖者在百度云上的举报示例

接下来我们进行换位思考：假如我们是倒卖者，想要某一个正常文件违规，应该怎么做？

方法自然是举报，但是如我刚才所言，举报需要达到一定的数量才能让文件违规，这里的数量不单指举报的次数，还必须得是“大量不同账号进行的大量举报”，需要达到一定的规模。

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

但是这个机制却被倒卖者察觉到，并加以开发利用来进行自动化批量大规模恶意举报。

要达到一定规模由人手工完成比较麻烦，因此可以对 scrapy 这类爬虫框架进行魔改，把 get 请求改为 post 请求。然后购入大量百度账号的 cookies 信息放入 cookies 池中，再给这些 cookies 购入一些代理 IP 避免被官方察觉到异样。

Scrapy 爬虫框架示意图

如此，只用一个爬虫的资源，就可以实现一个简单有效的自动批量举报程序，所需花费仅有 cookies 和代理 IP。

剩下的事情就是用一个靶子小号分享想要使之违规的文件，然后运行举报爬虫，使爬虫轮番以不同账号的名义对分享文件进行举报，达到网盘的违规阈值，就可以让原分享炸链了。这种方法在逻辑上和 DDos 攻击有异曲同工之处。

这个架构非常适合批量化，假如需要违规的文件有多个，那就分别对其进行分享然后把分享链接放入举报池中，让爬虫依次举报即可。这种举报是针对具体文件的，哪怕后来这个文件申诉成功，脱离了原来的分享链接，只要这个文件可以被分享，重复上述流程，就可以再次让它违规。

更进一步，假如直接举报到第二级，但凡不是隐写文件，哪怕用秒传也是扛不住的（例如此投稿）。这种情况在秒传时期大家应该或多或少的察觉到，不能在线解压的分卷压缩包中的某一个或几个文件会莫名其妙违规无法下载，进而导致资源整个作废，其原理便是如此。

如果想要新增文件，直接给举报池里添加新的文件即可，假如文件不增加/申诉不成功，那么这个举报池就不用更新。

在百度网盘一家独大的情况下，倒卖者对于百度网盘审核机制的研究也最为深入，他们充分利用了百度网盘的违规机制，发明了批量转存+脚本举报的技术，转存想要使之违规的文件，然后调用举报脚本，自动化批量创建分享链接，再以大量账号池组成的海量的举报逐个冲垮文件（类似于 DDoS 攻击），对于隐写文件，则可能会先修改后缀以破坏其伪装。

倒卖者可以全程不下载任何文件，就能流水线式地在云端进行转存举报等一系列操作（这也就意味着各种复杂密码、改后缀等等操作都意义不大）；倒卖者也不需要关心具体举报哪个文件，只需要源源不断地把转存后的文件放入举报池中即可，如此构建起一个简单易操作、成本又可控的举报工作流。只要每天开机运行一遍，就可以让所有举报池中的文件违规。

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

并且，假如一个百度账号同一天内多个链接被举报的次数大于了 1000，那么被封号的可能性就很高了，第一次禁止分享 30 天，第二次永久。这种攻击可以无限次使用，一轮不行就多来几轮，总能让你封号。

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

总的来说，这种架构简单易维护，非常适合居家旅行以及偷鸡摸狗时使用。

注意，此行为可能会导致牢底坐穿，好孩子切勿模仿

关于倒卖者使用此手法的证据可以参考：
https://www.south-plus.net/read.php?tid=2308875
另外据这篇文章，倒卖者所拥有的百度黑号的数量至少大于 2000

4. 关于安全分享的一些建议

根据我们之前的测试与检验，我们发现百度网盘的审核机制实际上并没有我们想象的那样严苛，只要不被举报/不在线解压，百度网盘对于无法解密的文件分享通常是不会管的，也就是采取民不告官不理的做法。

而对于零星的举报，部分加密压缩包能扛过去，扛不过去就会炸链，且无法申诉。

对于隐写文件而言，抵抗举报的能力会强不少，这也正是隐写文件的优势：被强制违规也有申诉的可能。即使发生如这种盗链后遭到举报的情况，只要对方没有孜孜不倦地大量举报（零星的举报并不足以让隐写文件违规），申诉最多 1、2 次基本就解决问题了。

不过，对于持续性地脚本大量举报造成的强制违规，目前除了拉锯式申诉也没有太好的办法（即同样以脚本进行自动批量申诉，相比于大量举报的机器人成本，在云服务上自动运行的申诉脚本成本应该会低不少，因为只需要一个），但是这毕竟还是需要钱的，虽然听着比较解气，但花钱解气属于赌气，并不是理性的选择，此时应采用 IPFS、BT 或者自建网盘 等不会因为举报而和谐的分享方式为宜。

判定是否是脚本的标准也很容易，只要隐写文件连续炸链两次以上，即申诉成功后又很快炸链，那么就可以判断是脚本举报。

经过上面的分析，我们大致可以得出一些基本的要领了：

假如场景中只存在无意中在线解压的风险，那么采用加密压缩包已经可以满足需要；
假如可能会被故意在线解压，那么采取分卷压缩和自解压格式压缩即可满足需要；
假如可能会遭遇零星乃至有限次的大量举报，那么采用隐写文件为宜，炸链了可以尝试申诉；
假如可能会遭遇反反复复的脚本持续举报，此时应放弃网盘，选择 IPFS、BT、自建网盘为宜。

总之，分享的手段多种多样，根据不同的风险采用不同的级别，这样应该就能尽量做兼顾安全性与舒适度的分享了。

5. 能不能使用外网盘？

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

资源提示违规

分享账号被封禁

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

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

Mega 的申诉流程走了半个月

此外，MediaFire：

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

PikPak

Pixeldrain

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

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

6. 目前倒卖者举报能力归纳

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

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

7. 关于理论最强安全性

知道了举报的原理，我们可以从纯理论角度构想一种最安全的办法——以毒攻毒法。

即先把分享文件举报到第一级，使得它不可以用网盘的分享系统分享（但仍然可以下载），然后采用秒传链接（假如秒传还能用的话）或离线下载的方式进行分享。

这个分享文件不能被在线解压，因为倒卖者可以直接在线解压后举报内容，让文件掉到第二级，使之无法下载。由于非隐写文件不可申诉，文件彻底宣告死亡。

这个分享文件也不能是隐写文件，隐写文件的可申诉性在这个场景下反而成了不利因素，因为倒卖者可以先申诉成功，然后再把文件举报到第二级，开始举报&申诉的拉锯战；

综上所述，最优方案就是【被举报到禁止分享的自解压文件】，相比于分卷，自解压文件可以做到单层压缩仅有一个文件，更加简洁，并且由于不可申诉，可以稳定维持第一级违规状态。

如此，利用非隐写文件的不可申诉性保证文件的安全，再用秒传/离线下载进行分享，应该就可以达成理论上最强的安全性了。

当然，这种办法只是理论上的，实际操作起来非常麻烦，一般来说采用上述的 4 条建议会更简单易行一些。

长驱鬼魅不休战

附录：MP4隐写技术相关系列文章（时间顺序）

主要内容

[1] [技巧] 用文件隐写来规避网盘和谐
[2] [工具分享] 隐写者：把资源嵌入MP4文件的隐写工具 [资源防炸链解决方案倡议&规避网盘审查技巧探讨]
[3] [技巧分享] 隐写分享压力测试阶段性报告 [资源防炸链解决方案倡议]
[4] [技巧分享] 后秒传时代如何避免资源分享炸链 [资源防炸链解决方案倡议]
[5] [技巧分享] 关于评论区地毯式炸链现象的一些测试及初步猜想 [资源防炸链解决方案倡议]
[6] [技巧分享] 关于此评论区地毯式炸链的真实原因及补档相关说明 [资源防止炸链解决方案倡议]
[7] [技巧分享] 后秒传时代的安全分享路在何方？为什么我们需要隐写？ [资源分享传火呼吁&隐写用法释疑]
[8] [技巧分享] 网盘资源分享的几种安全级别、审核与举报，分享建议 [资源防炸链解决方案倡议]
[9] [技巧分享] 隐写文件误区及申诉补档建议、百度云批量申诉工具 [资源防炸链解决方案倡议]
[10] [技巧分享] 如何应对恶意举报 - 百度云篇 - 其一 [资源防炸链解决方案倡议]
[11] [技巧分享] 如何应对恶意举报 - 百度云篇 - 其二 [资源安全分享方案倡议]
[12] [技巧分享] 百度网盘大号传小号分享的操作方法 [资源安全分享方案]

延伸阅读

[X1] [技术分享] 如何在.mkv格式视频里夹带隐藏文件，附带mkvtoolnix，MkvEdit和gMKVExtractGUI工具
[X2] [杂谈] 给新司机的一个简单的科普 (笔者注：此文是关于安全分享的科普)
[X3] [技巧分享] IPFS分享资源快速上手及其适用场景浅议 [资源防炸链解决方案]
[X4] [技巧] 利用网盘离线下载分享规避审查
[X5] [技巧分享] [自建网盘] 自建网盘cloudreve+离线下载
[X6] [高阶文章] 关于新时代文件分享机制的思考 (笔者注：此文介绍了除网盘外的其他分享方案)
[X7] [技巧分享] 图种的制作与使用
[X8] [技巧分享] 防炸教程 (笔者注：本文介绍了网盘常用的分享方案，不过作者有可能要吃电脑屏幕了)
[X9] [教程] BitTorrent (种子文件) 扫盲 [绅士仓库 tracker 更新] [2020 Rev] (笔者注：本文是磁力做种的教程)
[X10] [技巧分享] [IPFS] 无法被举报的文件分享神器CRUST IPFS操作指南 PART.I ( IPFS 托管平台教程)
[X11] 关于百度近日封号的相关措施 (此文也是秒传时代的开端)
[X12] [南+] 本坛还是有牛马用户啊，低能儿请远离互联网好吗？一口一个敬语问我要资源下载了之后反手就去微软举报，你咋不去网信部举报？说不定给你颁一个好市民奖
[X2] [南+] 看看单纯的举报行为会对百度网盘资源有多大的影响

2025-02-02

IPFS 分享资源快速上手及其适用场景浅议

IPFS 分享资源快速上手及其适用场景浅议

IPFS 分享资源快速上手及其适用场景浅议

摘要

本文详细介绍了 IPFS（星际文件系统）的使用方法、优缺点及其在资源分享中的应用场景。文章首先讲解了 IPFS 的基本操作，包括文件的上传、固定、分享和下载。随后，介绍了 IPFS 本地文件管理和使用托管平台的方法。最后，文章对比了 IPFS 与传统网盘分享方案，提出了分场景使用不同级别分享方案的建议，分析了 IPFS 作为最终手段，在应对恶意举报问题上的优势。

更新：

20241103：4.4 节更新 IPNS 用法相关内容介绍，可以在无服务器的情况下创建类似于域名的网址用于可更新的分享，详见目录；同时修正了一些文章错漏。

文章目录

【IPFS分享工作流】

关于 IPFS 的几个要点：

IPFS 上传和下载都不需要公网 IP，也不需要 VPS，但是注意如果挂了梯子【不要开启 TUN 模式】。
IPFS 发布文件需要先固定（类比 BT 的做种），然后可以通过浏览器整合下载。
IPFS 除了自己固定（做种），也可以选择托管平台托管，代为做种。
IPFS 发布的文件大部分都可以直连下载。

先在这里下载 IPFS 客户端并安装：

https://docs.ipfs.tech/install/ipfs-desktop/#windows

以下是操作流程的详细说明。

如果上面的链接打不开，或者找不到，可以从下面的备用镜像链接下载（）

百度网盘：https://pan.baidu.com/s/1MI6QKUI8abkl0MmiTLhHtA?pwd=u2xt

IPFS 直链：https://gw-seattle.crustcloud.io/ipfs/bafybeifh2jdor3r26x4adskx2rlz33ada64mducx2iq6oa3iqh5ir42zby?filename=IPFS-Desktop-Setup-0.38.0.exe

以下是操作流程的详细说明。

1. 固定并分享文件

1.1 固定想要共享的文件

在 IPFS 中，每一个文件都有一个独一无二的标识符 CID ，CID 在 IPFS 中就对应具体文件，类似于 BT 的磁链，因此分享 CID 就等于分享文件，下载时只需要知道 CID 即可下载文件。

CID 的示例如下（有两种格式 v0 和 v1，分别以 Qm 和 ba 开头）：

1 2	QmPKhevNWUx89XBU82XF4UYs2xsdxZnG2xPz2uZsA6Yatm bafybeibcr7x6d2bo43ce6xaye6d6aogvbfmeokphpsvjlqv27udl34ads4

目前推荐使用后者。

在配置中的 Import 部分把 CidVersion 参数改为 1 ，然后保存并重启 IPFS 即可。

配置完毕后，就可以开始固定文件了

右键点击上传后的文件，设置固定

固定在本地节点

1.2 复制 CID 以发布文件

固定成功后再次点击右键，选择复制 CID ，就可以发布文件了。

可以采用分享链接的方式分享文件，由于默认的公共网关被墙了，在分享前需要修改 IPFS 的公共网关，可以修改为以下网关中的一个：

可用 IPFS 公共网关（随时更新）

https://eth.sucks
https://flk-ipfs.xyz
https://cdn.ipfsscan.io
https://gw-seattle.crustcloud.io
https://gw.crustgw.work
https://gw.crust-gateway.xyz
https://gateway.ipfsscan.io

然后右键文件-分享链接即可

在下面的网址可以找到更多的可用公共网关

https://ipfs.github.io/public-gateway-checker/

在说明下载前，可以检测一下自己网络的可用性。

此网址可以检查自己的 IPFS 网络的可用性：

https://check.ipfs.network/

下面的 4 个检查得至少满足前 3 个，如果你有公网 IP 则会有第 4 个。

1.3 开启 DHT 加速

20241009 更新：实际测试，DHT 加速会显著增加 IPFS 的资源消耗，并且相比于其消耗的资源来说对效率的提升较为有限（氪佬随意），在使用 Crust 等托管平台而非自己做种时，不建议开启 DHT 加速。

在上传之前可以在配置选项卡中如下修改配置信息，开启 DHT 加速，DHT 加速可以提高连接节点数量，增加效率。

1	"AcceleratedDHTClient": true,

1.4 关于分享文件的可用性

IPFS 类似于磁链，也需要有人“做种”，需要有人固定文件（做种），并且在线，才可以下载。

可以在这个网址中检测 CID 是否可用：

https://explore.ipld.io/

2. 根据 CID 下载文件

2.1 使用 IPFS 原生下载功能下载文件

下载文件和上传文件是类似的，首先需要导入文件

在弹出的窗口中输入 CID ，可以自行指定文件名

导入完成后点击右键，选择下载

接下来会使用浏览器的下载功能进行文件下载，这种下载方式类似于 BT 是 P2P 的，能否下载成功取决于对方是否在做种。

如果安装了 IDM、FDM 等下载软件，也可以使用这些软件接管下载，比如我用的是 FDM ：

2.2 使用 IPFS 公共网关下载文件

除了类似于 BT 的 P2P 以外，IPFS 还可以采用公共网关创建分享链接的方式分享文件，公共网关本身也是一个 IPFS 节点，但拥有公网 IP ，连接速度较快，可以帮助其他节点下载。具体来说就是用它生成直链，让下载者用这个直链下载。

IPFS下载链接结构为 网关+CID

示意图如下：

使用这种方式分享的时候下载者不需要软件，用浏览器、IDM 等即可直连下载。

由于默认的公共网关被墙了，在分享前需要修改 IPFS 的公共网关，可以修改为以下网关中的一个：

可用 IPFS 公共网关

https://eth.sucks
https://flk-ipfs.xyz
https://cdn.ipfsscan.io
https://gw-seattle.crustcloud.io
https://gw.crustgw.work
https://gw.crust-gateway.xyz
https://gateway.ipfsscan.io

也可以在这个由 sandbox 维护的网站中寻找更多可用的网关：
https://rentry.org/ipfsnodes

按照下图所示设置：

然后右键文件-分享链接即可

在下面的网址可以找到更多的可用公共网关

https://ipfs.github.io/public-gateway-checker/

2.3 使用 IPFS 本地网关下载文件

公共网关本身也是一个 IPFS 节点，经由公共网关访问文件或文件夹 CID 可以理解为由对方代理来连接到 IPFS 网络中的资源，由于这些网关有公网 IP ，速度也比普通的家宽更快，所以通常建议用公共网关访问并下载资源。

但是公共网关也可能面临被恶意举报导致封 CID 的情况，这种时候除了更换其他公共网关，也可以用自己 IPFS 节点的本地网关访问资源，这种访问类似于 BT 是纯 P2P 的，也就是说，即使这个 CID 在所有公共网关上都被屏蔽了，只要你自己不屏蔽这个 CID 就能访问。

在本地的 IPFS 启动后，在浏览器地址栏中输入 CID，后面加上 .ipfs.localhost:8080 ，即可用 IPFS 的本地网关查看并下载文件，示例如下：

http://bafybeihon37a3qtxqynvphkt4ebe3hd42tdrfw4gstsadka5yijz3fjbfe.ipfs.localhost:8080
或者在 CID 前面加上路径形式的本地网关：
http://127.0.0.1:8080/ipfs/bafybeihon37a3qtxqynvphkt4ebe3hd42tdrfw4gstsadka5yijz3fjbfe/
（注意是 http 不是 https ，这里的 http 只用来连接本地的 IPFS 节点，相当于 IPFS 成了代理，所以不必担心安全性）

这个 CID 对应的是一个 html 文件，因此被浏览器渲染成了网页的样子，按 ctrl+s 可以把这个文件下载到本地查看，对于其他格式资源也是同理，这也就是为什么 IPFS 分享的东西能被浏览器或者 IDM 或者 FDM 等下载器直接下载的原因了。

此外，在安装 IPFS 客户端的情况下，在浏览器地址栏输入：

ipfs://bafybeihon37a3qtxqynvphkt4ebe3hd42tdrfw4gstsadka5yijz3fjbfe

也会自动打开刚才的本地网关。

从上面这个例子可以看出，ipfs 某种意义上可以代替 http 来访问互联网中的内容，CID 就是内容的地址，IPFS 的这种特性称为“内容寻址”

.ipfs.localhost:8080 中最后 4 位数字为本地网关的端口号，通常为 8080，但是有时候也可能变化，此时端口被占用就无法使用，常见原因比如酸奶网盘与 IPFS 客户端冲突等，如果发现本地网关无法使用，如下图所示：

此时需要查看本地节点的 .ipfs 仓库中的 config 文件，右键用记事本打开后，下图中箭头所指的四位数字就是你的本地网关端口号，使用这个端口号即可。

2.4 使用 FDM 批量下载 IPFS 链接

在安装此油猴脚本的情况下，可以使用 FDM 来批量下载。

FDM (Free Download Manager) 是一款完全免费的下载软件，不会存在破解版 IDM 可能的弹窗问题，这里使用 FDM 来说明如何批量下载已复制的下载链接。

首先在这里下载最新版的 FDM 并安装：

https://files2.freedownloadmanager.org/6/latest/fdm_x64_setup.exe

安装完成后，先复制链接，然后点击右上角的三根横线，然后选择从剪贴板粘贴链接，选择下载路径进行下载即可。

3. IPFS 本地配置

3.1 移动本地文件仓库

IPFS 安装以后，默认会在用户路径（C:\Users\你的用户名）下方创建一个名为 .ipfs 的文件夹，用来存放固定的文件，如果 C 盘空间不足，可以选择移动 IPFS 仓库的默认位置。右键任务栏 IPFS 程序的图标，然后选择 Move Repository Location 即可。

注意移动仓库以后，之前固定的文件会失效，需要重新根据 CID 固定文件（如果忘了 CID 就没办法了，最好先移动仓库再开始固定文件）

3.2 清理非固定文件

当 IPFS 的本地文件过多，可以选择任务栏图标中的 Run Garbage Collector 进行清理，这个操作会清理所有没有在文件选项卡中显示的文件释放磁盘空间。

### 3.3 设置代理以增强安全性

IPFS 相比 BT 来说要更安全，因为节点间通讯经常会中转其他节点，传输内容也有基本的链路加密，但是 IPFS 毕竟并不 像 Tor（洋葱路由）那样专门用来保护隐私安全，IPFS 网络中的其他节点仍然能知道哪些节点在请求或者提供某个 CID，不能完全隐藏 IP 地址。

在使用托管平台托管文件时（第 4 节会讲到），不必担心因为异常流量被运营商查水表（因为流量走的是托管平台），但是总还是有安全性隐患，尤其是发布了需要长期维护的 IPNS 之后。

因此，设置代理以保证安全性是很有必要的。

4. 使用 IPFS 托管平台托管文件

由于 IPFS 类似磁链，属于去中心化的分享方式，假如没人开机做种，就会导致后续的下载者没有办法下载。这种时候可以使用托管平台托管文件，代为“做种”。用法类似于网盘，但是分享不通过分享系统，而是采用 CID 进行，因此没有审核、举报系统，不管文件保存在哪里，只要 CID 匹配就可以下载到文件。

IPFS 的托管平台有很多，和 IPFS 的网关不同，这些托管平台大多数都没有被墙可直连，比如支付加密货币把文件托管给矿工的 Crust 以及基于 Crust 开发的 酸奶网盘 、可以白嫖的 Chainsafe ，这里以后者 https://app.storage.chainsafe.io/ 为例说明，关于 Crust 可以参考 这篇仓库文章[7] 的教程。

4.1 注册 chainsafe 账号

登录以后的界面如下，新注册的账号有 20 GB 的免费额度

4.2 上传并固定文件到 Chainsafe

点击右上角的 Create Bucket，创建一个用于存储文件的 Bucket，然后点击 Upload 选择文件进行上传

视个人网速上传速度可能会有点慢，耐心等待即可。

上传完毕后复制文件的 CID，然后在第 2 个选项卡中固定（PIN）CID，可以给 CID 起名，这个名称是托管平台中显示的名称，与分享的文件名无关。

固定后稍等动作完成

4.3 添加网关发布文件

固定完成后，给 CID 加上相应的网关链接，就得到可以直连下载的分享链接了，下载过程与上文完全一致。

下载链接的格式如下：

1	网关 + CID + ?filename=你想要的文件名.你想要的后缀名

这里给出此平台两种可以用的网关（推荐使用第一个）：

1 2	https://ipfs-chainsafe.dev/ipfs/ https://ipfs.chainsafe.io/ipfs/

分享链接的例子如下：

1	https://ipfs-chainsafe.dev/ipfs/bafybeiasosbjq2mcc73s3e3ccb3apial7i7g2d6yz5maq52m43ge5bibgm?filename=20240724-06-COMIC_BAVEL_202408.7z

4.4 使用 Crust 平台搭配 IPNS 托管文件夹

Chainsafe 一个账号最多只能托管 20GB 的文件，对于大量分享来说还是不太够用的，如果有大量分享的需求，可以使用 Crust 托管平台，关于 Crust 平台的用法可以参考本篇仓库文章：

[技巧分享] [IPFS] 无法被举报的文件分享神器CRUST IPFS操作指南 PART.I

接下来说明一些仅在使用 Crust 平台时推荐的分享技巧。

我们可以使用 CrustFiles 或者 酸奶网盘 把文件分别托管 (又称上链) 到 Crust 网络中，然后通过本地 IPFS 客户端聚合文件以进行管理。

具体来说，先把文件上传到酸奶网盘（或者 CrustFiles ）进行托管，然后再把这些已经托管的文件的 CID 导入并聚合到本地 IPFS 的一个文件夹中（不必固定到本地，这样就不会占用本地空间），这样一来，本地做种只需要做种聚合文件夹即可，使得文件夹中的内容能被 IPFS 网络访问，内容则交由托管平台保存，不占用本地空间。

也因此，在使用托管的情况下 IPFS 的做种比 BT 更轻量，希望大家可以积极帮助他人做种，只需要把别人的文件夹 CID 导入但不固定在本地即可（注意不要改动文件路径中的文件名，否则会导致 CID 发生变化，想重命名进行管理的话，可以新建一个文件夹把东西整个丢进去），这样一来就可以帮助他人保持文件夹路径的可用性。并且由于内容托管在矿工那里，做种不消耗自己的流量，可以减少被运营商查水表的可能性。

由于 IPFS 内容寻址的特性，不同内容的 CID 都是不同的，假如你的内容需要频繁更新，每次都要改链接无疑很不方便。此时可以把聚合文件夹发布到 IPNS，把文件夹的 CID 与 IPNS 地址相关联。

和 CID 不同， IPNS 的地址是不变的，特别适合需要持续更新的内容，其内容需要使用你节点的私钥才能更改，可以当成自己的一个“域名”来使用。并且这个“域名”也是去中心化的，保存在 DHT （分布式哈希表）中，只要你的节点每天至少上一次线，就可以保证这个“域名”可用，和传统的 HTTP 域名不同， IPNS 即使关机也不会造成“域名”无法访问。（如果你有普通域名的的话，也可以把 CID 和域名关联起来，也能保证可用性）

下面是我用 IPNS 发布的 IPFS 分享助手软件，其中 k51…wi25 就是 IPNS “域名”，.eth.sucks 则是子域名形式的公共网关。

https://k51qzi5uqu5dh1ts2qvcw3069src00zyjw0qmwdkb102k8q4ft8bztw75iwi25.eth.sucks

上面是子域名形式的链接，路径形式的链接则应该如下：

https://eth.sucks/ipns/k51qzi5uqu5dh1ts2qvcw3069src00zyjw0qmwdkb102k8q4ft8bztw75iwi25

也可以用本地网关进行访问，子域名形式和路径形式的链接如下：

http://k51qzi5uqu5dh1ts2qvcw3069src00zyjw0qmwdkb102k8q4ft8bztw75iwi25.ipns.localhost:8080

http://127.0.0.1:8080/ipns/k51qzi5uqu5dh1ts2qvcw3069src00zyjw0qmwdkb102k8q4ft8bztw75iwi25

接下来我新生成一个名为 test 的 IPNS 密钥用来发布其他文件夹， IPNS 密钥的地址是固定的，这样每次更新内容后只需要把更新后的文件夹 CID 重新发布一次 IPNS 即可，不用更新链接。

点击发布，然后稍作等待：

复制上面的地址就可以发布了，由于 DHT 网络的广播需要时间，让 IPNS “域名”生效可能需要半个小时至一个小时左右，发布后稍作等待即可。

效果如下

https://cdn.ipfsscan.io/ipns/k51qzi5uqu5dk5cbbjykfthqkz6qh9r98zauauz2n6j843rv3e93fgbfh4abiu

IPNS 可用公共网关

https://gw-seattle.crustcloud.io/ipfs/你的IPNS
https://eth.sucks/ipns/你的IPNS 或者 https://你的IPNS.eth.sucks （分享和谐内容时不建议用这个网关，因为能被举报）
https://flk-ipfs.xyz/ipns/你的IPNS  或者  https://你的IPNS.ipns.flk-ipfs.xyz
https://cdn.ipfsscan.io/ipns/你的IPNS 
https://gw.crustgw.work/ipns/你的IPNS 
https://gw.crust-gateway.xyz/ipns/你的IPNS 
https://gateway.ipfsscan.io/ipns/你的IPNS

4.5 使用 IPFS 分享助手辅助分享

IPFS 分享助手是本人开发的一个小程序，用来简化 IPFS 分享的流程，主要功能有：

CID 批量计算、文件批量导入、CID 批量拉取、CID 格式转换、分享链接批量生成、批量固定到 Crust 等分享相关的一站式功能：

本地文件的 CID 计算：拥有 CID 计算功能，拖入即可计算某个文件的 CID，支持 v0 和 v1 两种格式；
2. 寻找本地最佳网关：可以对 CID 进行网关测速，查找最合适的网关，支持多种常见网关，可自定义网关。
3. 分享链接生成：根据多个 CID 批量生成网关+CID+文件名格式的分享链接
4. 由 CID 从 IPFS 网络拉取文件：可以把被多副本固定在 IPFS 网络中（行话叫”上链“）的文件批量拉取到本地
把本地文件/文件夹添加到 IPFS：支持通过拖拽文件批量添加到本地的 IPFS 仓库
6. IPFS 节点管理：内置 IPFS 节点，无需额外安装，也可连接其他 IPFS 仓库的节点。
7. WebUI 文件管理：可通过 WebUI 查看已上传文件列表，删除文件等，以及其他 IPFS desktop 的原生功能。
8. Crust 平台固定：可以远程固定 CID 到 Crust 网络，通常用于固定聚合文件夹的 CID 来分享大体积资源。

高级计算器及 Crust Pinner

在高级计算器中，还增加了 Crust Pinner 功能，可以使用 Crust 平台提供的远程固定服务，具体可以看这个视频来了解

1	https://youtu.be/Xof9kek1orU

4.6 把 IPFS 当作网盘来用：IPFS 文件管理

经过一段时间的发展，也感谢大家的使用，IPFS 已经逐步开始在仓库推广开来了，但是经过一系列的探索，还是必须得承认，IPFS 相比于传统的网盘还是存在一些不方便的地方，比如，好像不能进行文件管理，没有类似网盘的转存功能，只能下载。文件小还好说，假如文件比较大，想先保存一下，后面再来下载，就很不方便了。

比如说南+有位哥们提到：

1	顺便问问假如有大量资源上传如何进行分类，怎么找到需要的资源，按照文章内容来看貌似获得链接后不保存的话甚至都没地方找

接下来就来讲一下 IPFS 的本地文件管理这个方面问题。

https://cangku.moe/archives/214947

5. IPFS 的优缺点及适用场景的个人浅见

5.1 资源分享的安全级别排名

本人在之前的文章中讨论过分享的几种安全级别，这里简要带过一下：

多层加密压缩包：可以防止网盘扫描，但是无法防止在线解压（手机端可以解压包括 .7z 在内的所有格式）
分卷压缩包及自解压压缩包：无法被在线解压，安全性高于前者。
专有格式加密文件：如 Veracrypt 加密卷等，相比于通用的压缩文件，安全性更高一些。但无法应对举报造成的强制违规。
隐写文件：无法被在线解压，并且违规可申诉，如果被举报到无法分享/下载，申诉即可。安全性高于前述所有。
BT、IPFS 等去中心化分享方案：没有审核系统，安全性最高。但缺点是做不到长时有效稳定。

那么上述这么多级别，应该怎么选择呢？

在机器学习领域有一个定理叫做“没有免费午餐定理”（NFL），是说没有一种算法可以在所有问题上都表现最好。比如说如今的大模型领域都试图得到一个通用的模型实现 AGI，但是就目前而言，在具体下游任务上各种微调模型才是主流，今后可以预见的一段时间内应该也是如此。

回到安全分享这个话题，也是类似的，即不可能存在能够同时兼顾所有场景的分享方案，我们总是需要根据特定场景选择最适合的方案。

对于压缩包方案安全级别问题，我在之前的文章中已经讨论过，这里就不再赘述了，感兴趣可以参看我之前的文章，本文我想重点讨论一下 IPFS 方案的适用场景。

5.2 IPFS 分享方案的优缺点分析

本人对 IPFS 的研究比较浅薄，就站在使用者的角度发表一些浅见，算是以教代学，有不对的地方大家可以指正。

个人认为，IPFS 分享相比于网盘分享，其最大优势在于无法被举报，虽然做不到网盘那样长时有效稳定，但是其去中心化分享的特点令其在应对倒卖者的举报上具有无与伦比的优势。相比于同属去中心化分享的磁链方案，IPFS 可以选择托管平台，也可以自己做种，在托管平台选得比较靠谱的情况下，也可以做到类似于网盘那样的长期保存。

由于 IPFS 类似磁链的去中心化特点，分享的安全性有了很大的保障。即使托管平台被攻击或者跑路，只要网上还有人固定文件（做种），就仍有机会下载。并且相比于磁链完全靠做种，IPFS 可以选择托管也可以选择做种，具有更佳的灵活性，可以减轻分享者的负担。

不过 IPFS 作为去中心化的分享方案，也自然有其该有的缺点：首先靠谱的托管平台不好找，其次如果资源比较冷门没人长时间固定（做种），也会出现类似于磁链那样死种的情况。但是相比于磁链， IPFS 在保种这个问题上已经有很大程度的改进了，因为可以选择托管，做种也不需要公网 IP。

5.3 IPFS 分享方案与网盘分享方案的对比

分析完上述优缺点，我们可以设想一下其适用的最佳场景，在设想之前，我们需要先对比一下网盘分享的方案。

如果我们想进行长期有效稳定的资源分享，网盘一定是最佳选择，因为运营商代替用户保管文件，拿了钱自然要办事。为了更具体的分析，我们需要知道各大个人网盘的市场占比，限于成本问题，只查到了 2022 年的行业报告，虽然不是最新的，也应该能够反映一些问题，我们先看一下各家网盘的知名度：

根据# 2022年中国个人网盘市场研究报告(https://www.iimedia.cn/c400/84607.html)

图中的和彩云是现在的中国移动云盘。

我们可以看到，从数据角度，至少在 2022 年，百度网盘仍以绝对的优势占据了榜首。因此，尽管百度网盘一直被人诟病，但是依然是大部分人心目中“网盘”这个概念的体现，因此也是分享的首选（所谓“不是我非得用百度网盘，而是大家都在用百度网盘”）。

所以，就分享资源的长期有效稳定方面考虑，百度网盘必然是最优选择，但是相应地就存在审核机制。

我在这篇文章中所探讨过，百度网盘的审核机制其实并没有想象中那样严格，对于不分享的显然违规的文件，百度网盘通常是不会管的；对于包含违规文件的分享压缩包，只要无法解密，百度网盘也是不会管的。总之，只要分享的文件不能在线解压，显式地定位到违规文件，百度网盘通常是不会管的。

但是存在一个众所周知的问题：有这么一帮潜藏在各个资源站的特殊行业人群，这些人获取资源后非但不会感谢分享者，还会举报分享文件使之违规炸链，保证只有自己一个来源，然后再对此资源开价售卖。

这帮人就是资源倒卖者，俗称“倒狗/倒爷”。

在百度网盘一家独大的情况下，倒卖者对于百度网盘审核机制的研究也最为深入（所谓盗墓的也一定是半个考古学家），他们充分利用了百度网盘的违规机制（即达到举报阈值自动一刀切），创新性地发明了批量转存+脚本举报的技术，即先转存想要使之违规的文件，然后调用举报脚本，先自动化批量创建分享链接，再以大量账号池组成的海量的举报逐一冲垮文件（类似于 DDoS 攻击）。

倒卖者可以做到全程不下载任何文件，直接就能流水线式地在云端进行转存举报等一系列操作，倒卖者也不需要关注具体举报哪个文件，只需要源源不断地把转存后的文件放入举报池中即可，如此构建起一个简单易操作、成本又可控的举报工作流。只要每天开机运行一遍，就可以让所有举报池中的文件违规（隐写文件因为可申诉，时不时会复活，需要每天都举报）。

目前对于倒卖者的举报，网盘分享方案也确实没有太好的办法，之前试验的各种外网盘（Mega、PikPak、Gofile、ModsFire、MediaFire 等）也纷纷败下阵来。由于外网盘的封禁政策颇为严厉，一炸链就封号，不像国内网盘一般只是禁止该文件分享。出于文件安全角度考虑，分享还是最好选择国内网盘。

不过，根据我最近的一些传火，我发现倒卖者目前处理不了阿里云盘的隐写文件，个人猜测是因为阿里云的举报需要上传截图以及写小作文的原因，想要拿到截图需要下载文件，也需要写小作文跟网盘方说明，这或许导致举报工作流成本不可控。倒卖者是商人，不是恶人，亏本的买卖不好做。不过这也只是目前的结果，毕竟对方可能会孜孜不倦地举报，或者找到了低成本举报的办法，总归是存在隐患。