首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
JerryYuan
V2EX  ›  宽带症候群

求帮忙分析一个 Wireguard 组网网速慢的问题

  •   
  •   JerryYuan · 2025 年 5 月 24 日 · 3386 次点击
    这是一个创建于 252 天前的主题，其中的信息可能已经有所发展或是发生改变。

    请教组网大佬一个疑难杂症.

    背景

    我在城市 A 工作,购买了一台 NAS,上边下载了一些影视剧.为了让在城市 B 的父母也能看这些资源,选择用 Wireguard 进行组网,同时我还有个部署在腾讯云上的博客,利用这台机器的公网 IP 作为救援狗洞,将这台机器也纳入了整个 Wireguard 组网中.拓扑图如下: 基础拓扑 建立了如图中所示的 5 条 Wireguard 隧道:

    1. 网关 A-网关 B 互联:走 IPv6 直连,主要用于父母访问我这边的 NAS
    2. 网关 A-本人手机互联:走 IPv6 直连,主要用于本人在外回城访问 NAS 上的 Grafana 监控等
    3. 网关 A-腾讯云 CVM 互联:走 IPv4 直连,主要用于本人在城市 A 的家里访问博客后台(不对公网开放 22 等端口)
    4. 腾讯云 CVM-本人手机互联:走 IPv4 直连,主要用于本人在外访问博客后台
    5. 网关 B 互联-腾讯云 CVM 互联:走 IPv4 直连,主要用于隧道 1 不可用时,对网关 B 进行紧急救援,一般只有一些心跳流量

    网关 A,网关 B,腾讯云 CVM 拥有三个不同的内网网段,已经实现拓扑图中任意两点之间的互访(路由表等)

    问题发现

    大概从 2~3 天前开始,我发现我从手机 A 走隧道②过网关 A 访问家里的 NAS 下行速率(NAS→手机)只剩 0.1Mbps 了,但上行速度还算正常(手机→NAS),还能有 10Mbps.平时这条链路只有我查看 Grafana 监控的流量,一般我也不怎么看 NAS 上的视频,因此不存在非常大的流量.

    问题检查过程

    1. 初步定性

    因为用的都是移动网络,对移动关于大流量封禁和 UDP QoS 有所耳闻,初步分析认为是因为隧道①中父母看视频产生了过多的流量(但实际上也就每周末有稍微集中一些的上传),导致自己遭遇了相同的限速问题,于是第一时间尝试验证各个链路的可用性.

    2.验证隧道①速度

    在网关 A 上部署 iperf3 服务器,网关 B 直接测试速率,得到以下结果:

    root@OpenWrt:~# iperf3 -c <网关 A 地址>
Connecting to host <网关 A 地址>, port 5201
[  5] local <网关 B 地址> port 44024 connected to <网关 A 地址> port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.50 MBytes  2.10 Mbits/sec    0             sender
[  5]   0.00-10.03  sec  2.38 MBytes  1.99 Mbits/sec                  receiver

iperf Done.
root@OpenWrt:~# iperf3 -c <网关 A 地址> -R
Connecting to host <网关 A 地址>, port 5201
Reverse mode, remote host <网关 A 地址> is sending
[  5] local <网关 B 地址> port 51104 connected to <网关 A 地址> port 5201
[ ID] Interval           Transfer     Bitrate
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.03  sec  49.9 MBytes  41.7 Mbits/sec  1182             sender
[  5]   0.00-10.00  sec  47.2 MBytes  39.6 Mbits/sec                  receiver

iperf Done.

    结论: 城市 B 网关->城市 A 网关 上行 2Mbps 左右 下行 40Mbps 左右(符合城市 B/城市 A 上行带宽).也就是说,实际上城市 A 网关的上行并没有被限制。

    3.验证隧道③速率

    验证完 1 的链路后,还是不放心,又验证了隧道③的速率:

    root@CVM:~# iperf3 -c <网关 A 地址>
