两条宽带同时入户这件事，放在几年前还算个折腾活儿，现在装维师傅上门，光猫后面挂个多网口设备就能开搞。但“能拨上去”和“拨得稳、跑得快、掉线不慌”完全是两码事。双出口PPPoE拨号说白了就是让一台路由设备同时用两个账号（或两条线路）完成PPPoE认证，拿到两个公网地址，再按规则决定哪些流量走哪条线、哪条线挂了自动切。它解决的核心痛点是带宽不够用和单线不稳：小型工作室上传素材卡半天、家里三个人同时开会就掉帧、门店收银遇到线路检修直接停摆。这套东西适合有一定网络基础、动手能力尚可的读者——不必是专业网工，但你得愿意看日志、改配置、做验证。下面我按自己踩过的坑和最后的落地形态，从头讲一遍。
1. 双出口PPPoE拨号到底在解决什么问题
1.1 单出口的瓶颈往往不是“总带宽”而是“上行”和“并发”
很多人一上来就盯着下行数字，觉得千兆够用了。实际用起来难受的地方通常不在下载。我服务过的一个小团队，十二个人，日常是代码托管、设计稿同步、云端会议。下行五百兆，看着挺充裕，问题出在上行只有三十兆，赶上下午两个人往素材库传视频，会议就开始卡。这时候换更大的下行套餐没用，运营商给的上行是跟套餐绑死的，你只能加一条线。
所以判断要不要上双出口，我的经验是先看三件事：上行是否长期跑满、高峰期丢包和延迟是否明显上翘、断网一次的业务损失有多大。前两个指向带宽聚合，第三个指向冗余备份。这两件事的技术路径完全不一样，很多人没分清，装了两条线结果发现速度没变快，就以为是设备不行，其实是诉求和方案对不上。
还有一个容易被忽略的隐性瓶颈：单条线路的并发会话上限和NAT端口池。一些入门级设备在几百个并发连接后就开始丢包，表现是网页能打开但图片加载慢、视频一直在缓冲。这种情况加线也没用，换设备才有用。所以在动手之前，最好先确认一下自己到底是“带宽不够”还是“会话处理不过来”。
1.2 三种典型诉求，对应三套完全不同的策略
我把常见的需求归成三类，策略设计差别很大：
| 诉求 | 典型场景 | 关键策略 | 容易踩的坑 |
|---|---|---|---|
| 带宽叠加 | 多线程下载、素材同步、多人并发上传 | 按连接或按源地址做多路径分摊 | 单线程任务永远只跑一条线，测速看着没变化 |
| 线路冗余 | 门店收银、远程办公、监控回传 | 主备模式加健康检查，故障快速切换 | 切换后原有连接全断，未做会话恢复 |
| 业务分流 | 办公网与访客网分开、特定业务固定出口 | 按源地址段、按目标地址段做策略路由 | 规则顺序写反，后面的规则永远不命中 |
分流这个诉求在实操里最常被低估。举个很实际的例子：财务和收银类业务对公网地址变化极其敏感，登录态常常和地址绑定，你现在让它走负载均衡，一会儿从A线出去一会儿从B线出去，用户就会遇到“莫名其妙被登出”或者“验证码一直不对”。这类流量必须钉死在一条线上，宁可不叠加。
反过来，视频会议、大文件同步这种对地址不敏感但对带宽敏感的业务，才适合放开做分摊。判断标准很简单：这条业务换个公网地址会不会出问题。会，就固定；不会，才考虑分摊。这个判断我建议在画拓扑之前就列成清单，比事后调试省太多时间。
1.3 设备选型：软路由、企业级多WAN设备、还是光猫多拨
三种主流路子，各有明确适用边界：
开源软路由方案。一台低功耗小主机加两块以上网卡，装基于通用内核的路由系统，PPPoE、策略路由、连接跟踪、健康检查全部可控。优点是灵活到极致，规则想怎么写就怎么写，日志想看多细看多细；缺点是所有东西都得自己配，出问题也得自己查。我个人的偏好是这个，因为双出口场景里“能不能精细控制回程路径”几乎是决定成败的关键，成品设备给你的旋钮往往不够。
企业级多WAN路由器。开箱即用，带图形化的多线路配置、链路探测、会话保持选项。适合不想折腾、要求稳定交付的场景。局限是策略粒度通常停在“按接口权重”“按源地址段”这一层，遇到需要按目标域名或按端口做精细分流的场景就束手束脚。
光猫侧多拨。部分光猫支持桥接加多会话，但会话数量、认证方式、VLAN 绑定都由运营商侧决定，可控性最差。我一般只把它当临时验证手段，长期跑不建议。
还有一个前置条件必须确认：两条线路的接入方式。如果两条都是PPPoE拨号，那路由设备需要至少两个独立的三层接口（物理口或VLAN子接口）；如果其中一条是固定地址或动态地址方式，配置逻辑会不一样，但策略层的思路是通用的。线拉到设备之前，先把这层搞清楚，能省掉一次返工。
2. 核心原理拆解：会话、NAT与路由决策
2.1 PPPoE会话建立的四步握手和三个协商阶段
PPPoE这层很多人只记“填账号密码”，实际它分两大阶段：发现阶段和会话阶段。
发现阶段四个报文：客户端广播发起请求，接入设备单播回应提供报文，客户端再发一个请求指定选中的那个，服务端回确认并给出会话ID。这一步本质是“找到对端并拿到一个会话标识”，此时还没有任何认证。
会话阶段跑的是PPP本身：先是链路控制协商，谈最大接收单元、认证方式、魔术字；接着做认证，常见的是口令认证和挑战握手认证两种，后者会先用服务端下发的随机串做一次哈希，密码不裸奔；认证过了才进入网络层协商，由服务端分配地址和DNS。整个链条里任何一环超时，表现出来就是“一直在连接”然后失败。
理解这个顺序的价值在于排障。拨号失败时，日志里出现的是哪一阶段的错误，直接决定你该查什么：链路协商失败多半是物理链路或VLAN不对；认证失败是账号、密码、绑定的MAC或会话数超限；网络层协商失败往往是运营商侧地址池或策略问题。我见过有人认证失败就换网线，纯属浪费时间和耐心。
2.2 双出口下NAT和会话保持最容易翻车
这是双出口和单出口最大的技术分水岭。单出口时，内网所有流量从同一个公网地址出去，回包自然原路返回，没人关心路径。双出口时，如果同一个TCP连接的去程走了A线、回程从B线进来，而B线的NAT表里根本没有这条映射，包就被丢了。用户看到的现象是“网页转圈转很久然后失败”，但换台设备又好，极其迷惑。
解决靠的是连接跟踪加标记：连接建立的第一颗包做路径决策，把决策结果记在这条连接上，后续同一连接的所有包都强制走同一条出口。这套机制在内核里是现成的，关键是要确保你的策略路由规则在“新建连接”时就生效，而不是每个包都重新哈希一次。手动按包哈希（比如简单的源地址取模）在实验室看着挺美，真实流量一上去就开始随机失败。
还有一个细节：源地址转换的端口池。两条线各自维护独立的地址转换表，端口范围不共享。并发连接特别多的场景（比如一堆设备在跑P2P或大量短连接），单条线的端口池可能被打满，表现是新连接建立失败但老连接正常。把端口范围调大、把连接跟踪表容量和超时时间一并调优，能缓过来不少。
2.3 负载均衡和策略路由不是一回事，别混着用
这两个词经常被当成同义词，实际是两层东西。
策略路由解决的是“这个包该走哪条线”，靠的是路由表和规则，是确定性的、可预测的。负载均衡解决的是“在可选的多条线之间怎么分”，是分配算法问题。前者是后者的基础——你得先有办法把包塞进指定的出口，才谈得上在多出口之间分摊。
实际落地通常是组合拳：先用策略路由把必须固定的流量（收银、财务、远程管理）挑出来钉死在某条线；剩下的流量再交给多路径分摊算法，按权重或按哈希分配。这里权重怎么定？按带宽比例来，但要给上行留余量。比如一条一千兆下行三十兆上行，另一条三百兆下行一百兆上行，纯按下行算权重会造成上行瓶颈的那条线被压垮，实际权重应该更接近按上行能力来配，或者至少取两者中较紧的那个做参考。
我一般的做法是：默认路由给两条线做等价多路径，但权重按上行带宽比例分配；然后再用规则把大流量业务单独指到上行富余的那条。这样下载类流量自动吃到宽的那条，上传类流量不会挤在窄口上。
2.4 健康检查的判定逻辑决定了切换体验
探测做得好不好，直接决定用户是“完全无感”还是“每天都在骂”。核心参数就四个：探测方式、探测间隔、失败阈值、恢复延迟。
探测方式上，单纯ping运营商网关是不够的——网关活着但上游断了的情况很常见。我的经验是至少做两层：一层ping网关确认链路层通，一层对多个公共DNS做探测确认真正出网。两层都过了才算这条线健康。
失败阈值和间隔要一起看。间隔太短会误判，一次偶发丢包就切走，反而制造抖动；间隔太长切得慢，用户已经感受到卡了才动。三秒一次、连续三次失败判定为掉线，是我试下来比较平衡的组合。
恢复延迟这个参数最容易被忽略。线路恢复后如果立刻切回来，而线路本身还在抖，就会来回横跳，用户感受到的是“网络一会儿好一会儿坏”，比稳定慢一点还难受。加一个三十秒到一分钟的冷静期，确认稳定了再回切，体验会好很多。
3. 动手搭建：从接线到策略上线的完整流程
3.1 接口规划与物理接线，先把地基打对
先把命名定死，后面所有配置都靠它，改来改去最容易出错。我给个通用的规划思路，接口名按自己的环境替换：
- 线路一拨号接口：
pppoe-wan1，对应物理口或VLAN子接口eth1 - 线路二拨号接口：
pppoe-wan2，对应eth2 - 内网桥接口：
br-lan，地址段192.168.10.1/24 - 两条线路的接口度量值分别为 10 和 20，仅作为兜底优先级
接线顺序我建议这样：先把两条线分别接到设备的不同物理口，确认每个口都能单独拨号成功、单独能上网，再开始配双出口。跳过这一步直接上双线，一旦不通你根本分不清是线路问题、认证问题还是策略问题。这个“先单后双”的习惯，帮我省掉过至少三次无谓的排查。
提示：如果两条线来自同一个运营商同一个分光器，注意确认两条线路的VLAN标签是否相同。标签一样时，用同一物理口加两个VLAN子接口会冲突，必须分成两个物理口或者做端口隔离。
3.2 PPPoE参数：MTU、MRU和MSS钳制怎么算
这组参数是双出口场景里最容易被复制粘贴错的部分。
PPPoE会在以太网帧里额外塞进八字节头（六字节会话头加两字节协议字段），所以标准一千五百字节的以太网MTU，到了PPPoE链路上只能用1492。这个是硬约束，不是可选项。
再往下推TCP的MSS。MSS等于MTU减去IP头二十字节再减TCP头二十字节：
MSS = 1492 - 20 - 20 = 1452如果链路上还有额外的封装（比如某些场景下会多一层标签），还得继续往下减。我一般会把MSS钳制设在1400，留一点余量。原因很实际：路径上任何一跳设备的MTU比你以为的小，就会出现“小包正常、大包卡死”的经典症状——能打开网页首页，但图片加载到一半停住，或者SSH能登录但一执行大输出就断。
配置示例（接口名按实际替换）：
# 设置拨号接口MTU/MRU ip link set dev pppoe-wan1 mtu 1492 ip link set dev pppoe-wan1 mru 1492 ip link set dev pppoe-wan2 mtu 1492 ip link set dev pppoe-wan2 mru 1492 # 对两个出口方向做MSS钳制 nft add table inet mss nft add chain inet mss post { type filter hook postrouting priority mangle \; } nft add rule inet mss post tcp flags syn tcp option maxseg size set 1400MSS钳制一定要做在出方向，且要覆盖两条线路。只配一条的话，另一条线路上跑大流量就会间歇性失败，而且日志里几乎看不出异常，只能靠抓包定位。
3.3 策略路由落地：标记、路由表、规则三件套
双出口策略路由的标准套路是三件套：打标记、建独立路由表、加规则。我按最常用的分流需求写一套：
# 1. 建立两张独立路由表 echo "100 wan1" >> /etc/iproute2/rt_tables echo "200 wan2" >> /etc/iproute2/rt_tables # 2. 分别给两张表写默认路由 ip route add default dev pppoe-wan1 table wan1 ip route add default dev pppoe-wan2 table wan2 # 3. 打标记（示例：财务网段固定走线路一） nft add table inet pbr nft add chain inet pbr prerouting { type filter hook prerouting priority mangle \; } nft add rule inet pbr prerouting ip saddr 192.168.10.0/28 meta mark set 0x1 nft add rule inet pbr prerouting ip saddr 192.168.20.0/24 meta mark set 0x2 # 4. 按标记选表 ip rule add fwmark 0x1 table wan1 priority 100 ip rule add fwmark 0x2 table wan2 priority 110 # 5. 未标记流量走主路由表的等价多路径 ip route add default \ nexthop dev pppoe-wan1 weight 10 \ nexthop dev pppoe-wan2 weight 3权重 10:3 是按上行能力估出来的粗比例，实际值建议在你的真实流量下跑一轮再定。这里有个关键点：等价多路径的分摊是按连接做的，不是按包。同一条TCP连接的所有包始终走同一个下一跳，这正好是我们要的会话保持。如果你发现某些设备上分摊行为异常，优先去确认这一点，别去改权重瞎试。
规则优先级（priority 数值越小越先匹配）也要注意。默认路由的规则优先级一般靠后，把固定分流的规则放在前面，否则后面的规则永远不命中。这个错误我见过太多次，表现是“配了分流但完全没生效”，配置看上去一条不差。
3.4 健康检查与自动切换的具体做法
探测脚本的思路很朴素：定时对每条线路做连通性验证，失败累计到阈值就把该线路从路由里摘掉，恢复后延迟一段时间再摘回来。
#!/bin/sh # 简化示例：每3秒探测一次，连续3次失败判定掉线 FAIL1=0; FAIL2=0 while true; do if ping -c 1 -W 2 -I pppoe-wan1 223.5.5.5 >/dev/null 2>&1; then FAIL1=0 STATE1=up else FAIL1=$((FAIL1+1)) [ $FAIL1 -ge 3 ] && STATE1=down fi # 线路二同理 sleep 3 done判定为 down 之后要做的动作是：把该线路的路由权重置零或直接删除默认路由项，让流量全走剩下那条。这里我的经验是不要物理断开接口，只调整路由。接口断开会连带清掉连接跟踪，正在传输的连接全部失效；只改路由的话，已建立的连接至少还有机会走完（虽然回程可能因为出口地址变化而失败，但比全断好）。
恢复时加一个冷静期：
# 连续2次探测成功后才回切，且回切后30秒内不再判定 if [ "$STATE1" = "up" ] && [ "$PREV1" = "down" ]; then sleep 30 恢复路由权重 fi注意：健康检查脚本别写得太激进。我最早用的是一秒一次探测，结果日志里全是抖动记录，反而干扰了真实故障的判断。三秒间隔对绝大多数场景足够，除非你对切换时延有硬指标要求。
3.5 上线前的验证清单，一定要跑满
配置完不验证，等于没配。我固定跑这五项：
第一项，确认两条会话都在。查拨号接口状态和拿到的地址，两条都要有独立公网地址且不在同一网段。
第二项，确认单线路能出网。分别指定源接口去探测，两条都要通。
第三项，确认分流规则真的命中。从财务网段发起连接，在出口设备上抓包或看连接跟踪，确认走的是指定的那条线，而不是“看起来像走了”。
第四项，确认叠加有效果。用多线程下载工具同时开八到十六个连接，观察两条线路的流量是否都有明显占用。单线程测速只跑一条线是正常现象，不是故障。
第五项，做一次真断线演练。拔掉一条线的网线，观察业务是否中断、切换用了多久、恢复后是否自动切回。这项最值得做，因为所有切换逻辑的真实行为只有演练才能暴露。
4. 常见问题与排查实录
4.1 拨号失败：先看日志卡在哪一阶段
拨号失败别急着换线换设备，先看日志，它会告诉你在哪一步停的。
认证阶段失败，最常见的原因是账号密码不对、账号被绑定在别的设备上、或者同一账号并发会话数超限。这里要提醒一句：单账号能否并发认证，取决于运营商侧的会话策略，动手前最好跟运营商确认清楚，别自己试到一半发现被限速或者被临时封停，浪费时间还影响正常使用。
链路协商阶段失败，多半是物理层或VLAN的问题。检查网线、光猫端口、VLAN标签是否正确。有些光猫的某个LAN口是专门给IPTV用的，插上去怎么拨都不通，这个坑很经典。
超时无响应，则要确认光猫是不是桥接模式。光猫自己拨了号，路由设备再拨就必然失败——两边抢同一个会话。判断方法很直接：光猫管理页里看WAN连接状态，如果已经在线，就先去改成桥接。
4.2 拨上去了但速度没叠加，八成是这四种原因
单线程任务本来就只能走一条线。浏览器单文件下载、部分视频播放、某些网盘客户端都是单连接，速度上限就是单线带宽。测叠加必须用多连接工具。
权重配得不对。一条线权重给太高，另一条几乎吃不到流量。或者两条线带宽差太多，窄的那条被压满后成为整体瓶颈。
上行先打满。下行没跑满但上传已经顶格，整体速度就上不去。这种情况看接口的发送方向流量比看接收方向更有用。
连接跟踪表或端口池不够。高并发下新连接建立失败，表现是速度忽高忽低。调大表容量和端口范围能改善。
4.3 网页偶发打不开、登录态莫名丢失
这是双出口最典型的“隐性故障”，症状是间歇性、难复现。原因基本锁定在会话路径不一致或者公网地址漂移。
处理思路分两步。第一步，把对地址敏感的业务全部固定出口，包括但不限于：财务系统、收银终端、远程管理入口、需要长期保持登录态的网页应用。第二步，检查连接跟踪的标记逻辑是否覆盖了所有协议。特别是走UDP的业务，很多负载均衡实现对UDP的哈希处理和TCP不一样，容易出问题。
还有一类表现容易被误判：视频会议中途掉线重连。如果会议客户端走的是UDP且没有做会话保持，出口切换时必然会掉。解决办法同样是固定出口，别指望客户端自己重连得足够快。
4.4 常见问题速查表
| 现象 | 大概率原因 | 排查动作 |
|---|---|---|
| 拨号一直在“连接中” | 光猫未桥接、VLAN不对、物理口错误 | 查光猫WAN状态、核对VLAN、换口复测 |
| 认证被拒 | 账号密码错、MAC绑定、并发会话超限 | 单线单独测试、核对账号策略 |
| 小包通、大包不通 | MTU/MSS不匹配 | 下调MSS至1400、逐跳排查封装开销 |
| 测速看不出叠加 | 单线程任务、权重失衡 | 换多连接工具、按上行重算权重 |
| 网页偶发失败 | 会话路径不一致、地址漂移 | 敏感业务固定出口、检查连接标记 |
| 切换后长时间不恢复 | 缺少回切逻辑或冷静期设置不当 | 补健康检查回切、加30秒冷静期 |
| 高峰期限速感明显 | 上行瓶颈、端口池耗尽 | 看发送方向流量、调大端口范围 |
| 语音/会议频繁断 | UDP未做会话保持 | 该业务固定单出口 |
5. 我在实际项目里总结的几条硬经验
5.1 分流规则宁少勿多，顺序比数量重要
刚开始玩双出口的人容易上头，恨不得给每个应用都写一条规则。规则一多，排查成本指数上升，而且规则之间互相覆盖的情况极难发现。我现在的习惯是：只写三条硬规则——敏感业务固定线一、大上传业务固定线二、其余全走多路径分摊。就这三条，能覆盖九成场景。
顺序上，越具体的规则越靠前。源地址段精确到小网段的规则，一定放在大网段规则之前。写完一定要验证命中情况，别凭感觉。验证方法很简单：从目标网段发起一次连接，在设备上看连接跟踪记录里这条连接绑的是哪个出口，一目了然。
5.2 监控比配置更值得投入时间
配置是一次性的，故障是持续的。我现在给每个双出口项目都配三样监控：每条线路的实时流量、每条线路的探测成功率、当前生效的出口状态。三样都挂上告警，阈值别设太敏感，探测成功率连续五分钟低于九成才告警。
这么做的好处是，故障发生时你不是从“用户说网卡了”开始查，而是直接看到“线二探测成功率掉到六成”，五分钟定位。省下来的时间远超配置监控的成本。日志留存也建议至少留一周，间歇性故障全靠翻历史记录。
5.3 别在高峰期做变更，也别一次改多个变量
这条是纯粹的血泪教训。双出口的配置项之间耦合很紧，MTU、MSS、权重、探测参数、规则顺序，改一个可能连带影响另一个。一次改三个变量，出问题你根本不知道是哪个引起的。我现在的规矩是：一次只改一个参数，改完观察至少半小时再动下一个。
变更时间也尽量避开业务高峰。道理不用多说，但真到了赶进度的时候特别容易忘，然后就是一边回滚一边接电话。
5.4 留一条“后门”访问路径
双出口设备一旦策略配错，可能内网彻底出不去，而你又只能远程连过去改，就形成了死锁。我的做法是始终保留一个不经过策略路由的管理入口：可以是一个独立的管理网段直接挂在设备某个口上，也可以是设备本地保留一个控制台访问方式。这条路径不参与任何分流规则，永远可达。
代价是多了几行配置，收益是省掉一次跑现场。这个投入产出比，怎么算都划算。
最后分享一个实操中的小习惯：每次改完配置，我都把当前的完整配置和路由表导出一份带日期的备份，放在设备之外的地方。双出口这种配置，半年后你自己都记不清当时为什么把权重设成10:3。有备份，回滚和对照都只是几分钟的事，没有备份，就只能从头再来一遍。
