如何用Clash分流规则实现P2P流量分流？

凌晨三点十七分，我的Telegram频道里炸了锅。一条消息被置顶，来自一个ID叫“算力海盗”的老哥，他发了一张截图：矿机监控面板上，ETH算力曲线像心电图一样骤停，旁边配文——“机房路由器半夜自动重启，所有矿机掉线，排查两小时，发现是BT下载流量把上行带宽塞满了。谁他妈在用机房网络下《繁花》全集？”

底下评论区瞬间涌出三十多条回复，一半是幸灾乐祸的表情包，另一半是正经讨论：“你路由器上没做分流？”“Clash规则里写个P2P指向代理不就完了？”“说得轻巧，矿机流量走直连，BT流量走代理，你分得清吗？”

我盯着屏幕，突然意识到一个被大多数人忽略的真相：在虚拟币挖矿和P2P下载共存于同一网络环境的今天，Clash分流规则早已不是“科学上网工具”那么简单。它成了数字矿场里的一把手术刀，切得开流量，也切得开利益纠葛。

---

场景一：那台被P2P流量“绑架”的矿机

让我们把时间拨回三天前。深圳某城中村出租屋，五平米的空间里塞着六台显卡矿机，散热风扇的轰鸣声像一台永不停歇的直升机。阿杰是这里的“矿场主”，他同时干着另一件事——用同一台路由器挂BT下载，做“PT站”的种子保种，赚积分换上传量。

“矿机要稳定，延迟要低，丢包要少；BT要速度，连接数要多，上下行都要拉满。”阿杰说这话时，正蹲在地上用网线把矿机直连路由器LAN口，而他的笔记本电脑则通过Wi-Fi连着同一个网络。

问题出在晚上八点。PT站新发布了一部4K修复版《银翼杀手》，种子热度飙升，阿杰的BT客户端瞬间吃满50M上行带宽。矿池的提交延迟从80ms飙升到800ms，矿机开始频繁提交无效份额——ETH算力没变，但每天收益直接砍了15%。

“我试过限速，但BT客户端限速后上传量就降，PT站考核要挂。”阿杰挠着头，“后来我试了Clash，但默认规则全走代理，BT流量过代理反而更慢，矿机流量也被代理拖累。”

他需要的不是“全局代理”，而是一套精准的“分流手术”：让矿机流量直连矿池，让BT流量走代理（或者干脆直连但限速），让网页浏览走代理节点，让系统更新走直连。

---

场景二：Clash分流规则的核心逻辑——不是“分”，而是“判”

很多人对Clash分流的理解停留在“哪个域名走代理，哪个IP走直连”。但面对P2P流量，这套逻辑彻底失效。因为P2P没有固定域名，它是一大堆随机IP的乱序连接，端口从6881到65535随机跳动，甚至伪装成HTTPS流量。

关键认知：P2P分流不能靠“域名规则”，必须靠“IP规则”和“进程规则”双管齐下。

阿杰后来在Clash配置里写了这样一段逻辑：

yaml rules: # 矿池流量必须直连，延迟第一 - IP-CIDR,192.168.1.0/24,DIRECT - DOMAIN-SUFFIX,ethpool.org,DIRECT - DOMAIN-SUFFIX,ethermine.org,DIRECT

# P2P流量识别：常见BT端口段 - DST-PORT,6881-6889,REJECT - DST-PORT,51413,REJECT - DST-PORT,8999,REJECT

# 或者更狠一点：让BT流量走代理，但代理节点只选“允许P2P”的 - DST-PORT,6881-6889,PROXY

但问题来了：REJECT会让BT客户端疯狂重试，反而产生更多无效连接；PROXY则会让BT流量绕过代理节点，导致代理服务器被封IP。

真正的解法，是“三层漏斗”：

1. 第一层：进程匹配（仅限Clash Premium内核）。阿杰把BT客户端（qBittorrent.exe）单独拉出来，指定它走“P2P策略组”，而这个策略组的下游是“直连+限速”。矿机程序（PhoenixMiner.exe）则被指定走“矿池策略组”，强制DIRECT。

yaml rules: - PROCESS-NAME,qBittorrent.exe,P2P_DIRECT - PROCESS-NAME,PhoenixMiner.exe,MINER_DIRECT

1. 第二层：端口兜底。对于局域网内其他设备（比如手机、智能电视），用DST-PORT规则把常见的BT端口（6881-6889、51413等）指向一个“限速节点”——这个节点本质上是一个本地虚拟网卡，通过tc命令把上行带宽限制在1Mbps。

