OpenWrt 下 Tailscale 性能调优全记录：网卡中断、内核参数与传输协议的选择

摘要： 本文记录了解决异地组网（Tailscale）访问 NAS 速度缓慢问题的完整过程。通过分析发现，瓶颈并非单一因素，而是由 SMB 协议在高延迟下的低效、运营商对 UDP 大包的 QoS 限制以及软路由 CPU 单核软中断瓶颈共同导致。文章详细介绍了如何通过更换传输协议（WebDAV/FTP）、伪装 UDP 443 端口绕过 QoS、开启 Linux BBR 拥塞控制、以及优化网卡 Ring Buffer 和 RPS 软负载均衡，最终将传输速度从 86Mbps 提升至跑满带宽的 399Mbps。

原因-openwrt性能不行

tailscale涉及到加密解密，若是将tailscale安装在软路由上，性能将会很不佳，3~10MB就是上限了，应该将 tailscale 安装在x86的电脑上。

原因-SMB 协议的物理定律 (带宽延迟积)

如果是直接在 Windows 资源管理器里“复制/粘贴”文件，那么这就是原因。

原理： SMB（Windows 共享协议）是一个串行确认协议。
- 它发一个数据块（Block），就必须停下来等 NAS 回复一句“收到了”，才能发下一个。
  - 延迟是 45ms。这意味着每秒钟只能进行约 22 次（1000ms / 45ms）有效的“发送-确认”握手。
现象：
- 为什么慢？ TCP 窗口无法被填满。单线程 SMB 在 40ms+ 延迟下的物理极限速度通常就是在 5MB/s ~ 15MB/s 左右。
  - 为什么波动？ 因为 TCP 协议在尝试通过“慢启动”增加发送窗口，一旦遇到丢包（公网 UDP 传输常见的抖动），窗口大小瞬间减半，速度就会从 11MB/s 掉到 2MB/s，然后重新慢慢爬升。这就是看到的“锯齿状”波动。

验证方法：

请不要用“拷贝文件”来测速，那测的是 SMB 的效率，不是网络的带宽。请用 iPerf3打流测试(后文有写)：

需要可以更换专业的软件 Rclone Browser 、FileZilla、AirExplorer 才能更好的传输, 最好用ftp+AirExplorer, 然后在一个文件夹中创建8个1G以上的压缩文件, 传输这个文件夹, 测试最大速度.

还可以在ubuntu中打流测试会更准.

使用专业的传输工具（强烈推荐 - 跑满速） 请下载 FileZilla (免费开源)。

主机： sftp://192.168.50.201 (使用 SSH 协议，最稳) 或 WebDAV 地址。
用户名/密码： NAS 的账号密码。
关键设置： 它可以同时传输多个文件，或者把一个大文件分成多块同时传。
- 这能用并发连接数（Concurrency）来抵消 45ms 的延迟。
- 效果： 速度应该能稳定在 30MB/s - 40MB/s (取决于 350Mbps 下行带宽极限)。

预测结果： 单线程可能只有 20-50Mbps (几MB/s)，但多线程（-P 8）很可能会跑满上行带宽（200Mbps+）。如果是这样，说明网络没问题，是 SMB 协议拉胯。

Windows 资源管理器的“单线程”机制
- 当在“我的电脑”里复制文件到 Z 盘（RaiDrive 挂载盘）时，Windows 是按顺序一个块一个块传输的。
- 它发一个块，必须等 NAS 回复“写入成功”，再发下一个。
- 45ms 的延迟 意味着每秒钟只能交互 20 次左右。这直接物理锁死了单线程传输上限（通常就在 10MB/s 左右）。
RaiDrive 的缓存与上传机制
- RaiDrive 会先在本地缓存文件，然后尝试上传。
- 波动原因： Windows 资源管理器试图推数据 -> RaiDrive 缓冲区满 -> 暂停等待网络上传 -> 网络上传受限于延迟 -> 缓冲区空了 -> 继续推数据。这种“推-停-推-停”的过程，体现在进度条上就是速度忽高忽低（锯齿状）。
WebDAV 协议的开销
- WebDAV 基于 HTTP，本身协议头就比较重。加上 Tailscale 的加密头，有效载荷进一步降低。

解决方案建议

如果 iPerf3 多线程 能跑出高分（比如 200Mbps+），那么网络架构是完美的。要解决传文件慢的问题，需要换“交通工具”：

换协议（最推荐）：
- WebDAV: 之前用 RaiDrive 挂载的就是 WebDAV。WebDAV 对延迟的容忍度比 SMB 好很多。
- FTP / SFTP: 传输大文件时，FTP 是效率之王。
多线程复制（如果必须用 SMB）：
- 不要用 Windows 自带的复制粘贴。
- 使用 FastCopy 或 Robocopy 等工具。
- 开启 多线程/缓冲 选项。这能同时建立多个连接，把 45ms 的延迟因为并发而抵消掉，轻松跑满带宽。

原因-运营商对 UDP 大包的 QoS (限速/丢包)

Tailscale 底层走的是 UDP 协议。

现状： 国内运营商（特别是跨运营商，或者高峰期）对 大流量的 UDP 数据包 非常敏感。他们会认为这是 P2P 下载或者攻击流量，从而进行 QoS 丢包。
后果：
- WireGuard 协议一旦发生丢包，就需要重传。
  - 在 TCP（SMB）之上再跑一个丢包的 UDP（Tailscale），会发生“TCP 拥塞控制崩溃”，导致速度剧烈波动。
  - 2~11MB/s 的波动 非常符合“丢包-重传-降速-恢复”的特征。

(一般)尝试优化 MTU（对抗波动）-Tailscale所在Linux

虽然很难对抗运营商，但可以尝试修改 Tailscale 的 MTU（最大传输单元），减小包的大小，降低被运营商丢弃的概率。

在笔记本和 Ubuntu Server 上： 尝试将 Tailscale 接口的 MTU 从默认的 1280 改为 1200 甚至更小，看看波动是否减小。

