两台 VPS 的平台限制：条款、机制与约束链

对象：debi = DediRock LA Promo VPS Special（Atlas Cloud LLC，$10.88/yr，Virtualizor）· shoc = Shock Hosting SSD-KVM-2GB 洛杉矶（$20/yr，SolusVM）
盘点与原文复核日期：2026-11-10（条款以当日抓取版本为准，两家均声明可不经通知修订）· 本文是经验文，不是法务意见：原文标原文、推断标推断
底稿：经验文档《平台限制盘点》（proxy-node 主题），本页为扩展版——新增三节深化：禁 CDN/流媒体的机制、满载到底多久、敏感性分层与约束链，并含 vidlib 谷歌归档线的环节级复核，与在两台上搭邮件服务器的三层可行性专节

先说结构性差异：两家的条款不是一个物种

Shock 有独立 AUP + 独立 ToS，AUP 内有 VPS 专节，禁止清单是全网罗列式、写得细——所以 Shock 的结论多为明文。DediRock 只有一份 ToS，正文大量是共享主机（shared hosting）时代的样板条款（「User may not」清单多条明写 on shared servers），几乎没有 VPS 专章——所以 DediRock 的结论多为未明文。
两家都有兜底条款（商家自称唯一裁判、可无通知停机、上游政策并入）。因此全文的铁律是：未明文 ≠ 允许。未明文项的实际风险由兜底条款 + 投诉触发机制决定。

一、两家限制对照总表（盘点结论压缩版）

维度	DediRock（debi）	Shock（shoc）
自用鉴权代理（密码、仅本人）	未明文 ToS 通篇无 proxy/VPN 字样	未明文（相邻明文）明文禁的是「Open proxies」；封闭自用代理字面不撞
公开/开放代理	未明文	禁止（明文） Open proxies，无警告停机口径
VPN 自用 / Tailscale exit	未明文	未明文 AUP 的「Unauthorized GRE tunnelling」与 WireGuard 无关，勿误读
端口/漏洞扫描	未明文但有「无授权连接第三方系统可停机」的宽泛句；实际执行由上游投诉驱动（见第四节）	禁止（明文） Network/port scanning、Vulnerability scanning、Bruteforcing
爬虫/抓取	限制（含糊） spider 禁令明文限定 on shared servers，对 KVM 的适用性未明文	部分禁止（明文） Social media crawlers 明文禁；一般网站爬虫未点名
邮件 / spam	限制（明文严厉） spam 零容忍可即时终止；账户致 IP 段被拉黑 → 立即停机 + 可收清理费	限制（明文）禁 mass unsolicited e-mail 等；致 IP 段进黑名单可停机/终止
25 端口	未明文无端口封锁清单	未被封（KB 反证）永久封锁只有 TCP&UDP 17/19/111/1900、UDP 11211/53413，25 不在内
Tor	未明文	exit 禁止（明文） TOR exit nodes；relay 未明文
挖矿	未明文	禁止（明文） *coin mining；连 Folding@Home / World Community Grid 也点名禁
版权 / DMCA	限制（明文）侵权移除、重复侵权停机/终止，投诉走 abuse@	禁止（明文）托管版权内容、乃至「链接到盗版内容」都在清单
文件托管 / 存储	限制（共享口径）「shared account 作备份/存储设备」禁，限定 shared；VPS 未明文	禁止（明文）「Any form of file hosting, file storage, cyberlocker, leeching or similar activity」全网口径
视频流 / CDN	未明文	禁止（明文） Video streaming、Content delivery networks (CDN)——机制见第二节
月流量 / 超量后果	≈4 TB/月双向合计（工单翻倍实证）；超量后果未明文	2 TB/月双向合计（订单实证）；超量后果未明文
CPU 持续满载	未明文（对 VPS）唯一数字「25%/90 秒」是共享条目，不适用 KVM——见第三节防误引	限制（明文，VPS 专节）无数字、纯裁量：持续 + 长时间 + 影响邻居 → 工单 → 重则关停——见第三节
投诉响应义务	限制（明文流程） abuse 邮件 24 小时不回可停机/终止	限制（明文）不确认 abuse 工单 → suspend
转售 / 账号	限制（分层明文）共享账户不得转售；VPS 本身转售未明文；优惠码滥用可停机	未明文客户转售/多开均未提
退款	未明文 ToS 无退款保证条款	限制（明文） 7 天、仅首张发票、支付宝/微信/crypto 不可退
兜底	两家同构：商家为唯一裁判；可无通知停机/终止；DediRock 另明文「违反上游/数据中心政策可无通知停机」——上游政策经此并入（社区有上游投诉驱动的批量停机实证，④级）；Shock AUP 自称「not meant to be exhaustive」，未写明的违规行为同样可禁

本方实测旁证（③级，不构成许可）：两台自购入起持续运行自用鉴权代理与 Tailscale exit，截至 2026-11-10 未收到两家任何警告工单——只说明尚未被处置。

二、为什么禁 CDN 与视频流（Shock）

Shock 的清单把「Video streaming」「Content delivery networks (CDN)」「Any form of file hosting…」并列在一处。这不是道德判断，是成本与风险的算术。把 VPS 当分发基础设施用，会同时引爆四件事：

1. 带宽成本结构：$20/年的盘子装不下分发量

低价 VPS 的带宽是按批发价整批买来、靠超售比摊薄的：定价假设是绝大多数客户只用配额的零头。视频与 CDN 的流量形态恰好相反——持续大出站（注意出站才是分发的方向，中转流量在双向合计的商家表上还天然记两遍）。一个客户把 2 TB 配额全部拿去做分发，消耗的上行批发成本就可能超过他全年付的钱。禁的不是「视频」这个内容品类，禁的是把配额当分发管道烧完的用法。

2. 滥用磁铁：公开分发是投诉的头号来源

公开可达的文件托管/流媒体是 DMCA 投诉、版权方自动监测（内容指纹 + 链接爬取）、支付通道风控的第一落点。一家小主机商的 abuse 部门人力有限，每封投诉都要处理、每次 IP 段被标记都伤全体客户——直接在条款层把整个品类关掉，是最便宜的风控。Shock 甚至把「linking to pirated content」都写进清单，就是这个逻辑：连磁铁的引线都剪掉。

3. 邻居效应：分发流量挤占的是共享端口与上行

消费级 VPS 的 1 Gbps 是共享端口。一个租户持续跑满出站，整台宿主机上其他租户的晚高峰体验一起遭殃——这与第三节的资源专节是同一条线：分发类用途是「持续 + 大流量」的典型形态，所以被单独点名，而不是留给 fair-use 裁量慢慢处理。

4. 界线在哪：禁的是「把 VPS 当分发基础设施」，不是「数据流过」

