前言：
"在Oracle的e2.1.micro免费实例上安装了tailsacle，
设置为了exit出口，
Windows电脑也把这个实例作为所有流量exit出口，
第一天连接这个出口的网速很快，
但第二天、第三天就很慢，
在云南省文山州使用Windows电脑，e2.1.micro实例在Tokyo"一、可以通过如下命令优化网速：
这些命令是 Tailscale 官方推荐的性能优化配置，特别是针对作为 Exit Node（出口节点）的 Linux 设备。
-
tailscale netcheck检查当前网络连接状况（包括 UDP 是否可用、NAT 类型、到 DERP 中继服务器的延迟、是否能直连等）。这是 Tailscale 的诊断工具，用于排查连接问题，比如是直连还是走中继（DERP，中继速度通常慢很多）。
-
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")自动获取默认路由出口网卡的名称（通常是 eth0 或 ens3 等），后面 ethtool 命令会用在这个网卡上。
bash
# 获取网卡名称 ens3
ubuntu@:~$ ip -o route get 8.8.8.8
8.8.8.8 via 10.0.0.1 dev ens3 src 10.0.0.54 uid 1001 \ cache-
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off这是核心优化命令：
- rx-udp-gro-forwarding on：启用 UDP Generic Receive Offload 转发功能，能让内核批量聚合传入的 UDP 包，显著降低 CPU 开销，提高转发吞吐量（对 WireGuard/Tailscale 这种 UDP 隧道特别有效）。
- rx-gro-list off（接收通用接收分段列表）：关闭 GRO fraglist，防止它优先级高于上面的 UDP GRO 转发，导致优化失效。
Tailscale 1.54+ + Linux 内核 6.2+ 时，作为 Exit Node 或 Subnet Router 时强烈推荐开启，能明显提升 UDP 转发性能。
-
最后的 ethtool 检查命令：验证设置是否生效。
bash
ubuntu@:~$ ethtool -k $NETDEV | grep -E 'rx-udp-gro|rx-gro-list'
rx-gro-list: off
rx-udp-gro-forwarding: on总结：这些命令优化了 Linux 内核对 UDP 流量的接收/转发能力，减少 CPU 消耗，提高 Tailscale Exit Node 的吞吐量（尤其是高流量场景）。不设置的话，Tailscale 会提示 "UDP GRO forwarding is suboptimally configured" 警告，性能受限。
注意 ：ethtool 修改重启后会丢失，建议按 Tailscale 文档用 networkd-dispatcher 做开机自动生效。
"第一天快，后面慢"的原因
Oracle e2.1.micro 是 burstable（可突发） 的免费实例，只有很低的 baseline CPU（约 1/8 核），有 CPU 积分（credit）机制。
- 第一天快：实例有积累的 CPU credit，能突发高性能。
- 第二天/第三天慢：CPU credit 耗尽，只能跑很低的 baseline 性能，Tailscale WireGuard 加密 + 转发会很吃 CPU，导致整体变慢。
其他可能原因（跨国 + 中国网络环境）：
- 直连变中继（DERP）：东京到云南的 UDP 直连可能不稳定，尤其是 Oracle 的网络策略或中国出口限速。
tailscale netcheck能确认。 - Oracle 免费实例网络本身有一定限制 + 长时间高负载。
- Windows 客户端问题或 MTU 不优。
建议优化步骤
-
立即检查：
- 在 Exit Node（Oracle）上运行
tailscale netcheck和客户端的tailscale netcheck，看是否直连（Preferred DERP 相同且 latency 合理）。 - 检查 CPU 使用率（
htop或top），看是否长期 100%。
- 在 Exit Node（Oracle）上运行
-
应用上面 GRO 优化（已经贴的命令），并做持久化。
-
考虑换实例（强烈推荐）：
- Oracle Ampere A1（ARM）免费实例转发性能远好于 E2 micro，即使 1 OCPU 也能轻松跑几百 Mbps。很多用户反馈用 ARM 后速度大幅提升。
-
其他优化：
- 确保 IP forwarding 和 iptables 配置正确（Tailscale exit node 需要）。
- Windows 客户端试试调整 MTU（有时默认 1280 太保守）。
- GRO 优化还没持久化或没完全生效
- Windows 客户端 MTU 或驱动问题
立即诊断命令（请在 Windows 电脑 上运行）
powershell
# 1. 看具体到 Exit Node 的连接详情
tailscale ping 你的-exit-node-hostname # 或 tailnet IP
# 2. 客户端自己的 netcheck
tailscale netcheck优化建议
- 应用你之前提到的 GRO 命令，并做开机持久化（参考 Tailscale 文档用 networkd-dispatcher）。
- 在 Windows 客户端尝试：
tailscale down && tailscale up --exit-node=xxx --reset- 调整 MTU：
tailscale up ... --mtu=1280（或 1420 测试）
- 监控 Exit Node CPU：
htop，如果长期接近 100%，就是 CPU 瓶颈。
二、查看mtu值
bash
PS C:\Users\> netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 1326587 Loopback Pseudo-Interface 1
1280 1 2418943923 643979728 Tailscale
1500 5 0 0 Ethernet
1500 1 1209466813 430082065 Wi-Fi 2
1500 5 0 0 Local Area Connection* 9
1500 5 0 0 Local Area Connection* 10
1500 1 0 277173 vEthernet (Default Switch)
1500 5 0 0 vEthernet (June9virtual_Switch)1，1280 是 Tailscale 的默认值**，也是最常用的推荐值。**
默认1280的原因
- 这是 IPv6 要求的最小 MTU（RFC 标准规定 IPv6 至少支持 1280）。
- Tailscale 是 WireGuard 隧道，会有一定的封装开销（UDP + 加密头）。默认 1280 能在绝大多数网络环境下稳定工作，避免分片（fragmentation）和丢包。
- 对大多数用户（尤其是跨地区、跨运营商）来说，1280 是一个安全且平衡的选择。
在你这个场景下的建议
你的 Oracle → 云南是长距离国际直连 ，网络路径复杂（中间可能有各种 NAT、防火墙、中国出口等），默认 1280 已经算保守，但不一定是"最优"。
很多用户（包括 Reddit 上反馈）在类似长距离或不稳定链路上，把 MTU 再调低到 1250 或 1200 后，反而获得更高吞吐量和更稳定的速度。
快速测试建议
继续用你当前的 Wi-Fi 环境，依次测试下面几个值（每次改完测速 30-60 秒）：
powershell
tailscale down
# 最推荐先测这两个
tailscale up --exit-node=ccpp --reset --mtu=1250
tailscale up --exit-node=ccpp --reset --mtu=1200
# 如果还想试
tailscale up --exit-node=ccpp --reset --mtu=1280 # 默认值
tailscale up --exit-node=ccpp --reset --mtu=1150 # 再低一点（极限测试）