如果 iPerf3 测试结果也不稳定，说明运营商在丢 UDP 包。请尝试在 笔记本电脑 的管理员 CMD 中修改Linux Tailscale 虚拟网卡的 MTU：

# 查看当前 MTU
ip addr show tailscale0

# 修改 MTU 为 1200 (默认是 1280)
sudo ip link set dev tailscale0 mtu 1200

改小 MTU 可以让数据包更“小巧”，更容易穿过运营商拥堵的管道，减少丢包重传带来的速度骤降。

实测MTU1200会有一点提升, 但区别不大, 当前网络环境不需要修改.

(极佳)Linux开启 BBR 拥塞控制算法

Linux（Tailscale在的系统），BBR 是 Google 开发的拥塞控制算法，特别擅长在高丢包、高延迟的网络环境下“抢带宽”。

在 Ubuntu Server 上检查并开启 BBR：

检查当前算法：
```
sysctl net.ipv4.tcp_congestion_control
```
(如果是 cubic 或 reno，那就必须得换)

开启 BBR：

echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

验证是否开启：
```
lsmod | grep bbr
```
(如果看到 tcp_bbr，说明开启成功)

开启 BBR 后再测一次 iperf3。对于这种跨运营商的高丢包线路，BBR 往往有奇效，能把被 QoS 丢掉的速度抢回来。

(较好)Windows设置开启“接收窗口自动调节”

更简单的，开启“接收窗口自动调节”：
管理员权限运行cmd

netsh interface tcp set global autotuninglevel=normal

(极佳)更换 Tailscale 端口 (绕过运营商 QoS)

注意: Windows客户端不好修改, 推荐用虚拟机中UbuntuServer安装Tailscale当子网路由

运营商通常对 41641 这个默认端口盯得很紧。我们把它改成 UDP 443（伪装成 QUIC 流量）或者随机端口。

在 Ubuntu Server（Linux）上，修改 Tailscale 监听端口的正确方法是修改系统配置文件

在终端中输入以下命令打开配置文件：

sudo vim /etc/default/tailscaled

修改或添加端口变量

将PORT="41641"修改为PORT="0"设置为 0 (或443)后，Tailscale 每次启动都会随机选择一个高位端口。这能有效防止运营商针对固定端口（41641）的长期 QoS 限速。

重启 Tailscale 服务

修改配置后，必须重启服务才能生效：

sudo systemctl restart tailscaled

验证端口是否改变

重启后，可以检查一下当前 Tailscale 到底监听在哪个端口：

sudo netstat -ulpn | grep tailscaled

随机端口后会好很多, 如果隔一段时间又不佳了, 设置为443看看, 一般都会好很多!

屏蔽的是“入站 TCP 443” (建站行为)
- 运营商为了防止家庭用户搭建非法网站，确实会封锁家庭宽带公网 IP 的 TCP 80 和 TCP 443 端口。
- 这意味着：外网无法通过 https://的IP 访问家里的 Web 服务器。
放行的是“UDP 443” (HTTP/3 QUIC 协议)
- Tailscale 使用的是 UDP 协议。
- 现代互联网（Google, YouTube, Bilibili, 抖音等）正在全面普及 HTTP/3 (QUIC) 协议，而 QUIC 协议的标准端口正是 UDP 443。
- 运营商不封锁 UDP 443： 如果运营商封了 UDP 443，会导致大量主流 APP 卡顿、网页打不开。

为什么改成 443 后速度起飞了？

这就涉及到运营商的 QoS (流量整形) 策略了：

随机高位端口 (之前)： 运营商看着一个不知名的 UDP 端口跑了 300M 流量，判定为：“疑似 P2P 下载/BT 流量/垃圾流量”，策略：“低优先级，网络拥堵时优先丢包”。
UDP 443 端口 (现在)： 运营商看着 UDP 443 跑了 300M 流量，判定为：“疑似 QUIC 网页浏览/流媒体视频”，策略：“高优先级，这是用户在看视频，尽量别卡”。

真相：成功地将 Tailscale 流量“伪装”成了正常的网页浏览流量，骗过了运营商的 QoS 限制！

(可选)openwrt安装Turbo ACC

注意Turbo ACC的安装比较复杂, 需要重新编译, 建议用别的方式替代!

这个是针对R2S之类的性能较弱的软路由, 若是Openwrt运行在x86平台, 在x86PVE中运行openwrt, 4核心, 开启了irqbalance和软件流量卸载, PVE9安装R8125 2.5G网卡驱动、开启缓冲区、开启硬件多队列支持, 则不需要.

Turbo ACC (特别是其中的 SFE - Shortcut Fast Path Engine) 主要针对 MIPS/ARM 等低功耗 CPU 的路由器，这些路由器的 CPU 性能有限，需要软件加速来弥补。 x86 CPU (4核心) 性能远超普通路由器 CPU，处理数据包的能力强大得多。即使没有 SFE，也能以非常高的 PPS (每秒包数) 处理流量。

irqbalance： 它将网卡中断请求（IRQ）分发到不同的 CPU 核心，避免单个核心成为瓶颈，充分利用了多核心优势。这对于高 PPS 的流量至关重要。

软件流量卸载 (Software Flow Offloading)： 这是 OpenWrt 内核自带的流量加速机制，其作用和 Turbo ACC (SFE) 的核心功能高度重合。它通过在内核中建立快速路径，让已建立连接的流量绕过大部分复杂的防火墙和 NAT 查询，直接进行转发。这正是 Turbo ACC 试图实现的目标。

R8125 驱动和缓冲区： 确保了网卡驱动的稳定性和足够的队列缓冲区，可以更好地应对突发大流量，减少网卡层面的丢包。

硬件多队列 (Hardware Multiqueue)： 这是非常关键的优化！它允许网卡将入站数据包分发到多个 CPU 核心的独立队列中。结合 irqbalance，这意味着不同的 CPU 核心可以并行处理不同的数据流，极大地提高了 PPS 处理能力和总带宽。

