宽带不够用的时候，绝大多数人的第一反应是「升级套餐」。但在动手交钱之前，有一类被老玩家玩了十几年的办法值得先算一笔账：单线多拨——同一条入户光纤、同一个宽带账号，在软路由上并行开多个 PPPoE 会话，把局端没锁死的带宽吃满。
它能让部分线路的下行从 500M 跑到 900M，也能让你折腾一整个周末最后一无所获。区别不在你的动手能力，而在你家局端的限速到底做在哪一层——这就是本文要从原理讲到配置的原因：先判断可行性，再决定要不要动 macvlan 和 mwan3。
有一条边界必须提前说清，否则你会在多拨成功之后才发现方向错了：多拨叠加的是「你家到运营商出口」这一段。你访问 Google、GitHub、ChatGPT 走的那段跨境路，和你拨出几个会话毫无关系，它由出口线路本身决定——同样的多拨配置，把节点换成自由猫这类 IEPL 专线，跨境那段的延迟和丢包体感能差出好几倍。本文第五、六节会专门讲「为什么本地多拨的 IP 对海外访问没用」。
一、多拨的原理与边界：局端限速做在哪一层，决定你能不能叠加
家用宽带的「1000M」不是一条从你客厅直通机房的专线，而是几段拼起来的：你家光猫到小区机房的 PON 段、机房 OLT 上行的汇聚段、再到 BRAS 和骨干出口。你签的套餐限速，可能落在其中任意一段，落点不同，结果天差地别。
而 PPPoE 是一个会话层协议。同一根网线上可以并行存在多个 PPPoE 会话，每个会话独立认证、独立拿一个公网 IP、独立建立一条逻辑通路。这就是「单线多拨」全部的物理基础：你没有凭空多出一根线，只是在同一条线上开了好几个「账户会话」——前提是局端不拦。
能不能叠加，取决于限速落点。下面这张表是判断的核心，看懂了比看十个教程都有用：
| 限速落点 | 典型场景 | 多拨能否叠加 |
|---|---|---|
| 账号级（AAA 下发单账号总带宽） | 2020 年后的多数城市光纤套餐 | ❌ 所有会话共享同一份额度，拨再多也不叠加 |
| 会话级（每条 PPPoE 会话独立限速） | 部分老式宽带、部分小区/校园宽带 | ✅ 常见叠加，2～4 个会话有明显收益 |
| 端口 / OLT 侧限速 | GPON 端口共享、上行收敛比 | ⚠️ 取决于端口余量；上行几乎不可能叠加 |
| 未额外限速，仅受物理端口限制 | 千兆内网、光猫或路由成瓶颈 | ✅ 常能叠加，此时瓶颈通常在你自己的设备上 |
结论很直接：「能不能多拨」的答案不在任何教程里，在你家局端。教程能教你的只是「假设可以，怎么配」；而验证必须你自己做（第二节给了 5 步实测法）。还要接受一个现实：即便今天能叠加，局端做一次策略调整就会失效，所以家庭主力网络不要建在多拨上——把它当成额外收益，而不是地基。
另外要先把三种形态区分清楚，它们经常被混着配，导致排障时找不到北：
- 单线多拨：一个物理口上开多个 PPPoE 会话，靠 macvlan 虚拟出多个 MAC 地址撑住（本文第三、四节主线）。
- 单口 / 多 VLAN 多拨：同一台光猫的不同 LAN 口接软路由不同网口，或在同一口上打 802.1q 标签划分 VLAN，各自拨号（当局端拒绝同口多会话时值得一试）。
- 多 WAN 多线：家里真有两条宽带（电信 + 移动）。这一支的负载均衡与策略路由在软路由性能优化完全指南的「多WAN 负载均衡」一节已讲过，本文不重复，只在需要对照的地方引用。
二、动手之前先验证：5 步判断你的线路支不支持多拨
先花 20 分钟验证，再决定要不要折腾配置。顺序反了，后面每一步都是在给一个错误前提打补丁。
2.1 第一步：确认光猫已是桥接，拨号动作在软路由上
多拨要求你掌握会话控制权，也就是「谁在拨号」。光猫自己拨号（路由模式）时，后面接什么设备都只是它的下级，你没法凭空多开一个会话。先把光猫改成桥接、由软路由 PPPoE 拨号——超管账号、LOID 注册、删掉原有的 PPPoE 连接、端口绑定这些步骤，家庭网络基础改造指南里有完整走法，照着做完再回来。
2.2 第二步：记录单拨基线，两种测速都要做
这是最容易偷懒、也最容易导致误判的一步。必须同时记两个数：
- 多线程基线：浏览器打开 speedtest.net 网页版或 fast.com，或者对内网一台机器
iperf3 -c 服务器 -P 8。这是你的「套餐理论值」。 - 单线程基线：同一条线路
iperf3 -c 服务器 -P 1，或用单线程下载工具拉一个大文件。这个数才是很多场景的真实上限。
两个数差得越多，说明这条线的「多线程潜力」越大——也说明多拨之后很可能有效果。如果单线程就已经贴满套餐值，多拨不会带来变化。
2.3 第三步：加第二个会话，看能不能拨上
最快的验证方式不是配软路由，而是用一个临时会话试探：在 OpenWrt 上手工建一个 macvlan 接口再拨一次（命令见 3.2），或者先试探局端态度——用光猫另一个 LAN 口接电脑、电脑单独拨一次。重点观察三件事：
- 认证是否成功（失败或超时 = 局端不允许同账号多会话）；
- 拿到的 IP 是否与第一个会话不同；
- 能持有多久（几秒、几分钟，还是稳定在线）。
2.4 第四步：核对 IP 与会话状态
# 看两个会话各自的状态与地址（OpenWrt）
ifstatus wan | grep -E '"up"|"address"'
ifstatus wan1 | grep -E '"up"|"address"'
# 分别从不同会话出网，看公网 IP 是否真的不同
curl --interface pppoe-wan -s https://ifconfig.me
curl --interface pppoe-wan1 -s https://ifconfig.me两个会话拿到不同公网 IP，说明会话独立成立；IP 相同则说明局端做了地址复用，这种情况下带宽通常也不会叠加（第五节末尾的排障表有对应处理）。
2.5 第五步：多线程复测，并逐步加会话数
按 1 → 2 → 4 → 8 的顺序增加会话，每个数量级都做一次多线程测速。你会看到两种典型曲线：线性上涨到某个数然后封顶（说明撞到了账号级或端口级限制），或者加到第三、四个会话就开始失败/频繁掉线（说明有会话数上限）。把那个数字记下来，它就是你能用的最大值——不要为了「再多一点」去写高频重拨脚本，那是掉线的直接原因。
| 实测现象 | 结论 | 该怎么走 |
|---|---|---|
| 第二会话认证失败 / 超时 | 局端禁止同账号多会话 | 停止单线多拨，考虑多 VLAN 或真正加一条线 |
| 能拨上、IP 相同、多线程不提速 | 账号级限速 | 多拨只多几个 IP，无带宽收益（见第六节） |
| 能拨上、IP 不同、多线程明显提速 | 会话级限速，可叠加 | 进入第三节配置，第四节用 mwan3 管理出口 |
| 拨上后几秒到几分钟掉线 | 局端会话数限制或在做检测 | 减少会话数；仍然掉就放弃，别硬扛 |
| 白天正常、晚高峰缩水严重 | 端口 / OLT 拥塞 | 叠加只能部分生效，方案不要建在多拨上 |
三、macvlan 虚拟 WAN：把一条网线变成多个可拨号的接口
同一个物理口发出去的 PPPoE 请求，源 MAC 都是同一个。不少局端就是靠 MAC 判断「这是同一台设备」，把后续会话直接拒掉。macvlan 解决的正是这一点：在同一个物理网卡上虚拟出多个带独立 MAC 的子接口，每个子接口各自拨号。
在动手之前，先把 OpenWrt 的基础概念对齐一下（接口、设备、防火墙区域三者的关系）——还没装过软路由的读者建议先看软路由入门指南，否则下面的 UCI 配置会像天书。
3.1 先理解 macvlan 的模式，别照抄参数
macvlan 有 bridge / private / vepa 等模式。家用场景用 bridge 就行，它的特点是虚拟接口之间可以互相通信，也不会阻断宿主机与虚拟接口之间的流量。用 private 会导致一些奇怪的「拨上了但拿不到网关」现象，是新手常踩的坑。
3.2 手工创建两个虚拟接口（重启会丢，仅用于验证）
假设你的 WAN 口是 eth1（先 ip link show 确认，别抄）：
# 创建两个 macvlan 子接口
ip link add link eth1 name vwan1 type macvlan mode bridge
ip link add link eth1 name vwan2 type macvlan mode bridge
# 拉起接口
ip link set vwan1 up
ip link set vwan2 up
# 确认 MAC 各不相同（关键：相同就等于没拨）
ip -d link show vwan1 | grep -E 'macvlan|link/ether'3.3 写成 UCI 配置，重启后仍然生效
手工命令只用于验证，正式环境要写进 /etc/config/network。OpenWrt 21.02 及以后用 option device，更早的版本用 option ifname（写错会表现为「配置保存了但接口不存在」）：
config device
option name 'vwan1'
option type 'macvlan'
option ifname 'eth1'
option mode 'bridge'
config device
option name 'vwan2'
option type 'macvlan'
option ifname 'eth1'
option mode 'bridge'
config interface 'wan1'
option proto 'pppoe'
option device 'vwan1'
option username '你的宽带账号'
option password '你的宽带密码'
option peerdns '0'
option ipv6 'auto'
option metric '10'
config interface 'wan2'
option proto 'pppoe'
option device 'vwan2'
option username '你的宽带账号'
option password '你的宽带密码'
option peerdns '0'
option ipv6 '0'
option metric '20'注意 wan2 上把 IPv6 关掉了，原因见 3.5 的排障表：多个会话同时申请 IPv6 前缀会互相抢，典型症状是「主线路 IPv6 突然不见了」。
3.4 防火墙区域必须补上覆盖网络，否则拨上了也不能上网
新增的接口默认不属于任何安全区域。把它们加进 wan 区域（LuCI 路径：网络 → 防火墙 → 区域 → wan → 覆盖的网络 勾选 wan1、wan2）：
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan1'
list network 'wan2'3.5 验证与排障：多拨失败时先看这张表
# 会话是否真的拨上（看 up 与 address）
ifstatus wan1 | grep -E '"up"|"address"|"proto"'
ip -4 addr show pppoe-wan1
# 看内核日志里 PPPoE 的认证过程
logread | grep -i pppoe | tail -20
# 指定接口出网，确认出口可用
curl --interface pppoe-wan1 -s https://ifconfig.me| 现象 | 原因 | 解决 |
|---|---|---|
| 接口不存在 / 配置保存无效 | UCI 用了旧字段名，或设备名拼错 | 21.02+ 用 option device；ubus call network reload 后复查 |
| 只有第一个会话能认证成功 | 局端按 MAC 判定同设备 | 确认 macvlan 的 MAC 唯一；必要时手工指定不同的 MAC |
| 拨上但完全不能上网 | 接口没加进防火墙 wan 区域 | 补齐 list network，重启防火墙 |
| 主线路 IPv6 消失 | 多个会话抢占 IPv6-PD 前缀 | 除主线路外 option ipv6 '0'，或给各会话分配不同前缀 |
| 拨上几秒后掉线，反复重连 | 会话数超限 / 局端检测 | 减少会话数；拉长重拨间隔，避免重拨风暴 |
| 网速反而变慢 | 软路由转发或 NAT 会话表成瓶颈 | 开 Flow Offloading，并控制会话数（见第五、七节） |
3.6 只想拿多个 IP、不追求叠加的简化做法
如果第二节实测结论是「能多拨但不叠加」，仍有一种合理用法：只保留 2～3 个会话，靠它们拿到不同公网 IP，用于 P2P 连接数、端口映射、本地多出口——不需要 mwan3 做均衡，只需要为每个会话配好路由与规则，避免互相打架。具体用法见第六节 6.2。
四、mwan3 配置实战：权重、策略、健康检测与粘性会话
多拨只是把「多条出口」摆出来，怎么用由 mwan3 决定。它的模型是四层，按这个顺序理解就不会乱：接口（interface）→ 成员（member，带权重）→ 策略（policy，成员的组合）→ 规则（rule，哪类流量用哪个策略）。
4.1 接口：先让 mwan3 认识你的两条 PPPoE
安装 luci-app-mwan3 mwan3 后，在「网络 → 负载均衡 → 接口」把 wan1、wan2 逐个启用。健康检测地址建议用国内稳定的公共 DNS（如 114.114.114.114、223.5.5.5），别用会被污染的境外地址——那会让 mwan3 误判线路已死。
config interface 'wan1'
option enabled '1'
option family 'ipv4'
list track_ip '114.114.114.114'
list track_ip '223.5.5.5'
option reliability '2'
option count '2'
option timeout '2'
option interval '5'
option failure_interval '5'
option recovery_interval '5'
option down '3'
option up '3'4.2 成员与权重：1:1 还是 3:1
成员（member）决定每条线在策略里占多少份。多拨出来的几条会话质量往往不一样（有的会话跑在主端口上、有的走的是拥挤的链路），所以别默认 1:1，先用 1:1 观察，再按实测把快的调高：
config member 'wan1_m1'
option interface 'wan1'
option metric '1'
option weight '2'
config member 'wan2_m1'
option interface 'wan2'
option metric '1'
option weight '1'4.3 策略：把「聚合」和「固定单线」分成两个策略
balanced 会把新建连接分到不同线路，backup 则只有主线路失效才切备线。多拨场景真正需要的是两个策略并存：一个聚合策略给能受益的流量，一个单线策略给必须稳定的流量。
config policy 'balanced'
list use_member 'wan1_m1'
list use_member 'wan2_m1'
option last_resort 'default'
config policy 'main_only'
list use_member 'wan1_m1'
option last_resort 'default'顺着这个分法，出口可以按「场景」分工，而不是简单粗暴地全量叠加：下载、更新、多设备并发的流量走聚合；游戏、会议、代理这类实时交互走固定单线。分工之后，聚合带来的吞吐和单线带来的稳定各归其位——像万达云这类同时提供中转与专线方案的机场，天然适配这种「下载走中转、交互走专线」的分配方式：策略组里把两类节点分开，再按设备或按规则指向即可，不必为每台设备单独换订阅。
4.4 健康检测的几个参数，比权重更重要
多拨最容易出现的不是「一条线断了不切」，而是「一条线假死了还在吃流量」：会话还在、IP 还在，但实际已经不通。把阈值配好能大幅减少这类玄学问题：
reliability：至少几个探测点通才算线路可用（2 个比较稳）；timeout/interval：超时 2 秒、间隔 5 秒是常用值，间隔太短会造成频繁切换；down/up：连续几次失败/成功才改状态（3 次可以过滤掉抖动）；failure_latency/recovery_latency：延迟超过阈值也算失败，适合作为「线路劣化」的提前量。
状态随时可查：mwan3 status 看当前选中线路与路由，mwan3 interfaces 看每条线的在线状态与延迟。
4.5 规则与粘性：同一连接别跳线，这是多拨体验的分水岭
mwan3 是按连接做哈希的，正常情况下同一个连接会稳定落在同一条线上。但线路抖动、会话重建、健康检测切换状态时，这个连接可能被分到另一条线——对普通网页影响不大，对下面这些是灾难：长连接（SSH、数据库、在线文档）、断点续传下载、需要登录态的站点（出口 IP 一变就要求二次验证）。缓解手段是给规则加 sticky，按源地址把设备粘在一条线上：
config rule 'lan_balanced'
option src_ip '192.168.10.0/24'
option dest_ip '0.0.0.0/0'
option proto 'all'
option use_policy 'balanced'
option sticky '1'4.6 代理流量必须固定单线，不要跟着 mwan3 漂移
这是多拨与科学上网结合时最重要的一条配置原则。代理客户端的节点连接本身也是一个（或几个）TCP/UDP 会话：如果它被 mwan3 均衡走了不同出口，你会看到三种典型症状——测速时快时慢、长连接频繁断开、登录境外站点反复要求验证。原因很简单：多拨换线 = 你的本地出口 IP 变了，服务端看到的会话来源也变了。
正确做法是给代理流量写一条专用规则，固定走一条质量最好的会话：
config rule 'proxy_pinned'
option src_ip '192.168.10.8' # 跑代理客户端的那台设备
option dest_ip '0.0.0.0/0'
option proto 'all'
option use_policy 'main_only'
option sticky '1'五、多拨到底能快多少：单线程、多线程与晚高峰的叠加规律
多拨最容易产生预期落差的地方在这里：四个会话不等于四倍体感。根本原因是 TCP 的单连接特性。
5.1 单连接只能走一条路
一条 TCP 连接在任意时刻只经过一条路径，它的吞吐上限由「该路径带宽」和「RTT × 接收窗口」共同决定。多拨让你有了多条路径，但单连接的流量并不会自动分流到多条路径上——除非应用层主动开多个连接。所以你会看到非常反直觉的现象：多拨之后测速网站的数字翻倍了，下载同一个大文件却几乎没变。
5.2 会叠加的场景 vs 不会叠加的场景
| 使用场景 | 是否享受叠加 | 原因 |
|---|---|---|
| 多线程下载器（aria2 -x16、IDM、迅雷）/ BT / PT | ✅ 明显 | 应用层主动开多连接，天然分流到多条线 |
| 多设备同时在线（一家人各看各的） | ✅ 明显 | 不同设备的不同连接可以落在不同线路 |
| 流媒体 4K（YouTube/Netflix） | ⚠️ 部分 | 播放器会开多条连接，收益取决于实现 |
| 单个大文件单线程下载 | ❌ 无 | 一条连接只走一条线 |
| 在线游戏、语音会议（UDP 单流） | ❌ 无，还可能更差 | 单流不受益，换线还会导致断连 |
| 网页浏览 | ⚠️ 极轻微 | 并发连接数有限，单连接体积小 |
5.3 测速方法论：别被数字骗
# 单线程（看单条路径的真实上限）
iperf3 -c 服务器地址 -P 1 -t 20
# 多线程（看叠加潜力，P 值取 8 以上更明显）
iperf3 -c 服务器地址 -P 8 -t 20
# 多拨前后、同一服务器、同一时段各测一轮，才有对比意义三个要点：同一服务器（不同测速点的服务器本身就会造成差异）、同一时段（跨时段对比没有意义）、两种线程数都测（只看多线程会高估收益，只看单线程会误判多拨无效）。想验证晚高峰表现，就在 20:00～23:00 再测一轮并记录下来。
5.4 上行是另一个故事
下行的叠加在部分地区还能成立，上行几乎没有希望：OLT 上行侧本身就是共享且收敛的，上行限速也大多做在账号级。指望靠多拨把 100M 上行的直播推流变成 300M，基本是不现实的。有上行刚需（直播推流、大文件回传）的读者，直接看套餐升级或专线方案更省事。
5.5 别让软路由成为新的瓶颈
多拨让软路由同时维护多条会话、多份 NAT 会话表与防火墙规则，转发开销是实打实增加的。开 Flow Offloading / SFE 之前先确认与代理插件的兼容性，MTU 与 MSS 钳制也要跟着调——这些内容在软路由性能优化完全指南里有逐项说明，那篇讲的是「转发层怎么不掉链子」，本文讲的是「入口多几条」，两篇配合看才完整。
5.6 单连接场景下，决定体验的是出口而不是入口
把 5.1 的结论再往前推一步：日常最影响体感的那几件事——打开 ChatGPT、拉一个 GitHub Release、跑一次视频会议——基本都落在「少数几条连接」上，多拨对它们几乎没有帮助。这些场景的变量只有一个：那条出口线路的延迟和丢包是否稳定。
所以如果你的主要痛点是「上网慢、AI 工具连接不稳」，正确的优化顺序是先把出口换成一条稳定的专线，而不是去研究局端能不能多拨。像SS-ID这类节点数量不多、但每条都长期稳定的纯专线方案，配合 4.6 的固定单线规则钉住一条出口，在这种「连接数少、要求稳」的场景里比任何本地多拨都管用。跨境延迟到底由哪几段构成、哪一段多拨能优化、哪一段完全取决于出口，数据包旅程与代理延迟拆解讲得比这里更细。
六、多拨拿到的多个公网 IP，对海外访问几乎没有价值
这是多拨最容易产生方向性误解的地方。很多人以为「拨出 4 个 IP 就多了 4 个出口」，对国内的部分玩法确实成立，但对海外访问基本没有帮助。
6.1 海外服务看到的是你的落地 IP，不是你家拨号的 IP
你访问境外站点时，如果走的是代理/专线，对方看到的地址是节点的落地 IP；如果不走代理直连，看到的也是运营商出口侧的地址——无论哪种情况，都和你家拨号拿到了几个 IP 无关。本地多拨的 IP 属于同一个城市、同一个运营商的地址段，对境外平台来说它们几乎是等价的。想自己验证很简单：
# 直连看到的（本地出口/运营商地址）
curl -s https://ifconfig.me
# 走代理后看到的（节点落地地址）
curl --proxy http://127.0.0.1:7890 -s https://ifconfig.me
# 再看两个地址的归属与 ASN，就知道为什么平台只认后者
curl -s "https://ipinfo.io/$(curl --proxy http://127.0.0.1:7890 -s https://ifconfig.me)"6.2 本地多个公网 IP 的真正用途
它们并非一无是处，只是价值在国内场景：多线程 P2P 的连接数与更好的 peer 分布、端口映射与远程访问（NAS、监控）、绕过某些「按单 IP 限速」的服务、给不同设备分配不同出口做隔离。需要这些就用，但别把「多 IP」当成海外访问的增益。
6.3 更要紧的是：多拨会破坏出口稳定性
第二节到第五节都在讲「怎么让多拨可用」，但真正的风险是它的副作用：只要代理流量没有固定单线，出口就会在会话之间漂移。表现为——登录境外平台反复要求验证码、SSH/长连接莫名断开、断点续传从头开始、在线协作工具提示「会话异常」。这类症状很少被归因到多拨上，于是排障时会一直怀疑节点。
6.4 平台看的是出口 IP 画像，而多拨一个维度都改变不了
对境外平台而言，你的「地址画像」由几个维度组成：ASN 属于哪类主体、是不是数据中心段、该地址的历史行为、以及请求来源是否稳定。多拨能改变的维度是零——它给的都是同一个运营商、同一个城市的地址。真正决定账号能不能稳定用的是出口 IP 的类型：
| 出口 IP 类型 | 平台侧观感 | 适合场景 |
|---|---|---|
| 数据中心 IP（机房段） | 易被标记为代理，风控概率高 | 看视频、查资料、日常浏览与下载 |
| 住宅 IP（ISP 分配给家庭用户） | 与普通用户无异，风控最友好 | 跨境电商多账号、平台后台、需要长期登录态的运营 |
| 原生 IP（归属地与落地地一致） | 地域信息可信，解锁判定更顺 | 流媒体区域解锁、需要本地化身份的注册流程 |
所以「多拨 + 住宅 IP 出口」才是跨境电商、多账号运营这类场景的完整答案：前者解决本地带宽与多设备，后者解决账号可用性——两件事必须分开看，混在一起就会出现「带宽翻倍了，账号还是被封」的困惑。这方面仙路湾的定位正好对应（住宅 IP / 原生 IP 出口），适合作为多账号运营与流媒体解锁的出口层；而防关联的整体架构——环境隔离、指纹、账号与 IP 的对应关系——在跨境电商多账号运营网络方案里有完整说明，本节不重复。
七、多拨 + 科学上网的正确架构：聚合走一类，代理走单线
把前面几节的结论拼起来，得到一个清晰的分层架构：
- 入口层：单物理口 → macvlan 虚拟出 N 个会话（数量取决于局端允许值）；
- 出口层：mwan3 管理 N 条线路，健康检测兜底，聚合策略给下载，单线策略给交互；
- 代理层：代理客户端所在设备固定走单线（
proxy_pinned规则），必要时配 TUN 或透明代理； - 分流层：国内直连、境外走代理、需要住宅/原生 IP 的业务单独走一条出口。
7.1 三条规则骨架（照这个顺序写）
# 规则 1：代理设备固定单线（最重要，必须在前）
config rule 'proxy_pinned'
option src_ip '192.168.10.8'
option dest_ip '0.0.0.0/0'
option proto 'all'
option use_policy 'main_only'
option sticky '1'
# 规则 2：下载专用设备走聚合
config rule 'download_bonded'
option src_ip '192.168.10.20'
option dest_ip '0.0.0.0/0'
option proto 'all'
option use_policy 'balanced'
# 规则 3：其余设备走聚合，按需调整
config rule 'default_rule'
option dest_ip '0.0.0.0/0'
option proto 'all'
option use_policy 'balanced'7.2 与代理插件共存时最容易踩的坑
mwan3 靠防火墙标记（netfilter mark + 策略路由）实现选线，而透明代理（TPROXY）和 TUN 模式也会动路由表与标记。两者叠加时的典型症状是「代理时通时不通、走内网地址异常」。规避原则有三条：代理设备用专用规则固定单线（避免它的流量参与哈希）、不要对代理流量做均衡、改完规则用 mwan3 status 与一次代理延迟测试双向确认。旁路由部署的读者还要注意代理流量与 mwan3 的入口顺序，旁路由完全指南里的透明网关部分有对应的排查顺序；多订阅、多策略组的编排（把聚合组与专线组分开）可以照着多机场订阅管理与策略组高级配置里的写法来。
7.3 上线后怎么确认「代理确实固定在一条线上」
规则写进配置不等于生效，多拨环境尤其如此（多个接口、多个策略，很容易命中错误的规则）。一套可复现的验证流程，五分钟能做完：
- 在跑代理的那台设备上连续查询 5 次出口 IP，目标是不同站点（
ifconfig.me、ip.sb、ipinfo.io）——5 次结果必须完全一致； - 同时另开一个终端跑
watch -n 2 mwan3 status，观察规则命中计数是否只落在main_only对应的那条线上； - 把该线路的上游临时断开，确认代理是「切到备用线路并恢复」而不是「一直断流」——如果完全断了，说明健康检测或
last_resort没配好； - 恢复上游后重复第 1 步，确认出口 IP 回到原来那个（这一步能验证
sticky是否按源地址粘住了设备）。
这四步做完，你才真正知道「聚合给下载、单线给代理」的架构成立了。跳过验证直接上生产，出问题时你会同时怀疑节点、DNS、线路和 mwan3 四个变量，排障成本翻几倍。
八、运营商侧的博弈：多拨为什么越来越难，被限制时什么表现
8.1 局端是怎么发现你在多拨的
它并不需要专门的「多拨检测」功能，日常的认证与流量系统就足够判断：同一个宽带账号在极短时间内发起多个 PPPoE 会话、源 MAC 相同（或高度相似）、多会话之间流量画像异常（例如同一账号同时出现大量并发连接），这些都容易被识别。部分地区的 BRAS 甚至直接把「单账号并发会话数」写进策略。
8.2 常见处理手段与对应现象
| 处理手段 | 你会看到的现象 | 应对 |
|---|---|---|
| 拒绝新会话 | 第二/第三个会话认证失败、超时 | 无解，转向多 VLAN 或多线方案 |
| 限制会话数上限 | 加到第 N 个开始失败，N-1 个可用 | 按实测上限配置，不要超 |
| 延时踢线 | 拨上几分钟后掉线，重拨又能用 | 会话数减少；拉长重拨间隔，别用高频脚本 |
| 只放行一个会话的流量 | 所有会话都在线，但只有一个有流量 | 等于无法叠加，放弃带宽叠加诉求 |
| 账号级限速兜底 | 多会话可用、加起来还是套餐额度 | 多拨只剩「多 IP」价值（见第六节） |
8.3 为什么「别人能用，我不能」
多拨的可用性差异几乎全在局端侧，与你用的什么软路由无关。常见的影响因素包括：宽带品牌与局端 BRAS 型号、接入方式（GPON / EPON / 老式 ADSL 改造）、小区是否二级运营商转售、套餐类型（家庭套餐与企业/校园套餐策略不同）、以及所在城市的策略版本。所以看到「某某地区可以四拨」的帖子时，把它当成线索而不是结论——它说明技术上可行，不代表你所在局端没锁。
8.4 什么时候该承认「光猫/接入方式」才是瓶颈
有一种情况是再怎么配都无效的：光猫本身是瓶颈。判断依据有三条——光猫只有一个千兆口且你已经跑满（LAN 侧 940Mbps 左右就是千兆上限）、光猫在桥接模式下 CPU 占用高导致丢包、以及光猫固件锁定了单会话。前两条的解法是换一台支持多口/更高性能的光猫，或者让运营商开通 2.5G 口；第三条基本无解，只能换接入方式。多拨是软件层的技巧，它的收益上限始终由硬件和局端两侧共同决定，别和物理上限较劲。
8.5 合规与使用边界
多拨是自己家里把已有线路用满的技巧，但有两条线不要越：不要把多拨出来的带宽共享转售或用于经营性用途（家用宽带的用户协议通常明确禁止），也不要为了叠加而把上行跑满导致同端口其他用户受影响。前者是协议风险，后者是让局端注意到你、然后给你单独上策略的最快方式。
九、多拨后的 14 个典型故障：现象、原因与解决
| # | 现象 | 原因 | 解决 |
|---|---|---|---|
| 1 | 第二个会话拨不上 | 局端禁止同账号多会话 | 改用多 VLAN 或真正加线，别再折腾 |
| 2 | 所有会话同一个 IP | 地址复用 / 账号级限速 | 放弃带宽叠加诉求，按第六节用其中价值 |
| 3 | 多拨后测速翻倍，下载没变 | 单连接只走一条线 | 正常现象，换多线程下载器才有收益 |
| 4 | 拨上几分钟就掉线 | 会话数超限或被检测 | 减少会话数，拉长重拨间隔 |
| 5 | 接口配置保存了但不存在 | UCI 字段版本不符 / 设备名错 | 21.02+ 用 option device，重启 network 服务 |
| 6 | 只有一条线有流量 | mwan3 规则顺序或策略写错 | 用 mwan3 status 看规则命中，确认策略名一致 |
| 7 | 线路假死仍被选中 | 健康检测参数太宽松 | 补 track_ip、收紧 timeout 与 down |
| 8 | 登录境外站点反复要验证码 | 出口随线路漂移 | 代理流量固定单线 + sticky |
| 9 | SSH / 长连接莫名断开 | 同一连接中途换线 | 同上；实时交互流量不要参与均衡 |
| 10 | 主线路 IPv6 消失 | 多会话抢占 IPv6-PD | 副会话关 IPv6，或分开前缀 |
| 11 | 晚高峰叠加失效 | 端口 / OLT 拥塞 | 预期内，叠加收益只在非拥塞时段 |
| 12 | 整体网速比单拨更慢 | 转发 / NAT 会话表瓶颈 | 开 Flow Offloading，控制会话数，复查 MTU |
| 13 | 多拨后内网设备互访异常 | 接口被误放进 lan 区域或桥接关系被改 | 检查区域归属与桥接成员，别把虚拟 WAN 拉进 lan |
| 14 | DNS 解析随机变慢或失败 | 各会话拿到的运营商 DNS 不同、解析结果不一致 | 统一 peerdns '0' 并指定同一组 DNS |
表中第 1、2、4 条属于「局端不给」，再怎么调设备都没用；第 5～14 条属于可自修范围。遇到「连不上、断流、网速慢」这类通用症状，先把多拨与代理两个变量摘掉、只用单拨裸线路复现，再对照软路由科学上网故障排查完全指南按症状定位，能少走很多弯路。DNS 相关的第 14 条，在多拨环境里其实是高频问题——多条会话各自协商 DNS，解析结果漂移会表现为「时快时慢、偶尔解析失败」，统一 DNS 之后通常立刻改善。
十、成本与收益：什么情况下值得折腾多拨
把账算清楚，再决定投不投入时间：
| 你的情况 | 建议 | 理由 |
|---|---|---|
| 大流量下载为主、多设备、实测能叠加 | ✅ 值得做 | 多线程与多设备天然吃满叠加，收益明确 |
| 单线程下载为主、视频会议为主 | ❌ 不值得 | 单连接不受益，还引入漂移风险 |
| 需要上行（直播、回传） | ❌ 不值得 | 上行叠加基本不成立，升级套餐更直接 |
| 晚高峰卡顿为主要痛点 | ⚠️ 部分值得 | 拥塞时段叠加会缩水，优先优化出口线路 |
| 远程办公 / 跨境运营 | ❌ 不建议作为主力 | 稳定性优先，多拨反而破坏出口一致性 |
| 实测「能多拨但不叠加」 | ⚠️ 视需求 | 只当「多 IP 工具」用，别期待提速 |
还有一个隐性成本经常被忽略：维护成本。多拨配置对固件升级、插件更新、局端策略调整都敏感——升级后掉会话、换固件后接口名变化、局端封了多拨，都会让你重新修一遍。所以它更适合「愿意定期打理」的玩家，而不是「配好就不想再碰」的家庭网络。
想要「配好就不碰」的稳定体验，把钱花在出口线路上收益更确定：一条稳定的专线对打开 AI 工具、跑跨境业务、看 4K 的帮助是每天都生效的，而多拨的收益只在你做多线程下载时才出现。机场按预算怎么选、每档的带宽与设备数怎么权衡，机场价位档位选择指南里有分档对照表，可以按自己实际用量套。
十一、上线前自检清单与压测步骤
配置完成后按顺序过一遍，能省掉大量「配好了但有一处忘了」的问题：
- 会话层：每个会话
ifstatus显示 up，且 IP 互不相同（ip -4 addr核对）； - 路由层：
mwan3 status能看到所有接口在线，规则命中符合预期； - 防火墙：新增接口都在 wan 区域，内网可正常访问外网；
- 健康检测：手工断开一条线的上游，观察是否在
down阈值内切换； - 代理固定：在代理设备上连续三次查询出口 IP（
curl --proxy ... ifconfig.me），结果应完全一致； - 压测：
iperf3 -P 1与-P 8各一轮，与第二节基线对比，晚高峰再补一轮； - 长连接验证：保持一个 SSH 会话或下载任务 30 分钟以上，确认不断线（这是检验粘性配置最直接的实战方法）；
- DNS 一致性：确认各会话使用同一组 DNS，避免解析结果漂移；
- IPv6 复检：访问一个 IPv6 测试站点，确认没有出现「IPv4 走代理、IPv6 直连」的泄漏；
- 回滚准备：备份
/etc/config/network、/etc/config/mwan3与防火墙配置，出问题能 2 分钟退回单拨。
第 5、7、9 条是多拨环境特有的检查项，也是最容易被跳过的三项——它们恰好对应「为什么多拨之后账号老要验证、长连接老断、IPv6 网站绕过了代理」这几个真实痛点。整套配置的价值不在「拨上了几个会话」，而在这些稳定性的细节是否闭环。
十二、常见问题（FAQ）
Q1：多拨会不会被运营商封宽带？
更常见的处理是限制会话数、踢线或把带宽兜回账号额度，直接封宽带的案例相对少见，但用户协议通常禁止共享转售和经营性使用。自己家用、不转售，风险面小得多。
Q2：多拨需要几个网口？
单线多拨只需要一个 WAN 口——多个会话都跑在 macvlan 虚拟出来的子接口上。只有在局端拒绝同口多会话、需要走多 VLAN 时，才需要占用更多网口。
Q3：光猫能自己多拨吗？
部分光猫固件支持多 WAN/多会话，但可控性和日志能力都远不如软路由，而且很多光猫会把 IPv6 前缀分配搞乱。能上软路由就别折腾光猫。
Q4：多拨后游戏会更流畅吗？
不会。游戏是低带宽、低延迟、单流的场景，既享受不到叠加，还可能因为线路切换而瞬断。游戏优先场景应该固定单线，并把代理流量钉在延迟最低的那条线上。
Q5：多拨能突破机场的限速吗？
不能。机场的限速在节点侧，和你有几条本地会话无关。多拨只影响「你家到运营商」这一段。
Q6：为什么多拨之后测速网站数字好看，实际体验没变？
测速网站默认开多线程，测的是聚合吞吐；而你日常的单连接任务只能走一条线。判断多拨是否真的有用，要看你自己的主要场景是不是多线程。
Q7：可以给不同的会话配不同的 DNS 吗？
技术上可以，但建议不要：多条会话各自协商 DNS，解析结果会漂移，表现为「时快时慢、偶尔解析失败」。统一 DNS 并交给软件层的分流方案处理更稳。
Q8：多拨后 IPv6 老是出问题怎么办？
最稳的做法是只在主会话上启用 IPv6，其余会话显式关闭。多会话同时申请 IPv6-PD 前缀，很容易出现主线路前缀被抢、部分网站走 IPv6 直连的泄漏问题。
Q9：mwan3 和代理插件冲突，怎么判断是谁的问题？
做变量隔离：暂停代理，只用裸线路测试多拨分流；再用代理测试单线。哪一步坏掉，问题就在哪一层。多数冲突来自「代理流量参与了 mwan3 哈希」。
Q10：多拨配置能跟着固件升级保留吗？
能，前提是走 UCI 配置而不是手工 ip link 命令。手工创建的命令重启即失效，升级后更容易出现「虚拟接口不见了、拨号失败」的假故障。
Q11：一条线多拨和多买一条宽带，选哪个？
看目的：要稳定冗余和可预期带宽，加线更靠谱（两条物理线不会因为局端策略一天失效）；要零成本榨取现有线路余量，多拨值得一试，但别把它当主力方案。
Q12：多拨拿到多个 IP，能不能用来做多账号运营？
基本无效。多个本地 IP 属于同一运营商同一地区，平台侧看不到区分度；多账号真正需要的是不同地域、不同网络类型的出口（住宅 IP / 原生 IP），这一点第六节讲得更透。
Q13：多拨后内网设备互访变慢或失败？
多半是虚拟接口被错放进 lan 区域，或桥接关系被改动。虚拟 WAN 只应属于 wan 区域；内网互访异常时先检查区域归属与桥接成员，再查 mwan3 是否把内网流量也纳入了规则。
Q14：四个会话是不是一定比两个好？
不一定。会话越多，转发开销、conntrack 表压力、局端触发检测的概率都上升，而单连接的体验不会因此变好。多数人的收益在 2～3 个会话就已经到顶，先测再定。
Q15：多拨能不能替代双线冗余？
不能。多拨的多条会话走的是同一条物理线路和同一个局端端口，局端一断全断；真正需要冗余还是要两条独立的物理线路。
Q16：配置完多拨，软路由还能做旁路由吗？
能，但要理清顺序：多拨在 WAN 侧，旁路由是 LAN 侧的部署方式，两者本身不冲突。容易出问题的是「旁路由上的代理流量又参与了 mwan3 均衡」，所以固定单线规则要在旁路由场景下额外确认一遍。
十三、推荐阅读
- 软路由异地组网完全指南——多拨解决「入口更宽」，异地组网解决「远端怎么进来」，两套配置在同一台软路由上共存时的规则冲突值得一并看。
- 软路由 DNS 分流与防污染完全指南——多拨后解析路径变复杂，国内外域名分流与去广告要在软件层做干净，别再靠会话数硬扛。
- 晚高峰变慢完全指南：TCP 拥塞控制与 BBR——多拨在拥塞时段的收益为什么缩水、把线路换成更高优先级的出口是否划算，这篇从拥塞控制角度给了解释。