清单三项的共同分母是 distribution：存储在本机、向不特定或大量接收端持续分发。反过来，自用回放（如 Navidrome 只给自己的手机放歌：接收端 1 人、低码率、间歇）与「视频流服务」之间，字面距离和实质距离是两回事，必须分开判：

字面：「Video streaming」四字若按最宽读法，一切视频数据流出都算——Shock 没给出流量/受众门槛，字面空间在它那边（AUP 自称非穷尽 + 唯一裁判）。
实质：判断口径看三件事——公开性（是否对不特定人开放）、持续带宽（是否长期大出站）、投诉暴露面（内容是否侵权敏感、是否可被自动监测定位）。三项全低时，它与商家真正要防的形态（成本烧穿 + 投诉磁铁 + 邻居挤占）距离很远；任何一项拉高，距离迅速消失。
本方落点：Navidrome 这类自用回放目前只在 debi（DediRock 侧此项未明文，对照即在此）；即便只看实质，它也不该迁去 shoc——不是因为「放歌」本身，而是没必要把一个字面沾边的形态放进裁量权在对方手里的环境，见第六节复核同理。

辨析：代理看视频与经 Drive 看视频，禁令到底禁哪个（2026-11-10 补，用户追问）

问题：用自家封闭代理看 YouTube，和经 vidlib 从 Google Drive 拉流回放——同样是视频字节流过 VPS，商家分得清吗？Shock 清单里那句「Video streaming」，是不是等于「连用代理看视频也不行」？

流量层：没有区别——先承认这一点

两种形态在 VPS 的网卡上是同一种东西：持续、大码率、全程 TLS 加密的视频字节流。商家能看见的只有方向、速率、时长与对端，看不见内容（加密）、看不见业务语义；深包检测顶多从握手指纹猜出「像视频」，分不出这串字节是「代理转发途中的一段」还是「流媒体源站在分发」。任何声称「技术上能分清」的说法都是假的：禁令的执行从一开始就不建立在流量识别上——它靠的是服务形态（你有没有在运营一个分发端点）与投诉（有没有人找上门），下面四点才是定性的全部依据。

定性层：区别在服务形态，不在字节

源头 vs 中转：经代理观看时，内容源头是 YouTube／Google 的服务器，VPS 只是过路的 transit——字节不驻留、无内容目录、不对外提供点播接口，流一停什么都不剩。经 Drive 回放走应用中继时（vidlib 的 /file/ 中继路径），VPS 是分发链的最后一环：身后挂着自己的内容库与播放接口（/api/play/），请求进来、由它回源拉流再转出——即便观众只有本人一人，形态上也是「运营了一个流媒体端点」。
受众与可达性：代理观看侧是封闭鉴权、仅本人（一对一、凭据门后）；分发端点的形态定义是「备好内容，等请求来取」——本方部署的播放接口同样在鉴权门后，但它多了一层「端点 + 库」的服务结构，这层结构才是条款语言描述的对象。
投诉向量（商家真正怕的东西）：对外分发会让商家 IP 以「分发者」身份出现在版权方的自动监测与 DMCA 投诉里——第二节说的磁铁就是这么吸过来的。代理观看时，源站眼里这台 VPS 的 IP 只是一个观众：YouTube 看到的是一个在看视频的客户端，不产生任何「分发」指认；投诉链根本不会启动，分发指认无从谈起。
流量上限的来源不同：代理观看的总量被人的观看时长 × 码率自然封顶——一天看几小时就是几小时的流，且间歇。商家对分发服务的风险想象是另一种曲线：24/7 对外持续供给、与接收端人数成正比、可以无人值守地烧。禁令定价的是后一种曲线。

那么「禁视频流」等于「不能用代理看视频」吗——不等于

论据一·清单语境（解释）：「Video streaming」的邻居词条是 CDN、file hosting、cyberlocker、leeching——清一色「对外提供服务」的品类。按同类解释，这一条指「运营流媒体服务」，不是「有视频字节过境」。若按最宽读法（任何视频流流过即违规），经 VPS 的远程桌面、视频会议、乃至把自己拍的视频文件下载回家都一并违规——解释上不成立，商家自己的日常运维流量都过不了这条线。
论据二·原文结构（原文）：清单把「Open proxies」单列规制——代理在立法者那里有自己的品类条目，而且只禁 open 的。若「代理过境视频」本就被 streaming 条覆盖，open proxies 单列便没有必要；结构上，立法者明确区分了「代理」与「流媒体服务」两个品类。封闭自用代理观看属于代理品类的普通用途，落在代理条目的字面之外。

诚实边界（这一段与上面的论据同等重要）

Shock 的 AUP 自称非穷尽 + 自家为唯一裁判，ToS 另有「for any reason 无通知终止」。按最宽字面执行的空间客观存在，普通用户对此没有对抗手段——两条论据能说明「通常含义与行业执行惯例下不构成违规」，说明不了「商家永远不会这么执行」。
故本节的定级与盘点既有口径保持一致：自用封闭代理（经它看视频在内）= 字面有过度解读空间、实质与行业执行惯例低风险，与 open proxies「贴身相邻」（见第五节对照表与盘点第一节）。不写「明确允许」，不写「绝对安全」。
反过来也一样诚实：把 Drive 播放迁到 shoc，即便观众只有本人、流量再小，撞的也是形态（运营端点）而非流量——第六节 C 级的定性不因「只有我一个人看」而改变。

本方部署的对应关系（含一处现行实现的查证）

代理观看：走任意节点的封闭鉴权代理，是 shoc 订阅流量的日常形态——它与 streaming 条款的距离，就是本节辨析的全部内容：形态上属于代理品类，不属于分发品类。
Drive 播放（vidlib，仅 debi）：查证结论（2026-11-10 读现行代码，③）——播放是前端直连优先：/api/play/ 先经 AList 取签名链接，能拿到指向公网的直链（Google 直链）时把链接原样交前端，浏览器直接从 Google 拉流、字节不过 debi；只有直链不可用（链接是 AList 本地形态）时，才回落到 debi 自己域名下的 /d/、/p/ 路由经回环 AList 转出，或链接解析整体失败时回落应用自身的 /file/ 中继（服务器端代理拉流）；Subsonic 的 /rest/stream 走同一逻辑（302 直链优先、失败回落同一中继函数）——音乐播放同此形态。即 debi 的分发暴露面比「全量中继」小一截：常态下它只签发链接、不搬字节。但形态定性不变——端点与库仍在 debi 上运营，「运营流媒体端点」的判断不因直连优先而消失，所以它留 debi 的结论（第六节）不依赖流量大小。
一句收束：现行分法与条款的品类划分正好对齐——观看走代理（transit），端点留 debi（distribution 只出现在未明文的一侧）；shoc 上只有过境、没有端点。这不是巧合，是第四节约束链走完之后的自然落点。