找到 “网络” -> “Turbo ACC 网络加速” (或者在“系统”里)。
检查设置：
- 软件流量分流 (Software Flow Offloading): 必须勾选。
- 硬件流量分流 (Hardware Flow Offloading): 如果有，勾选。
- DNS 缓存: 可以开。
保存并应用。
- 原理：开启后，OpenWrt 转发数据包不再经过 CPU 复杂计算，而是直接走快速通道。这对 UDP 大流量传输至关重要。

提到没有安装 Turbo ACC。这在普通的上网场景下没问题，但在 高带宽 UDP 转发 场景下是致命的。

软中断风暴：
- Tailscale (WireGuard) 是基于 UDP 的。iPerf3 在 100Mbps+ 速度下会产生每秒数万个小包 (PPS)。
- 没有硬件加速（Offloading），每一个数据包都要 OpenWrt 的 CPU 亲自去“搬运”（从 WAN 到 LAN，再到 NAT 表查询）。
- CPU 的 softirq（软中断）会瞬间飙升。虽然 CPU 总占用率可能看着不高，但实际上网络栈已经堵塞了。
丢包机制：
- 当软中断处理不过来时，网卡缓冲区满了，新的数据包就会被直接丢弃。
- 这就是为什么看到了 2万次重传。

现状（无 Turbo ACC）： 每一个数据包进入路由器，Linux 内核都要走一遍完整的流程：网卡中断 -> 防火墙规则检查(iptables) -> 路由表查询 -> NAT转换 -> 转发。
- 瓶颈： 这个流程太长了！虽然 CPU 算得过来（占用率不高），但在处理流程上的延迟（Latency） 很高。
- 丢包原因： 当瞬间涌入 1000 个包，CPU 还在按部就班地走流程处理前 100 个，后面的 900 个没地方放，网卡缓冲区（Ring Buffer）溢出，直接丢弃。
Turbo ACC (SFE/Flow Offloading) 的作用： 它的原理是 “走捷径” (Shortcut)。
- 当第一个数据包走完流程后，Turbo ACC 记住这条路。
  - 后续的 999 个包，跳过防火墙检查、跳过路由查询，直接由驱动层修改 IP 头并转发。
  - 结果： 处理每个包的时间缩短了 10 倍。缓冲区清空得快，新包进得来，丢包自然就消失了。

(较好)openwrt安装irqbalance 硬件中断

openwrt之irqblance_openwrt irqbalance-CSDN博客
检查软件包里有没有 irqbalance，安装并启用它，自动分配中断。

1. 安装 irqbalance

opkg update
opkg install irqbalance

2. 编辑配置文件

vi /etc/config/irqbalance

配置文件内容示例：
option enabled '1' # 启用服务
别的暂时不需要修改!

config irqbalance
        option enabled '1'        # 启用服务
        option banirq '0'         # 禁止平衡的IRQ列表（留空或0表示无）
        option banmod 'iwlwifi'   # 禁止平衡的模块（如WiFi驱动）
        option args '--debug'     # 额外启动参数（可选）

3. 启动服务并设置开机自启

/etc/init.d/irqbalance start
/etc/init.d/irqbalance enable

4. 验证服务状态

# 检查进程
ps | grep irqbalance

# 查看服务状态
/etc/init.d/irqbalance status

# 检查中断平衡情况
cat /proc/interrupts

验证是否生效

启动后，可以通过 htop 命令（如果没有安装需 opkg install htop）观察 CPU 的负载情况。

生效前： 做 iperf3 测速时，可能只有一个 CPU 核心（例如 Core 0）占用率飙升到 100%，其他核心围观。
生效后： irqbalance 会尝试把网卡的硬中断（IRQ）分配给不同的核心。应该看到 软中断 (SIR / SoftIRQ) 负载被稍微摊平了一些。

(较好)openwrt安装RPS (软件负载均衡)

仅仅开启 irqbalance 可能不够。 irqbalance 处理的是硬件中断。对于网络包转发，特别是 OpenWrt 这种 Linux 系统，软件中断（SoftIRQ） 才是导致单核打死、大量丢包的元凶。

既然无法安装 Turbo ACC，强烈建议手动开启 Linux 内核自带的 RPS (Receive Packet Steering)。这是“ Turbo ACC平替”，纯软件实现多核分流。

请在 SSH 中执行以下命令（立即生效，重启失效）：

# 假设物理网口是 eth0, eth1, eth2... (根据实际情况调整)
#这个要去网络--接口查看, 例如我的就是WAN是eth1,lan是eth0

# 'f' 代表 16进制的 1111，即允许 4 个 CPU 核心参与处理。如果是双核就是 '3'。

# 开启 WAN 口 (eth0) 的多核软中断负载均衡
for file in /sys/class/net/eth0/queues/rx-*/rps_cpus; do echo f > $file; done

# 开启 LAN 口 (eth1) 的多核软中断负载均衡
for file in /sys/class/net/eth1/queues/rx-*/rps_cpus; do echo f > $file; done

操作完这两步（irqbalance + RPS）后，请再跑一次 iPerf3。 这时候， 4 核 CPU 应该会一起工作，虽然 CPU 总占用率可能会上升，但单核不再瓶颈，重传数（Retr）应该会显著下降，速度会更稳。

登录 iStoreOS 后台。
点击菜单栏的 “系统” (System) -> “启动项” (Startup)。
点击顶部的 “本地启动脚本” (Local Startup) 选项卡（在页面最右边）。
在编辑器中，找到 exit 0 这一行。
在 exit 0 之前，粘贴刚才用到的优化代码。

友善R2S

完整的推荐脚本如下（直接复制粘贴进去）：

下面是友善R2S的, 可以直接复制粘贴

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

