faq_2026-09-26_net_2
title: “家宽加专线两条线聚合后反而丢包，微信消息延迟几十秒怎么回事” description: “一百五十人的公司，500M 家用宽带嫌会话数不够网速慢，又加了 50M 固定 IP 专线做双线聚合，结果经过企业级交换机转发反而丢包、微信文字消息延迟 15 到 30 秒；拔掉专线单用宽带不丢包但又回到会话数不够的老问题。” date: 2026-09-26 slug: home-broadband-dedicated-line-aggregation-packet-loss categories: [“常见问答”] draft: false
公司一百五十人左右，原来单用 500M 普通家用宽带，高峰期会话数不够、网速慢；后来加了条 50M 固定 IP 专线，在多 WAN 路由器上做双线聚合。麻烦来了：聚合之后内网经过交换机转发开始丢包，微信文字消息要延迟十五到三十秒才到；把专线拔掉单用宽带，丢包消失，可会话数不够的老毛病又回来。两条线各有各的问题，合在一起反而更糟。
原因分析
先纠正一个常见归因：这不是带宽不够。单用 500M 家宽时不丢包，说明带宽本身够用；问题出在多 WAN 聚合的分担方式上。第一，家宽和专线的时延、抖动差别不小，如果负载均衡按「逐包」分担，同一个会话的包被拆到两条线路上，先发的包走慢线、后发的包走快线，到对端乱序，微信这类长连接对乱序和丢包很敏感，表现就是消息卡几十秒。第二，两条线带宽是 500M 对 50M，差十倍，如果分担策略按连接数均分而不是按带宽加权，等于把一半会话压进 50M 专线，专线先拥塞丢包。第三，会话数不够的根源是路由器 NAT 并发会话表被顶满，终端上的更新、云同步、视频都在抢会话，这个病聚合多少条线都治不了，得单独治理。三个原因叠在一起，才出现「聚合反而更糟」的反直觉现象。
分步解决
- 两条线各自单跑测基线。分别只接一条线，记录各自的下载、时延和丢包（连续 ping 外网网关和公网 DNS 各几百个包）。单线都正常，才能把问题锁定在聚合逻辑上。
- 分担方式从逐包改成按会话。进多 WAN 路由器的负载均衡设置，把逐包分担改为按会话（流）分担，保证同一个连接的包始终走同一条线，乱序问题立刻消大半。
- 按带宽加权，别均分。两条线 500M 对 50M，就按约 10:1 的比例分配新会话，让专线只承载少量对公网 IP 和时延敏感的业务，避免被压爆。
- 关键应用走策略路由固定线路。微信、视频会议、需要固定 IP 对接的业务，用策略路由指定走专线；普通上网走家宽。这比纯负载均衡更符合两条线各自的特性。
- 治理会话数。在路由器上查 NAT 并发会话数和会话来源排行，对个别跑满会话的终端限速或限制 P2P 类应用，把系统更新、网盘同步错峰。会话表有余量，高峰期卡顿才会真正缓解。
- 改完用数据验证。高峰时段再连续 ping 公网目标并统计丢包率，同时盯着微信收发时间。丢包率降到接近单线水平、消息秒到，才算收工。
预防
混合线路聚合上线前，先把每条线的带宽、时延基线测出来再定分担策略；接入后把「会话数使用率」加进日常巡检项，高峰期经常顶到八成以上就要提前扩容或治理，而不是等到全员卡了再查。