三、满载限制到底多长时间

Shock：原文没有任何数字——这是裁量条款，不是阈值条款

2026-11-10 回 AUP 原文逐字复核（含 KB、ToS 再核）：VPS 口径下不存在分钟数、小时数或百分比阈值。VPS 专节「Server Resources」全文（原文）：

On our VPS platform, CPU, network and disk I/O are shared among other users on the same node. If your VPS is persistently using these resource(s) for a prolonged period of time and/or disrupting the experience of other users sharing the same node, we will notify you to reduce your usage via ticket. Severe cases may result in your VPS being rebooted, shutdown and/or suspended. Failure to acknowledge an abuse ticket will result in a suspension of your VPS.

KB 无补充数字：KB 里唯一的资源限额文章《What are the account resource limits?》写的是 cPanel 共享主机的 CloudLinux 限额（CPU 100%/200% 等），与 KVM VPS 无关——不要拿它当 VPS 的线。
禁止清单侧：另有泛述的「Resource intensive activities (CPU, I/O, Network etc)」列在 Prohibited Uses 里（无警告停机口径）——它与 VPS 专节的关系，原文没有交代何时用哪条；保守读法：专节是常态通道（先工单），清单条是商家保留的快速通道。
Fair Usage 节同样无数字：只有「more than is considered realistic or reasonable」→ 工单通知降量；且该节主体是 unlimited 共享主机话术，对 VPS 以专节为准读。

裁量条款的触发要素拆开看（全部出自原文措辞）：① 持续性 persistently——不是峰值，是反复/不间断；② 时长 prolonged period——原文不给数；③ 邻居影响 disrupting the experience of other users——与前两条是 and/or 关系，即只要实际影响到邻居，前两条可以不齐备；④ 工单回应——先通知、给降量机会，但不确认工单本身就停机；⑤ 处置梯度：工单 →（严重）reboot / shutdown / suspend。

DediRock：防误引——「25%/90 秒」不是 VPS 的线

ToS「User may not」第 1 条确有数字：「Use 25% or more of system resources for longer than 90 seconds」。但同清单的邻居条目全是共享主机语境（第 3 条 spider 明写 on shared servers、第 5 条 torrent 限定 our shared servers、inode 25 万上限明写 shared account），全文没有任何一句把这份清单适用到 KVM VPS；VPS 另有的只有一句「best-effort basis… No specific uptime percentage or SLA is guaranteed for promotional or budget VPS services」。结论保持盘点原判：debi 侧不存在可引用的 VPS CPU fair-use 明文。谁引用「25%/90 秒」说 debi 的 VPS 满载线，是误引。

我方安全线（推得，非原文——与上面原文部分严格分开）

分钟级满载测试无碍：两台的 steal 复测、跑分都是分钟级、错峰、盯探针——既不满足 persistently，也未影响邻居（本方实测，未收到任何工单，③级旁证）。
小时级持续满载即进入裁量区（shoc）：不是因为有数字线，而是「persistently + prolonged」的最自然读法从小时量级开始成立；再叠加邻居影响（and/or），线只会更靠前。
探针纪律如何对应：本方 cpu-probe 的告警线是 busy ≥85% 持续 20 分钟——这条自律线远严于条款的裁量区：探针先于商家发现问题。守住的办法不是背条款数字（没有数字可背），是让自己的负载形态永远落在「间歇、分钟级峰值」这一侧，并对任何 abuse 工单第一时间响应（两家都把「不回工单」写成了独立停机事由，这一条比满载本身更硬）。

四、不同操作的敏感性：不是一家说了算，要过整条约束链

判断一个操作能不能做，只查主机商条款是查了最外一层。完整的约束链由外向内是五层，每层的执行者、触发方式、后果都不一样——很多操作死在里层，与主机商无关。

敏感性分层（由低到高）与平台为什么敏感

层级	典型操作	平台为什么敏感
1 · 最低	纯自用封闭代理（鉴权、仅本人）	流量形态与普通应用接近、不对外开放、无投诉入口；敏感点只剩「像不像代理」——所以禁令通常只点名 open proxies
2 · 低	个人抓取（低频、个人归档）	投诉可达性低（目标站多半只封 IP 了事）；但目标平台 ToS 与版权方在另一层等着（见下表）
3 · 中	出口节点（Tailscale exit 等）	你的出口 IP 替「另一台设备」的全部流量背锅：下游行为的投诉、黑名单都记在节点 IP 头上
4 · 中高	公开中继（Tor relay、公共代理池）	为不特定第三人转发 = 投诉与滥用流量的汇入点；exit 更是法律文书的第一收件人，故 relay 与 exit 常被区别对待（Shock 即是：只点名 exit）
5 · 高	文件分发 / 流媒体 / CDN	三敏感叠加：带宽成本可测地烧、DMCA 投诉自动找上门、邻居带宽被挤——第二节的四件事全占
6 · 很高	扫描（端口/漏洞）	在多数网络的规则里与攻击行为不可区分，上游与目标网络都会自动报警；不需要受害者投诉，机器自己触发
7 · 最高	挖矿 / 群发（spam）	挖矿 = 纯资源变现，与商家卖的东西正面冲突且零邻居价值；群发 = 直接毒害 IP 段声誉，伤全体客户——两家对 spam 都是最硬口径，与此对应

分层是经验框架（推断），排序依据是四种敏感源的叠加程度：投诉可达性（受害者/权利方能不能找到商家）、计费可测性（成本能不能在计量表上直接看见）、法律暴露（文书与责任是否落到商家）、上游连带（会不会连累商家自己的上游与 IP 段）。

约束链：五层对照

约束层	执行者	触发方式	典型后果	本方实例
① 主机商条款（ToS/AUP）	商家 abuse/风控部门	自动监控（资源/流量形态）或投诉转办	工单警告 → 限速/重启 → 停机/终止	Shock 禁止清单与 VPS 资源专节；DediRock 的兜底裁量
② 上游 / 数据中心政策	机房与上游运营商（如 ColoCrossing）	上游收到投诉/监测后向下压：要求商家处置其客户	商家为保上游关系批量停机，申诉链条更长	DediRock ToS 明文并入上游政策；社区实证（④）其 VPS 曾因上游 abuse 报告（含 port scanning、UCE）被批量停、7 天未解决即终止
③ IP 段声誉 / 黑名单体系	各黑名单与信誉库（ROKSO、Spamhaus 类）、目标站风控	自动收录：spam、扫描、滥用流量被任意一站报告即可	IP 段进名单 → 段内所有客户连带受损 → 商家反过来立即停掉肇事账户	两家都把「致我方 IP 段被拉黑」写成即时停机事由（DediRock 还可收清理费）
④ 支付通道风控	卡组织 / PayPal / 收单方	拒付率、业务品类审查、投诉	商家收款通道被限/被关 → 商家对高风险品类一刀切	文件托管/流媒体被禁的隐形推手之一；本方 $20 单用卡支付、退款条款里 crypto/支付宝不可退也是通道成本的形状
⑤ 目标平台 ToS（对侧）	Google、YouTube、知乎等目标平台	账号风控、接口封禁、ToS 执行潮	封号/封接口——与主机商无关，机器再合规也救不了账号	Antigravity 的风险在 Google 侧（第三方接入禁令）；vidlib/zhihu 抓取的版权与接口风险在内容平台侧
⑥ 属地法律	执法与权利人（DMCA、法院、国别法规）	DMCA 通知、法院命令、执法请求	内容移除、数据披露、账户终止；商家依法配合、不替客户扛	两家 ToS 均写明配合执法披露订户信息；DediRock 引 Section 230 的同时把法院定性作为移除依据