# 1. 开启网卡 RPS 软负载均衡 (针对 NanoPi R2S 4核优化)
# eth0 (WAN)
if [ -d /sys/class/net/eth0/queues ]; then
    for file in /sys/class/net/eth0/queues/rx-*/rps_cpus; do echo f > $file; done
fi

# eth1 (LAN)
if [ -d /sys/class/net/eth1/queues ]; then
    for file in /sys/class/net/eth1/queues/rx-*/rps_cpus; do echo f > $file; done
fi

# 2. 优化网卡 Ring Buffer (防止突发丢包)
# 注意：eth0 支持双向调节，eth1 只支持 RX 调节且最大为 4096
if [ -x /usr/sbin/ethtool ]; then
    ethtool -G eth0 rx 1024 tx 1024
    ethtool -G eth1 rx 4096
fi

# 3. 优化内核队列 (配合 Ring Buffer)
sysctl -w net.core.netdev_max_backlog=16384
sysctl -w net.netfilter.nf_conntrack_max=65536


exit 0

点击底部的 “保存” (Save)。

开启软件流量卸载

x86虚拟机

关于 Ring Buffer (rx/tx) 的精确调整

虽然的脚本设置了 rx 4096 tx 4096，但PVE 虚拟机的网卡（例如 VirtIO）可能支持更大或更小的值，或者根本不能手动设置。

需要先在 OpenWrt 命令行中查看当前和最大值，然后进行调整。

查看当前网卡设置：

SSH 连接到OpenWrt。

分别查看 WAN (eth1) 和 LAN (eth0) 的 Ring Buffer 信息：

Bash

ethtool -g eth1 # 查看 WAN (eth1) 的 Ring Buffer
ethtool -g eth0 # 查看 LAN (eth0) 的 Ring Buffer

输出（示例）：

root@iStoreOS:~# ethtool -g eth1 # 查看 WAN (eth1) 的 Ring Buffer
Ring parameters for eth1:
Pre-set maximums:
RX:             1024
RX Mini:        0
RX Jumbo:       0
TX:             256
Current hardware settings:
RX:             1024
RX Mini:        0
RX Jumbo:       0
TX:             256

root@iStoreOS:~# ethtool -g eth0 # 查看 LAN (eth0) 的 Ring Buffer
Ring parameters for eth0:
Pre-set maximums:
RX:             1024
RX Mini:        0
RX Jumbo:       0
TX:             256
Current hardware settings:
RX:             1024
RX Mini:        0
RX Jumbo:       0
TX:             256

root@iStoreOS:~#

Pre-set maximums： 这是网卡驱动支持的最大值。
Current hardware settings： 这是当前正在使用的值。

根据查看结果修改 rc.local：

如果 Pre-set maximums 很高（如 4096 或 8192），那么可以尝试将 ethtool -G ethX rx YYYY tx ZZZZ 中的 YYYY 和 ZZZZ 设置为更大的值（例如 rx 4096 tx 4096），但不要超过 Pre-set maximums。
如果 ethtool -g 命令报错或者显示 Pre-set maximums 只有 256 或更小，说明虚拟网卡可能不支持手动调节到很高，或者有其他限制。在这种情况下，保持默认或者设置到一个合理值（如 256 或 512）即可。
对于 x86 虚拟机，rx 1024 tx 1024 通常是一个比较安全的起点，rx 4096 tx 4096 是一个比较激进但常见的高性能设置。

PVE 宿主机网卡设置

在 PVE 宿主机上对物理网卡（R8125）的优化，例如安装驱动、开启缓冲区、开启硬件多队列，这些是物理层面的优化，与 OpenWrt 虚拟机内部的 ethtool 命令无关。

PVE 宿主机上的 ethtool -K 和 ethtool -G： 这些命令应该在 PVE 宿主机上对物理网卡 (enpXsX 或 ensXX) 执行，以优化物理网卡本身。
PVE 虚拟机中的 ethtool -K 和 ethtool -G： 这些命令是在 OpenWrt 虚拟机内部对虚拟网卡 (eth0, eth1) 执行的。

确认 PVE 物理网卡设置：

SSH 登录到你的 PVE 宿主机。
使用 ip a 命令查看物理网卡的名称（例如 enp3s0和 eno1）。

查看物理网卡的 Ring Buffer：

ethtool -g <你的物理网卡名称，例如 eno1>

root@pve:~# ethtool -g eno1
Ring parameters for eno1:
Pre-set maximums:
RX:                     1024
RX Mini:                n/a
RX Jumbo:               n/a
TX:                     1024
TX push buff len:       n/a
Current hardware settings:
RX:                     1024
RX Mini:                n/a
RX Jumbo:               n/a
TX:                     1024
RX Buf Len:             n/a
CQE Size:               n/a
TX Push:                off
RX Push:                off
TX push buff len:       n/a
TCP data split:         n/a
root@pve:~# ethtool -g enp3s0
Ring parameters for enp3s0:
Pre-set maximums:
RX:                     1024
RX Mini:                n/a
RX Jumbo:               n/a
TX:                     1024
TX push buff len:       n/a
Current hardware settings:
RX:                     1024
RX Mini:                n/a
RX Jumbo:               n/a
TX:                     1024
RX Buf Len:             n/a
CQE Size:               n/a
TX Push:                off
RX Push:                off
TX push buff len:       n/a
TCP data split:         n/a
root@pve:~#

查看物理网卡的校验和卸载状态：

ethtool -k <你的物理网卡名称，例如 eno1>

root@pve:~# ethtool -k eno1
Features for eno1:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: on
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: on
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]
root@pve:~# ethtool -k enp3s0
Features for enp3s0:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: on
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: on
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
tx-gso-list: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]
root@pve:~#

在 PVE 宿主机上优化物理网卡：

对于 R8125 这样的 2.5G 网卡，如果宿主机性能足够，开启硬件卸载（包括校验和、TSO、GSO 等）通常是有益的。但是，如果你的 OpenWrt 虚拟机内部也开启了校验和卸载，有时可能会导致冲突。