2. 第三层：IP段排除。某些PT站会使用特定的Tracker服务器（比如tracker.ptchina.org），这些域名必须走代理（因为国内直连会DNS污染），但实际下载的Peer IP则走直连。所以规则要写成：

yaml - DOMAIN-SUFFIX,ptchina.org,PROXY - IP-CIDR,0.0.0.0/8,DIRECT

---

场景三：虚拟币矿场的“流量经济学”

阿杰的困境不是个例。我认识一个在内蒙古做托管矿场的老周，他管理着2000台矿机，网络架构是“三线BGP+双路由”。但真正让他头疼的不是矿机，而是矿场宿舍里那帮技术员的私人设备。

“他们晚上用迅雷下游戏，下完就开着上传，把矿场的公网IP搞进了PT站的封禁名单。”老周说，“更气人的是，有人用矿机网络挖门罗币（Monero），但挖矿软件走的代理节点是美国IP，矿池检测到延迟过高直接拒绝份额。”

老周的解决方案是“物理隔离+逻辑分流”：

• 物理层：矿机单独接一台千兆交换机，走独立VLAN，物理上不跟办公网互通。
• 逻辑层：办公网出口路由器上跑Clash，但规则只对办公网生效。矿机VLAN的流量直接NAT出去，不经过Clash。

但老周后来发现一个问题：矿机的固件更新和远程管理需要走外网，而某些矿池的备用端口（比如Stratum协议的非标准端口）会被防火墙误杀。 于是他在Clash里加了这样一条：

yaml - IP-CIDR,192.168.10.0/24,DIRECT - DST-PORT,3333,DIRECT # 蚂蚁矿机S19的默认Stratum端口 - DST-PORT,4444,PROXY # 备用Stratum端口，走代理防封

---

场景四：P2P分流的“反直觉陷阱”

你以为写完规则就万事大吉？阿杰在实战中踩过三个坑，每一个都让他损失了半天的收益。

坑一：DNS污染导致P2P流量“迷路”
BT客户端在获取Peer列表时，会向Tracker服务器发起HTTP请求。如果Tracker域名被DNS污染（解析到127.0.0.1），客户端就找不到Peer，自然没有下载速度。阿杰的Clash配置里虽然写了DOMAIN-SUFFIX,tracker.com,PROXY，但BT客户端的DNS查询走的是系统默认DNS（运营商的），而不是Clash的DNS。

解法：在Clash配置里启用dns模块，并设置enhanced-mode: fake-ip。这样所有域名解析都经过Clash，Tracker域名走代理解析，矿池域名走直连解析。

yaml dns: enable: true enhanced-mode: fake-ip nameservers: - 8.8.8.8 - 1.1.1.1 fallback: - 119.29.29.29

坑二：UDP流量被“误伤”
P2P下载的Peer通信大量使用UDP协议（尤其是uTP和µTorrent Transport Protocol）。而Clash默认规则里，很多人的PROXY策略组只代理TCP流量，UDP直接丢弃。结果就是：BT下载速度极慢，但CPU占用率飙升。

解法：在策略组里显式声明proxy: true和udp: true，或者针对P2P策略组单独设置udp: true。

坑三：代理节点的“出口IP”被PT站标记
如果你让BT流量走代理，而代理节点的IP恰好是某家云服务商的机房IP（比如DigitalOcean或Vultr），PT站会直接判定为“盒子”或“作弊”，轻则警告，重则封号。

解法：P2P流量最好“直连+限速”，而不是走代理。如果非要走代理，必须选择“住宅IP”节点（比如某些机场提供的家宽出口），但成本极高。

---

场景五：终极方案——“双Clash实例”与“策略组嵌套”

阿杰最后悟出的终极方案，是跑两个Clash实例。一个负责“常规流量”（浏览器、社交、邮件），另一个负责“P2P流量”（BT、PT、电驴）。两个实例监听不同的端口，通过路由器上的策略路由把不同设备的流量分发到不同端口。

具体实现：

1. 在路由器（OpenWrt）上装Clash Premium，监听7890端口。
2. 在NAS上装另一个Clash，监听7891端口。
3. 路由器上的Clash规则里，把NAS的IP地址（192.168.1.100）的所有流量转发到7891端口。
4. NAS上的Clash规则里，只配置P2P相关规则，比如：

yaml rules: - PROCESS-NAME,qbittorrent,DIRECT - PROCESS-NAME,transmission,DIRECT - DST-PORT,6881-6889,REJECT - MATCH,PROXY

这样，NAS上的BT下载流量走NAS的Clash，直连但限速；手机和电脑的网页流量走路由器的Clash，走代理节点。两者互不干扰。