一句话主线

一个操作要落地，先在脑子里把这条链走完：主机商看形态、上游看投诉、黑名单看记录、支付看品类、对侧平台看账号、法律看内容。任何一层说不，整个操作就不成立；而「主机商没写禁」只意味着第一层暂时没说话。

逐类深挖（2026-11-10 补，用户点名）：两类最容易误判的行为

（本小节是本节 v1 框架的逐类展开：v1 给了分层与约束链，本小节把其中两类——位于分层表最高档的群发、与分发层只有一线之隔的 BT——按同一小结构拆透：机制 / 检测与执法 / 两家条款落点 / 与本方部署的距离。）

深挖一：垃圾邮件 / 群发——它不是流量问题，是 IP 段的声誉连坐

平台为何敏感（机制）：spam 的危害计量单位不是这台机器、是整个 IP 段乃至 ASN 的邮件可达性。Spamhaus 一类 RBL 的收录常以段为粒度：一台机发 spam，段被列入名单，同段所有客户的正常邮件一起进垃圾箱、被退信——商家卖的每台机器都附带「IP 能正常发信/被主流服务接受」这份隐性价值，spam 是在毒化全体客户共用的资产。这正是它在分层表里与挖矿并列最高档的原因：不是它多耗资源，而是它伤别人、且伤得不可逆（除名要走申诉、耗时以周计）。
检测与执法如何运作：三条自动回路——① 出站 25 端口监控：发信量异常是最廉价的信号，多数机房对 25 端口有量级监控或默认节流；② 投诉回路（FBL）：大邮箱服务商把用户点「举报垃圾邮件」的回执自动回送发信方网络，商家不靠人举报、靠机器回执就知道哪台机在发；③ RBL 自动巡检：商家定期扫自家段是否上榜，上榜即定位肇事账户。三条都是自动触发，不需要受害者找上门。
两家条款落点（原文）：DediRock 是现成的整套原文（盘点第四节）——对 spam 零容忍、可即时终止；「账户致其 IP 段被拉黑 → 立即停机/终止」，且可收 blacklist cleanup fee：连坐逻辑被商家自己写进了条款。Shock 同向：禁 mass unsolicited e-mail、mail/SMS bombers；致其域名/IP 段进黑名单可停机、调查后可终止。25 端口的实际状态（盘点已对齐）：Shock 的全网永久封锁清单里没有 25；DediRock 对端口封锁未明文——端口开着不等于发信自由，约束在行为与声誉层，不在端口层。
与本方部署的距离：两台都不发信（无任何邮件用途），看似离这一类最远——但真正的相邻面不在「发不发」，在「会不会变成」：任何一台被入侵的机器，攻击者最先变现的用途之一就是当 spam 跳板，届时零容忍 + 段连坐 + 清理费全套瞬间与本方有关。对自用机的真实启示只有一句：安全卫生即合规——补丁、密钥纪律、异常出站的察觉（探针之外留意 25 端口出站），守的不是抽象安全，是这一类条款的触发线。

一句结论：spam 的定级不看你发了多少，看你的段因此被毒了多深——所以商家对它的处置永远是全场最快、最不讲情面的。

深挖二：BT/PT——下载不敏感，做种才是把自己变成公开分发者

平台为何敏感（机制）：必须把 BT 拆成两半看。下载本身敏感性中等（入站为主、形态与大文件下载无异）；做种（上传分发）才是高敏感的那一半：BT 协议的设计就是每个下载者同时是对 swarm 公众的上传者——你按下下载的那一刻，协议已经替你成为了分发者，不需要任何「我要分享」的额外决定。这是普通用户最容易无意中踩到的公开分发：没有搭站、没有发布链接，仅仅「下完没关客户端」就在持续做种，正对应分层表第 5 层（文件分发）。另外两笔账：DHT/PEX 让客户端持续与大量陌生对端建连，连接形态与扫描有几分像（第六类敏感源的上游连带会被勾动）；长期做种 = 持续出站，撞的还是资源专节那条裁量线。
检测与执法如何运作：版权方的监测不需要商家配合：监测公司自己加入 swarm，记录每个 peer 的 IP 与分发的内容指纹，投诉按 IP 直达其所属商家——商家是被动收件方，处置压力来自 DMCA 流程与重复侵权条款。换言之，BT 做种的投诉链是所有行为里最自动化、最不依赖他人举报的一条，与深挖一的 RBL 巡检同属「机器触发」型。
两家条款落点（以盘点既有证据为准）：Shock 无 BT 专条——做种形态落到「Copyrighted content hosting and/or linking」与 file hosting 的兜底裁量里判，没有专条不等于没有线，线在版权那一行。DediRock 的 torrent 条目在共享主机语境清单里、对 KVM 未明文（盘点第四节，防误引同第三节）；它对 debi 的实际约束形态是投诉响应机制：abuse 邮件 24 小时不回可停机/终止——BT 投诉进来，考验的不是你有没有做种条款，是你回不回工单。
与本方部署的距离：现行两台无任何 BT 用途，距离为满格。只留一句换位提醒：在哪跑，账完全不同——若将来在家里 Mac/家宽上跑 BT，约束链换了一套（家宽无 VPS 式 AUP 的分发条款，但版权投诉改走 ISP、后果是 ISP 警告乃至断网，且家宽 IP 与全家设备共担声誉）；在 VPS 上跑，则是本节这套账。选址即选约束，先想清楚再开客户端。

一句结论：BT 的敏感性不在「下」，在协议默认替你「传」——关掉做种，敏感性掉一半还多；开着做种，你就是分层表第 5 层的一员，与自建分发站同罪同罚。

五、现行用途对照（三档）