鉴于你在 OpenWrt 内部已经关闭了校验和卸载，你可以保持 PVE 宿主机上的物理网卡默认开启硬件卸载，或者也尝试关闭看看效果。通常情况下，虚拟机的内部设置更重要，宿主机的物理网卡保持默认或开启卸载即可。

主要修改 OpenWrt 内部 rc.local 脚本，将网卡名称对调。
根据 ethtool -g ethX 的输出，微调 ethtool -G 的 Ring Buffer 值。
PVE 宿主机的物理网卡优化是另一层面的优化，与 OpenWrt 虚拟机内部的 ethtool 命令不直接冲突。

如果你是x86 PVE虚拟机, 可以看下面的配置: # 我的WAN是eth1,lan是eth0( br-lan), 你的和我相反的话, 只需要调换eth0和eth1位置即可.

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

# 以下是为 x86 PVE 环境优化的网络配置

# 1. 开启网卡 RPS 软负载均衡 (RPS = Receive Packet Steering)
# 注意：eth1 (WAN), eth0 (LAN)
# 'f' (二进制 1111) 代表将流量分发到所有 4 个核心。
# 如果你的 OpenWrt VM 分配了更多核心（例如 8核），可以改为 'ff' (二进制 11111111)。
# /sys/class/net/ethX/queues/rx-N/rps_cpus 表示将接收队列N的CPU负载分配到哪些核心

# WAN (eth1)
if [ -d /sys/class/net/eth1/queues ]; then
    for file in /sys/class/net/eth1/queues/rx-*/rps_cpus; do echo f > $file; done
fi

# LAN (eth0)
if [ -d /sys/class/net/eth0/queues ]; then
    for file in /sys/class/net/eth0/queues/rx-*/rps_cpus; do echo f > $file; done
fi

# 2. 优化网卡 Ring Buffer (防止突发丢包)
# 根据 OpenWrt 虚拟机内部 ethtool -g 的结果调整：
# eth1 和 eth0 的 RX 最大是 1024，TX 最大是 256。
if [ -x /usr/sbin/ethtool ]; then
    # eth1 (WAN): RX 最大 1024, TX 最大 256
    ethtool -G eth1 rx 1024 tx 256
    # eth0 (LAN): RX 最大 1024, TX 最大 256
    ethtool -G eth0 rx 1024 tx 256
fi

# 3. 关闭校验和卸载 (解决某些虚拟化/隧道兼容性问题)
# 针对 WAN (eth1), LAN (eth0) 和桥接接口 (br-lan)
if [ -x /usr/sbin/ethtool ]; then
    ethtool -K eth1 tx off rx off
    ethtool -K eth0 tx off rx off
    ethtool -K br-lan tx off rx off
fi

# 4. 优化内核队列 (配合 Ring Buffer，避免内核侧拥塞)
sysctl -w net.core.netdev_max_backlog=16384
sysctl -w net.netfilter.nf_conntrack_max=65536
sysctl -w net.core.somaxconn=65536 # 提高 TCP 连接队列最大值

# 启用 BBR 拥塞控制 (如果需要，并确保内核支持)
# BBR 对于 Tailscale 这种 WAN 优化很有用
# sysctl -w net.ipv4.tcp_congestion_control=bbr
# sysctl -w net.core.default_qdisc=fq

exit 0

(极佳)检查openwrt是否支持BBR

要判断你的 OpenWrt 内核是否支持 BBR，最直接的方法是：

SSH 连接到 OpenWrt。
检查内核模块： 运行以下命令：
```
lsmod | grep bbr
```
- 如果显示有 tcp_bbr 模块，说明内核支持 BBR。
- 如果没有任何输出，说明内核可能没有编译 BBR 模块。

检查可用的拥塞控制算法： 运行以下命令：

sysctl net.ipv4.tcp_available_congestion_control

#示例
root@iStoreOS:~# lsmod | grep bbr
root@iStoreOS:~# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = reno cubic #说明当前可用的拥塞控制算法只有 reno 和 cubic，不包含 bbr。
root@iStoreOS:~#

如果输出中包含 bbr (例如 net.ipv4.tcp_available_congestion_control = cubic reno bbr)，说明 BBR 模块已加载并可用。
如果输出中不包含 bbr，则不支持或未加载。

结论：我的 OpenWrt 当前不支持 BBR。

如何安装 BBR (如果不支持)？

如果你的 OpenWrt 内核默认不支持 BBR，你需要安装相应的内核模块。

更新软件包列表：
```
opkg update
```

查找 BBR 模块：

opkg list | grep kmod-tcp-bbr

# 示例
root@iStoreOS:~# opkg list | grep kmod-tcp-bbr
kmod-tcp-bbr - 6.6.110-r1 - Kernel module for BBR (Bottleneck Bandwidth and RTT) TCP congestion control. It requires the fq ("Fair Queue") pacing packet scheduler. For kernel 4.13+, TCP internal pacing is implemented as fallback.
root@iStoreOS:~#
# 这明确表示我的 OpenWrt 软件源中有可用的 BBR 内核模块，并且版本是 6.6.110-r1，这与我的内核版本是匹配的。

如果能找到类似 kmod-tcp-bbr - 5.10.XX-1-YYYY 的包，说明有预编译好的模块。

安装 BBR 模块：
```
opkg install kmod-tcp-bbr
```
- 安装完成后，通常会自动加载模块，但最好重启一下 OpenWrt 或者手动加载 modprobe tcp_bbr。
重启后再次验证： 登录 OpenWrt SSH 后，再次运行以下命令确认 BBR 已启用：

lsmod | grep bbr
sysctl net.ipv4.tcp_available_congestion_control
# 示范
root@iStoreOS:~# lsmod | grep bbr
tcp_bbr                16384 50
root@iStoreOS:~# sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = reno cubic bbr
root@iStoreOS:~#

这次应该能看到 tcp_bbr 模块和 bbr 拥塞控制算法。

