PCDN跑不起来？先别甩锅给平台，问题可能出在这

1. 引言

很多朋友在部署 PCDN 时都会遇到"跑不起来"的情况，第一反应往往是抱怨平台限制、调度不给量、收益太低。但冷静下来复盘，绝大多数问题其实出在自身配置、网络环境和节点质量上。本文不替平台说话，只帮你把排查思路理清楚，少走弯路。

2. 先分清：是"没量"还是"跑不动"

在动手排查之前，先明确一个关键区别：**"没量"是指平台没有给你分配足够的调度请求，"跑不动"**是指有请求进来但你的节点处理不了。这两类问题的解决方向完全不同。

• 没量：更多和节点质量、在线稳定性、区域覆盖有关，需要从自身节点入手。
• 跑不动：更多和带宽、磁盘 IO、CPU 负载、软件配置有关，需要从性能调优入手。

如果你连日志里都看不到请求，那大概率是"没量"；如果日志里有请求但处理超时、失败率高，那才是"跑不动"。先定位清楚，再对症下药。

3. 常见原因一：网络环境不合格

PCDN 对上行带宽、公网类型和 NAT 穿透能力非常敏感。很多"跑不起来"的案例，根源都在网络侧。

• 上行带宽不足：PCDN 主要消耗上行流量，如果上行被限速或共享，调度自然减少。
• NAT 类型严格：对称型 NAT 或处于多层 NAT 后面，节点难以被外部主动连接，调度会大幅降低。
• 公网 IP 缺失：没有公网 IP 或处于运营商大内网（CGNAT）环境，穿透成功率低。
• 防火墙/安全组拦截：部分端口被运营商或本地防火墙封禁，导致握手失败。

建议先用工具检测当前 NAT 类型和公网可达性，确认网络环境是否满足平台的基本要求，再谈其他优化。下面给出一组 Linux 下常用的检测命令，覆盖 NAT 类型、公网可达性、上行带宽和丢包率四个维度。

3.1 检测 NAT 类型

NAT 类型决定了节点能否被外部主动连接。对称型 NAT 或处于多层 NAT 后面时，穿透成功率会大幅下降。Linux 下可用 stun-client 或 nattype 工具检测：

# 安装 STUN 客户端（Debian/Ubuntu）
sudo apt install stun-client
使用公共 STUN 服务器检测 NAT 类型
stun stun.l.google.com:19302
输出示例
Binding test: success
Local address: 192.168.1.100:54321
Mapped address: 203.0.113.10:54321
Behavior test: success
NAT type: Full Cone NAT

关键指标解读 ：NAT type 一行的结果直接决定节点可被外部连接的难度。Full Cone NAT 和 Restricted Cone NAT 穿透能力较好，适合 PCDN；Symmetric NAT（对称型 NAT）最难穿透，调度会大幅降低，建议调整路由器 NAT 模式或改用桥接。

3.2 检测公网可达性

公网可达性用于确认节点是否拥有公网 IP，以及是否处于运营商大内网（CGNAT）环境。可用 curl 查询出口 IP 并对比本地网卡 IP：

# 查询本机出口公网 IP
curl -s ifconfig.me
# 输出示例：203.0.113.10
查询本机网卡 IP
ip -4 addr show | grep inet
输出示例：inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0
若出口 IP 与网卡 IP 不一致，说明处于 NAT 或 CGNAT 环境
若出口 IP 属于 100.64.0.0/10 段，则确认处于运营商大内网（CGNAT）

关键指标解读 ：出口 IP 与网卡 IP 不一致，说明节点在 NAT 后面；出口 IP 落在 100.64.0.0/10 段，基本可判定为 CGNAT 环境，此时公网穿透成功率低，建议申请公网 IP 或使用支持端口映射的组网方案。

3.3 检测上行带宽

PCDN 主要消耗上行流量，上行带宽不足会直接导致调度减少。推荐使用 iperf3 进行实测，需要一台公网服务器作为对端：

# 服务端（公网服务器上执行）
iperf3 -s
客户端（PCDN 节点上执行，-R 表示测试上行）
iperf3 -c 203.0.113.10 -R -t 30
输出示例
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-30.00  sec   112 MBytes   31.3 Mbits/sec    0
[  5]   Sent    80000 / 80000 packets (100%) received

关键指标解读 ：Bitrate 一行的上行速率（如 31.3 Mbits/sec）即实测上行带宽，应不低于平台要求；Retr 为重传次数，数值越大说明链路越不稳定；Sent ... received (100%) 表示发送成功率，低于 100% 说明存在丢包。