现行用途	debi（DediRock）	shoc（Shock）
自用鉴权代理（AnyTLS/Hy2）	未明文但低风险	未明文但低风险（贴身相邻：禁的是 open proxies，字面不撞、裁量在对方）
Tailscale exit node	未明文但低风险	未明文但低风险（GRE 禁令无关）
apirelay（自有 API 聚合、token 鉴权）	未明文但低风险	未明文但低风险（有 token 门，不是 open proxy）
subconv（拉机场订阅 + 连通性测速）	未明文但低风险	未明文但低风险——测的是自有/订阅节点的连通性，不是端口扫描；不要演变为扫描器
vidlib / zhihu 抓取（个人归档）	未明文但低风险（spider 禁令限定 shared；风险在版权投诉兜底与对侧平台层）	不在 shoc 上跑
平台文件类（transfer、AList 本地库、Navidrome，均仅 debi）	未明文但低风险（存储禁令限定 shared account）	有明文风险（若迁）：本机存储 + 本机分发形态正面撞清单——不迁（云端归档形态另判，见第六节）
Antigravity 适配（仅 debi）	对主机商：未明文但低风险；真风险在约束链第五层（Google 侧）	不在 shoc（已摘除）
订阅文件托管（/sub 静态小文件）	明确安全	明确安全（体量口径）：配置文件分发、非 AUP 语境的 file hosting 服务；字面最宽解释有过度解读空间，备查
批量/重活（CPU 类）	未明文但低风险（VPS 无 CPU 明文条款 + 本方探针自律）	有明文约束（非现行违规）：资源专节裁量线在头上——不长期满载即不触发，靠探针纪律守（第三节）

六、复核：vidlib 谷歌归档线能不能搬去 shoc

（2026-11-10 10:20 用户追问触发的环节级复核；本节修正盘点早期「文件类不能迁」的笼统口径，盘点 md 已同步修正。）

问题：vidlib 的归档线是——文件经 AList 上传存入 Google Drive（对象以 hash 名存在 Drive 上）、本地只留数据库与元数据、在线播放经 AList 签名链接直出。它是否真的不能搬去 shoc？用户的论点：上传（把文件写进 Drive）不属于禁止清单任何一项；播放继续留 debi、只迁上传行不行？

结论先行：用户论点成立。「文件/流媒体类应用不能迁 shoc」这句只对「本机存文件 + 本机对外分发」形态成立（transfer 本地部分、AList 本地库、Navidrome 镜像库属此列）；对「上传中转 + 云端存储」形态必须逐环节另判。拆开看，这条线四个环节里只有「播放分发」正面撞清单——而它本来就可以不迁。

环节	在 shoc 上实际发生什么	对 Shock 清单字面
上传	应用把字节流出站写进 Google Drive	不沾边：清单禁的是以本机为存储/分发点对外提供文件（hosting 的通常含义）；出站写第三方云盘不在任何一项字面内。字面最宽解释的唯一备查点是文件条款里的「leeching or similar」——leeching 在托管 AUP 语境通常指文件托管生态的代下载/直链生成，与「抓取 → 转存自有云盘」距离较远；属裁量备查，不改判级（解释，非原文）
存储	对象在 Google 的盘上；shoc 盘上没有文件库	不沾边：「file storage」指控的是存储服务本身——这里提供存储的是 Google，shoc 不是存储方
索引数据库与元数据	本地 SQLite 库 + 条目元数据	完全不沾边：任何 VPS 应用都有自己的数据库；若这也算 file storage，一切带库的应用都违规——清单的通常含义不是这个
在线播放分发	观看端经签名链接拉流回放（回源 Drive 转出）	正面撞：「Video streaming」+ 分发形态的 file hosting。此环节留 debi 是整个拆法的关键

真正的约束是流量形态，不是内容条款

批量归档上传 = 持续大出站。内容清单字面不禁它，但第三节那条 VPS 资源专节把 network 与 CPU/IO 并列写进了「persistently prolonged + disrupting」裁量线——大批量补库若持续满速跑数小时，撞的是资源专节，不是禁止清单。量级判断（形态判断，非实测月度数）：日常增量归档是 GB 级以下、分钟级的间歇出站，与普通应用无异；一次性全量重传（现库 4000+ 文件的历史积累量级）是持续小时级大出站，不可接受——但那本来也不会发生。安全形态 = 增量 + 限速分批 + 探针纪律，与「备份上传」同性质。

实速注脚：这条线物理上很难高占用（2026-11-10 补，本方实测）

用户补了一个物理论点：这条线的速率被两头夹住——文件从国内直连发到 VPS 的入站速度、与 Google Drive 的接收速度，都远低于把出站顶满所需的量级。本方实测支持这个论点（证据等级 ③，均为 debi 侧实测）：

入站（国内客户端 → VPS）约 0.9 MB/s：vidlib 上传访问日志，2026-11-07 晚高峰一场 570 个完成的上传会话，其中 3 个 ≥100 MB 的大文件（252 / 176 / 126 MB）端到端速率 0.86 / 0.84 / 1.05 MB/s（聚合 0.89 MB/s ≈ 7 Mbps）——这正是 debi 国内入站路径的已知伤。注意这头是 debi 的瓶颈：shoc 的国内入站好得多（用户实测其 Tailscale 出口约 250 Mbps 为旁证），若上传环节迁到 shoc，这一头会松开。
出站写 Drive（VPS → Google Drive）端到端上限约 4.7–8.8 MB/s：生产归档记录（vidlib files 表时间戳，2026-11-07）三个大文件 8.30 / 8.75 / 8.05 MB/s；2026-11-10 复测（48 MiB 随机文件经 AList 写 Drive，远端确认存在后已删除、本地已删，测试流量约 48 MB 已计入本月）10.7 秒、4.72 MB/s ≈ 38 Mbps。两组测得的不是同一个单点，而是同一量级：端到端上限为 4.7–8.8 MB/s 区间，约 38–70 Mbps，约为 1 Gbps 端口的 4–7%——单点取 9 是高估，区间表述为准（端到端量测，无法分解归因到 Drive / AList / 路径中的哪一方；不影响结论。一般知识另注：Drive 另有 API 配额与单账号日上传量级的天花板，与此处测得的速率上限是两回事。）
形态是分段、不是流式：客户端分块先落盘成完整文件（staging），再由归档 worker（3 并发）从本地文件经 AList 写入 Drive。出站段不被入站实时节流，但被两件事封顶：Drive 侧约 4.7–8.8 MB/s 的速率上限，与待归档存量的深度——而存量只能由入站以约 0.9 MB/s 灌入，攒出一小时满速的存量需约 17–32 GB（按 4.7 与 8.8 两端各算），要先连续灌入约 5–10 小时。实际量级：本库 2026-11-04 至 11-09 共归档 20.5 GB；最大的三个文件入站耗时合计约 10 分钟，归档段合计仅约 64 秒。