取消 rc.local 中 BBR 配置的注释： 最后，编辑 /etc/rc.local 文件，将这两行前面的 # 去掉(上面的代码)：

sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.core.default_qdisc=fq

保存文件，然后再次重启 OpenWrt（这是为了确保 BBR 在每次开机时都被设置为默认）。

再次验证： 安装后，重复上面“检查可用拥塞控制算法”的步骤，确认 bbr 已经出现在列表中。

BBR 的优点 (对于 Tailscale/WAN 优化尤其突出)：

更好的带宽利用率： BBR 不像传统的基于丢包的拥塞控制算法 (如 Cubic) 那样依赖丢包来判断网络拥塞，它基于网络中的带宽和往返时间 (RTT) 来预测网络容量。
更低的延迟： BBR 试图在不填满缓冲区的情况下，最大化发送速度，从而减少排队延迟 (Bufferbloat)。
更少的丢包： 由于不依赖丢包作为拥塞信号，BBR 能够避免不必要的丢包。
公平性： 在混合网络中，BBR 与其他拥塞控制算法也能较好地共存。

潜在的“不好的影响”或需要注意的地方：

轻微的 CPU 额外开销： BBR 算法比 Cubic 更复杂一些，可能会带来微小的 CPU 额外计算量。但在你强大的 x86 4 核心 PVE 环境下，这几乎可以忽略不计。
某些网络环境中可能表现不佳 (极少数)： 虽然 BBR 在大多数广域网环境下表现优异，但在一些非常特殊、带宽极高但 RTT 变化剧烈的网络中，或者与某些极端保守的 TCP 实现混合时，理论上可能表现不如预期。但这种情况非常罕见，尤其是在家庭宽带和 VPN 隧道场景。
内核版本依赖： kmod-tcp-bbr 模块必须与你的 OpenWrt 内核版本严格匹配。如果你的 OpenWrt 是自编译的或者经过大幅修改，可能需要自己编译 BBR 模块。但对于官方或常见固件，opkg 安装通常没问题。

开启 BBR 后，你应该会发现通过 OpenWrt 路由出去的 TCP 连接（包括通过 Tailscale 转发的 TCP 流量）在带宽利用率和延迟方面都有更好的表现。

使用多线程对抗丢包

使用8~32线程对抗即可, 用人海战术. 一般16就行了.

修改Openwrt 增大网卡环形缓冲区 (Ring Buffer)

这一步被上文openwrt安装RPS (软件负载均衡) 的配置文件统一合并.

这是最立竿见影的方法。如果不及时处理，包就会在这里被丢掉。

安装工具：
```
opkg update
opkg install ethtool
```
查看当前大小：
```
# 查看 WAN 口 (eth0) 设置
ethtool -g eth0
```
- 会看到 Pre-set maximums (硬件支持的最大值) 和 Current hardware settings (当前值)。
- 通常默认值很小（比如 256 或 512）。
修改为最大值： 假设最大值是 4096 (常见值)：
```
ethtool -G eth0 rx 1024 tx 1024
# 先看一眼 eth1 的上限（通常也是 1024，但也确认一下） 
ethtool -g eth1 # 如果上限也是 1024，直接拉满 
ethtool -G eth1 rx 4096
ethtool -g eth1
```
- 原理： 增大缓冲区，让 CPU 来不及处理的突发数据包先在内存里“排队”，而不是直接被丢弃。
- 注意： 这会消耗少量内存，但看截图还有 600MB+ 空闲，完全没问题。
修改启动脚本 (重要)

之前的 /etc/rc.local 脚本也需要对应修改，eth0 和 eth1 的命令要分开写，因为参数不同。

请将启动脚本修改为：

# 优化网卡 Ring Buffer
if [ -x /usr/sbin/ethtool ]; then
    # eth0 (WAN) 支持双向调节，设为 1024
    ethtool -G eth0 rx 1024 tx 1024
    
    # eth1 (LAN) 只支持调节 RX，且支持更大，设为 4096
    ethtool -G eth1 rx 4096
fi

协议分析和软件

在配置上面的优化后, 速度从86 Mbits/sec提升到了399 Mbits/sec !

根据 399 Mbits/sec 测速结果 和 NAS 支持的服务，最佳使用姿势如下：

场景	推荐协议	推荐软件	预期体验
异地搬运大文件 (几十GB)	FTP	FileZilla (开启多线程)	🚀 极速 (跑满 280Mbps，约 35MB/s)
异地看电影/浏览图片	WebDAV	RaiDrive / PotPlayer	📺 流畅 (拖动进度条稍有延迟，播放稳)
异地下载单个大文件	WebDAV	NDM (32线程下载)	⚡ 极速 (跑满带宽)
异地改文件名/删文件	SMB	Windows 资源管理器	🐢 稍慢 (但在可接受范围内)

建议：

既然开了 Tailscale，可以放心地试一下 FTP + FileZilla。相比 SFTP，标准 FTP 在 Tailscale 隧道里 CPU 消耗更低，速度可能会更稳！

FTP+filezilla

最大10线程，设置中无法再增加，设置只能1-10并发传输。
客户端 - FileZilla中文网

Air Explorer +ftp

网络在 8~16 线程 下表现最稳, 设置上传16下载8

并行分块下载大文件：已勾选

在 FTP 协议 下，需要了解 “单个大文件” 和 “一堆小文件” 的区别：

场景 A：上传一个文件夹（里面有 100 张照片或 10 集电视剧）
- 速度： **起飞。
- 原理： 软件会启动 16 个线程，同时传 16 个文件。总速度就是 16 个文件的叠加，预计能达到 25-40 MB/s。
场景 B：上传“单个” 20GB 的压缩包
- 速度： 可能只有 5-10 MB/s（取决于 Air Explorer 对 FTP 分片上传的支持程度）。
- 原理： 大多数 GUI 客户端（包括 Air Explorer）在 FTP 协议 下，往往不支持把“单个文件”切成几块同时上传（因为 FTP 协议本身对并发写入支持较差）。这时候它可能会回落到单线程。
- 解决： 如果发现传单个大文件慢，不用怀疑设置，那是软件和协议的物理限制。Rclone 是解决这个单一场景的唯一终极方案。