Connecting to host <网关 A 地址>, port 5201
[  5] local <CVM 地址> port 37276 connected to <网关 A 地址> port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
...    
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  21.7 MBytes  18.2 Mbits/sec  670             sender
[  5]   0.00-10.00  sec  21.1 MBytes  17.7 Mbits/sec                  receiver

iperf Done.
root@CVM:~# iperf3 -c <网关 A 地址> -R
Connecting to host <网关 A 地址>, port 5201
Reverse mode, remote host <网关 A 地址> is sending
[  5] local <CVM 地址> port 37304 connected to <网关 A 地址> port 5201
[ ID] Interval           Transfer     Bitrate
...              
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  57.8 MBytes  48.4 Mbits/sec  1934             sender
[  5]   0.00-10.00  sec  55.3 MBytes  46.4 Mbits/sec                  receiver

iperf Done.

    结论: 腾讯云 CVM->城市 A 网关 上行 20Mbps 左右 下行 40Mbps,也是符合我云服务器和城市 A 的上行带宽.到这里基本可以确定城市 A 网关应该是没有什么限速的问题存在.

    4.验证隧道②的速率

    本人的手机 A 是一台 Android 手机,安装了 Termux,可以执行一些 Linux 命令,遂尝试开 Wireguard 的情况下使用 iperf3 对的网关 A 进行测速.

    ~ $ iperf3 -c <网关 A 地址>
Connecting to host <网关 A 地址>, port 5201
[  5] local <手机内网地址> port 39652 connected to <网关 A 地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  4.00 MBytes  3.36 Mbits/sec    2            sender
[  5]   0.00-10.60  sec  2.62 MBytes  2.08 Mbits/sec                  receiver

iperf Done.
~ $ iperf3 -c <网关 A 地址> -R
Connecting to host <网关 A 地址>, port 5201
Reverse mode, remote host <网关 A 地址> is sending
[  5] local <手机内网地址> port 39726 connected to <网关 A 地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec  0.00 Bytes  0.00 bits/sec   70            sender
[  5]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  receiver

iperf Done.

    结论: 这里手机->城市 A 网关的速度已经不正常了,上行还能有 2Mbps,下行就风狂重试几乎测不出速度了.至此怀疑是手机流量的问题,计划再测试一下手机->CVM 云服务器的速度.

    5.验证隧道④的速率

    在腾讯云 CVM 上开 iperf 服务器,使用手机连接,测试得到如下结果:

    v~ $ iperf3 -c <CVM 内网地址>
Connecting to host <CVM 内网地址>, port 5201
[  5] local <手机内网地址> port 41036 connected to <CVM 内网地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  5.50 MBytes  4.61 Mbits/sec    0            sender
[  5]   0.00-21.37  sec  1.84 MBytes   724 Kbits/sec                  receiver

iperf Done.
~ $ iperf3 -c <CVM 内网地址> -R
Connecting to host <CVM 内网地址>, port 5201
Reverse mode, remote host <CVM 内网地址> is sending
[  5] local <手机内网地址> port 41156 connected to <CVM 内网地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.07  sec  69.6 KBytes  56.6 Kbits/sec   72            sender
[  5]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  receiver

iperf Done.

    结论: 手机->CVM 云服务器速率也是不正常的,上行只有 4Mbps 不到,时常丢包丢到不到 1Mbps.目前基本怀疑是流量网络的问题.

    6.确认蜂窝网络流量的问题

    测试到这里基本觉得就是移动蜂窝网络搞了什么新策略,把我 wireguard 的 UDP 包给 QOS 了.但是还不死心,又尝试了下面这个拓扑: 笔记本走流量组网 这里我将手机上的配置文件传到笔记本上,然后笔记本走 USB 共享手机的网络,建立隧道②和隧道④,然后重新用 iperf3 测试了以下隧道的速率,于是这里就出现了很神奇的事情:

    