对 B 级的影响：成立条件收窄。自然使用形态（边收边传）下，出站被入站节流在约 1 MB/s 量级、且间歇；即便上传迁到 shoc、入站松开，全程上限也只剩 Drive 侧的约 5–9 MB/s。B 不删除：人为先攒下大批存量再集中放行，仍可构造出小时级约 5–9 MB/s 的持续出站——那是刻意构造，不是这条线的自然形态；B 的实际上限由链路物理决定，不由客户端意愿决定。

裁决分级

A（字面与实质都干净）：只迁上传 + 索引库、播放留 debi、增量节制（限速分批）——实质就是「普通应用 + 出站写云盘」。
B（字面干净、实质看资源专节）：同 A 但长期大批量持续满速上传——内容条款仍不撞，风险转移到资源专节的网络持续占用裁量，即第四节约束链的第①层里侧（其成立条件经上「实速注脚」收窄：自然形态下难以出现，刻意攒存量集中放行才构成）。
C（真撞线）：连播放在一起迁——「Video streaming」正面命中，不可。

旧表述，保留演变痕迹

transfer 一句话定位：混合形态——本地落盘暂存 + 对外下载分发端点属「本机存储 + 本机分发」，沾字面；其 Drive 直传部分与 vidlib 上传环节同判（干净）。整体仍以不迁为稳妥，理由在落盘与分发端点，不在 Drive 部分。

整线迁移的实质账：实际上能不能整条线都搬过去（2026-11-10 补，用户追问）

问题：拆开判每个环节都干净或低风险，那把 vidlib 整条线——上传 + 存储索引 + 播放入口全套——迁到 shoc，实际上是不是也行？按第二节辨析自己的逻辑（定性看服务形态与投诉向量、不看字节）把账算完，结论是：整线在 shoc 的真实暴露面，小于上面 C 级按字面给出的判断。

为什么暴露面小于字面判断

播放入口不在公开面：它长在平台层鉴权之后（面板 gate／直连码），不是无门对外开放的端点；链接带签名、观众只有本人。
无公开目录、无分发指认来源：没有对外可爬的内容目录，没有第三方观众，版权监测与 DMCA 投诉找不到「以商家 IP 为分发者」的指认路径——第二节说的磁铁在这里没有引线（指认逻辑见第二节定性四点）。
流量双重封顶：被观看时长（人的上限）与链路瓶颈双重压住——入站约 0.9 MB/s、Drive 侧端到端约 4.7–8.8 MB/s 区间（实测见上「实速注脚」），构造不出 24/7 对外供给的曲线。

合起来：整线是「带播放界面的私人库」，不是清单语境里的「公开流媒体服务」。C 级的旧表述按「播放入口 = Video streaming」的字面归类定级；按形态与投诉向量复核，它应改述为——

C′（改述，2026-11-10）：整线迁 shoc = 字面最宽读法撞线、实质暴露面小；现阶段不迁的决定性理由是平台耦合与观察期裁定（工程账），不是条款本身（条款账）。

保留的真实摩擦（如实列，不因改述而消失）

① 条款账的残余：AUP 一方解释权 + 无通知停机兜底仍在，最宽字面执行的空间不可消除。C′ 的定级只能是「实质低风险、非零字面空间」，与第二节「诚实边界」同口径——不许读成「安全」。
② 耦合现实（今天字面不可执行）：App Hub 平台本体在 debi、不在迁移面内；vidlib 是跑在面板之下的 /web 项目——播放页与库管理长在平台里，整线迁移在今天就是搬不动，除非先把 vidlib 脱离面板独立部署（工程上可行，但那是另一笔账，见 ③）。AList 本身是独立服务、可迁，但它不是 vidlib 的全部。
③ 两个决定不要混成一句：2026-11-10 的观察期裁定（平台留 debi、新重活默认落 shoc、12 月初再决策）是工程／组织决定；「播放入口在条款层面实质低风险」是条款判断。前者说「现在不搬」，后者说「条款并不构成搬不动的理由」——两者不冲突，也不可互相冒充：将来若为 vidlib 做独立部署，条款账按 C′ 已经算清，剩下的只是工程账。

七、在这两台 VPS 上搭邮件服务器：能搭，但「能搭」不等于「能投」（2026-11-10 补，用户追问）

（本节是第四节 spam 深挖的应用篇：那一节讲商家为什么对发信零容忍，本节讲自己在这两台机上发信，过不过得去。问题拆三层判——条款、网络、投递，与第四节约束链同构。用途锚先钉死：自用通知，发给家人的 QQ 邮箱，个人量级——量极小，但每封都重要。结论对这个锚负责，不对「能不能把 MTA 跑起来」负责。）

（2026-11-10 口径补正：本节初稿把「接口发送」默认理解成云厂商 SES/API；用户所指的「接口」是个人 QQ 邮箱的 SMTP 授权码——用自己的 QQ 邮箱 + 授权码经 smtp.qq.com 提交。下文已按此补正：发信形态改为三形态并列（自建直投 / 云 API / 个人授权码 SMTP），场景结论改述，SES 降为第二顺位。）

第一层 · 条款：没有一家明文禁止「跑邮件服务器」

Shock（原文）：AUP 的邮件条目禁的是行为——mass unsolicited e-mail、mail/SMS bombers、因用户行为致其域名/IP 段进黑名单（盘点第四节）；禁令清单里没有「mail server / MTA」这个品类。KB 永久封锁清单里也没有 25（盘点已证）。低量、收件人明确的个人通知，不沾 spam 各条的字面。
DediRock（原文 + 解释）：ToS 同样没有「禁止自建邮件服务器」的字样；其最硬的 spam 零容忍，原文射程是 spam 行为本身与「账户致 IP 段被拉黑 → 立即停机 + 清理费」——自用低量通知不在这个语义内（解释）。但注意其兜底与投诉机制（24 小时 abuse 响应）一直在：条款层过关，靠的是「不发垃圾邮件」，不是「没人管」。

本层结论：两台都过。真正的墙不在条款，在下面两层。

第二层 · 网络：出站全通；入站要自己开门；PTR 一台现成一台空白（本方实测 2026-11-10）