3.4 检测丢包率与链路质量

丢包率高、延迟波动大会导致心跳超时被判定为离线。可用 ping 和 traceroute 检测链路质量：

# 连续 ping 100 个包统计丢包率
ping -c 100 -i 0.2 8.8.8.8
输出示例
100 packets transmitted, 98 received, 2% packet loss
rtt min/avg/max/mdev = 12.345/18.678/45.123/6.789 ms
使用 tcping 检测指定端口的 TCP 连通性（需安装 tcping）
tcping -t 5 203.0.113.10 80
输出示例：Connected to 203.0.113.10:80, time=23.456ms
使用 traceroute 查看链路经过的每一跳
traceroute -n 8.8.8.8
输出示例
1  192.168.1.1   1.234 ms
2  100.64.0.1    5.678 ms
3  203.0.113.1   12.345 ms

关键指标解读 ：packet loss 应尽量为 0%，超过 1% 就需要排查链路问题；rtt avg 为平均延迟，波动大（mdev 偏高）说明链路不稳定；tcping 用于确认关键端口是否被防火墙拦截；traceroute 第二跳若出现 100.64.x.x，进一步佐证处于 CGNAT 环境。

4. 常见原因二：节点硬件与磁盘 IO 瓶颈

PCDN 本质上是把内容缓存到边缘节点，再分发给附近用户。磁盘读写速度和稳定性直接决定缓存命中率和分发效率。

• 磁盘 IO 过低：机械硬盘在并发读写场景下容易成为瓶颈，建议使用 SSD 或 NVMe。
• 缓存目录空间不足：剩余空间太少会导致缓存无法写入，节点会被判定为不可用。
• 内存不足：缓存索引和热数据需要内存支撑，内存过小会导致频繁换页。
• CPU 负载过高：如果节点同时跑着其他业务，CPU 被打满，处理请求自然变慢。

建议监控磁盘 IO、内存占用和 CPU 负载，确认硬件资源没有被其他进程抢占。

5. 常见原因三：软件配置与版本问题

很多时候问题不在硬件，而在配置。版本过旧、参数不合理、日志没开全，都会让你误以为"平台不给量"。

• 版本过旧：旧版本可能存在已知 bug 或协议兼容问题，建议升级到最新稳定版。
• 并发参数不合理：连接数、线程数、队列长度等参数设置不当，会导致请求堆积或拒绝。
• 缓存策略配置错误：缓存淘汰策略、分片大小、预取规则等配置不当，会影响命中率。
• 日志级别过低：日志没开全，你根本看不到调度请求和失败原因，排查无从下手。

建议先开启完整日志，观察一段时间，看看是否有请求进来、失败原因是什么，再针对性调整配置。

6. 常见原因四：节点在线稳定性差

PCDN 调度系统会优先把请求分配给在线稳定、响应快速的节点。如果你的节点频繁掉线、重启或网络抖动，调度权重会被大幅降低。

• 频繁重启：检查是否有 OOM、断电、进程崩溃等问题。
• 网络抖动：丢包率高、延迟波动大，会导致心跳超时被判定为离线。
• 时间不同步：节点时钟偏差过大会影响协议握手和调度判断。
• 长时间离线：离线越久，重新上线后恢复调度所需的时间越长。

建议保证节点 7×24 小时稳定在线，并配置自动重启和健康检查，减少人为干预。

7. 排查思路总结

与其抱怨平台，不如按下面的顺序系统排查一遍：

1. 看日志：确认是否有调度请求进来，失败原因是什么。
2. 查网络：检测 NAT 类型、公网可达性、上行带宽和丢包率。
3. 查硬件：确认磁盘 IO、内存、CPU 是否满足要求。
4. 查配置：核对版本、并发参数、缓存策略和日志级别。
5. 查稳定性：确认节点在线时长、重启频率和网络抖动情况。

按照这个顺序逐项排查，大多数"跑不起来"的问题都能找到根因。平台调度规则我们无法控制，但自身节点质量、网络环境和配置调优，是完全可以掌握在自己手里的。

8. 结语

PCDN 跑不起来，先别急着甩锅给平台。把日志打开、把网络测一遍、把硬件和配置过一遍，你会发现大部分问题都出在自己这边。把能控制的部分做到位，剩下的交给时间和耐心。希望这篇排查思路能帮你少踩坑、快见效。