C:\Downloads\iperf-3.19-win64>iperf3 -c <网关 A 地址>
Connecting to host <网关 A 地址>, port 5201
[  5] local <手机内网地址> port 6224 connected to <网关 A 地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec  1.50 MBytes  1.26 Mbits/sec                  sender
[  5]   0.00-10.33  sec  1.38 MBytes  1.12 Mbits/sec                  receiver

iperf Done.

C:\Downloads\iperf-3.19-win64>iperf3 -c <网关 A 地址> -R
Connecting to host <网关 A 地址>, port 5201
Reverse mode, remote host <网关 A 地址> is sending
[  5] local <手机内网地址> port 6231 connected to <网关 A 地址> port 5201
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.03  sec  23.6 MBytes  19.8 Mbits/sec   50            sender
[  5]   0.00-10.01  sec  23.1 MBytes  19.4 Mbits/sec                  receiver

iperf Done.

    这里其实已经发现了奇怪的问题,测速竟然又是好的了,虽然没有跑满网关 A 的上行,但基本也够我回城看个 Grafana 监控了.

    问题

    经过这些测试,彻底想不通为啥手机上 Wireguard APP 下只有 0.1Mbps 的下行了,既然用分享的热点电脑能正常速率通信,那么手机的流量应该是没问题的.

    Wireguard 的 APP 我也试了几个老版本的,发现问题并不能得到缓解,仍然速率非常的慢.另外我还试了下 iperf 直接对网关进行测试,发现不论是 TCP 还是 UDP,通信速率都是正常的.

    我还试了一下在腾讯云买了一台带 IPv6,和已有服务器不同 VPC 的主机,试了一下 IPv6 直连网关 A 的速度,也是正常的.

    写了也比较多了,希望能有大佬可以帮忙分析下问题所在.

    第 1 条附言  ·  2025 年 5 月 25 日
    最新结论: 是 MTU 的问题，隧道双方 Peer 都改成 1200 就可以恢复速率了
  • wireguard
  • 网络速率慢
  • 移动网络
    19 条回复  •  2025-05-26 14:17:22 +08:00
    NealLason
        1
    NealLason  
       2025 年 5 月 24 日
    先 降低 MTU 到 512 字节试试
    JerryYuan
        2
    JerryYuan  
    OP
       2025 年 5 月 24 日
    @NealLason 感谢回复，这边试了一下把 Wireguard 的 MTU 降低到 512 ，似乎没有什么变化：
    ![测速]( )
    Ipsum
        3
    Ipsum  
       2025 年 5 月 24 日
    跨网限速，电信甚至通网都限速。试试 ovpn 的 tcp 模式。
    NealLason
        4
    NealLason  
       2025 年 5 月 24 日
    @JerryYuan 好吧，那和我的现象不一样。我是把互相通信的两个 peer 的 MTU 都配置成 512 ，吞吐就恢复正常了，1460 反而 QoS 严重。
    JerryYuan
        5
    JerryYuan  
    OP
       2025 年 5 月 24 日 via Android
    @Ipsum 我跨网的那条链路测下来问题不大，只是我手机流量这条链路有问题，手机和网关 A 都是移动网，按理说不存在跨地区或者跨网的说。

    我又补充测试了一个，挂上 wstunnel 转成 TCP 去回城网速确实能恢复，这样看确实是移动加强蜂窝网络的 UDP QoS 了？

    另外我笔记本走热点回城速度却又不受影响应该怎么解释呢😂
    JerryYuan
        6
    JerryYuan  
    OP
       2025 年 5 月 24 日 via Android
    @NealLason 诶？我只改了手机一侧，一会试下网关的 MTU 也改 512 试下
    yinmin
        7
    yinmin  
       2025 年 5 月 24 日 via iPhone
    网关 A 的 wireguard 的 mtu 改成 1200 ，手机的 wireguard 的 mtu 也改成 1200 ，然后再试试，wireguard 奇奇怪怪的问题很多都是 mtu 的原因。
    JerryYuan
        8
    JerryYuan  
    OP
       2025 年 5 月 24 日
    @yinmin @NealLason 感谢大佬们的回复,试了一下网关 A 的 MTU 改成 1200,速度就恢复了,这样看确实是 MTU 的问题.所以原理就是 wg 的 UDP 包太大,导致被移动给丢了?然后笔记本走热点恰巧 MTU 选了一个小的值,速度就正常?

    稍后我再试下如果给笔记本指定 1400,看看能不能复现问题.
    RinGress
        9
    RinGress  
       2025 年 5 月 24 日 via Android
    第一直觉是跨网限速。不过确实碰到过好几回 mobile 网络接入的时候 MTU 设成 1400 左右连不上，1200 可以的问题
    Naples
        10
    Naples  
       2025 年 5 月 24 日 via Android
    Wireguard MTU: over ipv4, 1432; over ipv6, 1412.
    xqzr
        11
    xqzr  
       2025 年 5 月 25 日
    @NealLason > 1460 反而 QoS 严重

    IPv4 Endpoint 最多就 1440 ； IPv6 Endpoint 1420 （物理网卡 1500 情况下）

    腾讯云的网络，需要减小 36 。所以，IPv4 Endpoint 1404
    AlphaTauriHonda
        12
    AlphaTauriHonda  
       2025 年 5 月 25 日 via iPhone
    AmneziaWG ，实在不行只能 TCP 。
    JerryYuan
        13
    JerryYuan  
    OP
       2025 年 5 月 25 日 via Android
    @linzyjx 我这比较尴尬，跨网跨省的反而没事，市内通信先挂了😂另外我用最后热点的方案试了下 1400 的，似乎没有复现手机的问题

    @Naples 我这比较尴尬，peer 之间既有 ipv4 的也有 ipv6 的，感觉只能取小值设定一个了

    @AlphaTauriHonda 我有 TCP 的备用方案了，用 wstunnel 套一下也能恢复，先用 UDP 的吧，毕竟省事，等实在不行了再考虑换协议吧
    pxlxh
        14
    pxlxh  
       2025 年 5 月 25 日
    搞这么复杂 一个环节挂了全挂
    网盘解千愁

    要达到网盘同样稳定性 需要投入五十倍以上
    JerryYuan
        15
    JerryYuan  
    OP
       2025 年 5 月 25 日 via Android
    @pxlxh 目的不同罢了，网盘享受的是结果，NAS 享受的是折腾的过程以及解决技术问题时多巴胺的冲击。

    btw ，不喜欢国产软件那个忽悠你用起来，等你离不开了再收割的尿性，利用这套东西，已经基本实现去国产化+90%以上开源方案了

    另外从长远(数年)来看，相同体验下 NAS 和网盘投入的资金是差不多的
    JensenQian
        16
    JensenQian  
       2025 年 5 月 25 日
    wireguad 基于 udp
    udp 喜欢 qos 运营商
    跨网+udp ，这雪上加霜

    建议还是用基于 tcp 的协议
    allenby
        17
    allenby  
       2025 年 5 月 26 日
    有一个 ws 实现的
    swananan
        18
    swananan  
       2025 年 5 月 26 日
    这个其实是 ip fragment 导致的，本质上要传输层自己搞个 mtu 探测就好了，但是一刀切 1200 似乎是个省事的办法
    JerryYuan
        19
    JerryYuan  
    OP
       2025 年 5 月 26 日 via Android
    @JensenQian 有所耳闻，不过目前看还能用还够用就先用吧，等哪天真的不行了再换吧，搭这一套也花了不少时间

    @swananan 那理论上应该是 MTU 加上包头长度在 IP 报允许的最大 payload 长度附近了，导致产生一大堆小包？我还试了 MTU 拉到离谱大，似乎也不会出现限速问题，大概是因为强制分包导致包长度能回到合理范围？
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2001 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 11:11 · PVG 19:11 · LAX 03:11 · JFK 06:11
    ♥ Do have faith in what you're doing.