测项（2026-11-10 实测，③）	debi（DediRock）	shoc（Shock）
25 出站（连 Gmail MX 与 QQ MX mx1/mx2/mx3，v4/v6 分开测）	两台双栈全通。QQ MX 均回真实横幅「220 newxmmxsz.qq.com MX QQ Mail Server.」，Gmail MX 同样 220——两家的网络层都没有封 25 出站，与 Shock KB 封单无 25 的原文互相印证。附带一条方向纪律：debi v4 的已知伤是入站被绞杀，出站不受影响*，本轮实测再次分清了方向。
25 入站（收信所需）	两台默认都不通，但拦路的是自家防火墙，不是商家。两台同装 server-kit 的 guard 防火墙（默认拒绝 + 白名单制，25 不在白名单内）；shoc 实测：在本机监听 25 的窗口内从 debi 侧连其 v4/v6，双栈超时、监听零命中。放行是本方一条 allow 规则的事——同制式的先例现成（debi 上已有 apphub-allow-10443、apphub-allow-31426 这类放行单元），自助可改、不需要商家批准。没放行之前，「收信」形态不成立。（debi 入站未单独复测，按同一 kit 制式与 allow 先例推断，同标 ③。）
PTR 现状	v4 有通用 PTR：192-227-187-220-host.colocrossing.com——存在，但不是自家域名，正反向与自有域名对不上；v6 无 PTR	v4 无 PTR；v6 无 PTR
RBL 现状（只读查询，自 debi 发起，2026-11-10）	v4 在 Spamhaus ZEN / SpamCop / Barracuda / SORBS / PSBL 五家均未列名；v6 在 ZEN / SORBS 未列名	v4 被 Barracuda 列名（返回 127.0.0.2），其余四家未列名；v6 在 ZEN / SORBS 未列名

PTR 怎么设：PTR 只能由 IP 持有方设置，自己在域名解析里写不了（腾讯云文档同旨：反向解析须向 IP 所属方申请）。DediRock 官方博客的说法是「联系服务商或经控制面板设置 PTR」（① 其博客）——Virtualizor 里是否已开自助未证实，落点是：先在面板找 rDNS 项，没有就开工单（该家工单通道本方用过、有效，流量翻倍就是工单办成的）。Shock 侧：SolusVM 平台客户区原生支持正/反向 DNS 自助管理（平台能力），Shock 是否在其 SolusVM 里开启未证实，落点相同：面板先找、没有就工单。两台都不是「设不了」，是「要走一道商家侧手续」。
shoc 的 Barracuda 列名怎么读：Barracuda 是企业级过滤的常用名单，QQ 是否采用它未证实，不必直接等同于「QQ 会拒」；但它说明这个 IP（或其邻段）有历史——新机器到手时 IP 声誉不是一张白纸。Barracuda 官网有免费除名申请通道；若将来真要在 shoc 上碰发信，除名是第一步，先于一切配置。

第三层 · 投递：QQ 邮箱才是胜负手（老实评估）

连接通、横幅正常，只说明 QQ 的大门开着，不说明它会收你的信。投递发生在 DATA 之后，那时看的是另一套账：

QQ 的过滤维度是公开的：其退信代码体系（腾讯退信说明的通行汇编）里有成套的 550——「Mail content denied」（内容被判群发嫌疑）、「Connection / Ip / Sender / Domain frequency limited」（按连接、IP、发件人、域名四个维度的频率限制，具体数值腾讯明示保密）。腾讯云官方排障文把境外自建发信最常见的三类硬伤列得很直白：IP 被列入黑名单；IP 信誉低或未授权（解法原文：配置 PTR，或改用中继服务器发送）；PTR 记录缺失（退信 "cannot find your hostname"）。翻译过来：QQ 对发信方的审查项就是本节第二层那几行——PTR、黑名单、信誉——而两台的现状是：一台 PTR 不对名、一台在名单上、两台共同没有信誉。
冷启动的死结（机制，一般知识）：IP 信誉靠「持续投递 + 零投诉 + 收件人正向互动（打开、移出垃圾箱、加白名单）」慢慢养，量太小养不出统计意义上的信誉曲线，量大又先撞频率限制与 spam 嫌疑。而通知场景恰好是死结的正中心：一天几封，低到养不出信誉；每封又都重要，丢一封就出事。SPF / DKIM / DMARC / PTR 全套配齐只是入场券——保证「有资格被评估」，不保证进收件箱。
分台评估：debi 直投 QQ——声誉基线是两台里较好的（五家 RBL 干净），工单把 PTR 改成自家域名、全套认证配齐之后，部分信能到，但进垃圾箱的概率长期偏高，且无任何手段确认家人是否真的看见；shoc 直投——起点更差（无 PTR + Barracuda 列名未除之前，等于带着案底去敲门）。两台共同的结构性问题是「境外托管段 + 零信誉冷启动」，不随配置努力消失。

本层结论：自建直投 QQ = 能发、能折腾、不能托付。对「每封都重要」的通知，「大概率能到、偶尔进垃圾箱且无回执感知」就是不合格——不是发不出去，是没有到达的确定性。

发信三形态：区别不在谁发，在信誉是谁的（2026-11-10 口径补正，新增形态 C）

形态 C 的机制先讲清：程序以「本人 QQ 邮箱地址 + 16 位授权码」登录 smtp.qq.com:465（SSL）提交邮件，之后信由腾讯的服务器与 IP 池完成投递——DKIM 签名、发信 IP 信誉都是腾讯自家背书，发件人身份就是你本人的 QQ 账号。两台 VPS 的 IP 与这条链零关系：提交程序只是一个 SMTP 客户端调用方，跑在哪台机器上都不进入投递链，哪怕跑在本地电脑上形态也完全一样，VPS 在这个形态里可以根本不在场。开通要点（QQ 邮箱帮助流程）：网页版 QQ 邮箱设置 → 账户 → 开启 POP3/IMAP/SMTP 服务（短信验证）→ 在同页生成授权码；程序里填的是授权码、不是 QQ 密码；授权码可随时在同页关闭服务或重新生成，旧码即刻失效，吊销零成本。授权码只该躺在你自己机器的配置里，不交任何人代存。

维度	A 自建（自有 IP 直投）	B 云 API（如腾讯云 SES）	C 个人 QQ 授权码 SMTP（新增）
发信路径	自家 MTA 从自家 IP 直连收件方 MX（25 端口）投递	程序调 API（或提交服务商 SMTP 入口），服务商用自己的 IP 池投递	程序提交 smtp.qq.com（465/SSL），腾讯服务器与 IP 池投递
信誉归属	从零自养：IP 信誉与域名信誉两份都要自己攒	借服务商 IP 池的存量信誉；发信域名仍须 SPF/DKIM/DMARC 验证——借的是路，名还是自己的	腾讯全量背书：账号信誉、IP 池、DKIM 签名都是腾讯自家的
发件人身份	自有域名地址，自己说了算	自有域名地址（完成域名验证后）	只能是本人 @qq.com 地址，没有自有域名发件人
成本	机器已有，现金零边际；真实成本在时间与不确定性	通知量级约等于免费：SES 每账号 1000 封免费额度（不限有效期）、超出 0.0019 元/封（① 其价格文档，2026-11-10 查）	零：个人邮箱既有服务，无单价、无额度费
量上限	物理上不限，实际被收件方限频与自家信誉卡住	额度制、明码标价、可扩容	受腾讯风控的频率/日量限制——官方未公布固定阈值（2026-11-10 查 QQ 邮箱帮助与腾讯公开说明，均无个人邮箱日发信量数字；其退信代码仅证实存在四维限频且数值保密）；一般量级为每日数十至数百封、随账号状态浮动（一般知识）。通知的日均几封离它很远，批量群发则必被拦
凭据形态	无第三方凭据；靠 PTR/SPF/DKIM/DMARC 全套认证记录与机器本身	API 密钥 / 服务商 SMTP 凭据 + 发信域名验证	一枚 16 位授权码：可随时吊销重发、非账号密码，只存自己机器的配置
到达确定性（对 QQ 收件）	冷启动期长期低位，进箱靠概率	高——进箱率是其商品本身；但跨厂投递仍要过 QQ 对外部发件人的审查	最高：收发同在腾讯体系内，进箱由其自家通道与账号信誉背书
与两台 VPS 的关系	强耦合：发信 IP 就是代理与服务的出口 IP，被拉黑或被投诉连坐同一 IP 上其他用途的声誉——与第四节 spam 深挖的「段连坐」是同一枚硬币	完全解耦：发信翻车（退信、投诉、限流）止于服务商账户，不进自家院子	零关系：两台 IP 根本不在投递链上，最坏后果止于 QQ 账号自身的发信功能