rclone

Site Unreachable

Rclone downloads
RcloneBrowser | Simple cross platform GUI for rclone. Supports macOS, GNU/Linux, BSD family and Windows.
Releases · kapitainsky/RcloneBrowser

Rclone + Rclone Browser 是目前在 Windows 上免费实现 多线程分片下载/上传（榨干带宽）的终极方案。

第一步：下载必要软件

需要下载三个东西（都是绿色软件，解压即用）：

Rclone (核心程序):
- 下载地址：https://rclone.org/downloads/
- 选择 Windows - 64 Bit 的 Zip 包。
Rclone Browser (图形界面):
- 下载地址：https://github.com/kapitainsky/RcloneBrowser/releases
- 下载最新的 .zip 或 .exe 安装包。
WinFsp (挂载依赖 - 可选但推荐):
- 如果以后想把 NAS 挂载成电脑的一个盘符（像 Z 盘），必须安装这个。
- 下载地址：https://winfsp.dev/rel/

第二步：整理与安装

安装 WinFsp： 双击安装包，一路 Next 安装即可。
解压 Rclone： 把下载的 rclone-v1.xx-windows-amd64.zip 解压到一个固定目录，例如 D:\Tools\Rclone。会看到 rclone.exe。
解压 Rclone Browser： 同样解压，建议放在 D:\Tools\RcloneBrowser。

第三步：配置连接 (核心步骤)

我们需要先用 rclone.exe 生成配置文件，告诉它怎么连 NAS。我们使用 SFTP 协议，因为它最稳定且支持分片。

打开资源管理器，进入存放 rclone.exe 的文件夹 (D:\Tools\Rclone)。
在地址栏输入 cmd 并回车，打开黑窗口。
输入 rclone config 并回车。
按照以下交互进行输入 (请根据实际情况):
- n (新建 New remote) -> 回车
- name: 输入 MyNAS (名字随便起) -> 回车
- Storage: 会出现一长串列表，找到 SFTP (通常是数字 40+)，输入 sftp -> 回车
- host: 输入 Tailscale IP 123.123.121.121 -> 回车
- user: 输入 NAS 用户名 -> 回车
- port: 输入 22 (或者 SSH 端口) -> 回车
- pass: 输入 y (Yes, 输入密码) -> 回车
  - 注意：输入密码时屏幕不会显示任何字符，输完按回车，再输一次确认。
- key_file: 直接回车 (留空)
- ...接下来的选项（key_file_pass, md5sum 等）全部直接 按回车 使用默认值即可...
- 直到看到 Edit advanced config? -> 输入 n (No) -> 回车
- 最后看到 Keep this "MyNAS" remote? -> 输入 y (Yes) -> 回车
- 输入 q (Quit) 退出。

恭喜，配置文件生成完毕！

第四步：设置 Rclone Browser (连接 GUI)

运行 RcloneBrowser.exe。
如果是第一次运行，它会弹窗让设置路径：
- rclone location: 点击 Browse，选择刚才解压的 D:\Tools\Rclone\rclone.exe。
- rclone.conf location: 通常它会自动识别。如果没有，它通常在 C:\Users\用户名\.config\rclone\rclone.conf。
点击 OK。
现在应该能在主界面看到刚刚创建的 MyNAS 了。双击它，稍等片刻，就能看到 NAS 里的文件列表了。

第五步：关键性能调优 (如何跑满)

如果不设置这一步，它和普通软件没区别。我们要开启多线程分片。

在 Rclone Browser 中，点击左上角的 File -> Preferences。
找到 Transfers (这里是默认设置，针对多文件)：
- Transfers: 建议改为 8 或 10 (同时传 8 个文件)。
- Checkers: 改为 16。
针对“单文件跑满带宽”的设置：
- Rclone Browser 的全局设置里可能没有直接暴露 multi-thread-streams，我们需要在执行任务时设置，或者修改 Rclone Browser 的默认参数。
- 推荐做法：
  - 在 Rclone Browser 里选中要下载的文件/文件夹，点击 Download。
  - 在弹出的对话框中，会看到一行 "Extra arguments" (额外参数)。
  - 请在这行里填入：
    
    Plaintext
```
--multi-thread-streams 8 --buffer-size 64M
```
  - (解释：--multi-thread-streams 8 表示把一个大文件切成 8 块同时下；--buffer-size 64M 增大内存缓存防止断流)
点击 Run。

第六步 (可选)：挂载为本地硬盘 (像 RaiDrive 那样)

如果想把它变成一个 Z 盘，并且拥有 Rclone 的高性能：

在 Rclone Browser 主界面，选中 MyNAS。
点击上方的 Mount 按钮。
Mount Point: 选择一个盘符 (例如 Z:)。
Extra arguments 填入：

Plaintext
```
--vfs-cache-mode full --vfs-cache-max-age 24h --vfs-read-chunk-size 64M --vfs-read-chunk-size-limit off
```
(这一串参数非常重要，开启全功能缓存，能极大提升在 Windows 资源管理器里的浏览和播放体验)
点击 Run。

iperf3打流测试最大速度

NAS-Docker安装

安装networkstatic/iperf3
端口为5201:5201
name=iperf3-server

Windows安装

第一步：下载 iPerf3

点击此链接下载 Windows 64位版本： iperf3-3.1.3-win64.zip (如果链接打不开，请访问 iperf.fr 官网下载)

第二步：解压与运行（最简便方法）

下载后，将压缩包解压到一个文件夹（比如直接解压在“下载”里的 iperf-3.1.3-win64 文件夹）。
进入解压后的文件夹，会看到 iperf3.exe 和 cygwin1.dll 这两个文件。
关键操作： 在当前文件夹的地址栏（就是显示文件路径的地方），输入 cmd 并按回车。
- 这会自动打开一个命令提示符窗口，并且路径已经定位到了这个文件夹。