---

场景六：虚拟币“矿工”的P2P分流实战模板

写到这里，我猜你已经迫不及待想要一份可以直接套用的规则了。以下是我为阿杰和老周设计的“矿工专用分流模板”，你可以根据自己的网络环境微调：

yaml

proxy-groups: - name: "矿池直连" type: select proxies: - DIRECT - name: "P2P限速" type: select proxies: - "限速节点" # 这个节点实际上是一个本地虚拟网卡，用tc命令限速 - DIRECT - name: "代理节点" type: url-test proxies: - 你的机场节点1 - 你的机场节点2 url: "http://www.gstatic.com/generate_204" interval: 300

rules: # 矿机流量（按IP段） - IP-CIDR,192.168.2.0/24,矿池直连 # 矿池域名（直连） - DOMAIN-SUFFIX,ethermine.org,矿池直连 - DOMAIN-SUFFIX,ethpool.org,矿池直连 - DOMAIN-SUFFIX,f2pool.com,矿池直连 # P2P进程（限速直连） - PROCESS-NAME,qbittorrent.exe,P2P限速 - PROCESS-NAME,transmission.exe,P2P限速 - PROCESS-NAME,aria2c.exe,P2P限速 # P2P端口（拒绝或限速） - DST-PORT,6881-6889,REJECT - DST-PORT,51413,REJECT - DST-PORT,8999,REJECT # 其他流量走代理 - MATCH,代理节点

---

场景七：别忘了“流量整形”这件事

分流只是第一步，真正的难点在于让P2P流量“有秩序地跑”。阿杰后来在Clash的script模块里写了一段Python脚本，定期检查BT客户端的连接数，如果超过500个，就自动把P2P策略组切换到“REJECT”模式三分钟，强制断开一部分连接。

python def main(): if get_bt_connections() > 500: set_policy_group("P2P限速", "REJECT") time.sleep(180) set_policy_group("P2P限速", "限速节点")

这种“动态整形”的好处是，矿机流量永远不会被P2P流量挤占，因为P2P流量在连接数超标时会自动“吃药”。

---

场景八：虚拟币热点与P2P分流的“隐秘关联”

你可能觉得奇怪：为什么虚拟币挖矿会和P2P分流扯上关系？原因有三：

1. 矿池协议本身是长连接，对延迟敏感，而P2P下载会产生大量短连接，挤占连接表。Linux系统默认的net.ipv4.tcp_max_syn_backlog只有1024，如果BT连接数超过这个值，矿机的Stratum连接就会被丢包。

2. 矿机固件更新往往通过BT协议分发（比如某些矿机厂商用BitTorrent来推送固件镜像），如果分流规则没写好，固件更新流量会走代理，导致下载速度极慢，甚至卡在99%永远完成不了。

3. 虚拟币交易所有时候会使用P2P网络来同步区块数据（比如BTC的区块链同步就是典型的P2P流量），如果Clash规则把8333端口（BTC的默认端口）错误地指向代理，同步速度会下降十倍以上。

---

场景九：最后的调试技巧——用“日志”代替“直觉”

阿杰在折腾了一周后，终于总结出一套调试方法论：

1. 开启Clash的日志输出，级别设为info。在日志里搜索P2P或REJECT，看看哪些连接被误杀了。
2. 用netstat -an | grep 6881 查看当前活动的BT连接，对比Clash日志中的规则匹配情况。
3. 在矿机上用ping和tcping测试到矿池的延迟，如果延迟超过100ms，检查是否有P2P流量在跟你抢带宽。

阿杰最后告诉我一句话：“分流规则不是写一次就完事的，它是活的。你的网络环境在变，矿池的IP在变，BT种子的热度在变，你必须每周检查一次规则命中率。”

---

凌晨五点，阿杰发来一张新的截图：ETH算力曲线恢复平稳，BT上传速度稳定在5Mbps，PT站积分每小时涨200分。他在群里发了一条语音，声音带着熬夜后的沙哑：“现在我的矿机和BT下载，就像两个互不打扰的室友，共用一条水管，但各自装了独立的水表。”

然后他补了一句：“对了，刚才我把Clash的规则文件备份了一份到GitHub，你们直接拿去用，记得把机场节点改成自己的。”

群里瞬间又炸了，但这次是清一色的“好人一生平安”表情包。我关掉手机，看了眼窗外泛白的天际线，心想：在虚拟币和P2P共存的灰色地带，一套好的分流规则，就是数字世界的“交通警察”——它不站队，只负责让每辆车都跑在自己的车道上。