给本方场景的建议（锚：自用通知 → 家人 QQ 邮箱）

首选：用你自己的 QQ 邮箱授权码发（形态 C），不要用两台直投。三条理由正对着这个锚：① 收件人是家人的 QQ 邮箱、发件也在腾讯体系内——信走腾讯的服务器、IP 池与签名递进 QQ 收件箱，进箱确定性是三形态里最高的；② 零冷启动、零成本：不需要养任何信誉，你账号本身的信誉就是现成的；③ 与两台 VPS 零牵连：发信翻车（限频、退信）的最坏后果止于 QQ 账号的发信功能，不碰自家 IP 与段声誉。

形态 C 的代价（如实列）：发件人只能是你本人的 @qq.com 地址——家人看到的是你的 QQ 邮箱在发通知，不是自有域名地址；且受个人邮箱风控的频率/日量上限约束（官方无固定数字，见上表）。对「自用通知」这个锚，这两条都不构成问题。
云 API（SES 类）降为第二顺位：出现以下任一需求时再上——想以自有域名地址发件（家人看到自家域名）、发送量涨到个人邮箱风控会拦的量级、或需要退信报表与送达统计。它借服务商 IP 池的信誉、保留自有域名身份，是「再往上一档」的选项，不是这个场景的起点。
收发分离仍是标准形态，发信侧第一顺位换成形态 C：发信走授权码 SMTP（需要域名身份时换 SES），收信可以自建——收信不看你 IP 的发信信誉，门槛低得多；将来若想要自有域名的收件箱，在任一台上放行入站 25（一条 allow 规则）+ 配好 MX 即可，它只负责收，不背到达率的锅。
自建直投的正确定位不变：练手与理解协议的实验品。要练在 debi 上练（声誉基线干净、PTR 可经工单改成自家域名），练完就知道上面每一句是怎么回事——但不要让任何「必须到」的通知走它。
分层定级收尾：条款层——明确可行（两台均无明文禁止，低量通知不沾 spam 条款）；网络层——可行但要动手（出站现成；入站一条规则；PTR 一台改名、一台先除名再申请）；投递层（对 QQ）——自建直投实质不可托付，但这一层对本方场景已有现成解：发信借自己 QQ 邮箱的通道（授权码），到达确定性由腾讯体系背书。总括一句：能搭 ≠ 能投；通知的第一顺位是自己的 QQ 授权码，自建留给收信与练手，SES 留给需要自有域名发件人的那一天。

八、证据与来源

证据四级（全文通用，不混写）：① 商家官方文本（ToS/AUP/KB/产品页原文）——只有这一级能下「允许/禁止」结论；② 订单/工单实证；③ 本方实测（旁证，不等于许可）；④ 社区转述（仅线索，与官方结论分开呈现）。文中标「原文」者为 ① 级逐字或近逐字引用；标「推断/框架/我方安全线」者为本方分析，不是商家的话。

官方文本（2026-11-10 抓取；满载一节于当日二次精读复核）：

DediRock Terms of Services（主体 Atlas Cloud LLC）：dedirock.com/terms-of-services
Shock Hosting Acceptable Use Policy：shockhosting.com/aup
Shock Hosting Terms of Service：shockhosting.com/terms
Shock Hosting KB「Which ports are blocked?」：shockhosting.net/portal/knowledgebase/41
Shock Hosting KB「What are the account resource limits?」（本文第三节用于排除其对 VPS 的适用：该文是 cPanel 共享口径）：shockhosting.com/portal/knowledgebase（KB 14）
腾讯云文档「邮件推送价格说明」（SES 每账号 1000 封免费额度、超出 0.0019 元/封）与「PTR 反向解析」（PTR 由 IP 所属方设置、须向其申请）：cloud.tencent.com/document（2026-11-10 查）
QQ 邮箱退信代码汇编（winmail.cn 转载腾讯退信说明，非腾讯官方页面；本文仅用其 550 代码体系佐证 QQ 的过滤维度）：winmail.cn/ndr/qq
QQ 邮箱帮助「POP3/IMAP/SMTP 服务与授权码」开通流程（网页版设置 → 账户 → 开启服务 → 生成授权码）：help.mail.qq.com（2026-11-10 查）；个人邮箱日发信量的固定阈值，腾讯官方未公布——第七节形态 C 的量上限按「官方无数字 + 一般量级」标注，未采信任何第三方给出的具体封数
DediRock 官方博客「How to Find and Manage Your Server's IP Address」（rDNS 一节原文：联系服务商或经控制面板设置 PTR）：dedirock.com/blog（2026-11-10 查）；SolusVM 客户区正/反向 DNS 自助管理为该平台的原生能力（SolusVM 官方发布口径，Shock 是否开启未证实）

② 级：debi 工单 #QFY-998250（流量翻倍至 ≈4 TB/月）；shoc 订单邮件（$20/yr、Recurring $20、2 TB/月）。④ 级：Trustpilot 上 DediRock 官方回复的终止案例（上游 abuse 驱动批量停机）——仅作执行机制的线索，不作条款结论。
底稿与本页的关系：盘点全文（含六维度逐项原文要点）存于经验文档《平台限制盘点》（~/workspace/apphub-experience/经验/proxy-node/平台限制盘点.md），本页是它的扩展版——总表为压缩、深化三节与第六节复核为新增，盘点结论无一改口；第六节对旧表述的修正已同步回盘点 md；第二节末的「视频流辨析」附节、第六节的 C′ 改述与整线迁移账、第四节的 spam/BT 逐类深挖（均为 2026-11-10 晚补）同步收录于盘点 md 附节二至附节五（邮件服务器专节为附节五）。