./iperf3 -c 192.168.50.201 -P 8 即可，后面的是线程数。

Linux安装

sudo apt-install iperf3
有弹窗选择NO。

为了方便查看测试结果： 现在是为了排查网络问题。如果选择 <Yes>（作为守护进程后台运行），iperf3 会在后台默默工作，在屏幕上看不到“谁连上来了”、“当前速度是多少”等实时日志。
按需运行： 作为测试工具，通常只需要在想测速的时候手动运行一下即可，没必要让它 24 小时占用后台资源和端口。
iperf3 -c 192.168.50.201 -P 8

Retr (Retransmission) 重传数，严重的重传会导致 TCP 拥塞控制算法（CUBIC/Reno）疯狂降低发送速率，这就是为什么速度上不去且剧烈波动的原因。

结果分析

如果 iPerf3 能跑出 200Mbps (约 25MB/s) 以上且比较稳定，说明网络链路、Tailscale 加密、CPU 性能都没问题。
如果 iPerf3 依然在 2~11MB/s 波动，说明是运营商对 UDP 流量进行了 QoS 干扰（见下文 MTU 优化）。

如何针对笔记本进行优化？(可选)

如果想减轻 OpenWrt 和 AP 之间那根网线的压力，并降低笔记本的延迟，可以在 Windows 笔记本 上添加一条 “静态路由”。

目的： 让笔记本直接把数据包扔给 Ubuntu，跳过 “笔记本 -> OpenWrt -> Ubuntu” 这个绕路环节。

操作步骤（仅在笔记本电脑上执行）：

以管理员身份打开 CMD (命令提示符)。
添加路由命令： 假设 Ubuntu Server IP 是 192.168.6.x (例如 192.168.6.100)，NAS 网段是 192.168.50.0。

PowerShell
```
# route add -p [目标网段] mask [掩码] [下一跳网关IP]
# 请将 192.168.6.100 替换为 Ubuntu 的真实 IP
route add -p 192.168.50.0 mask 255.255.255.0 192.168.6.100
```
- -p: 表示永久生效 (Persistent)，重启后还有。

优化后的路径：

之前： 笔记本 -> AP -> OpenWrt -> AP -> Ubuntu
之后： 笔记本 -> AP -> Ubuntu (少走了一次 OpenWrt，少了一次转发延迟)

深度解析：为什么 `-P 4` 反而比 `-P 16` 更快？

可能会觉得：“之前不是说线程越多越好吗？为什么现在线程少了反而快了？”

这得益于之前做的一系列底层优化（r8125驱动、多队列、443端口伪装），现在的网络环境变了：

1. 1:1 完美映射 (CPU 效率最高)

硬件层： 的网卡现在有 4 个 接收队列 (rx-0 到 rx-3)。
应用层： 开启了 4 个 iPerf3 线程 (-P 4)。
效果： 理想情况下，Linux 内核会将这 4 个数据流分别分配给 4 个不同的 CPU 核心和网卡队列处理。
- 没有争抢： 每个核心专心处理一个流，上下文切换（Context Switch）最少，CPU 缓存命中率最高。
  - 效率极致： 这就是为什么看到了 323 Mbps 的新高。

2. 边际效应递减 (过犹不及)

当开 -P 16 时：
- 网卡只有 4 个队列。这意味着平均每个队列（和对应的 CPU 核心）要同时处理 4 个 TCP 流。
- 后果： CPU 需要频繁在不同的流之间切换，增加了软中断的开销。而且，16 个流同时抢占带宽，会导致更激烈的拥塞控制竞争，反而增加了重传（Retr）的混乱程度。

3. BBR 的强大能力

在未优化前（默认 CUBIC 算法），单线程“太怂”，所以需要用 16 个线程（人海战术）来填满带宽。
现在开启了 BBR 且换了 443 端口，单线程的“战斗力”大大增强。4 个精锐部队（BBR 线程）已经足够打满 350Mbps 的带宽了，不需要 16 个杂牌军来凑数。

💡 最终建议：如何选择线程数？

在未来的实际使用（如 Rclone、Air Explorer）中，请遵循以下原则：

基准选择： 4 到 8。
- 设置为 4：最省 CPU，理论效率最高。
- 设置为 8：容错率稍好。如果某一个线程突然断流，还有其他 7 个撑着。
什么时候用 16+？
- 只有当发现 4 线程跑不满带宽（例如卡在 100Mbps），且 CPU 占用率很低时，才尝试增加到 16。
- 在现在的环境下，超过 8 线程纯属徒增功耗。

在 OpenWrt 上添加静态路由

需要做的是在 OpenWrt 上添加一条静态路由，告诉它：“凡是有人找 192.168.50.x，别往外网扔，转交给 Ubuntu (192.168.6.152) 处理”。

操作步骤：

登录 OpenWrt (iStoreOS) 后台。
进入 网络 (Network) -> 静态路由 (Static Routes)。
点击 添加 (Add)。
填写如下信息（请根据实际 IP 填写）：
- 接口 (Interface): lan
- 目标对象 (Target): 192.168.58.0 (注意：提到的是 58 段，如果之前是 50 段，请核对清楚)
- 子网掩码 (Netmask): 255.255.255.0 (/24)
- IPv4 网关 (Gateway): 填写 Ubuntu Server 的局域网 IP (例如 192.168.6.100)
- 度量值 (Metric): 0 (或者留空)
点击 保存并应用。

生效后： 手机再次访问 192.168.50.201 -> 发给 OpenWrt -> OpenWrt 查表发现该找 Ubuntu -> 转发给 Ubuntu -> 进入 Tailscale 隧道 -> 成功！

posted @ 2025-11-19 17:38 舟清颺阅读(3948) 评论(0) 收藏举报

刷新页面返回顶部

zqingyang