1. 先把这个词拆开：PCDN 到底在跑什么
1.1 从中心分发到边缘接力：一次被带宽成本逼出来的架构迁移
我最早接触这类系统是在做点播加速的外包项目里。那时候视频清晰度从 720P 往 1080P、4K 走，中心机房的带宽账单涨得比用户量还快——用户越多，出口带宽成本越高，而内容分发的特点是"热点集中、长尾分散"，热门片子被反复拉取，冷门内容占了存储不占带宽。传统的 CDN 靠在全国各地铺边缘节点解决这个问题，节点离用户近，回源少，体验好，但节点是自建的、要机房、要电、要运维，单价压不下来。
PCDN 的思路很朴素：既然大量普通用户的设备常年在线、带宽闲着、硬盘也闲着，那能不能把这些闲散资源组织起来，当成一张"众包边缘节点网"？把热门内容切片缓存到这些节点上，用户请求时优先从就近的节点取，取不到再回源。这和传统 CDN 的技术目标完全一致，区别只在于节点的归属——一个是机房里的服务器，一个是散落在千家万户的小盒子、软路由、旧笔记本。
理解这一点非常关键：PCDN 不是什么新协议，它是 CDN 的一种资源组织方式。核心依然是缓存、调度、回源这三件事，只是把"边缘"从机房挪到了离用户更近的地方。也正因为节点在家庭网络里，后面所有关于限速、停机的争议，根子都埋在这个"物理位置"上。
1.2 四层结构：节点、调度、鉴权、结算
一套能跑起来的 PCDN 系统，我习惯把它拆成四层来看，这个拆法对排查问题特别有用，因为绝大多数故障都能定位到某一层。
第一层是节点层，也就是跑在设备上的缓存服务，负责接收请求、命中缓存、返回分片、上报心跳和流量。节点层的核心指标是命中率、上行吞吐、连接数、磁盘 IO。第二层是调度层，决定一个用户请求应该落到哪个节点，靠的是节点上报的负载、延迟、地理和时间邻近性。调度算法做得好不好，直接决定整张网的效率，做不好就会出现"节点很忙但命中率很低"的怪现象。第三层是鉴权与计量层，确认请求合法、防止被刷，同时记录每个节点的有效流量，作为结算依据。第四层是结算层，把计量数据折算成收益，按周期出账。
这四层里，节点层和调度层是技术活，鉴权和计量是"防作弊"的活。很多做节点的人只关心第一层，觉得"我上行跑满就该给钱"，但结算看的是去重后的有效流量，大量重复回源、无效请求是不计费的。我见过不少人抱怨"跑了 2TB 只结算了 300GB"，本质上就是没搞懂第三层的规则。
1.3 参与链条上的三类角色和各自的算盘
从业务视角看，这条链路上有三类角色，各自诉求完全不同，理解他们的诉求，才能理解为什么会出现限速这种事。
需求方是内容提供者，比如视频平台、下载站、游戏更新分发方。他们的诉求很简单：用更低的单价买到更稳的分发能力，最好比中心 CDN 便宜一半以上。平台方是把闲散资源组织起来的那一层，负责调度、计量、结算，赚的是差价和技术服务费。节点方就是提供设备和带宽的人，诉求是投入产出比，一台设备的回本周期最好控制在半年以内。
三方的利益并不完全一致。需求方要便宜和稳定，平台方要规模和毛利，节点方要高单价快回本。当节点规模快速膨胀、单价被摊薄的时候，节点方就会倾向于"多开设备、榨干上行"，而这个动作恰好会撞上家庭宽带产品的使用边界——这就是后面要讲的限速与停机的起点。我在实际项目里见过最极端的情况，一个机位塞了四台设备、十几条线路轮换，这种做法在技术上确实能短期提高吞吐，但稳定性极差，也不符合宽带服务协议里关于使用用途的约定。
提示：本文讨论的是自建分发系统、家庭实验室和边缘缓存的技术实践。任何涉及宽带服务协议、结算规则的判断，务必以你自己签署的协议条款为准，别拿别人的经验当合同。
2. 限速和停机到底是怎么发生的：流量画像比你想的更细
2.1 上行流量画像：为什么被盯上的总是上行
家庭宽带有一个历史遗留特征：上下行不对称。早年是 ADSL 时代的技术限制，后来光纤入户了，但产品设计沿用了这个思路——下行给足，上行克制。千兆套餐常见配置是 1000Mbps 下行配 30~50Mbps 上行，部分地区能给到 100Mbps 上行，这已经算优待了。
普通家庭的上行使用特征非常明显：总量小、突发、时间集中在晚上。刷视频、发消息、视频通话，上行占比通常不到下行的十分之一，而且很少有持续几小时跑满上行的情况。PCDN 节点的特征恰恰相反：上行持续高占用、24 小时不间断、流量曲线接近一条水平直线。这两种画像放在一起，几乎不需要什么复杂算法就能区分开。
所以限速这件事，本质上不是"针对谁"，而是网络侧对流量行为做分类后的正常管理动作。我在做带宽质量分析的时候，见过最典型的判定特征有这么几个：单账号上行长期占用超过套餐上行的 70%；连接数常年维持在数千以上；出站流量的目标地址高度分散且以视频分片请求为主；流量时间分布没有明显的昼夜波谷。这四条同时命中的账号，基本跑不掉。
2.2 限速发生在哪一层：四种常见实现方式
很多人以为限速就是"网变慢了"，其实限速可以发生在好几个不同的层级，表现和绕过难度完全不同。下面这张表是我在实际排查中总结的对照，遇到速度异常时先按这个表定位。
| 限速层级 | 典型表现 | 判断方法 | 影响范围 |
|---|---|---|---|
| 应用层流量整形 | 特定协议/端口速度骤降，其他正常 | 换端口、换协议测速对比 | 单一业务 |
| 会话/连接数限制 | 新连接建立失败，老连接仍可用 | 看 conntrack 计数与新建失败率 | 全局连接 |
| 账号级速率模板 | 上下行同时被压到固定值 | 换设备、换网线仍不变 | 整条线路 |
| 上行端口协商降级 | 链路速率从 1000M 掉到 100M | 看光猫/交换机的协商速率 | 物理链路 |
我踩过最迷惑的一次坑是第四种。当时一台软路由跑得好好的，突然所有测速都卡在 90Mbps 左右，怎么调软件都没用。后来登到交换机上看端口状态，发现协商速率从千兆掉到了百兆——原因是那根网线被设备压着，水晶头一侧卡扣松了，接触不良导致协商降级。这种问题跟限速一点关系都没有，但如果只看应用层，永远查不出来。
第二种也很常见。家用光猫的 NAT 会话表容量普遍不大，几千到一两万条的级别，PCDN 节点动辄上万的并发连接很容易把表打满，表现就是"能连上但新连接一直超时"。这时候用conntrack看一眼计数就清楚了：
# 查看当前连接跟踪表使用量与上限 cat /proc/sys/net/netfilter/nf_conntrack_count cat /proc/sys/net/netfilter/nf_conntrack_max # 按源地址统计连接数，找出占用最高的客户端 conntrack -L 2>/dev/null | awk '{print $5}' | cut -d= -f2 | sort | uniq -c | sort -rn | head -20 # 临时提高上限并缩短空闲超时（重启失效） sysctl -w net.netfilter.nf_conntrack_max=262144 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600注意：调大连接跟踪上限会增加内存占用，每条记录约 300 字节，26 万条约占 80MB，小内存设备别盲目拉满，先看
free -m的余量。另外这类内核参数属于临时验证手段，长期方案应该是减少无效连接，而不是无限扩容。
2.3 停机是怎么触发的：从欠费到异常流量核查
"局停"这个说法在圈子里传得很玄乎，实际上触发链路就那么几条，捋清楚就不慌了。我把它归成三类。
第一类是账务和服务状态问题，欠费、套餐到期、实名信息待更新，这类最单纯，补上就好。第二类是设备与线路故障，光猫异常、光功率过低、ONU 掉注册，表现是"完全没网"而不是"变慢"，看光猫指示灯和光功率就能判断。第三类是使用行为触发了核查，长期高上行占用、多设备共享、频繁更换终端 MAC、短时间内大量上下线，这些行为组合起来会被风控模型打上标记，然后进入人工或自动核查流程，核查期间服务可能被暂停。
这里我要说句实在话：第三类不是"无缘无故"。家庭宽带产品在服务协议里通常写明用途是家庭日常使用，把一条家宽当作商业分发节点长期跑满上行，属于用途与产品定位不符。平台方和宽带服务方对这类用法的态度，写在协议里，不在技术里。我见过有人反复投诉"凭什么停我的网"，但翻回去看协议条款，其实写得很清楚。作为技术人，可以讨论技术方案的合理性，但绕过协议约定去操作，风险得自己承担。
2.4 家宽和专线：不是速度差别，是责任边界差别
很多新手会问：家宽上行 100M 一个月几十块，专线 100M 一个月几千块，为什么不能拿家宽干专线的活？
差别不在速率，在服务等级和责任边界。家宽是共享型产品，上行带宽是超售的，运营商不承诺 SLA，不保证上行稳定，也不承担因用途不符导致的服务中断责任。专线是独享型，有明确的可用率承诺、有固定的公网地址、有故障响应时限，价格里包含了这些承诺的成本。拿家宽跑商业分发，本质上是享受了共享型产品的低价，却要求独享型产品的稳定性，这个账在任何商业模型里都算不平。
实操层面的差异也很具体：家宽的公网地址是动态的、可能被 NAT 多层转换、端口被封、没有固定 IP，这些都会影响 PCDN 节点的连通性和调度质量。我做过对比测试，同一条物理线路，家宽模式下节点的 NAT 类型经常是端口受限型甚至对称型，穿透成功率明显低于专线模式，直接影响命中率和有效流量。所以如果真要把这件事做正经，专线或者至少是商用宽带才是可讨论的方案，家宽只适合做小规模实验。
3. 想跑起来：硬件选型、系统调优和一笔明白账
3.1 硬件与带宽：先算回本周期，再买设备
我在这个圈子里见过太多"先买设备后算账"的人，最后设备吃灰。正确的顺序是反过来：先算清楚一条线路能产生多少有效流量，再倒推设备该花多少钱。
带宽收益的上限很好算。假设你有 100Mbps 上行，理论上一天能跑满的量是：
100 Mbps × 86400 s ÷ 8 = 1,080,000 MB ≈ 1.03 TB/天但这是理论峰值，实际有效流量要打几个折扣：命中率折扣（不是每个请求都能在本地命中）、调度折扣（平台不一定把你的节点排满）、去重折扣（重复请求不计费）、时段折扣（白天流量低谷）。综合下来，一条 100M 上行线路，实际有效流量能到理论的 30%~50% 就算不错了，也就是每天 300~500GB。如果你的线路是 30M 上行，那这个数字要再除以三。
设备侧的成本要算全：设备购置（一次性）、电费（持续）、硬盘损耗（持续）、网络设备（一次性）。一台功耗 15W 的小主机，一个月电费大概是：
15 W × 24 h × 30 d ÷ 1000 = 10.8 kWh 10.8 kWh × 0.6 元/kWh ≈ 6.5 元/月硬盘是大头。PCDN 节点是持续写入型负载，机械盘扛不住随机写，固态盘的写入寿命会被快速消耗。一块 500GB 的消费级固态，TBW 通常标 300TB 左右，如果节点每天写入 200GB（缓存替换产生的写入量往往远大于有效流量），理论上 1500 天写满，实际考虑写入放大，可能 800~1000 天就要换。这块成本必须摊进月度支出，否则账是假的。
把这几项加起来做个表，回本周期一目了然：
| 项目 | 金额 | 说明 |
|---|---|---|
| 小主机 | 800 元 | 一次性，按 24 个月摊销约 33 元/月 |
| 固态硬盘 500GB | 300 元 | 一次性，按 24 个月摊销约 12.5 元/月 |
| 电费 | 6.5 元/月 | 15W 满载估算 |
| 网线/交换机摊销 | 5 元/月 | 一次性投入摊薄 |
| 月度总成本 | 约 57 元 | 不含宽带费用 |
如果按有效流量 400GB/天、单价 0.003 元/GB 估算，月毛收入约 36 元——注意，这个数字是亏的。这就是我想强调的核心结论：在单价被摊薄的当下，单条家宽跑 PCDN 的经济性非常脆弱，能不能赚取决于单价、命中率和你是否忽略了设备折旧。很多晒收益的帖子只算毛收入不算折旧电费，看的时候要留个心眼。
3.2 系统层调优：把设备资源用在刀刃上
设备到位后，系统层的调优目标很明确：让缓存命中率尽可能高、让上行尽可能少浪费、让设备别因为资源耗尽而假死。我一般按这个顺序做。
第一步是网络栈参数。PCDN 节点的特点是大量短连接加少量长连接，文件描述符和端口范围是第一道坎：
# /etc/sysctl.d/99-pcdn.conf fs.file-max = 1000000 net.core.somaxconn = 32768 net.ipv4.tcp_max_syn_backlog = 16384 net.ipv4.ip_local_port_range = 10240 65535 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 15 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216改完执行sysctl -p生效。这里有个细节：tcp_tw_reuse只在主动发起连接时生效，对服务端被动关闭的连接没帮助，别指望它解决所有 TIME_WAIT 堆积问题，真正的解法是减少无效短连接。
第二步是缓存盘的选择和挂载参数。缓存盘建议单独一块盘，不要和系统盘混用。挂载时关掉 atime 更新能减少不必要的写入：
# /etc/fstab 示例：noatime 减少元数据写入，discard 对 SSD 视情况开启 UUID=xxxx-xxxx /data ext4 defaults,noatime,nodiratime 0 2注意：
discard挂载选项在部分低端主控上会引起周期性卡顿，我一般改成每周一次的fstrim定时任务，稳定性更好。
第三步是容器化部署。现在大部分节点软件都有官方镜像，用 compose 管起来最省事，升级和回滚都方便：
# docker-compose.yml services: pcdn-node: image: registry.example.com/pcdn/node:1.8.2 container_name: pcdn-node restart: unless-stopped network_mode: host # 需要直连宿主网络做端口穿透 volumes: - /data/cache:/cache # 缓存目录，务必挂在独立盘上 - ./config:/etc/node:ro # 配置只读挂载，避免误写 environment: - NODE_CACHE_SIZE=380G # 留 20% 空间给日志和临时文件 - NODE_MAX_UPLINK=90 # 留 10% 余量，避免长时间满速 - NODE_LOG_LEVEL=warn ulimits: nofile: soft: 65535 hard: 65535 logging: driver: json-file options: max-size: "50m" max-file: "3"NODE_MAX_UPLINK这个参数值得单独说。很多教程建议直接拉满上行，我个人倾向于留 10% 左右余量。原因有两个：一是跑满上行会让同一条线路的其他设备体验极差，家里其他人在晚上用网会明显卡；二是持续满速更容易触发前面说的流量画像判定。留余量不是技术上的必需，是稳定性和生活质量的折中。
3.3 必须盯住的几个指标：没有监控等于盲跑
节点跑起来之后，最怕的是"看起来在跑，其实早就废了"。我见过太多设备，界面显示在线，实际命中率掉到个位数，流量全靠回源，白跑好几天没人发现。所以监控不是可选项。
必须盯的核心指标有这么几个：
| 指标 | 健康区间参考 | 异常含义 |
|---|---|---|
| 缓存命中率 | 60% 以上 | 偏低说明内容不匹配或缓存盘异常 |
| 上行吞吐 | 稳定在设定值的 80% 以上 | 骤降可能是限速或调度降权 |
| 并发连接数 | 稳定且不持续攀升 | 持续攀升可能是 NAT 表被打满 |
| 磁盘 IO 等待 | 低于 10% | 偏高说明盘性能不足，影响命中 |
| 进程存活 | 持续在线 | 频繁重启查 OOM 和内核日志 |
| 节点心跳 | 上报周期稳定 | 丢包说明线路质量有问题 |
采集我用 Prometheus 加 node_exporter，再配几条告警规则，比天天登设备看界面靠谱得多：
# prometheus/rules/pcdn.yml groups: - name: pcdn-node rules: - alert: NodeHitRateLow expr: pcdn_cache_hit_ratio < 0.4 for: 30m labels: severity: warning annotations: summary: "节点命中率低于 40%，持续 30 分钟" - alert: DiskIOWaitHigh expr: rate(node_cpu_seconds_total{mode="iowait"}[5m]) > 0.15 for: 15m labels: severity: warning annotations: summary: "磁盘 IO 等待超过 15%，检查缓存盘健康状态" - alert: NodeDown expr: up{job="pcdn-node"} == 0 for: 5m labels: severity: critical最后一条NodeDown是保命的。我有一次设备半夜内存溢出挂了，第二天中午才发现，白白损失了十几个小时的流量。加了告警之后，五分钟内手机就能收到通知。顺带提一句，一定要配ulimits.noffile，默认 1024 的文件描述符限制在高并发下必然耗尽，表现就是进程还在但所有请求都超时，这个坑我踩过不止一次。
3.4 一次完整的部署验证流程
设备装好、参数调完，别急着接入平台跑量，先做一轮自测，把基础问题排掉。我常用的顺序是这样：
第一，线路质量基线。用iperf3打一轮上行，看能不能达到套餐标称值，同时记录抖动和丢包：
# 服务端（对端设备） iperf3 -s -p 5201 # 客户端，跑 30 秒上行，4 条并发流 iperf3 -c <对端地址> -p 5201 -t 30 -P 4 -R # 同时用 mtr 观察路径质量，重点看丢包和抖动 mtr -n -c 100 <对端地址>这一步的意义是建立基线。后面如果速度掉了，拿现在的数据一对比就知道是线路问题还是节点问题。我习惯把每次基线测试的结果存到一个文本文件里，写上日期和当时的环境，出问题时翻记录特别有用。
第二，NAT 类型判定。PCDN 节点的连通性极度依赖 NAT 类型，全锥形最好，对称形最差。判定方法可以用打洞测试工具，也可以看节点软件自己上报的类型。如果是对称形，先排查是不是光猫在做二次 NAT——把光猫改桥接、由自己的路由拨号，经常能显著改善。
第三，缓存盘压测。用fio模拟随机读写，确认盘的性能符合预期，同时看温度：
# 4K 随机写，模拟缓存替换的写入特征，跑 60 秒 fio --name=randwrite --ioengine=libaio --direct=1 --bs=4k \ --rw=randwrite --size=2G --numjobs=4 --iodepth=16 \ --runtime=60 --time_based --group_reporting如果 4K 随机写的 IOPS 只有几百，那这块盘基本不适合做缓存，命中率会被 IO 拖死。我用过一块廉价固态，顺序读写标称很好看，4K 随机写只有 300 IOPS，实际跑起来缓存淘汰极慢，命中率一直在 40% 上下晃。
第四，小流量试跑。把上行限制设到设定值的 20%，跑 24 小时，观察命中率、连接数、内存占用、磁盘写入量的曲线。这一步是找"温水煮青蛙"型问题，比如内存泄漏、日志爆盘、连接数缓慢攀升，都是低负载下看不出来、满负载下才爆的。
4. 排查实录：那些让人抓头的现象和它们的真相
4.1 速度从 100M 掉到 5M：一次完整的定位过程
这是最典型的一类求助：昨天还好好的，今天速度掉到个位数。我一般按"分层排除"的顺序走，从最外层往内层查，避免一上来就改配置。
先看物理层。登交换机看端口协商速率，看光猫的光功率（正常范围通常在 -8dBm 到 -27dBm 之间，低于 -27 就要报修），看网线有没有被压、有没有氧化。这一步能排掉大约两成的故障。
再看账号层。用同一台设备、换一条网线、换个时间段测速，如果速度始终固定在某个值（比如 5Mbps、10Mbps、30Mbps），而且上下行同时被压，那大概率是账号级速率模板生效了。这时候再折腾设备就是浪费时间，得去看服务状态和协议约定。
最后看应用层。如果只有特定业务慢、其他正常，那就是协议或端口被针对性整形，换端口、换传输方式试试就能确认。
我把这套流程做成了一张速查表，贴在工位上，出问题照着走：
| 现象 | 优先排查 | 快速验证方法 |
|---|---|---|
| 速度固定在某个整数 | 账号速率模板 | 换设备换网线，速度不变即确认 |
| 只有特定业务慢 | 应用层整形 | 换端口/协议对比测速 |
| 新连接大量超时 | 连接跟踪表打满 | 看 nf_conntrack_count 是否接近上限 |
| 完全没网 | 线路或账号状态 | 看光猫指示灯、光功率 |
| 白天正常晚上慢 | 上行拥塞或共享超售 | 分时段测速对比 |
| 速度忽高忽低 | 无线或网线接触不良 | 换有线连接、看端口协商 |
| 节点在线但零流量 | 调度降权或鉴权失败 | 看节点日志的错误码 |
4.2 节点频繁掉线：内存、句柄和看门狗
掉线问题比限速更烦人，因为它不规律。我遇到过的原因按频率排序：内存溢出被 OOM Killer 干掉、文件描述符耗尽、磁盘写满、看门狗误杀、网络抖动导致心跳超时。
排查 OOM 最直接的办法是看内核日志：
# 查最近的 OOM 记录 dmesg -T | grep -i -E "oom|killed process" # 查系统的重启历史和异常关机 last -x | head -20 # 查节点进程的峰值内存占用 systemd-cgtop --order=memory -n 1如果是 OOM，先别急着加内存，先看是不是缓存索引占太多。有些节点软件会把索引全量加载进内存，缓存目录设得越大内存吃得越多，500GB 缓存配 1GB 内存的机器必然爆。这种时候要么减缓存容量，要么加内存，没有第三条路。
磁盘写满的问题也很常见，而且阴险——日志和缓存共用一个分区，缓存把空间吃满，日志写不进去，进程就卡死。我的做法是缓存目录和日志目录分盘，缓存目录单独限额，日志用 logrotate 或者 docker 的max-size限制。前面 compose 里那两个日志参数就是干这个用的，别嫌麻烦。
心得：给节点设备加一个硬件看门狗或者简单的守护脚本，比事后查日志省事得多。我用的是一个五分钟检查一次的脚本，进程不在就拉起来，连续三次拉起失败就重启整机，同时发通知。这套东西不上台面，但能省下大量半夜爬起来处理的精力。
4.3 收益和流量对不上：计量口径的坑
这个问题的求助量仅次于限速。用户看到自己设备上跑了 2TB，结算只有 300GB，第一反应是"平台黑我"。实际情况通常是计量口径不同。
节点本地统计的是网卡出流量，包含重传、握手、无效请求、回源、心跳。平台结算的是有效分发流量，要经过请求去重、分片校验、回源剔除、异常流量过滤。这两者之间差三到五倍是常态。想验证的话，自己搭一个抓包统计，看请求的响应码分布，如果大量是 4xx 或者重复请求同一分片，那计量差异就有解释了。
还有一种情况是调度降权。节点的健康度、在线率、延迟、丢包都会影响调度权重，权重低的时候平台给的任务少，本地看流量就是"跑不满"。这时候看日志里的调度响应和心跳质量比看流量数字有用。
4.4 边界提醒：哪些事不能做
写到这儿必须把话说清楚。技术方案可以讨论，但有几条线不能碰：不要用伪造信息批量开通线路，不要在多条线路之间做规避性的流量切换来绕开服务管理，不要把家宽当商用专线对外售卖分发能力，不要碰任何来路不明的"高单价渠道"。这些东西短期看着有收益，出问题的时候没有任何保障，也没有任何一方会替你兜底。
我见过最可惜的一种情况：有人把设备、线路、时间全投进去了，跑到规模之后被要求整改，前面几个月的投入全打水漂。真正稳的做法是小规模验证、把账算清楚、把协议读明白，赚的是确定性的钱，不是博弈的钱。
5. 这笔账还值不值得算：我的取舍经验
5.1 成本结构变了，结论也就变了
早几年单价高、竞争少的时候，一条家宽加一台旧设备确实能跑出不错的收益，很多人是那个阶段进来的。现在的情况完全不同：节点规模上来了，单价被摊薄；设备折旧和电费是硬的；带宽使用行为的管理越来越精细。三个因素叠加，单条线路的利润率被压得很薄。
我用一个简单的模型来判断值不值得做：把月毛收入减去月度总成本（设备摊销、电费、硬盘摊销、宽带费用分摊），得到净收益，再看净收益除以投入本金得到的月回报率。如果月回报率低于 3%，我基本不会做，因为这点回报覆盖不了设备故障、政策变化、时间投入这些隐性成本。用前面第 3.1 节的数据算，一台设备月净收益大概是负数到十几块，这个回报率对应的是几百到一千块的本金，说难听点，不如把这台设备拿去做别的事。
规模化能不能改善？能，但改善的是边际成本，不是单价。十台设备的运维复杂度不是一台的十倍，可能是三到五倍，因为故障排查、固件升级、线路管理都会叠加。所以规模化的前提是你有一套自动化运维体系，能远程批量管理，否则人会被拖死。
5.2 换个方向：把同样的技术能力用在更稳的场景
我一直觉得，做 PCDN 练出来的这套本事——缓存设计、调度理解、网络调优、监控告警、成本核算——本身很值钱，只是未必非要用在"跑量换钱"这一个方向上。
比如家庭实验室的私有分发。家里有多台设备、多个成员，影音库、软件源、模型文件、固件包这些内容反复下载，用同样的缓存思路在本地做一层加速，省的是自己的时间和带宽，收益是确定的。搭一套本地缓存代理，把常用的包源、镜像源、模型文件缓存在局域网，多设备共享，体验提升非常明显。
再比如小型团队的内网分发。一个十几人的团队，日常要拉依赖包、下数据集、更新工具链，出口带宽经常是瓶颈。用一台小机器做本地缓存节点，配合调度规则，能把重复下载干掉一大半。这类场景不需要考虑对外分发，也不涉及宽带用途的争议，技术上是同一套东西，风险却低得多。
还有边缘计算的实验环境。想学调度算法、想验证缓存策略、想研究 P2P 协议，用几台设备组一个最小可用的实验网，跑自己的调度器，观察命中率、延迟、带宽利用率的变化。这种实验的价值在于理解原理，而不是赚钱，但恰恰是这种理解，能让你在真正需要做技术选型的时候判断得更准。
我自己现在的做法是：保留一台设备做实验和本地分发，不再追求跑量。省下来的精力放在监控体系和自动化上，这些能力在其他项目里复用率更高。说到底，一项技术能不能长期做下去，看的不是短期单价，而是它能不能沉淀成可迁移的能力。
